Thanks for clarifying, Robert. On Mar 3, 2009, at 10:22 AM, Robert Raszuk wrote:
Let me clarify ... Note that this option requires that the NLRI field and/or MP_REACH [RFC4760] attribute be successfully parsed. In the case of an optional transitive attribute which has no effect on route selection or installation, the malformed attribute MAY instead be discarded. An example of such an attribute is the AGGREGATOR attribute. In any case, an error in an optional transitive attribute whose Partial bit is set MUST NOT be responded to by sending a NOTIFICATION message or resetting the BGP session.The draft in the current form says to withdraw the routes if malformed partial transitive optional attribute which has an effect on routing is received within the BGP update msg. That is fine. (My email was actually in support on this behavior in response to Danny's mail).On the other hand the draft is confusing in defining the behavior on when such NLRI can not be parsed. That would effectively mean that the update itself can not be parsed and is silently dropped. I am just questioning that part of this draft.
Ah! That was not the intent. That sentence ("Note that this option requires that the NLRI field and/or MP_REACH [RFC4760] attribute be successfully parsed") is non-normative and is meant to draw the attention of implementors to exactly the problem you're pointing out. Two paragraphs down the draft says that if the UPDATE is broken in any other way the normal reset behavior is followed. ("In the event that an UPDATE message is deemed to be malformed in any other way... the procedures of [RFC4271] continue to apply.")
I'll take a note to clarify this in -01, either by removing the sentence which caused the confusion, explicitly calling out non- parseable NLRI as an example of a fatal error, or both.
The draft says: "In any case, an error in an optional transitive attribute whose Partial bit is set MUST NOT be responded to by sending a NOTIFICATION message or resetting the BGP session."So if an optional transitive attribute whose Partial bit is set has an error in it's length field we can not reset the session. That is IMHO too strong of requirement.
Not sure why you see this as a problem -- as long as the error is restricted to that particular optional transitive attribute, that is exactly the error case this draft is trying to cover. Indeed for practical purposes length field errors are the majority of discoverable errors in optional transitives. And the same exact problems apply for length field as any other error -- that is, routers which do not recognize that particular attribute are unable to validate the length field since they don't know what the length is supposed to be. I do agree (see above) that if there is any error in the UPDATE other than one restricted to an optional transitive Partial attribute, RFC 4271 rules should continue to apply.
More over such silent update drop dimension may be very difficult to architect around.
To reiterate, "silent update drop" isn't the intent of the draft and we'll strive to make this even clearer in the next version.
Thanks, --John