Hi Dhruv, Thanks for the discussion earlier today and please check inline below for response. On Sun, Nov 3, 2024 at 8:36 PM Dhruv Dhody <dd@xxxxxxxxxxxxxx> wrote: > > 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: KT> One nit, the registry group is called "Segment Routing" - this was pointed out by Amanda last week and now fixed in the IDR document as well. > > > I am guessing you will also make the same change in the IDR document. KT> The IDR document was already aligned with this, so we are good on that front. > > >> >> 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. KT> Yes, they are not used in BGP. Thanks, Ketan > > 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
