Subject: Re: My BGP Route Update Pacing Draft

From: Mareline Sheldon <[email-masked]>
Date: Tue, 23 Jul 2002 04:52:05 -0700 (PDT)

Hi Manav,
| 
| 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!

what exactly do you mean by this?

Regards,
mareline s.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 23 Jul 2002 17:31:55 +0530

Mareline,

| | 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!
|
| what exactly do you mean by this?

If you have some UPDATEs to announce and if you are holding them back
because of the congestion you perceive in the network and then if you
recieve a WITHDRAW for one of those same prefixes then you have to first
advertise the UPDATEs because it is invalid to announce the same address
prefix in the WITHDRAWN routes and the NLRI field of an UPDATE message. You
thus end up flushing all the BGP UPDATEs you had piled up waiting for the
congestion to clear out at your remote end. The better solution is to let
TCP take care of the congestion internally as it has always been OR if you
want to dynamically adjust to the congestion then you may re-negotiate the
HoldTimer using the Dynamic Capabilities.

I hope i make myself clear.

Regards,
Manav

---

From: Dennis Ferguson <[email-masked]>
Date: Tue, 23 Jul 2002 15:35:42 -0700

Hello,

> congestion to clear out at your remote end.

Why would you do this?  If you receive a withdrawal for a route for which
you haven't sent an UPDATE yet, why wouldn't you forget about the UPDATE
and just send the withdrawal (or, if you've never advertised the route
to the peer, just send nothing at all)?  If a route is flapping and
goes up and down 62 times while your peer has you flow controlled, would
you really send the 62 flaps when the peer allows you to send again?  Why
wouldn't you just send the final result?

You need to do routing protocol implementations in a way which avoids
unbounded state, and doing this means that you shouldn't be recording
all route transitions to play back to a peer which isn't listening at
the moment.  If the only state you keep is what you advertised to the
peer before and what the state of the route is now, then the amount
of state you need to keep remains proportional to the number of routes
you have and you only need to advertise the current state (if it doesn't
match what the peer already knows, otherwise you send nothing) when
the peer starts taking updates again.

> The better solution is to let
> TCP take care of the congestion internally as it has always been

I don't think this has much to do with TCP, TCP flow control works
the same way.

Dennis Ferguson

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 24 Jul 2002 09:37:11 +0530

Hi Dennis,

| Why would you do this?  If you receive a withdrawal for a route for which
| you haven't sent an UPDATE yet, why wouldn't you forget about the UPDATE
| and just send the withdrawal (or, if you've never advertised the route
| to the peer, just send nothing at all)?  If a route is flapping and

Depends on whether your BGP UPDATE packets waiting to be announced are in
some transit queue above the TCP or lying below it. If you have already
given the UPDATE to the TCP then there isnt much that you can do upon
receiving the WITHDRAW. If its the former case (above TCP) then i have yet
to see any implementation which scans through all the pending BGP UPDATEs
it has in its transmit queue upon receiving the withdraw to remove the NLRI
if it exists in the withdraw also OR scanning through all the WITHDRAW
messages when it recieves any new NLRI to advertise.

Manav

---

From: vrishab sikand <[email-masked]>
Date: Tue, 23 Jul 2002 21:59:14 -0700 (PDT)

Manav Bhatia <[email-masked]> wrote: 
Hi Dennis,

Such  implemenations exist. and it does not require scanning any update list. The route entry itself can have enough information in it to indicate to which neighors it has been sent and to which neighors it has been queued to be sent to. Off course once it is given to TCP it is as good as sent but thats not a long list as TCP buffers are not VERY large @16K in most implemenatations.

Manav

---------------------------------
Do You Yahoo!?
Yahoo! Health - Feel better, live better