Hi Jon, This looks very good and addresses my concerns. Thanks for the dialog and for the responsiveness.
Regards, Dan On Mon, Mar 12, 2018 at 6:44 PM, Jonathan Hardwick < jonathan.hardw...@metaswitch.com> wrote: > Hi Dan > > > > I have written the following text to address the general question of > manageability of different LSP Setup types and plan to include it in the > next revision of this draft. Please let me know if you have any comments. > > > > NEW (insert before “Security Considerations” section) > > > > 6. Manageability Considerations > > > > This document generalises PCEP to allow path setup methods other than > RSVP-TE to be used by the network. It is possible that, in a given > network, multiple path setup methods will be used. It is also possible > that not all devices will support the same set of path setup methods. > Managing networks that combine multiple path setup methods may therefore > raise some challenges from a configuration and observability point of view. > > > > Each document that introduces a new path setup type to PCEP must include a > manageability section. The manageability section must explain how > operators can manage PCEP with the new path setup type. It must address > the following questions, which are generally applicable when working with > multiple path setup types in PCEP. > > - What are the criteria for when devices will use the new path setup > type in PCEP, and how can the operator control this? > - How can the network be migrated to the new path setup type, and are > there any backwards compatibility issues that operators need to be aware > of? > - Are paths set up using the new path setup type intended to coexist > with other paths over the long term and, if so, how is this situation > managed with PCEP? > - How can operators verify the correct operation of PCEP in the > network with respect to the new path setup type? Which fault conditions > must be reported to the operators? > - Are there any existing management interfaces (such as YANG models) > that must be extended to model the operation of PCEP in the network with > respect to the new path setup type? > > > > See [RFC 6123] for further guidance on how to write manageability sections > in PCEP standards-track documents. > > > > END NEW > > > > + [RFC 6123] is added as an informative reference. > > > > Many thanks > > Jon > > > > > > > > *From:* Dan Romascanu [mailto:droma...@gmail.com] > *Sent:* 03 March 2018 10:57 > *To:* Jonathan Hardwick <jonathan.hardw...@metaswitch.com> > *Cc:* ops-...@ietf.org; pce@ietf.org; i...@ietf.org; > draft-ietf-pce-lsp-setup-type....@ietf.org > *Subject:* Re: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08 > > > > > > > > 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
