The MPLS WG Archive

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

Kishan,

    So, is there a question you are trying to ask?

    You made the same mistake I had made earlier, but you must not
have read the text you included below (from my earlier reply to Abhijit)
where I said:

"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)."

Otherwise, you would have realized that there is no step that says "if
unable to determine next hop in LMp.11, release the label mapping."
In liberal retention mode, it is not necessary to make this determination
in order to retain the label.  I admit that, at first, it didn't make sense to
me either - but there you have it.  :-)

--
Eric Gray

You wrote:

> A.1.6 talks about FECs which are learned via routing table.
> If a FEC label binding was received before the FEC was
> learned ( probably Route table has no matching entry for the FEC,
> or is not covered by FEC learning policy which is implementation
> dependent), the procedure 'Receive Label Mapping' in Appendix
> would follow
>
> LMp.1, LMp.3, LMp.9, LMp.11, stop here...
>
> LMp.11. Determine the Next hop for FEC..
>
> Now, the LSR should not be able to decide the next hop,
> because the FEC it self is not yet learned, hence
> release the binding .....
>
> Passing Unknown hop count as last argument value for procedure
> 'Prepare_Label_Mapping_attribute' is used to force the SAttributes,
> include a path vector of length 1 (own LSR ID)
> when both the following conditions hold !!!
>
> A) The LSR is configured for Loop Detection
>
> B) The attributes received from a downstream peer
>    have no path vector but have a non-zero hop-count.(known hopcount)
>
> --
> Kishan
>
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf
> > Of Eric Gray
> > Sent: Tuesday, September 11, 2001 7:28 AM
> > 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
> >
> >