On 18 Apr 2012, at 02:47, heasley wrote: > Mon, Apr 16, 2012 at 05:37:02PM -0700, Tony Li: >> >> On Apr 16, 2012, at 5:24 PM, Christopher Morrow wrote: >> >>> If the concern is, this peer keeps sending me an update that is >>> unparsable, ignoring it (and logging a note/alert/etc) seems ok. If >>> the problem is that the neighbor did something quite wrong on the >>> session as a whole more immediate action should be taken. >> >> >> Sending something unparsable *is* quite wrong and just ignoring it is going >> to lead to errors down the road. See previous comment about withdrawn >> routes in updates. > > We agree with Tony. Furthermore, if an update has a parsing or semantic > error, what degree of confidence does one have that any portion that appears > to be parsable is in fact correct?
When the error is with the logic of what is in the well-formed attributes, rather than an error with how the UPDATE itself is built, then I don't see why this assumption is dangerous. Essentially, where treat-as-withdraw is defined as the approach, then the intention is that we are confident that we can apply some form of targeted error handling to deal with this. A couple of examples off the top of my head: - AS4_PATH - in this case, we had AS_CONFED_SET in AS4_PATH - the whole UPDATE is completely valid just what was in a particular attribute is not allowed. - AS0 in AGGREGATOR (http://www.ietf.org/mail-archive/web/idr/current/msg05816.html) - again, a valid UPDATE, just where a particular set of content was not considered valid. As I see it, we have to balance the two approaches of absolute confidence and correctness against the robustness requirements for how the protocol is deployed, and this is what is described in the draft at some length. In some deployments the requirement might be for 100% correctness, and hence perhaps the requirements described within the draft won't be desirable. However, bear in mind that the requirements in the draft are not defining that one must deploy all (or even any of) the error handling mechanisms in all deployments, but rather it states the requirements that occur when one removes the statement that you MUST send a NOTIFICATION and hence impact all NLRI. As with all compromises, it will be up to individual operators to choose the right balance for their deployment. The "semantic" category of errors are those where we consider that we can extract the NLRI with a degree of confidence that it is correct. If there are problems with the definition in the draft, or the types of errors that are listed - let's please discuss this here. I'd really welcome as much feedback as possible from the WG on this! Kind regards, r. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
