Subject: [bess] SRv6 versus SR-MPLS

From: Gyan Mishra <[email-masked]>
Date: Fri, 4 Oct 2019 20:22:57 -0400

Bess,

What is the benefit of SRv6 over SR-MPLS for greenfield deployments or existing mpls deployments.

Regards,

Gyan Mishra 
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

Sent from my iPhone

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 5 Oct 2019 01:02:22 -0400

In line possible answers 

Sent from my iPhone

> On Oct 4, 2019, at 8:22 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> Bess,
> 
I think I answered my own question but please chime in with your thoughts..

This NANOG document talks about the state of TE with providers and currently the big show stopper with SRv6 which removes it off the table as a possibility is the SID depth and larger packet size given that customers are set to 9100 and the core is 9216 so when adding in mpls overhead vpn labels and Ti-LFA EH insertion at PLR node to PQ node that adding in the entire SID list for long TE paths that have huge SID depth makes SRv6 not viable at this point.

https://pc.nanog.org/static/published/meetings/NANOG73/1646/20180627_Gray_The_State_Of_v1.pdf

For existing implementations it appears from my research a no brainer to go with SR-MPLS as that is a painless seamless migration but SRv6 due to SID depth issues and given limited head room from customer MTU to the  backbone MTU today we are over the limit with larger SID depth for Ti-LFA paths or non protected paths.  Until that is addressed SRv6 unfortunately may not get much traction with service providers which I think due to the SRv6 issues ....uSID and SRv6+ may tend to be more viable and more attractive.

---

From: Lizhenbin <[email-masked]>
Date: Sat, 5 Oct 2019 09:35:31 +0000

Hi Gyna,

We proposed following the draft which has relation with your question. Hope it may be helpful.

https://tools.ietf.org/html/draft-xie-spring-srv6-network-migration-00

From my point of view, one of the best advantages of SRv6 is easy incremental deployment.

I believe there will more deployments of SRv6 soon.

Best Regards,

Zhenbin (Robin)

________________________________
发件人: BESS [[email-masked]] 代表 Gyan Mishra [[email-masked]]
发送时间: 2019年10月5日 8:22
收件人: [email-masked]
主题: [bess] SRv6 versus SR-MPLS

Bess,

Regards,

Gyan Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> FDC1 3rd Floor
<https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>Silver Spring, MD 20904<https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>
United States<https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>
Phone: 301 502-1347<tel:301%20502-1347>
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>

Sent from my iPhone

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 5 Oct 2019 13:23:05 +0200

IMHO the question of SR-MPLS vs SRv6 is wrong as it all depends what are
you trying to accomplish in your network and what services you need to run
on it.

For example some networks need TE some do not.

Some may like to carry L2/L3VPNs some do not.

Some may think about requirements associated with special packet handling
perhaps augmented with in house development of P4 based fancy services so
do not.

Last some network are IPv4 only, some are IPv4+MPLS, some may be dual stack
and some may be IPv6 only.

For some the overhead associated with attaching additional data to each
packet matters - so do not care and do not even realize it :).

So this is very loaded question. It is like asking should I go left or
should I go right without stating your ultimate destination. Sure likely
you may end up there regardless how you turn but it may not be optimal
path.

And last as this is BESS WG ... I would really seriously consider for BESS
services use of RFC4797 and RFC7510.

Cheers,
R.

On Sat, Oct 5, 2019 at 11:35 AM Lizhenbin <[email-masked]> wrote:

> ------------------------------
> *发件人:* BESS [[email-masked]] 代表 Gyan Mishra [[email-masked]]
> *发送时间:* 2019年10月5日 8:22
> *收件人:* [email-masked]
> *主题:* [bess] SRv6 versus SR-MPLS
>
>
> Bess,
>
> 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> FDC1
> 3rd Floor
>
> <https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>Silver Spring, MD
> 20904 <https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>
>
> United States <https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>
>
> Phone: 301 502-1347
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Sat, 5 Oct 2019 16:11:18 +0200

I second Robert.

SRv6 is yet another tool in the overall toolset, and, as with every tool, there are situations (use cases) where using this particular tool might be the optimal solution, whereas there are use cases, where other tools do the job better, and, there are use cases where using this particular tools is complete misunderstanding. There as are as well use cases, where combinations of multiple tools bring the best effect.

