Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE

From: Chatur sharp <[email-masked]>
Date: Tue, 13 Jun 2000 12:05:20 -0700 (PDT)

Shahram and Eric( Gray and Rosen)

This is exactly, what we discussed on the mailing
list yesterday. And it seems to hold all the threads
togather.

However, the concern is this: is it just a quick
fix solution/explaination or was this the intent 
of the draft in the first place ?

I guess it is time for anyone using NULL label as
the sole label to SPEAK UP.

C.

--- Eric Rosen <[email-masked]> wrote:
> 
> 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. 
> 
> 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. 
>  
> 
> 

=====
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: Yakov Rekhter <[email-masked]>
Date: Tue, 13 Jun 2000 12:29:24 -0700

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: Daniel Awduche <[email-masked]>
Date: Tue, 13 Jun 2000 15:54:14 -0400

The FA concept clearly has independent interest, besides the 
original optical application. In fact, it is needed in certain
operational contexts today. Therefore, it's a good idea to
document it separately, and include additional relevant details 
not shown in draft-kompella-optical-mpls-00.txt, so that, 
hopefully, interoperable implementations can be derived

Cheers,
/Dan

---

From: Bora Akyol <[email-masked]>
Date: Tue, 13 Jun 2000 14:54:43 -0700

I would support this.

Bora

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 Jun 2000 08:38:58 -0700

Dan,

> hopefully, interoperable implementations can be derived

Kireeti and myself did as we promised. The Internet Draft is
draft-kompella-lsp-hierarchy-00.txt. Kireeti and myself would like the
MPLS WG to accept this Internet Draft as an MPLS WG document.

Yakov.

---

From: Rohit Chhapolia <[email-masked]>
Date: Thu, 22 Jun 2000 16:48:07 -0400

In the section 5.1, it is suggested that Path/Resv message
should be encapsulated in another IP header if sent
as unicast over the control plane. Can you please
clarify why is this required?

It should be possible to send the Resv message as it is.
Path message can be sent without router alert to the
next hop IP address. In this case, IP address of the tail
end of the FA-LSP.

thanks,
Rohit

-- 
Rohit Chhapolia
Globespan, Inc.
mailto:[email-masked]
http://www.globespan.net

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 22 Jun 2000 14:57:59 -0700

Rohit,

> clarify why is this required?

See below....
  
> It should be possible to send the Resv message as it is.

Agreed.

> next hop IP address. In this case, IP address of the tail

Agreed.

We'll correct the text in the next iteration of this document.

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2000 19:19:04 -0400

Yakov,

IP encapsulation *is* required on path messages as intermediate nodes may 
process the PATH message even if a router alert isn't included.

IP encapsulation of the Resv is beneficial as it ensures intermediate nodes 
don't hand the RSVP message to the RSVP code/module.  This is an 
optimization, hence "may" or "should" is appropriate.

Lou

---

From: Rohit Chhapolia <[email-masked]>
Date: Wed, 28 Jun 2000 15:36:44 -0400

Lou,

Probably I don't understand something here. But I think
that if a message is not addressed directly to a node and
RA isn't included, it will be forwarded by the IP layer to
the next hop based on the destination address. It should be
treated just like any other data packet in this regard.

Rohit

-- 
Rohit Chhapolia
Globespan, Inc.
voice: 732-345-6237

---

From: Lou Berger <[email-masked]>
Date: Wed, 28 Jun 2000 20:53:40 -0400

Go back to RFC2205.  It allows for interception of protocol 46 even when RA 
is *not* included....

Lou