Re: [spring] Spring SR question??

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>,
>> wrote:
>>
>>
>>
>> Thanks Ron!
>>
>> Gyan
>>
>> On Tue, Jun 23, 2020 at 3:51 PM Ron Bonica <[e-mail]> 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 <[e-mail]> *On Behalf Of* Gyan Mishra
>>> *Sent:* Tuesday, June 23, 2020 1:20 PM
>>> *To:* SPRING WG <[e-mail]>
>>> *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> * 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> *Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>