Re: [Pce] RtgDir review: draft-ietf-pce-lsp-control-request-06.txt

[Mahendra Singh Negi]

Hi Tomonori,

Many thanks for your review. New version addresses the comments:

New Version:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-control-request-07

Diff with previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-07


Regards,
Mahendra

-Original Message-
From: Tomonori Takeda  
Sent: Monday, July 15, 2019 9:38 PM
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf-pce-lsp-control-request@ietf.org; 
pce@ietf.org
Subject: RtgDir review: draft-ietf-pce-lsp-control-request-06.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=EY53_4FU97aSiZY1AQpXTblgh2QhRlBT4hCaV9T8nEk&s=i4tooGNHNlmKvITJy6x1OpuH-NBr6L-eLQzcPF6KWBg&e=

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

  Document: draft-ietf-pce-lsp-control-request-06.txt
  Reviewer: Tomonori Takeda
  Review Date: July 16th, 2019
  IETF LC End Date: Not known
  Intended Status: Standards Track

Summary: 
This document is basically ready for publication, but has nits that should be 
considered prior to publication.

Comments:
This document specifies a PCEP extension by which a PCE can request control of 
LSP(s) from PCC(s) over the stateful PCEP sessions.
The procotol extension is simple, and its operation is well documented, 
including operation with PCCs that do not support the protocol extension 
specified in this document.

Major Issues:
None

Minor Issues:
None

Nits:
1) In Section 2, it states terminologies. Since these terminologies are already 
defined in other documents, I would suggest to add references.

2) In Section 8.1, it says:
"Further, the operator MAY be to be allowed "

It should be:
"Further, the operator MAY be allowed "


Thanks,
Tomonori Takeda

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Rtgdir last call review of draft-ietf-pce-stateful-path-protection-07

[Mahendra Singh Negi]

Hi Ines,

Many thanks for your review. If you please see inline [MN] for your 
questions/comments.

Regards,
Mahendra


-Original Message-
From: Ines Robles via Datatracker  
Sent: Tuesday, July 09, 2019 9:36 AM
To: rtg-...@ietf.org
Cc: draft-ietf-pce-stateful-path-protection@ietf.org; pce@ietf.org; 
i...@ietf.org
Subject: Rtgdir last call review of draft-ietf-pce-stateful-path-protection-07

Reviewer: Ines Robles
Review result: Ready

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see 
​https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=OfH7jqq3ZeA-wTebRlEpsyIMH15hY5NeZNI8AnstJzY&s=SHbxX7UldX-WPWAR_ar5R2SzCgNY4hbVoCqrXP8GYAU&e=

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-pce-stateful-path-protection-07.txt
Reviewer: Ines Robes
Review Date: 09-07-2019
IETF LC End Date: --
Intended Status: Standards Track

Summary:

I believe the draft is technically good. This document is well written.

This document specifies a stateful PCEP extension to associate two or more LSPs 
for the purpose of setting up path protection.

I have some minor questions.

Major Issues: No major issues found.

Minor Issues: No minor issues found.

Nits: from the tool ->   Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==),
1 comment (--).
[MN] We will fix this in new version.

Comments/Questions:

1- about "..associate one working LSP with one or more protection LSPs..." --> 
Is there a limit of numbers of protection LSPs to be associated with one 
working LSP?
[MN] This limit depends on the local configuration and standards (including 
RSVP-TE protection) do not restrict the same.

2- About Table 1: PPAG TLV, the name of the flag "S - STANDBY" should be 
"Secondary" (S) as per Figure 1?
[MN] We will fix this in new version.

Thank you for this document,

Ines.


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE WG Adoption poll for draft-leedhody-pce-vn-association

[Mahendra Singh Negi]

Yes/Support

Thanks,
Mahendra

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 14 July 2019 18:30
To: pce@ietf.org
Cc: draft-leedhody-pce-vn-associat...@ietf.org
Subject: [Pce] PCE WG Adoption poll for draft-leedhody-pce-vn-association

Hi WG,

He authors of draft-leedhody-pce-vn-association have been asking for adoption 
and...

- the base PCEP association extensions seem to be stable and advancing
- I did an early review and the authors span a new version

So, this starts an adoption poll for the draft. Because IETF-105 is imminent 
and you all have lots to do and read, we'll make this a three week poll ending 
on 4th August.

Please send your comments of support or antipathy.

In either case, please indicate whether or not you have read the draft, and if 
you support it, please say whether or not you propose to and even possibly 
implement the draft.

Many thanks,
Adrian (for the 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

Re: [Pce] Shepherd Review of draft-ietf-pce-association-diversity-07

[Mahendra Singh Negi]

Hi Julien,

Many thanks for the detailed review comments, we have fixed all the comments 
and new version is posted, please find the new-version and version-diff links 
below:

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-08

To answer your question:
Complementary question: why an optional behavior (SHOULD) instead of mandatory 
(MUST)? ->   Yes MUST is appropriate and updated in the new version.


Thanks,
Mahendra

-Original Message-
From: julien.meu...@orange.com [mailto:julien.meu...@orange.com] 
Sent: 28 June 2019 20:53
To: draft-ietf-pce-association-divers...@ietf.org
Cc: pce@ietf.org
Subject: Shepherd Review of draft-ietf-pce-association-diversity-07

Hi authors,

Please find below my detailed comments on draft-ietf-pce-association-diversity. 
I originally started to review -06. Thanks for posting -07 after Dhruv's 
comments, as it addressed some on mine as well.

The main technical concern lies in section 4.6, in case no solution is found by 
the PCE. Section 4.3, about SVEC, relies on PCRep with NO-PATH, which is 
consistent with existing PCEP specification. IMHO, section 4.6 is confusing and 
incomplete. What about the following?

OLD
   [...] the PCE SHOULD
   reply with a PCUpd message containing an empty ERO.  In addition to
   the empty ERO Object, the PCE MAY add the NO-PATH-VECTOR TLV [...]

NEW
    [...] the PCE MUST
   reply to a request (PCEReq) with a PCRep message containing a NO-PATH
   object. In case of network event leading to an impossible strict
   disjointness, the PCE SHOULD send a PCUpd message containing an empty
   ERO to the corresponding PCCs. In addition to the NO-PATH or the
   empty ERO object, the PCE MAY add the NO-PATH-VECTOR TLV [...]

Complementary question: why an optional behavior (SHOULD) instead of mandatory 
(MUST)?


Nits:
--
Global and usual nit: the flag name. The I-D has a collection of X 
flag/X-flag/X-Flag/flag X/etc that needs consistency. Many PCEP documents use 
"X flag".
--
Title
---
- s/communication Protocol (PCEP) extension for signaling LSP diversity 
constraint/Communication Protocol (PCEP) Extension for LSP Diversity Constraint 
Signaling/
--
Abstract
---
- s/Communication Protocol/communication Protocol/
- s/knows that LSPs in the same group/knows that the LSPs in the same group/
- s/needs to/need to/
--
2. Terminology
---
- s/Communication Protocol/communication Protocol/
--
3.  Motivation
---
- s/above, consider that/above, let us consider that/
- s/difficult. Whereas, computation/difficult, whereas computation/
- s/These messages uses/These messages use/
- s/the disjoint path computation/a disjoint path computation/
- s/disjoint group-ids/disjoint group IDs/
- s/should allow to overcome/allows to overcome/
- s/association source could/the association source could/
--
4. Protocol extension
---
- s/Protocol extension/Protocol Extension/
- s/Association group/Association Group/
- s/TLVs - Global Association Source or Extended Association ID are 
included/TLVs - Global Association Source or Extended Association ID - are 
included/
- s/to uniquely identifying/to uniquely identify/
- s/Association object -/Association object:/
- s/[I-D.ietf-pce-association-group]
specify/[I-D.ietf-pce-association-group] specifies/
- s/in the PCEP messages/in PCEP messages/
- s/Refer [I-D.ietf-pce-association-group]/Refer to 
[I-D.ietf-pce-association-group]/
- s/more LSPs. But a PCE/more LSPs, but a PCE/
- s/in how many LSPs/in the number of LSPs/
- s/vendor specific behavioral information/vendor-specific behavioral 
information/
- OLD
 When unset, PCE is allowed to relax disjointness
 by using either applying a requested objective function or any
 other behavior if no objective function is requested (e.g.:
 using a lower disjoint type (link instead of node) or relaxing
 disjointness constraint fully)
  NEW
 When unset, the PCE is allowed to relax disjointness
 by either applying a requested objective function (cf. section
 4.4 below) or using any other behavior if no objective function
 is requested (e.g. using a lower disjoint type (link instead of
 node) or fully relaxing disjointness constraint).

- s/The flags  L, N, and S/The L, N and S flags/
- s/The flag P/The P flag/
- s/the flag T/the T flag/
- s/both SVEC and ASSOCIATION object/both SVEC and ASSOCIATION objects/
- s/in SVEC object/in the SVEC object/
- s/with NO-PATH object/with a NO-PATH object/
- s/Disjointness objective functions/Disjointness Objective Functions/
- s/The PCEP OF-List TLV allow/Whereas the PCEP OF-List TLV allows/
- s/Incompatible OF codes/Incompatible OF code/
- s/listed below -/listed below:/
- The last example at the end of section 4.4 shows that the specification 
doesn't prohibit redundant constraints. I would be nice to add a sentence 

Re: [Pce] Shepherd Review of draft-ietf-pce-lsp-control-request-05

[Mahendra Singh Negi]

Hi Hari,

Thanks for the review, comments are fixed and new version is uploaded.


Htmlized:  https://tools.ietf.org/html/draft-ietf-pce-lsp-control-request-06

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-06


Regards,
Mahendra


From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Tuesday, June 25, 2019 7:09 AM
To: pce@ietf.org; ar2...@att.com; ag6...@att.com; jakar...@cisco.com; Siva 
Sivabalan (msiva) ; Mahendra Singh Negi 

Subject: Re: Shepherd Review of draft-ietf-pce-lsp-control-request-05

+ Authors.

On Mon, Jun 24, 2019 at 6:31 PM Hariharan Ananthakrishnan 
mailto:h...@netflix.com>> wrote:
---
Header:
In general should we use "Stateful PCE" or "stateful PCE" ? I see in RFC 8231 
we use "Stateful PCE"

OLD:
Ability for a stateful Path Computation Element (PCE)

NEW:
Ability for a Stateful Path Computation Element (PCE)


Abstract:
OLD:
A stateful Path Computation Element (PCE)

NEW:
A Stateful Path Computation Element (PCE)

-
Section 4:
To make it more clear, it would be good to state that C and D flags are 
mutually exclusive in PCUpd message.

OLD:

The PCE SHOULD NOT send control request for LSP which is already delegated to 
the

PCE, i.e. if the D flag is set in the PCUpd message, then C flag SHOULD NOT be 
set.



NEW:

The D Flag and C Flag are mutually exclusive in PCUpd message. The PCE SHOULD 
NOT

send control request for LSP which is already delegated to thePCE, i.e. if

the D flag is set in the PCUpd message, then C flag SHOULD NOT be set.



--

I dont see Adrian's suggestion being implemented in Section 8 in the latest 
draft. It would be good to have this apart from the Security Considerations.



SUGGESTED:

Not sure whether it belongs in 8.1 or 8.3 or 7...

The Security considerations section suggests dropping delegation

requests if the PCC is swamped. I think you need to configure the

threshold for swamping, and to recommend that the issue be logged.

IMPLEMENTED:

-

Thanks,

Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

[Mahendra Singh Negi]

Hi Adrian,

We have posted a new update handling the comments from you and Haomian.

I-D: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-control-request-05

Snipping to

---
Section 4

  If the LSP(s) is/are already delegated to the PCE making the request, the PCC 
ignores the C Flag.
Doesn't this over-complicate things? Why not have the PCE always respond with D 
set or clear depending on whether it wants to have delegated? That way, a PCE 
that drops context (i.e., does it have control or not?) is able to regain 
context.

Or are you trying to prevent a thrash where...
PCE---> C flag
D flag <--- PCC
PCE---> D flag and C flag
D flag <--- PCC
PCE---> D flag and C flag etc.

I see you don't give the PCE advice about not setting the C flag for LSP, it 
already has delegate control over. That would lead to...

PCE---> C flag
D flag <--- PCC
PCE---> D flag

--
First, we rephrased this for clarity -

  The PCE SHOULD
  NOT send control request for LSP which is already delegated to the
  PCE, i.e. if the D flag is set in the PCUpd message, then C flag
  SHOULD NOT be set. If a PCC receives a PCUpd message with D flag set
  in the LSP object (i.e. LSP is already delegated) and the C flag is
  also set (i.e. PCE is making a control request), the PCC MUST ignore
  the C Flag.

Second, for a delegated LSP, PCE always sends PCUpd with the D flag set unless 
it wants revocation of the delegation. Both D and C flag in PCUpd message 
should not be set together. We wanted to have a new flag to independently 
indicate 'LSP control request' and not overload the existing flag.

---
Section 4
  It should be noted that a legacy implementation of PCC, that does not
  understand the C flag in PCUpd message, would simply ignore the flag (and the 
request to grant control over the LSP). At the same time it would trigger the 
error condition as specified in [RFC8231] (a PCErr with Error-type=19 (Invalid 
Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated 
LSP)).

  I looked through 8231 and 8281 and I don't find a discussion of handling 
unknown flags. What is missing in 7.2 of 8231 is "Unassigned flags MUST be set 
to zero on transmission, and unknown flags MUST be ignored on receipt." I think 
that without that addition to 8231, your text doesn't work.

---
We rephrased this to say -

  It should be noted that a legacy implementation of PCC, that does not
  support this extension would trigger the error condition as specified
  in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
  error-value 1 (Attempted LSP Update Request for a non-delegated LSP))
  as the D flag would be unset in this update request. Further, in
  case of PLSP-ID of 0, the error condition as specified in [RFC8231]
  (a PCErr with Error-type=19 (Invalid Operation) and error-value 3
  (Attempted LSP Update Request for an LSP identified by an unknown
  PSP-ID)) would be triggered.

