Subject: Re: [Idr] MRAI and withdrawals

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 May 2010 15:19:08 +0200

On 28 apr 2010, at 22:48, John Scudder wrote:

> You might want to review this mail thread: http://www.ietf.org/mail-archive/web/idr/current/msg03274.html

Thanks. Also thanks to Paul for his private message.

So basically the argument is that an update could be turned into a withdrawal somewhere along the way.

This is of course true:

A--B-+
     C--D
   E-+

If C allows the path C B A to D but not the path C E and then E becomes reachable, this update from E to C must result in a withdrawal from C to D.

That still doesn't explain what happened from RFC 1771 to RFC 4271, as none of this is explained in the the appendix that describes the difference between the two.

Also, does it really matter how a withdrawal starts its life? A withdrawal means "stop sending packets, I can't deliver them". Delaying this information is harmful, because during the delay packets are spilled on the floor.

If implementations can't easily excempt updates-turned-withdrawals from the MRAI then it would still be better to apply the MRAI only to those, and still excempt "pure" withdrawals.

Also, the path hunting problem is made much worse by delaying withdrawals.

As Paul is already working on an MRAI-related document, I would suggest adding to that document the recommendation that a separate MinRouteWithdrawalInterval is maintained and that the default value for the MRWI is 0 seconds.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 May 2010 14:09:59 +0000

Iljitsch,

On Mon, May 03, 2010 at 03:19:08PM +0200, Iljitsch van Beijnum wrote:
> Also, does it really matter how a withdrawal starts its life? A withdrawal
> means "stop sending packets, I can't deliver them". Delaying this information
> is harmful, because during the delay packets are spilled on the floor.

It does.  MRAI appears to have been designed to reduce churn associated with
convergence events from appearing outside of an AS.  We know from experience
and also several papers that in the event that when reachability is
completely gone for a given prefix that MRAI will delay convergence and
extend the life of path exploration within the Internet.

But we also can show via trivial examples that during iBGP convergence events
that withdrawals may be received from one iBGP peer prior to the receipt of
a similarly valid replacement route.

Given the above, if we propagate a withdrawal immediately, we expose peer
ASes to churn of reachability that will remain viable once convergence has
been achieved.

>From this, we could generalize that *once an AS has converged a given
prefix*, we could then propagage the withdrawal and not contribute to
unnecessary churn.  The text from RFC 1771 and 4271 continue to support
this by recommending that withdrawals internally propagate withdrawals
quickly.

One of the remaining problems, even if you propagate withdrawals quickly, is
that feasible reachability may not be pushed to the front of the queue for
advertisement within the AS.  Presuming we're not TCP window bound, we could
theoretically push such reachability toward the front, but that plays havoc
with the implementation efficient distribution of routes.  This means that
within an AS you will have short-lived blackholes until the feasible
reachability is propagated.

If you find a method for finding the bound time for AS-wide convergence of a
given prefix, make sure the BMWG hears about it.  When I was helping Sue and
Howard on the single-router convergence draft, that was bad enough.  Such a
metric is what should be used to define external MRAI values.

-- Jeff

---

From: Paul Jakma <[email-masked]>
Date: Tue, 4 May 2010 06:53:02 +0100 (BST)

On Mon, 3 May 2010, Iljitsch van Beijnum wrote:

> As Paul is already working on an MRAI-related document,

Not so much a document as adjusting a couple of sentences to reflect 
the state of deployed reality and the consensus here. ;)

> I would suggest adding to that document the recommendation that a 
> separate MinRouteWithdrawalInterval is maintained and that the 
> default value for the MRWI is 0 seconds.

There seems to be a range of opinions on MRAI, so the document 
basically leaves these matters to implementors and operators and 
doesn't recommend any defaults. It allows for the above though.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Answer a fool according to his folly, lest he be wise in his own conceit.
 		-- Proverbs, 26:5