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
