Re: [spring] Beyond SRv6

[Alexandre Petrescu <[e-mail]>]

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://www.ietf.org/mailman/listinfo/spring
>> _______________________________________________
>> spring mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/spring
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>