Re: [spring] Beyond SRv6

[Satoru Matsushima <[e-mail]>]

Hi Alex, Ron,

Thanks for your interest in the mobile side of SRv6. :-) 

SRv6 is considered as user plane protocol in DMM WG. And yes, 3GPP also considered it as an user plane protocol in 3GPP CT WG4. 

Thank to 128-bits length SID in SRH, the proposed SRv6 user plane solution fulfills almost 3GPP requirements. The vote result unfortunately shows that not to standardize it as an alternative of GTP within the scope of Rel-16. But it doesn’t matter here in IETF.

So now it might be the chance for you Ron, if you want to introduce your solution to 3GPP.

Good luck.
--satoru

2019/09/10 22:09、Ron Bonica <rbonica=[e-mail]>のメール:

> Alexander,
> 
> I don't participate in 3GPP, but I hear that the following question was put to a vote during CT4#93 (August 26-30, 2019):
> 
> - Do you want to standardize SRv6 user plane protocol (w/o GTP-U) as described in clause 6.2.2 of TR 29.892?
> 
> Maybe someone who participates can report the results.
> 
>                                                                                              Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Alexandre Petrescu
> Sent: Tuesday, September 10, 2019 8:05 AM
> To: [e-mail]
> Subject: Re: [spring] Beyond SRv6
> 
> Hi,
> 
> I want to understand whether Segment Routing Header is a technology considered for GTP in cellular networks that connect smartphones and IoT devices.
> 
> As far as I know, the IPv6 deployments for such cellular networks use GTP, which runs on IPv4. That needs to evolve to IPv6. When moving to
> IPv6 that would change to IPv6-in-IPv6. Further in time, that
> IPv6-in-IPv6 would become just IPv6.
> 
> Is SRH considered there?
> 
> Alex
> 
> 
>> Le 09/09/2019 à 05:52, 松嶋聡 a écrit :
>> As an operator of running a nation wide network in non-trivial size 
>> with SRv6, I agree on that multiple or many SRv6 SIDs support in terms 
>> of MTU size limit is not an issue.
>> 
>> And solutions already exist that enable us to deploy TE with minimum 
>> number of SID (e.g, flex-algo) not only for SRv6, but also for SR-MPLS.
>> Additional solution to reduce size of SIDs seems beneficial. However, 
>> requiring another type of EH just for reduce the size of SIDs sounds 
>> no make sense to me.
>> 
>> Therefore I see no benefits on CRH for our deployments. SRH has been 
>> developed and specified through legitimate IETF process with 
>> non-trivial time and efforts. Adding extra header for the same purpose 
>> would waste all our precious efforts so far and require much 
>> unnecessary time and efforts down the load which is no make sense for all of us.
>> 
>> We have to stick SRH to be used and be compatible with the existing 
>> SID definition in SRH if we need solution to reduce SIDs.
>> 
>> Cheers,
>> --satoru
>> 
>> 2019/09/08 16:19、Gyan Mishra <[e-mail]
>> <mailto:[e-mail]>>のメール:
>> 
>>> As an operator of a Tier 1 provider with massive mpls networks I 
>>> think our traditional bread and butter “mpls” will be around for a 
>>> very very long time as is IPv4 if not longer.
>>> 
>>> Most all service provider cores run greater then or equal to MTU 9000 
>>> mpls cores to account for mpls overhead shims being tacked on plus 
>>> edge overhead from possible GRE tunneling or IPSEC so in general 
>>> making  the core the maximum Jumbo MTU supported by most vendors at
>>> 9216 is what is generally done out in the field.
>>> 
>>> So for SRv6 support of multiple or many EH insertions is really a non 
>>> issue for most operators.
>>> 
>>> From reading through all the discussion threads the SR insertion is 
>>> two fold one being for FRR capabilities using Ti-LFA or remote LFA 
>>> tunnel so end up requiring double EH insertions on the Ingress PE 
>>> tunnel head end SRv6 source node and then second scenario being a 
>>> possible EH insertions occurrence on intermediate nodes.  I have not 
>>> read through the drafts or RFC regarding Ti-LFA with SR but since 
>>> that is an IGP extension I am guessing an opaque LSA and is not the 
>>> traditional MPLS FRR link/node/path protection that adds an 
>>> additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.
>>> Can someone clarify that use case for me.  Also the EH insertion on 
>>> intermediate node what is the use case or reason for that.  My guess 
>>> is it’s for special use case of stitching SRv6 domains together.
>>> Please clarify..
>>> 
>>> I do agree with some of the other operators on the marketing hype and 
>>> push for SR-MPLS and SRv6 is not for every service provider as goes 
>>> the mantra ..”if it’s not broken..don’t try to fix it..leave it alone”
>>> and I think you can definitely say that for MPLS as it has had a 
>>> SOLID run for service providers since the 90’s ever since ATM and 
>>> frame relay were put to rest so I don’t think that it’s going away 
>>> any time soon.
>>> 
>>> I think it would be a serious mistake and sad state of affairs for 
>>> vendors to push SR-MPLS and SRv6 and stop development and support of 
>>> MPLS as that would really pigeon hole all operators into one 
>>> technology which does not fit the bill for every use case out there.
>>> 
>>> The mention of SR-MPLS pulling support for IPv6 and forcing operators 
>>> to go with SRv6 is a wrong move for vendors and would really limit 
>>> operators with flexibility to chose based on their use case to stay 
>>> with traditional mpls or go with with SR-MPLS or SRv6 only if 
>>> necessary with their unique use case warrants.
>>> 
>>> I think SR-MPLS and SRv6 should be marketed by vendors and the 
>>> industry as yet another tool in our operator “design toolbox” to use 
>>> as we see fit or not use but not be forced into it.
>>> 
>>> There are particular use cases for SR-MPLS for migration from 
>>> existing LDP and the downside of having state maintained in the core 
>>> is not a downside as the P and PE nodes have to be provisioned anyway 
>>> so their is no savings in pulling mpls LDP/mLDP with SR-MPLS 
>>> “Sr-prefer” and ditching LDP.
>>> 
>>> I think the major use case for SR-MPLS and SRv6 is coloring per-vrf 
>>> TE feature for L3 VPNs steering without adding complexity of adding 
>>> ibgp loopback egress PE FEC next hop to traffic engineer L3 VPN traffic.
>>> That is a unique use case and not every major service provider has 
>>> that requirement so if you don’t their really is no need to jump on 
>>> the SR band wagon and you can stay put with the tried and true mpls 
>>> that has been around for decades and is not going away any time soon.
>>> 
>>> SRv6 has a more ubiquitous all encompassing use case that could serve 
>>> for MPLS core replacement or on the public internet or for enterprise 
>>> network traffic engineering of flows between data centers or access 
>>> to data center and an alternative to SD WAN application based routing 
>>> solutions.  But here as well the use case benefit has to exist.
>>> Nobody wants to be forced into it if it’s unnecessary added complexity.
>>> 
>>> My 2 1/2 cents
>>> 
>>> Regards,
>>> 
>>> Gyan Mishra
>>> Verizon Communications
>>> Cell- 301 502-1347
>>> 
>>> Sent from my iPhone
>>> 
>>> On Sep 6, 2019, at 10:17 AM, Robert Raszuk <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>> 
>>>> I don't think so.
>>>> 
>>>> In OAM packets are on purpose made huge - even up to MTU to make 
>>>> sure real customer packets can go through or to detect and diagnose 
>>>> MTU issues. So adding SRH to it is nothing one can call inefficient.
>>>> 
>>>> Wrong tree :)
>>>> 
>>>> Cheers,
>>>> R.
>>>> 
>>>> On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>> 
>>>>    __ __
>>>> 
>>>>    On 06/09/19, 4:32 PM Robert Raszuk from [e-mail]
>>>>    <mailto:[e-mail]> said >____
>>>> 
>>>>    __ __
>>>> 
>>>>    Not really. Only SR OAM packets may need it. Is that a real
>>>>    problem ? ____
>>>> 
>>>>    __ __
>>>> 
>>>>        Thanks for clarification. Like Ron pointed out before, its
>>>>        inefficient encoding.____
>>>> 
>>>>        __ __
>>>> 
>>>>        srihari…____
>>>> 
>>>> _______________________________________________
>>>> spring mailing list
>>>> [e-mail] <mailto:[e-mail]> 
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
>>>> ring__;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1
>>>> CREd8sPdsxuYOWGb$
>>> _______________________________________________
>>> spring mailing list
>>> [e-mail] <mailto:[e-mail]> 
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
>>> ing__;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1CR
>>> Ed8sPdsxuYOWGb$
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
>> __;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1CREd8s
>> Pds3jENCH2$
>> --------------------------------------------------------------------
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QuuGxfYaKY18JJXyoD_Oe8_Uw4NMuUrz4oZdXfTr4r5oPvR1CREd8sPds3jENCH2$
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------