Subject: Hierarchical Tunnel Establishment in RSVP-TE

From: Bora Akyol <[email-masked]>
Date: Fri, 9 Jun 2000 11:48:08 -0700

How does one establish hierarchical tunnels using RSVP-TE?
 
I know that the label object can be deeper than one label, but you need more
than this
to establish hierarchical tunnels.
 
Thanks
 
Bora

---

From: Chatur sharp <[email-masked]>
Date: Fri, 9 Jun 2000 12:41:13 -0700 (PDT)

I would also like to know why and if any body would
ever be interested in pushing more than one label 
at a ingress LSR.

C.

> to establish hierarchical tunnels.

=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 11 Jun 2000 01:15:43 -0700 (PDT)

> There are two cases:
> 1. B happens to be the edge of a domain (with the domain definition taken
> from draft-kompella-mpls-optical-00.txt). In this case B knows that it has
> to use a FA-LSP for this LSP request and it can look up the FA-LSP to use
> or create one if it doesn't exist. Hence there is no value to explicitly
> specifying a FA-LSP in the ERO.

That's the plan.

> 2. All the links are in the same domain. In this case if B receives an 
> ERO A, B, E (strict), F do we say that since E is a strict next hop and
> is not adjacent to B, a LSP should be used to send it E ? Apparently there
> is no other way to interpret this case other than sending an error back!
> Furthermore if E is a loose next hop, should B use a LSP to send it to E
> or should it just compute a route and add it to the ERO? It might be 
> nice to have the flexibility to specify the usage of a FA-LSP explicitly
> in such a case. 

Still works.  Domains simplify automatic creation of FA-LSPs; if
the FA-LSP already exists, you can use it by specifying its IP
address.

Kireeti.

---

From: "Punj, Arun" <[email-masked]>
Date: Mon, 12 Jun 2000 14:57:25 -0400

It seems you have slightly misinterpreted the draft.

What it says is that just by looking at the top label you cannot pop two
labels.

However at a given LSR you could pop two labels by first popping one label
and than forwarding it to yourself and than popping another if required.

Where forwarding to yourself really means you continue with parsing of the
label
stack of a packet.

hope it helps

-TL

-----Original Message-----
From: Chatur sharp [mailto:[email-masked]]
Sent: Monday, June 12, 2000 2:37 PM
To: [email-masked]
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE

Hi
I had this doubt after reading 2.1.4.b of
draft-ietf-mpls-label-encaps-07:

[ it has expired, but no replacement yet ???, ditto
for MPLS ARCH document.. ]
[text from draft]
.....

The operation to be performed on the label stack
before 
forwarding; this operation may be to replace the ....
....
....

From this paragraph it would seem that the list of
operations allowed is:

1. Swap
2. Pop
3. Replace the top label with one or more additional
   entries on the stack. 

Does that mean that two pops cannot be performed ?
Surely this cannot be the case. Right ?

thanks
C.

--- "James R. Leu" <[email-masked]> wrote:
> On Mon, Jun 12, 2000 at 01:19:01PM -0400, Dimitry
> Haskin wrote:
> > Curtis,
> > 
> > If I read you correctly, you're implying that both
> labeled and unlabeled IP
> > packets are encapsulated into the outer tunnel,
> i.e. the RSVP control
> > traffic is sent with a single MPLS header of outer
> tunnel. Is it correct? If
> > so, this is fine except that, as far as I know,
> some MPLS vendors (note that
> > it does not apply to the equipment I am most
> familiar with ;) would not be
> 
> See draft-ietf-mpls-arch-06.txt
> 
> 3.10. The Next Hop Label Forwarding Entry (NHLFE)
>    ...
>    Note that at a given LSR, the packet's "next hop"
> might be that LSR
>    itself.  In this case, the LSR would need to pop
> the top level label,
>    and then "forward" the resulting packet to
> itself.  It would then
>    make another forwarding decision, based on what
> remains after the
>    label stacked is popped.  This may still be a
> labeled packet, or it
>    may be the native IP packet.
> 
>    This implies that in some cases the LSR may need
> to operate on the IP
>    header in order to forward the packet.
>    ...
> 
> > able to handle this in their fast path. To support
> labeled and plain IP
> > packets in the same tunnel would require the fast
> path decision based on the
> > state of S-bit of the outer header which is
> problematic with some equipment.
> > In addition, I've heard that one particular vendor
> would not be able to
> > terminate MPLS tunnels unless it arrives with a
> Null IP label.
> 
> It seems the arch draft allows it, is this the same
> way others have interpreted
> this?
> 
> Jim
> -- 
> James R. Leu

