Subject: [Idr] I-D Action:draft-ietf-idr-optional-transitive-02.txt

From: [email-masked]
Date: Fri, 26 Mar 2010 09:15:08 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Error Handling for Optional Transitive BGP Attributes
	Author(s)       : J. Scudder, E. Chen
	Filename        : draft-ietf-idr-optional-transitive-02.txt
	Pages           : 9
	Date            : 2010-03-26

According to the base BGP specification, a BGP speaker that receives
an UPDATE message containing a malformed attribute is required to
reset the session over which the offending attribute was received.
This behavior is undesirable in the case of optional transitive
attributes.  This document revises BGP's error-handling rules for
optional transitive attributes, and provides guidelines for the
authors of documents defining new optional transitive attributes.  It
also introduces a new Path Attribute flag, Neighbor-Complete, to
allow more accurate fault-finding.  Finally, it revises the error
handling procedures for several existing optional transitive
attributes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 26 Mar 2010 10:44:30 -0700

Folks,

FYI the primary change in this version is to introduce the "Neighbor-Complete" Path Attribute Flag, which we've discussed on the list before (not by that name).  It's a backward-compatible change.  See Section 2.  

This had the side effect of asking the IANA to establish a registry for BGP Path Attribute Flags.  The proposed allocation policy is Standards Action.  See Section 8.

--John

On Mar 26, 2010, at 9:15 AM, [email-masked] wrote:
> <draft-ietf-idr-optional-transitive-02.url>_______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 26 Mar 2010 19:09:31 +0000

John,

I think I may have made similar comments to the ones that follow before, but I
have been unable to locate them in my sent mail archive.  Forgive my poor
memory if that's the case.

On Fri, Mar 26, 2010 at 10:44:30AM -0700, John G. Scudder wrote:
> FYI the primary change in this version is to introduce the
> "Neighbor-Complete" Path Attribute Flag, which we've discussed on the list
> before (not by that name).  It's a backward-compatible change.  See Section
> 2.  

This draft presumes a level of conformance with RFC 4271 that should be
reasonable in theory but may not be realized in practice.  Most of the issues
that give me this concern were seen a number of years ago and may not be issues
in practice *now*, but it's probably worth highlighting them anyway.

RFC 4271 (and 1771) requires that our bit-in-question, 5, MUST be set to
zero and MUST be ignored on receipt.

Given an implementation that does *not* zero bit 5 out that does not support
the functionality in this draft and given a vendor train pervasive enough in
a given provider such that the 1 is propagated, you can't necessarily tell
if the 1 was set by the neighbor router or not.  The intervening routers
have properly ignored the bit but weren't clean about setting it back to 0.

(After all, this sort of "propagating evil" is what this draft attempts to
address.)

I will admit that such a bug would simply result in the bad optional
attribute causing the neighboring peering session to be the one to bear the
brunt of the fault even if it isn't theirs.  One could consider this the
price of non-conformance. :-)

A capability that says "I support this update" would remove the shadow of a
doubt that is left here.

All of this said, I do *not* think it's worthwhile to add such a capability.
However, I do encourage IDR readers to attempt to validate the conformance
to the bit-reset behavior in either their code bases or in boxes in their
networks.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 26 Mar 2010 12:12:14 -0700

Jeff,

Thanks for the analysis; I agree with it.

--John