Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt]

From: Ananth Suryanarayana <[email-masked]>
Date: Wed, 11 Mar 2009 15:31:40 -0700

Hi,

According to the spec..

A NEW BGP speaker that receives malformed AS4_PATH attribute in an
UPDATE message from an OLD BGP speaker MUST discard the attribute,
and continue processing the UPDATE message. The error SHOULD be
logged locally for analysis.

1. Can this phrase "continue further processing"  be further clarified ?
     According to [OPT-ATTR-E], malformed optional-transitive-partial attributes
     must be discarded and handled as withdraws instead. I believe we should
     do the same here.

2. Though, it is expected that AS4Path and [Aggregator4] attribures sent from
   Old speakers are marked 'partial', if it is not done so, should they still
   be treated as withdraws (because we know that peer is Old Spekaer from
   capabilities negotiated). I would think so. (Though only relying on the
   partial bit in the attribute flags makes all (except may be Aggregator4)
   malformed otional-transitive-partial attributes processing consistent.

Thanks
-- 
Regards,
Ananth

-- 
----- Forwarded message from Enke Chen <[email-masked]> -----

Date: Mon, 9 Mar 2009 17:32:05 -0700
From: Enke Chen <[email-masked]>
To: Inter-Domain Routing List <[email-masked]>
Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt]

FYI  -- this revised version includes further clarifications in the 
Error Handling section.

-- Enke

-------- Original Message --------
Subject: 	I-D Action:draft-chen-rfc4893bis-02.txt
Date: 	Sat, 7 Mar 2009 16:00:02 -0800 (PST)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : BGP Support for Four-octet AS Number Space
	Author(s)       : Q. Vohra, E. Chen
	Filename        : draft-chen-rfc4893bis-02.txt
	Pages           : 11
	Date            : 2009-03-07

Currently the Autonomous System (AS) number is encoded as a two-octet
entity in BGP. This document describes extensions to BGP to carry the
Autonomous System number as a four-octet entity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

----- End forwarded message -----

---

From: Enke Chen <[email-masked]>
Date: Wed, 11 Mar 2009 16:26:36 -0700

Hi, Ananth:

On your comment #1:

[OPT-ATTR-E] provides two options for handling a malformed optional transitive attribute:

    1) Treat as withdraw.
    2) Discard the attribute.

Currently the rfc4893bis specifies the "Discard the attribute" option (thus favors reachability) for a malformed AS4_PATH attribute from an OLD speaker due to the following considerations:

   - During the transition, the 2byte AS numbers will dominant. So the as-path loop detection will be intact across the 2byte AS domains.

   - The possible routing loop (due to loss of AS4 info) would be broken somewhere, as pointed out by John Scudder).

   - Other side effects (such as potential oscillation) are highly topology and policy dependent, and should be rare.

In case of a real side effect, operator intervention (such as applying a filter) would be required, as with the "Treat as withdraw" option. However, such intervention would be on a needed based, instead of immediate for the "Treat as withdraw" option.

In the case of a malformed AS4_PATH attribute, there is really no perfect solution. The tradeoff is between preserving the reachability and dealing with potential side effects. As currently specified, rfc4893bis favors reachability.

On your comment #2:

The partial bit should have been set for the AS4_PATH or AS4_AGGREGATOR from an OLD speaker. If it is not set, it is covered by [OPT-ATTR-E]:

   In the specific case of incorrect path attribute flag bits -- i.e., a
   path attribute that is known by its type code to be Optional and
   Transitive but whose flag bits are not set accordingly -- the
   behavior specified by [RFC4271] SHALL be followed.  (Consider that in
   the case of such an error, the "tunneling" argument given above does
   not apply, by definition.)

Although the speaker at fault is punished, one can argue that it is a bit harsh for a recoverable error.

Thanks.   -- Enke