Subject: draft-ietf-mpls-rsvp-lsp-tunnel-06.txt

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 12 Jul 2000 11:44:40 -0700

George et al.,
I have a few comments on the new version of the RSVP-TE draft:

1. Bandwidth Increase procedure:
The draft talks about doing bandwidth increase in a manner similar to 
make-before-break i.e. using a new LSP_ID to attempt a larger bandwidth
reservation. 

I am wondering why this can not be achieved by 
sending a new path refresh with an increased adspec. This will result in
the receiver sending a resv with an increased flowspec. If there is an 
admission control failure during path msg propagation (or during resource
reservation, while processing the resv message), a path/resv error will be
sent. In that case its up to the sender to revert back to the old adspec or
to try and reroute the tunnel with the higher adspec.

2. To spread a traffic trunk over multiple paths, a sender may create more
than one LSP tunnel (with a different LSP_ID and the same Tunnel id). It
may be desirable to share resources on common links between the LSP tunnels. In
this case the receiver has to send the resv with a SE style flow descriptor.
Shouldn't there be a flag in the session attribute object to indicate this,
just like it is done for rerouting with the 'ingress node may reroute' flag?

3. The label subobject in a RRO has a flag to indicate a global label. Is
the primary purpose of this to enable the upstream router to do fast reroute
with the knowledge that the downstream supports a global label? Currently
there is no other way of signaling this to an upstream router and such 
an indication is useful, though I am not sure if using the label subobject
in a RRO is the best way to do this. 

4. The draft has removed the 'Merging permitted' flag in the session 
attribute object. I am not sure what the purpose of this flag was, to begin
with, and out of curiosity what is the reason for taking it out? 

I will appreciate any comments on the above.

Thanks,
rahul

---

From: George Swallow <[email-masked]>
Date: Wed, 12 Jul 2000 15:25:13 -0400

Rahul -

> to try and reroute the tunnel with the higher adspec.

If no policy is being enforced by nodes on Path messages, then what
you suggest will work just fine.  

Otherwise there's a problem.  If a policy engine has an up/down
decision to make on forwarding a Path message and the bandwidth cannot
be increased then the whole tunnel will be torn down.  The procedures
are to cover that case.
 
> just like it is done for rerouting with the 'ingress node may reroute' flag?

I don't understand.  If you split the load over multiple paths
and some of these paths have links in common, then those links will
need more capacity.  So setting up multiple tunnels (different Tunnel
id) or using FF seems like a better approach.
 
> in a RRO is the best way to do this. 

Seems like an efficent way to me.  Got a better idea?

> with, and out of curiosity what is the reason for taking it out? 

You were far from being alone in not being sure.  And of those who
were sure, there were multiple opinions.  One use that was clear was
to allow an ATM LSR to not be forced to merge if it is merge
incapable.  But for that it made more sense put it in the Label
Request Object for ATM.
 
> I will appreciate any comments on the above.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 12 Jul 2000 14:07:11 -0700

George,
Thanks for the comments. I have a couple of inline comments:

Also I just realized that the new draft has limited the contents of the label
object to a single label, rather than a stack of labels. What is the reason
for this limitation? 

> be increased then the whole tunnel will be torn down.  The procedures

Is it possible to document this in the draft?

> id) or using FF seems like a better approach.

I agree. However a similar problem arises while attempting to increase the 
bandwidth of an existing tunnel. Will the sender initiate the tunnel with the
'ingress node my reroute' flag? 
Perhaps it is best to have a flag saying 'ingress node desires bandwidth 
sharing'. That can take care of reroute, bandwidth increase or other cases 
where sharing may be desired  and will enable the receiver to respond with
a SE style resv. 

> Seems like an efficent way to me.  Got a better idea?

It means that to achieve the above, I have to always include a RRO in a path
and resv message. If all I want to know is whether the label received from
downstream is from the global label space or not, this seems like an overhead.
Is it possible to: 
a) Have a flag/bit in the label-request object to ask the
   downstream for the label scope of the label
b) Add a new object before the label object for the downstream to convey the
   label scope to the upstream. Or have a special label to indicate that
   the label stack is from the global space. This special label can be the
   topmost label of the label object. (Goes back to having the label object
   as a stack)

thanks,
rahul

---

From: "Ganesh Murugesan" <[email-masked]>
Date: Thu, 13 Jul 2000 09:01:36 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Rahul
> Aggarwal
> Sent: Wednesday, July 12, 2000 5:07 PM
> To: George Swallow
> Cc: Rahul Aggarwal; [email-masked]
> Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-06.txt
> 
> 
> George,

====> But Section 1.1 Background 2nd paragraph says 
      "Label stacking is also supported."

thanks
ganesh

---

From: George Swallow <[email-masked]>
Date: Thu, 13 Jul 2000 16:43:00 -0400

ganesh -

>       "Label stacking is also supported."

Missed that one.  Thanks for pointing it out.

...George

---

From: "Ganesh Murugesan" <[email-masked]>
Date: Thu, 13 Jul 2000 16:53:47 -0400

Section 4.1.1.1

   If a node receives a Resv message that has assigned the same label
   value to multiple senders, then that node MAY also assign the same
   value to those same senders or to any subset of those senders.

The above seems a little confusing. Is the draft suggesting that the node
receiving
the RESV use the received label as the label in the RESV message it sends to
the upstream neighbor ?  Or is it that the receiving node when generating
its RESV
MAY choose to send a common label (which may be different from the ones
received)to
those same senders or a subset of those senders.

thanks
ganesh

---

From: George Swallow <[email-masked]>
Date: Thu, 13 Jul 2000 16:57:13 -0400

> Is it possible to document this in the draft?

I added some discussion in section 2.2 on policy processing on Path
messages.  I didn't want to be too pendantic since this is a matter of
local policy and not part of the protocol.  If other folks think this
needs further explaining I can add some more.
  
> where sharing may be desired  and will enable the receiver to respond with

When I first added that flag I wanted to call it "SE Style desired".
Someone objected to that, but I can't remember why.  If no one objects
I'll put it back to that. 

>    topmost label of the label object. (Goes back to having the label object

The point is that you may want to merge a re-route path further
downstream than the very next node.  You only need the RRO if you're
doing that kind of local repair.  

Collecting up all the label values is also useful for network
management.

...George

---

From: George Swallow <[email-masked]>
Date: Thu, 13 Jul 2000 17:06:49 -0400

ganesh -

>    value to those same senders or to any subset of those senders.

I see your point.  Does the following change make it clear?

Section 4.1.1.1

   If a node receives a Resv message that has assigned the same label
   value to multiple senders, then that node MAY also assign a single
                                                             ^^^^^^^^
   value to those same senders or to any subset of those senders.

...George

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 13 Jul 2000 15:31:26 -0700

George,

> needs further explaining I can add some more.

The discussion in 2.2 is helpful. 
I guess my point is that there could be a couple of different ways of 
increasing the bandwidth. The one outlined in the draft is one of them and is 
useful in a certain context. Perhaps the text should make that clear. 

> I'll put it back to that. 

Fine. 

> doing that kind of local repair.  

Yes, I realized that after sending out the above. To handle a generic local
repair case, as described by you, RRO seems like the best way.

> Collecting up all the label values is also useful for network

Sure. 

thanks,
rahul