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

From: "Susan Hares" <[email-masked]>
Date: Sun, 21 Aug 2005 11:04:53 -0600

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

---

From: Enke Chen <[email-masked]>
Date: Sun, 21 Aug 2005 22:30:35 -0700

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

---

From: Paul Jakma <[email-masked]>
Date: Mon, 22 Aug 2005 13:41:54 +0100 (IST)

On Sun, 21 Aug 2005, Enke Chen wrote:

> 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.

Using NEW_AS_PATH instead does /not/ imply you have to change the 
user interface.

The user continues to work with 'as-path', all that changes is a 
behind-the-curtain implementation detail of how that information is 
represented on the wire. (with a new attr code, so what ;) ).

> 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).

You *are* introducing a new well-known and mandatory attribute 
though. Worse, it has the same type code as an existing attribute, 
but with a different and incompatible syntax. And similar with 
AGGREGATOR.

You're also introducing two additional 'temporary' attributes, 
NEW_AS_PATH and NEW_AGGREGATOR, which after the transition period 
will simply no longer be used anywhere on the internet.

The sensible thing to do is to /not/ overload existing attributes and 
make full use of the new attributes you introduce.

I disagree this makes life more difficult for NEW<->OLD scenarios, 
issues are same really.

> -- Enke

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
All phone calls are obscene.
 		-- Karen Elizabeth Gordon