Adrian, Hi! Thanks for bringing this to the WG's attention!
I don't think this issue warrants anything other than (1) from your list of actions. This isn't much of an issue from a deployment/operational point of view. If an RSVP-TE implementation chose to add (either deliberately or erroneously) a sub-object of type 36 (or 40 or some other PCEP-only type that gets added in the future) in the ERO/SERO, there is sufficient text in RFC3209 (sections 4.3.4.1 and 4.3.6) that explains what a recipient-node needs to do when it encounters an unknown sub-object. If an unknown sub-object shows up in the RRO/SRRO, the expected behavior on the node processing the recorded information is to ignore the sub-object (Section 4.4.5 of RFC3209). Regards, -Pavan (as a WG participant) On Tue, Feb 21, 2023 at 2:14 AM Adrian Farrel <adr...@olddog.co.uk> wrote: > 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 > <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 > <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 >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
