Re: [spring] 64-bit locators

On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> 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.
>

 [Gyan] For IPv6 addressing you can have any length prefix up to /128.  i
am all for flexibility with vlsm even though may not be widely used.

SRv6 SID encoding differs in that we had 3 fields
{locator;function;arguments} that I think it makes sense to be fixed in the
specification as Ron has brought up.

>From an operator perspective for programmability as SRv6 deployments with
or without centralized controller, fixed length of the 3 fields makes sense
so operators can easily craft ACLs for deployments.

I think we could go crazy with the sizing but I think since 64 bit boundary
exists today for slaac we could make the locator /64 as well is fine.  We
could split the other 2 fields evenly 32 bits each or make the function
longer.  I think we’ll defined sizing is important so SID addressing plan
is not chaotic.

>
>
>
>> 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
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com

www.linkedin.com/in/networking-technologies-consultant