Sighing slightly:-) If, as may be the case, there is a demand to make this work either as currently specified or to be seamlessly interoperable with what is already specified then so be it. Let's make that as a conscious decision. However, I think that using 7120 as an "excuse" is a bad idea. What 7120 is saying is that the allocated code point must show some stability in meaning from the point of early allocation on to RFC (just as it would need to if the RFC was revised). But that is not saying that, upon noticing that we are a herd of lemmings rushing towards the cliff we must say "We have always rushed towards the cliff. Our parents rushed towards the cliff. We must continue even if it means we plunge to our deaths." Of course, nothing so dramatic, but... If the current specification works well - stay with it. If the current specification works but is clumsy - tweak it in a backward compatible way If the current specification is broken in a minor way - fix it in a backward compatible way If the current specification is more seriously broken - burn a new code point to fix it In my earlier emails I was only speculating on "how I would have done this if starting from scratch." Obviously (?) I should have participated in WG discussions much earlier in the cycle, and as a result my opinion really only counts if either: - the current specification is more seriously broken or - there is no WG desire to stick close to the current specification. Clearly, although people who implement against I-Ds are doing so at their own risk, we should not unnecessarily burden early implementations with changes just for the sake of change. There is a sliding scale of "better ways to do things" that incorporates "it's a bit messy," "it will be easier to maintain and extend," all the way up to "it's broken." The WG will want to work out where we are on that scale and weigh it against the cost and inconvenience of change. Shipping in software may be one measure. Deployed and in use is another measure. Cheers, Adrian From: Julien Meuric [mailto:julien.meu...@orange.com] Sent: 25 July 2017 09:31 To: Jonathan Hardwick; adr...@olddog.co.uk; pce@ietf.org Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; draft-ietf-pce-segment-rout...@ietf.org Subject: Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type? Hi,
I agree that capability bitmap with optional capability-specific sub-TLVs would be the way to go from scratch. However the SR-PCE-CAPABILITY already has an early allocated codepoint, and RFC 7120 says that "if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable." As a result, it seems to me that adding this new format may require that the I-D keeps documenting an optional SR-PCE-CAPABILITY TLV for legacy reasons. Cheers, Julien Jul. 25, 2017 - jonathan.hardw...@metaswitch.com: I agree that allowing optional sub-TLVs is a good thing. However, this strongly suggests that SR-PCE-CAPABILITY should become a sub-TLV, which is a non-backwards compatible change. So, we are back to my original question. Implementers - any views? Cheers Jon From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: 24 July 2017 19:51 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:jonathan.hardw...@metaswitch.com> mailto:jonathan.hardw...@metaswitch.com] Sent: 24 July 2017 09:15 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:adr...@olddog.co.uk> mailto:adr...@olddog.co.uk] Sent: 21 July 2017 19:55 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:pce-boun...@ietf.org> mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: 21 July 2017 16:07 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
