Hi all
On Fri, Nov 1, 2024 at 8:15 AM Ketan Talaulikar <ketant.ietf@xxxxxxxxx> wrote:
Hi All,
While working on related IDR documents, I've come across some issues
with the IANA consideration section of this document and would like to
suggest a way to address/resolve them.
Section 6.5
The new SR Policy Protocol Origin registry created under the Segment
Routing registry group is shared between this document and
draft-ietf-idr-bgp-ls-sr-policy. However, the allocation policy is not
aligned between the two - Specification Required vs Expert Review.
There is also a private use space. To harmonize them, I would like to
suggest that the allocation policy for range from 0-125 be retained as
Specification Required (as per this PCEP document) and the FCFS be
used for 126-255. I believe this would meet the requirements of both
the documents and also avoid the private use space.
Dhruv: Ketan and I met offline. We concluded that it makes sense for a field like "protocol origin" to use "expert review" and "private use" to allow for an appropriate amount of review and control. Here is the suggested change -
This document requests IANA to maintain a new registry under "Segment Routing Parameters" registry group. The new registry is called "SR Policy Protocol Origin". New values are to be assigned by "Expert Review" [RFC8126] using the guidelines for Designated Experts as specified in [RFC9256]. The registry contains the following codepoints:
I am guessing you will also make the same change in the IDR document.
Sections 6.7 (SR Policy Invalidation Operational Flags) and 6.8 (SR
Policy Invalidation Configuration Flags) are PCEP specific and the
right place to park them should be under the PCEP Numbers registry
group rather than the currently proposed Segment Routing registry
group. The Segment Routing registry group is where we keep codepoints
shared by multiple protocols.
Dhruv: if we are sure that there is no use in BGP, then yes it makes sense to put them in the PCEP registry group.
Thanks!
Dhruv
Thanks,
Ketan
On Mon, Oct 21, 2024 at 10:23 PM The IESG <iesg-secretary@xxxxxxxx> wrote:
>
>
> The IESG has received a request from the Path Computation Element WG (pce) to
> consider the following document: - 'Path Computation Element Communication
> Protocol (PCEP) Extensions for
> Segment Routing (SR) Policy Candidate Paths'
> <draft-ietf-pce-segment-routing-policy-cp-18.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@xxxxxxxx mailing lists by 2024-11-11. Exceptionally, comments may
> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> Segment Routing (SR) allows a node to steer a packet flow along any
> path. SR Policy is an ordered list of segments (i.e., instructions)
> that represent a source-routed policy. Packet flows are steered into
> an SR Policy on a node where it is instantiated called a headend
> node. An SR Policy is made of one or more candidate paths.
>
> This document specifies the Path Computation Element Communication
> Protocol (PCEP) extension to signal candidate paths of the SR Policy.
> Additionally, this document updates RFC 8231 to allow stateful bring
> up of an SR Label Switched Path (LSP), without using the path
> computation request and reply messages. This document is applicable
> to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over
> IPv6 (SRv6).
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list -- ietf-announce@xxxxxxxx
> To unsubscribe send an email to ietf-announce-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
