The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)
In message <200211060003.gA603jS78616@merlot.juniper.net>, Der-Hwa Gan writes: > > > Der-hwa, > > > > Here we have a trade-off between a small potential for > > simplification represented by using a symmetrical approach > > (the same approach used for increasing or decreasing the > > TE-LSP bandwidth) and the potential risk of not being able > > to make a new reservation with a lesser bandwidth in the > > unusual use of FF reservation style. > > It is not a question of simplication. If FF reservation style is > excluded from RSVP-TE spec, then we won't discuss it. But if FF remains > a potential option (perhaps a future application may make use of it?), > then it is fair to consider it. > > My response was mainly to the point that Curtis raised - could there be > a reason that changing ID is bad? > > > > > Please tell me again why this is a hard choice? > > There are other benefits to not changing the ID. It was those considerations > that drove the original choice - it is more optimal, less > states, and less overhead to the network. > > Do you see a easy choice? > Der-Hwa If we can't agree that one approach is better, then we are stuck with the current situation. The ingress can either change the LSP-ID or not change the LSP-ID and just decrease the bandwidth. wrt you preferences. There is no "less states" advantage since you still have to implement bandwidth increase. The overhead of an additional interim LSP is inconsequential. In either case the flooding of a new reservable bandwidth amount incurs more overhead than the RSVP signaling, is identical for either approach, and is not a big deal either. If we still have two methods available to the ingress, then we have to make sure the midpoints can handle both. If so, then the only thing that we should add is (currently implied if the ingress can do it) that the midpoint LSR must be prepared to handle a decrease in bandwidth on an LSP. Curtis btw - maybe we should be getting rid of use of FF and just use SE but thats a whole new topic.
|
|