General comments, Given that we are talking about technology for the future of the Internet, it would be good to consider requirements of Internet traffic.
LFA for Internet? With smart apps, CDNs, intelligent clients? What? We need to move to IPV6, we are. Are You? We need to do it very efficiently and enable innovation and TTM with low risk. Scale is obviously an issue. I want to enable more bandwith! Raw bandwidth to someone offnet really drives the tradeoffs for an Internet provider, move to V6 only. Now! Flexibility in what we can do internally is a big value add, V6 SR. Because V6 is how we offer services to our customers, new mandate. Commercial Intranet traffic (VPN) is high value, but really noise as far as volume. Do we build a future IP architecture on this? Channeling PeterL, the cheapest way to build a SONET network is to build a SONET network. Or something like that, I think we can do better butŠ Apologize for a mis quote. Peter can address with me. Given we build INTERNET infrastructure for <100% capacity at peak, for single link, single site, single fiber bundle failures. And then we pad it for growth. With Overcapacity of 50%ish. You have to love 50% CAGR per year on traffic, you are never wrong. Some of this optimization stuff is inertsesting (sp?), that is not how we build networks on this side. Everything for us is IPV6, not interested in forcing us to have to tunnel it all in MPLS. I¹m not even happy with Ethernet. SONET gone, Ethernet?, Big Fat V6 Pipe go. John Leddy On 5/30/14, 4:08 PM, "Hannes Gredler" <han...@juniper.net> wrote: >robert, > >On May 30, 2014, at 9:50 PM, Robert Raszuk wrote: > >> Hi Yakov, >> >> I read Eric's email and included its main point a bit differently. >> >> It is known for a fact that in large network (say 1000 routers) it is >> sufficient to force traffic only via few key core boxes (perhaps 10 or >> so) in order to perform good traffic engineering. > >i do not share that view: > >we have heard of many customer requirements requiring to to disjoint >routing >of SIGTRAN traffic down to the PE level. >IOW pretty much every router needs to have support for the new >*expensive* data plane. > >> With SR it is possible while in classical RSVP-TE it is not - simply >> due hop by hop signalling nature of the latter. > >with LSP hierarchy we can solve pretty much any scaling problem, right ? > >> His reference to PE was IMHO just an example without intention to >> provide exhaustive list. >> >> For local protection with basic IPv6 network I would rather recommend >> use of LFA solutions which again do not require anything to do with >> SRH processing - so his SRH forwarding only case for vast majority of >> routers in a given domain remains sound and valid. > >the trouble with LFA technology and 100% backup coverage is >a bit like star-wars Š lots of episodes ;-) > >Episode 1: - LFA > is not deployable due to the algorithm not > consider what is an operational feasible > path (think of backup of a oc-768 with a oc-3). > > so we need: > >Episode 2: - LFA + policy (manageability draft) > > trouble is now we have eliminated many paths > due to policy reasons: so we need something > to increase path-diversity by reusing > existing tunnels - which gets us to > >Episode 3: - R-LFA > it is still possible to construct pathologic > topologies which do not provide 100% coverage. > >Episode 4: - R-LFA +DF > concerns about micro-loops and desire to place SPT > backup traffic on the post-convergence-path leads us > to > >Episode 5: - TI-LFA > > >now my question is: would you bet the farm on that there won't >be another episode (i.e. things we haven't considered so far). >i won't, given that track record of misguided hopes and believes. > >/hannes > >> On Fri, May 30, 2014 at 9:37 PM, Yakov Rekhter <ya...@juniper.net> >>wrote: >>> Eric, >>> >>>> -----Original Message----- >>>> From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] >>>> Sent: Tuesday, May 27, 2014 2:37 PM >>>> To: Hannes Gredler; Stefano Previdi (sprevidi) >>>> Cc: Yakov Rekhter; <spring@ietf.org>; Alvaro Retana (aretana) >>>> Subject: Re: [spring] WG Adoption Call for >>>>draft-martin-spring-segment- >>>> routing-ipv6-use-cases >>>> >>>> Late reply to Hannes point: >>>> >>>> On 28/03/14 22:23, "Hannes Gredler" <han...@juniper.net> wrote: >>>>> >>>>> the real question is what percentage of public Internet routers >>>>> >>>>> 1) does have MPLS hardware forwarding support >>>>> 2) does have IPv6-SR hardware forwarding support. >>>>> >>>>> And >>>> >>>> Regarding the IPv6-SR compatibility, as SRH is basically 'loose source >>>> routing', it only requires: >>>> - SRH processing by all SR-enabled router whose segment id is in the >>>> SRH, typically some PE routers. Those will need to be modified indeed >>>> but those will be minority >>>> - SRH forwarding (i.e. Not parsing or acting upon the SRH) for all >>>> remaining routers. Those will be the majority >>> >>> If indeed, as you said above, only "minory" of the routers (e.g., only >>>PEs) >>> would be able to process IPv6 SRH, then SR would *not* be able to >>>support >>> such use cases as various flavors of local protection, and traffic >>>engineering >>> (except for EPE). Conversely, support for various flavors of local >>> protection and/or traffic engineering (other than EPE) would require >>> all routers to support IPv6 SRH. >>> >>> Yakov. >>> >>>> >>>> The latter is currently OK, I wrote a small script >>>> https://www.vyncke.org/sr.php which basically sends a dummy SRH to >>>>your >>>> browser (requirement is that your browser/clients supports IPv6) and >>>> after a dozen of tests, all were successful. While this is not a >>>> mathematical proof, this is good enough from my engineer's point of >>>> view >>>> >>>> Hope this helps >>>> >>>> -éric >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
