Subject: RE: CR LDP Label Mapping

From: Vijayanand C <[email-masked]>
Date: Fri, 27 Jul 2001 10:57:42 +0530

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:[email-masked]]
Sent: Thursday, July 26, 2001 9:24 PM
To: Vijayanand C
Cc: [email-masked]; [email-masked]
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

---

From: Eric Gray <[email-masked]>
Date: Fri, 27 Jul 2001 10:41:29 -0400

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