<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN
class=893551621-12042006>Greetings,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=893551621-12042006></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=893551621-12042006>Yesterday, I
attempted to propose a solution to the problem described in policy proposal
2006-2. I realize that the explanation I gave was somewhat confusing and ipv4
biased, so let me try it again but in ipv6 terms this time.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>The problem leading
to the BGP convergence issue:</FONT></SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>When the /128 route,
used to resolve the BGP next-hop of the current BGP best
path, is removed from the RIB because the BGP neighbor has gone down, the
BGP next-hop is still resolvable via a less specific route, an aggregate route
for instance, which causes the staled BGP paths to remain in the routing table
for up to 3 minutes (BGP holdtime) even though one or many other paths are
available. This obviously results in traffic being
blackholed.</FONT></SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>The
solution:</FONT></SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>Modify BGP
implementations so they only consider host routes (/128) as valid
routes to resolve the BGP next-hop. This way, if a router goes down
and its loopback interface address disappears from the IGP, its BGP neighbors
will immediately be able to react by invalidating all BGP prefixes having this
address as their BGP next-hop, which leads to a new BGP best path being
selected. This should also be configurable to accept a less
specific prefix to cope with cases where /128 prefixes are not
injected in the IGP under normal conditions.</FONT></SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>This
solution as been applied and tested with ipv4 and is
also applicable to ipv6.</FONT></SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>The point I would
like to get across is that in my view there is ways to handle this issue from a
routing protocol standpoint. I hope this clears out the confusion I created when
I explained at the conference.</FONT> </SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>Please let me know
if you have any questions or comments,</FONT></SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial size=2>BTW: I really
enjoyed my first ARIN meeting!!</FONT></SPAN></DIV>
<DIV><SPAN class=893551621-12042006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV align=left><FONT face=Arial size=2>Harold Ritter, CCIE 4168 (R&S /
SP)</FONT><FONT face=Arial size=2><BR>Cisco Advanced Services</FONT><FONT
face=Arial size=2><BR>1501 McGill College, 6ième étage<BR>Montréal, Québec H3A
3M8 Canada<BR>Téléphone: 514 847-6856<BR></DIV></FONT>
<DIV> </DIV></BODY></HTML>