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-boun...@ietf.org> On Behalf Of Dhruv Dhody
Sent: 17 June 2019 11:02
To: pce@ietf.org
Cc: draft-ietf-pce-lsp-control-requ...@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.i...@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
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
