I-D Action:draft-ietf-idr-dynamic-cap-10.txt

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           : Dynamic Capability for BGP-4
	Author(s)       : E. Chen, S. Ramachandra
	Filename        : draft-ietf-idr-dynamic-cap-10.txt
	Pages           : 8
	Date            : 2010-01-15

This document defines a new BGP capability termed "Dynamic
Capability", which would allow the dynamic update of capabilities
over an established BGP session. This capability would facilitate
non-disruptive capability changes by BGP speakers.

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

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Question on draft-ietf-idr-rfc4893bis-01.txt

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

Re: Question on draft-ietf-idr-rfc4893bis-01.txt

Hi, Manish:

Please see my replies inline.

Manish Vora wrote:
> 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 ?
>   

Re: Question on draft-ietf-idr-rfc4893bis-01.txt

Manish,

One clarification below.

Enke Chen wrote:
> Hi, Manish:
>
> Please see my replies inline.
>
> Manish Vora wrote:
>> 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

Re: Question on draft-ietf-idr-rfc4893bis-01.txt

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.

Re: Question on draft-ietf-idr-rfc4893bis-01.txt

Manish Vora wrote:
> 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 ?
>   

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

-- Enke

> 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

Revised proposed IDR charter

Folks,

As you know we're in the process of updating our charter.  Here's a revision to the version we discussed in
Hiroshima, incorporating comments received from WG members and feedback from the IESG and Routing ADs. 
The main changes are a statement that IDR has oversight responsibility for all BGP work done in the IETF,
and an elaborated scope of work section.

If you have comments, please send them within the next week.  

Thanks,

--John & Sue

Inter-Domain Routing (idr)
Last Modified: 2010-01-26

Additional information is available at tools.ietf.org/wg/idr

Chair(s):
 - Susan Hares <shares <at> ndzh.com>
 - John Scudder <jgs <at> juniper.net>

Routing Area Director(s):
 - Ross Callon <rcallon <at> juniper.net>
 - Adrian Farrel <adrian.farrel <at> huawei.com>

Routing Area Advisor:
 - Ross Callon <rcallon <at> juniper.net>

Mailing Lists: