Hi authors, all, I've reviewed draft-horn-srv6ops-srv6addressing-02 ahead of the WG adoption call. The document fills a real operational gap and the addressing hierarchy (Block/Set/Node) is well-thought-out. I have a few comments that I believe should be addressed:
*1. Extensibility principle vs. format migration* Section 3 states that the addressing plan "must be able to adapt as the organization and the network evolves." However, the three format variants use incompatible FA/Region nibble positions: - Small: `BBBB:BBBF:SSNN::` (FA at nibble 8) - Large: `BBBB:BBFR:SSNN::` (FA at nibble 7) - Very large: `BBBB:BFRR:SSNN::` (FA at nibble 6) An operator that starts with the "small" format and later needs regions cannot grow without renumbering — `5f00:0001:7543::/48` means "FA 1, Set 0x75, Node 0x43" in the small format, but "FA 0, Region 1, Set 0x75, Node 0x43" in the large format. The document should reconcile this tension — either by recommending that operators always use the large format regardless of current size (satisfying the extensibility principle at the cost of wasting 4 bits of Region space), or by explicitly acknowledging that adapting from one format to another requires renumbering (qualifying the extensibility principle with practical guidance on planning for projected growth). *2. FA ID mapping clarification* The examples show Algorithm 0 → FA ID 0, FA 128 → FA ID 1, FA 129 → FA ID 2. I understand the FA ID nibble in the address is purely an addressing plan convention for human readability and summarization — the IGP carries the algorithm association explicitly (RFC 9352, RFC 9513), so there is no protocol concern. However, since this document's purpose is to provide unambiguous addressing guidance for operators building their first SRv6 plans, consider stating whether the FA ID mapping is a specific recommended formula (e.g., algo 0 → ID 0; algo 127+N → ID N) or whether it is an operator-local choice. The current examples alone could be interpreted as either formula-based or sequential assignment. *3. Inter-domain considerations* The document covers "very large networks" with millions of devices. At that scale, abstraction boundaries and inter-domain separation are typically recommended. A brief scoping statement (e.g., "this document addresses single-SR-domain addressing; inter-domain coordination is out of scope and may be addressed in future work") would help set expectations for readers. *4. Anycast SID allocation* Anycast SIDs (same SID advertised by multiple nodes) are a common operational pattern for load-balancing and geo-redundancy. The document's addressing plan assigns unique Node IDs per device but doesn't discuss how anycast fits. Should anycast Node IDs be reserved from a specific range within a Set? Do they come from the GIB or LIB? Does a node participating in anycast need a unique Node ID in addition to the shared one? A brief subsection would be helpful. *5. Security Considerations* The structured addressing scheme recommended by this document makes node enumeration straightforward — an attacker with knowledge of the Block and Set structure can scan the predictable Node ID range to identify all SRv6-capable routers in a domain. Consider discussing mitigation strategies (e.g., sparse or randomized Node ID assignment, or referencing RFC 9602's guidance on filtering the locator range at SR domain boundaries). *Editorial:* - Section 6.2: "AOne possible mitigation" → "One possible mitigation" - The terms "SID Space" (Section 2) and "SRv6 Space" (Sections 4.6, 4.7) appear to be used interchangeably — please use one consistently. Overall I support adoption with the above items addressed. Regards, Pavan On Thu, Jul 23, 2026 at 12:58 AM Dan Voyer IETF <[email protected]> wrote: > Dear WG, > > This message starts a two-week Working Group adoption call for: > > Addressing Recommendations for SRv6 > draft-horn-srv6ops-srv6addressing-02 > > https://datatracker.ietf.org/doc/draft-horn-srv6ops-srv6addressing/ > > The document provides addressing recommendations for SRv6 deployments, > including structured and summarizable addressing plans for the NEXT-CSID > and REPLACE-CSID formats. > > Please review the document and indicate whether or not you support its > adoption by the SRv6OPS Working Group. > > When responding, please provide comments or reasons supporting your > position. Working Group adoption is not a vote; the chairs will consider > the technical discussion, alignment with the Working Group charter, and the > level of interest and energy available to progress the document. > > Please also indicate if you are willing to review the document, contribute > text, or otherwise help advance the work. > > Participants are reminded of the IETF IPR disclosure obligations described > in BCP 79. If you are aware of any IPR applicable to this document that has > not already been disclosed, please disclose it in accordance with IETF > procedures. > > This adoption call ends on 6 August 2026. > > Thanks, > > Dan > On behalf of the SRv6OPS chairs > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
