On Fri, Feb 4, 2011 at 12:31 AM, Shane Amante <sh...@castlepoint.net> wrote: > 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. >
I don't disagree with being careful. > 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. > You probably also want this to be rate-limited separately from your example ICMP rate-limit, correct? Do you want to lose functionality or features because hop-by-hop is over-running the limiter? ICMP limits (error limits) are often there, because generate of unreachables happens in hardware in many platforms, to protect OtherPeoplesNetworks not your device. Limits set against transit traffic (icmp echo/echo-reply rate-limits) generally require a filter on the interface (or interface level configuration), that too is sub-optimal. I could see a limiter for HBH, in a cisco example, at or before the linecard-CPU (from interface -> LC-CPU -> RP for the example here) that is built into the hardware and is different from what exists today for COPP. Again, this is something that will impact transit traffic, so how reliable is it going to be? how reliable is it expected to be? >>> 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. I'd also be interested in the purpose of these... > > 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 :) > Yup, the 'but these are only supposed to be used in private networks' worked well for .. NetBios :( or many, many other protocols. Hoping that this 'bad thing' will only be used on the 'inside' has a horrible track record. -chris > -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 --------------------------------------------------------------------
