On Apr 20, 2012, at 1:00 AM, Rob Shakir wrote:

> 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!


Rob,

Thank you, I think that this was enormously constructive.

Yes, if we're willing to dive down a layer, we can classify errors as syntactic 
and semantic.  Syntactic would be ones that include inconsistent TLV lengths, 
unknown mandatory attributes, etc.  Semantic errors would be about TLV contents.

I could see taking drastic action for syntactic errors, but being more genteel 
about semantic errors with the exception of NLRI.  If those are busted in some 
way, I don't see how you can even "treat as withdraw".

Regards,
Tony


_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to