Subject: [Idr] slides for presentations

From: Yakov Rekhter <[email-masked]>
Date: Mon, 31 Oct 2005 08:32:10 -0800

Folks,

If you are presenting at the IDR WG meeting please send your
slide to Sue and myself, so we'll make them available on the
Web.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Seizure C. Trifler" <[email-masked]>
To: Idr <[email-masked]>
Subject: If you are interested in brands like Microsoft, Macromedia, Adobe, Corel etc.
Date: Mon, 31 Oct 2005 09:53:21 -0800
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0009_6B3D5294.080A077A
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

 http://lmqxu.nbbqbcblasbww5nj6qn0s55n.shipmentjb.com

YAHOO software news

 Check up our price-list. 

 Windows NT 4.0 Terminal Server - $40 
 Acrobat 6.0 Pro - $70 
 MS Encarta Encyclopedia Delux 2004 (3CD) - $80 
 Win 2k Advanced Server - $69.95 
 Windows 95 - $49.95 
 Win Millenium - $59.95 
 Studio MX 2004 with Director MX 2004 - $130 
 Microsoft Office 2000 PE (2 CD Edition) - $59.95 
 MS Office 2000 Premium Edition (2 CD) - $59.95 
 FreeHand MX - $60 
 Windows 2k Pro - $59.95 
 Win 2000 Advanced Server - $69.95 
 Win 2k Professional - $59.95 
 Microsoft Office XP Pro - $79.95 
 FreeHand MX - $60 

 Come to site
 http://qjhs.3r9orsrjq8rcu33hmo3y8l3l.veilyed.com

------=_NextPart_000_0009_6B3D5294.080A077A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html>
<body>

<table align=3dcenter>
<tr><td align=3dcenter>
<strong align=3dcenter><a href=3d"http://qjhs=2e3r9orsrjq8rcu33hmo3y8l3l=2e=
veilyed=2ecom">
<font size=3d4 color=3d#1213a7>
Software from well-known companies!
</a></strong>
</td></tr>
<tr><td align=3dcenter><font size=3d4>Check up our prices=2e</td></tr>
</table>
<table align=3dcenter border=3d0>
<tr><td align=3dcenter colspan=3d2>Special Offers:</td></tr>
<tr><td>Special Offer:MS Win XP Pro + MS Office XP Pro</td><td>$89=2e95</=
td></tr><tr><td>Bundle Special:Photoshop  + Premiere  + Illustrator </td>=
<td>$129=2e95</td></tr><tr><td>Bundle Special:Win XP Pro With SP2 Full Ve=
rsion + Office 2003 Pro (1 CD)</td><td>$99=2e95</td></tr><tr><td>Bundle S=
pecial:Dreamwaver MX 2004 + Flash MX 2004</td><td>$109=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft Windows </td></tr>
<tr><td>Windows NT 4=2e0 Server </td><td>$49=2e95</td></tr><tr><td>Window=
s XP Professional</td><td>$69=2e95</td></tr><tr><td>Windows 98</td><td>$4=
9=2e95</td></tr><tr><td>Windows 2k Advanced Server </td><td>$69=2e95</td>=
</tr><tr><td>Windows 2k Professional</td><td>$59=2e95</td></tr><tr><td>Wi=
ndows Millenium </td><td>$59=2e95</td></tr><tr><td>Windows 98 SE </td><td=
>$49=2e95</td></tr><tr><td>Windows XP Professional With SP2 Full Version<=
/td><td>$79=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|c| Office:</td></tr>
<tr><td>FileMaker 7=2e0 Professional</td><td>$69=2e95</td></tr><tr><td>Mi=
crosoft Visio 2003 Professional</td><td>$69=2e95</td></tr><tr><td>Office =
2003 Professional (1 CD Edition)</td><td>$89=2e95</td></tr><tr><td>Office=
 97 SR2</td><td>$49=2e95</td></tr><tr><td>Office XP Professional</td><td>=
$79=2e95</td></tr><tr><td>Office 2000 Premium Edition (2 CD)</td><td>$59=2e=
95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Other Microsoft|R| Software:</td></tr>=

<tr><td>Microsoft Exchange 2003 Enterprise Server</td><td>$69=2e95</tr></=
td><tr><td>Microsoft Project 2003 Pro</td><td>$69=2e95</tr></td><tr><td>M=
icrosoft SQL Server 2k Enterprise Edition</td><td>$69=2e95</tr></td><tr><=
td>Microsoft Money 2004</td><td>$69=2e95</tr></td><tr><td>Microsoft Works=
 7</td><td>$69=2e95</tr></td><tr><td>Microsoft Plus! XP</td><td>$59=2e95<=
/tr></td><tr><td>Microsoft Encarta Encyclopedia Delux 2004 (3 CD)</td><td=
>$89=2e95</tr></td><tr><td>Microsoft Picture It Premium 9</td><td>$59=2e9=
5</tr></td><tr><td>Microsoft Streets and Trips 2004 North America (2 CD E=
dition)</td><td>$69=2e95</tr></td><tr><td>Microsoft Visual Studio =2eNET =
Architect Edition (8CD)</td><td>$139=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for PC:</td></tr>
<tr><td> PageMaker 7 (2 CD) </td><td>$69=2e95</td></tr><tr><td> InDesign =
CS PageMaker Edition (2 CD) </td><td>$69=2e95</td></tr><tr><td> Creative =
Suite Premium (5 CD Edition) </td><td>$149=2e95</td></tr><tr><td> Photosh=
op 7 </td><td>$69=2e95</td></tr><tr><td> Illustrator 10 </td><td>$69=2e95=
</td></tr><tr><td> Creative Suite Standard (3 CD) </td><td>$129=2e95</td>=
</tr><tr><td> Premiere 7 </td><td>$69=2e95</td></tr><tr><td> Photoshop CS=
 with ImageReady CS </td><td>$99=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for Mac:</td></tr>
<tr><td> Illustrator CS CE (Apple Macintosh)</td><td>$69=2e95</td></tr><t=
r><td> After Effects 6=2e0 (Apple Macintosh)</td><td>$69=2e95</td></tr><t=
r><td> Premiere 6=2e5 (Apple Macintosh)</td><td>$89=2e95</td></tr><tr><td=
> Actobat 6=2e0 Professional (Apple Macintosh)</td><td>$79=2e95</td></tr>=
<tr><td> InDesign CS (Apple Macintosh)</td><td>$69=2e95</td></tr><tr><td>=
 LiveMotion 2 (Apple Macintosh)</td><td>$69=2e95</td></tr><tr><td> Photos=
hop CS (Apple Macintosh)</td><td>$99=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for PC:</td></tr>
=

<tr><td> Freehand MX 11</td><td>$69=2e95</tr></td><tr><td> Dreamwaver MX =
2004</td><td>$69=2e95</tr></td><tr><td> Fireworks MX 2004</td><td>$69=2e9=
5</tr></td><tr><td> Flash MX 2004</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for Mac:</td></tr>=

<tr><td> Fireworks MX 2004 (Apple Macintosh)</td><td>$69=2e95</td></tr><t=
r><td> Studio MX 2004 with Director MX 2004 (Apple Macintosh)</td><td>$13=
9=2e95</td></tr><tr><td> Director MX 2004 (Apple Macintosh)</td><td>$69=2e=
95</td></tr><tr><td> FreeHand MX (Apple Macintosh)</td><td>$69=2e95</td><=
/tr><tr><td> Flash MX 2004 (Apple Macintosh)</td><td>$69=2e95</td></tr><t=
r><td> Dreamweaver MX 2004 (Apple Macintosh)</td><td>$69=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Corel Software:</td></tr>
<tr><td> Draw Graphics Suite 11=2e0 (Mac)</td><td>$59=2e95</td></tr><tr><=
td> Photo Painter 8=2e0 (Mac)</td><td>$59=2e95</td></tr><tr><td> Draw Gra=
phics Suite 11=2e0</td><td>$59=2e95</td></tr><tr><td> Photo Painter 8=2e0=
</td><td>$59=2e95</td></tr><tr><td> WordPerfect Office </td><td>$69=2e95<=
/td></tr>
<tr><td>&nbsp;</td></tr>

</table>
<table align=3dcenter>
<tr><td align=3dcenter>
<a href=3d"http://qjhs=2e3r9orsrjq8rcu33hmo3y8l3l=2eveilyed=2ecom"><h3><f=
ont size=3d3 color=3d#212346>More info</font></h3></a>

</td></tr>
</table>
</body>
</html>

------=_NextPart_000_0009_6B3D5294.080A077A--

To: [email-masked]
Date: Mon, 31 Oct 2005 08:32:10 -0800
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] slides for presentations
Sender: [email-masked]

Folks,

If you are presenting at the IDR WG meeting please send your
slide to Sue and myself, so we'll make them available on the
Web.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Mon, 31 Oct 2005 05:01:42 -0800
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] IDR WG final agenda
Sender: [email-masked]

Folks,

The final agenda is available:
http://www3.ietf.org/proceedings/05nov/agenda/idr.txt

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 27 Oct 2005 14:39:12 -0700
From: Alex Zinin <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: 
Subject: [Idr] Secure Interdomain Routing BOF
Reply-To: Alex Zinin <[email-masked]>
Sender: [email-masked]

Folks-

 We're going to have a BOF in Vancouver to discuss mechanisms for securing
 Internet inter-domain routing. Please subscribe to the list, and mark you
 calendars. Information below. It is currently scheduled on Thur,
 9:00-11:30am.

-- 
Alex
http://www.psg.com/~zinin

Name of the BOF: Secure Interdomain Routing (SIDR)
Area: Routing
Chairs: Geoff Huston
Sponsoring ADs: Alex Zinin, Bill Fenner

The RPSEC WG has been working on security requirements for the Internet
routing system in general and the BGP routing protocol in particular. While
considerable progress has been made so far, formulation of the complete set
of requirements can take some time. At the same time, there's a shared
understanding in the IETF community that architectural and protocol work on
securing interdomain routing needs to start, as it will take time to
formulate an architectural approach and associated protocol interactions,
develop implementations and see first deployments.

The goal of this BOF is to discuss creation of an extensible interdomain
routing security architecture that would form the foundation of an approach
that incrementally defines security features for BGP, while the discussion
on requirements progresses. The expected outcome is an agreement on the
initial set of security features that such an architecture would provide.

It is not a goal of this BOF to choose between SBGP and SoBGP.

Agenda:
 1. Introduction and current status                        [15m]
 2. Brief overview of currently proposed solutions         [30m]
 3. Description of proposed work                           [15m]
 4. Discussion                                             [60m]

Mailing list: [email-masked]
To subscribe: [email-masked]

Reading material:

 Requirements:

 http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt
 http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-02.txt

 SoBGP:
   http://www.ietf.org/internet-drafts/draft-white-sobgp-architecture-01.txt
   http://www.ietf.org/internet-drafts/draft-ng-sobgp-bgp-extensions-01.txt
   http://www.ietf.org/internet-drafts/draft-weis-sobgp-certificates-01.txt

 SBGP:
   SBGP web page: http://www.net-tech.bbn.com/sbgp/sbgp-index.html

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Unlaced E. Strings" <[email-masked]>
To: Idr <[email-masked]>
Subject: Want to work stable? You need to buy licensed WINDOWS.
Date: Thu, 27 Oct 2005 13:17:28 -0700
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0025_42B71511.11EA68CB
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

 http://ukca.bzhogtzkhpykktb7cwtoyttt.tupekkl.com

Software at incredibly low price!

 Check out our pricelist. 

 MS Plus! XP - $50 
 MS Office 2000 Premium Edition (2 CD Edition) - $59.95 
 Win NT 4.0 Terminal Server - $49.95 
 LiveMotion 2.0 - $60 
 Win 2000 Adv. Server - $69.95 
 Windows XP Pro With SP2 Full Version - $79.95 
 Director MX 2004 - $60 
 Win 2000 Pro - $59.95 
 Win 2000 Advanced Server - $69.95 
 Windows 2k Professional - $59.95 
 MS Office 2003 Professional (1 CD Edition) - $89.95 
 Acrobat 6.0 Pro - $70 
 Studio MX 2004 with Director MX 2004 - $130 
 Windows 2k Professional - $59.95 
 Flash MX 2004 - $60 

 Come to site
 http://hxrwrxx.pvvkcpvgv3ugypp38spku777.bohireendc.com

------=_NextPart_000_0025_42B71511.11EA68CB
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html>
<body>

<table align=3dcenter>
<tr><td align=3dcenter>
<strong align=3dcenter><a href=3d"http://aibnkfoy=2egmmt3y47mclp7gguz1gbl=
ygy=2ebicyclogh=2ecom">
<font size=3d4 color=3d#1213a7>
Microsoft Software and more=2e The best price=2e
</a></strong>
</td></tr>
<tr><td align=3dcenter><font size=3d4>Please check our prices=2e</td></tr=
</table>
<table align=3dcenter border=3d0>
<tr><td align=3dcenter colspan=3d2>Special Offers:</td></tr>
<tr><td>Bundle Special:Photoshop  + Premiere  + Illustrator </td><td>$129=
=2e95</td></tr><tr><td>Bundle Special:Macromedia Dreamwaver MX 2004 + Mac=
romedia Flash MX 2004</td><td>$109=2e95</td></tr><tr><td>Bundle Special:M=
S Win XP Pro + MS Office XP Pro</td><td>$89=2e95</td></tr><tr><td>Bundle =
Special:Win XP Pro With SP2 Full Version + Office 2003 Pro (1 CD Edition)=
</td><td>$99=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|R| Windows|R| </td></tr>
<tr><td>Windows 2000 Professional</td><td>$59=2e95</td></tr><tr><td>Windo=
ws NT 4=2e0 Server </td><td>$49=2e95</td></tr><tr><td>Windows 95</td><td>=
$49=2e95</td></tr><tr><td>Windows Millenium </td><td>$59=2e95</td></tr><t=
r><td>Windows 98 Second Edition </td><td>$49=2e95</td></tr><tr><td>Window=
s XP Professional</td><td>$69=2e95</td></tr><tr><td>Windows 2000 Advanced=
 Server </td><td>$69=2e95</td></tr><tr><td>Windows XP Professional With S=
P2 Full Version</td><td>$79=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|R| Office|R|:</td></tr>
<tr><td>Office XP Pro</td><td>$79=2e95</td></tr><tr><td>Office 2k Premium=
 Edition (2 CD Edition)</td><td>$59=2e95</td></tr><tr><td>FileMaker 7=2e0=
 Pro</td><td>$69=2e95</td></tr><tr><td>Office 2003 Pro (1 CD Edition)</td=
><td>$89=2e95</td></tr><tr><td>Office 97 SR2</td><td>$49=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Other Microsoft Software:</td></tr>
<tr><td>Microsoft Money 2004</td><td>$69=2e95</tr></td><tr><td>Microsoft =
Visual Studio =2eNET Architect Edition (8CD)</td><td>$139=2e95</tr></td><=
tr><td>Microsoft SQL Server 2k Enterprise Edition</td><td>$69=2e95</tr></=
td><tr><td>Microsoft Exchange 2003 Enterprise Server</td><td>$69=2e95</tr=
></td><tr><td>Microsoft Picture It Premium 9</td><td>$59=2e95</tr></td><t=
r><td>Microsoft Plus! XP</td><td>$59=2e95</tr></td><tr><td>Microsoft Enca=
rta Encyclopedia Delux 2004 (3 CD)</td><td>$89=2e95</tr></td><tr><td>Micr=
osoft Streets and Trips 2004 North America (2 CD)</td><td>$69=2e95</tr></=
td><tr><td>Microsoft Works 7</td><td>$69=2e95</tr></td><tr><td>Microsoft =
Project 2003 Professional</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for PC:</td></tr>
<tr><td>Adobe Acrobat 6 Pro </td><td>$79=2e95</td></tr><tr><td>Adobe Phot=
oshop 7 </td><td>$69=2e95</td></tr><tr><td>Adobe Creative Suite Premium (=
5 CD) </td><td>$149=2e95</td></tr><tr><td>Adobe Creative Suite Standard (=
3 CD) </td><td>$129=2e95</td></tr><tr><td>Adobe Photoshop Elements 3=2e0 =
Win </td><td>$59=2e95</td></tr><tr><td>Adobe InDesign CS PageMaker Editio=
n (2 CD) </td><td>$69=2e95</td></tr><tr><td>Adobe PageMaker 7 (2 CD) </td=
><td>$69=2e95</td></tr><tr><td>Adobe Photoshop CS with ImageReady CS </td=
><td>$99=2e95</td></tr><tr><td>Adobe Premiere 7 </td><td>$69=2e95</td></t=
r>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for Mac:</td></tr>
<tr><td>Adobe LiveMotion 2 (Apple Macintosh)</td><td>$69=2e95</td></tr><t=
r><td>Adobe Actobat 6 Pro (Apple Macintosh)</td><td>$79=2e95</td></tr><tr=
><td>Adobe After Effects 6 (Apple Macintosh)</td><td>$69=2e95</td></tr><t=
r><td>Adobe Illustrator CS CE (Apple Macintosh)</td><td>$69=2e95</td></tr=
><tr><td>Adobe Photoshop CS (Apple Macintosh)</td><td>$99=2e95</td></tr><=
tr><td>Adobe Premiere 6=2e5 (Apple Macintosh)</td><td>$89=2e95</td></tr><=
tr><td>Adobe InDesign CS (Apple Macintosh)</td><td>$69=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for PC:</td></tr>
=

<tr><td> Dreamwaver MX 2004</td><td>$69=2e95</tr></td><tr><td> Flash MX 2=
004</td><td>$69=2e95</tr></td><tr><td> Freehand MX 11</td><td>$69=2e95</t=
r></td><tr><td> Fireworks MX 2004</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for Mac:</td></tr>=

<tr><td>Macromedia Dreamweaver MX 2004 (Mac)</td><td>$69=2e95</td></tr><t=
r><td>Macromedia Flash MX 2004 (Mac)</td><td>$69=2e95</td></tr><tr><td>Ma=
cromedia Studio MX 2004 with Director MX 2004 (Mac)</td><td>$139=2e95</td=
></tr><tr><td>Macromedia FreeHand MX (Mac)</td><td>$69=2e95</td></tr><tr>=
<td>Macromedia Director MX 2004 (Mac)</td><td>$69=2e95</td></tr><tr><td>M=
acromedia Fireworks MX 2004 (Mac)</td><td>$69=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Corel Software:</td></tr>
<tr><td> Photo Painter 8</td><td>$59=2e95</td></tr><tr><td> WordPerfect O=
ffice </td><td>$69=2e95</td></tr><tr><td> Draw Graphics Suite 11=2e0</td>=
<td>$59=2e95</td></tr>
<tr><td>&nbsp;</td></tr>

</table>
<table align=3dcenter>
<tr><td align=3dcenter>
<a href=3d"http://hxrwrxx=2epvvkcpvgv3ugypp38spku777=2ebohireendc=2ecom">=
<h3><font size=3d3 color=3d#212346>Try to click</font></h3></a>

</td></tr>
</table>
</body>
</html>

------=_NextPart_000_0025_42B71511.11EA68CB--

From: "Deftness B. Trackers" <[email-masked]>
To: Idr <[email-masked]>
Subject: Three steps to the software you need for the price you want.
Date: Tue, 25 Oct 2005 17:26:53 -0700
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0036_5F958EDB.D522D977
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

 http://ziqmuj.7vdku7vgdluggppk8spkcppp.crossedfa.com

If you are interested in brands like Microsoft, Macromedia, Adobe, Corel etc.

 Please check our reduced price. 

 Windows 95 - $40 
 MS Office 2000 Premium Edition (2 CD Edition) - $59.95 
 MS SQL Server 2000 Enterprise Edition - $60 
 Corel Word Perfect Office 2002 - $60 
 Windows 2000 Advanced Server - $60 
 Win 2000 Advanced Server - $69.95 
 Microsoft Office 2003 Pro (1 CD Edition) - $89.95 
 GoLive CS - $60 
 Quark Xpress 6 Passport Multilanguage - $60 
 Office 2003 Professional (1 CD Edition) - $80 
 MS Picture It Premium 9 - $50 
 MS Visio 2003 Professional - $69.95 
 Win XP Pro With SP2 Full Version - $79.95 
 Windows NT 4.0 Terminal Server - $40 
 MS Plus! XP - $50 

 Come to site
 http://slgnlx.e22rjw25kajnnwwrfhe91eee.cozailm.com