So this I-D can be progressed independently, while the WG decides how to handle 
the missing statement in RFC 8231.

Thanks for your review,
Mahendra

--
Mahendra Singh Negi Mahendra
Mobile: +91-7204000290
Email: mahendrasi...@huawei.com<mailto:mahendrasi...@huawei.com>
From:Adrian Farrel 
To:'Dhruv Dhody' ;pce@ietf.org 
Cc:draft-ietf-pce-lsp-control-requ...@ietf.org 

Date:2019-06-17 21:17:02
Subject:RE: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi,

Picking up on Dhruv's request, I did a quick review as co-chair. It's
after the end of WG last call, but life is full of little
disappointments.

Enjoy!

Adrian

===

Please reduce to five or fewer authors on the front page or provide the
shepherd with a good reason why not.

---

Please expand "LSP" in the document title.

---

I found the Abstract a bit hard to work through. How about...

   A stateful Path Computation Element (PCE) retains information about
   the placement of MPLS-TE Label Switched Paths (LSPs). When a PCE has
   stateful control over LSPs it may send indications to LSP head-ends
   to modify the attributes (especially the paths) of the LSPs. A Path
   Computation Client (PCC) has set up LSPs under local
   configuration may delegate control of those LSPs to a stateful PCE.

   There are use-cases in which a stateful PCE may wish to obtain
   control of locally configured LSPs of which it is aware but that have
   not been delegated to the PCE.

   This document describes an extension to the Path Computation Element
   communication Protocol (PCEP) to enable a PCE to make such requests.

---

Please expand abbreviations on first use in the body of the document
(even if they have already been used in the Abstract). I found:
- PCEP
- TE LSP
- PCC
- PCE

---

You need to move the block of text "Requirements Languag

Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

[Mahendra Singh Negi]

Support, this is an important extension in Redundant PCE deployments motivated 
by real use cases.

Thanks,
Mahendra

-Original Message-
From: Dhruv Dhody [mailto:dhruv.i...@gmail.com] 
Sent: 18 June 2019 10:18
To: Farrel Adrian 
Cc: pce@ietf.org; draft-ietf-pce-lsp-control-requ...@ietf.org
Subject: Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

On Mon, Jun 17, 2019 at 9:16 PM Adrian Farrel  wrote:
>
> Hi,
>
> Picking up on Dhruv's request, I did a quick review as co-chair. It's 
> after the end of WG last call, but life is full of little 
> disappointments.
>

Thanks Adrian for your comments, they are still within the WG LC period. The WG 
LC ends tomorrow i.e. 19th June 2019!

Regards,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll on draft-ietf-pce-lsp-control-request-04

[Mahendra Singh Negi]

Hi,



I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Regards,
Mahendra

From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: 05 June 2019 06:26
To: ar2...@att.com; ag6...@att.com; cy0...@att.com; jakar...@cisco.com; 
ms...@cisco.com; jdpar...@cisco.com; Mahendra Singh Negi 

Cc: pce@ietf.org
Subject: IPR poll on draft-ietf-pce-lsp-control-request-04


Hi Authors,



In preparation for Working Group last call on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.



Please respond (copying the mailing list) to say one of:



I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd Review of draft-ietf-pce-stateful-path-protection-05

[Mahendra Singh Negi]

Hi Julien,

All the outstanding issues are resolved except "number of authors". 
Please find the new draft-version and version-diff links below:
.
Version-06:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-path-protection-06

Version Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-path-protection-06


Regards,
Mahendra

-Original Message-
From: julien.meu...@orange.com [mailto:julien.meu...@orange.com] 
Sent: 06 June 2019 21:45
To: draft-ietf-pce-stateful-path-protect...@ietf.org
Cc: pce@ietf.org
Subject: Shepherd Review of draft-ietf-pce-stateful-path-protection-05

Hi authors of draft-ietf-pce-stateful-path-protection,

Thank you for the update following Dhruv's comments.

To summarize, I mainly have 2 issues to point out:
- The I-D depends on RFC 4872 and reuses the P, S and PT flags (which is 
great); however, the side effect of redefining (why?) the expansion of the S 
bit (Standby vs. Secondary) leads to a common behavior with an opposite flag 
value between the specifications! As suggested by the reference in section 
3.2., we expect alignment here.
- In sections 4.5 and 6.3, the Error-Type for associations has shifted from 26 
(early allocated by IANA) to 29 (from nowhere); this mistake makes me wonder 
about the implementation status of the I-D.

Then, looking at the details.
--
Header
---
- As pointed out by Dhruv, we still miss a valid justification for the 7 names 
listed on the front page, all the more as you exceed the recommended threshold 
by 2.
--
Abstract
---
- s/A stateful Path Computation Element/An active stateful Path Computation 
Element/
- s/for a stateful PCE/for an active stateful PCE/
--
1. Introduction
---
- s/the PCE Initiated mode/the PCE-Initiated mode/
--
3. PCEP Extensions
---
- s/[I-D.ietf-pce-association-group]
specify/[I-D.ietf-pce-association-group] specifies/
- s/The length field is 16 bit-long and has/The length field (16 bits) has/
- s/Following flags are currently defined -/The following flags are currently 
defined:/
- s/Following values are/The following values are/
- s/i.e. P bit is unset/i.e. as if P bit is unset/
--
4. Operation
---
- s/[RFC8231], the the association group/[RFC8231]. The association group/
- s/to a LSP/to an LSP/
- s/includes PPAG./includes PPAGs./
- s/PCC Initiated/PCC-Initiated/
- s/remove on or more/remove one or more/
- s/PCC would report/PCC reports/
- s/via Path Computation Report(PCRpt) message/via the Path Computation Report 
(PCRpt) message/
- s/LSPs to a stateful PCE/LSPs to an active PCE/
- s/where PCE would/where the PCE would/
- s/via Path Computation Update(PCUpd) message/via the Path Computation Update 
(PCUpd) message/
- s/to PCC via PCUpd message/to the PCC via the PCUpd message/
- s/refer [I-D.litkowski-pce-state-sync]/refer to 
[I-D.litkowski-pce-state-sync]/
- s/PCE Initiated LSPs/PCE-Initiated LSPs/
- s/both the PCE and PCC/both the PCE and the PCC/
- s/uses PCUpd or Path Computation Initiate(PCInitiate) message/uses the PCUpd 
or the Path Computation Initiate (PCInitiate) messages/
- s/at PCC/at the PCC/
- s/Same procedure/The same procedure/
- s/with Error-Type= 29/with Error-Type 26/
- s/and Error-Value = TBD3/and Error-Value TBD3/
- s/1:N (with N=1),/1:N with N=1,/
- s/and protection LSP/and one protection LSP
- s/a PCEP Speaker/a PCEP speaker/
- s/with Error-Type=29/with Error-Type 26/
- s/and Error-Value = TBD4/and Error-Value TBD4/
- s/continue to apply/continues to apply/
--
5. Other considerations
---
- s/Other considerations/Other Considerations/
- s/LSPs.The/LSPs. The/
- s/for the the protection LSP/for the protection LSP/
- s/both ASSOCIATION object/both ASSOCIATION objects/
- s/and disjoint association/and the disjoint association/
--
6. IANA considerations
---
- s/IANA considerations/IANA Considerations/
- s/Action [RFC8126]. Each bit should be tracked with the following 
qualities:/Action [RFC8126]./  [The sentence appears twice.]
- s/new Error-Type and Error-Value/new Error-Value/
- The table in section 6.3 is confusing. A way to clarify would be to
say: "allocate new error values for Error-Type 26 within [...]" and change the 
1st column into "Error-Value".
--


Cheers,

Julien


_

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 

Re: [Pce] IPR poll on draft-ietf-pce-association-diversity

[Mahendra Singh Negi]

I am aware of IPR applicable to this draft, and it has already been disclosed 
to the IETF.

Thanks,
Mahendra
From:Hariharan Ananthakrishnan 
To:draft-ietf-pce-association-divers...@ietf.org 

Cc:pce@ietf.org 
Date:2019-04-10 08:27:41
Subject:IPR poll on draft-ietf-pce-association-diversity


Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection

[Mahendra Singh Negi]

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Thanks,
Mahendra
From:Hariharan Ananthakrishnan 
To:draft-ietf-pce-stateful-path-protect...@ietf.org 

Cc:pce@ietf.org 
Date:2019-04-10 08:27:46
Subject:IPR poll on draft-ietf-pce-stateful-path-protection


Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-02.txt

[Mahendra Singh Negi]

Hi All,

Thanks for the valuable suggestions/comments. We have fixed all the comments 
received, difference link goes below: 
Diff: 
https://www.ietf.org/rfcdiff?url1=draft-ietf-pce-segment-routing-ipv6-00&url2=draft-ietf-pce-segment-routing-ipv6-02

Please do reach out to us in case you have comments/suggestions.

Regards,
Mahendra

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 08 April 2019 09:56
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-02.txt


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   : PCEP Extensions for Segment Routing leveraging the 
IPv6 data plane
Authors     : Mahendra Singh Negi
  Cheng Li
  Siva Sivabalan
  Prejeeth Kaladharan
  Yongqing Zhu
Filename: draft-ietf-pce-segment-routing-ipv6-02.txt
Pages   : 22
Date: 2019-04-07

Abstract:
   The Source Packet Routing in Networking (SPRING) architecture
   describes how Segment Routing (SR) can be used to steer packets
   through an IPv6 or MPLS network using the source routing paradigm.
   SR enables any head-end node to select any path without relying on a
   hop-by-hop signaling technique (e.g., LDP or RSVP-TE).

   It depends only on "segments" that are advertised by Link- State
   IGPs.  A Segment Routed Path can be derived from a variety of
   mechanisms, including an IGP Shortest Path Tree (SPT), explicit
   configuration, or a Path Computation Element (PCE).

   Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE
   should be able to compute SR-Path for both MPLS and IPv6 forwarding
   plane.  This document describes the extensions required for SR
   support for IPv6 data plane in Path Computation Element communication
   Protocol (PCEP).  The PCEP extension and mechanism to support SR-MPLS
   is described in [I-D.ietf-pce-segment-routing].  This document
   extends it to support SRv6 (SR over IPv6).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-segment-routing-ipv6-02
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-ipv6-02


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/

___
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

Re: [Pce] Building the PCE WG Agenda for the IETF 104

[Mahendra Singh Negi]

Hi Chairs,

We would like to request  for a slot to discuss updates on PCECC drafts. Please 
note I'll be remote.

- the draft(s) you want to discuss:
draft-ietf-pce-pcep-extension-for-pce-controller 
   draft-zhao-pce-pcep-extension-pce-controller-sr

- the expected presenter name:
   Mahendra Negi

- the requested duration, including question time as part of the slot: 
  15 minutes

- the reason why you want to be on the agenda; What do you want to achieve? Why 
is a presentation necessary to achieve it?
To introduce updates on these drafts and seek WG opinion. We do seek WG  
adoption for draft-zhao-pce-pcep-extension-pce-controller-sr.

Regards,
Mahendra

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Monday, February 25, 2019 10:58 AM
To: pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] Building the PCE WG Agenda for the IETF 104

Hi WG,

The PCE WG session in Prague is tentatively scheduled for Thursday Morning 
session I [1]. If you need some face-to-face time to progress some work, please 
send a slot request to the chairs by Monday March 11th including:
- the draft(s) you want to discuss,
- the expected presenter name,
- the requested duration, including question time as part of the slot,
- the reason why you want to be on the agenda; What do you want to achieve? Why 
is a presentation necessary to achieve it?

Please note - Asking for a slot does not mean you will get one. We will be 
prioritising moving WG work first as well as drafts that were discussed on the 
mailing list. Please make sure to introduce your new draft or summarise an 
update in the mailing list. The last date to submit drafts is also March 11th 
[2].

Thanks!
PCE Chairs

[1] https://datatracker.ietf.org/meeting/104/agenda.html
[2] https://datatracker.ietf.org/meeting/important-dates/

___
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

Re: [Pce] IPR Check on draft-negi-pce-segment-routing-ipv6

[Mahendra Singh Negi]

Hi Dhruv,

Yes, I'm aware of IPR that applies to this draft and It has been disclosed in 
compliance with IETF IPR rules.

Regards,
Mahendra


-Original Message-
From: Dhruv Dhody [mailto:dhruv.i...@gmail.com] 
Sent: 22 February 2019 12:15
To: Mahendra Singh Negi ; Chengli (Cheng Li) 
; Siva Sivabalan (msiva) ; 
preje...@rtbrick.com
Cc: pce@ietf.org
Subject: IPR Check on draft-negi-pce-segment-routing-ipv6

Authors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropriate.

If you are listed as a document author please answer the above by responding to 
this email regardless of whether or not you are aware of any relevant IPR. This 
document will not advance to the next stage until a response has been received 
from each author.

If you are on the WG email list or attend WG meetings but are not listed as an 
author, we remind you of your obligations under the IETF IPR rules which 
encourages you to notify the IETF if you are aware of IPR of others on an IETF 
contribution, or to refrain from participating in any contribution or 
discussion related to your undisclosed IPR. For more information, please see 
the RFCs listed above and 
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
PCE WG Chairs

PS. Please include all listed in the headers of this message in your response.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption Call for draft-negi-pce-segment-routing-ipv6

[Mahendra Singh Negi]

Support as co-author.  

This document defines required PCEP extensions to support SRv6 path 
provisioning by PCE (Controller), and is a necessary building block of SRv6 
control plane.

Regards,
Mahendra

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: 22 February 2019 12:17
To: pce@ietf.org
Subject: [Pce] WG Adoption Call for draft-negi-pce-segment-routing-ipv6

Hi WG,

Please read & review draft-negi-pce-segment-routing-ipv6-04 [1] and send your 
comments to the mailing list.

Should this draft be adopted by the PCE WG? Please state your reasons
- Why / why not?

What needs to be fixed before or after adoption?

Are you willing to work on this draft? Do you plan to implement it?

This poll will run until 8th March.

Thanks,
PCE Chairs

[1] 
https://datatracker.ietf.org/doc/draft-negi-pce-segment-routing-ipv6/?include_text=1

___
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

Re: [Pce] WG Last Call on draft-ietf-pce-applicability-actn

[Mahendra Singh Negi]

Hi Adrian,

I have read the document and support the publication.
To authors few references are missing in sections 1.1/1.1.2/1.1.3, in case not 
taken care.

Thanks,
Mahendra

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 08 February 2019 17:04
To: pce@ietf.org
Subject: [Pce] WG Last Call on draft-ietf-pce-applicability-actn

Hi WG,

draft-ietf-pce-applicability-actn seems to be ready to progress towards 
publication.

This email starts a two week working group last call (ends on 23rd February).

During this time, please read the draft and make comments for improvement.
If you then support its publication please let us know that you have read the 
draft and support it. If you have any concerns, please let us know and propose 
solutions.

Thanks,
Adrian

___
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

[Pce] Updated PCECC WG I-D and PCECC-SR I-D for review

[Mahendra Singh Negi]

Hi WG,



We have made an update to the PCECC WG I-D as well as to the PCECC-SR I-D.



I-D: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-01

Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-01



I-D: 
https://datatracker.ietf.org/doc/html/draft-zhao-pce-pcep-extension-pce-controller-sr-04

Diff: 
https://www.ietf.org/rfcdiff?url2=draft-zhao-pce-pcep-extension-pce-controller-sr-04



The changes are: -

- Authorship changes

- Support for PCC based allocation i.e. PCC controlled label space where the 
PCECC instruct PCC to allocate label/SID and report back to the PCECC.

- Support for Binding label/SID allocation via PCECC



Kindly review and provide comments!



Thanks,

Mahendra
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08

[Mahendra Singh Negi]

Yes/Support

Regards,
Mahendra

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 13 October 2018 20:17
To: pce@ietf.org
Cc: draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org
Subject: [Pce] WG adoption poll for 
draft-zhao-pce-pcep-extension-for-pce-controller-08

This is the start of a two week poll on making 
draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/

Please review the draft and send an email to the list indicating "yes/support" 
or "no/do not support".  If indicating no, please state your reasons.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

The poll ends on Friday, October 26.

Many thanks,

Jon and Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG adoption poll for draft-zhang-pce-resource-sharing-07

[Mahendra Singh Negi]

Yes/Support

