Yeah, sorry guys. I’m a bit behind with stuff and unable to respond instantly :-)
Will be there soon. A From: Mahesh Jethanandani <mjethanand...@gmail.com> Sent: 18 February 2025 22:07 To: Vishnu Pavan Beeram <vishnupa...@gmail.com> Cc: Adrian Farell <adr...@olddog.co.uk>; John Scudder <jgs=40juniper....@dmarc.ietf.org>; The IESG <i...@ietf.org>; draft-ietf-pce-pcep-co...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; andrew.st...@nokia.com Subject: Re: [Pce] Mahesh Jethanandani's Discuss on draft-ietf-pce-pcep-color-09: (with DISCUSS and COMMENT) Hi Pavan, While I wait for Adrian to respond to your responses, I had but one comment. See below with [mj]. On Feb 17, 2025, at 9:11 PM, Vishnu Pavan Beeram <vishnupa...@gmail.com <mailto:vishnupa...@gmail.com> > wrote: Adrian, Please see inline (prefixed [Beeram]) Regards, -Pavan On Fri, Feb 14, 2025 at 2:18 AM Adrian Farrel <adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> > wrote: Thanks again, Pavan. [snip] I read: This color attribute is used as a guiding criterion for mapping services onto the TE tunnel I took this to mean a guide for a classifier to know what traffic to place on the TE tunnel. I.e., the second option. [VPB] Yes, using color for mapping services onto the TE tunnel is a target use case. As an example, for a BGP-based service, the originating PE could attach some community, e.g., the Color Extended Community [RFC9012], with the service route. A receiving PE could use locally configured policies to associate service routes carrying Color Extended Community 'X' with a TE Tunnel of color 'Y'. Using BGP Color Extended Community is just one approach for mapping services onto a TE Tunnel tagged with a color - the draft does not advocate any specific approach (standardized or otherwise). Actually, for this to be of use, it is not enough to tag the TE tunnel with a color, you also have to define how traffic is mapped to that color. You have covered this with: The mechanism used at the PCC for appropriately mapping services onto a TE path that is tagged with a color attribute is outside the scope of this document. [VPB] Yes, the actual mechanism for mapping services is outside the scope of this document. So, perhaps I am reading too much into the utility and purpose (“intent”) of this work. You are just defining a “TE tunnel tag (color)” that can be used in the future by some other process yet to be defined. Is this clear in the document? If so, then we can close this point. [VPB] Yes, this document just defines a protocol mechanism to associate a color tag (representing "intent") with a TE tunnel. The usage is defined elsewhere. The onus is on the document that uses the color TLV to describe the corresponding use case in detail (Example: https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath). Please advise on how we can make this more apparent in the document. [AF] Perhaps… OLD This document introduces extensions to PCEP to carry the color attribute tagged with TE paths that are set up using RSVP-TE ([RFC8408]) or Segment Routing (SR) ([RFC8664]) or any other path setup type supported under the stateful PCE model. NEW This document introduces extensions to PCEP to allow a color tag to be assigned to any path operated under a stateful PCE model (including those set up using RSVP-TE [RFC8408] or Segment Routing (SR) [RFC8664]). The use of this color tag is beyond the scope of this document. END … or some reworking of this text that makes you happy. [Beeram] Please see if the following text suffices instead - The mechanism employed by the PCC for mapping services onto a TE path associated with a color attribute is outside the scope of this document, as is any other use of the color tag. [Beeram] We have also added a "Manageability Considerations" section ( <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-color-11#section-5> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-color-11#section-5), as suggested. Given the scope of the document, there isn't much to add. Please review it and let us know if there are any issues. [mj] In his OPSDIR review, Adrian points out that when the PCE WG published RFC 6123, it was recording the need for all documents that go through the WG to evaluate them for manageability considerations. Manageability considerations per the RFC include: - Fault management - Cofiguration - Accounting - Performance - Security collectively known as FCAPS. A reference to RFC 6123 does not explain what the FCAPS that this particular document is introducing. For example, when this draft states that it "introduces extensions to PCEP to allow a color tag to be assigned to any TE path,” how is that extension configured? Using a proprietary CLI? Similarly, how would an operator know that the extension has been configured? Is there a show command for it? Or when "a PCC is unable to honor a color value passed in a PCUpd or a PCInitiate message, the PCC MUST reject the message and send a PCErr message with Error-type=19 (Invalid Operation) and error-value=TBD1 (Invalid color).”, is there a way for an operator to know how many such messages were received? The manageability considerations section should at the minimum identify: * how can the feature be enabled? If it is not configurable, e.g., it is always enabled by default, state so. If it is configured through some other mechanism, such as proprietary CLI or through NETCONF/RESTCONF using a YANG module, state so. Note that we are not asking that you implement or define how CLI should work or define the YANG model in this document. That work can be done in another document. As a protocol designer, you are in the best position to describe how the feature should be managed. * what are some of the parameters or statistics an implementation should support to enable debugging or monitoring of the feature? Again, a set of recommendations. * are there any faults an implementation should support? What are they? If so, should they be supported using a Syslog event or sent as a notification through protocols such as NETCONF/RESTCONF? Also, a set of recommendations. Does that help explain what Adrian and I are looking for in the manageability considerations section? Thanks. Cheers, Adrian Mahesh Jethanandani mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
