Subject: RE: A new draft.

From: Jonathan Lang <[email-masked]>
Date: Wed, 19 Jul 2000 15:37:25 -0700

Zhang,

The tying together of the upstream and downstream label can be done using
the Suggested Label that is also proposed in draft-lang-mpls-rsvp-oxc-00.txt
(updated and included in draft-generalized-signaling-mpls-00.txt).

-Jonathan

-----Original Message-----
From: Zhang, Leah [mailto:[email-masked]]
Sent: Wednesday, July 19, 2000 2:27 PM
To: 'Jonathan Lang'; Fu, James; [email-masked]
Subject: RE: A new draft.

Jonathan:
 
   Thanks very much for your comments.  We read your draft very carefully.
There are a lot of good thoughts and points in your draft.  Please see our
response below.

James Fu, Dan Guo, Raymond Cheng, Leah Zhang 
 
Sorrento Networks Inc.
9990 Mesa Rim Road
San Diego, CA 92121

 -----Original Message-----
From: Jonathan Lang [mailto:[email-masked]]
Sent: Tuesday, July 18, 2000 6:04 PM
To: 'Fu, James'; [email-masked]
Cc: Jonathan Lang
Subject: RE: A new draft.

James,
  I read your draft and I'm afraid you have misunderstood the bi-directional
approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and included in
draft-generalized-signaling-mpls-00.txt).   The process of establishing a
bi-directional LSP is the same as the establishment of a unidirectional LSP
with the exception that an Upstream Label is added to the Path message.
(Incidentally, the flow of the Upstream Label is the same as the normal flow
of a Label would be for the upstream segment of a bi-directional LSP, except
that we have short-circuited sending the Path message upstream -- see
example below).

We understand your approach of assigning Upstream Label in the Path message,
and assigning Downstream Label in the Resv message.  In your approach, the
assignment of Upstream Label and 
the assignment of Downstream Label is not tied together. We think that to
support bi-directional LSP, it is important to do pair-wise assignment (or
reservations) at the SAME time. This becomes especially 

important in the transparent pure optical networks where wavelength
continuity is required.  

Contention may occur for the following reasons:
1)  If there is a requirement that the input/output ports for the
bi-directional path be tied together (e.g., if they must be on the same
physical I/O card).  Since these are assigned by different OXCs, contention
may occur.  The scheme that you have proposed will also have this contention
scenario.

We admit that we did not consider this requirement at the time we wrote the
draft. We defines the

contention specifically as two OXCs trying to assign labels for the same
link. This contention scenario, though, happens much less often than the
contention scenario where two OXCs trying to assign labels for the same link

2)  If two bi-directional LSPs are attempted to be established
simultaneously in opposite directions and there are only enough resources
for one of the bi-directional LSPs.  In this case, one of the LSPs cannot be
established along that path.  The scheme that you propose avoids this
contention, I assume, by resource checking on the Path message and sending a
PathError message to the losing LSP.  This is also how it is done in
draft-lang-mpls-rsvp-oxc-00.txt.

We agree to this assessment.

On another note, I think overloading the ResvError message for label
allocation is a bad idea.

We are not fond of this solution, too. However, this is a better compromised
solution at moment compared with that a new LMP has to be used together with
the RSVP extensions. . We are open to any good alternatives and suggestions.

To summarize, we think that to support bi-directional LSP (OSP), pair-wise
label assignment scheme is better  than uni -directional label assignment
schemes. This becomes especially important to support
wavelength continuity requirement in transparent optical networks. We will
modify our draft. A new version will come out soon.

Regards,
Jonathan
 
Example:
 
downstream ----->
upstream    <-----
 
(1)  RSVP-TE used to establish a bi-directional LSP:
 
+-+-+  Path(Label Request) +-+-+  Path(Label Request) +-+-+
Path(LabelRequest)
 |     |  --------------------------->  |     |
--------------------------->  |     |     --------------------------->
+    +  Resv(Label)              +    +   Resv(Label)             +    +
Resv(Label)
 |     |  <---------------               |     |  <---------------
|     |  <----------------            

+ A +                                 + B +                                +
C +  
 |     |  Path(Label Request)   |     |  Path(Label Request)  |     |
Path(LabelRequest)
+    +  <---------------------------  +    +  <--------------------------  +
+  <------------------------
 |     |  Resv(Label)                |     |     Resv(Label)            |
|      Resv(Label)
+-+-+  -------------------------->   +-+-+    -------------------------->
+-+-+  ------------------------>
 
(2)  bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt

+-+-+  Path(Label Request, +-+-+  Path(Label Request) +-+-+
Path(LabelRequest)
 |     |         UpstreamLabel)  |     |        UpstreamLabel)   |     |
UpstreamLabel)  
+    +  --------------------------->  +    +  ---------------------------> +
+  --------------------------->  
 |     |                                  |     |
|     |   

+ A +                                 + B +                                +
C +  
 |     |  Resv(Label)               |     |  Resv(Label)                |
