On Jun 6, 2014, at 1:31 PM, Hannes Gredler wrote: > hi eric, > > see answers inline. > > On Fri, Jun 06, 2014 at 09:48:12AM +0000, Eric Vyncke (evyncke) wrote: > | Hannes, > | > | I am following this thread from far away but I wonder about: > | > | On 6/06/14 11:17, "Hannes Gredler" <[email protected]> wrote: > | > > | > 1. There is little to no SP traction on IPv6-SR. > | > those SPs who have voiced support in all reality > | > can be served well with nested IP tunnels based on > | > exisiting protocols (GRE, IPIP, L2TPv3 ) > | > | Tunnels are also expensive (cfr point below) but if you want to enforce a > | specific route for TE, then, I am afraid that this will be a lot of > | specific configuration (or states if dynamic) in a lot of nodes... As well > | as a lot of specific routes towards those tunnels. So, kind of heavy. > ^^^^^^^^^^^^^ > > depends a whole lot how you implement IP tunnels. > if you follow the prevailing model that an IP tunnel is implemented as a > logical-interface, > (and hence needs to be explicitly configured) then you're right its heavy > weight and > expensive. > > however, it does not have to be like that: > one could have e.g. an implementation where all inbound tunneled traffic is > routed > towards a decapulator-interface (where you do all the key validation, ACL > etc.) > which POPs of the outer tunnel header and > does an IP lookup on the next-tunnel-header. > > so assuming this 'IP-tunnel-decapsulator' in core-nodes then any ingress node > could describe an explicit path by pushing N nested IP tunnels. > > | Not to mention that with SRH you could have different paths among two > | end-points based on the application (web vs video) identified by some > | means (such as layer-4 information), way more complex to do it with > | tunnels and 'plain' routing. > > see above: applications actually could do the nested-tunnel-pushing, > using exisiting OS kernels. > > | > 4. the cost of adding explicit routing forwarding capabilities > | > to IPv6 forwarding hardware is now visible (and guess what - its > | >expensive > | > to implement on high speed (100GBIT/s lookup engines - > | > (parsing IPv6-extensions headers does require a lot of memory > | >references) > | > | I am sure that you know how source routing works, only the router in the > | destination address main IPv6 header field needs to inspect the SR header, > | all others routers can safely act only on the DA and ignoring the > | extension header chain (of course, if ACL are applied on layer-4 you need > | to parse the extension header chain but this is the same with or without > | SR). > > see and that is the problem here ... > > http://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-00 > > "Each segment endpoint inspects the SRH, updates the DA (with the next > segment) and forwards the packet towards the next segment." > > this adds the requirement to rewrite the IPv6-DA. > i'd estimate that the majority of IP6 hardware forwarding implementations > does not have the ability to *rewrite* IPv6 DAs (perhaps on the edge > thatre are some CG-NAT chipsets which can do this).
I'd leave you with your estimation however I'd like to point out that the behavior consisting of rewriting the DA at a segment endpoint has not been defined by Segment Routing but rather by IPv6 architecture (rfc2460). Segment Routing just leverages an architectural component defined a few years back. s. > > /hannes _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
