Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Dhruv Dhody]

Hi Adrian!

Got it! Thanks for your patience in clarifying your proposal! I finally
understood :)

Thanks!
Dhruv

On Tue, Feb 21, 2023 at 10:55 PM Adrian Farrel  wrote:

> 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

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Adrian Farrel]

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

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Dhruv Dhody]

Hi Adrian,

On Tue, Feb 21, 2023 at 2:36 PM Adrian Farrel  wrote:

> Looks like I was somewhat right with “unpopular” 
>
>
>
> 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 :)

Thanks!
Dhruv



> [AF] I’m not lobbying for this (despite it being the “right thing to do”),
> but let’s make any decisions based on a balanced view.
>
>
>
> Adrian
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Adrian Farrel]

Looks like I was somewhat right with “unpopular” 

 

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.

 

[AF] I’m not lobbying for this (despite it being the “right thing to do”), but 
let’s make any decisions based on a balanced view.

 

Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Vishnu Pavan Beeram]

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  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
> 
> 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
>
> 

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Dhruv Dhody]

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  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
> 
> 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.
>
>
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
> Pce@ietf.org
> 

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Huaimo Chen]

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  On Behalf Of Adrian Farrel
Sent: Monday, February 20, 2023 3:45 PM
To: pce@ietf.org; 'TEAS WG' 
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=05%7C01%7Chuaimo.chen%40futurewei.com%7Cab54020d9a50400f60b708db13834e20%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125226932148129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HPhNLTbf5I7XnmevWwRUpSp8mcQkm31Qz01LepzcKgY%3D=0
-parameters-25 and
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Frsvp-parameters%2Frsvp-parameters.xhtml%23rsvp-=05%7C01%7Chuaimo.chen%40futurewei.com%7Cab54020d9a50400f60b708db13834e20%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125226932148129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=cR0JWE3OsvQGgwOvrZkitlFQCn9NSrtvGFtwm4gmB8o%3D=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