Hi Dhruv, The issue we have is that all the PCC and PCE implementations which successfully interoperated until and during last year EANTC event implemented the top level SR-PCE-CAPABILITY TLV with a value of 26. While one can reasonably quickly upgrade a PCE to use the combination of the PATH-SETUP-TYPE-CAPABILITY TLV and SR-PCE-CAPABILITY sub-TLV, the issue is really with the PCC. Many of our customers deploy routers with support of the top level SR-PCE-CAPABILITY TLV only and upgrading them is not always possible within a reasonable timeframe. In fact some customers will only upgrade if they are picking a new major feature. So, we cannot control this as vendors really.
My vote is to relax the rule and make it a SHOULD because the onus will most likely be on PCE implementations to support both earlier and latest encodings. Implementations which chose to do this optional behavior MUST send both TLVs. Also, the text below is not sufficient. It should also state the behavior of newer implementation towards implementations which followed the earlier versions of this draft. The newer implementation must send both the PATH-SETUP-TYPE-CAPABILITY TLV (with the SR-PCE-CAPABILITY TLV as sub-TLV) *and* the SR-PCE-CAPABILITY as a top level TLV. That way the earlier implementations will ignore the first TLV (and its sub-TLV) and honor the second TLV. The text below does not state that. Also, I am not sure if the sub-TLV will have a codepoint drawn from the same space as the top level PCEP TLVs. If so, then we cannot re-use the value of 26 as far as I understand but I may be wrong. Regards, Mustapha. -----Original Message----- From: Pce <pce-boun...@ietf.org> On Behalf Of Dhruv Dhody Sent: Wednesday, February 6, 2019 8:40 AM To: pce@ietf.org Subject: Re: [Pce] Backward compatibility with earlier version of draft-ietf-pce-segment-routing Hi WG, I wanted to clarify the context for the mail. We added the quoted text (see below mail) to allow backward compatibility with older implementations of this draft (which did not follow the later changes reflected in RFC 8408). The IESG has however pointed out that our proposal does not meet the expectation for a Standard Track document (c.f. "It is inappropriate to use Internet-Drafts as reference material" from the boilerplate). It is the expectation that any pre-standards implementations needs to figure out a way forward and comply with the standard. We need to resolve this IESG discuss to allow this document to move forward. Please reply on the mailing list or send mail to pce-cha...@ietf.org, if removing this text is an issue for you with your reasons. The last date is extended to 13th Feb to accommodate for the Lunar New Year break (Happy year of the Pig!) Thanks! Dhruv (for the PCE chairs) On Sat, Feb 2, 2019 at 8:49 AM Dhruv Dhody <dhruv.i...@gmail.com> wrote: > > Hi WG, > > To accommodate earlier implementations of PCEP-SR (before the path > setup type capability exchange was changed), we added this text to > allow backward compatibility with older versions - > > > https://tools.ietf.org/html/draft-ietf-pce-segment-routing-14#section- > 7 > > Some implementations, which are compliant with an earlier version of > this specification, do not send the PATH-SETUP-TYPE-CAPABILITY TLV in > their OPEN objects. Instead, to indicate that they support SR, these > implementations include the SR-CAPABILITY-TLV as a top-level TLV in > the OPEN object. Unfortunately, some of these implementations made > it into the field before this document was published in its final > form. Therefore, if a PCEP speaker receives an OPEN object in which > the SR-CAPABILITY-TLV appears as a top-level TLV, then it MUST > interpret this as though the sender had sent a PATH-SETUP-TYPE- > CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and > SR-TE PSTs are supported) and with the SR-CAPABILITY-TLV as a sub- > TLV. If a PCEP speaker receives an OPEN object in which both the SR- > CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level > TLVs, then it MUST ignore the top-level SR-CAPABILITY-TLV and process > only the PATH-SETUP-TYPE-CAPABILITY TLV. > > It has been a while since RFC8408 was published and this document > updated, and you might have already updated your implementations to > the latest standard. > > - Are there any older implementations, still in the field that needs > to inter-operate with other pcep speakers that are running the latest > standard? > - If yes, can they be patched to latest standard in a planned manner, > without impacting the network operations? > - Please shout out the impact if the above text is removed. > - Further, if you have a valid rationale to keep the text, would you > be fine with changing MUST to SHOULD in the text? > > Please respond by 8th Feb. You may choose to reply directly to the > chairs/AD instead of mailing list if you wish. > > Thanks! > Dhruv (for the PCE chairs) _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
