The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Shahram,

    Not too many months ago, I had an off-line discussion
with someone about this kind of problem.  The conclusion
arrived at was that we have two different perspectives:

A) Pragmatism and the reality of implementation complexity;
B) Protocol Purity or the end of the world as we know it.

At the risk of exposing my position in the discussion, I have
to say that the behavior you describe is allowed and - thus
- it cannot be much of a surprise that it will happen.  But I
feel that it is not healthy behavior - and may be pathological.
There are lots of reasons why an implementation may assign
special significance to packets received with a label - even
the explicit null label.  In fact, it is possible that a system
might assign the explicit null label specifically to differentiate
some packets from IP packets (possibly received as a result
of an implicit null assignment).

    A chance meeting between an implementation that assigns
specific significance to the explicit null label (believing that
the explicit null label will only be used in the cases where it
has been assigned) and another implementation that always
uses the explicit null label except when it has a legitimate
label alternative is likely to produce surprises for both sets
of implementers.  In protocol implementation and deployment,
surprises are seldom good.

--
Eric Gray

You wrote:

> Hi Eric,
>
> Thanks for your nice explanation. I also am not advocating
> such as behavior, it is just that somebody in IETF told me
> that they are doing this, and I just wanted to see whether
> this is the current practice.
>
> The logic as you said is that if an LSR (not LER) for reasons
> can't accept unlabeled packets, then using explicit null label
> could be a solution, although at each hop a extra push and pop
> would be needed.
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: Eric Gray [mailto:eric.gray@sandburst.com]
> > Sent: Monday, March 26, 2001 4:52 PM
> > To: Anoop Ghanwani
> > Cc: Shahram Davari; MPLS Mailing List
> > Subject: Re: Explicit null label ?
> >
> >
> > Anoop,
> >
> >     There are two cases.  The first is when LSP signaling
> > is used hierarchically (in which case, the explicit null may
> > be used by the penultimate hop for the LSP being used).
> > It would only be used at the last hop of an LSP hierarchy.
> > This does not appear to be the case that Shahram is asking
> > about.  The other is illustrated below.
> >
> >     You have these two implementations - call them Butch
> > Cassidy and Sundance Kid.  Both are technically LSRs,
> > but Butch Cassidy signals the implicit null whenever it can
> > (possibly because it doesn't have a clue what to do with a
> > real label) and the explicit null in ALL other cases - while
> > Sundance Kid can't send anything but labeled packets.
> >
> >     Since the explicit null label is well defined in RFC 3032,
> > there's theoretically no reason why Sundance Kid cannot
> > use explicit null labeled packets to talk to Butch Cassidy.
> >
> >     Understand that I am not advocating this behavior.  In fact
> > far from it.  I think Butch Cassidy and Sundance Kid should
> > be shot.  But, that is another story...
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > Is there any reason why would you even consider the second
> > > option?
> > >
> > > -Anoop
> > >
> > > > -----Original Message-----
> > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > > > Sent: Monday, March 26, 2001 11:43 AM
> > > > To: 'mpls@uu.net'
> > > > Subject: Explicit null label ?
> > > > Importance: Low
> > > >
> > > >
> > > > Hi All,
> > > >
> > > > In an MPLS network that supports TE, the constraint-based
> > > > routing is done via CR-LDP or RSVP-TE signaling. My question
> > > > is which one of the following methods have people adapted or
> > > > is envisioned to be superior:
> > > >
> > > > 1) CR-LDP/RSV-TE signaling be done using unlabeled IP packets.
> > > > 2) CR-LDP/RSVP-TE signaling be done using MPLS labeled packet
> > > > with label=0 (explicit null label).
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Shahram Davari
> > > > Systems Engineer
> > > > Product Research Group
> > > > PMC-Sierra, Inc. (Ottawa)
> > > > Phone: (613) 271-4018
> > > > Fax:    (613) 271-7007
> > > >  <<Shahram Davari.vcf>>
> > > >
> >