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