Subject: LMp. 17 in rfc3036.

From: Abhijit Gadgil <[email-masked]>
Date: Fri, 15 Jun 2001 15:28:22 +0530 (IST)

Hi,

perhaps it's pointed out before, but inclusion of MsgSource in the loop of
LMp. 17 seems somewhat problematic.

Consider
Ru - Upstream guy (DU ordered, Loop Detection = Yes)
Rd - Downstream guy (DU ordered, Loop Detection = Yes)
F  - FEC in question.

Assume Rd is not egress for the FEC, then according to section 2.8.2, Rd
will send Path Vector to Ru.

If Rd sends mapping for fec F to Ru.
and as a part of loop of LMp. 17
Now at Ru according to LMp. 18 - LMp.21

LMp. 18 - No
LMp. 19 - Yes
LMP. 20 - (PV = (LSRid Ru, LSRid Rd), Hop Count = 0)
LMp. 21 - send message to Rd.

Now when Rd receives this message, it will detect a loop according to
Check_Received_Attributes, it will NAK the message, with Loop Detected.

So the purpose of sending the message is lost (Even with Liberal
Retention at Rd).

not inclusion of Rd in LMp. 17 is perhaps, problematic if Rd is of the
type RequestNever.(Which is likely in DU) and Then Rd may never get
mapping from Ru if Ru becomes nexthop for the same FEC sometime. But then
in that case. Upon receiving Mapping from new next hop Rd1 (below), Ru
will propagate it to Rd (As a part of LMp. 17 loop again).which won't be
NAKed then.

Initially
      ----------->
   Ru ------------ Rd
   |
   |
   |
   Rd1

Later (perhaps)
      <----------
   Ru ------------ Rd
   | |
   | |
   | v
   Rd1

This may not be problematic if Loop Detection is not enabled and Rd does
not send Path Vector in Mapping to Ru.

Of course this is not harmful as far as the normal operation goes. It's
only unnecessary. Am I missing something?

thanks and regards

-abhijit

---

From: Eric Gray <[email-masked]>
Date: Fri, 15 Jun 2001 09:59:08 -0400

Abhijit,

    Please see below.

This is interesting behavior.

Implied in the use of a Path Vector is the intent to use the corresponding
LSP as reflected by the Path Vector.  However, whether Ru provides a
label mapping to Rd in response to the label mapping it received from Rd
or not, it MUST NOT bind these two labels.  There is a logical disconnect
- therefore - in having Ru send a label mapping to Rd containing a path
vector with Rd in it already.

As you point out, Rd will detect a loop and release the Label Mapping it
receives from Ru, and the problem goes away.

> So the purpose of sending the message is lost (Even with Liberal

Not necessarily, see below.

> will propagate it to Rd (As a part of LMp. 17 loop again).which won't be

Correct.

> Initially

Exactly.

It  is not definitely wrong for Ru to send a label mapping to Rd for the
same FEC that Rd has just sent a label mapping to Ru - even though
Ru knows that Rd is the next hop for this FEC.  However, in doing so,
it is effectively NOT using ordered control since there is no downstream
label to which it can bind the label it is advertising to Rd.  As said before,
it is definitely wrong for Ru to bind the label it receives from Rd to the
label it advertises to Rd.

> only unnecessary. Am I missing something?

It can be useful, as you suggested, in the case where Rd is using DU,
and liberal retention, modes.

---

From: Abhijit Gadgil <[email-masked]>
Date: Sat, 16 Jun 2001 22:28:50 +0530 (IST)

Eric,

Few comments are not quite clear to me. Please see below.

 >label it advertises to Rd.

 Accepted, Ru MUST NOT bind it as u pointed out.

 >and liberal retention, modes.

I don't think it's even useful then because, it will be released by Rd,
as soon as it processes the mapping for the corresponding label.

At Rd., upon receiving this label.
LMp.1 - No
LMp.3 - yes
LMp.4 - No
LMp.8 - Send release for (Label L, FEC F).
LMp.33 - Ok

Note here LMp.13 or LMp.16 is not reached, so the label won't be retained
anyways.

The reason why Ru originally sent Label to Rd. was that Rd retains it
if configured for Liberal retention. But even in that case, Rd is not
retaining it at all. So it's not useful also.

If Ru simply does not send it to Rd, it saves on sending one Mapping
message and processing one Release message.  Rd saves on processing one
Mapping and sending one release. (this is just for one FEC)

I agree this won't hamper the data traffic, but there will be lot of
unnecessary Mapping and Release messages dancing. (This is not as a result
of some mis-configuration, but rather a protocol behavior)

Is this Correct?

-abhijit

---

From: Eric Gray <[email-masked]>
Date: Mon, 18 Jun 2001 10:04:20 -0400

Abhijit,

    Please see response below.

    For the record, though, it turns out that sending a Label Mapping to
message source was included in the current specified procedure in an
attempt to cover what was felt at the time to be a hole (see the Note
referenced previously for details).  As you have already pointed out,
this hole would mosty likely never occur in properly functioning LSRs
(a subsequent route change that introduces a requirement for the label
not previously distributed would also result in a new label distribution).
However, as may be inferred from your earlier observation (the PV may
result in loop-detection and release - if PV is enabled), strict following
of the currently specified procedure will do no harm.

    In other words, it is not necessary to distribute a label to MsgSource
as part of the procedure for handling a label distributed from MsgSource
- but it will do no harm if an implementation does so.  Consequently, it
does not seem necessary to take any sort of immediate action WRT this
issue and RFC 3036.

    Does this clear up the remaining muddy areas?

--
Eric Gray

> Note here LMp.13 or LMp.16 is not reached, so the label won't be retained

This was the case when Ru included a Path Vector that includes Rd.  As
pointed out already, this is strange behavior - since Ru cannot consider
the label it receives from Rd and the label is sends to Rd to be part of the
same LSP.

In the case where Ru sends a label to Rd - coincidental to the label it got
from Rd and for the same FEC - but either does not include a Path Vector
or includes a Path Vector with only itself included (as would be the case
if it were distributing this label independently), then Rd would be able to
retain this label.  This would be useful because Rd could immediately
start using this label in a topology change scenario in which Ru suddenly
becomes the next hop for this FEC relative to Rd.

Note that I am using the designations Ru and Rd in the context of prior
discussion.  In the scenario described above, these designations are
unfortunately chosen.