Subject: route to null0

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 11:10:08 -0400

If a speaker aggregates a route, a route to the aggregated set of
destinations with a next-hop of null is installed in the speaker's routing
table.  This is done to avoid a routing loop in the event that: one of the
more specific routes goes away, the peer (that the aggregate was advertised
to) advertised the default route, and the peer (that the aggregate was sent
to) sends a pkt to the speaker destined for the more specific route that
went away.

I think the current draft stipulates that this should be handled by the
speaker withdrawing the more specific route and/or de-aggregating or
something; there is no mention of the current working code's "null solution"
(as described above).

Not sure what Juniper does on this one (use 127.x.x.x vs null0 ???).

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 02 Oct 2002 08:27:22 -0700

Jonathan,

> something; there is no mention of the current working code's "null solution"

See Section 4.2 RFC1519.

Yakov.

> ------_=_NextPart_001_01C26A25.CBF1A260
> Content-Type: text/html
> 
> <html>
> 
> <head>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
> 
> 
> <meta name=Generator content="Microsoft Word 10 (filtered)">
> 
> <style>
> <!--
>  /* Style Definitions */
>  p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman";}
> h1
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.25in;
> 	page-break-after:avoid;
> 	font-size:16.0pt;
> 	font-family:"Times New Roman";}
> h2
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.8in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.3in;
> 	page-break-after:avoid;
> 	font-size:12.0pt;
> 	font-family:Arial;}
> a:link, span.MsoHyperlink
> 	{color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{color:purple;
> 	text-decoration:underline;}
> p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft, div.StyleHeading
1Arial12ptLeft
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.25in;
> 	page-break-after:avoid;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman";
> 	font-weight:bold;}
> p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered, div.StyleArial22
ptBoldCentered
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	text-align:center;
> 	font-size:20.0pt;
> 	font-family:Arial;
> 	font-weight:bold;}
> span.EmailStyle19
> 	{font-family:Arial;
> 	color:windowtext;}
> @page Section1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.25in 1.0in 1.25in;}
> div.Section1
> 	{page:Section1;}
>  /* List Definitions */
>  ol
> 	{margin-bottom:0in;}
> ul
> 	{margin-bottom:0in;}
> -->
> </style>
> 
> </head>
> 
> <body lang=EN-US link=blue vlink=purple>
> 
> <div class=Section1>
> 
> <p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
> font-family:Arial'>If a speaker aggregates a route, a route to the aggregated
> set of destinations with a next-hop of null is installed in the speaker's
> routing table.&nbsp; This is done to avoid a routing loop in the event that: 
one
> of the more specific routes goes away, the peer (that the aggregate was
> advertised to) advertised the default route, and the peer (that the aggregate
> was sent to) sends a pkt to the speaker destined for the more specific route
> that went away.</span></font></p>
> 
> <p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
> font-family:Arial'>&nbsp;</span></font></p>
> 
> <p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
> font-family:Arial'>I think the current draft stipulates that this should be
> handled by the speaker withdrawing the more specific route and/or
> de-aggregating or something; there is no mention of the current working code'
s
> "null solution" (as described above).</span></font></p>
> 
> <p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
> font-family:Arial'>&nbsp;</span></font></p>
> 
> <p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
> font-family:Arial'>Not sure what Juniper does on this one (use 127.x.x.x vs
> null0 ???).</span></font></p>
> 
> </div>
> 
> </body>
> 
> </html>
> 
> ------_=_NextPart_001_01C26A25.CBF1A260--

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 02 Oct 2002 12:21:09 -0400

In message <[email-masked]
ks.com>, "Natale, Jonathan" writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> Content-Type: text/plain

This is specific to one implementation (and similar in others).  A
data structure is needed to represent the aggregate and the route data
structure is one that is clearly visible (in "show" commands) and
understood by the user to be an internally generated aggregate.

Avoiding the route loop with a less specific aggregate that overlaps
the aggreagate that was formed is another good reason to use a route
data structure.  The effect is to black hole the destinations for
which there are no more specific routes rather than loop.

> something; there is no mention of the current working code's "null solution"

There is no need to reflect one vendor's implementation details.  It
has no affect on the spec.  If a different data structure is used and
it doesn't appear in the "show ip route" or equivalent but is listed
by a separate command that's fine with the BGP spec.  If it also can
transform a loop into a black hole, all the better.

It would seem obvious enough that if the component routes go away, the
aggregate must be deleted.  It is also obvious enough that if you
advertised the component routes (not doing a summary aggregate) that
you still need to withdraw them if they go away.  It also seems
obvious enough that if the set of components change, the AS-SET, if
used, has to be updated if it has changed.  This is one reason why no
one uses AS-SETs anymore, preferring ATOMIC_AGGREGATE.

In no case can you advertise something and forget about it, not
withdrawing the route if it is no longer valid.  We don't need to
explicitly state that this also holds true for aggregates.

Curtis