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*
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
