Re: [Pce] Eric Rescorla's No Objection on draft-ietf-pce-pce-initiated-lsp-10: (with COMMENT)

[Jonathan Hardwick <[e-mail]>]

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



<snip>



----------------------------------------------------------------------

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.