On Jun 6, 2014, at 11:17 AM, Hannes Gredler wrote: > stefano, et al, > > my read of SR and IPv6-SR in the past year is: > > 1. that in 2013 you have started out with a *unified* control-plane > based on stacked-tunnels technology which supports more than > one data-plane. > > 2. because it supports 'more than' dataplane and there is > a high congruency between dataplane forwarding semantics you need an > overarching, common 'architecture' with new terminology etc. > > now lets have a closer look after more than one-year of 'SR-promised-land': > > 1. There is little to no SP traction on IPv6-SR.
the above statement reflects a lack of understanding of what's going on at that particular side. I'd suggest you to have a better look. I think even on this list, operators expressed their interest in SR architecture for v6 dataplane. Very recently we had an interesting presentation at NANOG. Maybe you should have a look. > those SPs who have voiced support in all reality > can be served well with nested IP tunnels based on > exisiting protocols (GRE, IPIP, L2TPv3 ) This is what you keep publicly claiming... without really believing on it. > 2. For certain usecases (e.g. protection, OAM, controller-based TE, etc) > there is SP traction in SR-over-MPLS. > > 3. There is little to no congruency in terms of forwarding-semantics > between the IPv6-SR dataplane and the MPLS data-plane. > > a) MPLS forwarding > = loose and strict forwarding based on local assigned tags > > b) IPv6-SR forwarding > = best-matching prefix forwarding based on global assigned adresses > > 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) > > 5. IOW the need to support for 'more-than-one dataplane' has just shrunk down > to 'one dataplane' of practical relevance (which is MPLS). > > 6. for *one* practical dataplane we do not need new architecture, nor new > terminology. > all what is required is some further clarification to rfc3031, which > 'draft-gredler-spring-mpls' really is all about. draft-gredler-spring-mpls is the most complex solution to a very simple requirement. I believe your draft is a very nice exercise so to prove you can do source routing with something that was clearly not designed to do so. With a very high price in terms of complexity (architectural and operational) you mimic what SR does with much more simplicity. Your draft explains in more than 10 pages what SRs explains in 10 lines and nobody changes anything in the mpls dataplane. Well, you know that, we've talked about it already, right ? > what really irritates me relax, enjoy the summer that's coming... > is your repeated delay tactics around publication on this mailing you already told me I'm a liar, now you state I'm doing tactics... should I keep a counter ? > of 'IPv6-SR' in sufficient details, such that one can see the clear need for a > *common* architecture. my trust that this will happen has gotten down to > almost zero. why are you so stressed ? The change that needs to be made in the 6man draft is only about the adj-sid. a minor detail. Since you seem very stressed and obsessed about it, let me promise you I will submit the draft today so you can have a more relax week-end. Obviously, only if this makes you feel better. s. > before asking the WG to adopt a common SR architecture and terminology > i'd rather ask you to *proof* the need for it. right now there > is *zero* evidence on the table that we need a 'common, dataplane neutral > SR architecture' at all, for supporting the practical relevant use-cases. > > /hannes > > > On Mon, Jun 02, 2014 at 07:36:47PM +0000, Stefano Previdi (sprevidi) wrote: > [ ... ] > > | > 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 ...) - > | > | > | Indeed, SR-IPv6 was initially presented at mplswc2013, then it > | triggered interest and collaboration from many parties. Note that > | we met during a couple of hours in Paris at that time and we gave > | you all the details of what we had in mind, including the ipv6 > | part. > | > | Then, at some point in the cycle, we published a draft describing > | what the authors worked out in terms of architecture and SRH details. > | I don't think I have to come with a justification about the amount > | of time it took. > | > | Anyway, in the mean time, implementation work from multiple parties > | started (for both mpls and v6 dataplanes). Now that we have multiple > | implementations, we are working on interoperability and we will, > | probably, again update some of the details but don't take this as a > | commitment from my side to publish anything in a delay that suits > | your time perception. > | > | > | s. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
