Yes to that, Jon. But what happens when the next thing comes along? Since sub-TLVs can be present, I would suggest to use a Setup-Type TLV with a bit map as I previously described in my email, and add optional sub-TLVs dependent on the bits that are set. Isn't that the best of both worlds? Adrian From: Jonathan Hardwick [mailto:[email protected]] Sent: 24 July 2017 09:15 To: [email protected]; [email protected]; [email protected]; [email protected] Cc: [email protected] Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type? Adrian, The SR-PCE-CAPABILITY TLV is more than just a Boolean value - it also contains information about the maximum SID depth. However, I like your idea and I think that it gives us a better way to do this without breaking backwards compatibility with existing SR implementations. Suppose we introduce a setup-type TLV into the OPEN object as you propose, and assign a bit to each setup type. If the TLV is absent, then RSVP-TE is supported. If the TLV is absent and the SR-PCE-CAPABILITY TLV is present, then RSVP-TE and SR are supported. This retains backwards compatibility with existing SR implementations. If the TLV is present, then the bits indicate which setup types are supported. We would modify the LSP setup type draft to say that implementations supporting path setup types other than RSVP-TE SHOULD include the setup-type TLV. It's not exactly beautiful, but it's not as ugly as RSVP-TE-NON-SUPPORT. Cheers Jon From: Adrian Farrel [mailto:[email protected]] Sent: 21 July 2017 19:55 To: Jonathan Hardwick <[email protected]>; [email protected]; [email protected]; [email protected] Cc: [email protected] Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type? 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]> mailto:[email protected]] On Behalf Of Jonathan Hardwick Sent: 21 July 2017 16:07 To: <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected] Cc: <mailto:[email protected]> [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
