On Thu, Feb 3, 2011 at 10:11 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: > Lets be a little careful here: > 1) If we say "No Extension Headers for intermediate processing", and "No Hop > By Hop Options", then we are saying that we do not want any extensions > intended to be processed in intermediate routers. While I personally like > that, I want to make really sure that we understand that is what we are > saying.
My feeling is this: hop-by-hop processing will happen in slow-path (if you permit it to happen at all), you can't build a router today with an asic that'll know how to handle options which are created in the future :( This means that the gear in the network is subject to failure at relatively low packet rates (as compared to interface rates), it also means that the failure is likely not just at the interface level (the RP/RE/PRP/etc will be doing this processing), much of this box will fail. This is an unacceptable outcome. > 2) I have been told that many large rotuers have a setting that causes them > to ignore the hop by hop options field. To the degree that is both true and > turned on, then we need to allow for that in our think (both positive and > negative.) I've mostly seen the 'throw the packet away' option... I agree that if I can ignore these in all of my routers I don't care what you do with them before you see my router or after I pass this off to my friendly neighbor router. This means that if you expect all intermediate networks to do "something" for you with this option, you will not get it, your application and other things should never rely upon this being functional. if we get to that then... why are we making these exist anyways? -chris (I agree that being clear here is a good plan) > > Yours, > Joel > > On 2/3/2011 9:57 PM, Christopher Morrow wrote: >> >> On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) Lam<hingka...@gmail.com> >> wrote: >>> >>> The below white paper from Cisco asserts that most vendors including >>> Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this >>> correct? >>> >>> >>> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html >>> >>> If Yes, then we should not add support for more sub options with HBH >>> header. >> >> yes, see notes from me (in particular) about this from the last 2+ >> years... no more HBH header options pls... OR understand that these >> may/will get dropped (probably the whole packet actually) at some >> provider edges. >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
