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 <mailto:hayabusa...@gmail.com>> > Sent: Sunday, September 8, 2019 3:20 AM > To: Robert Raszuk <rob...@raszuk.net <mailto:rob...@raszuk.net>> > Cc: Srihari Sangli <ssan...@juniper.net <mailto:ssan...@juniper.net>>; SPRING > WG List <spring@ietf.org <mailto:spring@ietf.org>>; 6...@ietf.org > <mailto:6...@ietf.org>; Zafar Ali (zali) <z...@cisco.com > <mailto:z...@cisco.com>>; Rob Shakir <ro...@google.com > <mailto:ro...@google.com>>; Ron Bonica <rbon...@juniper.net > <mailto:rbon...@juniper.net>>; Tarek Saad <tsaad....@gmail.com > <mailto: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 > <mailto: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 > <mailto:ssan...@juniper.net>> wrote: > > On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net > <mailto: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 <mailto:spring@ietf.org> > https://www.ietf.org/mailman/listinfo/spring > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!QmUWmBSwMeAovLUIjU_O2tFmWCZOPQmNOWvSTsaRgHjWkA0is1xv2wNVKz9IevQp$>-------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6> > --------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
