The MPLS WG Archive

[Rahul Aggarwal <rahul@redback.com>]

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? 

On Wed, Jul 12, 2000 at 03:25:13PM -0400, George Swallow wrote:
> Rahul -
> 
> > 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.
> 
> 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.

Is it possible to document this in the draft?


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

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. 

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