The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Venu,

    I find myself in the ironic position of trying to defend a specification's
'weaknesses' that I have pointed out previously.  The irony is that I find
myself 'passing on' the same arguments that were given to me then.  I
am not representing that I agree or disagree with these arguments, but I
did find them at least somewhat mollifying at the time.

    Perhaps, after this attempt, if you are not satisfied with my restatment
of these arguments - then you should probably take this discussion up
with the RFC's authors.

    As much as procedures in the Appendix look like function calls, they
are not intended to be as precise as that.  There is - for instance - no
intention that every implementation should implement precisely these
procedures, arguments, steps and/or data structures.  The procedures
in the Appendix are not like a MIB specification that is intended to just
compile and run correctly.

    An example of how to interpret the Appendix might be to look at the
argument "InitAttributes" as a place holder in the procedure call to the
procedure "Prepare_Label_Mapping_Attributes" that is needed because
- in new FEC processing - there is no "RAttributes" to pass.  In this
case - assuming that an implementation was trying to follow the steps
in the Appendix as closely as possible - an implementor would most
likely implement a variation of "Prepare_Label_Mapping_Attributes"
that did not require this argument and used the values from RAttributes
stored previously.

    If you look at the section of the Appendix that defines RAttributes in
"Prepare_Label_Mapping_Attributes", you will see that it defines it as:

    "The attributes this LSR associates with the LSP for FEC."

Analyzing this statement in the abstract, this would mean - in this
specific case - the RAttributes recorded earlier in association with a
Label Mapping received from the next hop for this FEC.

--
Eric Gray

You wrote:

> Eric,
>
>     FEC.1.DUI.3 passes the value InitAttributes corresponding to the
> parameter
>     RAttributes in the function Prepare_Label_Mapping_Attributes.
>     As given in Notes 1 of New FEC procedure, InitAttributes will not
> include a known
>     hop count or a path vector. So, RAttributes is not the attribute
>     received from the fec next hop. So, effectively the hop count is set
>     to unknown hop count even if Propagating is set to IsPropagating (which
>     is possible only in the liberal retention mode) and this does not
>     look correct.
>
> - Thanks
> Venu.G.S
>
> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@sandburst.com]
> Sent: Tuesday, September 11, 2001 7:58 PM
> To: Abhijit Gadgil
> Cc: Venu G.S; mpls@UU.NET
> Subject: Re: Doubt in New FEC procedure, FEC.1
>
> Abhijit,
>
>     The key words and tricky phrase here was 'may be accepted'.  I meant
> that
> an LSR cannot accept a label mapping for a FEC for which it does not have a
> route table entry.  In that case, the FEC would have to be known before
> label
> mappings may be accepted for it.  On re-reading the specification, however,
> the exact wording is:
>
>    "An LSR receiving a Label Mapping message from a downstream LSR for a
>    Prefix or Host Address FEC Element should not use the label for
>    forwarding unless its routing table contains an entry that exactly
>    matches the FEC Element."
>
> And I had incorrectly read into this that the LSR would release the label.
> This would not be the case if the LSR is using liberal retention - as is
> likely to be the case if it is also using DU distribution.  This may be
> verified by following the 'Receive Label Mapping' procedures in Appendix.
> In the case Venu raised, the steps would be LMp.1, LMp.3, LMp.9, LMp.11,
> LMp.12, LMp.13 and either LMp.32 (where the label would be released in
> the conservative retention mode) or LMp.33 (where it would not be in the
> liberal retention mode).
>
> In this case, Venu would have a valid point - except that (in an arcane
> sort of way) the procedures for handling a new FEC takes into account the
> retention mode (see FEC.1.DU.2 and 3) and - if liberal retention is used
> AND if a Label Mapping has previously been received and retained for the
> next hop associated with this FEC - then the hop count for the previously
> retained label mapping would be incremented and used in upstream Label
> Mapping.  This can be seen from the "Prepare_Label_Mapping_Attributes"
> procedure which - in this case - would include steps PMpA.1, PMpA.2, PMpA.4,
> PMpA.5, PMpA.7, PMpA.9, etc.  Step PMpA.7 is where the value of the hop
> count in the corresponding received Label Mapping attributes is incremented
> and set in the send attributes for Label Mappings to be sent upstream.
>
> --
> Eric Gray
>
> You wrote:
>
> > Eric,
> >
> > I have some doubt here.
> >
> > EG> In that case, there is an ordering constraint on the way in which
> Label
> > EG>Mappings and new FEC information must arrive.  The new FEC must be
> > EG>recognized before a Label Mapping for this FEC may be accepted from
> > EG>a peer LSR.
> >
> > How can this be guaranteed? Since the two entities involved in the
> > corrosponding events are independent if not uncorrelated.
> >
> > -abhijit