The MPLS WG Archive

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

Vijay,

    Although it is intended to be informational, rather than standards track,
the LDP state machine draft actually provides perhaps clearer information
on handling local repair.  Not that 'local repair' in this sense is an artifact
of CR-LDP - hence it would not be explained in the LDP specification.

    Also, the fact that you do not need to propagate attribute changes all the
way to the ingress as a result of a local repair does not mean that you can't
get an accurate hop count.  I thought I made that clear.  If having an accurate
hop count is important, than local repair should be disallowed.  Simple enough,
really.

    Finally, the really long answer is that you CAN return a hop count as an
'unsolicited' label mapping even when operating in the DoD mode.  To see
why this is needed, think about the case where I have a mix of DoD, ordered
control and DU independent control mode LSRs involved in an LSP in basic
LDP.  In this mode, it is likely that a DoD LSR will receive an initial Label
Mapping with a Hop Count that is unknown and this will subsequently have
to be updated (when the LSP is established all the way to an egress).  When
this is necessary, no Label Request Message ID is required to determine the
context for the Label Mapping - the LSP 'request' (which was essentially
satisfied earlier) that it pertains to can be determined directly from the
Label.

--
Eric Gray

You wrote:

> Hello,
> For Dod Ordered control there is no need for checking the loop
> parameters(HC/PV) in the mapping message. This brings us to the question of
> why it is used in Mapping messages of CR-LDP. The understanding was that it
> helps the ingress to measure the TTL of the LSP for non- TTL decerementing
> doamins.Now,according to what you say, this purpose seems to be lost!
>
> Also in RFC 3036, in the procedure to handle to Label Mapping message(which
> is applicable for CR LDP also) , the mapping is redistributed to the
> upstream peers if the loop attributes change(LMP 22 to LMP 27), regardless
> of the distribution and control modes. So should this be modified or
> interpreted differently for CR LDP?
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@sandburst.com]
> Sent: Thursday, July 26, 2001 9:24 PM
> To: Vijayanand C
> Cc: mpls@UU.NET; gopinathg@ctd.hctech.com
> Subject: Re: CR LDP Label Mapping
>
> 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