Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE

From: Eric Gray <[email-masked]>
Date: Mon, 12 Jun 2000 16:10:04 -0700

Shahram/Tony,

	I think we may be glossing over some of the
complexities in this discussion.

	In the diagram given earlier:

A -- B -.           .- E -- F   
         `- C -- D -'             

We want to create an outer tunnel from B to E to
transport MPLS labeled packets in the inner tunnel
from A to F.  Two sets of RSVP-TE messages would be
required: those going from A to F (the inner tunnel) 
and those going from B to E (the outer tunnel).  The
RSVP-TE messages associated with the inner tunnel 
would be transported using the labels associated with
the outer tunnel in going from B to E. The RSVP-TE
messages associated with the outer tunnel would be
either transported using raw IP or using LSP(s) with
E (and B) as LSP destinations - in other words, yet
another set of LSPs.

	For RSVP-TE messages being used to support the
inner tunnel, Shahram is correct - no special label
is needed by E.  This is because E is the egress for
the outer tunnel and either D will pop the label for
the outer tunnel, or E will.  Whether D is asked to
do a PHP for the outer tunnel or not depends on the
capabilities of D as an LSR/LER.  Whether or not an
explicit NULL label is required by E depends on the
capabilities of E.  For example, for some traffic 
going through the outer tunnel, E may choose to ask
B to do a PHP for an inner tunnel (yet another one)
that - for instance - goes from A to E.  This would
also produce IP encapsulated packets inside the outer
tunnel LSP.  If LSR D is doing PHP for the outer 
tunnel, it must be able to distinguish when it is 
popping the last label and when it is not so that it 
will produce the correct L2 encapsulation for the 
link from D to E.  Once it has done this, then E will 
be able to demux labeled and unlabeled traffic 
received from D.

	Both simpler and more complex than discussion
seemed to make it out to be...

--
Eric Gray

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Monday, June 12, 2000 3:13 PM
> To: 'Tony Li'; Bora Akyol
> Cc: [email-masked]'
> Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
> 
> 
> 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 
> 
> >-----Original Message-----
> >From: Tony Li [mailto:[email-masked]]
> >Sent: Saturday, June 10, 2000 1:25 AM
> >To: Bora Akyol
> >Cc: [email-masked]'
> >Subject: Hierarchical Tunnel Establishment in RSVP-TE
> >
> >
> >
> >
> > | 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.
> >
> >
> >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
> >
>

---

From: Bora Akyol <[email-masked]>
Date: Mon, 12 Jun 2000 17:27:04 -0700

I would agree with Eric here.

Since I started this thread, about three alternate (maybe complementary
approaches) to doing hierarchical tunnels with RSVP-TE got proposed:

1) Tony Li's email suggested that one can use RSVP-TE by tunneling the
RSVP messages between A and F via the tunnel between B&E.

2) There was a suggestion of using directed LDP over the first tunnel to
establish the second tunnel.

3) And finally a reference to draft-kompella-*** came out, which I admit
I haven't read yet, but will probably do tonight.

I think this topic deserves farther discussion. We are NOT writing a
research paper here, but trying to produce working, interoperable code.
So those that have this working in a network, lab, demo etc; please come
forward and speak up.

Do we need to have an informational ID on this?

Bora

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 Jun 2000 17:37:17 -0700

Bora,

> Do we need to have an informational ID on this?

If yes, then one way to address this would be extract the relevant
parts out of draft-kompella-*** and turn it into an Internet Draft on
its own.

Yakov.

---

From: Bora Akyol <[email-masked]>
Date: Mon, 12 Jun 2000 17:41:27 -0700

I would agree to a document that would result in a clear understanding of this
subject. I would also agree to help edit/co-author it (what is 1 less hour of
sleep per night anyway ;-)

Bora