I will change non-assigned values to TBD in the next revision. On Fri, Nov 15, 2024 at 8:48 AM Jonathan Hardwick < jonathan.e.hardw...@gmail.com> wrote:
> 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 >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
