date:20230220

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

2023-02-20 Thread 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] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

2023-02-20 Thread xiong.quan

Hi Cheng,






Thanks for your reply!


The suggested text maybe like this following shown.

"  *  V: When this bit is set to 1, the PCC should perform the SID verification 
in validity of an Explicit Candidate Path as described in as per Section 5.1 of 
 [RFC9256]. When a segment list of an explicit candidate path be invalid, a 
PCErr message should be sent. "

I am not sure about the last PCEP error part. Maybe the PCC should notify the 
PCE when the candidate path is invalid.




Best Regards,

Quan
















Original



From: ChengLi 
To: 熊泉00091065;julien.meu...@orange.com ;
Cc: pce@ietf.org ;
Date: 2023年02月20日 15:14
Subject: RE: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15


Hi Quan,
 
The usage is the same as defined in RFC9256. Do you have any suggested text?
 
Thanks,
Cheng
 
 
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of xiong.q...@zte.com.cn
Sent: Thursday, February 16, 2023 5:16 PM
To: julien.meu...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15
 
Dear PCE WG,
 
I support the WG LC of this draft. I reviewed this document in details and I 
think it is useful and reasonable for SRv6 networks with PCEP extension.
Thanks the authors for the well-written draft and I have a suggestion for 
section 4.3.1 with text "V: The "SID verification" bit usage is as per Section 
5.1 of  [RFC9256]." Maybe it is better to add more description on how to 
use the V bit for SID verification.
 
