Adrian, Please see inline (prefixed [Beeram])
Regards, -Pavan On Fri, Feb 14, 2025 at 2:18 AM Adrian Farrel <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), 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. > > Cheers, > > Adrian > > >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