=====

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Jun 2000 12:48:31 -0700

Hi,

What is an IP Null Label?

-Shahram

>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Monday, June 12, 2000 10:57 AM
>To: Tony Li
>Cc: Bora Akyol; [email-masked]'
>In message <[email-masked]>, 
>Tony Li writes:
>> 
>> 
>>  | How does one establish hierarchical tunnels using RSVP-TE?
>>  |  
>>  | I know that the label object can be deeper than one 
>label, but you need mo
>> re
>>  | than this to establish hierarchical tunnels.
>> 
>> 
>> A hierarchical tunnel requires the participation of at least 
>two LSRs.  The
>> operation of the LSR creating the innermost tunnel is 
>straightforward and
>> is unchanged from what has been endlessly discussed here.
>> 
>> For an LSR to create an outer tunnel, it simply creates 
>another tunnel and
>> specifies MPLS as the L3PID.  It then forwards packets 
>received on the
>> inner tunnel by pushing a label for the outer tunnel.  The 
>RSVP control
>> traffic for the inner tunnel is also forwarded through the 
>outer tunnel
>> after first being encapsulated with a null IP label.
>> 
>> Recurse, ad nauseum.
>> 
>> Simple, really.  ;-)
>> 
>> Tony
>
>
>Tony,
>
>Two minor points.  
>
>If the outer tunnel is constrained (by configuration) to accept only
>inner tunnels with one L3PID, then that L3PID can be placed on the
>outer tunnel.  If there are optimization possible for a particular
>L3PID (IP src/dst hash to split loading along the way comes to mind
>for IPv4) then putting the inner L3PID on the outer tunnel has
>advantages.
>
>No where have I seen a requirement to put a null label on traffic
>destined to the egress LSR.  I had been assuming that if the IP packet
>under the top label has the address of the router ID of the egress
>under the outer label, then the packet would be delivered to the
>egress.  If the egress required PHP, then the penultimate LSR would
>put a null label on the control traffic for the the inner label and
>the egress would POP the null label and see its own IP address.
>Otherwise, the egress would see two null labels.
>
>If I'm missing something and/or there will be any interoperability
>problem with the way I intended to encapsulate control traffic inside
>the outer label, please tell us about it.
>
>Curtis
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Jun 2000 12:51:01 -0700

Sorry,

Did you mean IPV4 or IPV6 Explicit Null Labels?

-Shahram

>From: Shahram Davari 
>Sent: Monday, June 12, 2000 3:49 PM
>To: [email-masked]'; Tony Li
>Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>Hi,
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Jun 2000 13:16:17 -0700

Dimitry,

>From: Dimitry Haskin [mailto:[email-masked]]
>Sent: Monday, June 12, 2000 1:19 PM
>To: [email-masked]; Tony Li
>If I read you correctly, you're implying that both labeled and 
>unlabeled IP
>packets are encapsulated into the outer tunnel, i.e. the RSVP control
>traffic is sent with a single MPLS header of outer tunnel. Is 
>it correct? If
>so, this is fine except that, as far as I know, some MPLS 
>vendors (note that
>it does not apply to the equipment I am most familiar with ;) 
>would not be
>able to handle this in their fast path. To support labeled and plain IP
>packets in the same tunnel would require the fast path 
>decision based on the
>state of S-bit of the outer header which is problematic with 
>some equipment.