Thanks,
Krzysztof

> On 2019-Oct-05, at 13:23, Robert Raszuk <[email-masked]> wrote:
> 
> 
> IMHO the question of SR-MPLS vs SRv6 is wrong as it all depends what are you trying to accomplish in your network and what services you need to run on it.
> 
> Some may think about requirements associated with special packet handling perhaps augmented with in house development of P4 based fancy services so do not.. 
> 
> Last some network are IPv4 only, some are IPv4+MPLS, some may be dual stack and some may be IPv6 only. 
> 
> For some the overhead associated with attaching additional data to each packet matters - so do not care and do not even realize it :).. 
> 
> So this is very loaded question. It is like asking should I go left or should I go right without stating your ultimate destination. Sure likely you may end up there regardless how you turn but it may not be optimal path. 
> 
> And last as this is BESS WG ... I would really seriously consider for BESS services use of RFC4797 and RFC7510. 
> 
> Cheers,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sat, Oct 5, 2019 at 11:35 AM Lizhenbin <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Gyna,
> 
> https://tools.ietf.org/html/draft-xie-spring-srv6-network-migration-00 <https://tools.ietf.org/html/draft-xie-spring-srv6-network-migration-00>
>  
> 发件人: BESS [[email-masked] <mailto:[email-masked]>] 代表 Gyan Mishra [[email-masked] <mailto:[email-masked]>]
> 发送时间: 2019年10月5日 8:22
> 收件人: [email-masked] <mailto:[email-masked]>
> 13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> FDC1 3rd Floor
>  <https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>Silver Spring, MD 20904 <https://imailcn01.huawei.com/owa/UrlBlockedError.aspx>
> Phone: 301 502-1347 <tel:301%20502-1347>
> Email: [email-masked] <mailto:[email-masked]>
> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> 
> Sent from my iPhone
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/bess <https://www.ietf.org/mailman/listinfo/bess>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 5 Oct 2019 16:44:12 -0700

Hi Gyan,
you're asking very good questions and your arguments are all correct. But I
think that now there are several proposals that address what is considered
the scalability issue of SRv6. Among these is the Unified SID for SRv6
<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/>. U-SID
benefits from all the advantages SRH provides while adding a higher density
of SIDs thus allowing stricter path control.

Regards,
Greg

On Fri, Oct 4, 2019 at 10:02 PM Gyan Mishra <[email-masked]> wrote:

> This NANOG document talks about the state of TE with providers and
> currently the big show stopper with SRv6 which removes it off the table as
> a possibility is the SID depth and larger packet size given that customers
> are set to 9100 and the core is 9216 so when adding in mpls overhead vpn
> labels and Ti-LFA EH insertion at PLR node to PQ node that adding in the
> entire SID list for long TE paths that have huge SID depth makes SRv6 not
> viable at this point.
>
>
> For existing implementations it appears from my research a no brainer to
> go with SR-MPLS as that is a painless seamless migration but SRv6 due to
> SID depth issues and given limited head room from customer MTU to the
>  backbone MTU today we are over the limit with larger SID depth for Ti-LFA
> paths or non protected paths.  Until that is addressed SRv6 unfortunately
> may not get much traction with service providers which I think due to the
> SRv6 issues ....uSID and SRv6+ may tend to be more viable and more
> attractive.
>
>
>
>
> Regards,
>
> Gyan Mishra
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 5 Oct 2019 17:19:58 -0700

+1

Every technology has a number of trade-offs associated with it, one can’t assess gain/loss of a particular technology without understanding the architecture as a whole.

As long as we are comparing the technologies in the right context and based on their technical merits we come up with a great solution, that is what IETF does!
Else...

Regards,
Jeff

> On Oct 5, 2019, at 07:11, Krzysztof Szarkowicz <[email-masked]> wrote:
> 
> I second Robert.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 5 Oct 2019 23:18:09 -0400

No Greg, uSID does not bring all the benefits of SRv6 while using 
shorter SIDs.
It also violates the basic IP archtiecture really abdly.

Yours,
Joel

