eric, <devils advocate> if *just* loose source routing is required, then the same can get achieved using nested IP tunnels. no need for new architecture, no need for new signaling protocol extensions, perhaps some re-spin of forwarding hardware in order to push the large tunnel strings. </devils advocate>.
point is that you can't get away with loose source routing semantics for supporting all the SR use-cases. thus the current 6man draft needs rework in order to be somewhat feature congruent to the mpls-dataplane, which stefano has agreed to post _soon_. i hope it does not take another 12 months (e.g. like the last time when we have asked for the data ipv6-sr plane specification presented at mplswc2013 - actual publication data was feb 2014 ...) - tx, /hannes On May 27, 2014, at 8:36 PM, Eric Vyncke (evyncke) wrote: > 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 > > 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
