Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[Brian E Carpenter <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> 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