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
