Subject: [Idr] draft-ietf-idr-error-handling

From: <[email-masked]>
Date: Tue, 12 Nov 2013 10:21:18 +0000

Hi,

draft-ietf-idr-error-handling §2 says:
" If the "Optional bit" or the "Transitive bit" in the Attribute
      Flags for an attribute conflicts with the Attribute Type Code,
      then the error SHOULD be logged, and the conflicting bit in the
      Attribute Flags MUST be reset to the correct value."

IMO, if the "Transitive bit" is found to be 1 (transitive) in the received UPDATE message while should be 0 (non-transitive) as per the spec then the attribute MUST be discarded.

Indeed if there is such a conflict, it means that previous BGP speakers did not recognize the attribute and have propagated it because of the Transitive bit (incorrectly set to Transitive). 
This was not the intended behavior as the Transitive bit should have been cleared/non-transitive and hence previous BGP speaker not understanding this attribute should have removed it.

This would also match the analysis performed by Eric for the specific case of the AIGP attribute. (http://tools.ietf.org/agenda/88/slides/slides-88-idr-2.pdf slides 3 & 4)

Thanks,
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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Chris Hall" <[email-masked]>
Date: Wed, 13 Nov 2013 14:11:48 -0000

Bruno Decraene wrote (on Tue 12-Nov-2013 at 10:21 +0000):
...
> IMO, if the "Transitive bit" is found to be 1 (transitive) in the
> received UPDATE message while should be 0 (non-transitive) as per
> the spec then the attribute MUST be discarded.
> 
> Indeed if there is such a conflict, it means that previous BGP
> speakers did not recognize the attribute and have propagated it
> because of the Transitive bit (incorrectly set to Transitive).
> This was not the intended behavior as the Transitive bit should
> have been cleared/non-transitive and hence previous BGP speaker not
> understanding this attribute should have removed it.

It could also mean:

  * the Attribute Type Code is corrupt...

    ...the fact that the Flags and the Type "conflict"
       doesn't tell you which is correct -- all it
       means is that something is wrong.

  * an earlier Attribute Length is corrupt...

    ...so the Flags and the Type are both nonsense (but
       happily the small number of valid Flags values
       is indicating that something is wrong).

IMO: trying to "patch-up" a set of attributes and continue is a
primrose path of good intentions most likely to lead to
disappointment.  Not to mention being a lot of special purpose code to
implement some ill-defined heuristic(s), which will probably never be
tested outside the lab and which may (or may not) work as expected or
as intended in production.

Chris