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 ? 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... > 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. > 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 ? Also, do you really think we are planning to do a forklift upgrade of all network elements because of SR-IPv6 ? 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. 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. s. > > /hannes > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
