Hi WG, Thanks to all of you who responded on the mailing list and offline on this.
Your chairs, AD and Jon worked with Alvaro on his concern and the compromise that we came up with is to move this to appendix (without the use of normative language). We will also incorporate suggestion made by Mustapha and Quan in the new text. Lookout for the new version that will be posted by Jon. I will also like to thank Jon who did a lot of heavy lifting for this very important document. Regards, Dhruv, Julien and Adrian On Wed, 6 Feb 2019 at 7:09 PM, Dhruv Dhody <dhruv.i...@gmail.com> wrote: > 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
