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