Hi Danny, > contained prefixes had been withdrawn". I'd strongly > prefer that in ALL cases the update be discarded.Wouldn't making "silent" update discard lead to stale BGP paths sitting in the network as long as the session they were received on is up ? I am thinking about implicit/explicit withdraws in fact in both ebgp and ibgp cases.
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 ?
I think the current text at least suggest that if withdraw of NLRIs is possible when we drop the update let's dispatch it.
I personally don't like the "if" part. If we make a protocol decision optimized for "most common" scenarios and not "all cases" IMHO we are already starting to cut the branch we are sitting on.
"While lamentable, this issue is expected to be rare in practice, and more importantly is seen as less problematic than the session-reset behavior it replaces."I would actually propose to drop the update _only_ if withdraw of NLRIs it contains can be generated. If not continue today's behavior to drop the session. Having even if "rear in practice" black wholes is quite scary if some folks are already looking at using IP to control for example commercial aircrafts.
Two additional points to the claim that dropping the session is worst thing ...
* We design a mechanism without any assumption if 1% or 99% or received updates contain a malformed transitive optional attribute. If it is the latter wouldn't dropping the session be actually much cleaner solution network wide ?
* Considering bigger picture and the consequence of dropping the session it is true that today it may result in BGP churn and potential for traffic disruption. But let's keep in mind that more and more tools are being introduced across vendors to allow you to have path redundancy already in place for each net. That combined with peering redundancy would effectively result in a very localized path switchovers with almost negligible network wide consequences of single session drop.
Cheers, R.
On Mar 1, 2009, at 6:40 AM, John G. Scudder wrote:FYI. We plan to present this at the upcoming IDR meeting.URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txtSome comments on the draft... - I'm not sure I like the recommended behavior in S 2 where we're treating malformed updates "as though all contained prefixes had been withdrawn". I'd strongly prefer that in ALL cases the update be discarded. Making assumptions and providing rules for how to selectively handle mal-formed updates seems much like something you yourself would caution us against. I'd much prefer a 'discard and log' requirement. - I could see how this text is S 2. might not be the case, if varying implementations handle a given update in different ways: "This is likewise the case if an optional transitive attribute is received whose Partial bit is not set -- this is because the detected error can be imputed to the direct peer." No other comments, I think this is a useful document. -danny _______________________________________________ Idr mailing list Idr at ietf.org https://www.ietf.org/mailman/listinfo/idr