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

[Suresh Krishnan <[e-mail]>]

Hi Ed/Nick/Mark/Michael/Robert/Gyan,
  I have noted the valuable points you brought up regarding the format, and operational properties of the prefix. They are all extremely relevant to the discussion of the operational guidelines mentioned at the end of section 5. I will try to put these together for a potential presentation for discussion during IETF 115 (venue TBD).

Thanks
Suresh

> On Oct 4, 2022, at 1:27 PM, Vasilenko Eduard <[e-mail]> wrote:
> 
> Does it make sense to develop prefix randomization inside this new SRv6 block? (like for fd/8)
> Or else it may happen the same as for fc/8 – it is not used because no one organization has been found to accept the registry duties.
> Ed/
> From: ipv6 [mailto:[e-mail]] On Behalf Of Nick Buraglio
> Sent: Tuesday, October 4, 2022 6:44 PM
> To: Gyan Mishra <[e-mail]>
> Cc: SPRING WG List <[e-mail]>; 6man <[e-mail]>; [e-mail]; [e-mail]; 6man Chairs <[e-mail]>
> Subject: Re: 6MAN WGLC: draft-ietf-6man-sids
>  
> 
> ----
> nb
>  
>  
> On Thu, Sep 29, 2022 at 11:16 AM Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
> Brian
>  
> On Thu, Sep 29, 2022 at 5:50 AM Brian Carpenter <[e-mail] <mailto:[e-mail]>> 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 ofnon-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, <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
> On Wed, Sep 28, 2022 at 11:31 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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><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> <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/> <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
> >     [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6><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 [e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>//
> > /
> > 
> > /M 301 502-1347
> > 
> > /
> > 
> > 
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail] <mailto:[e-mail]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> > --------------------------------------------------------------------
> -- 
>  <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
> Gyan Mishra <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
> Network Solutions Architect  <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
> Email [e-mail] <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
> M 301 502-1347 <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
>   <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
> -- <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
>  <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>Gyan Mishra
> Network Solutions Architect 
> Email [e-mail]
> M 301 502-1347
> 
>  <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
>   <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>
> ᐧ <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F>