Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

I agree with the text proposed by Danny, to handle this particular
malformed-ness in AS4_PATH attribute.

> Recommended addition to RFC 4893 - S 4.2.3:
>
>   If a NEW BGP speaker receives an UPDATE message containing the path
>   segment types AS_CONFED_SEQUENCE or AS_CONFED_SET [RFC3065] in the
>   AS4_PATH attribute, it MUST strip and discard those segments from
the
>   attribute and continue processing the the AS4_PATH attribute.  The
>   BGP speaker MUST log the event in a manner that assists network
>   operators in determining the originator of the malformed attribute.

Further, may be the general handling of "malformed
optional-transitive-attributes" needs a closer look (RFC-4271) too -
given the fact that whenever new-features using newer
opt-trans-attributes are deployed, we may hit this issue. 

May be implementations should provide the operator with means to be
cognizantly lenient and skip the malformed optional-transitive-attribute
without dropping the session.

i.e.

RFC-4271: section "6.3 UPDATE Message Error Handling"
---------
May be we can consider Changing this text:
   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded, and the Error Subcode MUST be set to Optional
   Attribute Error.  The Data field MUST contain the attribute (type,
   length, and value).
To:
   If an optional transitive attribute is recognized, then the value of
this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded. And the speaker MAY continue processing the UPDATE

   after logging the event in a manner that assists network operators in

   determining the originator of the malformed attribute; this decision 
   should be taken on a case-by-case basis as specified by the
attribute's 
   error-handling mechanisms. If the speaker chooses to send a
Notification, 
   Error Subcode MUST be set to Optional Attribute Error.  The Data
field 
   MUST contain the attribute (type, length, and value).

Thanks,
Kaliraj 
-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
Danny McPherson
Sent: Tuesday, December 16, 2008 6:45 AM
To: Enke Chen
Cc: Inter-Domain Routing List; quaizar.vohra@gmail.com
Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

On Dec 15, 2008, at 5:16 PM, Enke Chen wrote:
>
> The logic here appears twisted. I have never said that either RFC  
> should NOT be updated. I just gave the rational why the behavior was  
> not spelled out explicitly in the 4byte AS document (because we  
> thought that's covered by the confed documentation). Also I stated  
> that the behavior for processing unexpected confed segments should  
> be the same in both RFCs.

Heh, ok then :-)

> If the WG consensus is to update RFC 5056 / RFC 4893, or both, I  
> will be glad to do my share with Quaizar on RFC 4893.

Very well, thanks Enke!

-danny
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr