Excellent news.

I’d capture your case in the SRv6 deployment draft, in case you’d be okay.

Cheers,
--satoru

2019/09/11 9:55、Hirofumi Ichihara <hirofumi.ichih...@linecorp.com>のメール:

> Hi folks,
> ​
> Let me mention my opinion as an operator.
> ​
> Our company already has deployed and used SRv6 Network in our DC. Our use 
> case is L3VPN to isolate network for each multi-tenant and we decided to use 
> T..Encaps and End.DX4. Currently, we deployed hypervisors and gateway nodes 
> which are aware of SRv6. Although there are many routers not supported SRv6 
> between HVs and GW nodes, it works fine because of current SRH mechanism. We 
> actually use one SID only between HV and HV, HV and GW so we don't face the 
> issue like many SIDs now although we have a plan to use multiple SIDs for our 
> SFC use case.
> ​
> We don't have specific opinion to shorter SIDs. However, we operator hope 
> strongly that new thing must configure backward compatibility or reasonable 
> migration plan.
> ​
> Thanks,
> Hirofumi
> 
> -----Original Message-----
> From: "Shraddha Hegde"<shraddha=40juniper....@dmarc.ietf.org> 
> To: "Andy Smith (andsmit)"<ands...@cisco.com>; "Ron 
> Bonica"<rbonica=40juniper....@dmarc.ietf.org>; 
> Cc: "SPRING WG List"<spring@ietf.org>; "6...@ietf.org"<6...@ietf.org>; "Gyan 
> Mishra"<hayabusa...@gmail.com>; "Robert Raszuk"<rob...@raszuk.net>; "Rob 
> Shakir"<ro...@google.com>; "Tarek Saad"<tsaad....@gmail.com>; 
> Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00)
> Subject: Re: [spring] Beyond SRv6.
>  
> Andy,
>  
> RFC 6119 defines ipv6 router-id .
> It is not mandatory to advertise IPv4 router-id in ISIS.
>  
> Rgds
> Shraddha
>  
> From: spring <spring-boun...@ietf.org> On Behalf Of Andy Smith (andsmit)
> Sent: Monday, September 9, 2019 10:07 PM
> To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>
> Cc: SPRING WG List <spring@ietf.org>; 6...@ietf.org; Gyan Mishra 
> <hayabusa...@gmail.com>; Robert Raszuk <rob...@raszuk.net>; Rob Shakir 
> <ro...@google.com>; Tarek Saad <tsaad....@gmail.com>
> Subject: Re: [spring] Beyond SRv6.
>  
> Ron,
>  
> Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?
>  
> So you can't really build an ipv4 'free' network.   Not 100% anyway.
>  
> Andy
>  
>  
> 
> 
> On Sep 9, 2019, at 12:21 PM, Ron Bonica 
> <rbonica=40juniper....@dmarc.ietf.org> wrote:
>  
> Hello Gyan,
>  
> Amplifying what you have said…..
>  
> There is no reason why SR-MPLS shouldn’t work over an IPv6 only 
> infrastructure. So long as every node is MPLS capable, SR-MPLS should not 
> require IPv4 to be enabled.
>  
>                                                                               
>  Ron
>  
>  
>  
> Juniper Business Use Only
> From: Gyan Mishra <hayabusa...@gmail.com> 
> Sent: Sunday, September 8, 2019 3:20 AM
> To: Robert Raszuk <rob...@raszuk.net>
> Cc: Srihari Sangli <ssan...@juniper.net>; SPRING WG List <spring@ietf.org>; 
> 6...@ietf.org; Zafar Ali (zali) <z...@cisco.com>; Rob Shakir 
> <ro...@google..com>; Ron Bonica <rbon...@juniper.net>; Tarek Saad 
> <tsaad....@gmail.com>
> Subject: Re: [spring] Beyond SRv6.
>  
> 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 <rob...@raszuk.net> 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 <ssan...@juniper.net> wrote:
>  
> On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to