Subject: RE: Label Spaces and Uniqueness

From: Shahram Davari <[email-masked]>
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
>

---

From: "Sherry Wei" <[email-masked]>
Date: Tue, 10 Jul 2001 15:26:15

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,
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Tue, 10 Jul 2001 14:31:39 -0400

> >>>
> >>>         B-----C--------E-------F
> >>> A-------B----------------------F-------G
> >>>
> >>> LSP1: ABFG
> >>> LSP2: BCEF
> >>
> >> 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.)
> > 
> >    Why not? As long as I use labels from different label space.
> >    And I think this is a very importance feature in Fast-Reroute
> >    in LSP protection.
> > 
> >    LSP1: ABFG uses labels from global label space, so, even
> >    after reroute of LSP2 (because of some failure) F receives
> >    data in that on a different interface and can interpret
> >    data correctly because the inner label is from global
> >    label space.
> > 
> >    LSP2: BCEF uses per interface label space. As far as I know
> >    both of these label spaces can coincide and more over
> >    F can allocate the "same" local significance label to B as
> >    well as to E. (as long as it distinguishes which LSP the
> >    data is flowing)
> > 
> >    Is this possible. If not why not?
> 
> When the labeled packet arrives, how will you be able to 
> determine which
> label space to use?  This isn't part of any header.  All 

  A packet from B traversing LSP1 cannot arrive at F natively since they 
  are remote peers. It has to arrive encapsulated and it so happens here 
  that encapsulation is the outer label (of LSP2). So, in this scenario, 
  the outermost label cannot have the same context as the one used for
  distributing label to B by F and its safe to assume that the only context 
  outer-most label has is the one used for distributing label to E by F.

> you've got is a
> label stack and the opaque payload.
> 
> If you can determine the label space, then sure, go right 
> ahead.  But I
> think the only factors that you can use are either layer-2 information
> or physical port information.

  Or the fact that the router (F here) has already looked at the outer
  label (which defines a tunneled interface in a sense) and so its
  time to switch the label space to one which was used while distributing
  label to B for this tunneled interface. In short, treat outermost label 
  as a tunneled interface (layer 2.5 !!).

  - Ravi Shekhar.

---

From: Anouk Rocher <[email-masked]>
Date: Tue, 10 Jul 2001 18:12:39 -0400

Minor point in line Don.

---- On Tue, 10 Jul 2001, Don Fedyk ([email-masked]) wrote:

> Hi
> 
> So what I think I heard is either:
> 
> Standard says: All labels from the same space. No problems.
> 
> But in practice I thought VPNs used:
> 
> Assume per/interface outer labels, the next inner stacked label 
> from per node space. PHP to be avoided adjacent to boxes doing this.

As per my understanding, VPNs need not use per interface labels for
the outer label. Per Platform labels for this should work equally well.

Or was there a point in there that I missed?

> 
> In the end it is a local decision of the box. No other box 
> cares what algorithm the allocating box is using. 
> 
> So should the standard be updated?
> 
> Don

Anouk.

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 10 Jul 2001 18:37:03 -0400

> Subject: Re: RE: Label Spaces and Uniqueness
> 
> Minor point in line Don.
> 

Actually there is a subtlety that I skimmed over. There is a difference
between requirements on labels for forwarding and allocation. Much of the
discussion 
for the label space has been motivated by forwarding. This is the first
point, 
all labels from per platform space works from a forwarding paradigm.
However, 
in some instances people are looking at per interface label space on the
outer 
labels to allow more freedom in allocating (inner) VPN labels. You can 
reallocate ranges with more freedom for example. Then this has implications
on forwarding.

Don

---

From: Hummel Heinrich <[email-masked]>
Date: Fri, 13 Jul 2001 16:45:59 +0200

1)For some while I also thought about separate label spaces, but not one space per hierarchy level (there are no well-defined
hierarchical levels and at least for now I don't think they are needed). Instead, I thought about  one label space which is
owned by the respective tunnel edge router, and another which is owned by a different entity like a domain-related server.
However meanwhile   I  think none of these label spaces are required. 

2) I don't like penultimate label popping. The gain is not worth the trouble to deal with two alternatives.
However, though mostly  penultimate label popping looks like a borne trouble-maker there will be solutions that will
bypass the problem, like solutions which do not depend on hierarchical label spaces. 

Heinrich 

-----Ursprüngliche Nachricht-----
Von: Karthik Muthukrishnan [mailto:[email-masked]]
Gesendet: Freitag, 13. Juli 2001 16:16
An: [email-masked]
Cc: [email-masked]; chandrasekar kathirvelu; Andy Malis
Betreff: Re: Label Spaces and Uniqueness

Anouk:

I agree with your concerns.. These concerns are the basis of the draft: 

http://search.ietf.org/internet-drafts/draft-kathirvelu-hiervpn-corevpn-00.txt.

A complication is that with penultimate hop popping, every two consecutive labels starting with the first one have to be from the same space. For example, <L1, L2, L3, L4> are the labels with L1 being
the highest on the stack. L1 and L2 are from the same space [say space1] and L3 and L4 are from the same space [say space2] where space1 and space 2 may or not be equal. The choice of whether space1
and space2 are the same and the action when L2 is popped off is left to the implementation; in other words, no wordsmithing in the standard docs is necessary..

-karthik

Anouk Rocher wrote:
>    having a different label space for different levels of the hierarchy;
> allocate labels from a single label space? Isn't this a bit too
> at different levels of the label-stack to be from different label spaces.
> 
> Comments?
> 
> Anouk
>