The MPLS WG Archive

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

Vijay,

    Short answer: your assumption about propagation of HC/PV beyond
the intermediate LSR that intiates a 'local repair' is wrong.

    Both Hop Count and Path Vector would need to be included in a label
mapping message only to the extent that they were previously included.
When using explicit route objects, use of Hop Count or Path Vector is
somewhat redundant, since it is impossible to explicitly route a loop.
While this is particularly in the strict ERO case, since it is possible for
a loop to occur in that portion of an LSP that is either loosely specified,
or strictly specified using an abstract node (e.g. - an AS number), either
Hop Count or Path Vector need only to be used in loosely specified LSP
segments in order to ensure that the resulting LSP is loop free.  Also, it
is a general truth that - if you can be certain that ordered control is used
through out the length of an LSP, than you can be sure Label Mappings
will not be received by the ingress to any portion of the LSP if there is a
loop in the downstream LSP setup control path.

    In the case that you mention, for instance, as soon as the intermediate
LSR receives a Label Mapping - with or without a Hop Count or a Path
Vector - it may assume that the corresponding LSP is loop free.  Since -
in this case - this LSR is the originator of the initial Label Request, there
is no reason for it to send a new Label Mapping to any upstream peer.

    This brings up a minor failing in the protocol: if Hop Count is used to
set the TTL decrement value (at the ingress of the LSP) - for an ATM
LSP for example - then the only way for the intermediate LSR to ensure
that an accurate Hop Count is received by the ingress is to tear down the
LSP and force the ingress to re-establish it.  This is a minor failing since
the ingress can ensure that this happens by disallowing 'local repair' (the
process you describe in this case) during LSP setup.

--
Eric Gray

You wrote:

> Hello all,
> I have a question regarding label distribution in CR LDP.
>
> Assume that a CR LSP is established and at an intermediate LSR a Next Hop
> change occurs. When the intermeditate LSR requests for and gets a mapping
> from the New Next hop it will propagate the mapping upstream since the HC/PV
> values have changed(according to procedures in RFC3036 which is applicable
> for CR LDP also). This mapping is, strictly speaking, an unsolicited
> mapping. So, is this behaviour of propagating the mapping upstream because
> the HC /PV attributes differ from the values in the previous mapping,
> correct for Dod Ordered control .
>
> If so, what will be the request message ID in the mapping message ?. In CR
> LDP, the request message ID TLV is mandatory for the mapping message.  Would
> it be correct to use the request ID of the last request received from
> upstream, for which mapping was already sent. This strategy will prevent the
> upstream from reusing that message ID indefinitly.
>
> Please clarify and correct me if I am wrong.
>
> Thanks in advance,
> Regards,
> Vijay