Subject: RE:

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 23 Jul 2002 10:47:36 -0400

Sri:
  How would you handle many adds and withdrawls of same routes. Would that
not cause
the effect of alot more update messages?

Say we get into route oscillations related problems, would we see alot of
updates in a given period of time?

Ben

> -----Original Message-----
> From: Padmaja kotamarthiC [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 10:35 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: 
> 
> 
> Hi Manav,
>         If your peer is congested for whatever reason
> the simple solution is to: set the peer prefix limit
> to the appropriate value to avoid the problem. 
> 
> sri
> 
> Hi Ben,
> I have some thoughts on the draft.
> 
> The crux of your draft is that if a peer gets so
> congested that it is not
> able to send any UPDATE/KEEPALIVE message to the
> remote uncongested peer
> then the session can break down because of the Hold
> Timer expiring and it
> can be prevented by sending some pacing information
> which will inform the
> uncongested peer to limit its route advertisement
> rate. The PACING
> information will too be carried in the TCP packets, so
> if the TCP is
> implementing flow control and is not sending packets
> to avoid congestion
> then how will the PACING information be sent? And if 
> TCP can send the
> PACING information then it can as well send the
> KEEPALIVE packet which will
> keep the HoldTimer from expiring at the other end.
> 
> Secondly, if you are aware that your router is old and
> might come in a
> situation when it might not be able to handle the full
> feed of BGP Updates
> from the remote end then it can negotiate a HoldTime
> of zero and keep the
> session running even when it is in the congested
> state.
> 
> Thirdly, the very idea of artificially impeding
> reachability information
> (or sending of BGP UPDATE messages) doesn't really
> appeal to me. I was
> initially against the idea of using
> MinRouteAdvertisementInternal etc
> timers in my implementation arguing that a router
> should pack off any
> reachability information it has as soon as it comes to
> know of it. But this
> created a problem when i got say some 80K routes. I
> would then be sending
> 80K packets to my other peers! Finally , better sense
> prevailed on me and i
> started using the timers for efficiently packing my
> NLRIs in the UPDATE
> messages. This is one point where i hold my
> reachability information from
> my peers & I discourage it doing any other time. IMHO
> i feel we should let
> TCP take care of withholding any data it wants with
> itself till the
> congestion state rides by rather than us interfering
> with it.
> 
> What happens say when an uncongested router receives
> pacing information
> telling it to reduce the advertisement rate by some
> 70%. In that case there
> will be many UPDATEs lying with it remaining to be yet
> announced to the
> remote peer which is experiencing congestion. Now what
> if the uncongested
> network receives withdrawals (both implicit and
> explicit) for certain
> prefixes which have already been announced or remain
> yet to be announced?
> You open up a can of worms now !!
> 
> You have to now flush all your output buffers
> regardless of the congestion
> state your remote peer lies in!
> 
> Thus you end up doing what you always wanted to avoid.
> 
> I think a cleaner and a much simpler approach would be
> to dynamically
> negotiate the value of the HoldTimer during the
> session. If you feel you
> are getting congested then increase the value and once
> the red flags are
> all down you can revert back to your original value or
> decrease it back
> again.
> 
> Regards,
> Manav
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Abarbanel, Benjamin"
> <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 19, 2002 1:01 AM
> Subject: My BGP Route Update Pacing Draft
> 
> 
> | Hi all:
> |
> |    Our recent discussions on this list and my recent
> work
> |  experiences have led me to write this draft and
> offer it
> |  to the IETF community. I would appreciate any
> comments
> |  anyone has to make.
> |
> |  Thanks in advance,
> |  Ben
> |
> |
> |
> |
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>