Hi Adrian! Got it! Thanks for your patience in clarifying your proposal! I finally understood :)
Thanks! Dhruv On Tue, Feb 21, 2023 at 10:55 PM Adrian Farrel <adr...@olddog.co.uk> wrote: > Hi again, Dhruv. > > > > Still not pushing this idea, but still trying to make sure it is correctly > understood…. > > > > Of course an (unpopular) option would be to tell the PCE WG that it is not > acceptable to use the RSVP-TE registries in this way, and let them know > that > if they want to specify paths for other uses they should use a new PCEP ERO > and RRO Object-Type and a new registry of subobjects. In many ways, that > would be so much cleaner, but it would break RFC 8664 implementations. > > Dhruv: (also addressing Huaimo), to me this is a bit overkill. We would > need to update a lot of documents. > > Of course if the situation changes nothing would stop us from moving in > this direction in future, but I dont think we are there yet! > > [AF] I don’t believe “a lot of documents” would need to be updated. > > You wouldn’t be changing the fact that it is an ERO. You’d keep the same > Object Class value. You’d just be changing the Object Type used in the case > of SR. > > So none of the legacy documents that refer to the inclusion of an ERO > would change. > > AFAICS it would be just 8664 that would be changed. > > > > Dhruv: I misunderstood then! You were suggesting that the subobjects > shared by PCEP and RSVP-TE still remain in the old registry and subobjects > only used in PCEP go into a brand new registry! Hmmm.... But ERO could have > subobjects from both registries and that would make it weird. That is why I > thought we were suggesting a fresh new PCEP registry for all subobjects > used in PCEP. > > > > I kinda still feel its overkill :) > > > > [AF2] Yes, but going a step further. > > The PCEP objects have two identifier fields (just like RSVP): the > Object-Class and the Object-Type. > > The Object-Class identifies the sort of object. Thus, ERO = 7, RRO = 8. > > The Object-Type indicates the type of use that the object is put to. There > are 15 values available. > > In general, PCEP objects all use Object-Type = 1. > > But some objects (such as END-POINTS and BANDWIDTH) have a small number of > Object-Types available. > > The Object-Type says “I know what sort of object I am handling and what it > is for, but I need more information to understand the encoding and use > case.” > > > > So, my suggestion was to use Object-Class=7, Object-Type=1 for G/MPLS LSP > EROs (signaled or manually provisioned), and Object-Class=7, Object-Type=2 > for SR paths. > > (You could even go Object-Type=2 for SR-MPLS and Object-Type=3 for SRv6. > Further, since RFC 8664 is already published, we could leave SR-MPLS alone, > and just go straight to Object-Type=3 for SRv6 in this document.) > > The subobjects for Object-Type != 3 are those defined in this document: > namely SR-ERO. And they could come from a new registry. > > This would have no impact on the existing EROs and so no changes to the > existing registry. > > > > Cheers, > > Adrian >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
