Fixed length of any field LOC:FUNC:ARGs makes no sense to me. What is
optimal for Ron or Mark may not be optimal for me.
While we are at that fixed size of 128 bits of IPv6 also makes no sense -
but that vessel left the harbour a while ago.
Cheers,
R.
On Thu, Dec 19, 2019 at 10:57 PM Gyan Mishra <hayabusa...@gmail.com> wrote:
>
>
> 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
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
