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