Why is the state of the S-bit important in supporting non-labled ingress
packets?

-Shahram

>In addition, I've heard that one particular vendor would not be able to
>terminate MPLS tunnels unless it arrives with a Null IP label.
>
>Dimitry 
>
>> Tony Li writes:
>> > 
>> > 
>> > A hierarchical tunnel requires the participation of at 
>> least two LSRs.  The

---

From: "Punj, Arun" <[email-masked]>
Date: Mon, 12 Jun 2000 16:58:40 -0400

Hi,

I guess the reference is to MPLS label value 0 or 2 or 3, 
as mentioned in draft-ietf-mpls-label-encaps-07

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Monday, June 12, 2000 3:49 PM
To: [email-masked]'; Tony Li
Cc: Bora Akyol; [email-masked]'
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 

Hi,

-Shahram

---

From: Chatur sharp <[email-masked]>
Date: Mon, 12 Jun 2000 14:08:12 -0700 (PDT)

On the face of it what you say seems to be correct.

Could it be that draft should be interpreted as:

"As that there should be no more labels below a NULL
label. However, labels could be applied on top
of a NULL label. "

--- Shahram Davari <[email-masked]>
wrote:
> Toni,
> 
> The Encaps-draft says that the IPV4/6 Explicit Null
> Labels are only legal if
> they are the sole label stack entry. However, in
> your example the RSVP
> messages will have two labels, the outer label and
> the IPV4/6 Explicit Null
> Label. Isn't this a violation of the Encaps-draft
> requirement?
> 
> Regards,
> -Shahram
> 
> >From: Tony Li [mailto:[email-masked]]
> >Sent: Monday, June 12, 2000 1:22 PM
> >To: [email-masked]
> >Cc: Tony Li; Bora Akyol; [email-masked]'
> > | If the outer tunnel is constrained (by
> configuration) to accept only
> > | inner tunnels with one L3PID, then that L3PID
> can be placed on the
> > | outer tunnel.  If there are optimization
> possible for a particular
> > | L3PID (IP src/dst hash to split loading along
> the way comes to mind
> > | for IPv4) then putting the inner L3PID on the
> outer tunnel has
> > | advantages.
> >
> >
> >I agree that this is also possible for
> implementations that 
> >want to parse
> >up the label stack.
> >
> >
> > | No where have I seen a requirement to put a null
> label on traffic
> > | destined to the egress LSR.
> >
> >
> >The requirement exists if you take the more general
> approach 
> >of specifying
> >an outer L3PID of MPLS and then wish to tunnel
> (otherwise 
> >unlabeled) RSVP.
> >Under the approach that you've proposed, this would
> not be necessary.
> >
> >Tony
> >
> 

=====

---

From: Shahram Davari <[email-masked]>
Date: Mon, 12 Jun 2000 15:12:51 -0700

Hi Tony,

Since an S-bit=0 indicates that the encapsulated packet is an MPLS packet,
can't we conclude that L3PID is used only for the identification of L3? In
other words it is possible to tunnel both labeled and unlabeled packets
through the same MPLS tunnel (i.e., with the same outer label)?

If this is true then you don't need to set the L3PID=MPLS for the outer
tunnel. Instead you can set the L3PID=IP and use the same tunnel for the
tunneled MPLS packets as well as tunneled RSVP messages. 

Regards,
-Shahram 

>Sent: Saturday, June 10, 2000 1:25 AM
>To: Bora Akyol
>Cc: [email-masked]'
>Subject: Hierarchical Tunnel Establishment in RSVP-TE
>
>
>
>
> | I know that the label object can be deeper than one label, 
>but you need more
>specifies MPLS as the L3PID.  It then forwards packets received on the
>inner tunnel by pushing a label for the outer tunnel.  The RSVP control
>traffic for the inner tunnel is also forwarded through the outer tunnel

---

From: [email-masked]
Date: Tue, 13 Jun 2000 10:44:04 +0100