Best Regards,
Quan
 
 
 
 
 
 
<<[Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

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

2023-02-20 Thread 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
> https://www.ietf.

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

2023-02-20 Thread 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&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?

Che

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

2023-02-20 Thread Adrian Farrel

Hi,

Here is my WG last call review of this document. Thanks to the authors
for all of the work that has gone in.

[A note for the chairs: Was this last call shared with SPRING?]

Cheers,
Adrian

===

Abstract

   The Source Packet Routing in Networking (SPRING) architecture

In fact, although RFCs 7855, 8354, and 8355 talk about "Source Packet
Routing in Networking (SPRING)", the architecture document (RFC 8402)
is the "Segment Routing Architecture."

---

Abstract

   It depends only on "segments"

As it is a new paragraph, you need to clarify what "it" is. Or maybe
move this sentence to the previous paragraph so that para 2 begins "A
Segment Routed Path..."

---

Abstract

s/forwarding plane/forwarding planes/(twice)
s/support for IPv6 data plane in/support for the IPv6 data plane in the/

---

Abstract

OLD
   The PCEP extension and mechanism to support SR-MPLS
   is described in RFC 8664.
NEW
   The PCEP extensions and mechanisms to support SR-MPLS
   are described in RFC 8664.
END

---

Abstract

I think the final sentence is superfluous (or confusing).
Probably this is a repeat of "This document describes the extensions
required for SR support for IPv6 data plane in Path Computation Element
communication Protocol (PCEP)."

---

1.

s/Locater/Locator/
s/The list of segment/The list of segments/

---

1.

   Upon completion of a segment, a pointer in the new
   routing header is incremented and indicates the next segment.

Not so new anymore!
Try...

   Upon completion of a segment, a pointer in the SRH
   is incremented and indicates the next segment.

---

1.

   Segment Routing use cases are described in [RFC7855] and [RFC8354].
   Segment Routing protocol extensions are defined in [RFC8667], and
   [RFC8666].

There is nothing untrue in this paragraph. But what does it add? The use
cases aren't mentioned anywhere in the document, and the protocol
elements aren't used.

I'd just remove the paragraph.

---

1.

   As per [RFC8754], an SRv6 Segment identifier is an 128-bit value.
   "SRv6 SID" or simply "SID" are often used as a shorter reference for
   "SRv6 Segment".  Further details are in an illustration provided in
   [RFC8986].

This duplicates and somewhat modifies where the first paragraph says...

   An ordered list of segments
   is encoded as an ordered list of IPv6 addresses in the routing
   header.

I suggest you try to fold this short paragraph into the first paragraph
and clarify the difference between "an 128-bit value" and "IPv6 address"

---

1.

   The SR is applied to IPV6 forwarding
   plane using Source Routing Header (SRH) [RFC8754].

You've already said this in the first paragraph

---

1.

   A SR path can be
   derived from an IGP Shortest Path Tree (SPT), but SR-TE paths may not
   follow IGP SPT.

a. You have just introduced "SR-TE". You need to expand it as "Segment
   Routing Traffic-Engineering".

b. Is there actually any difference between an SR path and an SR-TE 
   path? If so, you might add it to Section 2 after the definition of
   "SR Path".

c. Notwithstanding RFC 8664, s/may/might/ to avoid confusion with the
   normal English "you may not do it!"

---

1.

s/SR-TE LSP for MPLS data plane/SR-TE LSP for the MPLS data plane/
s/support SR for IPv6 data plane/support SR for the IPv6 data plane/
s/either stateful or a stateless PCE/either a stateful or stateless PCE/

---

2.

s/equivalent to a SRv6 Path/equivalent to an SRv6 Path/

---

3.

s/operations for PCEP speakers is/operations for PCEP speakers are/

---

3.

   SR-capable PCEP speakers should be able to generate and/or process
   such an ERO subobject.

"should be able to" ??

Maybe...

   SR-capable PCEP speakers can generate or process
   such an ERO subobject.

---

3.

   This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in the
   ERO and the RRO respectively to carry the SRv6 SID (IPv6 Address).

Should the previous paragraph have talked about the RRO?

---

3.1

   In SR networks, an ingress node of an SR path appends all outgoing
   packets with an SR header consisting of a list of SIDs (IPv6 Prefix
   in case of SRv6).

a. s/SR header/SRH/

b. The SRH is only used for SRv6, so this text is a bit mixed-up

c. Isn't there technically a case where only one SID is present so the
   SRH is not needed (the SID is put in the DA field of the 
   encapsulating IPv6 header)?

---

3.1

OLD
   For the use of IPv6 in control plane only with MPLS data plane,
   mechanism remains the same as specified in [RFC8664].
NEW
   For the use of an IPv6 control plane but an MPLS data plane, the
   mechanism remains the same as specified in [RFC8664].
END

---

3.1

   This document describes an extension to the SR path for the IPv6 data
   plane.

It does? I thought it was all about PCEP.

---

3.1 seems to have some duplication of content from Section 3.

---

4.1.1

To avoid any risk of stale text persisting into the RFC (and given 
that you have this covered in the IANA section)...

OLD
   *  PST = 3 (

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

2023-02-20 Thread Adrian Farrel

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

[Pce] I-D Action: draft-ietf-pce-sr-path-segment-07.txt

2023-02-20 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Path Computation Element WG of the 
IETF.

Title   : Path Computation Element Communication Protocol 
(PCEP) Extension for Path Segment in Segment Routing (SR)
Authors : Cheng Li
  Mach(Guoyi) Chen
  Weiqiang Cheng
  Rakesh Gandhi
  Quan Xiong
  Filename: draft-ietf-pce-sr-path-segment-07.txt
  Pages   : 26
  Date: 2023-02-20

Abstract:
   The Path Computation Element (PCE) provides path computation
   functions in support of traffic engineering in Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   The Source Packet Routing in Networking (SPRING) architecture
   describes how Segment Routing (SR) can be used to steer packets
   through an IPv6 or MPLS network using the source routing paradigm.  A
   Segment Routed Path can be derived from a variety of mechanisms,
   including an IGP Shortest Path Tree (SPT), explicit configuration, or
   a Path Computation Element (PCE).

   Path identification is needed for several use cases such as
   performance measurement in Segment Routing (SR) network.  This
   document specifies extensions to the Path Computation Element
   Communication Protocol (PCEP) to support requesting, replying,
   reporting and updating the Path Segment ID (Path SID) between PCEP
   speakers.


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-07

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-path-segment-07


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

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

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

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

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

[Pce] I-D Action: draft-ietf-pce-sr-path-segment-07.txt

7 matches

Site Navigation

Mail list logo

Footer information