On 10/5/2019 7:44 PM, Greg Mirsky wrote:
> Hi Gyan,
> you're asking very good questions and your arguments are all correct. 
> But I think that now there are several proposals that address what is 
> considered the scalability issue of SRv6. Among these is the Unified SID 
> for SRv6 
> <https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/>. 
> U-SID benefits from all the advantages SRH provides while adding a 
> higher density of SIDs thus allowing stricter path control.
> 
> Regards,
> Greg
> 
> On Fri, Oct 4, 2019 at 10:02 PM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     In line possible answers
> 
>     Sent from my iPhone
> 
>     On Oct 4, 2019, at 8:22 PM, Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>>
>>     Bess,
>>
>>     What is the benefit of SRv6 over SR-MPLS for greenfield
>>     deployments or existing mpls deployments.
>>
>     currently the big show stopper with SRv6 which removes it off the
>     table as a possibility is the SID depth and larger packet size given
>     that customers are set to 9100 and the core is 9216 so when adding
>     in mpls overhead vpn labels and Ti-LFA EH insertion at PLR node to
>     PQ node that adding in the entire SID list for long TE paths that
>     have huge SID depth makes SRv6 not viable at this point.
> 
>     For existing implementations it appears from my research a no
>     brainer to go with SR-MPLS as that is a painless seamless migration
>     but SRv6 due to SID depth issues and given limited head room from
>     customer MTU to the  backbone MTU today we are over the limit with
>     larger SID depth for Ti-LFA paths or non protected paths.  Until
>     that is addressed SRv6 unfortunately may not get much traction with
>     service providers which I think due to the SRv6 issues ....uSID and
>     SRv6+ may tend to be more viable and more attractive.
> 
> 
> 
> 
>>     Regards,
>>
>>     Gyan Mishra ____
>>
>>     IT Network Engineering & Technology ____
>>
>>     Verizon Communications Inc. (VZ)____
>>
>>     13101 Columbia Pike
>>     <https://www.google..com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> FDC1
>>     3rd Floor____
>>
>>     Silver Spring, MD 20904____
>>
>>     United States____
>>
>>     Phone: 301 502-1347 <tel:301%20502-1347>____
>>
>>     <mailto:[email-masked]>____
>>
>>     <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>>
>>
>>     Sent from my iPhone

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Sun, 6 Oct 2019 12:32:26 +0200

+1

Hence, to avoid such violation, but still to use shorter SIDs, SRv6+ (https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-05 <https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-05>) architecture has been proposed.

Thanks,
Krzysztof

> On 2019-Oct-06, at 05:18, Joel M. Halpern <[email-masked]> wrote:
> 
> No Greg, uSID does not bring all the benefits of SRv6 while using shorter SIDs.
>> you're asking very good questions and your arguments are all correct. But I think that now there are several proposals that address what is considered the scalability issue of SRv6. Among these is the Unified SID for SRv6 <https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/>. U-SID benefits from all the advantages SRH provides while adding a higher density of SIDs thus allowing stricter path control.
>> Regards,
>> Greg
>> On Fri, Oct 4, 2019 at 10:02 PM Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>>    In line possible answers
>>    Sent from my iPhone

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 6 Oct 2019 08:29:36 -0700

Hi Joel,
thank you for reviewing U-SID draft. I'm looking forward to reading a more
detailed analysis.

Regards,
Greg

On Sat, Oct 5, 2019 at 8:18 PM Joel M. Halpern <[email-masked]> wrote:

> >>     <https://www.google.
> .com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> FDC1
> >>     3rd Floor____
> >>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 6 Oct 2019 11:54:58 -0400

I just realized reading this note from Greg that he was arguing for 
something different than I understood.  To that degree, I apologize to 
Greg.  My comments do not reflect on Greg's Unified SID work.

Yours,
Joel

PS: Greg, just so you know waht error I made, I connected U-SID with the 
uSID drafts.  Again, sorry, I misread and misunderstood your note.  Yes, 
you referenced your draft.