Observation/plea:

I am getting increasingly concerned that we have an MPLS trail object, ie an
LSP, but that the trail termination points (either source or sink) seem to
be a movable feast depending on (i) different people's interpetation of the
IDs produced to date, and/or (ii) the functional behaviour that is being
considered.  Can I therefore make the plea that if a further informational
ID is produced to clarify these matters (which Bora orginally suggested)
that we make sure that there is architectural consistency across all
functional behaviour wrt to where the trail termination points are.

Regards, Neil

> From:	Kireeti Kompella [SMTP:[email-masked]]
> Sent:	Tuesday, June 13, 2000 7:59 AM
> To:	[email-masked]
> Cc:	[email-masked]
> > Two POPs are needed to terminate a VPN tunnel.
> 
> Not if you use PHP.  You start popping one hop earlier, e.g., if
> X is the PE attached to the customer, and Y the penultimate hop,
> Y pops the "outer label" and forwards the packet with the "inner
> label" identifying the VPN to X.  X looks at the inner (only!)
> label, pops it and knows which customer to forward the packet to.
> 
> Corner case: a one-hop LSP carrying VPN info: don't put any "outer
> label" in this case.
> 
> > Three might be needed
> > if the outer tunnel on the VPN took its last hop through a FA-PSC.
> 
> Picture time:
> 
>     A ---- B ==== C ==== D ==== E ~~~~ customer
>             <-43-  <-28-  <--3-
>     <--71-- <-------- 3 -------
> 
>     <-- 32 for VPN to customer --
> 
> There's an FA-LSP from B to E.  E sends D an implicit NULL label,
> D sends C label 28, C sends B 43.
> 
> Now, there's another LSP that wants to tunnel through the above
> FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
> B sends A label 71.
> 
> A and E agree on label 32 for the VPN.
> 
> The label stack for a packet to the customer is as follows:
> 
>     A ---- B ==== C ==== D ==== E ~~~~ customer
>               43     28
>        71
>        32     32     32     32
> 
> Note that 71 -> 43 is not really a swap as much as a pop (PHP),
> followed by a push (equivalent, but you get there differently).
> 
> It is interesting to first work out the case where the tunneled
> LSP terminates beyond the tail of the FA-LSP, as the above example
> is another 'corner case'.
> 
> Kireeti.

---

From: Chatur sharp <[email-masked]>
Date: Tue, 13 Jun 2000 06:04:07 -0700 (PDT)

Shahram,
So what is the interpretation for the draft. 

"That you can apply NULL label only iff it is
the only label present in the label stack. "

Tony could we have clarification from you on 
the draft.

C.

wrote:
> Chatur,
> 
> I don't think so. Since in case of label= 1, the
> draft says:
> 
> "A value of 1 represents the "Router Alert Label". 
> This label value is
> legal anywhere in the label stack except at the
> bottom."
> 
> So in case of Label=2,4 they could have written:
> "nowhere except at the
> bottom". 
> 
> -Shahram
> 
> >Sent: Monday, June 12, 2000 5:08 PM
> >To: Shahram Davari
> >> >Subject: Re: Hierarchical Tunnel Establishment
> in
> >> RSVP-TE 
> >> >
> >> >
> >> >
> >> >Curtis,
> >> >

=====

---

From: Eric Gray <[email-masked]>
Date: Tue, 13 Jun 2000 12:01:41 -0700

Eric,

	See below.

You wrote (in part): 
> 
> My proposal is to replace the requirement that explicit nulls 
> only appear as the sole label on the stack with the requirement 
> that they only appear at the bottom of the stack. 
> 
> This doesn't change the fact that the S bit needs to be on 
> when these labels appear. 

Aha.  I guess I'm guilty of reading this meaning
into the existing text, since labels do not "appear"
until higher level labels are removed.  However, I
agree on re-reading the text that the current words
are just wrong.

The words -

   "This label value is only legal when it is the 
    sole label stack entry." 

