On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <markzzzsm...@gmail.com> wrote:
>
>
> On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril), <pcama...@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-boun...@ietf.org> on behalf of Alexandre Petrescu <
>> alexandre.petre...@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.mis...@verizon.com
www.linkedin.com/in/networking-technologies-consultant
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
