On Mar 31, 2014, at 3:28 PM, Hannes Gredler wrote: > hi stefano, > On Sat, Mar 29, 2014 at 09:25:51AM +0000, Stefano Previdi (sprevidi) wrote: > | > | On Mar 29, 2014, at 1:58 AM, Hannes Gredler wrote: > | > | > On Fri, Mar 28, 2014 at 09:53:18PM +0000, Stefano Previdi (sprevidi) > wrote: > | > | > | > | On Mar 28, 2014, at 10:45 PM, Hannes Gredler wrote: > | > | > | > | > On Fri, Mar 28, 2014 at 09:42:20PM +0100, Robert Raszuk wrote: > | > | > | [ ... ] > | > | > | So there are two options: > | > | > | > | > | > | - add minor extensions to IPv6 dataplane which can provide control > and > | > | > | encapsulation in a very smooth and gradual way for a number of > | > | > | applications > | > | > > | > | > those are by no means "minor extensions" - those are "major, intrusive > | > | > changes which often require hardware re-spins and expensive upgrade > cycles" > | > | > | > | > | > | I don't think the above statement reflects the entire HW industry. > | > > | > again, honesty in the discussion, please. > | > | > | really, I'm liar now ? > > i did not say that; - let me relate a story: > > in my "networking childhood" i was in a sales organization > and during teh years there i have got to understand the difference between > "lying" and "not saying the (full) truth". > most often when people try to *sell* something the > use a concious or unconcious form of the latter.
I understand your experience... but maybe avoid to generalize it. > | in general I don't reply to people pretending I'm not honest, because > | it looks more like an insult. > | > | Nevertheless, it's probably not what you intended but you got thoughts > | confused and the result is a misplaced sentence. It may happen to all > | of us... > > its a friendly reminder to check the facts again :-) > fact is that thare are performance/cost differences between > a lookup engine which > > a) does fixed sized lookups at a fixed offset (MPLS) > b) does best-matching prefix, recursive lookups at variable offsets. > (IP6-SR) > > | > | > cherry-picking a particular HW chipset that you may have > | > which may provides the necessary ucode budget for a few segments > | > and then declaring victory is insufficient. > | > | > | I really don't know why you pretend that. It is not the case but since > | you seems so convinced, I'm not sure it's worth trying to convince > | you that it's not the case. > > the cost of processing an additional routing header is not just the > routing header itself. because the routing header is between the IPv6 > header and e.g. the TCP header you are also increasing the cost > of accessing TCP header fields for e.g. matching port # inside a firewall > filter. > > As you know the IP6 header chaining has not been designed for making hardware > lookups efficient. > it may well be that because of the potential 100s of additional routing > header bytes > the firewall relevant data cannot be accessed hy the lookup engine, > which typically has got a limited view on the header bytes. > > this is a example of "not telling the full truth" ... (again no insult) > it may be that you can do the routing lookups, but can you do all together at > *scale* ? > > 1) processing large routing headers > 2) firewall lookups > 3) at line rate > 4) more than one chipset family > 5) differwnt chipset generations > > | > just watch your installed base in your co-authoring SP networks (core, > edge, DC) > | > and ask yourself if the hardware upgrade in support of v6-sr is > | > zero cost or > zero-cost and then look how big the upgrade cost is > | > and then it becomes obvious that this cannot be glossed over. > | > | > | do you really think we didn't do the exercise ? > > i don't know - if i just look at the cost of supporting this on a installed > base > e.g. two different ASIC families and two different generations thereof, plus > teh full feature matrix and senior testers which will squeeze the product > i'll get very fast at discomfort. since you don't need to support it on all platforms (only on platforms where you expect the SRH being processed) the scope is reduced and the platforms are usually not core devices. It won't come for free for sure but I know MANY platforms where the hit is far more than just acceptable. > | Also, do you really think we are planning to do a forklift upgrade of all > network > | elements because of SR-IPv6 ? > > no usually it works such that you: > > 1. try to insert this at the edge first (this adds value for an immediate > customer requirement) and > therbet carefully hiding the future cost of this (at high speed) in the > core. > 2. when SPs want to enable it at the core / higher speeds / other platforms > the true cost unveils. but by then, you will probably find more HW being capable of switching v6 packets with EHs. > | I think I explained multiple times but > | just in case: SR-IPv6 requires the node processing the SRH to be > | capable of so, not the entire network. > > understood, arguable the same (loose source routing) can be achieved e.g. > with nested GRE tunnels ... there is no need to add an entirely new dataplane. sure, you can also do it by stacking mpls-te-rsvp tunnels after all... > | Bottom line, we do have HW that does not incur a substantial (nor > | significant) penalty because of EHs. We have this in multiple vendor > | contexts and it matches the requirements of the use cases we're > | addressing. > > you're saying essentially that additional complexity comes at no cost - no. I says that additional complexity comes at acceptable cost for many platforms, especially for the use cases currently worked out. s. > and according to my past experience this is often an indication > that not all facts are on the table. again, no insult, not calling > anybody anything, just an invitation to poke and drill a bit into the > hardware implications of this. > > adding dataplanes #4 to the internet is something which is going to be > expensive, and therefore needs to be carefully examined from > different angles. > > /hannes > > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
