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> 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")?
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.
regards,
Ted Hardie
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
