Re: [spring] 64-bit locators

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Mark,

Not the intention at all!

This thread started trying to fix a /64 locator with the following argument:

 “While you might save a IPv6 address space with more specific locators, the savings might not be worth the administrative headache.”

I don’t think that operators agree to the “administrative headache”. The example is LINE that has voluntarily deployed using a /96.
This does not mean that we should use a fixed /96. This does not mean that /96 is the optimal. However, this does mean that in the context of LINE it was their preferred option.
Each operator will have a different view, and as Robert said, what is best for X will not be for Y.

For this reason, in my opinion the best option is to keep it flexible and let the operators decide what to use. This is what is currently stated in the draft.

Happy Holidays,
Pablo.

From: Mark Smith <[e-mail]>
Date: Thursday, 19 December 2019 at 22:17
To: "Pablo Camarillo (pcamaril)" <[e-mail]>
Cc: Alexandre Petrescu <[e-mail]>, SPRING WG <[e-mail]>
Subject: Re: [spring] 64-bit locators


On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril), <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 19 December 2019 at 09:44
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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
    >     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
    >     https://www.ietf.org/mailman/listinfo/spring
    >
    >
    > _______________________________________________
    > spring mailing list
    > [e-mail]<mailto:[e-mail]>
    > https://www.ietf.org/mailman/listinfo/spring
    >

    _______________________________________________
    spring mailing list
    [e-mail]<mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring