Well, personally, if I was designing this, I would not a whole TLV for each bit flag! I would have a Setup-Type TLV. If that TLV is absent, RSVP-TE is supported. If the TLV is present, each bit means that a different setup type is supported. That means... Legacy nodes don't include the TLV and are assumed to support RSVP-TE Legacy nodes that receive the TLV don't know what it means and so object to the Open (leaving a new node to re-Open for RSVP-TE only). New nodes include the TLV and so indicate explicitly what they support. I know it is late for that type of change, so how we proceed might depend on what implementations have done already. Adrian From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick Sent: 21 July 2017 16:07 To: [email protected]; [email protected]; [email protected] Cc: [email protected] Subject: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type? Dear PCE-ers I don't want to distract from the SDN topic too much, but we have an important decision to make about draft-ietf-pce-lsp-setup-type. The shepherd review raised an issue that there is no way for a PCEP speaker to indicate that it can't (or won't) support RSVP-TE as a path setup type. It is entirely plausible that a node might not support RSVP-TE, or else have it disabled, for example in an SR-only network. We think that draft-ietf-pce-lsp-setup-type should be changed to allow a speaker to declare that they do or don't have support for RSVP-TE paths. There are two proposals. 1. Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a (new) RSVP-TE-CAPABILITY TLV in their OPEN object. If this TLV if missing, but some other CAPABILITY TLV is present (such as SR-CAPABILITY) then it means that the speaker does not support RSVP-TE as a path setup type. 2. Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a (new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON'T support RSVP-TE. If this TLV is omitted, it will be assumed that they do support RSVP-TE. The problem with (1) is that it is not backwards compatible. Any existing SR implementation which also supports RSVP will not currently send this new capability. So, if we make change (1) then forwards-level implementations will incorrectly conclude that such backwards-level implementations do not support RSVP-TE. The problem with (2) is that it is ugly, and in my opinion we should only do something ugly with a new protocol extension if we simply can't avoid doing it. And so the question: are there any *deployments* of PCEP in a mixed SR/RSVP-TE environment that would be broken if we made change (1)? Thanks Jon
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
