Gyan, SRv6 could use ULA if it would start and stop within "limited domain".
But concept of SRv6 is from day one extended to start and end on end systems (user's host, mobile device, sensor etc ...) hence in those deployments is must use GUA. And with that if we are to use GUA in one case we could as well use it in all cases and relax need for ULA space. Thx, R. On Thu, Sep 29, 2022 at 6:16 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > Brian > > On Thu, Sep 29, 2022 at 5:50 AM Brian Carpenter < > brian.e.carpen...@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. > > 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. > > Thoughts? > >> >> Regards, >> Brian Carpenter >> (via tiny screen & keyboard) >> >> >> On Thu, 29 Sep 2022, 19:45 Gyan Mishra, <hayabusa...@gmail.com> wrote: >> >>> >>> >>> On Wed, Sep 28, 2022 at 11:31 PM Brian E Carpenter < >>> brian.e.carpen...@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 <furr...@gmail.com >>>> <mailto:furr...@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 >>>> > i...@ietf.org <mailto:i...@ietf.org> >>>> > Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 < >>>> https://www.ietf.org/mailman/listinfo/ipv6> >>>> > >>>> -------------------------------------------------------------------- >>>> > >>>> > -- >>>> > >>>> > <http://www.verizon.com/> >>>> > >>>> > *Gyan Mishra* >>>> > >>>> > /Network Solutions A//rchitect / >>>> > >>>> > /Email gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com>// >>>> > / >>>> > >>>> > /M 301 502-1347 >>>> > >>>> > / >>>> > >>>> > >>>> > >>>> > -------------------------------------------------------------------- >>>> > IETF IPv6 working group mailing list >>>> > i...@ietf.org >>>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> > -------------------------------------------------------------------- >>>> >>> -- >>> >>> <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >>> >>> >>> >>> *M 301 502-1347* >>> >>> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
