Subject: Clarification on Handling a specific event in LDP

From: "Ramia, Kannan Babu" <[email-masked]>
Date: Tue, 17 Sep 2002 22:07:45 -0700

Hi all
 
    I am encountering a peculiar situation where I need some clarification.
 
    Here is my problem
 
    My LSR A acts in DOD ordered mode (also assumed all the other LSRs in
the domain acts in the same mode). For a particular FEC X it has found
itself as an Egress LSR and it knows that the penultimate LSR B supports
IMPLICIT NULL LABEL and it distributed a NULL Label for that FEC X. Now in
the data plane at my LSR it will receive only unlabeled packets since the
penultimate LSR pops the label in the packet (assuming no stacking of
labels).
 
    Now in later point of time if some other LSR C gets added to this MPLS
Domain which happens to be my Next Hop for the FEC X. Now my LSR will become
an intermediate LSR for that particular FEC-X and it will request a label
from LSR C and install it in the forwarding plane. Now the problem arises
because it had distributed an NULL Label in the upstream, so before
installing this new label it needs to withdraw the NULL label from its
penultimate LSR B and redistribute a new label so that LSR B wont acts like
a proxy egress for this FEC-X. If we send a label withdraw message then that
message will progressively travel in the upstream direction and the whole
Lsp context will be lost. Since LSR A now send a new label map for the same
FEC-X the LSR B which receives it, will not propagate because it has been
configured as a DOD ordered mode.
 
    Can anyone suggest any solution to this problem...

I have a solution for this problem.
Basically if any LSR receives an Label withdraw message from its valid Next
hop neighbor then before propagating to its upstream peers it need to check
the value of the label being withdrawn, if the label happens to be an NULL
label then it should not propagate the label withdraw to its upstream peers.
Now this LSR should now assume itself as an egress for that LSP. 
 
Second one could be there should be a provision to change the label for the
particular FEC. I.e any point of time the valid next hop LSR can advertise a
change of label for that FEC. Here problems are we need to maintain the
context of that advertisement (LM).
 
Kannan Babu
Senior Network Software Engineer
Network Software Division
Intel Corporation         
Bangalore
841 2333 extn 2506

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Sep 2002 08:52:16 -0400

I think  this case  slipped through the  cracks, because  the use of  LDP in
DoD/Ordered mode was envisioned for  use in networks consisting of ATM-LSRs,
which of course don't do PHP.

Is this a practical problem for you, or simply a theoretical one?

---

From: Jack Brennen <[email-masked]>
Date: Wed, 18 Sep 2002 11:56:21 -0400

> Is this a practical problem for you, or simply a theoretical one?

It's an implementation detail for any implementor whose LSR gives out
NULL labels (either implicit or explicit).  Specifically, what should
the behavior be when a NULL label has been sent upstream, and a "real"
(non-NULL) label becomes available from the next hop (either through
a next hop change or through receipt of a Label Mapping or an Address
message)?  How is the behavior modified by the three major "knobs" of
LDP (DoD/Unsolicited, Ordered/Independent, Liberal/Conservative)?

RFC 3036 is silent on the matter, so I would assume that the behavior
is implementation-dependent, with the following possibilities (there
may be more, but these come to mind):

  (1)  Avoid the issue -- don't send NULL labels.  :-)

  (2)  Leave the NULL label in place; take no action.

  (3)  Withdraw the NULL label; readvertise using a non-NULL label
       only if the session supports Unsolicited advertisement.

  (4)  Withdraw the NULL label; readvertise using a non-NULL label
       regardless of the session's advertisement setting.

  (5)  Advertise using a non-NULL label, without withdrawing the
       NULL label.  The upstream peer *might* realize what you are
       trying to do...

It seems to me that any of these behaviors should be allowed; the
upstream peer should not interpret any of these behaviors as a
fatal error.  Additionally, it seems evident that any of these
behaviors is "acceptable" -- the data flow in question should be
correctly forwarded regardless of which behavior is chosen.

    Jack

---

From: Dan Tappan <[email-masked]>
Date: Wed, 18 Sep 2002 12:48:15 -0400

>correctly forwarded regardless of which behavior is chosen.

Actually, that point is arguable. In fact, in the case where the LSP in 
question didn't terminate at this LSR, i.e. where the FEC did not 
correspond to the LSR or to one of its connected interfaces, then 
advertising a NULL label at all will not produce correct forwarding 
behavior in the presence of a label stack.

So, the "correct" behavior is more like:

(1a) Advertise NULL labels only for terminating LSPs. For non-terminating 
LSPs, always advertise a non-NULL label even if no label has been received 
from the next-hop.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Sep 2002 13:42:11 -0400

Jack> It's an implementation detail for  any implementor whose LSR gives out
Jack> NULL labels 

No, it's only  an issue if the  LSR gives out NULL labels  on sessions which
are  running in  ordered DoD  mode.   If there  aren't any  such LSRs,  then
there's no problem in practice.  (Even  if the are such LSRs, it's still not
clear that there's much of a problem in practice.)

Jack> (1) Avoid the issue -- don't send NULL labels.  :-)

That works, but may have some costs.

Jack> (2) Leave the NULL label in place; take no action. 

This doesn't work, as Dan points out.

Jack> (3)  Withdraw the NULL label; readvertise using a non-NULL label
Jack>      only if the session supports Unsolicited advertisement. 

This isn't the case we're talking about.

Jack> (4)  Withdraw the NULL label; readvertise using a non-NULL label
Jack>      regardless of the session's advertisement setting. 

This will probably upset the peer.

Jack> (5)  Advertise using a non-NULL label, without withdrawing the
Jack>      NULL label.  The upstream peer *might* realize what you are
Jack>      trying to do...

This will probably upset the peer. 

Once you withdraw a label, you have to wait for the upstream peer to request
a new  label.  The upstream peer  could probably get away  with requesting a
new  label immediately,  not percolating  the withdraw  upstream  unless the
new  request is  refused.  Or the  upstream  peer could  just percolate  the
withdraws upstream,  in which  case the ingress  would have to  reinitiate a
request.  I  don't  really see  what  else  could  be done  without  causing
interoperability problems.