Subject: RE: Label Spaces and Uniqueness

From: Shahram Davari <[email-masked]>
Date: Tue, 10 Jul 2001 08:55:06 -0700

Hi Sherry,

You are partially right. Only when those labels are distributed by the same LSR must be unique across different levels. For example assume this architecture:

        B-----C--------E-------F 
A-------B----------------------F-------G

LSP1: ABFG
LSP2: BCEF

Assume LSR F distributes label L1 to B for LSP1, and label L2 to E for LSP2.
Since LSR E has is not allowed and does not need to look at the lower label
belonging to LSP1, it can distribute an identical label L1 to C for LSP2. So in
the cross section from C->E the packet may have 2 labels both being L1.

I think Eric Gray is right, and probably RFC-3031 should say: 

"In an LSR (rather than MPLS), there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant."

Yours,
-Shahram

> -----Original Message-----
> From: Sherry Wei [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 11:26 AM
> To: Shahram Davari
> Cc: [email-masked]
> Subject: RE: Label Spaces and Uniqueness
> 
> 
> Hi,
> 
> If the same label value exsists in different levels of the 
> label stack, will 
> it cause a loop? For example, the up most label value is 20 
> and the second 
> up most label value is also 20. In the ILM table, this label 
> value indicates 
> the according operation is "pop and lookup"... I think the 
> same label value 
> in different levels of the stack should have different meaning.
> 
> Please correct me if I am not right.
> 
> Sherry
> 
> 
> >From: Shahram Davari <[email-masked]>
> >To: "[email-masked]'" <[email-masked]>, [email-masked]
> >Subject: RE: Label Spaces and Uniqueness
> >Date: Tue, 10 Jul 2001 07:12:27 -0700
> >
> >Hi,
> >
> > > -----Original Message-----
> > > From: Anouk Rocher [mailto:[email-masked]]
> > > Sent: Monday, July 09, 2001 8:46 PM
> > > To: [email-masked]
> > > Subject: Label Spaces and Uniqueness
> > >
> > >
> > > Eric, Arun, Ross
> > >
> > > RFC 3031 in section 3.14 says (in the penultimate paragraph)
> > >
> > >   "In MPLS, there is no notion of
> > >    having a different label space for different levels of the
> > > hierarchy;
> > >    when interpreting a label, the level of the label is 
> irrelevant."
> > >
> > > Does this mean that while doing label stacking, it is 
> neccessary to
> > > allocate labels from a single label space?
> >
> >Yes.
> >
> >  Isn't this a bit too
> > > restrictive for the cases where the inner label represents
> > > customer traffic transiting a provider and the outer 
> label represents
> > > a path through the provider?
> >
> >No. This rule must be followed. The reason is that an LSR 
> has no way of
> >knowing which level of hierarchy a label belongs to.
> >
> > >
> > > In other ways, I think it is appropriate in some 
> situations for labels
> > > at different levels of the label-stack to be from different
> > > label spaces.
> >
> >NO. This is not right. The only time that you may find 
> exactly same labels
> >in different layers of hierarchy is when those labels are 
> distributed by 
> >two
> >different LSRs. This may happen when you have a label stack 
> of more than 2 
> >labels.
> >
> >-Shahram
> >
> > >
> > > Comments?
> > >
> > > Anouk
> > >
> > > ________________________________________________
> > > Get your own "800" number
> > > Voicemail, fax, email, and a lot more
> > > http://www.ureach.com/reg/tag
> > >
> >
> 
> ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com.

---

From: David Charlap <[email-masked]>
Date: Tue, 10 Jul 2001 12:26:42 -0400

Shahram Davari wrote:
> 
> You are partially right. Only when those labels are distributed by
> the same LSR must be unique across different levels. For example
> assume this architecture:
> 
> 
>         B-----C--------E-------F
> Assume LSR F distributes label L1 to B for LSP1, and label L2 to E
> for LSP2.  Since LSR E has is not allowed and does not need to look
> at the lower label belonging to LSP1, it can distribute an identical
> label L1 to C for LSP2. So in the cross section from C->E the packet
> may have 2 labels both being L1.

No argument here.  But I dont't think this is the really important
issue.  It is obvious that E might send a label mapping identical to
what's used in the outer LSP.  After all, E has no knowledge of that
outer LSP.  It would be unreasonable to expect a router to remain in
sync with routers that it is not sharing signaling information with.

A more important question is what happens at router F.

Router F must not send the same label to E and to B.  When a packet
arrives from E, the outer label will indicate a pop.  Then the remaining
label will indicate a swap.  (Let's pretend there are more routers
beyond G, so PHP won't come into play here.)

If the two labels are identical, then the forwarding engine in F won't
be able to apply different semantics to them.  It should not use the
size of the label stack as a way of differentiating, because the outer
label (sent from F to E) may appear without a stack underneath it.  (eg.
for traffic that originates from B and terminates at F).

This is what the RFC is talking about.  The only way for F to determine
whether a packet is from LSP1 or LSP2 is using the label.  If the label
values for the two are identical, then some other means, beyond the
scope of MPLS, must be used to determine the LSP that the packet belongs
to.  The easiest way to ensure that the same label is not used for the
two LSPs is to use the same label space for the two.

-- David

---

From: Eric Gray <[email-masked]>
Date: Tue, 10 Jul 2001 13:35:58 -0400

David,

    The current wording in RFC 3031 implies more than that you shouldn't
give the same label out to two different peers (with distinct semantics)
when you will be popping the top label off.  The current wording means
you shouldn't give the same label out with two different meanings where
one applies to packets received with a pop-and-look-again upper label
and the other applies when it is received as the first label.

    This latter implication is a little too restrictive - especially in light of

subsequent work on LSP tunnels and forwarding adjacencies.  However,
it may have been meant to provide correct LSR behavior in a particularly
pathological case.  That case would be when a PHop LSR (far from being
cooperative in the usual PHP way) actually maliciously inserts an extra
label in forwarding a labeled packet to the NHop LSR.  It would happen
like this:

    PHop swaps an existing label for the label given by the downstream
        LSR for the LSP in question,
    PHop pushes on a label for an LSP that terminates at NHop and
    PHop forwards the now stacked labeled packet to the NHop LSR.

This is pathological because the PHop LSR is inserting a label that does
not add value and does add work for NHop.  Moreover, this behavior will
make it impossible for NHop to distinguish locally distributed labels from
remotely distributed labels.  But this behavior is also obviously malicious
and should result in an implementer being placed in Coventry for a very
long time (at least until overcome by bankruptcy).

    Barring this bizarre behavior, it will always be possible to distinguish
remotely distributed labels received on a non-PHP LSP from locally
distributed labels.  Even with this bizarre behavior, it is possible to
distinguish labels received on LSP tunnels from labels received in the
raw or on a plain LSP.

--
Eric Gray

---

From: Matt Squire <[email-masked]>
Date: Tue, 10 Jul 2001 13:53:49 -0400

> two LSPs is to use the same label space for the two.

But there are many potential ways for F to distinguish the context of a
packet and hence the label space.  It could look at the port or VC or, as
Eric mentioned, it can view an LSP as a port and have a label space for that
port/LSP.

When a packet arrives the LSR has to determine the context, ie label space,
and view the packet in that context.  As long as the LSR can do that, it can
have any insane internal label assignment methodolgy that it wants.  There
are oodles of possibilities, most of them impractical but interoperable.

I agree with the original text that says the level is not important.  Its
not important, at least not directly.  However, as pointed out by Eric's
earlier note, it could have indirect importance by reflecting a different
context in which to interpret the label.

- Matt

---

From: David Charlap <[email-masked]>
Date: Tue, 10 Jul 2001 14:09:12 -0400

Matt Squire wrote:
> 
> But there are many potential ways for F to distinguish the context
> of a packet and hence the label space.  It could look at the port or
> VC or, as Eric mentioned, it can view an LSP as a port and have a
> label space for that port/LSP.

Port?  If you mean physical interface, yes.  It's always possible to
determine label space based on that.  If you're talking about TCP/UDP
port, then no - an MPLS forwarder should not use the payload as the
basis for any forwarding decisions.

VC?  With most MPLS-over-ATM implementations, the VC is the top label.

If you are talking about Juniper's implementation - using shim headers
to multiplex all LSPs into a single VC, then there's no issue.  Each VC
is equivalent to a separate physical interface.

As for the LSP, you've just created a circular definition.  The LSP is
determined by the label.  But you also want to compute the meaning of
that label from the LSP.

> When a packet arrives the LSR has to determine the context, ie label
> space, and view the packet in that context.  As long as the LSR can
> do that, it can have any insane internal label assignment methodolgy
> that it wants.  There are oodles of possibilities, most of them
> impractical but interoperable.

Sure.  But aside from physical port information or L2 information, the
only other way to determine the LSP is by looking at the top label.

-- David

---

From: Eric Gray <[email-masked]>
Date: Tue, 10 Jul 2001 14:43:46 -0400

David,

    Welcome back to the continuing saga of 'word wars'.

    Matt almost certainly was talking about 'logical port' and the
word 'VC' has meaning outside of ATM.  The point is that it is
possible to treat each layer of 'encapsulation' that is removed
at a network device as establishing a logical context for use in
interpreting the next layer of 'encapsulation'.  'Encapsulation'
can easily be seen to apply to each layer of an MPLS stack that
is removed at a single network device.  In this sense, I know of
no real-world physical reason why the same thing you say about
the physical interface would not also apply to logical interfaces -
particularly since, by the time you get to it, a packet processing
device may be completely unable to distinguish the two concepts.

--
Eric Gray

---

From: Matt Squire <[email-masked]>
Date: Tue, 10 Jul 2001 18:24:36 -0400

> > VC?  With most MPLS-over-ATM implementations, the VC is the top label.

I mean logical interface.  People create logical interfaces over
physical interfaces in oodles of ways (ATM VC, VLAN/Ethernet, FR, GRE,
PPP, ...).  An LSP provides another way of partitioning a physical
interface into multiple logical ports/channels/thingies.  

> > determined by the label.  But you also want to compute the meaning of

Actually I'm talking about a stacked implementation.  Its clear that one
could treat an LSP, from a certain perspective, as you would any
physical port (ie ethernet/mpls, run spanning tree, etc.).  You could
then just treat that LSP as a port over which you run LDP/RSVPTE/BGP/...
Its clear that the label space of in that context can be implemented in
such a way that they are independent of other label spaces on the box. 
Its just label stacking. 

> > only other way to determine the LSP is by looking at the top label.

I am in vehement agreement that there's no need to change the doc. 
Arguments for or against the correctness could be made either way.  As
long as I can interpret the labels I distribute, I'm free to do it in
any way I want using as many label spaces as I wish.

I shall now shut up on the subject forever as its not worth arguing
over.  If I comment on it again, feel free to pull me aside and beat me
with a stick.

No, I mean it.  A big stick. 

- Matt