On Fri, Mar 2, 2018 at 7:15 PM, Jonathan Hardwick < jonathan.hardw...@metaswitch.com> wrote:
> Hi Dan > > Many thanks for the review. Please see my replies below - look for "Jon>". > > Best regards > Jon > > > -----Original Message----- > From: Dan Romascanu [mailto:droma...@gmail.com] > Sent: 28 February 2018 15:23 > To: ops-...@ietf.org > Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-lsp-setup-type. > a...@ietf.org; droma...@gmail.com > Subject: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08 > > Reviewer: Dan Romascanu > Review result: Has Issues > > I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate > reviews a great part of the IETF documents being processed by the IESG for > the OPS ADs. > Please treat with these comments as with all other IETF LC comments. > Please wait for direction from your document shepherd or AD before posting > a new version of the draft. > > This document is an extension of PCEP to allow for other LSP setup methods > than RSVP-TE to be used. For this purpose it defines two new TLVs and > details their operation. > > This is an extension of an existing protocol. An RFC 5706 review applies. > > While the document seems to be focused to developers and implementers of > PCEP, it is not clear what is the impact from an operational point of view > and there are no considerations related to manageability. Maybe these are > detailed in other documents - in this case a reference would be useful. > > Jon> The context of this draft is that it generalizes PCEP so that the > protocol is not dependent solely on using RSVP-TE as a method for setting > up paths. The document performs this generalization, positioning RSVP-TE > as one possible method of path setup, but it stops short of defining any > other path setup methods. Since no new path setup methods are being > introduced, the manageability and operational considerations do not really > change. We have simply generalized a part of PCEP to allow other path > setup methods (and their manageability considerations) to be defined > elsewhere. > > > Here are a few issues. For a complete list of questions, see Annex A in > RFC 5706. > > 1. Why were these extensions needed? Do they improve efficiency? Are there > classes of devices that do not support RSVP-TE and need the new methods? > > Jon> This is a pre-requisite step to allow PCEP to be used in networks > that use segment routing to define paths. Segment routing (SR) is a > distinct path setup method from RSVP-TE. It is possible that SR devices > might not support RSVP-TE. The WG took the decision to write one draft to > generalize PCEP (this draft) and then to write a separate draft to explain > how this generalization is applied to segment routing > (draft-ietf-pce-segment-routing). The latter draft is post-WGLC in the > PCE WG and should be catching up with draft-ietf-pce-lsp-setup-type > shortly. Why did we not combine draft-ietf-pce-lsp-setup-type and > draft-ietf-pce-segment-routing? Suppose we invent a third path setup > type in future. It is clearer for implementers that they only need to > implement the procedures of draft-ietf-pce-lsp-setup-type in order to > prepare the ground for this third path setup type - having one combined > draft incorporating SR as well would make this harder. > > It would be good to describe all these in a paragraph of text, for folks in the future, and for those who did not follow closely the discussions and work assignments in the WG. > 2. How are the new TLVs going to be deployed and managed? Does an operator > have the option of selecting one LSP setup method or the other? How and > what are the criteria of selections? > > 3. There is no discussion about initial setup and configuration. Are there > any initial configuration parameters? If yes, how are they set up? > > 4. Are there any backwards compatibility and migration path issues > operators should be aware about? > > 5. What is the expected impact on network operation? > > 6. How is correct operation visible to the operators? Are there any fault > conditions that need to be reported to operators? > > 7. Are there any existing management interfaces (e.g. YANG models) that > need to be defined or extended? > > Jon> I think the above points 2..7 are really good questions to be asking > about each new path setup type that we introduce. In a draft that is > agnostic of path setup type, I don't really know how to answer them. For > example, I would expect draft-ietf-pce-segment-routing to answer these > questions in the context of configuring and enabling PCEP for segment > routing. Do you think that there is something we can usefully say about > working with multiple path setup types in general? > I am writing this review from the operational and manageability perspective. Managing networks that combine multiple path setup methods may raise some challenges from a configuration and observability point of view. If there are issues that are deferred to other documents, it would be good to mention this in a short paragraph, and provide a reference. I think that Benjamin also suggested something on these lines. Thanks for addressing my comments and for your answers. Regards, Dan
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
