Hi, You may recall that, back in the early days, the plan for PCEP was that it was used to determine the paths that were to be signalled in MPLS-TE and to report on those paths.
To that end, the ERO and RRO in PCEP messages follow the same construction as those used in RSVP-TE. That is, they are made up of an ordered list of subobjects as specified in the IANA registries for RSVP (https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp -parameters-25 and https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp- parameters-26) RFC 5440 says of the PCEP objects that, "PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types," and that, "Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO." We should also consider that the two registries reference RFC 3209, and also RFC 7571 (for the ERO) to describe the meaning of the registries. Of course, individual subobjects in the registries also reference the RFCs that define those subobjects, but there is (I think) an assumption that the registries list subobjects that can be used in RSVP-TE signaling. Now (finally) to the point. PCEP is being used for determining paths in Segment Routing networks. SR (of course) does not use RSVP-TE signaling, but there is still a desire to describe paths to be used and that have been used. To achieve that, RFC 8664 (for SR-MPLS) and draft-ietf-pce-segment-routing-ipv6 (for SRv6) have defined the use of the PCEP ERO and RRO for SR paths. In doing so, they needed to define new subobjects (to contain SR-MPLS SIDs and SRv6 SIDs) within the ERO and RRO. This led to those subobjects being added to the RSVP-TE IANA registries (using IANA early allocation in the case of draft-ietf-pce-segment-routing-ipv6). This leaves me a bit uneasy. While the entries for draft-ietf-pce-segment-routing-ipv6 (#40 for SRv6) show "(PCEP-specific)" the entry for RFC 8664 (#36 for SR) don't say anything extra. Of course, there are references to the defining documents, but neither document mentions what happens when those subobjects are found in an RSVP-TE message. Nothing tells an RSVP-TE implementer what to expect with these subobjects. This problem propagates to the SERO and SRRO in RSVP-TE since they inherit subobjects from the ERO and RRO. Possibly, this is all covered by RFC 3209 section 4.3.4.1 step 1) and should result in a "Routing Problem" error code with "Bad initial subobject" error value. In this case, there is not so much for me to worry about and (perhaps) we just need to: 1. Fix the registries to say "(PCEP only)" for #36. I think an AD action can do this without the need to write any drafts, etc. 2. Decide it is too late to put any note in RFC 8664 to clarify that the #36 subobjects are not for use in RSVP-TE. 3. Add a note to draft-ietf-segment-routing-ipv6 to say that the #40 subobjects are not for use in RSVP-TE. 4. Consider whether there is a need to document that the registries have entries that are only for PCEP. A way to do this would be a short draft to add two columns to the registries and populate them for existing subobjects to show "may be used in RSVP-TE" and "may be used in PCEP". I'd be willing to write that up. 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. Opinions? Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
