Subject: RE: route to null0

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 12:59:49 -0400

ok, I missed it, sorry. I still think it would be nice to add it in the
aggregation section:

Please change:

"Route aggregation and information reduction techniques
(see 9.2.2.1) may optionally be applied."

to:

"Route aggregation and information reduction techniques
(see 9.2.2.1) may optionally be applied."

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2002 11:59 AM
To: Natale, Jonathan
Cc: [email-masked]
Subject: Re: route to null0 

Jonathan,

> Yakov,
> 
> Thanks!
> 
> "A routing domain which performs summarization of multiple routes
> must discard packets which match the summarization but do not match any
> of the explicit routes which makes up the summarization."
> 
> That covers it.  
> 
> I think adding a "[8]" (currently "[8]" is not explicitly cited anywhere)
in
> a strategic spot would be a good idea; I have seen this point missed by
> some.

It is cited in Introduction:

  BGP-4 provides a new set of mechanisms for supporting Classless
  Inter-Domain Routing (CIDR) [8, 9]. 

Yakov.
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: Wednesday, October 02, 2002 11:27 AM
> To: Natale, Jonathan
> Cc: [email-masked]
> Subject: Re: route to null0 
> 
> Jonathan,
> 
> > 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).
> 
> See Section 4.2 RFC1519.
> 
> Yakov.
> 
> > 
> >  
> > 
> > Not sure what Juniper does on this one (use 127.x.x.x vs null0 ???).
> > 
> > 
> > ------_=_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--