Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

From: [email-masked]
Date: Mon, 20 Nov 2017 06:59:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

        Title           : Conveying path setup type in PCEP messages
        Authors         : Siva Sivabalan
                          Jeff Tantsura
                          Ina Minei
                          Robert Varga
                          Jon Hardwick
	Filename        : draft-ietf-pce-lsp-setup-type-06.txt
	Pages           : 10
	Date            : 2017-11-20

Abstract:
   A Path Computation Element can compute traffic engineering paths (TE
   paths) through a network that are subject to various constraints.
   Currently, TE paths are label switched paths (LSPs) which are set up
   using the RSVP-TE signaling protocol.  However, other TE path setup
   methods are possible within the PCE architecture.  This document
   proposes an extension to PCEP to allow support for different path
   setup methods over a given PCEP session.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 20 Nov 2017 15:07:03 +0000

Dear PCE WG

This new revision of the LSP setup type draft makes the following changes.

1) Added a capability TLV for the OPEN object and rules for processing it, as discussed in the attached thread. This is to address Julien's WGLC comment that there was no way for a PCEP speaker to express that it doesn't support RSVP-TE as a path setup type.

2) Made the path setup type explicit for anything other than RSVP-TE paths (where absence of TLV implies RSVP-TE).  This is to address Stephane's recent comment to the list.

3) Updated the IANA / code point text to reflect that we have had an early allocation.

4) Made some editorial fixes and clarifications.

Best regards
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 20 November 2017 14:59
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?
From: Jonathan Hardwick <[email-masked]>
To: Mahendra Singh Negi <[email-masked]>, "[email-masked]" <[email-masked]>, 'Julien Meuric' <[email-masked]>, "[email-masked]" <[email-masked]>, Dhruv Dhody <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 25 Jul 2017 15:03:55 +0000

Mahendra, many thanks for your input.

PCE WG, we have a backwards compatible proposal on the table which, apart from making a special case of SR-PCE-CAPABILITY, seems reasonably clean (or, at least, not seriously broken).  Shall we go forwards with that?

Best regards

Jon

From: Mahendra Singh Negi [mailto:[email-masked]]
Sent: 25 July 2017 13:12
To: [email-masked]; 'Julien Meuric' <[email-masked]>; Jonathan Hardwick <[email-masked]>; [email-masked]; Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Dear All,

This is to answer on implantation row, apologies for the delayed response,  YES we do have our PCEP solutions deployed in mixed SR/RSVP-TE environments.

I am afraid any non-backward compatible changes will break our solution. So hope we choose a backward compatible solution.

Regards,

Mahendra (Huawei Tech India Pvt Ltd)

From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Sighing slightly:-)

If, as may be the case, there is a demand to make this work either as currently specified or to be seamlessly interoperable with what is already specified then so be it. Let's make that as a conscious decision.

However, I think that using 7120 as an "excuse" is a bad idea. What 7120 is saying is that the allocated code point must show some stability in meaning from the point of early allocation on to RFC (just as it would need to if the RFC was revised). But that is not saying that, upon noticing that we are a herd of lemmings rushing towards the cliff we must say "We have always rushed towards the cliff. Our parents rushed towards the cliff. We must continue even if it means we plunge to our deaths."

Of course, nothing so dramatic, but...

If the current specification works well - stay with it.

If the current specification works but is clumsy - tweak it in a backward compatible way

If the current specification is broken in a minor way - fix it in a backward compatible way

If the current specification is more seriously broken - burn a new code point to fix it

In my earlier emails I was only speculating on "how I would have done this if starting from scratch." Obviously (?) I should have participated in WG discussions much earlier in the cycle, and as a result my opinion really only counts if either:

- the current specification is more seriously broken

or

- there is no WG desire to stick close to the current specification.

Clearly, although people who implement against I-Ds are doing so at their own risk, we should not unnecessarily burden early implementations with changes just for the sake of change. There is a sliding scale of "better ways to do things" that incorporates "it's a bit messy," "it will be easier to maintain and extend," all the way up to "it's broken." The WG will want to work out where we are on that scale and weigh it against the cost and inconvenience of change. Shipping in software may be one measure. Deployed and in use is another measure.

Cheers,

Adrian

From: Julien Meuric [mailto:[email-masked]]
Sent: 25 July 2017 09:31
To: Jonathan Hardwick; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Hi,

I agree that capability bitmap with optional capability-specific sub-TLVs would be the way to go from scratch. However the SR-PCE-CAPABILITY already has an early allocated codepoint, and RFC 7120 says that "if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable."
As a result, it seems to me that adding this new format may require that the I-D keeps documenting an optional SR-PCE-CAPABILITY TLV for legacy reasons.

Cheers,

Julien

