Hi Ben, On Thu, Oct 3, 2019 at 11:34 PM Benjamin Kaduk <[email protected]> wrote:
> Hi Deborah, > > On Tue, Oct 01, 2019 at 10:24:05PM +0000, BRUNGARD, DEBORAH A wrote: > > As it seems there are still some questions on "update or not", I'll try > to add some additional context. As we know, it is difficult to define > "update", so each working group has their context for it. For TEAS, CCAMP, > MPLS, PCE, if it is a new capability, which is making use of previously > reserved bits, we have not considered it an update, otherwise every new RFC > would be an update of the base RFC. > > > > Here's an example of exactly this (a quick scan by me, I'm sure there > are many more across all the groups): > > The PCE-CAP-FLAGS sub-TLV was defined in RFC5088 (bits 9-31 were > reserved). RFC 8623 defined stateful P2MP and defined new capability bits > (from the reserved group) using 13, 14, 15. It was not considered an update > of RFC5088 (OSPF extensions for PCE Discovery), or RFC8306 (P2MP TE LSPs > for PCEP), or RFC8281 (base document with extensions to support stateful > PCE). And RFC5088 was not an update of OSPF (RFC2328 and RFC2740). And > RFC8281 was not an update to RFC5440 PCEP base spec). As you can see, this > would result in a very big waterfall if all these were considered updates.. > An implementor of the base spec, with no interest in these new > capabilities, would need to read all the updates just to be sure the base > is not impacted. We wouldn't have any implementations, everyone would still > be reading😊 > > > > In this document, these new values are using several more of the > previously reserved values. Only implementors of this new capability need > to be aware of these assignments, so among PCE folks, it is not considered > an update. > > > > Dhruv already responded to Ben on the PLSP-ID. It is the same as these > flags, only those wanting to implement this new capability need to be aware > of it. And it is backwards compatible with the base spec. > > This all makes sense to me, and I see the reasoning behind not using > Updates: for them. I'm not sure that our discussion here has covered the > relaxation of error handling, though -- we have "this MUST NOT trigger the > error handling as specified in [RFC8231]" in one place, and IIRC a similar > thing in one other place. In some sense, this is overriding RFC 8231 and > an implementation of this spec is no longer compliant with the base RFC > 8231 specification. So, I wonder if the Updates: tag is needed in order to > "legitimize" this weakening of the requirements, as otherwise we have two > specifications which are formally in conflict with each other, one of which > is needed in order to use the other. > > IMHO this is similar to a protocol extension of an existing protocol message (with an updated parsing rules represented as RBNF). The base protocol (RBNF) might consider the extension as mangled as per the rules of the base RFC and trigger error but the extension overrides that. In this case, the error handling text was added as a helpful note to an implementer of this feature: to make sure that at the time of parsing, one should check for the C flag first before doing RFC8231 check on PLSP-ID. An existing RFC 8231 implementation (that does not implement this feature requires) no change. Maybe the current text goes overboard. We could reword this - OLD: The PLSP-ID of 0 indicates that the PCE wants control over all LSPs originating from the PCC. A PCC that receives a PCUpd message with C Flag set to 1 and PLSP-ID of 0 MUST NOT trigger the error condition for unknown PLSP-ID in an LSP update request as per [RFC8231]. NEW: The PLSP-ID of 0 indicates that the PCE wants control over all LSPs originating from the PCC. An implementation of this feature needs to make sure to check for the LSP control feature (C flag set to 1) before any check for PLSP-ID (as prescribed in [RFC8231]). END Thanks! Dhruv > Thanks, > > Ben >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
