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

[Nick Buraglio <[e-mail]>]

On Wed, May 18, 2022 at 11:29 AM Bob Hinden <[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.
>

I agree with this, however, would the conventions be any different than a
typical SRv6 deployment with any other IPv6 block? There has been some
offline chat about a BCP for allocation and configuration of SRv6 for
locator blocks, filtering, potential inter-domain interactions, etc. I
suspect that document could come together fairly quickly by building on a
few existing deployments and some vendor provided documentation.


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

Apologies, this is a bit stream-of-consciousness:
I have created a locator block with ULA in my lab and didn't see any real
issues, but also did not really exercise it to the fullest extent that it
probably needs, and I was using FRR and FreeRTR systems rather than
conventional vendor provided routing platforms. I can definitely see the
advantages as laid out in the draft, filtering for a sub-set of a block
that really does not need to be in the DFZ can be a bit cumbersome and much
gear seems to lack the ability to filter just RH4, last I looked. Since it
is not within the data plane, I suppose it may be doable in production, but
I would be wary of the tenuous code paths that seems to exist surrounding
that block of address space, especially in embedded systems that
non-vendors have no real visibility into, outside of running FOSS routers
with FRR, etc. In theory it *should* work, but I would be unsurprised if
that was a pandora's box making it difficult to operationalize in a timely
manner.

nb



>
> Bob
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
ᐧ