Hi Ketan, On Sat, Nov 9, 2024 at 5:20 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote:
> 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. > > Dhruv: Yes, It should be unassigned. Thanks for spotting it! @ authors - when do you plan to make the update? Thanks! Dhruv (Document Shepherd) > Thanks, > Ketan > > > On Sun, Nov 3, 2024 at 8:41 PM Ketan Talaulikar <ketant.i...@gmail.com> > 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 <d...@dhruvdhody.com> wrote: > > > > > > 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: > > > > 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-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
