On Mar 3, 2009, at 3:12 AM, Danny McPherson wrote:
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."
Can you be more specific about this? It seems to me that the behavior for setting the Partial bit is fully specified, so all compliant & correct implementations should behave more or less the same in that respect.
Since the relevant corollary in this case is that if the Partial bit is not set we know that the direct peer recognized the path attribute (else it would have set the Partial bit), I guess we can focus on what the consequences are if that is NOT done. Case 1 is when the direct peer doesn't set Partial even though it doesn't recognize the attribute. In that case we would falsely "blame" the direct peer for the detected malformation and reset the session. I think this is OK insofar as the direct peer *does* have a bug in its path attribute handling in this scenario, although not the one we think it does. Case 2 is when the direct peer recognizes the attribute but sets Partial anyway. In that case we would mistakenly give the direct peer a free pass instead of "blaming" it, and would follow the treat-as- withdraw behavior instead of resetting the session. This isn't ideal, but we already think treat-as-withdraw is OK as the general-case error- handling behavior -- session reset is an optimization. So I think that's OK. (Also I think these scenarios are pretty far-fetched.)
Based on this I'm comfortable with relying on the Partial bit. If we weren't going to do this the question would be, what to do instead?
--John