Thanks Ketan for your suggestion.
Please check submitted version 21. Finally, we called that extension block as
“Subobject Extension Block” since it will be used for RRO as well, so we tried
to avoid using “ERO” in the name.
Regards,
Samuel
From: Ketan Talaulikar <ketant.i...@gmail.com>
Sent: Monday, June 23, 2025 9:41 PM
To: Samuel Sidor (ssidor) <ssi...@cisco.com>
Cc: draft-ietf-pce-sid-a...@ietf.org; pce@ietf.org
Subject: Re: AD review of draft-ietf-pce-sid-algo-19
Hi Samuel,
Thanks for posting the last update.
Regarding this one outstanding point, thanks for clarifying that the 32-bit
Algo+Reserved field is optional (depending on the flag settings). Can we name
this 32-bit block as an optional "ERO Extension Block" and show it as optional
in the figure? Then at the bottom of the figure show this ERO Extension Block
to be composed of the Reserved + Algo fields?
I now understand the proposal better with the example. However, the text still
needs work to reflect this scheme. I use the term "ERO Extension Block" (please
feel free to pick a better name) to indicate that this is not Algorithm
specific anymore.
SUGGEST:
A new bit in the Flags field:
* A-flag (SR-Algorithm Flag): If set to '1' by a PCEP speaker, the
ERO Extension Block MUST be included in the SR-ERO subobject as
shown in Figure 1 along with the specified algorithm and the
length of the subobject is extended by 4 octets. If this flag is
set to 0, then either:
- the ERO Extension Block is not included and processing
described in Section 5.2.1 of [RFC8664] applies, or
- the ERO Extension Block is included (due to an extension
flag in a future document) and the Algorithm field MUST be
ignored.
ERO Extension Block:
Reserved (24 bits): This field is reserved for future use and
MUST be set to zero when sending and ignored when receiving.
Algorithm (8 bits): SR-Algorithm value from registry "IGP
Algorithm Types" of "Interior Gateway Protocol (IGP) Parameters"
IANA registry.
Any future extension that uses the Reserved field in the ERO Extension
Block MUST be accompanied with its own flag (similar to the A flag) in
the ERO as well as a capability signaling for its usage.
I hope I have got that correct, but please feel free to update/edit. There may
also be some other text changes for consistency around these new terms and this
concept.
Again, I will leave it to the WG on whether or not this is the approach or
direction they wish to take. I am only looking for a tight specification of
these behaviors in the document.
Thanks,
Ketan
On Mon, Jun 23, 2025 at 12:18 PM Samuel Sidor (ssidor)
<ssi...@cisco.com<mailto:ssi...@cisco.com>> wrote:
Hi Ketan,
The draft version from previous mail is submitted now. I'll update draft with
those minor updates.
For last opened comment:
KT> I am afraid this is not very clear. Are you saying that this document
is not just introducing a new A flag but also a fixed 32 bit container that
is always present in the SR-ERO object (when the algo capability is
advertised)? I just saw that those fields are not optional in the diagram.
Then I am confused why the size of the object would change depending on the
value of the A field (see text at the end of section 4.2).
<S> SR-ERO Subobject is extended with 4 bytes to keep length aligned to
multiple of 4. Those 4 bytes are present if needed for any extension included
in them based on flags (not globally to all instances based on capability
advertised). For now, it will be included if A flag is set in specific SR-ERO
subobject. In the future if some other draft will add another field in
"Reserved" space and new flag, then same 4 bytes can be included as well
(including Algorithm field). That's why we are saying in the draft even now
that PCEP speaker will ignore value of Algorithm field if A flag was not set
(even if capability was advertised).
We are trying to make sure that if in the future somebody will add new
extensions, which can (but does not have to combined with extensions from this
draft), then we will encode subobject in optimal way, so something like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT | Flags |N|A|F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | NEW FIELD | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Instead of doing sub-optimal encoding like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT | Flags |N|A|F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | NEW FIELD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Especially since ERO subobjects can be encoded a lot of times per LSP (multiple
hops in single ERO, possibly repeated in RRO, multiple segment-lists, reverse
ERO,…), so optimality of encoding is more important than for example encoding
of constraints.
(We can still start discussion in mailing list about future extensions, but
encoding above is at least keeping doors opened even if we decide to use
sub-TLV or any other solution.)
Regards,
Samuel
-----Original Message-----
From: Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>>
Sent: Friday, June 20, 2025 5:54 PM
To: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>>
Cc: draft-ietf-pce-sid-a...@ietf.org<mailto:draft-ietf-pce-sid-a...@ietf.org>;
pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: AD review of draft-ietf-pce-sid-algo-19
Hi Samuel/co-authors,
Thanks for taking the time to discuss and incorporate the suggestions/feedback.
I would also suggest posting this update as an "intermediate update" so the WG
also gets the time to review and (if necessary) follow-up. We are almost done
anyway.
Please check inline below for follow-ups/clarifications. There is really only
one major item where I am still not clear (related to the Algo field in the
SR-ERO).
Also you can consider points where I have not responded as addressed (either by
the proposed changes or responses).
On Tue, Jun 17, 2025 at 8:48 AM Samuel Sidor (ssidor)
<ssi...@cisco.com<mailto:ssi...@cisco.com>>
wrote:
> Hi Ketan,
>
>
>
> Please find inline responses <S> and version updated based on
> discussion with other co-authors (thanks a lot to PSF and Andrew for great
> discussion).
>
>
>
> Thanks,
>
> Samuel
>
>
>
> Hi Authors/WG,
>
> Thanks for your work on this important document that tries to leverage
> IGP technologies like FlexAlgo in PCE and builds on top for delivering
> new use-cases.
>
> I would like to start with a high-Level overview of the specifications
> based on my reading and some questions/suggestions. Please correct me
> if my understanding is wrong.
>
> 1) There are 3 main types of extensions:
>
> a) Extensions to Metric Objects: these aren't specific to SR path types,
> they aren't specific to FlexAlgo, they are more general. I suggest that
> this be brought out in the Abstract and Introduction sections.
> Also, that
> the specifications for this be brought out as a top-level section in the
> document. Please consider this as a major editorial comment.
>
> <S> Both abstract and introduction updated.
>
> b) Algo support in SR-ERO/RRO: this is purely a signaling extension to
> convey additional algo information and unrelated to any computational
> enhancements to the PCE functionality. E.g., it could be used for say a
> PCE-initiated explicit path. Would be great if this could be called out
> and the document sections were re-ordered accordingly.
>
> <S> Ack, moved to separate section.
>
> c) Algorithm Constraint: this is getting algo (both FlexAlgo and any
> other specific IGP algo) related aspects into the path computation. This
> now enables the conveying of IGP aspects (e.g., for FlexAlgo the
> optimization metric and other constraints from the FAD) in PCEP.
>
> Both (b) and (c) are covered by the same new capability being introduced
> and specific to the SR path setup types. Ideally, it would have
> been nice
> to use different capabilities, but I guess (b) is really a small
> add-on and
> hence covered together with (c). I hope there is no one that tries to
> implement (b) but not (c).
>
> <S> Correct, it is small enough to create separate capability, but we
> are open to change it if there anybody really plans to implement subset only.
>
> 2) The (1)(c) functionality can be further split into two major types:
>
> a) FlexAlgo related (algo 128-255): this requires that the PCE is aware
> of IGP signaling information related to FlexAlgo (such as FAD, algo
> participation, metric types including generic metric, ASLA, etc.).
> It would
> be good to call out that it is expected that this topology information
> is conveyed to the PCE via existing mechanisms (viz. IGPs or BGP-LS).
>
> <S> Added explicit statement to “5.2.2. Path Computation for Flexible
> Algorithms” section.
>
KT> Thanks. Please update the reference to BGP-LS to RFC 9552.
>
> b) non-FlexAlgo related (algo 0-127): Of these algos, only default (0)
> and strict-SPF (1) are specified. Since the rest is undefined, they
> cannot
> be supported in PCEP as well - this needs to be called out along
> with the
> necessary error handling, if those are received. Further, default
> (0) has
> been already in use in PCEP for ages now - this needs to be called out
--- Begin Message ---
Internet-Draft draft-ietf-pce-sid-algo-21.txt is now available. It is a work
item of the Path Computation Element (PCE) WG of the IETF.
Title: Carrying SR-Algorithm in Path Computation Element Communication
Protocol (PCEP)
Authors: Samuel Sidor
Zoey Rose
Shaofu Peng
Shuping Peng
Andrew Stone
Name: draft-ietf-pce-sid-algo-21.txt
Pages: 30
Dates: 2025-06-25
Abstract:
This document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) to enhance support for Segment Routing
(SR) with a focus on the use of Segment Identifiers (SIDs) and SR-
Algorithms in Traffic Engineering (TE). The SR-Algorithm associated
with a SID defines the path computation algorithm used by Interior
Gateway Protocols (IGPs). This document introduces extensions in
three main areas.
Mechanisms for informing PCEP peers about the SR-Algorithm associated
with SIDs by encoding this information in Explicit Route Object (ERO)
and Record Route Object (RRO) subobjects. This document updates RFC
8664 and RFC 9603 to allow such extension.
The document specifies SR-Algorithm constraint, enabling refined path
computations that can leverage IGP algorithm logic, including
Flexible Algorithms, and their associated constraints and
optimization metrics.
It defines new metric types for the METRIC object required to support
SR-Algorithm based path computation, but also applicable to Label
Switched Paths (LSPs) setup using different Path Setup Types.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo-21
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sid-algo-21
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
--- End Message ---
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