On 10/6/2019 11:29 AM, Greg Mirsky wrote:
> Hi Joel,
> thank you for reviewing U-SID draft. I'm looking forward to reading a 
> more detailed analysis.
> 
> Regards,
> Greg
> 
> On Sat, Oct 5, 2019 at 8:18 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > On Fri, Oct 4, 2019 at 10:02 PM Gyan Mishra
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >     In line possible answers
>      >
>      >     Sent from my iPhone
>      >
>      >     On Oct 4, 2019, at 8:22 PM, Gyan Mishra
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >>
>      >>     Bess,
>      >>
>     <mailto:[email-masked]>
>      >>     <mailto:[email-masked]
>     <mailto:[email-masked]>>____
>      >>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 7 Oct 2019 02:37:37 -0400

In-line

Thank you all for the response

Sent from my iPhone

> On Oct 6, 2019, at 11:54 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> I just realized reading this note from Greg that he was arguing for something different than I understood.  To that degree, I apologize to Greg.  My comments do not reflect on Greg's Unified SID work.
> 
> Yours,
> Joel

[Gyan] With regards to the SID depth issue with SRv6 one way to get around it is with jumbograms support 32 bit IPv6 mtu payload where IPv4 has 16 bit mtu theoretical maximum of which most vendors only support today up to 9216 but if the core was bumped let’s say to 64k then SRv6 would be fine as it stands with SID depth for long many hop TE paths as well as EH insertion on intermediate nodes for Ti-LFA at PLR to PQ node additional EH insertions occurring at least would not be an issue as far as overhead mpls bytes with jumbograms.  

With regards to SR-MPLS versus SRv6 with LDP supporting dual stack transport v4 v6 as of a few years ago and some providers have adopted so the decision tree of which direction to go is based on your core transport and if your mpls core “bgp and PIM free” is still IPv4 then you go with SR-MPLS and if dual stacked with LDP v4 v6 then you have the option to easily migrate to SRv6.  As far as TE goes in terms of per vrf coloring TE with LDP is supported by most SP router vendors today but is not as seamless as a separate loopback is required for egress FEC bgp peering so then with SR-MPLS you have SR-TE and with SRv6 you have Ti-LFA 50ms fast reroute so TE is functionally and FRR is available for all options.

The major gain that SRv6 has with TE capabilities is its use cases extend outside the service provider core arena to every permutation imaginable with traffic engineering natively with IPv6 dataplane from enterprise solutions for DC to Access client /server communication to IPSEC vpn net to net to internet flows can now all use Ti-LFA native traffic engineered protected paths.

uSID variable length SID does provide interoperability for dual data plane v4 SR-MPLS and SRv6 IPv6 data plane interoperability with 32 bit SID and SRv6 now with uSID along with SRv6+ compressed SID can provide workaround for the SRv6 SID depth issue until vendors are able to support larger MTUs for IPv6.
> 
> PS: Greg, just so you know waht error I made, I connected U-SID with the uSID drafts.  Again, sorry, I misread and misunderstood your note.  Yes, you referenced your draft.
> 
>> thank you for reviewing U-SID draft. I'm looking forward to reading a more detailed analysis.
>> Regards,
>> Greg
>> On Sat, Oct 5, 2019 at 8:18 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 7 Oct 2019 11:19:20 +0100

If you need uSIDs for MTU control or restrictions on the depth that you 
can parse in the packet, you should also consider regular MPLS-SR, or in 
an IP only network draft-ietf-mpls-sr-over-ip (RFC editor's queue).

- Stewart

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 7 Oct 2019 18:29:13 -0400

In-line

Good idea agreed that’s a good way to go using uSID along with SR-MPLS.  

I am going to set that up in my lab all 3 in parallel overlays SR-MPLS, uSID and SRv6.  That may not be a bad idea having the architecture in parallel I wonder and using SRv6 when you don’t have MTU constraints use Ti-LFA and for longer SID lengths paths use SR-MPLS in the same topology.  I believe the interoperability draft that was sent earlier on talks about building both SRv6 v6 data plane and SR-MPLS ipv4 data plane in parallel using uSID.

Gyan

Sent from my iPhone

> On Oct 7, 2019, at 6:19 AM, Stewart Bryant <[email-masked]> wrote:
> 
> If you need uSIDs for MTU control or restrictions on the depth that you can parse in the packet, you should also consider regular MPLS-SR, or in an IP only network draft-ietf-mpls-sr-over-ip (RFC editor's queue).
> 
> - Stewart
> 
> 
>