On Thu, 29 Sept 2022 at 19:51, 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. > I think SRv6 must have its own prefix. SIDS that are copied into IPv6 addresses in RFC 8986 have a different format, field names, field semantics and forwarding methods verses previous IPv6 addressing and forwarding in RFC4291, RFC4193 etc. I think the only way to be able to create a new IPv6 address format that has new and different attributes is to have a new well known prefix for it. Multicast (FF00::/8), ULA (FC00::/8), Link-Locals (FE80::/10) and Discard-Only (100::/64) are all examples. I'd also suggest a centralised registry for these SRv6 prefixes, or at least a pseudo random embedded id similar to ULAs, to avoid SRv6 prefix collisions if SR domains/networks merge. NAT/NPT on SRv6, including on SIDs/IPv6 addresses in the SRH itself, is not pleasant to think about, nor is renumbering a well established SID address space/SR domain. Regards, Mark. > > 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* >> >> -------------------------------------------------------------------- > 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
