Hi Pavan, Ignore this e-mail. I somehow landed looking at -10 of the draft. I see that you have addressed the Manageability Considerations in -11 of the draft. I will clear my DISCUSS once Adrian is good with it.
Sorry for the confusion. > On Feb 18, 2025, at 2:06 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: > > 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 >> <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> Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
