---- nb
On Thu, Sep 29, 2022 at 11:16 AM 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. > 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, <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/ >>>> <https://streaklinks.com/BOgeQnbdXQqEXVeasQZb5BE-/http%3A%2F%2Fwww.verizon.com%2F> >>>> > >>>> > >>>> > *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 >>>> > -------------------------------------------------------------------- >>>> >>> -- >>> >>> >>> <https://streaklinks.com/BOgeQnTTkwXl56xfuw7ho9oP/http%3A%2F%2Fwww.verizon.com%2F> >>> >>> *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
