Subject: Label Release receive doubt !!

From: Manoj Dutta <[email-masked]>
Date: Fri, 11 May 2001 15:06:28 -0700

Hi,

While going through RFC 3036 (LDP) section A.1.4 (label release
processing ), I came across the following section :

LRl.5     LRl.5  Has LSR previously advertised a label for this FEC  to
other peers ?
              If so, goto LRl.10

If this check fails (ie LSR has not advertised any labels to other peers
for this FEC), the corresponding downstream label may be released. Now,
consider the case below :

There are three LSRs        Ra-----Rb-------Rc connected in a striaght
line as shown (Rc being the downstream LSR for Rb and so on).
Now lets assume Ra is non merge capable and Rb is merge capable.
For a given FEC F, Ra requests multiple labels from Rb (one for each of
Ra's upstream peers for F). In response to these requests, Rb gives
label mappings {Lb1, Lb2, Lb3.....} to Ra and binds all these mappings
to Label Lc received from Rc for F. Now Ra releases one of the labels,
say Lb1, which it got from Rb for F. Now according to LRl.5,  Rb checks
if there are any other peer holding labels for Lc (downstream label from
Rc for FEC F). The check fails as Ra is the only peer holding labels for
F. In this case, Rb may release the downstream label Lc (if release
propagation is configured in Rb). This leaves other labels like {Lb2,
Lb3...}
sent to Ra from Rb (for FEC F) without any outgoing label on Rb. Thus
the packets from Ra labelled with
{Lb2, Lb3 ...} will need to use ip forwarding to reach Rc.

I think we should not release a downstream label as long as there is
even one upstream label mapped to it but  the procedure described
doesn't seem to take care of this case. Let me know if there is anything
I am missing here.

Thanks in advance,
Manoj

---

From: Bob Thomas <[email-masked]>
Date: Fri, 11 May 2001 18:15:43 -0400

Manoj,

> doesn't seem to take care of this case. Let me know if there is anything

I think you have found an error in LRl.5.  The intent is as you
suggest, but LRl.5 doesn't correctly specify that intent.  LRl.5 should
be saying something like:

   LRl.5   Has LSR previously advertised a label for this FEC to other
           peers or another label for this FEC to MsgSource?
           If so, goto LRl.10.

or:

   LRl.5   Does LSR have outstanding label advertisements for this FEC?
           If so, goto LRl.10.

Thanks,
Bob

---

From: Eric Gray <[email-masked]>
Date: Mon, 14 May 2001 10:59:36 -0400

Bob,

    Thanks to Manoj's picking up on this, I thought about what other
messages I may have missed earlier.  Unfortunately, I believe the
same problem exists with the procedures for label abort request
processing - in particular LAbR.8, which says:

 "LAbR.8  Are there upstream peers other than MsgSource that have
  requested a label for FEC?
  If so, goto LAbR.11."

If there are other outstanding requests for MsgSource, this test will
fail (as it is now written) and LAbR.9 will be executed, resulting in
killing the downstream propagation of these other requests.

    Sorry I didn't catch this before.  The fix would be nearly indentical
to your proposed fix for LRl.5