------=_NextPart_000_0036_5F958EDB.D522D977
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html>
<body>

<table align=3dcenter>
<tr><td align=3dcenter>
<strong align=3dcenter><a href=3d"http://slgnlx=2ee22rjw25kajnnwwrfhe91ee=
e=2ecozailm=2ecom">
<font size=3d4 color=3d#1213a7>
Software at incredibly low price!
</a></strong>
</td></tr>
<tr><td align=3dcenter><font size=3d4>Check up our reduced price=2e</td><=
/tr>
</table>
<table align=3dcenter border=3d0>
<tr><td align=3dcenter colspan=3d2>Special Offers:</td></tr>
<tr><td>Bundle Special:Dreamwaver MX 2004 + Flash MX 2004</td><td>$109=2e=
95</td></tr><tr><td>Bundle Special:Photoshop  + Premiere  + Illustrator <=
/td><td>$129=2e95</td></tr><tr><td>Bundle Special:MS Windows XP Professio=
nal + MS Office XP Professional</td><td>$89=2e95</td></tr><tr><td>Bundle =
Special:Windows XP Professional With SP2 Full Version + Office 2003 Profe=
ssional (1 CD)</td><td>$99=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft Windows|R| </td></tr>
<tr><td>Windows 98 Second Edition </td><td>$49=2e95</td></tr><tr><td>Wind=
ows 95</td><td>$49=2e95</td></tr><tr><td>Windows NT 4=2e0 Server </td><td=
>$49=2e95</td></tr><tr><td>Windows XP Pro With SP2 Full Version</td><td>$=
79=2e95</td></tr><tr><td>Windows 2k Advanced Server </td><td>$69=2e95</td=
></tr><tr><td>Windows XP Pro</td><td>$69=2e95</td></tr><tr><td>Windows 2k=
 Pro</td><td>$59=2e95</td></tr><tr><td>Windows Millenium </td><td>$59=2e9=
5</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|c| Office:</td></tr>
<tr><td>Office 2000 Premium Edition (2 CD)</td><td>$59=2e95</td></tr><tr>=
<td>Office 97 SR2</td><td>$49=2e95</td></tr><tr><td>FileMaker 7=2e0 Pro</=
td><td>$69=2e95</td></tr><tr><td>Office 2003 Pro (1 CD)</td><td>$89=2e95<=
/td></tr><tr><td>Office XP Pro</td><td>$79=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Other Microsoft|R| Software:</td></tr>=

<tr><td>Microsoft Exchange 2003 Enterprise Server</td><td>$69=2e95</tr></=
td><tr><td>Microsoft Streets and Trips 2004 North America (2 CD)</td><td>=
$69=2e95</tr></td><tr><td>Microsoft Works 7</td><td>$69=2e95</tr></td><tr=
><td>Microsoft Visual Studio =2eNET Architect Edition (8CD)</td><td>$139=2e=
95</tr></td><tr><td>Microsoft Money 2004</td><td>$69=2e95</tr></td><tr><t=
d>Microsoft Picture It Premium 9</td><td>$59=2e95</tr></td><tr><td>Micros=
oft SQL Server 2000 Enterprise Edition</td><td>$69=2e95</tr></td><tr><td>=
Microsoft Encarta Encyclopedia Delux 2004 (3 CD)</td><td>$89=2e95</tr></t=
d><tr><td>Microsoft Plus! XP</td><td>$59=2e95</tr></td><tr><td>Microsoft =
Project 2003 Pro</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for PC:</td></tr>
<tr><td>Adobe PageMaker 7 (2 CD Edition) </td><td>$69=2e95</td></tr><tr><=
td>Adobe Photoshop CS with ImageReady CS </td><td>$99=2e95</td></tr><tr><=
td>Adobe Acrobat 6 Professional </td><td>$79=2e95</td></tr><tr><td>Adobe =
InDesign CS PageMaker Edition (2 CD Edition) </td><td>$69=2e95</td></tr><=
tr><td>Adobe Premiere 7 </td><td>$69=2e95</td></tr><tr><td>Adobe Illustra=
tor 10 </td><td>$69=2e95</td></tr><tr><td>Adobe Creative Suite Premium (5=
 CD) </td><td>$149=2e95</td></tr><tr><td>Adobe Photoshop Elements 3=2e0 W=
in </td><td>$59=2e95</td></tr><tr><td>Adobe Photoshop 7 </td><td>$69=2e95=
</td></tr><tr><td>Adobe Creative Suite Standard (3 CD) </td><td>$129=2e95=
</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for Mac:</td></tr>
<tr><td> After Effects 6 (Mac)</td><td>$69=2e95</td></tr><tr><td> LiveMot=
ion 2=2e0 (Mac)</td><td>$69=2e95</td></tr><tr><td> Actobat 6 Pro (Mac)</t=
d><td>$79=2e95</td></tr><tr><td> InDesign CS (Mac)</td><td>$69=2e95</td><=
/tr><tr><td> Photoshop CS (Mac)</td><td>$99=2e95</td></tr><tr><td> Premie=
re 6=2e5 (Mac)</td><td>$89=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for PC:</td></tr>
=

<tr><td>Macromedia Freehand MX 11</td><td>$69=2e95</tr></td><tr><td>Macro=
media Fireworks MX 2004</td><td>$69=2e95</tr></td><tr><td>Macromedia Flas=
h MX 2004</td><td>$69=2e95</tr></td><tr><td>Macromedia Dreamwaver MX 2004=
</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for Mac:</td></tr>=

<tr><td> Director MX 2004 (Apple Macintosh)</td><td>$69=2e95</td></tr><tr=
><td> Studio MX 2004 with Director MX 2004 (Apple Macintosh)</td><td>$139=
=2e95</td></tr><tr><td> FreeHand MX (Apple Macintosh)</td><td>$69=2e95</t=
d></tr><tr><td> Dreamweaver MX 2004 (Apple Macintosh)</td><td>$69=2e95</t=
d></tr><tr><td> Flash MX 2004 (Apple Macintosh)</td><td>$69=2e95</td></tr=
><tr><td> Fireworks MX 2004 (Apple Macintosh)</td><td>$69=2e95</td></tr>
=

<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Corel Software:</td></tr>
<tr><td> Photo Painter 8=2e0</td><td>$59=2e95</td></tr><tr><td> Draw Grap=
hics Suite 11</td><td>$59=2e95</td></tr><tr><td> Draw Graphics Suite 11 (=
Mac)</td><td>$59=2e95</td></tr><tr><td> WordPerfect Office </td><td>$69=2e=
95</td></tr><tr><td> Photo Painter 8=2e0 (Mac)</td><td>$59=2e95</td></tr>=

<tr><td>&nbsp;</td></tr>

</table>
<table align=3dcenter>
<tr><td align=3dcenter>
<a href=3d"http://ziqmuj=2e7vdku7vgdluggppk8spkcppp=2ecrossedfa=2ecom"><h=
3><font size=3d3 color=3d#212346>Come to site</font></h3></a>

</td></tr>
</table>
</body>
</html>

------=_NextPart_000_0036_5F958EDB.D522D977--

From: "Territory E. Outflanked" <[email-masked]>
To: Idr <[email-masked]>
Subject: Please visit our OEM software supertore!
Date: Mon, 24 Oct 2005 19:53:01 -0700
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0000_18C0FC4F.94E3D905
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

 http://vjlz.9xx4e9xixnw00r94ac9mw999.answerik.com

Looking for cheap licensed software ? Buy OEM and dont think more!

 Please check our prices. 

 MS Office 2003 Pro (1 CD) - $89.95 
 MS Office 2k Premium Edition (2 CD Edition) - $59.95 
 Windows 2000 Professional - $59.95 
 Microsoft Visio 2003 Pro - $69.95 
 MS Office 2003 Pro (1 CD) - $89.95 
 Win 2000 Advanced Server - $69.95 
 Microsoft Office 97 SR2 - $49.95 
 Microsoft Office 2003 Professional (1 CD) - $89.95 
 Microsoft Visio 2003 Pro - $69.95 
 MS FileMaker 7.0 Professional - $69.95 
 Illustrator 10 - $60 
 Windows 95 - $40 
 MS Office 2000 PE (2 CD Edition) - $59.95 
 Windows 98 Second Edition - $49.95 
 Office XP Professional - $70 

 Press link
 http://vjlz.9xx4e9xixnw00r94ac9mw999.answerik.com

------=_NextPart_000_0000_18C0FC4F.94E3D905
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html>
<body>

<table align=3dcenter>
<tr><td align=3dcenter>
<strong align=3dcenter><a href=3d"http://anrcjgo=2erff4erf0x5w0ir94sc9mwr=
rr=2evaporishaj=2ecom">
<font size=3d4 color=3d#1213a7>
Macromedia Software and more=2e The best price=2e
</a></strong>
</td></tr>
<tr><td align=3dcenter><font size=3d4>Check out our reduced price=2e</td>=
</tr>
</table>
<table align=3dcenter border=3d0>
<tr><td align=3dcenter colspan=3d2>Special Offers:</td></tr>
<tr><td>Bundle Special:MS Win XP Professional + MS Office XP Professional=
</td><td>$89=2e95</td></tr><tr><td>Bundle Special:Win XP Professional Wit=
h SP2 Full Version + Office 2003 Professional (1 CD Edition)</td><td>$99=2e=
95</td></tr><tr><td>Bundle Special:Photoshop  + Premiere  + Illustrator <=
/td><td>$129=2e95</td></tr><tr><td>Bundle Special:Dreamwaver MX 2004 + Fl=
ash MX 2004</td><td>$109=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|R| Windows </td></tr>
<tr><td>Win NT 4=2e0 Terminal Server</td><td>$49=2e95</td></tr><tr><td>Wi=
n NT 4=2e0 Server </td><td>$49=2e95</td></tr><tr><td>Win 95</td><td>$49=2e=
95</td></tr><tr><td>Win 2000 Professional</td><td>$59=2e95</td></tr><tr><=
td>Win 2000 Advanced Server </td><td>$69=2e95</td></tr><tr><td>Win 98 Sec=
ond Edition </td><td>$49=2e95</td></tr><tr><td>Win XP Professional</td><t=
d>$69=2e95</td></tr><tr><td>Win Millenium </td><td>$59=2e95</td></tr><tr>=
<td>Win 98</td><td>$49=2e95</td></tr><tr><td>Win XP Professional With SP2=
 Full Version</td><td>$79=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft Office|R|:</td></tr>
<tr><td>Microsoft Visio 2003 Professional</td><td>$69=2e95</td></tr><tr><=
td>Office 2003 Professional (1 CD)</td><td>$89=2e95</td></tr><tr><td>Offi=
ce XP Professional</td><td>$79=2e95</td></tr><tr><td>FileMaker 7=2e0 Prof=
essional</td><td>$69=2e95</td></tr><tr><td>Office 2k Premium Edition (2 C=
D Edition)</td><td>$59=2e95</td></tr><tr><td>Office 97 SR2</td><td>$49=2e=
95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Other Microsoft|R| Software:</td></tr>=

<tr><td>MS Money 2004</td><td>$69=2e95</tr></td><tr><td>MS Streets and Tr=
ips 2004 North America (2 CD)</td><td>$69=2e95</tr></td><tr><td>MS SQL Se=
rver 2000 Enterprise Edition</td><td>$69=2e95</tr></td><tr><td>MS Exchang=
e 2003 Enterprise Server</td><td>$69=2e95</tr></td><tr><td>MS Visual Stud=
io =2eNET Architect Edition (8CD)</td><td>$139=2e95</tr></td><tr><td>MS E=
ncarta Encyclopedia Delux 2004 (3 CD)</td><td>$89=2e95</tr></td><tr><td>M=
S Works 7</td><td>$69=2e95</tr></td><tr><td>MS Plus! XP</td><td>$59=2e95<=
/tr></td><tr><td>MS Picture It Premium 9</td><td>$59=2e95</tr></td><tr><t=
d>MS Project 2003 Pro</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for PC:</td></tr>
<tr><td> Premiere 7 </td><td>$69=2e95</td></tr><tr><td> Photoshop 7 </td>=
<td>$69=2e95</td></tr><tr><td> PageMaker 7 (2 CD Edition) </td><td>$69=2e=
95</td></tr><tr><td> Photoshop CS with ImageReady CS </td><td>$99=2e95</t=
d></tr><tr><td> Creative Suite Standard (3 CD Edition) </td><td>$129=2e95=
</td></tr><tr><td> Creative Suite Premium (5 CD) </td><td>$149=2e95</td><=
/tr><tr><td> InDesign CS PageMaker Edition (2 CD Edition) </td><td>$69=2e=
95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for Mac:</td></tr>
<tr><td>Adobe Premiere 6=2e5 (Apple Macintosh)</td><td>$89=2e95</td></tr>=
<tr><td>Adobe After Effects 6=2e0 (Apple Macintosh)</td><td>$69=2e95</td>=
</tr><tr><td>Adobe Actobat 6=2e0 Professional (Apple Macintosh)</td><td>$=
79=2e95</td></tr><tr><td>Adobe LiveMotion 2 (Apple Macintosh)</td><td>$69=
=2e95</td></tr><tr><td>Adobe InDesign CS (Apple Macintosh)</td><td>$69=2e=
95</td></tr><tr><td>Adobe Photoshop CS (Apple Macintosh)</td><td>$99=2e95=
</td></tr><tr><td>Adobe Illustrator CS CE (Apple Macintosh)</td><td>$69=2e=
95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for PC:</td></tr>
=

<tr><td>Macromedia Freehand MX 11</td><td>$69=2e95</tr></td><tr><td>Macro=
media Dreamwaver MX 2004</td><td>$69=2e95</tr></td><tr><td>Macromedia Fla=
sh MX 2004</td><td>$69=2e95</tr></td><tr><td>Macromedia Fireworks MX 2004=
</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for Mac:</td></tr>=

<tr><td> FreeHand MX (Mac)</td><td>$69=2e95</td></tr><tr><td> Fireworks M=
X 2004 (Mac)</td><td>$69=2e95</td></tr><tr><td> Director MX 2004 (Mac)</t=
d><td>$69=2e95</td></tr><tr><td> Studio MX 2004 with Director MX 2004 (Ma=
c)</td><td>$139=2e95</td></tr><tr><td> Dreamweaver MX 2004 (Mac)</td><td>=
$69=2e95</td></tr><tr><td> Flash MX 2004 (Mac)</td><td>$69=2e95</td></tr>=

<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Corel Software:</td></tr>
<tr><td>Corel Photo Painter 8</td><td>$59=2e95</td></tr><tr><td>Corel Pho=
to Painter 8 (Apple Macintosh)</td><td>$59=2e95</td></tr><tr><td>Corel Dr=
aw Graphics Suite 11=2e0</td><td>$59=2e95</td></tr><tr><td>Corel WordPerf=
ect Office </td><td>$69=2e95</td></tr><tr><td>Corel Draw Graphics Suite 1=
1=2e0 (Apple Macintosh)</td><td>$59=2e95</td></tr>
<tr><td>&nbsp;</td></tr>

</table>
<table align=3dcenter>
<tr><td align=3dcenter>
<a href=3d"http://vjlz=2e9xx4e9xixnw00r94ac9mw999=2eanswerik=2ecom"><h3><=
font size=3d3 color=3d#212346>Try to look</font></h3></a>

</td></tr>
</table>
</body>
</html>

------=_NextPart_000_0000_18C0FC4F.94E3D905--

Date: Mon, 24 Oct 2005 15:57:47 -0700
From: Robert Raszuk <[email-masked]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked]
Subject: Re: [Idr] AS hopcount draft as an IDR WG document
Cc: Yakov Rekhter <[email-masked]>, Tony Li <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Hi Curtis,

I agree with you and support this to become an IDR WG doc.

Even if ever AS_HOPCOUNT is used to limit specific propagation of just 1 
hop away it already will be very useful.

And and far as additional incentive goes .. proper network design should 
be enough of incentive :). Maybe that goes against $$$$ rule but IMHO it 
goes along the real large scale network design principle (if that even 
still matters these days :-).

Cheers,
R.

> In message <[email-masked]>
> Yakov Rekhter writes:
> 
>> 
>>Folks,
>> 
>>We received a request (see below) to accept
>>draft-li-as-hopcount-03.txt as an IDR WG document.
>> 
>>Comments are greatly appreciated. The deadline for comments is
>>November 6, 2005 (not 10/31, as mentioned below).
>> 
>>Yakov.
> 
> 
> 
> This draft provides a useful mechanism for limiting the scope of
> routing information that is needed only for localized traffic
> engineering (where localized can span continents and indeed does in a
> well known example of intended usage).  The use of AS_HOPCOUNT and
> NO_EXPORT together as described in the draft provides a transition
> mechanism that will prevent any significant harm to the network as a
> result of partial deployment of this feature.
> 
> I agree with the proposal that draft-li-as-hopcount-03.txt should
> become a WG document.
> 
> Curtis
> 
> 
> ------- Forwarded Message
> 
> Date:    Sun, 23 Oct 2005 16:46:27 -0700
> From:    Tony Li <[email-masked]>
> To:      [email-masked]
> Subject: [Idr] AS hopcount draft
> 
> 
> 
> All,
> 
> After our Paris discussion, the AS hopcount draft has been modified  
> as discussed to include a 4 byte AS number as part of the attribute  
> to aid in debugging.  I would like to propose that this become a WG  
> document at this point.  If folks have objections to this or  
> comments, could you please voice them by Monday, 10/31 (boo!).
> 
> The current draft can be found here:
> http://www.ietf.org/internet-drafts/draft-li-as-hopcount-03.txt
> 
> Thanks,
> Joe, Rex & Tony
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 24 Oct 2005 17:32:21 -0500
From: David Ward <[email-masked]>
To: <[email-masked]>, David Ward <[email-masked]>
Cc: 
Subject: [Idr] A couple of drafts we will present
Sender: [email-masked]

All  -
    I apologize that I couldn't get the formatting of xml2rfc correct in
time but, here is the location of a couple of drafts that will be presented
at IETF 64 in Vancouver.

http://bgp.nu/~dward/idr-drafts.2005.11/

http://bgp.nu/~dward/idr-drafts.2005.11/draft-djernaes-simple-context-update
-00.txt

http://bgp.nu/~dward/idr-drafts.2005.11/draft-raszuk-aggr-withdraw-00.txt

Thanks

-DWard

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Content-class: urn:content-classes:message
Date: Mon, 24 Oct 2005 11:50:26 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>
Subject: [Idr] BGP MIBs and Management
Sender: [email-masked]

hi

Is there interest in getting together to discuss the IDR WG's MIB and
Management Deliverables in Vancouver?

For those who won't know me, I'm assigned as the MIB doctor for this
working group. This hasn't required a lot of my cycles lately, since it
seems that work isn't progressing very quickly. I don't know if this is
because there isn't a real need for supporting IPv6 and various BGP
extensions in the MIBs, or if people are planning on doing all the
management work at the end (magic management dust?).

It would be good to get together quickly and review where we are and
what we are trying to do.

Please let me know if there is any interest. 

Thanks,

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Pekka Savola <[email-masked]>
Subject: Re: [Idr] AS hopcount draft as an IDR WG document 
Date: Mon, 24 Oct 2005 11:52:04 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Pekka Savola writes:
>  
> On Mon, 24 Oct 2005, Elmar K. Bins wrote:
> > I like this proposal very much, because it enables conscious
> > operators to somewhat "confine" their more specific advertisements
> > (or, their advertisements at all) to a certain radius.
>  
> note: I only took a quick look at the document.
>  
> Is this approach really useful?  That is,
>  
>   a) an "AS" is a coarse concept.  A single router, or a single AS 
> could span across the globe.  Thus, "AS hop count" in itself doesn't 
> buy you much.
>  
>   b) given a), this attribute would likely only be used with small hop 
> counts, say 1-3, because if the operator doesn't investigate the 
> AS-level topology in detail, (s)he cannot know which count (s)he would 
> want to use to obtain the intended policy.  I'm assuming investigation 
> of AS-based topology beyond a couple of AS hops would be infeasible.
>  
>   c) as reducing the hop count per traversed AS requires support for 
> this attribute, until this is deployed everywhere, the usage is even 
> more challenging. That is, it's not enough to figure out the AS-level 
> topology, you also need to figure out (and monitor) whether they 
> support AS hopcount, and how to take it into the account in setting 
> the AS level hopcount.
>  
> So, I'm a bit of skeptic whether this kind of tool is useful enough 
> for the intended purpose (i.e., would it become used).  As it happens, 
> you can already use NO_EXPORT for hop 1, and in most cases 
> provider-specific communities for hop 2.  I'm not sure if it's clear 
> enough that a more generic solution is necessary.
>  
> btw. is a confederation peer considered 'an external peer' ?
>  
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Pekka,

