Chris, I think we may want to be a little careful here. At a minimum, maybe take a deep breath and think about this some, before making a final decision. :-) See below.
On Feb 3, 2011, at 20:17 MST, Christopher Morrow wrote: > 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 :( Agreed. > 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. I agree that's an unacceptable outcome; however, we have come up with solutions for this in the past. Namely, implement 'proper' rate-limiting at the linecards, in order to prevent overwhelming the RE/RP/PRP, etc. (think: ICMP rate-limiting). Of course, the key constraint this would place on any "applications" that attempt to use HbH options would be that it couldn't carry any user data traffic at any meaningful bit-rate as it WILL, most definitely, get dropped. OTOH, if we're talking about periodic/sporadic OAM protocols that are only used on a best-effort basis, (probably by operators, not end-users), then this "limitation" may be acceptable. >> 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. That's certainly another approach. > if we get to that then... why are we making these exist anyways? Actually, that latter part is probably the best question. It would probably be a useful thought exercise to revisit why they were originally created (anybody got pointers to source material?), whether those applications still hold water in today's world and/or if there are new, _practical_ (i.e.: could really get deployed) uses for them. Of course, there's always the argument that folks may want to use HbH headers in a private network (Enterprise network?) context, but "good luck" on getting them to be recognized or acted upon (at all) by SP routers. However, it seems like too much work to document even that in a BCP as the boilerplate would likely overwhelm the actual content of said draft/RFC. (Or, at least I'm not volunteering to do so :) -shane > -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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
