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

From: Dhruv Dhody <[email-masked]>
Date: Tue, 4 Jun 2019 21:56:02 +0530

Hi WG,

This email starts a working group last call for
draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, till
19th June 2019.

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

Please indicate your support or concern for this draft.

If you are opposed to the progression of the draft, please articulate your
concern.

If you support, please indicate that you have read the latest version and
it is ready for publication. Further, explaining the importance of the work in
your opinion is appreciated.

As always, review comments and nits are most welcome. Silence on the list, not
so much :)

Thanks,
Dhruv, Julien, & Adrian

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 5 Jun 2019 09:37:30 +0400

Yes/support

Regards,
Jeff

> On Jun 4, 2019, at 20:26, Dhruv Dhody <[email-masked]> wrote:
> 
> Hi WG,
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Satish K <[email-masked]>
Date: Thu, 6 Jun 2019 12:32:45 +0530

Yes / Support.

Regards,
Satish.

---

From: "RAGHURAM, ASWATNARAYAN" <[email-masked]>
Date: Thu, 6 Jun 2019 12:40:26 +0000

Yes  -  I support.

A.Raghuram
Lead Member of Technical Staff
Network Infrastructure and Services
AT&T Services, Inc.
200 S. Laurel Av, Room C5-2Z01, Middletown, NJ 07748
O 732.420.2471 | [email-masked]

This communication may contain information that is privileged, or confidential. If you are not the intended recipient, please note  FYI that any dissemination, distribution or copying of this communication is strictly prohibited.  Anyone who receives this message in error should notify the sender immediately by telephone or by return e-mail and delete it from his or her computer. 

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Tuesday, June 4, 2019 12:26 PM
To: [email-masked]
Cc: Hariharan Ananthakrishnan <[email-masked]>; [email-masked]
Subject: WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

This email starts a working group last call for draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, till 19th June 2019.

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpce-2Dlsp-2Dcontrol-2Drequest_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_z_mFV0kkYNAqjNJjFwtfw&m=79aVj5RJPlov8P95ZHRZKSkdiLhZMCUXKsbIIToMYA4&s=JKUEs_jknr-DgXnE5VahQEyT8zje1HKGCMnhrxD7qyY&e=

If you are opposed to the progression of the draft, please articulate your concern.

If you support, please indicate that you have read the latest version and it is ready for publication. Further, explaining the importance of the work in your opinion is appreciated.

As always, review comments and nits are most welcome. Silence on the list, not so much :)

Thanks,
Dhruv, Julien, & Adrian

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Thu, 6 Jun 2019 12:44:06 +0000

Support.

This work is motivated by a real use-case.

Thanks,
Siva

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Tuesday, June 4, 2019 6:26 PM
To: [email-masked]
Cc: Hariharan Ananthakrishnan <[email-masked]>; [email-masked]
Subject: WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

Thanks,
Dhruv, Julien, & Adrian

---

From: "GODDARD, AL" <[email-masked]>
Date: Thu, 6 Jun 2019 13:07:42 +0000

Support.

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Tuesday, June 04, 2019 12:26 PM
To: [email-masked]
Cc: Hariharan Ananthakrishnan <[email-masked]>; [email-masked]
Subject: WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpce-2Dlsp-2Dcontrol-2Drequest_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=d5xX5v4DLVCj08VmgVGYbg&m=PMnM9_2l9GxhkpmqMat2JRRWhI2u3iVxV7yypnLIPYs&s=etb-Mgp2psrobRFMAMzX4gEDkqc6YPzC2BeY4OKwems&e=

Thanks,
Dhruv, Julien, & Adrian

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 17 Jun 2019 15:31:41 +0530

Hi WG,

The WG LC ends in 2 days. We would like to see some more responses before we
make the consensuses call. Please confirm if the document is ready to be sent
to the IESG. Detailed comments are always welcome!

Thanks!
Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Jun 2019 16:46:42 +0100

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 Language" down to 
after the Introduction. Probably create a Section 2.1 for it.

That is also consistent with it not being appropriate to use 
Requirements Language in the Introduction. (You have just one "MAY" 
which can safely be made lower case.)

---

Section 3

s/a R/an R/
s/LSP(s)/LSPs/

OLD
   The LSP is identified by the LSP object.
