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)
Here is a resend. I screwed the From address in the last mail. Der-Hwa ------- Forwarded Message > > Well, in theory this shouldn't cause any interop problems because > no matter what approach it has chosen itself, an implementation has to > be prepared to deal with a bandwidth decrease via a simple change in An implementation has to be prepared to deal with changes in ERO, RRO, Label Object, Label Request Object, SessionAttribute without requiring a new LSP-ID. In fact, an implementation should be prepared that most RSVP objects may change on-the-fly, and react accordingly. None of this is specified in rfc2205 and rfc3209, and most implementations do a good job on it today. Why is bandwidth decrease so uniquely different? > the tspec or via a reroute (new LSP-ID). In practice, it apparently > has caused interop problems... > > I'm only familiar with three implementations, two of them use the > reroute method and one just changes the tspec. Because reroute > is the safer method that is guaranteed to work, I'm with JP here There are deployed implementations on live networks today, it is way beyond the stage of being 'safer'. It is perhaps more appropriate to ask what is the technical reason that a new ID is required to get bandwidth decrease? Der-Hwa > and would suggest that the LSP-ID should always be incremented > for any bandwidth change (whether increase or decrease). > > Markus > > > > Hi Amir, > > > > You're correct, there is an ambiguity in the RFCs that we need to address |
|