Hi all On Fri, Nov 1, 2024 at 8:15 AM Ketan Talaulikar <ketant.i...@gmail.com> 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-secret...@ietf.org> 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-c...@ietf.org mailing lists by 2024-11-11. Exceptionally, comments > may > > be sent to i...@ietf.org 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-annou...@ietf.org > > To unsubscribe send an email to ietf-announce-le...@ietf.org >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org