Thanks,
Mahendra

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Zhenghaomian 
(Zhenghaomian, Optical &Microwave Technology Research Dept)
Sent: 25 September 2018 07:19
To: Jonathan Hardwick ; pce@ietf.org; 
draft-zhang-pce-resource-shar...@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] 答复: WG adoption poll for draft-zhang-pce-resource-sharing-07

Yes/Support.

Best wishes,
Haomian (as a co-author)

发件人: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
发送时间: 2018年9月21日 21:19
收件人: pce@ietf.org; 
draft-zhang-pce-resource-shar...@ietf.org
抄送: pce-cha...@ietf.org
主题: WG adoption poll for draft-zhang-pce-resource-sharing-07

Hi PCE WG!

This is the start of a two week poll on making 
draft-zhang-pce-resource-sharing-07 a PCE working group document.
https://datatracker.ietf.org/doc/draft-zhang-pce-resource-sharing/

Please review the draft and send an email to the list indicating “yes/support” 
or “no/do not support”.  If indicating no, please state your reasons.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

The poll ends on Friday, October 5.

Many thanks,

Jon and Julien


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG adoption poll for draft-ananthakrishnan-pce-stateful-path-protection-05

[Mahendra Singh Negi]

Yes/Support..

Regards,
Mahendra


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Lizhenbin
Sent: 29 March 2018 08:36
To: Jonathan Hardwick; pce@ietf.org; 
draft-ananthakrishnan-pce-stateful-path-protect...@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] 答复: WG adoption poll for 
draft-ananthakrishnan-pce-stateful-path-protection-05

Yes/support.


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Tuesday, March 27, 2018 13:10
To: pce@ietf.org; 
draft-ananthakrishnan-pce-stateful-path-protect...@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] WG adoption poll for 
draft-ananthakrishnan-pce-stateful-path-protection-05

Dear PCE WG

This is the start of a two week poll on making 
draft-ananthakrishnan-pce-stateful-path-protection-05 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-ananthakrishnan-pce-stateful-path-protection/

Please review the draft and send an email to the list indicating “yes/support” 
or “no/do not support”.  If indicating no, please state your reasons.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

The poll ends on Tuesday, April 10.

Many thanks,

Jon and Julien



_



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.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

[Mahendra Singh Negi]

Very much OK with that.
Thanks a lot.

Regards,
Mahendra (Huawei Tech India Pvt. Ltd.)
From:Jonathan Hardwick
To:Mahendra Singh Negi,adrian,'Julien Meuric',pce,Dhruv Dhody,
Cc:draft-ietf-pce-lsp-setup-type,draft-ietf-pce-segment-routing,
Date:2017-07-25 20:36:04
Subject:RE: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?

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:mahendrasi...@huawei.com]
Sent: 25 July 2017 13:12
To: adr...@olddog.co.uk; 'Julien Meuric' ; Jonathan 
Hardwick ; pce@ietf.org; Dhruv Dhody 

Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; 
draft-ietf-pce-segment-rout...@ietf.org
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:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; pce@ietf.org<mailto:pce@ietf.org>
Cc: 
draft-ietf-pce-lsp-setup-t...@ietf.org<mailto:draft-ietf-pce-lsp-setup-t...@ietf.org>;
 
draft-ietf-pce-segment-rout...@ietf.org<mailto:draft-ietf-pce-segment-rout...@ietf.org>
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:julien.meu...@orange.com]
Sent: 25 July 2017 09:31
To: Jonathan Hardwick; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 
pce@ietf.org<mailto:pce@ietf.org>
Cc: 
draft-ietf-pce-lsp-setup-t...@ietf.org<mailto:draft-ietf-pce-lsp-setup-t...@ietf.org>;
 
draft-ietf-pce-segment-rout...@ietf.org<mailto:draft-ietf-pce-segment-rout...@ietf.org>
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,

Jul

Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

[Mahendra Singh Negi]

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:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; pce@ietf.org
Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; 
draft-ietf-pce-segment-rout...@ietf.org
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:julien.meu...@orange.com]
Sent: 25 July 2017 09:31
To: Jonathan Hardwick; adr...@olddog.co.uk; 
pce@ietf.org
Cc: 
draft-ietf-pce-lsp-setup-t...@ietf.org;
 
draft-ietf-pce-segment-rout...@ietf.org
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 - 
jonathan.hardw...@metaswitch.com:
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:adr...@olddog.co.uk]
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:jonathan.hardw...@metaswitch.com]
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