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 <[email protected]>のメール: > 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"<[email protected]> > To: "Andy Smith (andsmit)"<[email protected]>; "Ron > Bonica"<[email protected]>; > Cc: "SPRING WG List"<[email protected]>; "[email protected]"<[email protected]>; "Gyan > Mishra"<[email protected]>; "Robert Raszuk"<[email protected]>; "Rob > Shakir"<[email protected]>; "Tarek Saad"<[email protected]>; > 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 <[email protected]> On Behalf Of Andy Smith (andsmit) > Sent: Monday, September 9, 2019 10:07 PM > To: Ron Bonica <[email protected]> > Cc: SPRING WG List <[email protected]>; [email protected]; Gyan Mishra > <[email protected]>; Robert Raszuk <[email protected]>; Rob Shakir > <[email protected]>; Tarek Saad <[email protected]> > 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 > <[email protected]> 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 <[email protected]> > Sent: Sunday, September 8, 2019 3:20 AM > To: Robert Raszuk <[email protected]> > Cc: Srihari Sangli <[email protected]>; SPRING WG List <[email protected]>; > [email protected]; Zafar Ali (zali) <[email protected]>; Rob Shakir > <[email protected]>; Ron Bonica <[email protected]>; Tarek Saad > <[email protected]> > 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 <[email protected]> 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 <[email protected]> wrote: > > On 06/09/19, 4:32 PM Robert Raszuk from [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