Jul. 25, 2017 - [email-masked]<mailto:[email-masked]>:

   I agree that allowing optional sub-TLVs is a good thing.  However, this strongly suggests that SR-PCE-CAPABILITY should become a sub-TLV, which is a non-backwards compatible change.  So, we are back to my original question.

   Implementers – any views?

   Cheers

   Jon

   From: Adrian Farrel [mailto:[email-masked]]
   Sent: 24 July 2017 19:51

   Yes to that, Jon. But what happens when the next thing comes along?

   Since sub-TLVs can be present, I would suggest to use a Setup-Type TLV with a bit map as I previously described in my email, and add optional sub-TLVs dependent on the bits that are set.

   Isn't that the best of both worlds?

   Adrian

   From: Jonathan Hardwick [mailto:[email-masked]]
   Sent: 24 July 2017 09:15

   Adrian,

   The SR-PCE-CAPABILITY TLV is more than just a Boolean value - it also contains information about the maximum SID depth.  However, I like your idea and I think that it gives us a better way to do this without breaking backwards compatibility with existing SR implementations.

   Suppose we introduce a setup-type TLV into the OPEN object as you propose, and assign a bit to each setup type.

   If the TLV is absent, then RSVP-TE is supported.

   If the TLV is absent and the SR-PCE-CAPABILITY TLV is present, then RSVP-TE and SR are supported.  This retains backwards compatibility with existing SR implementations.

   If the TLV is present, then the bits indicate which setup types are supported.

   We would modify the LSP setup type draft to say that implementations supporting path setup types other than RSVP-TE SHOULD include the setup-type TLV.

   It’s not exactly beautiful, but it’s not as ugly as RSVP-TE-NON-SUPPORT.

   Cheers

   Jon

   From: Adrian Farrel [mailto:[email-masked]]
   Sent: 21 July 2017 19:55

   Well, personally, if I was designing this, I would not a whole TLV for each bit flag!

   I would have a Setup-Type TLV.

   If that TLV is absent, RSVP-TE is supported.

   If the TLV is present, each bit means that a different setup type is supported.

   That means...

   Legacy nodes don't include the TLV and are assumed to support RSVP-TE

   Legacy nodes that receive the TLV don't know what it means and so object to the Open (leaving a new node to re-Open for RSVP-TE only).

   New nodes include the TLV and so indicate explicitly what they support.

   I know it is late for that type of change, so how we proceed might depend on what implementations have done already.

   Adrian

   From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
   Sent: 21 July 2017 16:07

   Dear PCE-ers

   I don’t want to distract from the SDN topic too much, but we have an important decision to make about draft-ietf-pce-lsp-setup-type.

   The shepherd review raised an issue that there is no way for a PCEP speaker to indicate that it can’t (or won’t) support RSVP-TE as a path setup type.  It is entirely plausible that a node might not support RSVP-TE, or else have it disabled, for example in an SR-only network.

   We think that draft-ietf-pce-lsp-setup-type should be changed to allow a speaker to declare that they do or don’t have support for RSVP-TE paths.  There are two proposals.

   1.      Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a (new) RSVP-TE-CAPABILITY TLV in their OPEN object.  If this TLV if missing, but some other CAPABILITY TLV is present (such as SR-CAPABILITY) then it means that the speaker does not support RSVP-TE as a path setup type.

   2.      Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a (new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON’T support RSVP-TE.  If this TLV is omitted, it will be assumed that they do support RSVP-TE.

   The problem with (1) is that it is not backwards compatible.  Any existing SR implementation which also supports RSVP will not currently send this new capability.  So, if we make change (1) then forwards-level implementations will incorrectly conclude that such backwards-level implementations do not support RSVP-TE.

   The problem with (2) is that it is ugly, and in my opinion we should only do something ugly with a new protocol extension if we simply can’t avoid doing it.

   And so the question: are there any *deployments* of PCEP in a mixed SR/RSVP-TE environment that would be broken if we made change (1)?

   Thanks

   Jon

---

From: <[email-masked]>
Date: Mon, 20 Nov 2017 15:32:26 +0000

Hi Jon,

Thanks for the update.
One comment regarding this paragraph:
"If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
   speaker MUST infer that the peer supports path setup using at least
   RSVP-TE.  The PCEP speaker MAY also infer that the peer supports
   other path setup types, but the means of inference are outside the
   scope of this document."

Why not enforcing here ? I mean if a PCEP speaker uses a PST that was not advertised in the capability TLV, the PST is rejected by a PCError.
During the OPEN message, peers may agree on the PST to be used on the session based on the common subset.

What's your opinion on that ?

Brgds,

Stephane

-----Original Message-----
From: Jonathan Hardwick [mailto:[email-masked]] 
Sent: Monday, November 20, 2017 16:07
To: [email-masked]
Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS
Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Dear PCE WG

Best regards
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 20 November 2017 14:59
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Abstract:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 21 Nov 2017 08:27:58 +0000

Hi Stephane

Many thanks for the comment.  This text is a compromise to accommodate implementations of the previous version of the draft that have already been deployed.  Those implementations do not send PATH-SETUP-TYPE-CAPABILITY in the OPEN.  Instead, they send PCEP-SR-CAPABILITY.  Hence, to interoperate with those versions, a new implementation can use the presence of PCEP-SR-CAPABILITY to infer support of SR, rather than PATH-SETUP-TYPE-CAPABILITY.  In other words, this is for backwards compatibility.  It is discussed explicitly in the new version of draft-ietf-pce-segment-routing.

If you think the wording below can be improved for clarity, then please let me know!

Cheers
Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 20 November 2017 15:32
To: Jonathan Hardwick <[email-masked]>; [email-masked]
Cc: MEURIC Julien IMT/OLN <[email-masked]>
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Hi Jon,

Thanks for the update.

Brgds,

Stephane

-----Original Message-----
From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Monday, November 20, 2017 16:07
To: [email-masked]
Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS
Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Dear PCE WG

Best regards
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 20 November 2017 14:59
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Abstract:

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 21 Nov 2017 12:47:26 +0000

Sounds reasonable.

Thanks

-----Original Message-----
From: Jonathan Hardwick [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Cc: MEURIC Julien IMT/OLN
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Hi Stephane

Cheers
Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 20 November 2017 15:32
To: Jonathan Hardwick <[email-masked]>; [email-masked]
Cc: MEURIC Julien IMT/OLN <[email-masked]>
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Hi Jon,

Thanks for the update.

Brgds,

Stephane

-----Original Message-----
From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Monday, November 20, 2017 16:07
To: [email-masked]
Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS
Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Dear PCE WG

Best regards
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 20 November 2017 14:59
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Abstract: