On Sat, 31 Aug 2019 at 14:05, Zafar Ali (zali) <[email protected]> wrote: > > Dear Chairs and the WG: > > > > The SRv6 network programming solution and its SRH encapsulation is > implemented on 12 hardware platforms including Merchant Silicon. > > Multiple providers have deployed the SRv6 network programming solution and > its SRH encapsulation with line-rate performance carrying a significant > amount of commercial traffic. > > Several independent interoperability reports documenting successful > interoperability of implementation from multiple vendors exist. > > Implementation, deployment, and interoperability status is publicly > documented in > https://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt. > > > > Most use-cases are expected to use very few SRv6 segments. > > > > In some specific use-cases, one may desire to optimize the MTU usage further. > > The SRv6 network programming solution and its SRH encapsulation also support > for this Optimization, through the uSID network instruction. > >
If I understand it correctly, the idea is that uSIDs are encoded in the remaining bits of an IPv6 destination addresses, below a single high order aggregate prefix? If that is the case, then I think there are a number of issues with this proposal. Firstly, there are defined fields below the upper aggregate prefix for all IPv6 address formats. They are not available for arbitrary use. For the Link-Local Address, the bits between /10 and /64 are specified to be set to zero. The ULA prefix defines a fields up until /64. The most important one is the 40 bit Global ID field, between /8 and /48, which is required to be pseudo-random to attempt to avoid address space collision when two ULA domains are merged. A shorter than /48 ULA prefix impacts this important property. For both Global Unicast Addresses and ULA addresses, the bits between /48 and /64 are designated the Subnet ID field. Below that, for GUA, ULA and LLA, the following and lower 64 bits of an IPv6 address is the 64 bit Interface Identifier (IID) field. RFC 7136, "Significance of IPv6 Interface Identifiers", removed requirement for the IID field to have a modified EUI-64 value, allowing that field to be treated as an opaque 64 bit quantity generally, and to allow end-hosts or protocols to place significance on bits within the IID field if they chose to. So I think uSIDs could only be legitimately placed in the lower 64 bit IID field. There are however reserved IID values, so any combination of uSID values would not be able to result in any of these reserved IID values. "Reserved IPv6 Interface Identifiers" https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml For all these above IPv6 address format details, and others, see RFCs 4291 (GUA, LL) and 4193 (ULA). Regards, Mark. > > I do not see the need for any new encapsulation work. > > > > Thanks > > > > Regards … Zafar > > > > From: spring <[email protected]> on behalf of Rob Shakir > <[email protected]> > Date: Sunday, August 4, 2019 at 5:04 PM > To: SPRING WG List <[email protected]> > Subject: [spring] Beyond SRv6. > > > > Hi SPRING WG, > > > > Over the last 5+ years, the IETF has developed Source Packet Routing in > NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 > (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE. > > > > These encapsulations are past WG last call (in IESG or RFC Editor). > > > > During the SPRING WG meeting at IETF 105, two presentations were related to > the reduction of the size of the SID for IPv6 dataplane: > > > SRv6+ / CRH -- > https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04 > > > uSID -- > https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01 > > > > > During the IETF week, two additional drafts have been proposed: > > > https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 > > > https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03 > > > > > As we expressed during the meeting, it is important for the WG to understand > what the aims of additional encapsulations are. Thus, we think it is > important that the WG should first get to a common understanding on the > requirements for a new IPv6 data plane with a smaller SID - both from the > perspective of operators that are looking to deploy these technologies, and > from that of the software/hardware implementation. > > > > Therefore, we would like to solicit network operators interested in SR over > the IPv6 data plane to briefly introduce their: > > > use case (e.g. Fast Reroute, explicit routing/TE) > > > forwarding performance and scaling requirements > > > > e.g., (number of nodes, network diameter, > number of SID required in max and average). For the latter, if possible using > both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the number would > typically be different (*). > > > > if the existing SRv6 approach is not deployable > in their circumstances, details of the requirement of a different solution is > required and whether this solution is needed for the short term only or for > the long term. > > > > > As well as deployment limitations, we would like the SPRING community to > briefly describe the platform limitations that they are seeing which limit > the deployment of SRv6 In particular limitations related to the number of > SIDs which can be pushed and forwarded and how much the use of shorter SIDs > would improve the deployments . > > > > For both of these sets of feedback if possible, please post this to the > SPRING WG. If the information cannot be shared publicly, please send it > directly to the chairs & AD (Martin). > > > > This call for information will run for four weeks, up to 2019/09/03. As a > reminder, you can reach the SPRING chairs via [email protected] and ADs > via [email protected]. > > > > Thank you, > > -- Rob & Bruno > > > > (*) As expressed on the mailing list, a 128 bit SID can encode two > instructions a node SID and an adjacency SID hence less SID may be required. > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
