Re: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt

["Samita Chakrabarti" <[e-mail]>]

Hi Enke,

 

Thanks for your input. Please see my responses below.

 

>-----Original Message-----

>From: [e-mail] [mailto:[e-mail]] On Behalf Of Enke

>Chen

>Sent: Saturday, March 01, 2008 9:31 PM

>To: idr

>Subject: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt

> 

>Hi, folks:

> 

>I am posting my comments to the mailing list as I will not be at the

>upcoming

>IETF meeting.

> 

>-) On Issue - 1

> 

>   IMO RFC4893 is pretty clear in stating that the Capability "carries

>the 4-octet

>   Autonomous System number of the speaker in the Capability Value

>field". What

>   else needs to be said?

[SC>]  The issue-1 describes the need for clarification for implementation
on OPEN message processing when AS number is present in both capability
message and in "MY AS Number" fields. 

IMO, The document should clarify that AS Number present in Capability
message is used for the AS number and "My AS number" field is ignored. From
RFC 4893, it is assumed that nodes with 4byte-mappable 2-byte AS number can
advertise capability (AS4_PATH) as well as nodes with unmappable 4-byte AS
numbers. In case of un-mappable 4-byte AS numbers,the "My AS number" field
is AS_TRANS.

 

> 

>-) On Issue - 2:

> 

>   The issues with having islands of the same AS number are well
understood.

>   Please see "RFC 2270: Using a Dedicated AS for Sites Homed to a

>Single Provider".

> 

>   We could add the reference when there is ever sufficient reason to

>update the document

>   in the future.

[SC>]  Yes. It should be updated. IMHO, it might be a good idea to clarify
and update the document now before the deployment starts and face
interoperability issues. Are there many implementations in AS4_PATH that
have been interop tested ?

> 

>-) On Issue - 3:

> 

>    The mechanism described in RFC 4893 is designed to avoid the need for a

>    second transition for removing one of the attributes from the global

>routing

>    system.

> 

>    The proposal in Sect. 6.1 is backwards, and would require exactly

>the second

>    transition that we have worked very hard to avoid. The proposal is

>also not

>    realistic as there is simply no easy way to know when the transition is

>    "complete".

[SC>] I don't think RFC 4893 can either tell if the transition is complete
or not by looking at the AS_PATH, since AS_PATH will always contain 4-byte
ASes between two NEW BGP speakers. At the border NEW BGP speaker, it gets
the AS_PATH with 2-byte ASes from the OLD BGP speaker, but there is no way
to know how many ASes are new by looking at the AS_PATH because some
speakers on the path may be 4-byte capable but they have a 2-byte mappable
AS number.

> 

[SC>] Here is a brief analysis:

 

RFC 4893 style:

 Pro: A new BGP speaker can dynamically convert 2-byte AS number to 4-byte
AS-number in AS_PATH at the boundary.

 

Con: This requires extra processing of AS_PATH, AS_AGGREGATE conversion when
there is a OLD BGP peer on one side and a NEW BGP peer on the other side.
4-byte AS number migration will take time, thus during the long period of
transition, the border New BGP speaker will have to do this extra
processing. A new BGP speaker sometimes will process 4byte AS number in
AS_PATH and sometimes 2-bytes depending on whether it is coming from a NEW
speaker or OLD speaker. This overloading of AS_PATH usage can be
error-prone.

 

Proposed style in draft-chakrabarti-idr-rfc4893-mod-00.txt:

Pro: A NEW BGP speaker with 4-byte AS number always includes AS4_PATH

   attribute containing the extended 4-byte AS number.  If the AS number

   is 2-byte mappable, then it adds the corresponding 2-byte mapped AS

   number in the AS_PATH attribute, otherwise it uses AS_TRANS as the AS

   number in the corresponding AS_PATH attribute.  Thus the NEW BGP

   speaker will always have AS4_PATH and a corresponding AS_PATH

   attribute.  No conversion is needed at the transition boundary. Both
AS_PATH and AS4_PATH will co-exist during the transition period.

 

   When transition is over, a BGP speaker can use AS4_PATH only. It is a
simple concept and no overloading.

 

 

Con: Looking at AS_PATH or AS4_PATH info, one can not tell if the transition
has already happened in the Internet. But how important is it to know this
way? Was this a design goal ?

 

>-) On Issue - 4:

> 

>    The reservation of AS_TRANS is relatively new. There are tons of old

>speakers in

>    the field that would happily peer using the value if so configured.

>We can not

>    mandate what an old speaker should or should not do as they are

>already there

>    in the field :-)

> 

>    Also note that AS_TRANS is not the only reserved AS number.

> 

>    It is not clear if there is any practical value for introducing the

>notification.

> 

[SC>] I talked with a few people at NANOG who experienced that AS_TRANS
value was used often as AS number in the current BGP deployment. We can not
expect that every operator or administrator is fully aware of reserved
AS_TRANS value for this special purpose. Thus the notification message from
NEW BGP speaker to OLD BGP speaker who uses AS_TRANS value as "My AS number"
field in the OPEN message is very helpful during transition.

 

[SC>] besides, the transition section of RFC4893 should also mention the
order of AS number transition of PE/CE routers.Some folks think that PE
routers should be transitioned first (if not at the same time) in order to
take care of AS override function at the egress path. [ it is not part of my
draft yet ]

 

Regards,

-Samita

 

 

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr