Hi Pavan, thanks for your feedback!! You raised some important points, so lets me answer here:
ad1. it is obvious that extending range would be operationally challenging so planning must be done properly. And it is worthwhile to mention that explicitly! ad2. there are up to 128 possible values of FA (not mentioning 128 known values) so that cannot fit into proposed single nibble. So implicitly cannot be matched. So we will mention that explicitly. ad3. every addressing plan (no matter what is size of the network) must be done under single administrative entity, hence coordination is given. and there is section 6.3 covering that. ad4. anycast SID must come from anycast locator, so always GIB, and there are two options, either it is within single domain, and then it must follow domain addressing principles, and if it is needed for geo-redundancy it is by nature not summarizable. We can mention. that, but detailed anycast design is probably out of the scope of this document. Also importance of anycast SID is much lower in SRv6 than SR-MPLS ad5. there are several other documents focused on SRv6 security so i believe we should not interfere with those, but we should rather reference them both editorial comments are very valid! Thanks a lot again for detailed review!!! Cheers -j From: Vishnu Pavan Beeram <[email protected]> Date: Saturday, August 1, 2026 at 5:41 PM To: Dan Voyer IETF <[email protected]> Cc: [email protected] <[email protected]>; SPRING WG List <[email protected]> Subject: [SRv6OPS] Re: [spring] Working Group Adoption Call for draft-horn-srv6ops-srv6addressing-02 (ends 6 August 2026) 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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