- should be changed to something like -

   "This label value is only legal when it is at 
    the bottom of the label stack."

 - in both Explicit NULL labels.

> 
> We used well-known values so that an implementation wouldn't 
> have to look up the label in its database of allocated label 
> entries, only to find that it then needs to look up an IP 
> destination  address.  Checking a label value against a 
> couple of well known values is  much simpler than doing a 
> table lookup. 

No, duh.  :-)

My point is that the actual values may be chosen
by the implementation.  The fact that the specific
value of '0' or '2' is assigned to an upstream LSR
peer for a particular FEC has no more information
content than the fact that the hop count in the
message is '1'.  The upstream LSR simply stores
this label just like any other label and uses it
the same way, too.  Hence the value chosen by an
implementation could just as easily have been the
lucky-lotto numbers of the lead system designer.

Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Tue, 13 Jun 2000 13:25:03 -0700

Yakov,

	Good idea!  Now who bells the cat?

--
Eric Gray

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Tuesday, June 13, 2000 12:29 PM
> To: [email-masked]
> Folks,
> Given the recent e-mail exchange on the topic of hierarchical
> tunnel establishment in RSVP-TE, and given that most (but probably
> not all) the relevant material is covered under the notion of
> Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> I wonder whether there would be any objections agains extracting
> all the relevant material, filling the missing pieces (if any),
> and turning the result into a MPLS WG document. 
> 
> Yakov.
>

---

From: Helpdesk MIS <[email-masked]>
Date: Wed, 14 Jun 2000 11:29:43 -0400

From: James R. Leu

On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:
<snip>

> I makes sense for the inner labels to be per platform because the
> outer label can be rerouted and end up coming in on another interface.
> If that reroute occurs cleanly (make before break), it should not be
> nessecary to reroute the inner labels.
> 
> Curtis

Are your saying that an ILM will have labels from multiple labelspaces?
That would require the label manager to do co-ordination of every label
allocation.

Or, are you saying that you have a special outer label which points to a new
ILM for all future lookups?  Depending how you implement this it will break
the
proccesing when it is "IPv4 or label" under the top label.
(plus I don't think hardware implementors will like this approach)

Jim
-- 
James R. Leu

---

From: Helpdesk MIS <[email-masked]>
Date: Wed, 14 Jun 2000 11:30:22 -0400

From: James R. Leu

Jim
-- 
James R. Leu

---

From: Helpdesk MIS <[email-masked]>
Date: Wed, 14 Jun 2000 11:34:15 -0400

From: Curtis Villamizar

In message <[email-masked]>,
"Abes
, Andi" writes:
> Curtis,
> 
> The PHP options brings up a question that I've asked a 
> long time ago, but went un-answered:
> Are "inner" labels restricted to be from the "platform"
> label pool ?
> Are there implementations that use "per-interface" label 
> pools to allocate inner labels ?
> 
> It is concivable that an implementation will choose to
> define an LSP (or set of them) as an interface. And, on
> top of this interface manage a "per-interface" label pool.
> This can help simplify routing for example.
> 
> If this is allowed, then the PHP solution will break, since
> only the outer label identifys the incomming "interface".
> 
> Andi.

Curtis

---

From: Eric Gray <[email-masked]>
Date: Tue, 20 Jun 2000 09:47:09 -0700

Ganesh,

	It's at

http://www.ietf.org/internet-drafts/draft-kompella-lsp-hierarchy-00.txt

--
Eric Gray

> From: Ganesh Murugesan [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2000 9:00 AM
> To: Yakov Rekhter; [email-masked]
> Cc: [email-masked]
> Can you forward me a copy of this draft.
> 
> thanks
> ganesh
> 
> 
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> > Rekhter
> > Sent: Friday, June 16, 2000 4:16 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Kireeti and myself just submitted an Internet Draft on this.
> > If you can't wait until the Draft will appear in the IETF
> > server, drop me an e-mail and I'll send you a copy.
> > 
> > Yakov.
> > 
>