Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

[<[e-mail]>]

Hi all,

Some personal comments on the thread/subject 

1) When we see an error, we need to balance the risk of having a few NLRI unreachable (the ones in the erroneous UPDATE) and the risk of having all NLRI from that session unreachable. Some people assumes that a session can be shutdown because there will be another path for the NLRIs. Unfortunately, the alternate path may also suffer from the same issue. How much the alternate path may experience the same error MAY (SHOULD?) be a point to consider in the solution.

2) Let's evaluate the case where we are not 100% sure we extracted all NLTI from an erroneous UPDATE.
In general, when a single UPDATE is faulty, the error is due to a specific attribute set by the originator. Then if we assume that both MP_REACH & MP_UNREACH are not present in the same update, then only the NLRIs from the originator are impacted. Given that this is the one who played with the attribute, this seems fair to me that the originator is the one who assume that risk.
This may call for not mixing both MP_REACH & MP_UNREACH in the same UPDATE message.

3) We need a short term solution which is local, i.e. not requiring change on peers, in order to be able to deploy it (soon).
That being done, if this turn out to be too limiting/risky, IMO we could also explore a more long term solution requiring a cooperation from the peer. GR based notification & enhanced GR are examples. IMO solutions requiring interop with peers are also deployable, especially within an AS, which is the aspects which concern me the most (i.e. loosing both iBGP client sessions).

4)
>However, I am yet to be convinced of the value of accepting a
>well-known attribute (eg. ORIGIN) if it has invalid Flags or does not
>have (one of) the known valid Length(s).  I assume that accepting such
>an attribute is designed to cope with for software issues at the far
>end.  However, forming these attributes is very simple, well
>exercised, and easily tested code.  

I could agree if and only if we are 100% sure to only kill the "far end" which is responsible for the error.
On the contrary, once the attribute has propagated, deciding to shut down the session could affect losts of NLRI on both the nominal and backup sessions. So I don't think a single (bit) error should have such consequences.

Regards,
Bruno


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.