Hi Dhruv/Authors, I have not yet seen any updates on these issues related to the IANA section - I hope I have not missed anything. I would like to raise one other issue that was caught by Dan Romascanu in his last-call review of the IDR document. This PCEP document seems to be using "reserved" instead of "unassigned" for the registry in section 6.6 where we want IANA to manage future allocations. Please let me know if there is a reason to not allow future allocations by using reserved. Thanks, Ketan On Sun, Nov 3, 2024 at 8:41 PM Ketan Talaulikar <ketant.ietf@xxxxxxxxx> wrote: > > 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
