Hi Suresh & authors / all I support publication of the draft as-is.
The details I mentioned are covered in other drafts as references so no need to duplicate them in this draft. After reviewing further and feedback from Robert I am on board with /16 block for GUA and no need for ULA. Kind Regards Gyan On Thu, Sep 29, 2022 at 2:24 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > > 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* > > -- <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
