The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

Dan,

	Please see below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> -----Original Message-----
> From: Dan Tappan [mailto:tappan@cisco.com]
> Sent: Wednesday, September 18, 2002 1:43 PM
> To: Gray, Eric
> Cc: Jack Brennen; MPLS (E-mail)
> Subject: RE: Clarification on Handling a specific event in LDP
> 
> At 01:00 PM 9/18/2002 -0400, Gray, Eric wrote:
> >Dan,
> >
> >         The distinction between terminating LSPs and
> >non-terminating LSPs is not always readily apparent.
> >One of the scenarios I pointed out (much) earlier
> >is the one in which LDP is 'turned on' in a router.
> >This has the effect of changing a routing peer into
> >both a routing and LDP peer.  It also changes LSPs
> >that previously terminated on surrounding routing
> >peers into non-terminating LSPs.
> 
> You're missing the point.
> 
> If the FEC in question corresponds to the LSR advertising the label, then
> it is appropriate to advertise a NULL label.

I personally have no problem with this statement.  However, 
there are some implementers who will feel it is excessively 
restrictive.

While it is true that an LSR should not give out an implicit 
NULL label if it is not the terminating point for an LSP on 
which it may receive either labeled traffic or a mix of labeled 
and unlabeled traffic, there are many scenarios in which an LSR 
will be in a position to know that there are no other labels in 
the stack.  This is the case, for example, if it is currently 
the end point for an LSP on which it is getting IP packets that 
it is then forwarding as IP packets on some other interface.

But this is obvious.  What are you really getting at?

> 
> If the FEC does _not_ correspond to this LSR, then advertising a NULL
> label will cause the LSP to terminate prematurely.  So, if a packet 
> contains a label stack the underlying label will be exposed prematurely, 
> causing it to be interpreted by an LSR other than the one which 
> advertised it.

There is nothing implying the existence of a label stack in
this discussion.  The egress LSR is simply forwarding LSP
packets using IP and subsequently discovers that it could
start forwarding them using MPLS.  If there was a mixture
of IP and MPLS labeled traffic being received on the LSP,
the LSR was already presumably dealing with this.

> 
> With your example, given
> 
>   LSR_A --- LSR_B
> 
> ----LSPx----->
> 
> Where the path for LSPx goes through LSR_B. Turning on LDP in LSR_B does
> not change the LSP from "terminating" to "non-terminating" as far as LSR_A
> is concerned, in either case the next hop for the LSP goes through LSR_B.
> What it changes is whether or not LSR_A has received a valid label from
> the
> next hop. So, LSR_A can always advertise a non-NULL label, but it may
> change the forwarding behavior for that label depending on what it learns
> from LSR_B. It may also change whether LSR_A is the "egress" for LSPx, and
> so may affect whether or not LSR_A even advertises a label at all if in
> Ordered mode, but that is a separate issue from whether or not the
> advertised label should be null.

If you drop the fact that we are discussing DoD behavior
rather than DU behavior, I once had this same discussion 
with one of your colleagues at Cisco only with reversed
roles.  It is certainly arguable that the need to support
PHP is just is great in the DoD case as it is in the DU
case.  What may be a little harder to justify (I think
this was Eric Rosen's point earlier) is whether there is
as much need to support DoD as there is to support DU in 
any case where there is a need to support PHP.

Once you accept the fact that there is a legitimate need
to support PHP, then the restriction that it can only be
used when the LSP is for a FEC corresponding to the LSR
_is_ excessive.

> 
> If the complete corner case we're worrying about is:
> - DoD
> - Ordered
> - LSR_A changes from Egress to non-egress for an LSP
> 
> Then the correct behavior was:
> - advertise a non-null label while egress (because the LSP did not
> terminate)
> - if LSR_B starts to run LDP, meaning LSR_A realizes it is no longer
> egress, then withdraw the label. Presumably the upstream LSR(s) should
> re-request the mapping (see the last sentence in the "Summary" of RFC3036
> A.1.5), in which case the existing state machine applies.
> 
> > > -----Original Message-----
> > > From: Dan Tappan [mailto:tappan@cisco.com]
> > > Sent: Wednesday, September 18, 2002 12:48 PM
> > > To: Jack Brennen
> > > Cc: MPLS (E-mail)
> > > Subject: Re: Clarification on Handling a specific event in LDP
> > >
> > > At 11:56 AM 9/18/2002 -0400, Jack Brennen wrote:
> > > >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.
> > >
> > > 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.
> > >
> > >
> > > >Eric Rosen wrote:
> > > > >
> > > > > 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