The MPLS WG Archive

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

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