NEW   
   The LSPs are identified by the LSP object.
END
   
---

Section 3 has...

   [RFC8281] defines a R (LSP-REMOVE) flag.

This is true, but not very relevant. You don't mention the R flag 
anywhere else.

Maybe just delete this?

---

Section 4

OLD
   LSP(s) is/are
NEW
   LSPs are
END

s/[RFC8231] ./[RFC8231]./

---

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
LSPs it already has delegate control over. That would lead to...

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

---

Section 4

   In case multiple PCEs request control over an LSP, and if the PCC is
   willing to grant the control, the LSP MUST be delegated to only one
   PCE chosen by the PCC based on its local policy.

This might be clearer as...

   A PCC MUST NOT delegate an LSP to more than one PCE at any time.  If
   a PCE requests control of an LSP that has already been delegated by
   the PCC to another PCE, the PCE MAY ignore the request, or MAY revoke
   the delegation to the first PCE before delegating it to the second.
   This choice is a matter of local policy.

---

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.

---

Section 6

s/vectors/vector/

---

Section 7.1

It would be good if you could help IANA correctly identify the registry
you want actioned. I think this is...

   IANA maintains a registry called the "Path Computation Element
   Protocol (PCEP) Numbers" registry.  It contains a subregistry called
   the "SRP Object Flag Field" registry.

I note that the current registry reads...

   Value Description Reference
   0-30  Unassigned  [RFC8281]
    31   LSP-Remove  [RFC8281]

...so your proposed description for the c-bit is a bit lengthy.

---

Section 8.1

There is a further policy described in the document: that of deciding 
which of a pair of delegation requests to honour.

---

Not sure whether it belongs in 8.1 or 8.3...
The PCE that sends a delegation request and doesn't get a response "may
choose to retry requesting the control preferably using exponentially 
increasing timer." That implies a timer that should be configurable.

---

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.

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 17 June 2019 11:02
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

The WG LC ends in 2 days. We would like to see some more responses before we
make the consensuses call. Please confirm if the document is ready to be
sent
to the IESG. Detailed comments are always welcome!

Thanks!
Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 18 Jun 2019 10:18:26 +0530

> after the end of WG last call, but life is full of little

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

---

From: "Alex Tokar (atokar)" <[email-masked]>
Date: Tue, 18 Jun 2019 12:18:48 +0000

Support.

Thanks,
Alex

On 6/4/19, 6:27 PM, "Pce on behalf of Dhruv Dhody" <[email-masked] on behalf of [email-masked]> wrote:

    Hi WG,

    

    
    
    Thanks,
    Dhruv, Julien, & Adrian

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Tue, 18 Jun 2019 13:45:29 +0000

Support.

Thanks,
Mike.

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Tuesday, June 4, 2019 12:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

Thanks,
Dhruv, Julien, & Adrian

---

From: Mahendra Singh Negi <[email-masked]>
Date: Tue, 18 Jun 2019 13:49:23 +0000

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

Thanks,
Mahendra

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: 18 June 2019 10:18
To: Farrel Adrian <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

> after the end of WG last call, but life is full of little 

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

---

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Tue, 18 Jun 2019 16:21:04 +0000

Hi, Chairs, WG, 

I have reviewed this draft and believe it is ready for publication. This work is useful for enabling PCE and PCC to negotiate the control of LSPs. 

One minor comments on the text: 

In section 3, I was confused when first reading the last sentence on which flag is under discussion. Perhaps the following tweak helps remove the confusion. 
OLD: 
The flag has no meaning in the PCRpt and PCInitiate message and MUST be set to 0 on transmission and MUST be ignored on receipt.
New: 
This new C flag has no meaning in the PCRpt and PCInitiate message and MUST be set to 0 on transmission and MUST be ignored on receipt.

BTW, one of the reference of RFC8281 in section 4 is not correctly shown as hyperlink, please check the format. 

Thank you. 

Best wishes,
Haomian

-----邮件原件-----
发件人: Pce [mailto:[email-masked]] 代表 Dhruv Dhody
发送时间: 2019年6月5日 0:26
收件人: [email-masked]
抄送: [email-masked]
主题: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

Thanks,
Dhruv, Julien, & Adrian

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 19 Jun 2019 02:09:32 +0000

Yes/Support+1. This draft is important for controller. 

Thanks for authors' contributions!

Best Regards,
Cheng

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Wednesday, June 05, 2019 12:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

Thanks,
Dhruv, Julien, & Adrian

---

From: "YADLAPALLI, CHAITANYA" <[email-masked]>
Date: Wed, 19 Jun 2019 14:08:50 +0000

Support.

Thanks,
Chaitanya

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Tuesday, June 4, 2019 12:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpce-2Dlsp-2Dcontrol-2Drequest_&d=DwIFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=mPgKoipxne5RYJjR5j9Zuw&m=rKyxPAGeMlInDvfGHeLBqm5OQgXblTvvkl44mPTgpQA&s=bWDXDjncOCb5aKomNn2wEeC2XrTCL8Y417ryyy6ecLw&e=

Thanks,
Dhruv, Julien, & Adrian

_______________________________________________
Pce mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_pce&d=DwIFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=mPgKoipxne5RYJjR5j9Zuw&m=rKyxPAGeMlInDvfGHeLBqm5OQgXblTvvkl44mPTgpQA&s=CK-FK2kqyau2ARO7hFYPI6YjM4MKm6HjCHSg8Ybvy_Q&e=

---

From: "Jon Parker (jdparker)" <[email-masked]>
Date: Wed, 19 Jun 2019 14:17:19 +0000

Support.

Thanks,
Jon

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: June 4, 2019 12:26 PM
To: [email-masked]
Cc: Hariharan Ananthakrishnan <[email-masked]>; [email-masked]
Subject: WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

Thanks,
Dhruv, Julien, & Adrian

---

From: "Jay Karthik (jakarthi)" <[email-masked]>
Date: Wed, 19 Jun 2019 14:22:46 +0000

Support!

Thanks, 
Jay    
    -----Original Message-----
    From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
    Sent: Tuesday, June 4, 2019 12:26 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04
    
    Hi WG,

    

    
    
    Thanks,
    Dhruv, Julien, & Adrian

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 20 Jun 2019 13:18:08 +0530

Hi WG,

  The WG LC has ended. We seem to have support to move this work forward.
  Thanks to everyone who responded and especially to Adrian and Haomian for
  providing review comments.

Authors,

  please respond to comments and post a new update.

Hari,

  Thanks for being the document shepherd. Ball is now in your court to provide
  shepherd review and write-up, once the authors have made an update.

Thanks!
Dhruv, Julien, & Adrian

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Thu, 20 Jun 2019 14:32:55 +0000

Hi Dhruv,

We will spin off a new version.

Thanks,
Siva

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: Thursday, June 20, 2019 3:48 AM
To: [email-masked]
Cc: Hariharan Ananthakrishnan <[email-masked]>; [email-masked]
Subject: WG LC ends for draft-ietf-pce-lsp-control-request-04

Hi WG,

Authors,

Hari,

Thanks!
Dhruv, Julien, & Adrian

On Tue, Jun 4, 2019 at 9:56 PM Dhruv Dhody <[email-masked]> wrote:
> draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, 
> till 19th June 2019.
>
> If you support, please indicate that you have read the latest version 
> and it is ready for publication. Further, explaining the importance of 
> the work in your opinion is appreciated.
>

---

From: Mahendra Singh Negi <[email-masked]>
Date: Sun, 23 Jun 2019 09:54:56 +0000

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<tel:+91-7204000290>
Email: [email-masked]<mailto:[email-masked]>
From:Adrian Farrel <[email-masked]>
To:'Dhruv Dhody' <[email-masked]>;[email-masked] <[email-masked]>
Cc:[email-masked] <[email-masked]>
Date:2019-06-17 21:17:02
Subject:RE: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi,

Enjoy!

Adrian

===

---

---

---

---

---

Section 3

s/a R/an R/
s/LSP(s)/LSPs/

OLD

---

Section 3 has...

Maybe just delete this?

---

Section 4

OLD
   LSP(s) is/are
NEW
   LSPs are
END

---

Section 4

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

---

Section 4

---

Section 4

---

Section 6

s/vectors/vector/

---

Section 7.1

---

Section 8.1

---

---

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 17 June 2019 11:02
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

Thanks!
Dhruv

> draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks,
till