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

[Enke Chen <[e-mail]>]

Hi, Samita:

Please see my comments inlined.

Samita Chakrabarti wrote:
>
> 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./*
>

The text in the document is very specific and clear.

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

Again, the document is clear about using AS_TRANS in the "My AS number" 
field:

   To represent 4-octet AS numbers (which are not mapped from 2-octets)
   as 2-octet AS numbers in the AS path information encoded with 2-octet
   AS numbers, this document reserves a 2-octet AS number.  We denote
   this special AS number as AS_TRANS for ease of description in the
   rest of this specification.  This AS number is also placed in the "My
   Autonomous System" field of the OPEN message originated by a NEW BGP
   speaker, if the speaker does not have a (globally unique) 2-octet AS
   number.


> */ /*
>
> */ /*
>
> >
>
> >-) 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 ?/*
>

Just FYI - there have been multiple implementations and deployments 
since 2004.

In terms of transition, please see Section 6. It assumes a reasonable 
way of transition:

   To simplify transition, this document assumes that an Autonomous
   System could start using a 4-octet AS number only after all the BGP
   speakers within that Autonomous System have been upgraded to support
   4-octet AS numbers.


> */ /*
>
> >
>
> >-) 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 ? /*
>
>

This is a moot point at this time. After years of implementation and 
deployment, there can not be any change to the update generation. 
Besides what you proposed is something that was discussed and not 
pursued due to the major flaw I pointed out.

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

Sorry to say that you might be misinformed of the use of AS 23456. In 
the public internet, one must use an AS number allocated by IANA. 
Otherwise there are consequences, including partial connectivities ....

The allocation and management of AS numbers are outside the scope of the 
document.

> */ /*
>
> */ /*
>
> */ [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 ]/*
>

Please see Section 6 (Transition) of the document. The document assumes 
(probably should recommends) that the provider networks are upgraded 
first before connecting non-mappable 4byte AS peers.

Regards, -- Enke

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