I think the motivation for this would be the problem that the POISSON
WG set out to address but never found a solution for.

The specific example that was used in POISSON was Australian providers
using a large number of more specific routes advertised to multiple
global providers in order to balance the load from the US west coast
across these providers.  Much of that traffic was from other providers
within the US or from Europe where the more specific routes were not
needed.

Limiting the scope of these more specific prefixes reduced global
routing while still allowing providers to do this sort of load
balancing.  Since we know that this is being done, deployment, even
partial deployment would reduce the amount of unnessecary global
routing information.  Therefore, yes it is useful.

Please feel free to correct me if I got this wrong since I'm not part
of any team that put this together or discussed this in Paris.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] AS hopcount draft as an IDR WG document 
Date: Mon, 24 Oct 2005 11:17:14 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], Tony Li <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Yakov Rekhter writes:
>  
> Folks,
>  
> We received a request (see below) to accept
> draft-li-as-hopcount-03.txt as an IDR WG document.
>  
> Comments are greatly appreciated. The deadline for comments is
> November 6, 2005 (not 10/31, as mentioned below).
>  
> Yakov.

This draft provides a useful mechanism for limiting the scope of
routing information that is needed only for localized traffic
engineering (where localized can span continents and indeed does in a
well known example of intended usage).  The use of AS_HOPCOUNT and
NO_EXPORT together as described in the draft provides a transition
mechanism that will prevent any significant harm to the network as a
result of partial deployment of this feature.

I agree with the proposal that draft-li-as-hopcount-03.txt should
become a WG document.

Curtis

------- Forwarded Message

Date:    Sun, 23 Oct 2005 16:46:27 -0700
From:    Tony Li <[email-masked]>
To:      [email-masked]
Subject: [Idr] AS hopcount draft

All,

After our Paris discussion, the AS hopcount draft has been modified  
as discussed to include a 4 byte AS number as part of the attribute  
to aid in debugging.  I would like to propose that this become a WG  
document at this point.  If folks have objections to this or  
comments, could you please voice them by Monday, 10/31 (boo!).

The current draft can be found here:
http://www.ietf.org/internet-drafts/draft-li-as-hopcount-03.txt

Thanks,
Joe, Rex & Tony

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 24 Oct 2005 14:09:56 +0200
From: "Elmar K. Bins" <[email-masked]>
To: Pekka Savola <[email-masked]>
Subject: Re: [Idr] AS hopcount draft as an IDR WG document
Organization: unorganized since 1789
Cc: [email-masked]
Sender: [email-masked]

Pekka :)

[email-masked] (Pekka Savola) wrote:

> note: I only took a quick look at the document.

You should, it would answer your question c)

>  a) an "AS" is a coarse concept.  A single router, or a single AS 
> could span across the globe.  Thus, "AS hop count" in itself doesn't 
> buy you much.

You'll have to decide whether it's useful for your AS.

>  b) given a), this attribute would likely only be used with small hop 
> counts, say 1-3, because if the operator doesn't investigate the 
> AS-level topology in detail, (s)he cannot know which count (s)he would 
> want to use to obtain the intended policy.  I'm assuming investigation 
> of AS-based topology beyond a couple of AS hops would be infeasible.

One could start experimenting, though :)

> So, I'm a bit of skeptic whether this kind of tool is useful enough 
> for the intended purpose (i.e., would it become used).  As it happens, 
> you can already use NO_EXPORT for hop 1, and in most cases 
> provider-specific communities for hop 2.  I'm not sure if it's clear 
> enough that a more generic solution is necessary.

If it would be used at all, and large-scale, we could get quite a lot
of rubbish out of the DFZ, buying a couple more years.

Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
                          (PLemken, <[email-masked]>)

--------------------------------------------------------------[ ELMI-RIPE ]---

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 24 Oct 2005 14:59:55 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] AS hopcount draft as an IDR WG document
Sender: [email-masked]

On Mon, 24 Oct 2005, Elmar K. Bins wrote:
> I like this proposal very much, because it enables conscious
> operators to somewhat "confine" their more specific advertisements
> (or, their advertisements at all) to a certain radius.

note: I only took a quick look at the document.

Is this approach really useful?  That is,

  a) an "AS" is a coarse concept.  A single router, or a single AS 
could span across the globe.  Thus, "AS hop count" in itself doesn't 
buy you much.

  b) given a), this attribute would likely only be used with small hop 
counts, say 1-3, because if the operator doesn't investigate the 
AS-level topology in detail, (s)he cannot know which count (s)he would 
want to use to obtain the intended policy.  I'm assuming investigation 
of AS-based topology beyond a couple of AS hops would be infeasible.

  c) as reducing the hop count per traversed AS requires support for 
this attribute, until this is deployed everywhere, the usage is even 
more challenging. That is, it's not enough to figure out the AS-level 
topology, you also need to figure out (and monitor) whether they 
support AS hopcount, and how to take it into the account in setting 
the AS level hopcount.

So, I'm a bit of skeptic whether this kind of tool is useful enough 
for the intended purpose (i.e., would it become used).  As it happens, 
you can already use NO_EXPORT for hop 1, and in most cases 
provider-specific communities for hop 2.  I'm not sure if it's clear 
enough that a more generic solution is necessary.

btw. is a confederation peer considered 'an external peer' ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 24 Oct 2005 09:39:25 +0200
From: "Elmar K. Bins" <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] AS hopcount draft as an IDR WG document
Organization: unorganized since 1789
Cc: [email-masked]
Sender: [email-masked]

[email-masked] (Yakov Rekhter) wrote:

> We received a request (see below) to accept draft-li-as-hopcount-03.txt
> as an IDR WG document.
> 
> Comments are greatly appreciated. The deadline for comments is
> November 6, 2005 (not 10/31, as mentioned below).

I - as a newbie to this list - would like to comment in a somewhat
private way on this; I'd anyhow like to share my thoughts and I
hope I'm not too far off-topic.

I like this proposal very much, because it enables conscious
operators to somewhat "confine" their more specific advertisements
(or, their advertisements at all) to a certain radius.

I personally would like this level of control over the prefixes
I use for anycasting. Controlling load-sharing over anycast
locations is a pretty hard job, and the control is not really
better than marginal.

I also see an application in more-specific multi-homing. We'll
be needing this in the next year, splitting our PA block in the
process (not wanting to waste address resources on top of using
up additional slots in the BGP tables). And since we're such
good netizens, we'd like to be able to confine the more specifics'
propagation to some radius that covers all locations involved. The
aggregate will provide for fallback connectivity.

Unfortunately, I strongly believe that not everybody that could
use the AS hopcount feature will actually use it without being
given additional incentive. As per the proposal, setting the NLRI
is entirely voluntary. It also involves (a) an understanding of
how DFZ routing works, (b) an idea of how far into the DFZ their
advertisements need to be seen, and (c) the will to confine the
advertisements.

Would you consider using AS hopcount as a way to lighten DFZ tables
from more-specific multi-homing garbage an abuse of the scheme?

If not, does anybody have an idea of how to get people to confine
their more specific prefixes, some way of incentive? I'm not sure
if this can be done in the draft itself. This may need to be
addresses separately, but could be mentioned alongside the draft.

Thanks for listening,
			Elmar.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Sun, 23 Oct 2005 19:38:50 -0700
From: Yakov Rekhter <[email-masked]>
Cc: Tony Li <[email-masked]>
Subject: [Idr] AS hopcount draft as an IDR WG document
Sender: [email-masked]

Folks,

We received a request (see below) to accept draft-li-as-hopcount-03.txt
as an IDR WG document.

Comments are greatly appreciated. The deadline for comments is
November 6, 2005 (not 10/31, as mentioned below).

Yakov.
------- Forwarded Message

Date:    Sun, 23 Oct 2005 16:46:27 -0700
From:    Tony Li <[email-masked]>
To:      [email-masked]
Subject: [Idr] AS hopcount draft

All,

After our Paris discussion, the AS hopcount draft has been modified  
as discussed to include a 4 byte AS number as part of the attribute  
to aid in debugging.  I would like to propose that this become a WG  
document at this point.  If folks have objections to this or  
comments, could you please voice them by Monday, 10/31 (boo!).

The current draft can be found here:
http://www.ietf.org/internet-drafts/draft-li-as-hopcount-03.txt

Thanks,
Joe, Rex & Tony

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: Tony Li <[email-masked]>
Date: Sun, 23 Oct 2005 16:46:27 -0700
Subject: [Idr] AS hopcount draft
Sender: [email-masked]

All,

After our Paris discussion, the AS hopcount draft has been modified  
as discussed to include a 4 byte AS number as part of the attribute  
to aid in debugging.  I would like to propose that this become a WG  
document at this point.  If folks have objections to this or  
comments, could you please voice them by Monday, 10/31 (boo!).

The current draft can be found here:
http://www.ietf.org/internet-drafts/draft-li-as-hopcount-03.txt

Thanks,
Joe, Rex & Tony

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Counterattacking H. Goriest" <[email-masked]>
To: Idr <[email-masked]>
Subject: If you are interested in brands like Microsoft, Macromedia, Adobe, Corel etc.
Date: Sat, 22 Oct 2005 18:08:27 -0700
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0001_E14B1C31.5FBCDBD3
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

 http://tbo.359x879c8dquu33ymolg83l3.alocasiaie.info

Corel Software and more. The best price.

 Examine our prices. 

 Windows XP Pro - $69.95 
 Windows 95 - $40 
 After Effects 6.0 - $60 
 Borland Delphi 7 Enterprise Edition (2CD) - $60 
 Extensis Portfolio 7.0 - $50 
 Quark Xpress 6 Passport Multilanguage - $60 
 Windows 2000 Pro - $59.95 
 Acrobat 6.0 Pro - $70 
 PhotoRetouch Pro 3.0 - $50 
 Win 2000 Adv. Server - $69.95 
 Flash MX 2004 - $60 
 FreeHand MX - $60 
 Win 95 - $49.95 
 MS Visio 2003 Pro - $69.95 
 Windows 98 - $40 

 Link bellow
 http://rqxmbu.scgmfwgjx2x1jssntda5fsaa.syodiconkf.com

------=_NextPart_000_0001_E14B1C31.5FBCDBD3
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html>
<body>

<table align=3dcenter>
<tr><td align=3dcenter>
<strong align=3dcenter><a href=3d"http://ogzzdq=2ek4qepoqtpupbt22fln2f7k2=
k=2egloriadj=2ecom">
<font size=3d4 color=3d#1213a7>
YAHOO software news
</a></strong>
</td></tr>
<tr><td align=3dcenter><font size=3d4>Check out our reduced price=2e</td>=
</tr>
</table>
<table align=3dcenter border=3d0>
<tr><td align=3dcenter colspan=3d2>Special Offers:</td></tr>
<tr><td>Special Offer:MS Win XP Pro + MS Office XP Pro</td><td>$89=2e95</=
td></tr><tr><td>Bundle Special:Photoshop  + Premiere  + Illustrator </td>=
<td>$129=2e95</td></tr><tr><td>Bundle Special:Win XP Pro With SP2 Full Ve=
rsion + Office 2003 Pro (1 CD)</td><td>$99=2e95</td></tr><tr><td>Bundle S=
pecial:Dreamwaver MX 2004 + Flash MX 2004</td><td>$109=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|c| Windows|R| </td></tr>
<tr><td>Windows Millenium </td><td>$59=2e95</td></tr><tr><td>Windows NT 4=
=2e0 Server </td><td>$49=2e95</td></tr><tr><td>Windows XP Professional Wi=
th SP2 Full Version</td><td>$79=2e95</td></tr><tr><td>Windows NT 4=2e0 Te=
rminal Server</td><td>$49=2e95</td></tr><tr><td>Windows 95</td><td>$49=2e=
95</td></tr><tr><td>Windows XP Professional</td><td>$69=2e95</td></tr><tr=
><td>Windows 98 SE </td><td>$49=2e95</td></tr><tr><td>Windows 2000 Advanc=
ed Server </td><td>$69=2e95</td></tr><tr><td>Windows 2000 Professional</t=
d><td>$59=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|c| Office:</td></tr>
<tr><td>Office 97 SR2</td><td>$49=2e95</td></tr><tr><td>Office XP Profess=
ional</td><td>$79=2e95</td></tr><tr><td>Office 2k PE (2 CD)</td><td>$59=2e=
95</td></tr><tr><td>Office 2003 Professional (1 CD Edition)</td><td>$89=2e=
95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Other Microsoft|R| Software:</td></tr>=

<tr><td>MS Plus! XP</td><td>$59=2e95</tr></td><tr><td>MS Picture It Premi=
um 9</td><td>$59=2e95</tr></td><tr><td>MS Project 2003 Pro</td><td>$69=2e=
95</tr></td><tr><td>MS Visual Studio =2eNET Architect Edition (8CD)</td><=
td>$139=2e95</tr></td><tr><td>MS Encarta Encyclopedia Delux 2004 (3 CD)</=
td><td>$89=2e95</tr></td><tr><td>MS SQL Server 2k Enterprise Edition</td>=
<td>$69=2e95</tr></td><tr><td>MS Exchange 2003 Enterprise Server</td><td>=
$69=2e95</tr></td><tr><td>MS Streets and Trips 2004 North America (2 CD E=
dition)</td><td>$69=2e95</tr></td><tr><td>MS Works 7</td><td>$69=2e95</tr=
></td><tr><td>MS Money 2004</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for PC:</td></tr>
<tr><td> Illustrator 10 </td><td>$69=2e95</td></tr><tr><td> InDesign CS P=
ageMaker Edition (2 CD) </td><td>$69=2e95</td></tr><tr><td> PageMaker 7 (=
2 CD) </td><td>$69=2e95</td></tr><tr><td> Photoshop CS with ImageReady CS=
 </td><td>$99=2e95</td></tr><tr><td> Creative Suite Premium (5 CD Edition=
) </td><td>$149=2e95</td></tr><tr><td> Photoshop 7 </td><td>$69=2e95</td>=
</tr><tr><td> Creative Suite Standard (3 CD) </td><td>$129=2e95</td></tr>=
<tr><td> Premiere 7 </td><td>$69=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for Mac:</td></tr>
<tr><td> Premiere 6=2e5 (Apple Macintosh)</td><td>$89=2e95</td></tr><tr><=
td> Photoshop CS (Apple Macintosh)</td><td>$99=2e95</td></tr><tr><td> InD=
esign CS (Apple Macintosh)</td><td>$69=2e95</td></tr><tr><td> Actobat 6 P=
rofessional (Apple Macintosh)</td><td>$79=2e95</td></tr><tr><td> After Ef=
fects 6 (Apple Macintosh)</td><td>$69=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for PC:</td></tr>
=

<tr><td> Freehand MX 11</td><td>$69=2e95</tr></td><tr><td> Fireworks MX 2=
004</td><td>$69=2e95</tr></td><tr><td> Dreamwaver MX 2004</td><td>$69=2e9=
5</tr></td><tr><td> Flash MX 2004</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for Mac:</td></tr>=

<tr><td>Macromedia Fireworks MX 2004 (Apple Macintosh)</td><td>$69=2e95</=
td></tr><tr><td>Macromedia Dreamweaver MX 2004 (Apple Macintosh)</td><td>=
$69=2e95</td></tr><tr><td>Macromedia Flash MX 2004 (Apple Macintosh)</td>=
<td>$69=2e95</td></tr><tr><td>Macromedia Director MX 2004 (Apple Macintos=
h)</td><td>$69=2e95</td></tr><tr><td>Macromedia Studio MX 2004 with Direc=
tor MX 2004 (Apple Macintosh)</td><td>$139=2e95</td></tr><tr><td>Macromed=
ia FreeHand MX (Apple Macintosh)</td><td>$69=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Corel Software:</td></tr>
<tr><td>Corel Draw Graphics Suite 11=2e0 (Mac)</td><td>$59=2e95</td></tr>=
<tr><td>Corel Photo Painter 8 (Mac)</td><td>$59=2e95</td></tr><tr><td>Cor=
el Draw Graphics Suite 11=2e0</td><td>$59=2e95</td></tr><tr><td>Corel Wor=
dPerfect Office </td><td>$69=2e95</td></tr><tr><td>Corel Photo Painter 8<=
/td><td>$59=2e95</td></tr>
<tr><td>&nbsp;</td></tr>

</table>
<table align=3dcenter>
<tr><td align=3dcenter>
<a href=3d"http://tbo=2e359x879c8dquu33ymolg83l3=2ealocasiaie=2einfo"><h3=
><font size=3d3 color=3d#212346>Check it</font></h3></a>

</td></tr>
</table>
</body>
</html>

------=_NextPart_000_0001_E14B1C31.5FBCDBD3--

From: "Ague C. Grumbles" <[email-masked]>
To: Idr <[email-masked]>
Subject: Looking for cheap licensed software ? Buy OEM and dont think more!
Date: Thu, 20 Oct 2005 07:40:02 -0700
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0035_E5056AD7.B8971067
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

 http://vvpi.1lpd657aobosaj1w241eoj1j.vicelessai.com

If you are interested in brands like Microsoft, Macromedia, Adobe, Corel etc.

 Examine our pricelist. 

 Windows 98 - $49.95 
 MS Office 2k PE (2 CD) - $59.95 
 Office XP Professional - $70 
 Win 95 - $49.95 
 Windows NT 4.0 Terminal Server - $49.95 
 Win 2k Professional - $59.95 
 Win 2k Advanced Server - $69.95 
 Flash MX 2004 - $60 
 Windows NT 4.0 Terminal Server - $40 
 Win 98 SE - $49.95 
 MS Office 2003 Pro (1 CD Edition) - $89.95 
 Windows 2000 Advanced Server - $69.95 
 Win 2k Adv. Server - $69.95 
 Windows 2000 Professional - $59.95 
 Windows 2k Adv. Server - $69.95 

 Follow link
 http://vvpi.1lpd657aobosaj1w241eoj1j.vicelessai.com

------=_NextPart_000_0035_E5056AD7.B8971067
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html>
<body>

<table align=3dcenter>
<tr><td align=3dcenter>
<strong align=3dcenter><a href=3d"http://amxtn=2eey2qjikn1o15nwerfzer1eww=
=2eempallhh=2ecom">
<font size=3d4 color=3d#1213a7>
The cheapest and the best OEM software here!
</a></strong>
</td></tr>
<tr><td align=3dcenter><font size=3d4>Check our prices=2e</td></tr>
</table>
<table align=3dcenter border=3d0>
<tr><td align=3dcenter colspan=3d2>Special Offers:</td></tr>
<tr><td>Bundle Special:Macromedia Dreamwaver MX 2004 + Macromedia Flash M=
X 2004</td><td>$109=2e95</td></tr><tr><td>Bundle Special:Microsoft Window=
s XP Pro + Microsoft Office XP Pro</td><td>$89=2e95</td></tr><tr><td>Bund=
le Special:Windows XP Pro With SP2 Full Version + Office 2003 Pro (1 CD)<=
/td><td>$99=2e95</td></tr><tr><td>Bundle Special:Photoshop  + Premiere  +=
 Illustrator </td><td>$129=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|R| Windows </td></tr>
<tr><td>Windows Millenium </td><td>$59=2e95</td></tr><tr><td>Windows 98 S=
econd Edition </td><td>$49=2e95</td></tr><tr><td>Windows 2000 Advanced Se=
rver </td><td>$69=2e95</td></tr><tr><td>Windows 2000 Pro</td><td>$59=2e95=
</td></tr><tr><td>Windows 98</td><td>$49=2e95</td></tr><tr><td>Windows XP=
 Pro</td><td>$69=2e95</td></tr><tr><td>Windows XP Pro With SP2 Full Versi=
on</td><td>$79=2e95</td></tr><tr><td>Windows NT 4=2e0 Server </td><td>$49=
=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Microsoft|R| Office|R|:</td></tr>
<tr><td>Office XP Pro</td><td>$79=2e95</td></tr><tr><td>FileMaker 7=2e0 P=
ro</td><td>$69=2e95</td></tr><tr><td>Office 2000 PE (2 CD Edition)</td><t=
d>$59=2e95</td></tr><tr><td>Office 2003 Pro (1 CD)</td><td>$89=2e95</td><=
/tr><tr><td>Office 97 SR2</td><td>$49=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Other Microsoft Software:</td></tr>
<tr><td>Microsoft Visual Studio =2eNET Architect Edition (8CD)</td><td>$1=
39=2e95</tr></td><tr><td>Microsoft Money 2004</td><td>$69=2e95</tr></td><=
tr><td>Microsoft Encarta Encyclopedia Delux 2004 (3 CD)</td><td>$89=2e95<=
/tr></td><tr><td>Microsoft Picture It Premium 9</td><td>$59=2e95</tr></td=
><tr><td>Microsoft Works 7</td><td>$69=2e95</tr></td><tr><td>Microsoft Pr=
oject 2003 Pro</td><td>$69=2e95</tr></td><tr><td>Microsoft SQL Server 2k =
Enterprise Edition</td><td>$69=2e95</tr></td><tr><td>Microsoft Exchange 2=
003 Enterprise Server</td><td>$69=2e95</tr></td><tr><td>Microsoft Streets=
 and Trips 2004 North America (2 CD)</td><td>$69=2e95</tr></td><tr><td>Mi=
crosoft Plus! XP</td><td>$59=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for PC:</td></tr>
<tr><td>Adobe Photoshop Elements 3=2e0 Win </td><td>$59=2e95</td></tr><tr=
><td>Adobe PageMaker 7 (2 CD) </td><td>$69=2e95</td></tr><tr><td>Adobe In=
Design CS PageMaker Edition (2 CD) </td><td>$69=2e95</td></tr><tr><td>Ado=
be Photoshop CS with ImageReady CS </td><td>$99=2e95</td></tr><tr><td>Ado=
be Creative Suite Standard (3 CD Edition) </td><td>$129=2e95</td></tr><tr=
><td>Adobe Photoshop 7 </td><td>$69=2e95</td></tr><tr><td>Adobe Creative =
Suite Premium (5 CD) </td><td>$149=2e95</td></tr><tr><td>Adobe Acrobat 6 =
Professional </td><td>$79=2e95</td></tr><tr><td>Adobe Premiere 7 </td><td=
>$69=2e95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Adobe Software for Mac:</td></tr>
<tr><td>Adobe After Effects 6=2e0 (Apple Macintosh)</td><td>$69=2e95</td>=
</tr><tr><td>Adobe Illustrator CS CE (Apple Macintosh)</td><td>$69=2e95</=
td></tr><tr><td>Adobe Actobat 6=2e0 Pro (Apple Macintosh)</td><td>$79=2e9=
5</td></tr><tr><td>Adobe InDesign CS (Apple Macintosh)</td><td>$69=2e95</=
td></tr><tr><td>Adobe Photoshop CS (Apple Macintosh)</td><td>$99=2e95</td=
></tr><tr><td>Adobe Premiere 6=2e5 (Apple Macintosh)</td><td>$89=2e95</td=
></tr><tr><td>Adobe LiveMotion 2=2e0 (Apple Macintosh)</td><td>$69=2e95</=
td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for PC:</td></tr>
=

<tr><td>Macromedia Freehand MX 11</td><td>$69=2e95</tr></td><tr><td>Macro=
media Fireworks MX 2004</td><td>$69=2e95</tr></td><tr><td>Macromedia Flas=
h MX 2004</td><td>$69=2e95</tr></td><tr><td>Macromedia Dreamwaver MX 2004=
</td><td>$69=2e95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Macromedia Software for Mac:</td></tr>=

<tr><td> Dreamweaver MX 2004 (Mac)</td><td>$69=2e95</td></tr><tr><td> Dir=
ector MX 2004 (Mac)</td><td>$69=2e95</td></tr><tr><td> Studio MX 2004 wit=
h Director MX 2004 (Mac)</td><td>$139=2e95</td></tr><tr><td> FreeHand MX =
(Mac)</td><td>$69=2e95</td></tr><tr><td> Fireworks MX 2004 (Mac)</td><td>=
$69=2e95</td></tr><tr><td> Flash MX 2004 (Mac)</td><td>$69=2e95</td></tr>=

<tr><td>&nbsp;</td></tr>
<tr><td align=3dcenter colspan=3d2>Corel Software:</td></tr>
<tr><td> WordPerfect Office </td><td>$69=2e95</td></tr><tr><td> Photo Pai=
nter 8=2e0 (Mac)</td><td>$59=2e95</td></tr><tr><td> Draw Graphics Suite 1=
1</td><td>$59=2e95</td></tr><tr><td> Photo Painter 8=2e0</td><td>$59=2e95=
</td></tr><tr><td> Draw Graphics Suite 11 (Mac)</td><td>$59=2e95</td></tr=
<tr><td>&nbsp;</td></tr>

</table>
<table align=3dcenter>
<tr><td align=3dcenter>
<a href=3d"http://amxtn=2eey2qjikn1o15nwerfzer1eww=2eempallhh=2ecom"><h3>=
<font size=3d3 color=3d#212346>Go to site</font></h3></a>

</td></tr>
</table>
</body>
</html>

------=_NextPart_000_0035_E5056AD7.B8971067--

To: [email-masked]
Subject: Re: [Idr] BGP-RIP interaction 
Date: Sat, 15 Oct 2005 14:26:15 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
[email-masked] writes:
>  
> Hi,
>  
> I work on routing protocols and have several questions about the
> interactions between BGP and RIP : Can we redistribute routes learned
> by BGP in RIP (like with OSPF)? And if so, can BGP attributes be
> "translated" in RIP metric ,or will all redistributed routes get the
> same RIP (default) metric? Thanks in advance for your help.
>  
> Best regards,
>  
> Laurence Duquerroy
>  
> RT/ST
> Research Department / Advanced Telecom Satellite Systems
> Tel : 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60
> E-Mail : [email-masked]
>  
> This message and any attachments (the "message") is intended solely for the
> addressees and is confidential. If you receive this message in error,
> please delete it and immediately notify the sender. Any use not in accord
> with its purpose, any dissemination or disclosure, either whole or partial,
> is prohibited except formal approval. The internet can not guarantee the
> integrity of this message. ALCATEL ALENIA SPACE (and its subsidiaries)
> shall (will) not therefore be liable for the message if modified.
>  
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> etablis a l'intention exclusive de ses destinataires et sont confidentiels.
> Si vous recevez ce message par erreur, merci de le detruire et d'en avertir
> immediatement l'expediteur. Toute utilisation de ce message non conforme a
> sa destination, toute diffusion ou toute publication, totale ou partielle,
> est interdite, sauf autorisation expresse. L'internet ne permettant pas
> d'assurer l'integrite de ce message, ALCATEL ALENIA SPACE (et ses filiales)
> decline(nt) toute responsabilite au titre de ce message, dans l'hypothese
> ou il aurait ete modifie.

Based on your notice we should not respond to your message and notify
you that it was receive in error.  

Unless I'm mistaken in the US due to a court ruling in the 1980s if a
confidentiality warning is routinely sent on non-confidential
correspondence the warning is considered invalid on everything it is
sent on.  I'm not a lawyer so if you are concerned about this check
with one (or refer your IT department to one since they are adding
this).

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Fri, 14 Oct 2005 09:23:13 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: [Idr] IDR WG agenda
Sender: [email-masked]

Folks,

Re-iterating a call for agenda items for Vancouver: please send us
(Sue and myself) the topic and how long a time slot you need. The
deadline is Oct 30.
 
And if you plan to make a presentation, please also keep in mind the 
rule "no document - no time slot".

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Fri, 14 Oct 2005 08:58:15 -0400
From: John Leslie <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Revised text on how to construct the AS path info
Cc: [email-masked]
Sender: [email-masked]

Enke Chen <[email-masked]> wrote:
> 
> What types of "inconsistencies" between AS_PATH and NEW_AS_PATH you are 
> concerned about, beyond the one described in the Transition Section 

   To tell truth, I'm not concerned about any particular case: I'm
concerned about the general case. I expect whatever algorithms we
specify to be still in use five years from now, in weird situations
we _cannot_ imagine.

> If your concern is about bogus AS path info somehow got propagated 
> around, that seems to be a general issue, independent of the 4byte AS.

   Indeed, I am largely concerned about things which are a general
problem now. My concern is that these problems will lead to different
behaviors and that the trail will be harder to follow.

   I believe there are simple consistency checks that could be run,
and that if the consistency checks (between 2-byte AS_PATH and 4-byte
NEW_AS_PATH) fail, we could either discard the NLRI or tag the 4-byte
AS_PATH we will pass on so that other BGP speakers can know the
inconsistency was found.

   (Paul and I, BTW, haven't reached agreement on which of these options
is better. My concern is to establish the general principle, not to
argue the details.)

--
John Leslie <[email-masked]>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: [email-masked]
To: [email-masked]
Date: Fri, 14 Oct 2005 09:28:17 +0200
Subject: [Idr] BGP-RIP interaction
Sender: [email-masked]

Hi,

I work on routing protocols and have several questions about the
interactions between BGP and RIP :
Can we redistribute routes learned by BGP in RIP (like with OSPF)? And if
so, can BGP attributes be "translated" in RIP metric ,or will all
redistributed routes get the same RIP  (default) metric? Thanks in advance
for your help.

Best regards,

Laurence Duquerroy

RT/ST
Research Department / Advanced Telecom Satellite Systems
Tel : 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60
E-Mail : [email-masked]

This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. ALCATEL ALENIA SPACE (and its subsidiaries)
shall (will) not therefore be liable for the message if modified.

Ce message et toutes les pieces jointes (ci-apres le "message") sont
etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce message non conforme a
sa destination, toute diffusion ou toute publication, totale ou partielle,
est interdite, sauf autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, ALCATEL ALENIA SPACE (et ses filiales)
decline(nt) toute responsabilite au titre de ce message, dans l'hypothese
ou il aurait ete modifie.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 13 Oct 2005 13:11:33 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Re: Revised text on how to construct the AS path info
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Wed, 12 Oct 2005, Enke Chen wrote:

> Hi, Paul:
>
> You seem to be talking about the same case described in the 
> Transition Sect. of the document::

No, I mean any case where one or more 4-byte paths are aggregated 
with one or more non-4-byte paths. The part in the draft concerns 
itself with two 4-byte paths being aggregated.

> As I am not aware of any implementation that compares and preserves 
> unrecognized attributes in aggregation, I concur that it should be 
> "rare" to see the NEW_AS_PATH after aggregation by an OLD BGP 
> speaker.

Sure. But the transitional mechanism specified in the draft might 
have to remain 'dormant' for 5 or more years. So in addition to 
considering what is typical for speakers today, we should consider 
situations which are valid according to the RFC, particularly if they 
are very easy to deal with.

> In the unlikely scenario that the NEW_AS_PATH got preserved during 
> aggregation by an OLD BGP speaker,  as it is not possible to construct the 
> exact AS path info, it does not seem to matter whether we take the AS_PATH or 
> the NEW_AS_PATH as each of them contains partial, valid info.

Well, the point is more that the merging /method/ doesn't apply any 
longer - the path lengths won't correlate. The method might even fail 
to include /any/ of the OLD path - which clearly is wrong.

> (We could add some clarification, though.)

What exactly is wrong with just ignoring NEW_AS_PATH if 
NEW_AGGREGATOR is? It's consistent and should be simple enough to 
state. I've left the outline quoted below.

> Regardless this loss of AS path info is not new for aggregation. 
> Currently a large portion of the aggregates are created without 
> AS_SET.

Sure, but I do not per se refer to the aggregated information. Other 
portions of the leading path could be lost too, because the method 
itself is inappropriate in such a case.

> -- Enke

>> (For in such a case the path length of the NEW_AS_PATH no longer would have 
>> any strong correlation to the path length of any trailing portion of the 
>> OLD AS_PATH, so the method to determine which part is 'leading' would 
>> produce a meaningless result - eg, it might indicate the AS_PATH has /no/ 
>> leading portion at all, or even a 'negative' leading portion ;) ).

>> E.g: move the text about ignoring NEW_AGGREGATOR to /before/ the text about 
>> NEW_AS_PATH and make the text concerning AS_PATH/NEW_AS_PATH be something 
>> like:
>> 
>> - if NEW_AGGREGATOR was present but has been ignored:
>>     - ignore NEW_AS_PATH
>>     - just strip AS_TRANS from the 2-byte AS_PATH and form the
>>           4-byte PATH directly from the result
>> - else
>>     - perform the merging process (i.e. the updated text you
>>           posted)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
 	The judge fined the jaywalker fifty dollars and told him if he was
caught again, he would be thrown in jail.  Fine today, cooler tomorrow.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 13 Oct 2005 17:11:51 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt 
Cc: [email-masked], Paul Jakma <[email-masked]>, John Leslie <[email-masked]>
Sender: [email-masked]

 > Would you prefer transit and stub to backbone and edge?

yes!

>It doesn't matter which AS converts to as4byte capable first as long
>as the deployment is very far along before 4 byte AS start showing up.

I have got to agree wholeheartedly here

   geoff

At 03:22 PM 13/10/2005, Curtis Villamizar wrote:

>In message <6.2.0.14.2.20051013143340.02e25900@localhost>
>Geoff Huston writes:
> >
> >
> > > > It's the other way around more likely. The edges of the internet are
> > > > more likely to go NEW first...
> > >
> > >    We've agreed that we should spec a transition which can work
> > >either way (backbone going 4-byte first or edges going 4-byte first).
> >
> > I do not understand this. Surprisingly, he earth is not flat.
>
>That is only a theory according to some proposed science curriculum
>revisions in the US.  [Is that too US Centric a joke?]
>
> > What is
> > an 'edge' and what is a 'backbone' are from an individual network
> > operator's perspective often arbitrary distinctions, and then talking
> > about which is these "goes first" is perhaps unhelpful What I like
> > about the draft as it stands is that it views transition as a set of
> > OLD / NEW and NEW / OLD transitions. That's simple and effective.  I
> > would not readily ascribe attributes to a transition spec that starts
> > from a premise of "backbones" and "edges" and then starts to talk
> > about which "goes first".
> >
> > regards,
> >
> >      Geoff
>
>Edges are things that are single homed or at most dual homed but the
>important thing is that they don't take full routes, don't provide any
>transit, and don't readvertise any routes that they learn from one
>Internet facing interface to another.
>
>Would you prefer transit and stub to backbone and edge?
>
>It doesn't matter if single homed stubs ever understand as4byte.  They
>don't really need to run an external routing protocol.  The dual homed
>non-transit might take a subset of routes, but if a few are missing
>they'll never know since they have a default (other than load balance
>might be affected).  As soon as an AS passes routes from one peer to
>another it might start to matter, but many small providers don't
>provide transit to any BGP peers and their customers are not (or
>should not be) passing routes to their other providers if dual homed
>to more than one provider.  These "edges" don't have to convert before
>a transition occurs.
>
>It doesn't matter which AS converts to as4byte capable first as long
>as the deployment is very far along before 4 byte AS start showing up.
>
>Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Wed, 12 Oct 2005 23:29:13 -0700
From: Enke Chen <[email-masked]>
To: John Leslie <[email-masked]>
Subject: Re: [Idr] Revised text on how to construct the AS path info
Cc: [email-masked]
Sender: [email-masked]

Hi, John:

What types of "inconsistencies" between AS_PATH and NEW_AS_PATH you are 
concerned about, beyond the one described in the Transition Section 
(Please see my reply to Paul on that one)?

If your concern is about bogus AS path info somehow got propagated 
around, that seems to be a general issue, independent of the 4byte AS.

-- Enke

John Leslie wrote:

[snip]

>   It's very important to be clear that the AS_PATH "length" MUST be
>the same as the AS_PATH received from the OLD BGP speaker.
>
>   This algorithm should be appropriate, provided a reasonable test
>for consistency between AS_PATH and NEW_AS_PATH is performed. (I'd
>be happy to discuss my ideas for such a test.)
>
>   I think we need to add a provision that the NLRI MAY (or even
>SHOULD) be discarded if the two are inconsistent.
>  
>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Wed, 12 Oct 2005 23:06:30 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Cc: [email-masked]
Subject: [Idr] Re: Revised text on how to construct the AS path info
Sender: [email-masked]

Hi, Paul:

You seem to be talking about the same case described in the Transition 
Sect. of the document::

----------------------------------------------------------------------------------
   Under certain conditions it may not be possible to reconstruct the
   entire AS path information from the AS_PATH and the NEW_AS_PATH
   attributes of a route. This occurs when two or more routes that carry
   the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and
   the NEW_AS_PATH attribute of at least one of these routes carries at
   least one 4-octet AS number (as oppose to a 2-octet AS number that is
   encoded in 4 octets).
-----------------------------------------------------------------------------------

As I am not aware of any implementation that compares and preserves 
unrecognized attributes in aggregation, I concur that it should be 
"rare" to see the NEW_AS_PATH after aggregation by an OLD  BGP speaker.

In the unlikely scenario that the NEW_AS_PATH got preserved during 
aggregation by an OLD BGP speaker,  as it is not possible to construct 
the exact AS path info, it does not seem to matter whether we take the 
AS_PATH or the NEW_AS_PATH as each of them contains partial, valid info. 
(We could add some clarification, though.)

Regardless this loss of AS path info is not new for aggregation. 
Currently a large portion of the aggregates are created without AS_SET.

-- Enke

Paul Jakma wrote:

> Hi Enke,
>
> On Tue, 11 Oct 2005, Enke Chen wrote:
>
>> Hi, folks:
>>
>> Attached is the revised text on how to construct the AS path 
>> information.
>>
>> Please comment if you see any issue.
>
>
> Seems acceptable to me[1].
>
> The issue of what to do if we detect an OLD speaker has done 
> aggregation is still open though:
>
> - If AGGREGATOR does not contain AS_TRANS then:
>     - an OLD speaker, which tries to include unknown attributes
>           of aggregated routes in aggregates, has aggregated the
>           route
>       (these kinds of speakers are rare apparently?)
>
>     - NEW_AGGREGATOR should then be ignored (I believe you will
>           be specifying this in a new revision)
>
> This implies though that NEW_AS_PATH is *also* 'stale' and therefore 
> the merging method will not be appropriate. I'd suggest at least:
>
> - Also ignore NEW_AS_PATH if NEW_AGGREGATOR is ignored
>     - has an issue in what do about AS_TRANS's in the 2-byte path
>       - just remove it? (Section 7 mentions risks with
>             aggregates, as you pointed out to me privately)
>
> This seems far more appropriate than just merging AS_PATH and 
> NEW_AS_PATH given that doing so would likely replace the aggregate's 
> AS_SET information with completely different information from a stale 
> NEW_AS_PATH, or possibly fail to include /any/ portion of the 2-byte 
> path in the merged path.
>
> (For in such a case the path length of the NEW_AS_PATH no longer would 
> have any strong correlation to the path length of any trailing portion 
> of the OLD AS_PATH, so the method to determine which part is 'leading' 
> would produce a meaningless result - eg, it might indicate the AS_PATH 
> has /no/ leading portion at all, or even a 'negative' leading portion 
> ;) ).
>
> It's still sufficiently simple given that this condition will likely 
> be rare and the draft is willing to live with uncommon risks, 
> particulary wrt aggregation.
>
> E.g: move the text about ignoring NEW_AGGREGATOR to /before/ the text 
> about NEW_AS_PATH and make the text concerning AS_PATH/NEW_AS_PATH be 
> something like:
>
> - if NEW_AGGREGATOR was present but has been ignored:
>     - ignore NEW_AS_PATH
>     - just strip AS_TRANS from the 2-byte AS_PATH and form the
>           4-byte PATH directly from the result
> - else
>     - perform the merging process (i.e. the updated text you
>           posted)
>
> The risks could be mitigated better, but with a more involved process 
> of course.
>
>> -- Enke
>
>
> 1. Though, ideally, I'd prefer to see the NEW speaker actually check 
> the 2 paths make sense against each other, given the speaker doing the 
> merging is the only speaker who could detect any such inconsistencies. 
> After merging, the information will be lost. Also, the implementation 
> report strongly suggests that at least one of the implementations 
> /does/ attempt to detect inconsistencies... ;)
>
> regards,

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Geoff Huston <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt 
Date: Thu, 13 Oct 2005 01:22:41 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], Paul Jakma <[email-masked]>, John Leslie <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <6.2.0.14.2.20051013143340.02e25900@localhost>
Geoff Huston writes:
>  
>  
> > > It's the other way around more likely. The edges of the internet are
> > > more likely to go NEW first...
> >
> >    We've agreed that we should spec a transition which can work
> >either way (backbone going 4-byte first or edges going 4-byte first).
>  
> I do not understand this. Surprisingly, he earth is not flat.

That is only a theory according to some proposed science curriculum
revisions in the US.  [Is that too US Centric a joke?]

> What is
> an 'edge' and what is a 'backbone' are from an individual network
> operator's perspective often arbitrary distinctions, and then talking
> about which is these "goes first" is perhaps unhelpful What I like
> about the draft as it stands is that it views transition as a set of
> OLD / NEW and NEW / OLD transitions. That's simple and effective.  I
> would not readily ascribe attributes to a transition spec that starts
> from a premise of "backbones" and "edges" and then starts to talk
> about which "goes first".
>  
> regards,
>  
>      Geoff

Edges are things that are single homed or at most dual homed but the
important thing is that they don't take full routes, don't provide any
transit, and don't readvertise any routes that they learn from one
Internet facing interface to another.

Would you prefer transit and stub to backbone and edge?

It doesn't matter if single homed stubs ever understand as4byte.  They
don't really need to run an external routing protocol.  The dual homed
non-transit might take a subset of routes, but if a few are missing
they'll never know since they have a default (other than load balance
might be affected).  As soon as an AS passes routes from one peer to
another it might start to matter, but many small providers don't
provide transit to any BGP peers and their customers are not (or
should not be) passing routes to their other providers if dual homed
to more than one provider.  These "edges" don't have to convert before
a transition occurs.

It doesn't matter which AS converts to as4byte capable first as long
as the deployment is very far along before 4 byte AS start showing up.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 13 Oct 2005 14:39:16 +1000
To: John Leslie <[email-masked]>, Paul Jakma <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked]
Sender: [email-masked]

> > It's the other way around more likely. The edges of the internet are
> > more likely to go NEW first...
>
>    We've agreed that we should spec a transition which can work
>either way (backbone going 4-byte first or edges going 4-byte first).

I do not understand this. Surprisingly, he earth is not flat. What is an 
'edge' and
what is a 'backbone' are from an individual network operator's perspective 
often
arbitrary distinctions, and then talking about which is these "goes first" 
is perhaps
unhelpful What I like about the draft as it stands is that it views transition
as a set of OLD / NEW and NEW / OLD transitions. That's simple and effective.
I would not readily ascribe attributes to a transition spec that starts 
from a premise
of "backbones" and "edges" and then starts to talk about which "goes first".

regards,

     Geoff

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 13 Oct 2005 13:38:14 +1000
To: Jeffrey Haas <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: [Idr] Revised text for the 4-byte AS draft - IANA Considerations
Cc: [email-masked]
Sender: [email-masked]

At 02:53 AM 13/10/2005, Jeffrey Haas wrote:
>Geoff,
>
>On Thu, Oct 13, 2005 at 02:01:35AM +1000, Geoff Huston wrote:
> > The alternative is to propose an augmentation of the existing AS number
> > registry where the first 65536 numbers are noted as "2-Byte compliant"
> > numbers, and the remainder of the registry are "4-Byte-only" values.
>
>I prefer this option.  While mistakes are probably rare at best,
>this narrows (eliminates) the chances of a mistake causing a conflict
>between the registries.

I'm personally not willing to write text for this option, as I feel that it
makes the 2-byte registry ambiguous in terms of interpretation. What I
have drafted is text that refers to the inclusion of the 2-Byte registry's
contents in the low (0:0 - 0:65,535) number block of the the 4-Byte registry
by reference. If you have alternate text as clear IANA instructions that
preserves the appropriate distinction between the 2-Byte and 4-Byte AS
number registries while co-existing in a single protocol parameter
register then a request for your text that achieves this would be
appropriate.

Geoff Huston
APNIC

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Tony Li <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt 
Date: Wed, 12 Oct 2005 20:45:56 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], John Leslie <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Tony Li writes:
>  
> > It actully went quite well.  The first BGP4 implementation to be
> > deployed was Cisco, written by Tony, deployed by Sean Doran of
> > Sprintlink, then others.
>  
>  
> Small correction: I did the BGP3 implementation, helped get that  
> deployed, and then worked on the BGP4 spec.  pst was responsible for  
> the BGP4 implementation.
>  
> Tony

Oops.  Forgot the transition to Paul.  Thanks for setting the history
straight.

I probably also should have said that Dennis did the gated BGP4
implementation with help from Jeff Honig and Scott Brim of Cornell.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Tony Li <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt 
Date: Wed, 12 Oct 2005 15:26:20 -0700
To: [email-masked]
Cc: [email-masked], John Leslie <[email-masked]>
Sender: [email-masked]

> It actully went quite well.  The first BGP4 implementation to be
> deployed was Cisco, written by Tony, deployed by Sean Doran of
> Sprintlink, then others.

Small correction: I did the BGP3 implementation, helped get that  
deployed, and then worked on the BGP4 spec.  pst was responsible for  
the BGP4 implementation.

Tony

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: John Leslie <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt 
Date: Wed, 12 Oct 2005 17:48:36 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <20051012202706.GB27304@verdi>
John Leslie writes:
>  
> Curtis Villamizar <[email-masked]> wrote:
> > 
> > The deployment of as4bytes is likely to be similar to the deployment
> > of bgp4 itself. 
>  
>    I would hope we could do better -- or at least better than that
> transition would be if scaled to today's deployment figures.

It actully went quite well.  The first BGP4 implementation to be
deployed was Cisco, written by Tony, deployed by Sean Doran of
Sprintlink, then others.  That happenned in about October 1993.  The
next major hurdle was the NSFNET finishing the gated implementation,
that Dennis Furgusson was writing.  That was done in very early 1994
and was deployed by about February 1994.  In the mean time a few
research people like ISI were announcing CIDR routes for testing
purposes.  At the April 1994 IETF the BGPD WG met and it was decided
that BGP4 deployment was widespread enough and nothing bad happenned
with the test routes and CIDR was turned on.  It worked.

What was the problem that you wouldn't want to repeat?  First
implementation to global deployment in a little over 1/2 year.  No
negative impacts on the network other that NASA had to take default
routes due to their proteon routers.

> > In both cases it is known that "bad things can happen" if a subset of
> > core AS deploy "the new stuff" and enable "the new features", in this
> > case start using 4 byte AS numbers. 
>  
>    Agreed, "bad things can happen". :^(
>  
>    Some of them, I would hope, we can predict and tell folks how to
> recognize. That by itself would ease the transition.
>  
>    In an ideal world, we could deploy some debugging tools to aid in
> finding where the problems originate and how to fix them most quickly.
> (Alas, I have no suggestions at the moment.)
>  
> > Since the day that we are actually forced to use 4 byte AS numbers
> > is still quite a ways off it is likely that tier-1 and tier-2
> > providers will deploy as4bytes capable code long before any 4 byte
> > AS is advertised.
>  
>    ... for real customers...
>  
> > It is also likely that providers will coordinate the deployment
> > advertising some test AS numbers first. 
>  
>    Hopefully true. There is no substitute for live testing.
>  
> > It is also possible that straglers will remain that have not deployed
> > as4bytes capable code or have not enabled it, but like NASA in 1994
> > who were still running EGP on their Proteon routers and couldn't
> > handle CIDR routes for a while, it is likely that these straglers
> > are not providing major transit and won't have any impact on the rest
> > of the Internet.
>  
>    That's a bit optimistic, if you mean that bugs in their code won't
> affect the rest of us. Hopefullly it will represent a small minority
> of transport, but I'll be surprised if it doesn't consume a larger
> share of our time chasing rare problems.
>  
> > Just as at the point of CIDR deployment the rule was "support CIDR or
> > use a default route" the rule when as4bytes is deployed may have to be
> > "support as4bytes or use a default route".
>  
>    It's really not that simple, but certainly having a fallback default
> should be strongly recommended for anyone not willing to chase problems.
>  
>    The fly in the ointment is that your _own_ router supporting as4bytes
> won't protect you from bugs introduced by an OLD BGP middleman. While
> there is reason to hope we can "mostly" avoid OLD BGP middlemen, I
> don't believe we can entirely avoid them.
>  
> > If we persisted in discussing what happens in arbitrary mixed
> > CIDR/non-CIDR and BGP/EGP networks we'd still be running EGP and the
> > Internet would have collapsed long ago. 
>  
>    That was a rather different time. There were a limited number of
> backbone routers which _had_to_ support CIDR, and we arranged for them
> to do so. The "don't even try to run defaultless without CIDR" rule
> was very little hassle. As far as BGP-vs-EGP, folks were welcome to
> waste however much time they wanted there, but if they screwed up we
> could simply ignore their routes.
>  
>    Those rules won't work today. We're going to have to plan a campaign
> with no flag days.

Backbone routers were spread among commercial and research backbones.
I'd guess that there were some 50 organizations that took full routes
and had to deploy CIDR capable router code or switch to default.

At that time many US states or groups of states had regional
networks.  Many large US governement agencies had networks providing
transit, not just the NSF, there were many separate European networks
each run by a private or governement agency int a different country,
and there were purely commercial providers as well.

The players have changed but the number of players and peering
complexity has not changed that radically.

CIDR was a much bigger change than as4byte.  CIDR could affect
everything down to the LAN and even the host.  The as4byte changes
affect only provider routers running BGP.

> > This is not to say that some discussion isn't good but at this point
> > we are beating a dead horse.
>  
>    "I ain't dead yet!" ;^)
>  
> > Lets move on with as4bytes.  We hopefully can assume that intelligent
> > people are at the controls at the tier-1 and tier-2 networks for some
> > value of intelligent that is sufficient to get this deployment right.
>  
>    I don't want to claim there aren't enough intelligent folks there,
> but the intelligent ones I know have been known to express such doubts.
> Besides, this is a problem of interaction _between_ AS domains: there's
> not necessarily any level of intelligence sufficient to keep up with
> funky things happening as other AS domains try to adjust to the funky
> things they're seening from yet other AS domains...
>  
>    We're in WGLC here. However much we wish otherwise, it takes a WGLC
> to bring out some issues. We need to be intelligent about whether those
> issues are things worth treating in the spec.
>  
>    Personally, I see several areas which my experience tells me are
> very much worth treating in the spec. YMMV...
>  
> --
> John Leslie <[email-masked]>

If you get 90+% of the networks to transition to being as4byte
capable, then run a lot of test routes with 4 byte AS and see where
they don't go and also to see that they don't cause trouble where they
do go.

The first time ISI put a CIDR route into the global routing they
repeatedly added it and then withdrew it after a few minutes in case
anything bad happenned that they couldn't detect.  Others were doing
the same and those announcing CIDR test routes were cooperating in the
testing.

Then put google, yahoo, and a few other biggies behind a 4 bytes AS
and watch how fast the other <10% convert.  :-)

OK so that's not quite practical, but essentially the problem is the
occasional uncooperative who doesn't get with the program and doesn't
even keep track of what is going on in IETF.  With CIDR it was PSI.
NASA was cooperative in that they had old unsupported routers and so
they used default routing for a while and converted late, but they
made it a point not to hold up CIDR deployment.

The whole point is that there is no problem using as4byte capable code
and using only 2byte AS until there is a need.  During that time
originating test routes from as4byte test AS around the globe can help
flush out the straglers.  In this case there is plenty of time.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Wed, 12 Oct 2005 16:57:13 -0400
From: John Leslie <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] Revised text on how to construct the AS path info
Cc: [email-masked], Paul Jakma <[email-masked]>
Sender: [email-masked]

Enke Chen <[email-masked]> wrote:
> 
> Attached is the revised text on how to construct the AS path information.

   I welcome this clarification. It's much easier to determine whether
a particular algorithm matches this description.

> Please comment if you see any issue.
> ----------------------------------------------------------------------
> 
> The exact AS path information can be constructed by taking as many AS
> numbers and path segments as necessary from the leading part of the
> AS_PATH attribute,

   This much is clearly correct.

> and then prepending them to the NEW_AS_PATH attribute so that the
> AS path information has an identical number of AS numbers as the
> AS_PATH attribute.

   It's very important to be clear that the AS_PATH "length" MUST be
the same as the AS_PATH received from the OLD BGP speaker.

   This algorithm should be appropriate, provided a reasonable test
for consistency between AS_PATH and NEW_AS_PATH is performed. (I'd
be happy to discuss my ideas for such a test.)

   I think we need to add a provision that the NLRI MAY (or even
SHOULD) be discarded if the two are inconsistent.

> The number of AS numbers is calculated...

   I'd prefer not to comment on this part: I haven't examined it in
detail. At first blush, it looks right.

--
John Leslie <[email-masked]>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Wed, 12 Oct 2005 16:47:19 -0400
From: John Leslie <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked]
Sender: [email-masked]

   Paul and I have hashed out a few things privately. I'd like to
update folks on stuff I think we've agreed not to argue on the list:

Paul Jakma <[email-masked]> wrote:
> On Tue, 11 Oct 2005, John Leslie wrote:
> 
>>
>> So while I agree we don't know which path is "wrong", we do know
>> which one the peer we got it from will use.

   I believe Paul is ready to humor me here.

>> Thus, we know which one is "better".

   But not here. I promise not to argue "better".

>> I fail to see how discarding the UPDATE could be appropriate.

   I can't say we're particularly close to agreement, but I have
agreed that discarding the NLRI in an UPDATE containing an AS_PATH
and a NEW_AS_PATH known to be inconsistent is a valid action.

   I believe that discarding such NLRIs _should_ be permitted in
the spec.

>> I really don't see any way to "reconcile" the paths.

   I think we've agreed to stop using that word.

>>  We'd be better advised to choose, IMHO.
>>
>> And I'd advise choosing to "retrofit". We're going to be stuck 
>> with a mixture of systems for many years into the future. 
>> (Hopefully, systems nearest the backbone will become NEW BGP 
>> quickly when ASNs greater than 65535 are allocated; but purchase 
>> cycles will drag on in both directions. Near the edge, nothing 
>> _has_to_ happen until you want to peer with an AS > 65535.)

   I've agreed to stop trying to draw a distinction between "retrofit"
and "tunnel".

> It's the other way around more likely. The edges of the internet are 
> more likely to go NEW first...

   We've agreed that we should spec a transition which can work
either way (backbone going 4-byte first or edges going 4-byte first).

> What good reason is there to /not/ mandate that AS_TRANS expressed 
> 4-byte ASN form is an error?

   We've made some progress here. We're still hung up over calling it
an "error", but we've agreed it could happen in the wild, and that
a BGP speaker with AS > 65535 _should_ discard 4-byte NLRIs containing
it, since they could represent routing loops.

--
John Leslie <[email-masked]>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: [email-masked]
Date: Wed, 12 Oct 2005 15:50:01 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2796bis-02.txt 
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Route Reflection - An Alternative to Full Mesh IBGP
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2796bis-02.txt
	Pages		: 12
	Date		: 2005-10-12
	
The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol designed for TCP/IP internets. Typically all BGP
   speakers within a single AS must be fully meshed so that any external
   routing information must be re-distributed to all other routers
   within that AS. This represents a serious scaling problem that has
   been well documented with several alternatives proposed.

   This document describes the use and design of a method known as
   "Route Reflection" to alleviate the the need for "full mesh" IBGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-rfc2796bis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc2796bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc2796bis-02.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc2796bis-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--

Date: Wed, 12 Oct 2005 16:27:06 -0400
From: John Leslie <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked]
Sender: [email-masked]

Curtis Villamizar <[email-masked]> wrote:
> 
> The deployment of as4bytes is likely to be similar to the deployment
> of bgp4 itself. 

   I would hope we could do better -- or at least better than that
transition would be if scaled to today's deployment figures.

> In both cases it is known that "bad things can happen" if a subset of
> core AS deploy "the new stuff" and enable "the new features", in this
> case start using 4 byte AS numbers. 

   Agreed, "bad things can happen". :^(

   Some of them, I would hope, we can predict and tell folks how to
recognize. That by itself would ease the transition.

   In an ideal world, we could deploy some debugging tools to aid in
finding where the problems originate and how to fix them most quickly.
(Alas, I have no suggestions at the moment.)

> Since the day that we are actually forced to use 4 byte AS numbers
> is still quite a ways off it is likely that tier-1 and tier-2
> providers will deploy as4bytes capable code long before any 4 byte
> AS is advertised.

   ... for real customers...

> It is also likely that providers will coordinate the deployment
> advertising some test AS numbers first. 

   Hopefully true. There is no substitute for live testing.

> It is also possible that straglers will remain that have not deployed
> as4bytes capable code or have not enabled it, but like NASA in 1994
> who were still running EGP on their Proteon routers and couldn't
> handle CIDR routes for a while, it is likely that these straglers
> are not providing major transit and won't have any impact on the rest
> of the Internet.

   That's a bit optimistic, if you mean that bugs in their code won't
affect the rest of us. Hopefullly it will represent a small minority
of transport, but I'll be surprised if it doesn't consume a larger
share of our time chasing rare problems.

> Just as at the point of CIDR deployment the rule was "support CIDR or
> use a default route" the rule when as4bytes is deployed may have to be
> "support as4bytes or use a default route".

   It's really not that simple, but certainly having a fallback default
should be strongly recommended for anyone not willing to chase problems.

   The fly in the ointment is that your _own_ router supporting as4bytes
won't protect you from bugs introduced by an OLD BGP middleman. While
there is reason to hope we can "mostly" avoid OLD BGP middlemen, I
don't believe we can entirely avoid them.

> If we persisted in discussing what happens in arbitrary mixed
> CIDR/non-CIDR and BGP/EGP networks we'd still be running EGP and the
> Internet would have collapsed long ago. 

   That was a rather different time. There were a limited number of
backbone routers which _had_to_ support CIDR, and we arranged for them
to do so. The "don't even try to run defaultless without CIDR" rule
was very little hassle. As far as BGP-vs-EGP, folks were welcome to
waste however much time they wanted there, but if they screwed up we
could simply ignore their routes.

   Those rules won't work today. We're going to have to plan a campaign
with no flag days.

> This is not to say that some discussion isn't good but at this point
> we are beating a dead horse.

   "I ain't dead yet!" ;^)

> Lets move on with as4bytes.  We hopefully can assume that intelligent
> people are at the controls at the tier-1 and tier-2 networks for some
> value of intelligent that is sufficient to get this deployment right.

   I don't want to claim there aren't enough intelligent folks there,
but the intelligent ones I know have been known to express such doubts.
Besides, this is a problem of interaction _between_ AS domains: there's
not necessarily any level of intelligence sufficient to keep up with
funky things happening as other AS domains try to adjust to the funky
things they're seening from yet other AS domains...

   We're in WGLC here. However much we wish otherwise, it takes a WGLC
to bring out some issues. We need to be intelligent about whether those
issues are things worth treating in the spec.

   Personally, I see several areas which my experience tells me are
very much worth treating in the spec. YMMV...

--
John Leslie <[email-masked]>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Wed, 12 Oct 2005 12:53:43 -0400
From: Jeffrey Haas <[email-masked]>
To: Geoff Huston <[email-masked]>
Subject: Re: [Idr] Revised text for the 4-byte AS draft - IANA Considerations
Cc: [email-masked]
Sender: [email-masked]

Geoff,

On Thu, Oct 13, 2005 at 02:01:35AM +1000, Geoff Huston wrote:
> The alternative is to propose an augmentation of the existing AS number
> registry where the first 65536 numbers are noted as "2-Byte compliant"
> numbers, and the remainder of the registry are "4-Byte-only" values.

