Re: [spring] 64-bit locators

On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril), <pcamaril@cisco.com>
wrote:

> Hi,
>
> As mentioned in the draft, the choice of the locator length is deployment
> specific.
> LINE has deployed SRv6 using a locator different than a /64.
>

This is effectively an appeal to authority.

What makes what LINE has done the best and right thing to do?

I can already see they're using the IPv4 link-local 169.254/16 prefix in a
manner that wildly violates how it is specified to be used in RFC3927. See
Slides 9, 12, 24.

Tying your IPv6 addressing plan to IPv4 addressing could end up imposing
IPv4's addressing limitations on IPv6 - defeating the primary purpose of
IPv6 - providing many more addresses than IPv4.

Slide 32 shows they're violating RFC 4193 (IPv6 ULAs), because they're
using ULA-Cs ('fc') rather than ULA-Ls ('fd'), despite there being no
central registry.  Their 40 bit Global ID of "17" could be random, although
I'm guessing not, as random numbers would usually have far less zeros in
them. These sorts of ULA errors are why I presented "Getting IPv6
Addressing Right" at AusNOG this year -
https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right
 .

This is an Internet Draft, so this is the best time to make these sorts of
changes, as it is much easier now. When things become RFCs it becomes much
harder (and much, much harder when they become Internet Standards).

If somebody has deployed Internet Draft level technology, they have to
accept the risk that what they've deployed might not comply with the
eventual RFC.

Regards,
Mark.

> Cheers,
> Pablo.
>
> [1]
> https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6
>
> -----Original Message-----
> From: spring <spring-bounces@ietf.org> on behalf of Alexandre Petrescu <
> alexandre.petrescu@gmail.com>
> Date: Thursday, 19 December 2019 at 09:44
> To: "spring@ietf.org" <spring@ietf.org>
> Subject: Re: [spring] 64-bit locators
>
>
>
>     Le 19/12/2019 à 00:13, Mark Smith a écrit :
>     [...]
>
>     > VLSM [variable length subnet mask] is fundamentally hard,
>
>     We need VLSM in other places too, such as in ULA prefixes fd and fc.
>
>     I think it is indeed a difficult to grasp concept, but it is there for
>     growth.
>
>     Alex
>
>     >
>     > Regards,
>     > Mark.
>     >
>     >     __
>     >
>     >     In this case, we should probably change the document to reflect
>     >     implemented behavior.____
>     >
>     >     __ __
>     >
>     >
>     >
>     Ron____
>     >
>     >     __ __
>     >
>     >
>     >     Juniper Business Use Only
>     >
>     >     _______________________________________________
>     >     spring mailing list
>     >     spring@ietf.org <mailto:spring@ietf.org>
>     >     https://www.ietf.org/mailman/listinfo/spring
>     >
>     >
>     > _______________________________________________
>     > spring mailing list
>     > spring@ietf.org
>     > https://www.ietf.org/mailman/listinfo/spring
>     >
>
>     _______________________________________________
>     spring mailing list
>     spring@ietf.org
>     https://www.ietf.org/mailman/listinfo/spring
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>