I support publication of the draft. I have reviewed the draft and have some comments.
As the C-SID draft had been adopted by Spring I don’t see a need for section 4.2 as is not relevant. Section 4 talks about C-SID which is vague as it should be referencing the two different vendor solutions below: Brief description of each flavor and operation I think is important for the draft. 1. Cisco uSID micro sid - Next function- Shift by 16 bits and forward at each node endpoint processing. The 128 bit DA is a uSID carrier can have up to 6 16 bit uSIDs encoded into the DA for steering up to 6 nodes without SRH. If desirable to steer to more then 6 nodes an SRH is required along with SR Policy with Segment list. 2. Huawei G-SID - Replace function - Copies G-SID from SRH to DA address at each node endpoint processing. G-SID operation requires SRH present. Most all deployments of SRV6 are done using ULA addressing RFC 4193. Even across the internet the internal P nodes in a carrier network can use RFC 4193 as along as the eBGP peering points use next hop self which avoids requiring next hop eBGP subnet accessibility. That being said subnets or even aggregate summary of the carrier network does not need to be advertised outside of the carrier networks domain. This draft proposed an IANA allocation /16 for the GUA address for the SRv6 block B:N deployment out of which the SRv6 locators are allocated. I understand the reasoning behind it to avoid advertisement of the locators outside of the domain. The IANA allocation does not mention that the block should be made non internet routable like a ULA. If the /16 block is allocated but it’s internet routable and no different then any other GUA there is nothing that would prevent the leaking of the SRV6 SIDs to the internet security concern. We should qualify the IANA request to make the /16 non internet routable identical to ULA addressing. If that is what we desire then why don’t we make it standard BCP to always use ULA for the operators SRV6 domain. We would not have to burn up a /16 unnecessarily. Kind Regards Gyan On Sat, Sep 17, 2022 at 4:00 AM Jen Linkova <furr...@gmail.com> wrote: > Hello, > > This email starts the 6man Working Group Last Call for the "Segment > Identifiers in SRv6" draft > (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids). > > The WGLC ends on Tue, Oct 4, 23:59:59 UTC. > > As the document is closely related to the work in the SPRING WG, we'd > like the SPRING WG to review the document and discuss the following > questions: > > - the action items required from SPRING (Section 4.1 and 4.2 of the > draft, > https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4) > [*]. Would it make sense to merge those open issues with the 'Open > Issues' section of > the SPRING document? > - whether the document needs more guidance regarding routability of > /16 or such requirements shall belong to some other document? In > particular, shall we specify that it MUST NOT be in the DFZ? Or > setting 'Globally Reachable = false' in the registry should be > sufficient? The current idea is that the prefix needs to fail closed > and not be routable by default. > > [*] The draft currently refers to the individual submission instead of > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ > - the link will be updated in the next revision. > > Please review the draft and send your comments to the list/ > > -- > SY, Jen Linkova aka Furry > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
