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 <[email protected]> wrote: >> Eric, >> >>> -----Original Message----- >>> From: Eric Vyncke (evyncke) [mailto:[email protected]] >>> Sent: Tuesday, May 27, 2014 2:37 PM >>> To: Hannes Gredler; Stefano Previdi (sprevidi) >>> Cc: Yakov Rekhter; <[email protected]>; 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" <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
