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

From: Dhruv Dhody <[email-masked]>
Date: Sat, 2 Feb 2019 08:49:12 +0530

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)

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 6 Feb 2019 19:09:55 +0530

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!

---

From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 12 Feb 2019 21:53:02 +0000

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 <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Wednesday, February 6, 2019 8:40 AM
To: [email-masked]
Subject: Re: [Pce] Backward compatibility with earlier version of draft-ietf-pce-segment-routing

Hi WG,

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.

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)

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 1 Mar 2019 08:48:32 +0530

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