Subject: Optical MPLS

From: "Chatterjee, Shash" <[email-masked]>
Date: Wed, 5 Jul 2000 12:05:53 -0500

Hello everyone!

Where can I get a comprehensive list of the MPLS/CR-LDP
optical/lambda-switching drafts? 
So far, I have read draft-kompella...,draft-fan..., draft-basak... and
draft-krishnaswamy...  Are there any others?  Also, are there any other
(potentially non-IETF)  documents/mailing-lists where I can learn about the
various standards efforts and issues related to this topic?

Any pointers on this topic would be very welcome.

Thanks in advance,
Shash

Sasvata (Shash) Chatterjee
[email-masked]
White Rock Networks
Dallas, Texas, USA

---

From: Rajiv Papneja <[email-masked]>
Date: Wed, 5 Jul 2000 22:20:32 -0400 (EDT)

Hi Shash,

 Here are some more drafts related to MPL(ambda)S that you can
refer. These are available at IETF website.

 1)   Multi-Protocol Lambda Switching:Combining MPLS Traffic Engineering 
      Control With Optical Crossconnects
                       (draft-awduche-mpls-te-optical-01.txt)
   
 2)   Extensions to RSVP for optical networking                           
                       (draft-lang-mpls-rsvp-oxc-00.txt) 

  Also, you can find some good links related to optical networks at the
following site :
             http://user.chollian.net/~son6971/optical/opticalinternet.htm

 Regards

 Rajiv Papneja 
 (GRA-AIL)

> [email-masked]

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4700
email: [email-masked]
********************************

---

From: Chris Metz <[email-masked]>
Date: Wed, 05 Jul 2000 23:55:25 -0700

Check out:

http://infonet.aist-nara.ac.jp/member/nori-d/mlr/

>[email-masked]

Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: [email-masked]
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jul 2000 14:35:21 -0400

A number of us just submitted a draft that merges and extends some of 
the drafts you mention.  If you (or anyone else) would like to take a 
look at it before it comes out in the standard places, it's available at:
http://www.labn.net/lberger/docs/draft-ashwood-generalized-mpls-signaling-00.txt

Lou

---

From: "Robert Rennison" <[email-masked]>
Date: Fri, 14 Jul 2000 16:59:43 -0400

Lou et al,

I have two minor comments on this well written draft.

1.

There is a minor typo in section 3.1.1 for the Generalized Label Request
TLV.

The description of the TLV encoding for CR-LDP says:

"The format of a Generalized Labels (in CR-LDP) is:"

Instead it should say.

"The format of a Generalized Labels Request (in CR-LDP) is:"

I have previously commented to some of you that the similarity between the
name of
this Generalized Label Request TLV  and that of the Generalized Label
object/TLV will
lead to confusion and errors.

2.

In section 3.2.2 Procedures it specifies that:

   The Generalized Label travels in the upstream direction in
   MAPPING/Resv messages.

Upon first reading it appears that the generalized label _only_ flows in
the upstream direction. The next line goes on to discuss what happens in the
presence of
both a generalized and normal label,and error. It is not mentioned,in this
procedures section,
that the generalized label is allowed in the downstream direction in the
presence of link bundling.

Better would be something like:

   The Generalized Label travels in the upstream direction in
   MAPPING/Resv messages and optionally in the REQUEST/Path message when
   in the presence of link bundling.

Regards

Rob Rennison
---------------
Robert Rennison
Laurel Networks
Ph:  (724) 933-7330
Fax: (724) 933-3377
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Lou
> Berger
> Sent: Friday, July 14, 2000 2:35 PM
> To: Chatterjee, Shash
> Cc: MPLS Mailing-list (E-mail)
> Subject: draft-ashwood-generalized-mpls-signaling- (was Re: Optical
> MPLS)
>
>

---

From: "Ganesh Murugesan" <[email-masked]>
Date: Fri, 14 Jul 2000 17:13:31 -0400

Lou,

I had a few questions on this draft.

3.1.2. Procedures

   A node processing the Path/REQUEST message containing the Generalized
   Label Request must verify that the requested parameters can be
   satisfied by the node and by the outgoing interface.

Are we talking about the node generating the Path/Request Message or the
one receiving the message.  If it is the receiving then shouldn't the
interface by incoming interface?

4.2 Procedures (Bidirectional LSP)

   Terminator nodes process Path/REQUEST messages as usual, with the
   exception that the upstream label can immediately be used to
   transport associated data upstream to the initiator

Does this mean that the RESV messages flowing upstream will be labeled
packets ?  Can this be explained?

thanks
ganesh

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jul 2000 19:38:03 -0400

Rob,
         See responses below.

>"The format of a Generalized Labels Request (in CR-LDP) is:"

Thank you.

>presence of link bundling.

I think one of us is confused, perhaps you're talking about suggested label?

Thanks for the feedback.

Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 14 Jul 2000 19:43:48 -0400

Hi Ganesh,

>interface by incoming interface?

My view is that the previous hop verifies that the downstream link is 
compatible.  Certainly a statement that includes both incoming and outgoing 
interface is accurate as well.

>packets ?  Can this be explained?

No.  RSVP messages are control messages.  They are processed 
normally.  I'll look at rewording, but thing it's pretty close as is.

Thanks for the comments,

Lou

---

From: "Robert Rennison" <[email-masked]>
Date: Sun, 16 Jul 2000 14:57:24 -0400

Lou,

I believe that any confusion is  caused by the following  statement in
section
3.2.2.

"The presence of both a generalized and normal label object in a
Path/REQUEST message is a protocol error and should be treated as a
malformed message by the recipient."

This explicitly states that only the presence of _both_ the
generalized and normal label object is a Path/REQUEST message is an error.

This did seem like an odd statement, why would you worry about both of
the label and generalized label being in the Path/REQUEST message.

I therefore inferred that the generalized label could be used in
the Path/REQUEST message to hint to the downstream node the upstreams
preference, in essence the functionality you have with the separate object
called the Suggested Label.

I am curious, why did you specify a new TLV, the suggested label, which is
identical to that of the generalized label, instead of
merely allowing the generalized label to be sent in the downstream direction
to achieve this functionality. Error handling procedures perhaps ?

There is precedent in other signaling protocols for overloading of the
generalized label TLV,
 consider the mechanism in ATM signaling, whereby the user side
of a Q.2931 link was allowed to include the connid info element in the
initial
SETUP message. This was also the technique used in non-facility associated
signalling.

Regards.

Rob

---------------
Robert Rennison

Laurel Networks
Ph:  (724) 933-7330
Fax: (724) 933-3377