Robert Understood.
This is for brown field existing LDPv6 core. The thought was migration from LDPv6 fo SRV6. So with LDPv6 it’s simple to go to SR-MPLS v6 as you are reusing the MPLS data plane. So I was thinking of using that a simple stepping stone to get to SRv6 end state. We would stay at SR-MPLSv6 phase and don’t have to rush to SRv6 as we now gain all the SR benefits of SR-TE per vrf coloring features, Ti-LFA FRR and flex algo etc. As SRv6 matures with the variety of SRH compression techniques to overcome MSD issues and those get flushed out and also with PPR-Preferred Path Routing etc all become standards we can then migrate to SRv6. Kind Regards Gyan On Wed, Jun 24, 2020 at 5:24 AM Robert Raszuk <[email protected]> wrote: > Gyan, > > > I was looking for just vanilla SR-MPLS support natively using IPV6 data > plane. > > MPLS is a data plane. There is no SR-MPLS using IPv6 data plane (with > exceptions of encap). > > Your choice of data planes are: > > IPv4 > IPv6 > MPLS > > SR-MPLS uses MPLS data plane (with exceptions of encap) not IPv6 data > plane. > > You can use any control plane to distribute SR-MPLS SIDs (or indexes for > that matter) and match it against SPT computed against your IGP topology > ... no problem here. > > But let's make sure we do not create more confusion here. > > Last if your ultimate goal is to migrate LDPv4 to SRv6 I find it strange > that you would even consider transition via SR-MPLS. IMHO no need. > > Cheers, > R. > > > > > > On Wed, Jun 24, 2020 at 8:56 AM Gyan Mishra <[email protected]> wrote: > >> >> Thanks Jeff >> >> I was looking for just vanilla SR-MPLS support natively using IPV6 data >> plane. >> >> After reading a bit I confirmed below that both address families IPv4 and >> IPv6 data planes are supported with SR-MPLS. >> >> That is exactly what I was looking for. >> >> >> When reading RFC 8402 Segment Routing Architecture specification it talks >> about the two flavors SR-MPLS reuse of MPLS LDPv4 data plane and with SRv6 >> use of IPv6 data plane. So I was under the impression that it was not >> supported. >> >> When I first read through RFC 8660 I skipped over the critical section >> 2.5.1 which goes into discussion about FEC encoding assuming that it was >> mentioned that both v4 and v6 data planes are supported. >> >> It would have been nice if that were more clearly stated explicitly then >> just assumed that IPv6 data plane is supported with SR-MPLS. >> >> So in RFC 8660 it does talk about IPv6 only in section 2.5.1 FEC >> encoding below: >> >> The address family is represented by 8 bits, where IPv4 is >> encoded as 100, and IPv6 is encoded as 110. These numerical >> values are mentioned to guide implementations. If other >> numerical values are used, then the numerical value of IPv4 >> MUST be less than the numerical value for IPv6. >> >> - All addresses are represented in 128 bits as follows: >> >> o The IPv6 address is encoded natively. >> >> o The IPv4 address is encoded in the most significant bits, >> and the remaining bits are set to zero. >> >> - All prefixes are represented by (8 + 128) bits. >> >> o A prefix is encoded in the most significant bits, and the >> remaining bits are set to zero. >> >> o The prefix length is encoded before the prefix in an 8-bit >> field. >> >> >> >> As far as the SR-MPLS / SRv6 interworking that is something to definitely >> dig into on a separate discussion on interesting use cases which there are >> few specifications on namely the one mentioned RFC 8663 SR-MPLS over IP >> using RFC 4023 MPLSoGRE removing GRE and using IPv6. There are also some >> controller based interworking options as well. >> >> >> Thanks for the reference to the nanog link on SR interworking. >> >> >> Gyan >> >> >> On Tue, Jun 23, 2020 at 7:30 PM Jeff Tantsura <[email protected]> >> wrote: >> > Gyan, >>> >>> In SR-MPLS, either over IPv4 or IPv6 the data-plane is MPLS (rfc8660) >>> If MPLS is tunneled over IP, e.g MPLS over GRE, MPLS over UDP, etc, then >>> data-plane is that of outer encapsulation - rfc8663 as the best example, >>> e.g outer header would be IPv4/IPv6+UDP >>> Since bindings (SIDs) need to be distributed, you’d need a label >>> distribution protocol, with IPv6 that would be IS-IS, OSPFv3 or BGP >>> (or controller based). >>> Vendor support for that is rather limited, I don’t recall any. >>> Other option to distribute label bindings over IPv6 would be LDPv6 + v6 >>> IGP, I recall Junos implementation, there could be more. >>> There’s quite interesting discussion on NANOG - >>> https://mailman.nanog.org/pipermail/nanog/2020-June/208111.html >>> >>> Hope this helps >>> >>> Cheers, >>> Jeff >>> >> On Jun 23, 2020, 1:52 PM -0700, Gyan Mishra <[email protected]>, >>> wrote: >>> >> >>> >>> Thanks Ron! >>> >>> Gyan >>> >>> On Tue, Jun 23, 2020 at 3:51 PM Ron Bonica <[email protected]> wrote: >>> >>> Gyan, >>>> >>>> >>>> >>>> You can signal SR-MPLS over a network that has IPv6 enabled, but does >>>> not have IPv4 enabled. >>>> >>>> >>>> >>>> Ron >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Juniper Business Use Only >>>> >>>> *From:* spring <[email protected]> *On Behalf Of* Gyan Mishra >>>> *Sent:* Tuesday, June 23, 2020 1:20 PM >>>> *To:* SPRING WG <[email protected]> >>>> *Subject:* [spring] Spring SR question?? >>>> >>>> >>>> >>>> *[External Email. Be cautious of content]* >>>> >>> >>>> >>>> >>>> >>>> All >>>> >>>> >>>> >>>> SR-MPLS utilizes IPv4 data plane and and can service v4 v6 edges 6to4 >>>> softwire mesh framework from the VPN overlay aspect... >>>> >>> >>>> >>>> Can SR-MPLS use IPV6 data plane? >>>> >>>> >>>> >>>> Reason why I am asking is that it is very simple to get from LDPv4 core >>>> to SR-MPLS core. >>>> >>>> >>>> >>>> However if you have an existing brown field SP core and your end goal >>>> is to get to SRv6 - how can you easily get there. >>>> >>>> >>>> >>>> So my thoughts are you can use SR-MPLS as a stepping stone so to speak >>>> to get to SRv6. >>>> >>>> >>>> >>>> To that end you could use Greg Mirsky draft of tunneling SR-MPLS in >>>> SRV6 interoperability and use other inter operability drafts. >>>> >>>> >>>> >>>> But let’s say you prefer to get from point A go point B seamlessly and >>>> native naturally without any translation. >>>> >>>> >>>> >>>> An analogy would be migratory to IPV6 instead of using translation >>>> technology tunnels you dual stand the entire network and use ds-lite or LSN >>>> or 6RD to close the gap. >>>> >>>> >>>> >>>> So my thoughts on getting to the “end state” SRv6 are we follows: >>>> >>>> >>>> >>>> MPLS LDPv4 >>>> >>>> >>>> >>>> MPLS LDPv6 >>>> >>>> >>>> >>>> SR-MPLS v6 >>>> >>>> >>>> >>>> Once you have a v6 core and you have decommissioned LDPv6 you now have >>>> the v6 data plan ready to go to get to SRv6 >>>> >>>> >>>> >>>> SRv6 >>>> >>>> >>>> >>>> Only caveat with this idea is I am not sure if SR-MPLS supports IPv6 >>>> data plane v6 label binding. >>>> >>>> >>>> >>>> >>>> >>>> Kind Regards >>>> >>>> >>>> >>>> Gyan >>>> >>>> >>>> >>>> -- >>>> >>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> >>>> >>>> >>>> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Q4s7bsLfxzuPcWXIRDIeAIPQEmMceA3IXDq3kMe-U3ICOTolz45wy2DnuOsEl42h$> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions Architect * >>>> >>>> >>>> >>>> *M 301 502-1347 13101 Columbia Pike >>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> >>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>* >>>> Silver >>>> Spring, MD >>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> >>>> >>>> >>>> >>> -- >>> >>> <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> >>> >>> *M 301 502-1347 13101 Columbia Pike >>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> >>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver >>> Spring, MD >>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> >>> >>> _______________________________________________ >>> spring mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+Silver+Spring,+MD?entry=gmail&source=g> >> *Silver >> Spring, MD >> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+Silver+Spring,+MD?entry=gmail&source=g> >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
