Hi Robert Understood and agreed. I see what you are saying.
I was just thinking of ULA with added flexibility in mind. Kind Regards Gyan On Thu, Sep 29, 2022 at 1:01 PM Robert Raszuk <rob...@raszuk.net> wrote: > 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 >> -------------------------------------------------------------------- >> > -- <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*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
