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). /hannes _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
