Adrian, Please see inline for responses (prefixed [Pavan])
Regards, -Pavan On Wed, Feb 12, 2025 at 7:11 AM Adrian Farrel <adr...@olddog.co.uk> wrote: > Interesting. Thanks. > > > > I think there are possibly two meanings for “intent”: > > - How the network is meant to manage and operate to deliver a > particular TE tunnel. I.e., what we would like the TE tunnel to be like. > - What the TE tunnel is like. I.e., how we can use it to deliver a > service. > > [VPB] Okay. However, these two meanings don't necessarily need to be mutually exclusive. A TE tunnel whose path is optimized for "delay" is used to deliver "delay sensitive" services. The intent (color tag) tagged for this TE tunnel is "delay". > > > 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. > > > Cheers, > > Adrian > > > > *From:* Vishnu Pavan Beeram <vishnupa...@gmail.com> > *Sent:* 12 February 2025 14:44 > *To:* adr...@olddog.co.uk > *Cc:* John Scudder <jgs=40juniper....@dmarc.ietf.org>; Mahesh > Jethanandani <mjethanand...@gmail.com>; 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] Re: Mahesh Jethanandani's Discuss on > draft-ietf-pce-pcep-color-09: (with DISCUSS and COMMENT) > > > > Adrian, Mahesh, > > > > When the protocol extension was initially defined, the primary motivation > was to find parity for RSVP-TE paths with the color encoding used in SR > policy paths (which uses Extended ASSOCIATION). We also briefly > contemplated using an ASSOCIATION object but introduced a new TLV in the > LSP object to keep the procedure simple. We did not consider nor discuss > the use of the FLOWSPEC object. I think this is because FLOWSPEC was > perceived as a mechanism to categorize traffic mapped to the TE tunnel, > while the color attribute was used to tag a TE tunnel with specific intent > (we were trying to encode an attribute of the TE tunnel and not necessarily > an attribute of the traffic to be steered on to the TE tunnel). We treated > the color specification for a TE tunnel path to be similar to the > optimization objective specification for a TE tunnel path. I hope this > clarifies why the authors chose the current encoding in the initial version > of the draft. Since there was no opposition to this encoding during the WG > process, we assumed there was consensus in the WG for the chosen approach. > > Can a case be made to tweak the semantics of FLOWSPEC to specify an > attribute of the TE tunnel? Maybe. We'll let the IESG decide if this draft > needs to be returned to the WG for discussing all possible alternative > encoding mechanisms. > > > > Regards, > > -Pavan > > > > On Wed, Feb 12, 2025 at 3:24 AM Adrian Farrel <adr...@olddog.co.uk> wrote: > > I, too, was stimulated by the response on this point. > > I am certainly not saying that the WG must change its approach here. > But, given that a mechanism already exists to carry information describing > how to associate traffic with an LSP, I thought that there should be some > discussion (not necessarily in the draft) of why the existing mechanism was > not used. > I had expected a response that said something like, "We thought about this > and rejected it for the following reasons. We confirmed our reasoning with > the working group." > > I'll review the authors' other responses. > > Best, > Adrian > > -----Original Message----- > From: John Scudder <jgs=40juniper....@dmarc.ietf.org> > Sent: 12 February 2025 03:17 > To: Mahesh Jethanandani <mjethanand...@gmail.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-pce-pcep-co...@ietf.org; > pce-cha...@ietf.org; pce@ietf.org; andrew.st...@nokia.com > Subject: [Pce] Re: Mahesh Jethanandani's Discuss on > draft-ietf-pce-pcep-color-09: (with DISCUSS and COMMENT) > > Hi Mahesh, > > > On Feb 11, 2025, at 10:06 PM, Mahesh Jethanandani via Datatracker < > nore...@ietf.org> wrote: > > > > I was also piqued by the comment from the authors that "Given that the > document > > has reached this stage, it is safe to assume that there was consensus in > the WG > > to use this TLV. AFAIK there was no discussion or debate during the WG > process > > on whether the draft could have used an alternative encoding mechanism." > If the > > discussion never happened, how can we claim that there was consensus in > the WG? > > I don’t think our process requires that a WG explore the entire potential > solution space (which is often very large, even if only considering > reasonable solutions) before reaching consensus to use a particular > solution. Nor should it. > > —John > _______________________________________________ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-le...@ietf.org > > _______________________________________________ > Pce mailing list -- pce@ietf.org > To unsubscribe send an email to pce-le...@ietf.org > >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
