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

Mahendra Singh Negi <mahendrasingh@huawei.com> Sun, 23 June 2019 09:55 UTC

Return-Path: <mahendrasingh@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F930120151; Sun, 23 Jun 2019 02:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.631
X-Spam-Level:
X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RafPAcKp3Vvz; Sun, 23 Jun 2019 02:55:01 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0C712014F; Sun, 23 Jun 2019 02:55:01 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 39537FEE76241866372E; Sun, 23 Jun 2019 10:54:59 +0100 (IST)
Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 23 Jun 2019 10:54:58 +0100
Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sun, 23 Jun 2019 17:54:56 +0800
Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1591.008; Sun, 23 Jun 2019 17:54:56 +0800
From: Mahendra Singh Negi <mahendrasingh@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "pce@ietf.org" <pce@ietf.org>
CC: "draft-ietf-pce-lsp-control-request@ietf.org" <draft-ietf-pce-lsp-control-request@ietf.org>, "dhruv.ietf@gmail.com" <dhruv.ietf@gmail.com>
Thread-Topic: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04
Thread-Index: AQHVGvJRo/H0xi+it02OhpZtYy+7qKafK1GAgABgZQCACZHR6Q==
Date: Sun, 23 Jun 2019 09:54:56 +0000
Message-ID: 4061DD7D-A170-439E-9F52-4A52DD48743B
References: <CAB75xn6EyVFHDQ-SGMJNGqjvfSBvBpWZ00M=ihfXzLStJ=yUJw@mail.gmail.com> <CAB75xn65BCnOLaGK=gRsVziev5aSb6osGdrYtpksnhwVc9B+ig@mail.gmail.com>, <01b501d52523$dca74350$95f5c9f0$@olddog.co.uk>
In-Reply-To: <01b501d52523$dca74350$95f5c9f0$@olddog.co.uk>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_4061DD7DA170439E9F524A52DD48743B_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/fyzZAmM5icA2tazYDeULpdOSwz4>
Subject: Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jun 2019 09:55:07 -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: mahendrasingh@huawei.com<mailto:mahendrasingh@huawei.com>
From:Adrian Farrel <adrian@olddog.co.uk>
To:'Dhruv Dhody' <dhruv.ietf@gmail.com>;pce@ietf.org <pce@ietf.org>
Cc:draft-ietf-pce-lsp-control-request@ietf.org <draft-ietf-pce-lsp-control-request@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 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 <pce-bounces@ietf.org> On Behalf Of Dhruv Dhody
Sent: 17 June 2019 11:02
To: pce@ietf.org
Cc: draft-ietf-pce-lsp-control-request@ietf.org
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

On Tue, Jun 4, 2019 at 9:56 PM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>
> 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

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