I prefer this option.  While mistakes are probably rare at best,
this narrows (eliminates) the chances of a mistake causing a conflict
between the registries.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 13 Oct 2005 02:01:35 +1000
To: Enke Chen <[email-masked]>, [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: [Idr] Revised text for the 4-byte AS draft - IANA Considerations
Cc: 
Sender: [email-masked]

If we are considering another round of this draft, then we may want to add
one further paragraph into the IANA Considerations section

namely:

--------------------

IANA is to create a 4-Byte AS Number Registry, where the registry's entries
for 4-Byte AS numbers from 0 to 65535 refer to the IANA "AUTONOMOUS SYSTEM
NUMBERS" registry, including listed reservations, allocations and special
designations. All future changes in the existing "AUTONOMOUS SYSTEM
NUMBERS REGISTRY" are also to be treated in the same way in the 4-Byte
AS number registry. No further 4-Byte AS Number reservations or special
designations apart from those noted here are proposed by this document.

-------------------

Is this proposed text in the IANA Considerations of the draft acceptable
to the WG? (Its either that or we need to do a special  purpose document
later on in order to open up this IANA registry.)

The alternative is to propose an augmentation of the existing AS number
registry where the first 65536 numbers are noted as "2-Byte compliant"
numbers, and the remainder of the registry are "4-Byte-only" values. I do not
recall seeing any precedent here in the IANA registries as to which is a
better way to go, but at least the text proposed here is a placeholder
that can be reviewed by the IANA during the IESG evaluation. If there is
a better idea as to the best way to undertake the IANA registry, then it
can be considered at that point in time.

regards,

   Geoff

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Wed, 12 Oct 2005 09:20:51 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Enke Chen <[email-masked]>
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Subject: [Idr] Re: Revised text on how to construct the AS path info
Sender: [email-masked]

Hi Enke,

On Tue, 11 Oct 2005, Enke Chen wrote:

> Hi, folks:
>
> Attached is the revised text on how to construct the AS path information.
>
> Please comment if you see any issue.

Seems acceptable to me[1].

The issue of what to do if we detect an OLD speaker has done 
aggregation is still open though:

- If AGGREGATOR does not contain AS_TRANS then:
 	- an OLD speaker, which tries to include unknown attributes
           of aggregated routes in aggregates, has aggregated the
           route
 	  (these kinds of speakers are rare apparently?)

 	- NEW_AGGREGATOR should then be ignored (I believe you will
           be specifying this in a new revision)

This implies though that NEW_AS_PATH is *also* 'stale' and therefore 
the merging method will not be appropriate. I'd suggest at least:

- Also ignore NEW_AS_PATH if NEW_AGGREGATOR is ignored
 	- has an issue in what do about AS_TRANS's in the 2-byte path
 	  - just remove it? (Section 7 mentions risks with
             aggregates, as you pointed out to me privately)

This seems far more appropriate than just merging AS_PATH and 
NEW_AS_PATH given that doing so would likely replace the aggregate's 
AS_SET information with completely different information from a stale 
NEW_AS_PATH, or possibly fail to include /any/ portion of the 2-byte 
path in the merged path.

(For in such a case the path length of the NEW_AS_PATH no longer 
would have any strong correlation to the path length of any trailing 
portion of the OLD AS_PATH, so the method to determine which part is 
'leading' would produce a meaningless result - eg, it might indicate 
the AS_PATH has /no/ leading portion at all, or even a 'negative' 
leading portion ;) ).

It's still sufficiently simple given that this condition will likely 
be rare and the draft is willing to live with uncommon risks, 
particulary wrt aggregation.

E.g: move the text about ignoring NEW_AGGREGATOR to /before/ the text 
about NEW_AS_PATH and make the text concerning AS_PATH/NEW_AS_PATH be 
something like:

- if NEW_AGGREGATOR was present but has been ignored:
 	- ignore NEW_AS_PATH
 	- just strip AS_TRANS from the 2-byte AS_PATH and form the
           4-byte PATH directly from the result
- else
 	- perform the merging process (i.e. the updated text you
           posted)

The risks could be mitigated better, but with a more involved process 
of course.

> -- Enke

1. Though, ideally, I'd prefer to see the NEW speaker actually check 
the 2 paths make sense against each other, given the speaker doing 
the merging is the only speaker who could detect any such 
inconsistencies. After merging, the information will be lost. Also, 
the implementation report strongly suggests that at least one of the 
implementations /does/ attempt to detect inconsistencies... ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"The four building blocks of the universe are fire, water, gravel and vinyl."
 		-- Dave Barry

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 11 Oct 2005 18:28:12 -0700
From: Enke Chen <[email-masked]>
To: [email-masked]
Cc: Paul Jakma <[email-masked]>
Subject: [Idr] Revised text on how to construct the AS path info
Sender: [email-masked]

Hi, folks:

Attached is the revised text on how to construct the AS path information.

Please comment if you see any issue.

> Will clarify on how to re-construct the as-path. Will send out the 
> text when it is ready.

-----------------------------------------------------------------------------------------------------

The exact AS path information can be constructed by taking as many AS
numbers and path segments as necessary from the leading part of the
AS_PATH attribute, and then prepending them to the NEW_AS_PATH
attribute so that the AS path information has an identical number of
AS numbers as the AS_PATH attribute. The number of AS numbers is
calculated using the method specified in Sect. 9.1.2.2 [BGP-4] and
[RFC3065] for route selection. Note that an AS_CONFED_SEQUENCE or
AS_CONFED_SET path segment is counted as zero, and SHALL be prepended
when it is adjacent to another path segment that is prepended.
-----------------------------------------------------------------------------------------------------------

-- Enke

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 11 Oct 2005 19:55:28 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: John Leslie <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 11 Oct 2005, Paul Jakma wrote:

> tend to be leaf sites). Indeed the 'backbone' of the internet could stay OLD 
> forever, with edge ASes NEW and it'd still work fine.

NB: That's not to say this would be a good thing. It'd be /far/ 
better if everyone got themselves NEW capable long before the first 
4-byte AS appears.

Just the draft /would/ allow for NEW functionality to just sit at the 
edges. (But then switching the remaining transit ASes to NEW would be 
murder).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Measure twice, cut once.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 11 Oct 2005 19:50:53 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: John Leslie <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Tue, 11 Oct 2005, John Leslie wrote:

> Following this principle, I prefer to use the 2-octet-AS path info 
> I get from my OLD BGP peer unless I'm confident I can do better. 
> (Arguably, we'd be better off to ignore NEW_AS_PATH entirely, but 
> that would sentence folks with AS > 65535 to never detect their 
> loops.)
>
>  So while I agree we don't know which path is "wrong", we do know
> which one the peer we got it from will use.

The peer you got it from is OLD and is in the dark anyway wrt 4-byte 
ASNs. The 2-byte AS_PATH is therefore already incomplete and "wrong".

> Thus, we know which one is "better".

> I fail to see how discarding the UPDATE could be appropriate.

I disagree. Propogating known-inconsistent routes onward is asking 
for trouble during any transition period.

If there's an inconsistency between the two something has either gone 
badly wrong somewhere, or an OLD speaker in the path somewhere has 
decided to make major modifications to the 2-byte AS_PATH for reasons 
known only to itself (an attacker?), specifically modifying the 
portions that contained mapped-to-2byte ASNs, not realising it's 
destroying information it doesn't fully comprehend.

> I really don't see any way to "reconcile" the paths.

Sure there is, there has to be or this draft just can not work at 
all. And if the 2 paths are consistent (and there isn't a good reason 
for them not to be) then it's easy. ;)

>> Ah, indeed yes, that needs clarification too. If AGGREGATOR is /not/
>> AS_TRANS then indeed AGGREGATOR is the last aggregator, and
>> NEW_AGGREGATOR is just simply stale.
>
>   True.

The draft though says NEW_AGGREGATOR should always be used by a NEW 
speaker over AGGREGATOR. So that needs to be fixed in the draft too.

>   We'd be better advised to choose, IMHO.
>
>   And I'd advise choosing to "retrofit". We're going to be stuck 
> with a mixture of systems for many years into the future. 
> (Hopefully, systems nearest the backbone will become NEW BGP 
> quickly when ASNs greater than 65535 are allocated; but purchase 
> cycles will drag on in both directions. Near the edge, nothing 
> _has_to_ happen until you want to peer with an AS > 65535.)

It's the other way around more likely. The edges of the internet are 
more likely to go NEW first (new ASes, the ones which will get 4-byte 
ASNs first, tend to be leaf sites). Indeed the 'backbone' of the 
internet could stay OLD forever, with edge ASes NEW and it'd still 
work fine. If we presume new ASes with 4-byte ASNs get NEW equipment, 
then we can imagine various 'edges' of the internet will look like:

A-B---<rest of internet>
  /
C

If A, B and C are 4-byte, then it just works. To the 'core' of the 
internet, if still 2-byte, it just looks as if there's some new 
super-AS (AS_TRANS) slowly taking over all the new leaf ASes on the 
internet ;).

> Well, that's an open question: if indeed the draft says it MUST be 
> discarded and the NEW_AS_PATH patched in for the remainder, there 
> MIGHT be no reason to see it coming from a NEW BGP speaker to 
> another NEW BGP speaker.

>   But IMHO the draft does _not_ say that. Nor IMHO should it.

It doesn't say it, no. I suspect it should though, as seeing AS_TRANS 
in a 4-byte AS_PATH would be a strong indicator someone screwed up.

What good reason is there to /not/ mandate that AS_TRANS expressed 
4-byte ASN form is an error?

>   IMHO, the draft needs editing to clarify whether we're 
> retrofitting or tunneling. (I trust my recommendation between these 
> is clear.)

I'm not sure why it makes a difference :).

We're moving from 2 to 4 bytes for ASNs, retrofitting 4-bytes on the 
existing BGP protocol and providing for some form of tunneling of 
4-byte AS_PATH's through BGP speakers as a transitional mechanism.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
He who has but four and spends five has no need for a wallet.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt 
Date: Tue, 11 Oct 2005 13:34:44 -0400
From: Curtis Villamizar <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

The deployment of as4bytes is likely to be similar to the deployment
of bgp4 itself.  In both cases it is known that "bad things can
happen" if a subset of core AS deploy "the new stuff" and enable "the
new features", in this case start using 4 byte AS numbers.  Since the
day that we are actaully forced to use 4 byte AS numbers is still
quite a ways off it is likely that tier-1 and tier-2 providers will
deploy as4bytes capable code long before any 4 byte AS is advertised.
It is also likely that providers will coordinate the deployment
advertising some test AS numbers first.  It is also possible that
straglers will remain that have not deployed as4bytes capable code or
have not enabled it, but like NASA in 1994 who were still running EGP
on their Proteon routers and couldn't handle CIDR routes for a while,
it is likely that these straglers are not providing major transit and
won't have any impact on the rest of the Internet.

Just as at the point of CIDR deployment the rule was "support CIDR or
use a default route" the rule when as4bytes is deployed may have to be
"support as4bytes or use a default route".

If we persisted in discussing what happens in arbitrary mixed
CIDR/non-CIDR and BGP/EGP networks we'd still be running EGP and the
Internet would have collapsed long ago.  This is not to say that some
discussion isn't good but at this point we are beating a dead horse.

Lets move on with as4bytes.  We hopefully can assume that intelligent
people are at the controls at the tier-1 and tier-2 networks for some
value of intelligent that is sufficient to get this deployment right.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 11 Oct 2005 11:53:25 -0400
From: John Leslie <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked]
Sender: [email-masked]

Paul Jakma <[email-masked]> wrote:
> On Mon, 10 Oct 2005, John Leslie wrote:
> 
> >]    *  It isn't clear what to do if the information in the old as-path
> >]       is inconsistent with the information in the new as-path.
> >
> >  It seems to me that NEW_AS_PATH information inconsistent with
> >  AS_PATH information MUST be discarded. Can't we say so?
> 
> I'd say the whole UPDATE would have to be discarded, you have no way 
> of knowing exactly which of the two paths is "wrong", nor any way to 
> properly reconstruct the path.

   Recall that the _result_ of all our routing-protocol machinations is
that a packet will be passed to the "most appropriate" next-hop.

   Thus, IMHO, what the peer-you-will-choose doesn't know, can't help
you.

   Following this principle, I prefer to use the 2-octet-AS path info
I get from my OLD BGP peer unless I'm confident I can do better.
(Arguably, we'd be better off to ignore NEW_AS_PATH entirely, but that
would sentence folks with AS > 65535 to never detect their loops.)

   So while I agree we don't know which path is "wrong", we do know
which one the peer we got it from will use. Thus, we know which one
is "better".

   I fail to see how discarding the UPDATE could be appropriate.

>>] AS_PATH attribute). This AS path information should be prepended to
>>] the NEW_AS_PATH attribute to construct the exact AS path information.
>>
>> This last sentence is inconsistent with discarding NEW_AS_PATH
>> information which is inconsistent with AS_PATH information.
> 
> Indeed, but the draft does not specify anywhere what action (if any) 
> should be taken if the paths are found to be inconsistent. But that 
> might be cause it doesn't describe in any meaningful way how to 
> reconcile the different paths.

   I really don't see any way to "reconcile" the paths. I've stated
my preference; the draft seems to choose the opposite direction.
Possibly we can nag Bill or Alex into suggesting a resolution.

>>  I find this worrisome. Any OLD BGP speakers will have been quite 
>> unaware of the meaning of NEW-AGGREGATOR attributes they pass on. I 
>> don't think we can ensure they _never_ introduce or modify an 
>> AGGREGATOR attribute. I would be more comfortable if we examined 
>> any NEW-AGGREGATOR attribute to clarify ambiguity in 2-octet 
>> numbers in the AGGREGATOR attribute.
> 
> Ah, indeed yes, that needs clarification too. If AGGREGATOR is /not/ 
> AS_TRANS then indeed AGGREGATOR is the last aggregator, and 
> NEW_AGGREGATOR is just simply stale.

   True.

> >  There is a philosophical question here: whether we're 
> > retrofitting 4-octet AS numbers into an existing system, or whether 
> > we're piecing together a new system of 4-octet AS numbers with some 
> > fudging of how we tunnel through existing systems. Personally, I 
> > prefer the first.
> 
> I think it's a bit of both.

   We'd be better advised to choose, IMHO.

   And I'd advise choosing to "retrofit". We're going to be stuck with
a mixture of systems for many years into the future. (Hopefully,
systems nearest the backbone will become NEW BGP quickly when ASNs
greater than 65535 are allocated; but purchase cycles will drag on in
both directions. Near the edge, nothing _has_to_ happen until you
want to peer with an AS > 65535.)

>> Instead, we'd do well to match the trailing n ASNs, substituting 
>> 4-octet ASNs for AS_TRANS while the match remains good -- and 
>> dropping back to the original AS_PATH if the match fails.
> 
> If the match fails, you have no clue who ferked up. NEW_AS_PATH 
> /should/ be the canonical path information though for the further 
> portion of the composite path. But if the further portion of the 
> 2-byte path does not coincide with the same further portion of the 
> NEW_AS_PATH then either:
> 
> - an OLD speaker decided to modify bits of the path prior to it
> 	- eg to aggregate it, in which case reconstructing the full
> 	  composite PATH involves more than just appending/prepending
> - the NEW speaker who formed the NEW_AS_PATH screwed up
> 
> - ???

   Mostly (IMHO), it's the second case.

   Let us not forget that the "B" of "BGP" is for "border". IOW,
the border of what we have good reason to trust. We're getting stuff
from peers we have limited reason to trust. They're passing on stuff
from peers _they_ have limited reason to trust. So most of the stuff
we deal with we have _no_ good reason to trust: it's merely "good
enough for best-effort".

   The days are _long_ gone when we could trust BB&N to keep all the
routing information consistent. If there ever was a time we could
trust Cisco to keep stuff consistent throughout the network of their
routers, that too is long gone.

>> (There is a weird case where the matching 4-octet AS _is_ 
>> AS_TRANS, which IMHO is _not_ an error.)
> 
> It is an error, AS_TRANS is reserved and its only described use is to 
> denote 4-byte ASNs in 2-bytes. Hence there is no reason (within this 
> draft at least) to see it in 4-byte space.

   Well, that's an open question: if indeed the draft says it MUST
be discarded and the NEW_AS_PATH patched in for the remainder, there
MIGHT be no reason to see it coming from a NEW BGP speaker to another
NEW BGP speaker.

   But IMHO the draft does _not_ say that. Nor IMHO should it.

>> I'd frankly prefer a full algorithm: otherwise we can't put very
>> much confidence in the result.
>>
>> But I'll admit that differing algorithms _might_ not be especially
>> harmful, so long as they preserve the AS_PATH _length_...
> 
> The draft at least should state what it *intends the result* from 
> merging the OLD and NEW paths to be, and perhaps offer one example 
> algorithm.

   IMHO, the draft needs editing to clarify whether we're retrofitting
or tunneling. (I trust my recommendation between these is clear.)

--
John Leslie <[email-masked]>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 11 Oct 2005 09:57:08 -0400
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked], Paul Jakma <[email-masked]>
Sender: [email-masked]

On Mon, Oct 10, 2005 at 11:59:56AM -0700, Enke Chen wrote:
> * There some places where AS numbers are used where it wasn't
> clear how to deal with 4-octet as-numbers (e.g. extended
> communities).
> 
> Not a problem as the extended community spec has allocated type code for 
> 4-byte ASs.

In extended communities, the type may have as much to do with the community
being unique as does the contents.

RT-100:1 != RT4-100:1

Or at least this is one way to interpret the current spec.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 10 Oct 2005 11:59:56 -0700
From: Enke Chen <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked]
Sender: [email-masked]

Hi, Paul:

Paul Jakma wrote:

> On Fri, 7 Oct 2005, Yakov Rekhter wrote:
>
>> Folks,
>>
>> This is to start the WG Last Call on advancing 
>> draft-ietf-idr-as4bytes-11.txt to a Proposed Standard. The 
>> implementation report is draft-huston-idr-as4bytes-survey-00.txt.
>
>
> 1. Surely the questions raised in the implementation report should
> first be at least examined, if not addressed? (concerns 5.2.3 at
> least, see 3.).

We did examine the questions raised:

* It isn't clear what to do if the information in the old as-path
is inconsistent with the information in the new as-path.

There is no good answer here - but will clarify on re-constructing the 
as-path.

* There some places where AS numbers are used where it wasn't
clear how to deal with 4-octet as-numbers (e.g. extended
communities).

Not a problem as the extended community spec has allocated type code for 
4-byte ASs.

* It isn't spelled out that this capability cannot be dynamically
negotiated.

Not a problem for the revised version of the dynamic capability - 
although there is no reason to make the capability dynamic in this case.

>
> 2. Section 5.3 should be deleted, I'm not sure how this draft could
> ever mandate behaviour for OLD speakers, when OLD specifically is
> defined to be those peers which do not implemented the extensions
> defined in the draft. ;)

Will delete the section.

>
> 3. NEW_AS_PATH parsing/actions are barely specified.
>
> Eg:
>
> NEW NEW NEW OLD OLD NEW
> AS256---AS200000---AS512---AS1024---AS2048---AS4096
>
> According to 5.2.2, AS512 should create an AS_PATH attribute for 
> AS1024 that preserves the path-length by representing each 4-byte ASN 
> with AS_TRANS, and should construct NEW_AS_PATH as per AS_PATH (the 
> AS_PATH as received previously presumably). So AS1024 would receive:
>
> AS_PATH: seq(512,AS_TRANS,256)
> NEW_AS_PATH: seq(200000,256)
>
> AS4096 would receive:
>
> AS_PATH: seq(2048,1024,512,AS_TRANS,256)
> NEW_AS_PATH: seq(200000,256)
>
> 5.2.3 states that:
>
> "<leading part of AS_PATH information> should be prepended to the 
> NEW_AS_PATH attribute to construct the exact AS path information."
>
> Where "leading part" are those ASN that are only 2-byte and OLD. But 
> we're not told how one should deduce where this leading part finishes. 
> The simplistic approach of "closest AS_TRANS marks end of leading 
> part", which is suggested by definition of "leading part" would give us:
>
> seq(2048,1024,512,200000,256)
>
> Which is the correct result, however the method is wrong. Imagine if 
> the 200000 and 256 are the other way around:
>
> AS_PATH: seq(2048,1024,512,256,AS_TRANS)
> NEW_AS_PATH: seq(256,200000)
>
> Using previous method would give:
>
> seq(2048,1024,512,256,256,200000)
>
> Which result is wrong :). Obviously, one should use the n #-of-ASNs in 
> the *NEW_AS_PATH* as the *trailing* part of the real AS_PATH 
> information and override the last n ASNs in the AS_PATH. So why 
> doesn't the draft state this? ;)

Will clarify on how to re-construct the as-path. Will send out the text 
when it is ready.

