Re: Allocation of a Global Prefix (Re: I-D Action: draft-ietf-6man-sids-01.txt)

[Erik Kline <[e-mail]>]

(no hats) fwiw, I believe the next unicast /16 (for example) working "down"
from ULA space would be fbff::/16 (although my reckoning might be wrong).

On Wed, May 18, 2022 at 5:25 PM Suresh Krishnan <[e-mail]>
wrote:

> I am with Brian and Ted as well. I think one of the useful properties of a
> separate prefix rather than using ULAs is to differentiate the SRv6 usage
> from regular ULA usage and help with filtering at the edges. Also as Ted
> said upthread having an allocation would allow operators to write up the
> guidelines based on deployment experiences.
>
> Regards
> Suresh
>
> On Wed, May 18, 2022 at 6:14 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> I think Ted's analysis is correct. We already have issues in making ULAs
>> convenient to use, as discussed over on v6ops, so I think using them for
>> SIDs would complicate things in an unhelpful way.
>>
>> Regards
>>     Brian Carpenter
>>
>> On 19-May-22 06:21, Ted Hardie wrote:
>> > Hi Bob,
>> >
>> > On Wed, May 18, 2022 at 5:29 PM Bob Hinden <[e-mail]
>> <mailto:[e-mail]>> wrote:
>> >
>> >     Suresh,
>> >
>> >     In Section 5.  Allocation of a Global Unicast Prefix for SIDs the
>> draft discussed the use of a dedicated prefix for SR domains.   I think
>> that is an interesting idea, however it then says:
>> >
>> >         The SRv6 operational community, which is the first intended
>> user of
>> >         this block, is requested to come up with conventions and
>> guidelines
>> >         for the use of this newly allocated address block in line with
>> their
>> >         requirements.
>> >
>> >     I think the notion of doing the allocation first and then come up
>> with conventions and guidelines for how to use it is problematic.   I think
>> it needs to be the other way around, as well as probably combining it with
>> the IANA request for a prefix.
>> >
>> > The converse problem, of course, is that if you try to create
>> conventions and guidelines before you have any allocation you may end up
>> with significant aspects of the deployed reality that aren't reflected.  At
>> least in my experience, operational reality tends to throw some curveballs
>> at you that didn't occur in labs or simulations.
>> >
>> > I think the major point here is to allow SIDs traffic to be easily
>> distinguished from other traffic; any allocation gets that done.  So the
>> first guideline might be "use this prefix when that need is present".
>> I think any other guidelines need to be almost at that same level of
>> generality at this stage, and that we'll see detailed conventions and best
>> practices emerge after there is more experience.
>> >
>> >     I have also been wondering if ULAs could be used for this purpose.
>>  I think they have most of the right properties, that is, not intended for
>> global routing and easily filtered at administrative boundaries.   An SR
>> domain could allocate one or more ULA prefixes. Or it might be time to
>> define the centrally allocated ULA-C part of the ULA space.
>> >
>> >
>> > Since there are non-SIDs ULAs, I think using the currently defined
>> space misses the primary goal of distinguishing the usage type, or at least
>> makes it harder to achieve.
>> >
>> > I don't think setting up a new central registry is a goal here.   While
>> ULA-C space could be redefined as not requiring a central registry, I
>> believe it is simpler to use new space and define what principles govern it
>> rather than redefining something that was set aside for a different purpose.
>> >
>> > Just my take on it,  of course,
>> >
>> > Ted Hardie
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> >
>>
>> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>