Hi Adrian, As a WG participant...
Thanks for bringing this up to the WG attention.... On Tue, Feb 21, 2023 at 2:14 AM Adrian Farrel <[email protected]> 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. > > Dhruv: Your #1 makes the most sense to me! Though at one point when this RFC was early in the discussion I thought someone will propose carrying SR-ERO in RSVP-TE to do some kind of clever RSVP-TE + SR interworking :) #4 would possibly belong in TEAS and thus we can check with them if such a document is required and how do they handle such a situation right now! > 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! Thanks! Dhruv > Opinions? > > Cheers, > Adrian > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