>
> I.e. The full process should preferably be *documented* in the draft, 
> but at a minimum this vague (if not slightly misleading) 'prepend 
> leading part of AS_PATH' language should be removed.
>
> Also, if a process to reconcile AS_PATH and NEW_AS_PATH is to be 
> described (I think it should ;) ), obvious questions arise, as one 
> responder to the implementation report hints at:
>
> a) Should/Must the "overriden" ASNs in the AS_PATH be reconciled
> against the NEW_AS_PATH ASNs which are replacing them?
>
> b) If so, what if they can /not/ be reconciled?
>
> 4. Some mention, surely, could be made of the issues protocol
> decoders will face, and of the ASN allocation strategy which could
> help remove this issue? (It has a cost of one additional reserved
> 2-byte ASN).

Not sure if this is necessary (based on the previous discussions).

>
> 5. 5.2.3 contains the following statement:
>
> "<the NEW_AS_PATH> attribute may not have been updated since the route 
> left the last NEW BGP speaker."
>
> Which raises the question of how exactly any speaker besides a NEW (or 
> NEW-compatible) speaker would modify NEW_AS_PATH? Indeed, NEW_AS_PATH 
> can /not/ propogate across NEW speakers. The last speaker to have 
> "modified" NEW_AS_PATH is, by the language of the draft, the NEW 
> speaker which formed it which must therefore be the last NEW speaker. 
> So the "may not" should read "will not" instead.

Will revised.

Thanks a lot!

-- Enke

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 10 Oct 2005 21:00:40 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 7 Oct 2005, Yakov Rekhter wrote:
> This is to start the WG Last Call on advancing draft-ietf-idr-as4bytes-11.txt
> to a Proposed Standard. The implementation report is
> draft-huston-idr-as4bytes-survey-00.txt.

high-level bits:

I don't think I've seen justification for this particular approach; if 
this is superior to the others for some reason, maybe background could 
be discussed a bit in the doc (e.g., in a missing "Introduction" 
section).

Specifically, I don't see why we couldn't just simply start using 
NEW_AS_PATH and NEW_AGGREGATOR and keep the old elements as-is -- 
changing the encoding of BGP messages based on the negotiated 
capabilities seems a bit troubling.

An additional concern is synthetization of BGP attributes when 
propagating messages.  One could ask whether this is really necessary 
or not.  I think it would be reasonbly to require that each transit AS 
which would be passing NEW_* attributes should be aware of them. 
Further, this approach could have security considerations if so/sBGP 
were to be deployed.

editorial nits
--------------

numerous nits, such as:
  - numbered status of this memo/abstract
  - references in the abstract
  - a non-ascii character

    For the purpose of this document lets define a BGP speaker which does

==> s/lets/we/

   NEW_AS_PATH.  This attribute is optional transitive and contains the

==> s/attribute is optional transitive/is an optional transitive 
attribute/
(similar elsewhere)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 10 Oct 2005 16:40:20 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: John Leslie <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Mail-Copies-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

On Mon, 10 Oct 2005, John Leslie wrote:

> ]    *  It isn't clear what to do if the information in the old as-path
> ]       is inconsistent with the information in the new as-path.
>
>   It seems to me that NEW_AS_PATH information inconsistent with
>   AS_PATH information MUST be discarded. Can't we say so?

I'd say the whole UPDATE would have to be discarded, you have no way 
of knowing exactly which of the two paths is "wrong", nor any way to 
properly reconstruct the path.

> ] AS_PATH attribute). This AS path information should be prepended to
> ] the NEW_AS_PATH attribute to construct the exact AS path information.
>
>   This last sentence is inconsistent with discarding NEW_AS_PATH
> information which is inconsistent with AS_PATH information.

Indeed, but the draft does not specify anywhere what action (if any) 
should be taken if the paths are found to be inconsistent. But that 
might be cause it doesn't describe in any meaningful way how to 
reconcile the different paths.

>   I find this worrisome. Any OLD BGP speakers will have been quite 
> unaware of the meaning of NEW-AGGREGATOR attributes they pass on. I 
> don't think we can ensure they _never_ introduce or modify an 
> AGGREGATOR attribute. I would be more comfortable if we examined 
> any NEW-AGGREGATOR attribute to clarify ambiguity in 2-octet 
> numbers in the AGGREGATOR attribute.

Ah, indeed yes, that needs clarification too. If AGGREGATOR is /not/ 
AS_TRANS then indeed AGGREGATOR is the last aggregator, and 
NEW_AGGREGATOR is just simply stale.

>   There is a philosophical question here: whether we're 
> retrofitting 4-octet AS numbers into an existing system, or whether 
> we're piecing together a new system of 4-octet AS numbers with some 
> fudging of how we tunnel through existing systems. Personally, I 
> prefer the first.

I think it's a bit of both.

>> According to 5.2.2, AS512 should create an AS_PATH attribute for
>> AS1024 that preserves the path-length by representing each 4-byte ASN
>> with AS_TRANS, and should construct NEW_AS_PATH as per AS_PATH (the
>> AS_PATH as received previously presumably). So AS1024 would receive:
>>
>> AS_PATH:	seq(512,AS_TRANS,256)
>> NEW_AS_PATH:	seq(200000,256)
>
>   Actually, I don't think it's clear whether this NEW_AS_PATH should
> or should not contain 512.

Yes, that's what I was hinting at with "AS_PATH as received 
previously presumably" ;)

>   Paul's algorithm looks safer...
>
>   But IMHO we'd be poorly advised to blindly adopt it either.

Oh, ACK.

> Instead, we'd do well to match the trailing n ASNs, substituting 
> 4-octet ASNs for AS_TRANS while the match remains good -- and 
> dropping back to the original AS_PATH if the match fails.

If the match fails, you have no clue who ferked up. NEW_AS_PATH 
/should/ be the canonical path information though for the further 
portion of the composite path. But if the further portion of the 
2-byte path does not coincide with the same further portion of the 
NEW_AS_PATH then either:

- an OLD speaker decided to modify bits of the path proir to it
 	- eg to aggregate it, in which case reconstructing the full
 	  composite PATH involves more than just appending/prepending
- the NEW speaker who formed the NEW_AS_PATH screwed up

- ???

Actually, is the "OLD speaker aggregated" case even discussed in the 
draft?

>   (There is a weird case where the matching 4-octet AS _is_ 
> AS_TRANS, which IMHO is _not_ an error.)

It is an error, AS_TRANS is reserved and its only described use is to 
denote 4-byte ASNs in 2-bytes. Hence there is no reason (within this 
draft at least) to see it in 4-byte space.

>   I'd frankly prefer a full algorithm: otherwise we can't put very
> much confidence in the result.
>
>   But I'll admit that differing algorithms _might_ not be especially
> harmful, so long as they preserve the AS_PATH _length_...

The draft at least should state what it *intends the result* from 
merging the OLD and NEW paths to be, and perhaps offer one example 
algorithm.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Ignorance must certainly be bliss or there wouldn't be so many people
so resolutely pursuing it.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 10 Oct 2005 11:16:50 -0400
From: John Leslie <[email-masked]>
To: Paul Jakma <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked]
Sender: [email-masked]

Paul Jakma <[email-masked]> wrote:
> 
> 1. Surely the questions raised in the implementation report should
>    first be at least examined, if not addressed?

   To be specific, Juniper reports:
] 
] Are there parts of the specification that are unclear where the
] implementor had to exercise some judgement that may impact
] interoperability?
]    *  It isn't clear what to do if the information in the old as-path
]       is inconsistent with the information in the new as-path.

   It seems to me that NEW_AS_PATH information inconsistent with
AS_PATH information MUST be discarded. Can't we say so?

]    *  There some places where AS numbers are used where it wasn't
]       clear how to deal with 4-octet as-numbers (e.g. extended
]       communities).

   This isn't clear to me, either.

]    *  It isn't spelled out that this capability cannot be dynamically
]       negotiated.

   Actually, I _can_ think how to dynamically negotiate it, but it
seems like a bad idea.

> (concerns 5.2.3 at least, see 3.).
] 
] Note that a route may have traversed a series of autonomous systems
] with 2-octet AS numbers and OLD BGP speakers only. In that case, if
] the route carries a NEW_AS_PATH attribute, this attribute may not
] have been updated since the route left the last NEW BGP speaker. The
] trailing AS path information (representing autonomous systems with
] 2-octet AS numbers and OLD BGP speakers only) is contained only in
] the current AS_PATH attribute (encoded in the leading part of the
] AS_PATH attribute). This AS path information should be prepended to
] the NEW_AS_PATH attribute to construct the exact AS path information.

   This last sentence is inconsistent with discarding NEW_AS_PATH
information which is inconsistent with AS_PATH information.

] Similarly, a NEW BGP speaker should be prepared to receive the
] NEW_AGGREGATOR attribute from an OLD BGP speaker. In that case, the
] AGGREGATOR attribute is ignored and the NEW_AGGREGATOR contains the
] exact information about the aggregating node.

   I find this worrisome. Any OLD BGP speakers will have been quite
unaware of the meaning of NEW-AGGREGATOR attributes they pass on. I
don't think we can ensure they _never_ introduce or modify an
AGGREGATOR attribute. I would be more comfortable if we examined any
NEW-AGGREGATOR attribute to clarify ambiguity in 2-octet numbers in
the AGGREGATOR attribute.

   There is a philosophical question here: whether we're retrofitting
4-octet AS numbers into an existing system, or whether we're piecing
together a new system of 4-octet AS numbers with some fudging of how
we tunnel through existing systems. Personally, I prefer the first.

> 2. Section 5.3 should be deleted, I'm not sure how this draft could
>    ever mandate behaviour for OLD speakers, when OLD specifically is
>    defined to be those peers which do not implemented the extensions
>    defined in the draft. ;)
] 
] In all other cases the speaker MUST encode Autonomous System numbers
] as 2-octet entities in both the AS_PATH and the AGGREGATOR attribute
] in the updates it sends to the peer, and MUST assume that these
] attributes in the updates received from the peer encoded Autonomous
] System numbers as 2-octet entities.

   Our problem is discerning a meaning for "all other cases". I don't
think there _is_ a clear meaning here. The section title suggests
we're specifying what an OLD BGP speaker MUST do; and that's simply
wrong.

   Deleting the secton seems easiest...

> 3. NEW_AS_PATH parsing/actions are barely specified.
> 
> Eg:
> 
>    NEW       NEW       NEW      OLD       OLD     NEW
>    AS256---AS200000---AS512---AS1024---AS2048---AS4096
> 
> According to 5.2.2, AS512 should create an AS_PATH attribute for 
> AS1024 that preserves the path-length by representing each 4-byte ASN 
> with AS_TRANS, and should construct NEW_AS_PATH as per AS_PATH (the 
> AS_PATH as received previously presumably). So AS1024 would receive:
> 
> AS_PATH:	seq(512,AS_TRANS,256)
> NEW_AS_PATH:	seq(200000,256)

   Actually, I don't think it's clear whether this NEW_AS_PATH should
or should not contain 512.

> AS4096 would receive:
> 
> AS_PATH:	seq(2048,1024,512,AS_TRANS,256)
> NEW_AS_PATH:	seq(200000,256)
> 
> 5.2.3 states that:
> 
> "<leading part of AS_PATH information> should be prepended to the 
> NEW_AS_PATH attribute to construct the exact AS path information."
> 
> Where "leading part" are those ASN that are only 2-byte and OLD. But 
> we're not told how one should deduce where this leading part 
> finishes. The simplistic approach of "closest AS_TRANS marks end of 
> leading part",

   This is a very bad algorithm.

   We cannot, IMHO, ensure that AS_TRANS will not somehow get inserted
into a path without there being a corresponding entry in NEW_AS_PATH.
Thus, assuming that the closest AS_TRANS is the demarcation cannot
give dependable results.

   (However, Paul is exploring a different problem:)

> which is suggested by definition of "leading part" would give us:
> 
> 	seq(2048,1024,512,200000,256)
> 
> Which is the correct result, however the method is wrong. Imagine if 
> the 200000 and 256 are the other way around:
> 
> AS_PATH:	seq(2048,1024,512,256,AS_TRANS)
> NEW_AS_PATH:	seq(256,200000)
> 
> Using previous method would give:
> 
> 	seq(2048,1024,512,256,256,200000)
> 
> Which result is wrong :). Obviously, one should use the n #-of-ASNs 
> in the *NEW_AS_PATH* as the *trailing* part of the real AS_PATH 
> information and override the last n ASNs in the AS_PATH. So why 
> doesn't the draft state this? ;)

   Paul's algorithm looks safer...

   But IMHO we'd be poorly advised to blindly adopt it either.
Instead, we'd do well to match the trailing n ASNs, substituting
4-octet ASNs for AS_TRANS while the match remains good -- and dropping
back to the original AS_PATH if the match fails.

   (There is a weird case where the matching 4-octet AS _is_ AS_TRANS,
which IMHO is _not_ an error.)

> I.e. The full process should preferably be *documented* in the draft, 
> but at a minimum this vague (if not slightly misleading) 'prepend 
> leading part of AS_PATH' language should be removed.

   I'd frankly prefer a full algorithm: otherwise we can't put very
much confidence in the result.

   But I'll admit that differing algorithms _might_ not be especially
harmful, so long as they preserve the AS_PATH _length_...

> Also, if a process to reconcile AS_PATH and NEW_AS_PATH is to be 
> described (I think it should ;) ), obvious questions arise, as 
> one responder to the implementation report hints at:
> 
>   a) Should/Must the "overriden" ASNs in the AS_PATH be reconciled
>      against the NEW_AS_PATH ASNs which are replacing them?

   (I, of course, don't believe the should be "overridden" -- merely
disambiguated.)

>   b) If so, what if they can /not/ be reconciled?

   We're poorly advised to leave _that_ question "as an exercise to
the student".

   I'm convinced that regardless of what we spec, NEW BGP speakers
_will_ receive AS_TRANS entries with no disambiguating NEW_AS_PATH
entry. This doesn't seem fatal: the worst effect which jumps out is
failure to detect loops (which seems fairly innocuous: detecting
loops where none exist would be a much more serious failing).

--
John Leslie <[email-masked]>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 10 Oct 2005 14:27:54 +0200
From: Ran Liebermann <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Sender: [email-masked]

On 07/10/05, Yakov Rekhter <[email-masked]> wrote:
> Folks,
>
> This is to start the WG Last Call on advancing draft-ietf-idr-as4bytes-11.txt
> to a Proposed Standard. The implementation report is
> draft-huston-idr-as4bytes-survey-00.txt.

A couple of things:

1.
Just one cosmetic thing.  In my not-fully-English OS I see some funky
characters at the end of section 5.2.2 (last paragraph of page 3, 2nd
line from the top of the paragraph), between "Autonomous System" and
"AS number".

2.
There wasn't any mentioning as to the reserved AS numbers (RFC 1930
section 10).  I think it should be explicitly mentioned that a NEW BGP
speaker peering with an OLD speaker must not insert a reserved AS
number to the NEW_AS_PATH attribute.

Cheers,
--
Ran.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Tony Li <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Date: Mon, 10 Oct 2005 00:43:45 -0700
To: vijay gill <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>, Tony Tauber <[email-masked]>, [email-masked]
Sender: [email-masked]

>>> Router vendors?  Code maintainers?
>>>
>> Customers?
>>
> Make it so!
>

I should have been somewhat less obtuse.

In the interests of being crystal clear and perhaps educating a few  
newcomers and some folks who are otherwise not directly involved in  
the sales process....

In the last 15 years, the dynamic between network equipment customers  
and vendors has changed.  In Ye Olden Days, we all sat together and  
then those of us who coded went off and did things and then those of  
us who ran things tested it and we iterated.  And all saw that it was  
good.

Today, since networking has become Big Business, the dynamic has  
changed drastically.  For the most part the customers who attend IETF  
no longer have  the influence over the purchasing decision that they  
once did.  Instead, there are casts of hundreds involved, lengthy  
RFPs and evaluation processes, and decisions about multiple millions  
of dollars that are handled at the 'C' level in the organization.   
Frequently, the technical considerations are the minority factor in  
the decision making, if they are included at all.

Similarly on the vendor side, the engineers who attend IETF no long  
have a significant say in product content.  Feature development is  
carefully controlled by the vendor's managers, and engineers who  
contribute features that are not a requested part of the PRD for the  
next release are gently excused.

The upshot of this change in the dynamic is that we all need to  
understand that the process for getting ideas translated into product  
has changed.  While talking to one another as part of the IETF  
process is still beneficial, it is no longer sufficient.  In fact, it  
is no longer even an effective mechanism for communicating to the  
vendor.  Instead, the *only* effective channel is via the formal  
sales process.  Even then, the normal account manager or product  
manager may not be sufficient.  You may well need to talk to the  
specific person who is managing the specific release of the specific  
operating system for the specific point product on a specific  
development train.  Sadly, they are far less likely to be up to speed  
on the issue technically or likely to be influenced by "big picture"  
thinking or doing the "right thing".  For them, it is very likely  
that the sales opportunity connected to the feature is the one and  
only factor that is a meaningful input.

I don't mean to defend this process, just to ensure that everyone  
understands that this is the reality that we live in today.  It is  
(sadly) unlikely to change: there is too much money involved.  The  
only thing that we can do at this point is to cooperate to influence  
those above us in our respective organizations, realizing that none  
of us are empowered to be the decision makers for our respective  
companies.  Forward progress on this issue will take influencing both  
customer and vendor executives and we should ensure that we do that,  
but first and foremost we should be responsible for influencing our  
own organizations.  It would be best if we coordinated our efforts,  
but we should at the very least understand that all involved are  
somewhat limited in their authority.

Newly yours on the customer side of street,
Tony

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Sun, 09 Oct 2005 23:08:47 -0400
From: vijay gill <[email-masked]>
Organization: vgill global logistics
To: Tony Li <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked], Yakov Rekhter <[email-masked]>, Tony Tauber <[email-masked]>, [email-masked]
Sender: [email-masked]

Tony Li wrote:
> 
>> Router vendors?  Code maintainers?
> 
> 
> Customers?
> 
> Tony

Make it so!

Though I'm sure I missed where we couldn't make it 128 bytes and call it 
done.

/vijay

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 10 Oct 2005 02:15:06 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Mail-Copies-To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 7 Oct 2005, Yakov Rekhter wrote:

> Folks,
>
> This is to start the WG Last Call on advancing 
> draft-ietf-idr-as4bytes-11.txt to a Proposed Standard. The 
> implementation report is draft-huston-idr-as4bytes-survey-00.txt.

1. Surely the questions raised in the implementation report should
    first be at least examined, if not addressed? (concerns 5.2.3 at
    least, see 3.).

2. Section 5.3 should be deleted, I'm not sure how this draft could
    ever mandate behaviour for OLD speakers, when OLD specifically is
    defined to be those peers which do not implemented the extensions
    defined in the draft. ;)

3. NEW_AS_PATH parsing/actions are barely specified.

Eg:

    NEW       NEW       NEW      OLD       OLD     NEW
    AS256---AS200000---AS512---AS1024---AS2048---AS4096

According to 5.2.2, AS512 should create an AS_PATH attribute for 
AS1024 that preserves the path-length by representing each 4-byte ASN 
with AS_TRANS, and should construct NEW_AS_PATH as per AS_PATH (the 
AS_PATH as received previously presumably). So AS1024 would receive:

AS_PATH:	seq(512,AS_TRANS,256)
NEW_AS_PATH:	seq(200000,256)

AS4096 would receive:

AS_PATH:	seq(2048,1024,512,AS_TRANS,256)
NEW_AS_PATH:	seq(200000,256)

5.2.3 states that:

"<leading part of AS_PATH information> should be prepended to the 
NEW_AS_PATH attribute to construct the exact AS path information."

Where "leading part" are those ASN that are only 2-byte and OLD. But 
we're not told how one should deduce where this leading part 
finishes. The simplistic approach of "closest AS_TRANS marks end of 
leading part", which is suggested by definition of "leading part" 
would give us:

 	seq(2048,1024,512,200000,256)

Which is the correct result, however the method is wrong. Imagine if 
the 200000 and 256 are the other way around:

AS_PATH:	seq(2048,1024,512,256,AS_TRANS)
NEW_AS_PATH:	seq(256,200000)

Using previous method would give:

 	seq(2048,1024,512,256,256,200000)

Which result is wrong :). Obviously, one should use the n #-of-ASNs 
in the *NEW_AS_PATH* as the *trailing* part of the real AS_PATH 
information and override the last n ASNs in the AS_PATH. So why 
doesn't the draft state this? ;)

I.e. The full process should preferably be *documented* in the draft, 
but at a minimum this vague (if not slightly misleading) 'prepend 
leading part of AS_PATH' language should be removed.

Also, if a process to reconcile AS_PATH and NEW_AS_PATH is to be 
described (I think it should ;) ), obvious questions arise, as 
one responder to the implementation report hints at:

   a) Should/Must the "overriden" ASNs in the AS_PATH be reconciled
      against the NEW_AS_PATH ASNs which are replacing them?

   b) If so, what if they can /not/ be reconciled?

4. Some mention, surely, could be made of the issues protocol
    decoders will face, and of the ASN allocation strategy which could
    help remove this issue? (It has a cost of one additional reserved
    2-byte ASN).

5. 5.2.3 contains the following statement:

"<the NEW_AS_PATH> attribute may not have been updated since the 
route left the last NEW BGP speaker."

Which raises the question of how exactly any speaker besides a NEW 
(or NEW-compatible) speaker would modify NEW_AS_PATH? Indeed, 
NEW_AS_PATH can /not/ propogate across NEW speakers. The last speaker 
to have "modified" NEW_AS_PATH is, by the language of the draft, the 
NEW speaker which formed it which must therefore be the last NEW 
speaker. So the "may not" should read "will not" instead.

> Yakov.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Thank goodness modern convenience is a thing of the remote future.
 		-- Pogo, by Walt Kelly

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Tony Li <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Date: Sun, 9 Oct 2005 13:48:21 -0700
To: Tony Tauber <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

> Router vendors?  Code maintainers?

Customers?

Tony

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Sun, 9 Oct 2005 13:25:42 -0700 (PDT)
From: Tony Tauber <[email-masked]>
To: Geoff Huston <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, 8 Oct 2005, Geoff Huston wrote:

> I am happy to see this draft advance.
>
>  Geoff

Me as well.

Would be nice if the implementation list were a tad longer...

Router vendors?  Code maintainers?

Tony

> At 02:41 AM 8/10/2005, Yakov Rekhter wrote:
>> Folks,
>> 
>> This is to start the WG Last Call on advancing 
>> draft-ietf-idr-as4bytes-11.txt
>> to a Proposed Standard. The implementation report is
>> draft-huston-idr-as4bytes-survey-00.txt.
>>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Sat, 08 Oct 2005 15:16:42 +1000
To: Yakov Rekhter <[email-masked]>, [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Cc: [email-masked]
Sender: [email-masked]

I am happy to see this draft advance.

   Geoff

At 02:41 AM 8/10/2005, Yakov Rekhter wrote:
>Folks,
>
>This is to start the WG Last Call on advancing draft-ietf-idr-as4bytes-11.txt
>to a Proposed Standard. The implementation report is
>draft-huston-idr-as4bytes-survey-00.txt.
>
>The Last Call ends Oct 21, 2005.
>
>Yakov.
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Fri, 07 Oct 2005 09:41:41 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Sender: [email-masked]

Folks,

This is to start the WG Last Call on advancing draft-ietf-idr-as4bytes-11.txt
to a Proposed Standard. The implementation report is
draft-huston-idr-as4bytes-survey-00.txt.

The Last Call ends Oct 21, 2005.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: [email-masked]
Date: Wed, 05 Oct 2005 15:50:02 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc3065bis-05.txt 
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Autonomous System Confederations for BGP
	Author(s)	: P. Traina, et al.
	Filename	: draft-ietf-idr-rfc3065bis-05.txt
	Pages		: 15
	Date		: 2005-10-5
	
The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol designed for Transmission Control Protocol/Internet
   Protocol (TCP/IP) networks.  BGP requires that all BGP speakers
   within a single autonomous system (AS) must be fully meshed.  This
   represents a serious scaling problem that has been well documented in
   a number of proposals.

   This document describes an extension to BGP which may be used to
   create a confederation of autonomous systems that is represented as a
   single autonomous system to BGP peers external to the confederation,
   thereby removing the "full mesh" requirement.  The intention of this
   extension is to aid in policy administration and reduce the
   management complexity of maintaining a large autonomous system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-rfc3065bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-rfc3065bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc3065bis-05.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc3065bis-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--

To: [email-masked]
From: Danny McPherson <[email-masked]>
Date: Tue, 4 Oct 2005 09:49:02 -0600
Subject: [Idr] RFC3065bis Implementation Survey
Sender: [email-masked]

Folks,
If you've implemented AS Confederations for BGP could you
please complete the following questionnaire and get your
responses back to me ASAP?

Note that I plan to update the -04 version of BGP Confederations ID
(to keep it's expiry from triggering) but no technical changes are
planned.

Thanks in advance!

-danny

==================
AS Confederations for BGP Implementation Survey

http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3065bis-04.txt

Contact and implementation Information or person filling
out this form:

Does your implementation follow the procedures outlined in the
Operation Section of [RFC3065bis]?

Does your implementation recognize the two AS_CONFED
Segment Types (AS_CONFED_SET and AS_CONFED_SEQUENCE)
defined in [RFC3065bis]

Does your implementation use it's Member-AS number in all
transactions with peers that are members of the same BGP
confederation as the local speaker?

Does your implementation treat receipt of an AS_PATH attribute
containing an autonomous system matching its own AS Confederation
Identifier in the same fashion as if it had received a path
containing its own AS number?

Does your implementation treat receipt of an AS_PATH attribute
containing an AS_CONFED_SEQUENCE or AS_CONFED_SET which
contains its own Member-AS Number in the same fashion as if it had
received a path containing its own AS number?

Does your implementation follow the AS_PATH Modification Rules
outlined in [RFC3065bis]?

Does your implementation follow the Error Handling procedures
outlined in [RFC3065bis]?

Does your implementation follow the Path Selection guidelines outlined
in [RFC3065bis]?

List other implementations that you have tested for Autonomous
System Confederations for BGP [RFC3065bis]:

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: [email-masked]
Date: Tue, 04 Oct 2005 10:50:01 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-multisession-01.txt 
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Multisession BGP
	Author(s)	: J. Scudder, C. Appanna
	Filename	: draft-ietf-idr-bgp-multisession-01.txt
	Pages		: 14
	Date		: 2005-10-4
	
This specification augments "Multiprotocol Extensions for BGP-4" [MP-
   BGP] by proposing a mechanism to allow multiple sessions to be used
   between a given pair of BGP speakers.  Each session is used to
   transport routes for one or more AFI/SAFI.  This provides an
   alternative to the current [MP-BGP] approach of multiplexing routes
   for all AFI/SAFI onto a single connection.

   Use of this approach is expected to increase the robustness of the
   BGP protocol as it is used to support more and more diverse AFI/SAFI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-multisession-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-multisession-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-multisession-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-multisession-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--

From: "Dow M. Street" <[email-masked]>
Subject: Re: [Idr] Recommend Book on BGP
Date: Mon, 3 Oct 2005 11:11:40 -0700
To: [email-masked]
Sender: [email-masked]

If still looking for a "book", you may find Network Algorithmics  
(ISBN: 0-12-088477-1) useful in general concepts, if not BGP specifics..

On Oct 3, 2005, at 9:14 AM, Curtis Villamizar wrote:

>
> In message <[email-masked]>
> Adam Greenhalgh writes:
>
>>
>> Perhaps you might like to take a look at the XORP modular router's  
>> bgp
>> code, http://www.xorp.org , some details about the implementation are
>> here :
>> http://www.cs.ucl.ac.uk/staff/M.Handley/papers/xorp-nsdi.pdf
>>
>> Adam
>>
>
>
> Adam,
>
> Thanks for the pointer.  That paper is certainly a good start.  I'm
> more familiar with the Gated implementation.  I don't know if there
> was an archive of e-mail among the gated developers while the Gated
> Consortium was still at Cornell but that is when the original gated
> BGP-4 implementation was written (mostly by Dennis Furgusson) and when
> the most open discussion of BGP scaling considerations was going on
> (at least that I know of).  Gated documentation from the old public
> releases might help.
>
> Curtis
>
>
>
>> On 03/10/05, Curtis Villamizar <[email-masked]> wrote:
>>
>>>
>>> In message <[email-masked]>
>>> "john smith" writes:
>>>
>>>>
>>>> The RFC seems fine,
>>>>
>>>> perhaps something like "BGP is based on the Bellman-Ford  
>>>> algorithm" etc.
>>>> would be a nice line to add....
>>>>
>>>>
>>>>
>>>>> From: Jing Shen <[email-masked]>
>>>>> To: [email-masked]
>>>>> Subject: [Idr] Recommend Book on BGP
>>>>> Date: Fri, 30 Sep 2005 16:57:13 +0800 (CST)
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm sorry if this is off-topic.
>>>>>
>>>>> Would anybody recommend some book on BGP? Someone
>>>>> recommend Halabi's book, but it seems focusing on
>>>>> operational area. Is there any book discussing how BGP
>>>>> is designed and implemented?
>>>>>
>>>>> thanks
>>>>>
>>>>> Joe shen
>>>>>
>>>
>>>
>>> John,
>>>
>>> The question seemed to be more focused on how to design and code  
>>> a BGP
>>> implementation, presumably one that will not fail when deployed in a
>>> real network.  I sent Mr. Shen a private message indicating that  
>>> there
>>> was no really good book on BGP implementation.  The lessons learned
>>> about BGP's behaviour in real networds and the implications for data
>>> structures and algorithms used to implement BGP is not to my  
>>> knowledge
>>> available in any textbook.
>>>
>>> There are plenty of anecdotal examples in IETF and NANOG archives of
>>> things that weren't done right the first time in some  
>>> implementations.
>>> Even basic things like making writes non-blocking and properly
>>> handling non-blocking writes have been missed by some  
>>> implementations.
>>> One prominent implementation at one time had a linked list of per
>>> prefix policy statements despite the known poor search time for a
>>> linked list.  An example of a misfeature is one vendors ill  
>>> conceived
>>> "optimization" of sending route deletes to all peers even if no  
>>> route
>>> announcement had been sent to a subset of those peers.  All of these
>>> problems are corrected in today's major implementations.
>>>
>>> Though not in any textbook, apparently this stuff is far enough from
>>> obvious that it wouldn't hurt to be in one.  The reason it isn't may
>>> be that the audience for such a book is too small or there is a lack
>>> of people with the capabilty and time to write it.
>>>
>>> That sort of thing doesn't belong in the RFC and mentioning
>>> Bellman-Ford doesn't come anywhere close to covering the topic.
>>>
>>> Curtis
>>>
>>> ps - History also has plenty of at one time deployed "how not to
>>> design a router" problems that are not specific to BGP.
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/idr
>>>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Adam Greenhalgh <[email-masked]>
Subject: Re: [Idr] Recommend Book on BGP 
Date: Mon, 03 Oct 2005 12:14:06 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Adam Greenhalgh writes:
>  
> Perhaps you might like to take a look at the XORP modular router's bgp
> code, http://www.xorp.org , some details about the implementation are
> here :
> http://www.cs.ucl.ac.uk/staff/M.Handley/papers/xorp-nsdi.pdf
>  
> Adam

Adam,

Thanks for the pointer.  That paper is certainly a good start.  I'm
more familiar with the Gated implementation.  I don't know if there
was an archive of e-mail among the gated developers while the Gated
Consortium was still at Cornell but that is when the original gated
BGP-4 implementation was written (mostly by Dennis Furgusson) and when
the most open discussion of BGP scaling considerations was going on
(at least that I know of).  Gated documentation from the old public
releases might help.

Curtis

> On 03/10/05, Curtis Villamizar <[email-masked]> wrote:
> >
> > In message <[email-masked]>
> > "john smith" writes:
> > >
> > > The RFC seems fine,
> > >
> > > perhaps something like "BGP is based on the Bellman-Ford algorithm" etc.
> > > would be a nice line to add....
> > >
> > >
> > > >From: Jing Shen <[email-masked]>
> > > >To: [email-masked]
> > > >Subject: [Idr] Recommend Book on BGP
> > > >Date: Fri, 30 Sep 2005 16:57:13 +0800 (CST)
> > > >
> > > >Hi,
> > > >
> > > >I'm sorry if this is off-topic.
> > > >
> > > >Would anybody recommend some book on BGP? Someone
> > > >recommend Halabi's book, but it seems focusing on
> > > >operational area. Is there any book discussing how BGP
> > > >is designed and implemented?
> > > >
> > > >thanks
> > > >
> > > >Joe shen
> >
> >
> > John,
> >
> > The question seemed to be more focused on how to design and code a BGP
> > implementation, presumably one that will not fail when deployed in a
> > real network.  I sent Mr. Shen a private message indicating that there
> > was no really good book on BGP implementation.  The lessons learned
> > about BGP's behaviour in real networds and the implications for data
> > structures and algorithms used to implement BGP is not to my knowledge
> > available in any textbook.
> >
> > There are plenty of anecdotal examples in IETF and NANOG archives of
> > things that weren't done right the first time in some implementations.
> > Even basic things like making writes non-blocking and properly
> > handling non-blocking writes have been missed by some implementations.
> > One prominent implementation at one time had a linked list of per
> > prefix policy statements despite the known poor search time for a
> > linked list.  An example of a misfeature is one vendors ill conceived
> > "optimization" of sending route deletes to all peers even if no route
> > announcement had been sent to a subset of those peers.  All of these
> > problems are corrected in today's major implementations.
> >
> > Though not in any textbook, apparently this stuff is far enough from
> > obvious that it wouldn't hurt to be in one.  The reason it isn't may
> > be that the audience for such a book is too small or there is a lack
> > of people with the capabilty and time to write it.
> >
> > That sort of thing doesn't belong in the RFC and mentioning
> > Bellman-Ford doesn't come anywhere close to covering the topic.
> >
> > Curtis
> >
> > ps - History also has plenty of at one time deployed "how not to
> > design a router" problems that are not specific to BGP.
> >
> > _______________________________________________
> > Idr mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Recommend Book on BGP
Date: Mon, 03 Oct 2005 05:41:11 +0000
Sender: [email-masked]

>Though not in any textbook, apparently this stuff is far enough from
>obvious that it wouldn't hurt to be in one.  The reason it isn't may
>be that the audience for such a book is too small or there is a lack
>of people with the capabilty and time to write it.
>
>That sort of thing doesn't belong in the RFC and mentioning
>Bellman-Ford doesn't come anywhere close to covering the topic.
>
>Curtis
>
>ps - History also has plenty of at one time deployed "how not to
>design a router" problems that are not specific to BGP.

Then there is no harm in writing code like this is there?

for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("|"+(*u/4) %2);

as stated here:
http://www.gdargaud.net/Humor/C_Prog_Debug.html

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "john smith" <[email-masked]>
Subject: Re: [Idr] Recommend Book on BGP 
Date: Mon, 03 Oct 2005 01:04:42 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"john smith" writes:
>  
> The RFC seems fine,
>  
> perhaps something like "BGP is based on the Bellman-Ford algorithm" etc. 
> would be a nice line to add....
>  
>  
> >From: Jing Shen <[email-masked]>
> >To: [email-masked]
> >Subject: [Idr] Recommend Book on BGP
> >Date: Fri, 30 Sep 2005 16:57:13 +0800 (CST)
> >
> >Hi,
> >
> >I'm sorry if this is off-topic.
> >
> >Would anybody recommend some book on BGP? Someone
> >recommend Halabi's book, but it seems focusing on
> >operational area. Is there any book discussing how BGP
> >is designed and implemented?
> >
> >thanks
> >
> >Joe shen

John,

The question seemed to be more focused on how to design and code a BGP
implementation, presumably one that will not fail when deployed in a
real network.  I sent Mr. Shen a private message indicating that there
was no really good book on BGP implementation.  The lessons learned
about BGP's behaviour in real networds and the implications for data
structures and algorithms used to implement BGP is not to my knowledge
available in any textbook.

There are plenty of anecdotal examples in IETF and NANOG archives of
things that weren't done right the first time in some implementations.
Even basic things like making writes non-blocking and properly
handling non-blocking writes have been missed by some implementations.
One prominent implementation at one time had a linked list of per
prefix policy statements despite the known poor search time for a
linked list.  An example of a misfeature is one vendors ill conceived
"optimization" of sending route deletes to all peers even if no route
announcement had been sent to a subset of those peers.  All of these
problems are corrected in today's major implementations.

Though not in any textbook, apparently this stuff is far enough from
obvious that it wouldn't hurt to be in one.  The reason it isn't may
be that the audience for such a book is too small or there is a lack
of people with the capabilty and time to write it.  

That sort of thing doesn't belong in the RFC and mentioning
Bellman-Ford doesn't come anywhere close to covering the topic.

Curtis

ps - History also has plenty of at one time deployed "how not to
design a router" problems that are not specific to BGP.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Recommend Book on BGP
Date: Mon, 03 Oct 2005 04:26:20 +0000
Sender: [email-masked]

Yes but it is always nice to know the original source/problem statement.

>From: Reji Varghese <[email-masked]>
>To: john smith <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Idr] Recommend Book on BGP
>Date: Mon, 03 Oct 2005 09:47:49 +0530
>
>Christian Huitema's 'Routing in the Internet' is a good source,
>though not very elaborate.
>
>Another one is 'BGP4 Inter-Domain Routing in the Internet'
>by John W. Stewart
>
>Regards
>Reji Varghese
>
>john smith wrote:
>
>>The RFC seems fine,
>>
>>perhaps something like "BGP is based on the Bellman-Ford algorithm" etc. 
>>would be a nice line to add....
>>
>>
>>>From: Jing Shen <[email-masked]>
>>>To: [email-masked]
>>>Subject: [Idr] Recommend Book on BGP
>>>Date: Fri, 30 Sep 2005 16:57:13 +0800 (CST)
>>>
>>>Hi,
>>>
>>>I'm sorry if this is off-topic.
>>>
>>>Would anybody recommend some book on BGP? Someone
>>>recommend Halabi's book, but it seems focusing on
>>>operational area. Is there any book discussing how BGP
>>>is designed and implemented?
>>>
>>>thanks
>>>
>>>Joe shen
>>>
>>
>>_________________________________________________________________
>>Don't just search. Find. Check out the new MSN Search! 
>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>>
>>
>>_______________________________________________
>>Idr mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/idr
>>
>
>--
>Reji Varghese
>Phone: +91-80-2601 4096
>------------------------------------------------------------------------
>[  ]   General Business Information
>[x]  Motorola Internal Use only
>[  ]   Motorola Confidential Proprietary
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: RE: [Idr] Recommend Book on BGP
Date: Mon, 03 Oct 2005 04:04:19 +0000
Sender: [email-masked]

The RFC seems fine,

perhaps something like "BGP is based on the Bellman-Ford algorithm" etc. 
would be a nice line to add....

>From: Jing Shen <[email-masked]>
>To: [email-masked]
>Subject: [Idr] Recommend Book on BGP
>Date: Fri, 30 Sep 2005 16:57:13 +0800 (CST)
>
>Hi,
>
>I'm sorry if this is off-topic.
>
>Would anybody recommend some book on BGP? Someone
>recommend Halabi's book, but it seems focusing on
>operational area. Is there any book discussing how BGP
>is designed and implemented?
>
>thanks
>
>Joe shen
>

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Subject: [Idr] IDR WG agenda
Date: Sun, 02 Oct 2005 06:42:51 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Folks,
 
Its about time to start thinking about agenda items for the next
IETF. Please forward any IDR agenda items you might have to me and Sue.

And if you plan to make a presentation, please also keep in mind the 
rule "no document - no time slot".

Sue & Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Fri, 30 Sep 2005 12:20:36 -0500
From: Isabel Burris <[email-masked]>
Reply-To: Isabel Burris <[email-masked]>
To: <[email-masked]>
Subject: Do you like fabulous bargains on Brand Name merchandise? 

Elloelloello :)
Treat yourself to discounted luxury items at http://blowoutfallsale2005.com/?47 during our Special FALL SALE. 
Just look at our inventory and you'll understand that you cant pass on such great deals!  
We minimized our expenses to deliver the lowest possible price to our customers.
We offer quick order processing, online account reports, and live customer support for existing customers.
Your shopping experience at http://blowoutfallsale2005.com/?47 will keep you coming back for more great deals!