Hi Adrian,
It seems better to use a new PCEP ERO and RRO Object-Type and a new
registry of subobjects.
As you mentioned, that would be so much cleaner. In addition, it would be
much more concise.
Best Regards,
Huaimo
-----Original Message-----
From: Pce <[email protected]> On Behalf Of Adrian Farrel
Sent: Monday, February 20, 2023 3:45 PM
To: [email protected]; 'TEAS WG' <[email protected]>
Subject: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Frsvp-parameters%2Frsvp-parameters.xhtml%23rsvp&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cab54020d9a50400f60b708db13834e20%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125226932148129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HPhNLTbf5I7XnmevWwRUpSp8mcQkm31Qz01LepzcKgY%3D&reserved=0
-parameters-25 and
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Frsvp-parameters%2Frsvp-parameters.xhtml%23rsvp-&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cab54020d9a50400f60b708db13834e20%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125226932148129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cR0JWE3OsvQGgwOvrZkitlFQCn9NSrtvGFtwm4gmB8o%3D&reserved=0
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
[email protected]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpce&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cab54020d9a50400f60b708db13834e20%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125226932148129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xB6GgMnGmvSxe4%2BM41ScnZu7zaZGiZjQcHuFYT4pdqo%3D&reserved=0
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
