Subject: RE: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt

From: "Susan Hares" <[email-masked]>
Date: Mon, 22 Aug 2005 07:15:34 -0600

Enke:

Thanks for your note.  My understanding is given the implementation
experience you feel that the benefits of the current draft outweigh any 
Encoding issues.

Sue

-----Original Message-----
From: Enke Chen [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 1:31 AM
To: Susan Hares
Cc: [email-masked]; Inter-Domain Routing List; [email-masked]; Enke Chen
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt

Hi, Sue:

Please see my reply to Paul on some of the considerations (after digging

out some old notes).

In terms of implementation and customer experience, a couple things come

to my mind:

Using the AS_PATH attribute across has the advantage of being able to 
continue using the "as-path" list policy and displaying the "as-path", 
etc, and avoid supporting "new-as-path" in addition to "as-path" in the 
configuation.

As the NEW_AS_PATH is optional, the check for the required attribute 
portion remains unchanged. (As I mentioned earlier, one of the 
considerations was to avoid introducing another "mandatory" attribute. 
This follows the trandition that new attributes have all been "optional"

after RFC 1771).

-- Enke

Susan Hares wrote:

>Enke:
>
>After implementing the 4-Byte AS specification, do you think the
>avoidance of the new attribute justifies the confusion in the AS PATH
>syntax?
>
>Sue
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Enke Chen
>Sent: Friday, August 19, 2005 1:34 PM
>To: [email-masked]; Inter-Domain Routing List
>Cc: [email-masked]
>Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
>
>Hi, Paul:
>
>Thanks for your comments. My comments are inlined.
>
>Paul Jakma wrote:
>
>  
>
>>Hi,
>>
>>Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>>
>>I am curious why you chose to overload the syntax of the existing 
>>AS_PATH attribute according to whether two peers are or are not 4byte 
>>ASN capable?
>>
>>My primary concern of this aspect of the draft is that it will become 
>>impossible to parse AS_PATH without external reference. This would 
>>have implications for protocol analysers which are asked to observe a 
>>BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
>>also for 'old' analysers which are asked to observe a session between 
>>new peers (at best, such an analyser would produce syntactically 
>>incorrect results), as well as implications for modularity of code in 
>>BGP implementations.
>>    
>>
>
>
>These protocol analysis tools need to be augmented to support the
4-byte
>
>AS numbers regardless. Without the knowledge of whether the 4-byte AS 
>capability is supported over a session,  there are a couple of options 
>for the tools:
>
>     o introduce a button/knob to allow a user to specify whether the 
>session is doing 4-byte or 2-byte.
>     o or parse the AS_PATH using 2-byte encoding first, if there is an

>error, parse it using the 4-byte encoding (this may not be as robust as

>the previous one).
>
>  
>
>>Would it maybe be better to leave the syntax of AS_PATH alone and 
>>simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte
>>    
>>
>
>  
>
>>(you could even make AS_PATH optional and NEW_AS_PATH well-known 
>>between new speakers, so that AS_PATH slowly dies out during the 
>>transition period)?
>>    
>>
>
>
>One of the consideration was to avoid mandating another attribute.
Also
>
>it seems to be more consistent to use the AS_PATH attribute across the 
>board.
>
>Regards,
>
>-- Enke
> 
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr
>  
>

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