Hi Eric
Many thanks for these comments. I'm picking up this thread and replying as PCE
working group chair, as the authors are unavailable. I am very sorry for the
delay.
Please see my proposed resolutions inline below, marked with "Jon>"
Best regards
Jon
--
COMMENT:
--
Document: draft-ietf-pce-pce-initiated-lsp-10.txt
Note: I reviewed this document on my experimental Phabricator instance.
You can see the comments inline at:
https://mozphab-ietf.devsvcdev.mozaws.net/D20
Jon> This is a useful tool, thanks!
It may just be my unfamiliarity with this system, but it's not clear to me what
the security model is here for the delegation. As I understand this document
the PCC just tells the PCE that it has delegated the LSP to it, and then the
PCE can make the LSP via the normal procedures. But what is it that tells the
rest of the system that the PCC is allowed to manage that LSP. I didn't get
that out of this document or out of a cursory look at RFC 8051.
Jon> The model is that the PCE makes the first move. It instructs the PCC to
initiate an LSP that the PCC has not previously heard of. The PCC initiates
the LSP and sends a PCRpt message delegating control over it to the PCE. Once
it receives the delegation, the PCE is free to make whatever changes it likes,
or delete the LSP.
INLINE COMMENTS
Line 162
A possible use case is a software-driven network, where applications
request network resources and paths from the network infrastructure.
NIT: isn't the term here "software-defined network"
Jon> Indeed. Will fix.
Line 218
all state related to the LSP and sends a PCRpt for the removed state.
See details in Section 5.4.
A diagram would sure help here.
Jon> How about this:
NEW
The following diagram illustrates these message exchanges.
+-+-++-+-+
|PCC||PCE|
+-+-++-+-+
||
|<--PCInitiate---| (Initiate LSP)
||
|---PCRpt, PLSP_ID=1, D=1--->| (Confirm initiation)
|. |
|. |
||
|<--PCUpd, PLSP_ID=1-| (Update LSP)
||
|---PCRpt, PLSP_ID=1, D=1--->| (Confirm update)
|. |
|. |
||
|<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)
||
|---PCRpt, PLSP_ID=1, R=1--->| (Confirm update)
Figure 1: Initiated LSP lifecycle
END NEW
Line 263
Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt.
As I understand this text, you are merely adding a new code point to flags. I'm
not sure it's necessary to reproduce the PDU, but if you do, you should clarify
that th only change you are making is adding a new field. Perhaps on line 249
"It is reproduced here with the addition of the new I bit"
Jon> Yes, this is correct. I will update this section and the similar cases
below to follow the form of the "good text" from line 436 that you cite below.
Line 278
and the LSP objects, and MAY contain other objects, as discussed
later in this section.
Is the syntax here supposed to be ABNF? If so, you need a citation to the
syntax".
Jon> It's RBNF. It’s defined in [RFC5511], listed as a normative reference and
cited from section 2.
Line 337
create an LSP. If set to 1, it indicates a request to remove an
LSP.
I have the same comment here about repeating PDU.
Jon> Ack.
Line 436
The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
here for easy reference.
This is good text, and is what I would encourage the other places you replicate
PDUs from other documents.
Jon> Ack.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
