Subject: Re: [Pce] Backward compatibility with earlier version of draft-ietf-pce-segment-routing

From: <[email-masked]>
Date: Wed, 13 Feb 2019 15:48:35 +0800 (CST)

Hi Dhruv,

I support to keep the Backward compatibility with earlier version.

We have implemented the earlier version of using SR-PCE-CAPABILITY-TLV as the top-level TLV carried in OPEN message.
SR Capibility exchange errors has appeared in the operator test while old and new implementations coexist, especially in the
interworking scenario between different vendors. 

I suggest to add the text "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. Therefore, if a PCEP speaker receives an OPEN object, then older implementation can recognize 
the SR-PCE-CAPABILITY as a top level TLV." to that section cause the existing text just specifies the process of new implementation.

Thanks,
Quan

> 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 [email-masked],
> 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 <[email-masked]>; 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)