On Jun 14, 2013, at 2:56 PM, Doug Barton <do...@dougbarton.us> wrote:
> On 06/14/2013 01:39 AM, t.petch wrote: >> ----- Original Message ----- >> From: "Doug Barton" <do...@dougbarton.us> >> To: <ipv6@ietf.org> >> Sent: Thursday, June 13, 2013 9:23 PM >>> On 06/13/2013 01:17 AM, Randy Bush wrote: >>>>> FWIW, I don't think anyone has proposed "if the chain is larger >> than X, >>>>> then drop". >>>> >>>> i am saying that i am telling my neighbor that, if the header length >> is >>>> larger than X, it is likely that their packet will not propagate. >> it's >>>> an ops bcp statement, not a statement of ipv6 protocol definition. >>>> >>>> same as telling them that a bgp announcement of a prefix longer than >> a >>>> /24 likely will not propagete. >>>> >>>> today, real routers really do drop packets with headers longer than >>>> various limits. as an op, i am trying to remove the surprise in the >>>> 'various'. >>> >>> I agree with Randy, providing guidance on this topic will be very >>> helpful, and BCP is the right category. >>> >>> As for what the number should be, if 256 is in the 80th percentile or >>> higher of Warren's survey, that should be fine. A few vendors who are >>> examining less than that now may be encouraged to increase up to 256 >>> knowing that they have a reasonable upper bound to shoot for, as >> opposed >>> to an arbitrarily large number that varies from implementation to >>> implementation. >> >> I would like to check with current hardware designers that 256 is a good >> number for them, as opposed to 240, say. > > Others (more knowledgeable than I) had already made that point, but for the > record, yes, we should check with the hardware folks on this. I've already mentioned this in one of the N (where is is becoming distressingly large) threads on this, but we are planning on: A: adding something like this (you should be able to look N bytes / headers in the packet) to the long headers draft (RSN, promise!) and / or B: writing an advice to implementers draft. One of the co-authors (Ron) of the long-headers draft works for Juniper and has discussed this with their forwarding folk. We are also having discussions with other vendors on the same topic, and will hopefully have another author from at least one of the other large chappies… W > >> What I mean is that 256 is a nice round number, for us as for them, and >> so is a natural choice. But sometimes that has to include red tape, >> control information and such like, so what you get as a nice round >> number is a bit less when you pass it on to the next level of >> processing. Of course, with some hardware, that is built in, so that >> the hardware gets something greater and passes on a nice round number to >> its user (as with memory cards) but I have known occasions in the past >> when this was not the case and the choice of a nice round number caused >> problems. >> >> Apart from that 'detail', I agree with the approach. >> >> Tom Petch >> >>> Doug >>> >>> -------------------------------------------------------------------- >>> 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 > -------------------------------------------------------------------- > -- Credo quia absurdum est. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
