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

Reply via email to