Ted, On 18-Oct-21 20:22, Ted Hardie wrote: > Hi Brian, > > Thanks for the additional clarification. I've cut below to the meat of what > I understand to be your question: > > > On Sat, Oct 16, 2021 at 10:19 PM Brian E Carpenter > <brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote: > > > I want to draw a distinction between unicast address bits that are > arbitrary numbers as far as > the routing system is concerned -- such as the classical IID bits in IPv6 > unicast addresses, or the prefix bits following fc00::/7 -- and address > bits that are meaningful to the routing system, such as fe80::/10 (which > means "do not route this packet"). > > Within an SRV6 domain, with RFC8986 and the current draft, we see > something new: a field which has classically been an arbitrary 64-bit number > for > the routing system (the IID field) becomes meaningful to the routing > system. That's an architectural change, and definitely was not envisaged by > the IPv6 address architecture. > > So, IMHO, the question behind SPRING's question to 6MAN is not whether > there is an architectural change, but whether this changes matters. In > particular, will it have impact on legacy devices and software within the > SRV6 domain, and will it do any damage if it leaks outside the domain? > > > Do I understand correctly that you see the same architectural question for > RFC 8986 ("will it have an impact on legacy devices and software within the > SRV6 domain and will it do any damage if it leaks outside the domain")?
Yes, indeed. It's a bit clearer in my mind now than when we were debating that RFC as a draft, but it certainly applies there too. > > Presuming so, the question for RFC 8986 seems to me to be answered within the > document with a reference to rfc8754, Section 5, which has the deployment > model for segment routing spelled out. Would a similar applicability > statement here be something that helps resolve this? At least as far as I > can tell, a shift in the formatting to a compressed format doesn't change the > basic difference you call out, so I believe that it would be very similar if not identical. But it certainly does no harm to spell that out. In fact the current draft says (section 3): >> The compressed Segment List encoding is fully compliant with the >> specifications in [RFC8402], [RFC8754] and [RFC8986] so from a logical point of view, it doesn't appear essential to add this. However, it might well help future readers to do so. Thanks Brian _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