|   Resv(Label)               
+    +  <---------------------------  +    +  <--------------------------  +
+  <------------------------
 |     |                                  |     |
|     |       
+-+-+                                 +-+-+
+-+-+   

-----Original Message-----
From: Fu, James [mailto:[email-masked]]
Sent: Tuesday, July 18, 2000 9:39 AM
To: [email-masked]
Subject: A new draft.

An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical
Path Setup" has been submitted to the IETF. 

http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt
<http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt>  

James Fu 
Sorrento Networks Inc. 
9990 Mesa Rim Road 
San Diego, CA  92121 

[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Thu, 20 Jul 2000 12:08:05 -0400

Zhang,
         Pair-wise/simultaneous label allocation for bidirectional LSPs is 
supported in draft-generalized-signaling-mpls-00.txt.  To achieve 
pair-wise/simultaneous label allocation for bidirectional LSPs, you'd use 
label set with just a single element (label).  This would required the use 
of the passed label by the downstream node.

Is there anything else covered in your draft that isn't addressed in the 
generalized draft?

Lou

At 03:37 PM 7/19/00 -0700, Jonathan Lang wrote:

>the Suggested Label that is also proposed in 
>draft-lang-mpls-rsvp-oxc-00.txt (updated and included in 
>draft-generalized-signaling-mpls-00.txt).
>
>-Jonathan
>>    Thanks very much for your comments.  We read your draft very 
>> carefully. There are a lot of good thoughts and points in your 
>> draft.  Please see our response below.
>>
>>
>>   I read your draft and I'm afraid you have misunderstood the 
>> bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and 
>> included in draft-generalized-signaling-mpls-00.txt).   The process of 
>> establishing a bi-directional LSP is the same as the establishment of a 
>> unidirectional LSP with the exception that an Upstream Label is added to 
>> the Path message.  (Incidentally, the flow of the Upstream Label is the 
>> same as the normal flow of a Label would be for the upstream segment of 
>> a bi-directional LSP, except that we have short-circuited sending the 
>> Path message upstream -- see example below).
>>
>>We understand your approach of assigning Upstream Label in the Path 
>>message, and assigning Downstream Label in the Resv message.  In your 
>>approach, the assignment of Upstream Label and
>>support bi-directional LSP, it is important to do pair-wise assignment 
>>(or reservations) at the SAME time. This becomes especially
>>physical I/O card).  Since these are assigned by different OXCs, 
>>contention may occur.  The scheme that you have proposed will also have 
>>this contention scenario.
>>We admit that we did not consider this requirement at the time we wrote 
>>the draft. We defines the
>>for one of the bi-directional LSPs.  In this case, one of the LSPs cannot 
>>be established along that path.  The scheme that you propose avoids this 
>>contention, I assume, by resource checking on the Path message and 
>>sending a PathError message to the losing LSP.  This is also how it is 
>>done in draft-lang-mpls-rsvp-oxc-00.txt.
>>We are not fond of this solution, too. However, this is a better 
>>compromised solution at moment compared with that a new LMP has to be 
>>used together with the RSVP extensions. . We are open to any good 
>>alternatives and suggestions.
>>
>>To summarize, we think that to support bi-directional LSP (OSP), 
>>pair-wise label assignment scheme is better  than uni -directional label 
>>assignment schemes. This becomes especially important to support
>>wavelength continuity requirement in transparent optical networks. We 
>>will modify our draft. A new version will come out soon.
>>
>>
>>Regards,
>>Jonathan
>>
>>Example:
>>
>>downstream ----->
>>upstream    <-----
>>
>>+-+-+  Path(Label Request) +-+-+  Path(Label Request) 
>>+-+-+   Path(LabelRequest)
>>+ A +                                 + B 
>>+                                + C +
>>  |     |  Path(Label Request)   |     |  Path(Label 
>> Request)  |     |   Path(LabelRequest)
>>+    +  <---------------------------  +    +  <-------------------------- 
 >> +    +  <------------------------
>>  |     |  Resv(Label)                |     |     Resv(Label) 
>> |     |      Resv(Label)
>>+-+-+  Path(Label Request, +-+-+  Path(Label Request) 
>>+-+-+   Path(LabelRequest)
>>+    +  --------------------------->  +    + 
>>---------------------------> +    +  --------------------------->
>>  |     |                                  |     | 
 >>           |     |
>>+ A +                                 + B 
>>+                                + C +
>>  |     |  Resv(Label)               |     |  Resv(Label) 
>> |     |   Resv(Label)
>>+    +  <---------------------------  +    +  <-------------------------- 
 >> +    +  <------------------------
>>  |     |                                  |     | 
 >>           |     |
>>+-+-+                                 +-+-+ 
 >> +-+-+
>>
>>>An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional 
>>>Optical Path Setup" has been submitted to the IETF.
>>>
>>><http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt>http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt 
>>>
>>>
>>>James Fu
>>>Sorrento Networks Inc.
>>>9990 Mesa Rim Road
>>>San Diego, CA  92121
>>>
>>>[email-masked]