Hi John, 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.
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.
> I'd be interested in feedback from the WG regarding the question of > withdrawing the routes (what the draft proposes) vs. dropping the > session (current behavior). Especially feedback from network > operators. Exactly.In particular I would like to get other's opinion of the previously stated questions ...
* What is better to drop the session or to drop 99% of updates with such session ?
* What people who design mission critical applications based on BGP feel about protocol not being robust in all cases and allowing for "rare in practice" black wholes ?
In other words today we pretty well know how to build redundant and robust networks for such applications by introducing additional peering sessions, dual vendor networks etc .. But that works as long as protocol is 100% accurate. If you would start optimizing it for most common cases that will likely result in introduction of whole new dimension to network design best practices. More over such silent update drop dimension may be very difficult to architect around.
Cheers, R.
Hi Robert, On Mar 3, 2009, at 5:11 AM, Robert Raszuk wrote:Do we making in this draft an implicit assumption that transitive attribute malformation must always happen day one and not after the original advertisement have already left the originator ?No, the draft applies equally regardless of where the malformation is introduced.I think the current text at least suggest that if withdraw of NLRIs is possible when we drop the update let's dispatch it.Sorry, didn't follow the above.Two additional points to the claim that dropping the session is worst thing ...I'd be interested in feedback from the WG regarding the question of withdrawing the routes (what the draft proposes) vs. dropping the session (current behavior). Especially feedback from network operators.--John