RE: [spring] Beyond SRv6

[Ron Bonica <[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$
--------------------------------------------------------------------