> -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of Eric Vyncke > (evyncke) > Sent: Friday, June 06, 2014 5:48 PM > To: Hannes Gredler; Stefano Previdi (sprevidi) > Cc: Yakov Rekhter; <[email protected]>; John G. Scudder; Alvaro Retana (aretana) > Subject: Re: [spring] WG Adoption Call for > draft-martin-spring-segment-routing-ipv6-use-cases > > 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.
Agree that nested IP tunnels are expensive. However, the SRH which contains an ordered list of IPv6 addresses seems a bit heavy as well (e.g., the MTU issue), especially when the number of specified hops along the explicit path is very large. Why not use an ordered list of short ids, instead of an ordered list of IPv6 addresses to represent an explicit path while still allowing the underlay is IPv6 network? IMHO, the MPLS label stack seems like an ideal candidate for that ordered list of short ids. To some extent, the MPLS layer is now an overlay as opposed to the IPv6 underlay (see http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00). Or do you believe the MTU issue is not a problem anymore in practice? > 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. > > > 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). In the approach as I mentioned above, it only requires those specified hops along the explicit path to be upgraded as well (i.e., interpret the top label of the MPLS packet into the IPv6 address of the next specified hop and then forward the packet to that hop via an IPv6 tunnel instead of an MPLS LSP tunnel). In other words, its deployment cost is much similar with that of the SRH-based approach. Best regards, Xiaohu > Hope that my comment helps clarifying the context > > -é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
