Subject: [Idr] Question on draft-ietf-idr-rfc4893bis-01.txt

From: Manish Vora <[email-masked]>
Date: Fri, 22 Jan 2010 04:42:04 -0500

I have a couple of questions on the error handling procedures in draft-ietf-idr-rfc4893bis-01.txt.

(1) Some snippets from Section 6, on Error Handling

   The general guidelines presented in [ATTR-ERROR] apply to the error
   handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in
   this document.

   ...

   A NEW BGP speaker that receives a malformed AS4_PATH attribute in an
   UPDATE message from an OLD BGP speaker MUST discard the attribute,
   and continue processing the UPDATE message.

   ...

   A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute
   in an UPDATE message from an OLD BGP speaker MUST discard the
   attribute, and continue processing the UPDATE message

Although this section makes a reference to [ATTR-ERROR], my understanding upon reading draft-ietf-idr-rfc4893bis-01.txt is that a malformed AS4_PATH or AS4_AGGREGATOR MUST be discarded irrespective of the Partial bit in the Attribute Flags. Is this interpretation correct ?

(2) If the attributes AS4_PATH and AS4_AGGREGATOR are not marked as optional transitive, this should result in a notification message, irrespective of whether this was received from an OLD or NEW speaker, right ? Although this draft attempts to ignore attributes with errors, since it does not mention anything specific about the attribute flags, I am assuming that the following section from RFC 4271 still holds good.
 
   Section 6.3.  UPDATE Message Error Handling

   If any recognized attribute has Attribute Flags that conflict with
   the Attribute Type Code, then the Error Subcode MUST be set to
   Attribute Flags Error.  The Data field MUST contain the erroneous
   attribute (type, length, and value).

Thanks,
Manish Vora

---

From: Enke Chen <[email-masked]>
Date: Fri, 22 Jan 2010 09:26:38 -0800

Hi, Manish:

Please see my replies inline.

> Although this section makes a reference to [ATTR-ERROR], my understanding upon reading draft-ietf-idr-rfc4893bis-01.txt is that a malformed AS4_PATH or AS4_AGGREGATOR MUST be discarded irrespective…

Yes, that is correct..   The reason is that these attributes are 
supposed to be received only from an OLD speaker (which can not sourced 
these attributes).  Thus we already know (without inspecting the partial 
bit) that the direct neighbor is not at fault.

> (2) If the attributes AS4_PATH and AS4_AGGREGATOR are not marked as optional transitive, this should result in a notification message, irrespective of whether this was received from an OLD or NEW s…

Yes - strictly from the protocol correctness aspect.  However, from a 
practical aspect, an implementation should always be very careful in 
generating a notification (due to the disruptive nature).   I am 
wondering what good a notification for the flags would do when the 
attribute is to be discarded anyway.

The time-tested principle may apply again - "Be liberal with what you 
accept and be conservative with what you send".

Thanks.    -- Enke

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

---

From: Enke Chen <[email-masked]>
Date: Fri, 22 Jan 2010 10:24:16 -0800

Manish,

One clarification below.

Enke Chen wrote:
>> Although this section makes a reference to [ATTR-ERROR], my 
>> understanding upon reading draft-ietf-idr-rfc4893bis-01.txt is that a 
>> malformed AS4_PATH or AS4_AGGREGATOR MUST be discarded irrespective 
>> of the Partial bit in the Attribute Flags. Is this interpretation 
>> correct ?
>>   
>
> supposed to be received only from an OLD speaker (which can not 
> sourced these attributes).  Thus we already know (without inspecting 
> the partial bit) that the direct neighbor is not at fault.

"OLD speaker (which can not sourced these attributes)" should have been 
"OLD speaker (which does not understand these attributes)".

-- Enke

>
>
>>
>> (2) If the attributes AS4_PATH and AS4_AGGREGATOR are not marked as 
>> optional transitive, this should result in a notification message, 
>> irrespective of whether this was received from an OLD or NEW speaker, 
>> right ? Although this draft attempts to ignore attributes with 
>> errors, since it does not mention anything specific about the 
>> attribute flags, I am assuming that the following section from RFC 
>> 4271 still holds good.
>>   
>

---

From: Manish Vora <[email-masked]>
Date: Mon, 25 Jan 2010 00:52:48 -0500

Thanks Enke.

I agree with the general guidelines of trying to be liberal when processing received messages. But can the spec be updated to list these out explicitly, or is this not possible since it may cause a conflict with the base BGP spec ?

In particular, if Section 6 on Error Handling could add something along these lines..

   The AS4_PATH attribute in an UPDATE message SHALL be considered
   malformed under the following conditions:

[add proposed text]
   - the attribute is not marked as optional transitive.

If the above is acceptable, then also change this paragraph

   A NEW BGP speaker that receives the AS4_PATH attribute or the 
   AS4_AGGREGATOR attribute in an UPDATE message from another
   NEW BGP speaker MUST discard the path attribute and continue
   processing the UPDATE message. 

to

   A NEW BGP speaker that receives the AS4_PATH attribute or the 
   AS4_AGGREGATOR attribute in an UPDATE message from another
   NEW BGP speaker MUST discard the path attribute (even if
   it is malformed) and continue processing the UPDATE message.

Since this spec actually lists out what is considered malformed, seems like adding this would make it complete.

Thanks,
Manish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke Chen
Sent: Friday, January 22, 2010 10:57 PM
To: Manish Vora
Cc: [email-masked]
Subject: Re: [Idr] Question on draft-ietf-idr-rfc4893bis-01.txt

Hi, Manish:

Thanks.    -- Enke

---

From: Enke Chen <[email-masked]>
Date: Sun, 24 Jan 2010 22:16:27 -0800

> I agree with the general guidelines of trying to be liberal when processing received messages. But can the spec be updated to list these out explicitly, or is this not possible since it may cause a…

We should not specify something that would conflict with the base BGP 
spec..  

-- Enke