Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

----
nb

On Thu, Sep 29, 2022 at 11:16 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Brian
>
> On Thu, Sep 29, 2022 at 5:50 AM Brian Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>
>> No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve
>> for the dreamt-of centrally registered ULA prefixes, and fd00::/8 is fully
>> committed.
>>
>> If SRV6 is important, it could justify its own prefix.
>>
>
>
>    Gyan> As using either GUA or ULA for SRV6 block provides flexibility
> for operators, I agree that SRv6 can justify its own global block as the
> /16 being allocated with this draft.  I think we should augment the draft
> to add a dedicated ULA bock maybe same /16 size would be reasonable.  Since
> there is not an IANA ULA registry since ULA is private, as the compressed
> SID violates RFC 4291, I think maybe a draft at least that defines the
> dedicated /16 block for ULA for SRV6 use is a good idea.
>

I would caution against use of ULA for this for a number of reasons, not
the least of which is the fact that ULA is allocated as Brian mentioned
prior. A dedicated block solves both the issue of potential overlap with
site specific use of ULA (which admittedly is probably unlikely), but also
creates a clear visual indicator as well as an easier programmatic
implementation by using something that should never occur elsewhere in the
network topology. Also, using non GUA blocks further complicates
inter-domain efforts which is not a show stopper, but is definitely notable
in that SR block allocation now needs to be coordinated further than
internally.

>
> One of the major benefits as I mentioned for ULA over GUA is that ULA is
> not internet routable and that mitigates any possibility of security issues
> with SRV6 SID leaking to the internet.
>

This is a legitimate use case, and with the lack of SRH4 filtering
capabilities in platforms I have looked at (admittedly not everything) this
is an operational concern, however, I suspect that will be addressed and
should be part of a best practices recommendation for anyone not attempting
to do inter-domain SRv6 provisioning regardless of SRv6 SID choices.  It
feels a little like the model of using RFC1918 space as a mechanism to
further "air-gap" the control plane - which I have totally done in the
past, so no judgement - just an observation. Not illegitimate, but
definitely needs a bit of forethought, which in many cases it does not get.
As an operator, my response would be "why not both?". A dedicated block of
*non-ULA* space for use when required / desired and perhaps a bit of
verbiage on operational considerations for filtering at network edges when
GUA is in play?  Similar concerns are covered in section 4.1 but stop short
of filtering the header.***

*** my experience with this is largely lab-focused and incomplete
having only tested a few platforms and software packages, so I fully admit
that I may be missing information or misunderstanding. IIRC, one platform
could filter RH0 and none did 4.

> Thoughts?
>
>>
>> Regards,
>>     Brian Carpenter
>>     (via tiny screen & keyboard)
>>
>>
>> On Thu, 29 Sep 2022, 19:45 Gyan Mishra, <hayabusagsm@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Sep 28, 2022 at 11:31 PM Brian E Carpenter <
>>> brian.e.carpenter@gmail.com> wrote:
>>>
>>>> On 29-Sep-22 16:06, Gyan Mishra wrote:
>>>> ...
>>>>
>>>> > We should qualify the IANA request to make the /16 non internet
>>>> routable identical to ULA addressing.
>>>> >
>>>> > If that is what we desire then why don’t we make it standard BCP to
>>>> always use ULA for the operators SRV6 domain.
>>>>
>>>> I don't believe that a /48 would be enough, but it is required, to
>>>> conform with RFC4193.
>>>
>>>
>>>     Gyan> Understood.  Most operators would like to use ULA for SRV6
>>> deployments so do we need to carve out block out of ULA space just as we
>>> are doing for GUA to conform with RFC 4291.  ULA has is a big enough block
>>> FC00::/7 so we could carve a block out of that.  Does not need to be as
>>> large a block allocation for SIDs as it would not be advertised to the
>>> internet does not require to be globally unique.
>>>
>>>>
>>>>
>>>>     Brian
>>>>
>>>> > We would not have to burn up a /16 unnecessarily.
>>>> >
>>>> >
>>>> > Kind Regards
>>>> >
>>>> > Gyan
>>>> >
>>>> > On Sat, Sep 17, 2022 at 4:00 AM Jen Linkova <furry13@gmail.com
>>>> <mailto:furry13@gmail.com>> wrote:
>>>> >
>>>> >     Hello,
>>>> >
>>>> >     This email starts the 6man Working Group Last Call for the
>>>> "Segment
>>>> >     Identifiers in SRv6" draft
>>>> >     (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids <
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids>).
>>>> >
>>>> >     The WGLC ends on Tue, Oct 4, 23:59:59 UTC.
>>>> >
>>>> >       As the document is closely related to the work in the SPRING
>>>> WG, we'd
>>>> >     like the SPRING WG to review the document and discuss the
>>>> following
>>>> >     questions:
>>>> >
>>>> >     - the action items required from SPRING (Section 4.1 and 4.2 of
>>>> the
>>>> >     draft,
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4
>>>> <
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4
>>>> >)
>>>> >     [*]. Would it make sense to merge those open issues with the 'Open
>>>> >     Issues' section of
>>>> >     the SPRING document?
>>>> >     -  whether the document needs more guidance regarding routability
>>>> of
>>>> >     /16 or such requirements shall belong to some other document?  In
>>>> >     particular,  shall we specify that it MUST NOT be in the DFZ? Or
>>>> >     setting 'Globally Reachable = false' in the registry should be
>>>> >     sufficient? The current idea is that the prefix needs to fail
>>>> closed
>>>> >     and not be routable by default.
>>>> >
>>>> >     [*] The draft currently refers to the individual submission
>>>> instead of
>>>> >
>>>> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
>>>> <
>>>> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
>>>> >
>>>> >       - the link will be updated in the next revision.
>>>> >
>>>> >     Please review the draft and send your comments to the list/
>>>> >
>>>> >     --
>>>> >     SY, Jen Linkova aka Furry
>>>> >
>>>> >
>>>>  --------------------------------------------------------------------
>>>> >     IETF IPv6 working group mailing list
>>>> >     ipv6@ietf.org <mailto:ipv6@ietf.org>
>>>> >     Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6 <
>>>> https://www.ietf.org/mailman/listinfo/ipv6>
>>>> >
>>>>  --------------------------------------------------------------------
>>>> >
>>>> > --
>>>> >
>>>> > <http://www.verizon.com/
>>>> <https://streaklinks.com/BOgeQnbdXQqEXVeasQZb5BE-/http%3A%2F%2Fwww.verizon.com%2F>
>>>> >
>>>> >
>>>> > *Gyan Mishra*
>>>> >
>>>> > /Network Solutions A//rchitect /
>>>> >
>>>> > /Email gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>//
>>>> > /
>>>> >
>>>> > /M 301 502-1347
>>>> >
>>>> > /
>>>> >
>>>> >
>>>> >
>>>> > --------------------------------------------------------------------
>>>> > IETF IPv6 working group mailing list
>>>> > ipv6@ietf.org
>>>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> > --------------------------------------------------------------------
>>>>
>>> --
>>>
>>>
>>> <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>>
>>>
>>>
>>> *M 301 502-1347*
>>>
>>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
ᐧ