Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt

Hello,

Alex Zinin wrote:

>>2.2.  BGP Algorithms
>>
>>
>>   BGP uses an algorithm that is neither a pure distance vector
>>   algorithm or a pure link state algorithm.  It is instead a modified
>>   distance vector algorithm referred to as a "Path Vector" algorithm
>>   that uses path information to avoid traditional distance vector
>>   problems.  Each route within BGP pairs destination with path
>>   information to that destination.  Path information (also known as
>>   AS_PATH information) is stored within the AS_PATH attribute in BGP.
>>   This allows BGP to reconstruct large portions of overall topology
>>   whenever required.
>>    
>>
>
>I've always been uncomfortable with documents saying that BGP reconstructs the
>overall topology. It doesn't really do this like the link-state protocols do,
>for example.
>  
>
Is this sentence "This allows BGP to reconstruct  large portions of
overall
topology ...." talking about using AS_PATH  as topology information or
reconstructing routes/paths?

>>6.1.1.  CPU utilization
>>
>>
>>   An important and fundamental feature of BGP is that BGP's CPU
>>   utilization depends only on the stability of the Internet.  If the
>>   Internet is stable, then the only link bandwidth and router CPU
>>   cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE
>>   messages.  The KEEPALIVE messages are exchanged only between peers.
>>   The suggested frequency of the exchange is 30 seconds.  The KEEPALIVE
>>   messages are quite short (19 octets), and require virtually no
>>   processing.  As a result, the bandwidth consumed by the KEEPALIVE
>>   messages is about 5 bits/sec.  Operational experience confirms that
>>   the overhead (in terms of bandwidth and CPU) associated with the
>>   KEEPALIVE messages should be viewed as negligible.
>>
>>   During periods of Internet instability, changes to the reachability
>>   information are passed between routers in UPDATE messages.  The
>>    
>>
>
>While theoretically the text is correct and we could talk about periods of
>stability and instability of the Internet, I wonder if this text is still
>applicable from the practical perspective. I.e., the continuous churn that the
>Internet BGP speakers experience ensures that they practically always have
>something to process.
>
>Probably instead of talking about periods of "Internet stability" and "Internet
>instability" we could talk about something like "periods of stable state among
>BGP speakers when they do no have new updates to communicate to each other".
>
>  
>
>>Meyer and Patel                                Section 6.1.1.  [Page 10]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>   greatest overhead per UPDATE message occurs when each UPDATE message
>>   contains only a single network.  It should be pointed out that in
>>   practice routing changes exhibit strong locality with respect to the
>>   AS path.  That is, routes that change are likely to have common AS
>>   path.  In this case, multiple networks can be grouped into a single
>>   UPDATE message, thus significantly reducing the amount of bandwidth
>>   required (see also Appendix F.1 of [BGP4]).
>>
>>   Since in the steady state the link bandwidth and router CPU cycles
>>   consumed by the BGP protocol are dependent only on the stability of
>>   the Internet, it follows that BGP should have no scaling problems in
>>   the areas of link bandwidth and router CPU utilization.
>>    
>>
>
>Not sure I follow here. What is meant by the "steady state" here? If it means
>convergence on a stable topology after the initial exchange of updates, then why
>talk about "stability of the Internet"? 
>
>        I took this to mean that whenever a BGP session starts, there's a
>     potentially long initial exchange of routes, and we mean to exclude
>     that startup transient.
>
>        But, of course, we're back to the "stable Internet" paradigm. :^(

>In other words, if the Internet is
>unstable then can we say that the BGP speakers are in steady state? In the lack
>of topology changes, it seems that the consumption should instead depend on the
>number of peers (affects KEEPALIVE processing) and the number of persistently
>oscillating routes potentially present in the network...
>
I agree the term Internet instability may not be clear enough in this
draft.

It seems that the draft is saying :
BGP CPU's utilization depends mostly on number of route exchanges and
KEEPALIVE message processing is not significant [The route exchanges can
be due to a topology change, router startup, configuration changes,
oscillating routes, ..... And oscillating routes
may be triggered by topology change, router startup, configuration
changes .....] ?

If that's the case, instead of saying Internet stability or instability
as follows :
"If the Internet is stable, then the only link bandwidth and router CPU
cycles consumed by BGP are  due to the exchange of the BGP KEEPALIVE
messages. "

perhaps the draft could say something along this line :
"If there are no route exchanges, then the only link bandwidth and
router CPU cycles consumed by BGP are due to the exchange of the BGP
KEEPALIVE messages".

>   that as the Internet grows,  the overall stability of the inter-AS 
> connectivity of the Internet can be controlled. 

>     Please specify how it is assumed to be "controlled", e.g. through
>     operational practices.

>          I believe historically this meant route-flap damping

I thought route-flap damping may also slow down route convergence
(i.e. may cause instability in turn...)

Regards
Cheng-Yin

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr