Subject: RE: A new draft.

From: Jonathan Lang <[email-masked]>
Date: Tue, 18 Jul 2000 18:03:52 -0700

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).

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.
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.

On another note, I think overloading the ResvError message for label
allocation is a bad idea.
 
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: "Zhang, Leah" <[email-masked]>
Date: Wed, 19 Jul 2000 14:26:33 -0700

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,

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.  

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

We agree to this assessment.

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    <-----

+ A +                                 + B +                                +
C +  

+ A +                                 + B +                                +
C +  

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

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

[email-masked]

---

From: "Guo, Dan" <[email-masked]>
Date: Thu, 20 Jul 2000 18:11:14 -0700

Lou, Janathan and Leah,

The new generalized draft (just released) is an excellent piece for our
work. To all
of us working in this area, it is very helpful. 

Our draft came out of our practical work. After carefully examining the
issues,
I feel it may add to the generalized draft in the following aspects -

   1. Wavelength continuety issue to MPLS for some types of networks: we
feel
      it is of importance. 

   2. Contention scenario 2 outlined in Janathon's email:

      Our approach naturally AVOIDs the problem.  

      The approach by Janathan (as well as in the Generalized draft) is a
valid 
      one to RESOLVE contention.

      The difference is, we are for Contention-avoidance and the other 
      approach (through PathErr) is for Contention-resolution (as result,
one node
      loses and has to start over). Our approach lowers the chance to get
into the
	 trap of  contention.

      I also want to raise one point: The contention scenario 2 (outlined by

      Janathon) occurs NOT because "there are only enough resources for one
of the
      bi-directional LSPs" as mentioned in Janathon's email. It can still
happen when 
      there are plenty of resources but two neighboring nodes grab the same
link
      due to not-knowing-each-other's-actions. It is a race condition due to
lack of
      synchronization.

   3. Contention scenario 1 outlined in Janathon's email: our approach, at
the 
      current form, cannot avoid it. One way is to borrow the idea from
Janathon's
      approach using IP address. There could be other way. we will follow up
on this. 

We incline to change as little as possible to RSVP-TE (ie. not to allocate
label in Path 
msg and change the nature of receiver-initiating in RSVP). This is why we
use ResvErr in our draft. Other way (like Confirm, or Path) can be used for
this ONE-HOP informing the label allocation.

I hope the generalized draft by Janathan/Lou and others can absorb some of
points in our drafts.

Best regards,

Dan

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Thursday, July 20, 2000 9:08 AM
To: 'Zhang, Leah'
Cc: Jonathan Lang; Fu, James; [email-masked]
Subject: RE: A new draft.

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:

>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
>>From: Zhang, Leah [mailto:[email-masked]]
>>Sent: Wednesday, July 19, 2000 2:27 PM
>>To: 'Jonathan Lang'; Fu, James; [email-masked]
>>    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>ht
tp://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Jul 2000 09:20:55 -0400

Dan,
         See in-line comments.

>    1. Wavelength continuety issue to MPLS for some types of networks: we 

no argument, lots of others have made the same point.

>       Janathon) occurs NOT because "there are only enough resources for 
> one of the
>       there are plenty of resources but two neighboring nodes grab the 
> same link
>       due to not-knowing-each-other's-actions. It is a race condition due 
> to lack of
>       synchronization.

As mentioned in my last mail the right solution to cover this case is to 
use LabelSet.  The document should have discussed this in the context of 
bi-directional LSPs.  We can fix this in the next, rev.

I think we handle this particular error in a similar fashion 
(PathErr).  When using LabelSet (with a single element) both labels can be 
allocated on the Path message.  If the downstream node finds the label in 
the LabelSet unacceptable (for contention or any other reason) it responds 
with a PathErr.

>    3. Contention scenario 1 outlined in Janathon's email: our approach, 
> at the
>       approach using IP address. There could be other way. we will follow 
> up on this.
>
>use ResvErr in our draft. Other way (like Confirm, or Path) can be used 
>for this ONE-HOP informing the label allocation.

Given the fundamental addition of bi-directional LSPs, I the -generalized 
approach is cleaner / less complex.

>I hope the generalized draft by Janathan/Lou and others can absorb some of 

Absolutely.  We'll at least have a draft that better explains different 
scenarios.  (sorry about not doing a better job.)  I'm still not sure if 
there's anything in your draft that is not functionally provided in the 
-generalized draft.  Certainly the -generalized draft uses different 
mechanisms, but are there any functions that are missing or broken relative 
to your draft?

Thanks,
Lou

>From: Lou Berger [<mailto:[email-masked]>mailto:[email-masked]]
> >>From: Zhang, Leah 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >>From: Jonathan Lang [<mailto:[email-masked]>mailto:[email-masked]]
> >>>From: Fu, James [<mailto:[email-masked]>mailto:[email-masked]]
> >>><<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>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: "Guo, Dan" <[email-masked]>
Date: Fri, 21 Jul 2000 10:35:55 -0700

Lou, i appreciate/like your kind response (i apologize for mis-spelling
Jonathan's name)
some comments follow and hope it helps.

>the LabelSet unacceptable (for contention or any other reason) it responds 
[Dan's comment]
when you revise the generalized draft, i hope you study if it is worthwhile
to adopt the special way of allocating a pair of labels, detailed in our
draft. 
   Conventional Way:
     1.             Node    -----> Node 
                      A    <-----  B
   Our way:
     2.   Node       Node  <----- Node
          C  ----->   A           B

By using way 2 instead way 1, it avoids the contention scenario 2 (see
Jonathan's email)
and thus avoids those special/unnecessary PathErrs.  PathErr will occur only
for 
contention scenario 1 (see Jonathan's email). 

>scenarios.  (sorry about not doing a better job.)  
thanks! i think you/others did a terrific job in coordiating things to reach
consensus.
 
>I'm still not sure if 

>to your draft?

[Dan's comments]
In terms of high-level functions, i agree our draft
(draft-sorrento-rsvp-bi-osp-00.txt)
 provides a subset of functions from your draft. 
i personally think contention-avoidance (as compared to contention
resolution) may
be considered as a low-level function. However, as our draft did not avoid
the 2nd
type of contentions, the value is limited somewhat. We will put some more
study.

sincerely,
Dan

---

From: Jonathan Lang <[email-masked]>
Date: Fri, 21 Jul 2000 11:17:24 -0700

Dan,
  For case 2 that I mentioned in a previous email (and referred to in both
yours and Lou's email), if there are available resources, contention is
always *avoided* with the Upstream Label for bi-directional LSPs outlined in
draft-lang-mpls-rsvp-oxc-00.txt and draft-generalized-signaling-mpls-00.txt.
I think Lou's suggestion about discussing these issues in Pitts. is a good
one.

-Jonathan 

Calient Networks

-----Original Message-----
From: Guo, Dan [mailto:[email-masked]]
Sent: Friday, July 21, 2000 10:36 AM
To: 'Lou Berger'; Guo, Dan
Cc: Zhang, Leah; Jonathan Lang; Fu, James; [email-masked]
Subject: RE: A new draft.

[Dan's comment] 

  

[Dan's comments] 

sincerely, 
Dan