Hi Rishabh Thanks for the reply. For the code points in section 8 that you don't have an early allocation for, it's best to replace the literal values you've specified with "TBD" and just leave it to IANA to fill in. Unless you actually do need them to be those specific values, in which case you should get an early allocation to avoid the possibility of a conflicting allocation. Just my advice based on unfortunate things that I have seen happen in the past!
Best regards Jon On Fri, 15 Nov 2024 at 16:18, Rishabh Parekh (riparekh) <ripar...@cisco.com> wrote: > Jonathan, > We will fix the NITS in next revision. > > We have already obtained early IANA allocations for the "SR-MPLS P2MP > Tree". For "SRv6 P2MP Tree", the document just proposes a value.If you > prefer, I can change the column to "Proposed Value" in "SRv6 Endpoint > Behaviors" table for End.DTMC4/6. > > Thanks, > Rishabh. > > > -----Original Message----- > > From: Jonathan Hardwick via Datatracker <nore...@ietf.org> > > Sent: Friday, November 15, 2024 8:09 AM > > To: rtg-...@ietf.org > > Cc: bess@ietf.org; draft-ietf-bess-mvpn-evpn-sr-p2mp....@ietf.org > > Subject: Rtgdir early review of draft-ietf-bess-mvpn-evpn-sr-p2mp-11 > > > > Reviewer: Jonathan Hardwick > > Review result: Has Nits > > > > Hi there > > > > I have conducted an Early Review of this document on behalf of the > routing > > directorate. In my opinion, this document is ready to progress subject to > > resolution of a few nits. Please attend to these along with the next > published > > version of the draft. > > > > My only note of caution below is to use the process for early IANA code > point > > allocation if specific code point values are required. > > > > Best regards > > Jon > > > > Section 3. > > Clarify this passage: > > OLD > > Root is an IP address identifying the Root of a P2MP tree. This can be > either an > > IPv4 or IPv6 address and can be inferred from the PTA length. NEW Root > is an IP > > address identifying the Root of a P2MP tree. This can be either an IPv4 > or > > IPv6 address. The address type can be inferred from the PTA length. END > > > > Section 5 > > Typos: > > OLD > > Egress PEs join asLeaf Nodes using Intrra-AS I-PMSI or Leaf > Auto-Discovery > > routes. NEW Egress PEs join as Leaf Nodes using Intra-AS I-PMSI or Leaf > Auto- > > Discovery routes. END > > > > Section 5.2 > > Typos: > > OLD > > To join a SRv6 Ingres Replication P-Tunnel advertised in PTA of Inra-AS, > Inter-AS, > > or Selective S-PMSI A-D routes… NEW To join a SRv6 Ingress Replication P- > > Tunnel advertised in PTA of Intra-AS, Inter-AS, or Selective S-PMSI A-D > routes… > > END > > > > Section 6 > > Remove redundant RECOMMENDED/SHOULD clauses. > > OLD > > Since Leaf A-D routes are used to discover Leaf PE of a P2MP tree, it is > > RECOMMENDED that PEs SHOULD damp Leaf A-D routes… NEW Since Leaf A-D > > routes are used to discover Leaf PE of a P2MP tree, PEs SHOULD damp Leaf > A-D > > routes… END > > > > Section 8 > > > > Please avoid specifying code point values before IANA has allocated > them. If it's > > important that certain code points are used (for example, because of > fielded > > implementations) then please consider following the process to secure an > early > > allocation of these code points from IANA prior to publication as an > RFC. See > > https://www.rfc-editor.org/rfc/rfc7120. > > > > > >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
