Subject: [Idr] Recommend Book on BGP

From: Jing Shen <[email-masked]>
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

		
___________________________________________________________ 
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 
http://cn.mail.yahoo.com

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

Date: Fri, 30 Sep 2005 16:57:13 +0800 (CST)
From: Jing Shen <[email-masked]>
To: [email-masked]
Subject: [Idr] Recommend Book on BGP
Sender: [email-masked]

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

		
___________________________________________________________ 
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 
http://cn.mail.yahoo.com

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

To: [email-masked]
From: [email-masked]
Date: Wed, 28 Sep 2005 15:50:02 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-11.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 Support for Four-octet AS Number Space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-11.txt
	Pages		: 9
	Date		: 2005-9-28
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
   two-octet field. This document describes extensions to BGP to carry
   the Autonomous System number as a four-octet field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-11.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-as4bytes-11.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-as4bytes-11.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-as4bytes-11.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-11.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: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Date: Fri, 23 Sep 2005 17:28:31 -0400
Cc: [email-masked]
Subject: [Idr] Last Call: 'Multiprotocol Extensions for BGP-4' to Draft Standard 
Reply-To: [email-masked]
Sender: [email-masked]

The IESG has received a request from the Inter-Domain Routing WG to consider 
the following document:

- 'Multiprotocol Extensions for BGP-4 '
   <draft-ietf-idr-rfc2858bis-07.txt> as a Draft Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-10-07.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-07.txt

The Implementation Report can be accessed at
http://www.ietf.org/IESG/Implementations/mp-bgp-implementation-report.txt

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

Date: Tue, 20 Sep 2005 11:34:44 +1000
To: "Yakov Rekhter" <[email-masked]>, [email-masked]
From: Geoff Huston <[email-masked]>
Cc: [email-masked], Bruno Rijsman <[email-masked]>
Subject: [Idr] draft-ietf-idr--as4bytes - Implementation Report
Sender: [email-masked]

Hi,

At the last IDR working group meeting I took the action to complete
an implementation report on the 4-byte AS draft.  The attached
implementation report has been submitted as an internet draft
(to be published as draft-huston-idr-as4bytes-survey-00.txt)

My thanks to Bruno Rijsman, Enke Chen and Albert Tian for their
kind assistance in assembling this report.

regards,

   Geoff

----------------------------------------------------------------------------
4-Byte AS Implementation Report

September 2005

Abstract

   This document provides a survey of BGP-4 4-Byte AS Number support
   implementations.

1.  Survey Summary

   This document provides a survey of BGP-4 4-Byte AS Number Support
   [ID.4ByteAS] implementations.  After a brief summary, each response
   is listed.  The editor makes no claim as to the accuracy of the
   information provided.

2.  Summary Forms

2.1.  Juniper Networks

   Organization: Juniper Networks

   Person filling out this form:
      Bruno Rijsman <[email-masked]>

   Implementation:
      JUNOSe 4-1-0 and later

   Does the implementation include all parts of the specification:
      Yes

   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.
      *  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).
      *  It isn't spelled out that this capability cannot be dynamically
         negotiated.

   Has there been any interoperability testing?
      Yes; no problems were discovered.

      1.  NEW / OLD ineroperability testing with:
             Juniper ERX (older version which does not support draft)
             Juniper M/T/J
             Cisco 7500

      2.  NEW / NEW interoperability testing with:
             Juniper M/T/J
             Redback SmartEdge

      3.  Most deployed Juniper ERX routers run code which supports
          4-octet AS-numbers (and the feature is enabled by default).
          This provides some confidence that the draft does not cause
          interoperability problems.  Note however that the NEW_AS_PATH
          attribute is not generated unless the AS-path contains at
          least one AS-number greater than 65535 which is -as far as we
          know- not yet the case in the Internet today.

   Has there been testing of the interface between this implementation
   and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte)
   update path?
      Yes

   Has there been testing of the OLD (2-byte) to NEW (4-byte) path?
      Yes

   Have there been any issues noted with the mechanism to reconstruct
   the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS
   Path on an OLD -NEW BGP update session?
      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.

   Any other comments regarding the implementation
      Some older versions of Cisco IOS send an unsupported capability
      notification (instead of ignoring the capability) when they
      receive a capability advertisement which they don't recognize and
      which has non-empty data.  The 4-octet as-number capability is
      such a capability.  Our implementation recognizes this
      notification and stops automatically stops advertising the 4-octet
      as-numbers capability (and others) until the next hard clear on
      the BGP session.

2.2.  Redback

   Organization: Redback

   Person filling out this form:
      Albert Tian <[email-masked]>

   Does the implementation include all parts of the specification:
      Yes

   Are there parts of the specification that are unclear where the
   implementor had to exercise some judgement that may impact
   interoperability?
      No.

   Has there been any interoperability testing?
      Yes

   Has there been testing of the interface between this implementation
   and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte)
   update path?
      Yes (Cisco: 2-byte; Redback: 4 byte).

   Has there been testing of the OLD (2-byte) to NEW (4-byte) path?
      Yes. (Cisco: 2-byte; Redback: 4-byte).

   Have there been any issues noted with the mechanism to reconstruct
   the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS
   Path on an OLD -NEW BGP update session?
      No

   Have there been any issues noted with the mechanism to reconstruct
   the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS
   Path on an OLD -> NEW BGP update session?
      No.

   Any other comments regarding the implementation
      No

References

   [ID.4ByteAS]
              Vohra, Q. and E. Chen, "BGP support for four-octet AS
              number space", Work in progress, Internet
              Draft: draft-ietf-idr-as4bytes-10.txt, July 2005.

Author

   Geoff Huston
   Asia Pacific Network Information Centre
   Email: [email-masked]
   URI:   http://www.apnic.net

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

To: "john smith" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
Date: Sun, 18 Sep 2005 22:30:52 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"john smith" writes:
>  
> Yes possibly i did,
>  
> i think it would help if someone could help clarify when exactly
> local_pref came into the picture.

Day one.  local_pref appeared in the internet-draft that was the basis
for the first versions of BGP4 from Cisco deployed in late fall of
1993 and the gated version deployed in the NSFHET in 1994.  That
internet-draft predated rfc1771.  local_pref has always been in
rfc1771 as well.

> I was wondering if the authors could help clarify the motivation of
> retaining path length.

If what you mean by "retaining path length" means using AS path length
in the decision process, this was to match widespread implementation
and deployment.  But I already said that a few messages back on this
thread.

Curtis

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

Date: Sun, 18 Sep 2005 19:05:23 -0400
To: "john smith" <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked]
Sender: [email-masked]

There are a set of decision items laid out in the I-D that will be the new 
BGP RFC.
These include, under certain circumstances, comparing the number of 
elements in the AS path.
If we had and were using the metric that was recently proposed, this would 
not be an issue.

Specifically, in section 9.1.2.2 if multiple routes have gotten this far 
then "Remove from consideration all routes which are not tied for having 
the smallest number of AS numbers present in the AS Path attributes.  Note 
that when counting this number, an AS_Set counts as 1, no matter how many 
ASs are in the set."

Given that the number of ASs (seqeunce elements or sets) can have a direct 
effect on the selection of routes, we don't want to break that criteria 
while allowing a router to use multiple routes.  And when such a router 
speaks to a non-ECMP router, we want the number of AS (as described above) 
to be the same as it would have had if ECMP had not been used.

Note that this text does not say to collapse adjacent AS Sets, but rather 
that each AS set counts as one AS for comparison purposes.

Yours,
Joel M. Halpern

At 04:49 PM 9/18/2005, john smith wrote:
>Yes possibly i did,
>
>i think it would help if someone could help clarify when exactly 
>local_pref came into the picture.
>
>I was wondering if the authors could help clarify the motivation of 
>retaining path length.
>
>
>>From: Curtis Villamizar <[email-masked]>
>>Reply-To: [email-masked]
>>To: "john smith" <[email-masked]>
>>CC: [email-masked], [email-masked]
>>Subject: Re: [Idr] Re: 4-Byte As Number soon to come? Date: Sat, 10 Sep 
>>2005 12:07:50 -0400
>>
>>In message <[email-masked]>
>>"john smith" writes:
>> >
>> > >
>> > >It was precisely to avoid such misleading effects that we introduced the
>> > >series of AS Sets.
>> > >
>> >
>> > then perhaps one of the authors would like to explain the arguments in 
>> this:
>> >
>> > http://www.merit.edu/mail.archives/idr/2004-09/msg00023.html
>> >
>> > :-)
>>
>>
>>That message was about weights and local-pref.  It appears to have
>>nothing to do with AS Sets.  Is it possible you got the URL wrong?
>>
>>Curtis
>
>_________________________________________________________________
>Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

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

To: "john smith" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
Date: Sat, 10 Sep 2005 12:07:50 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"john smith" writes:
>  
> >
> >It was precisely to avoid such misleading effects that we introduced the 
> >series of AS Sets.
> >
>  
> then perhaps one of the authors would like to explain the arguments in this:
>  
> http://www.merit.edu/mail.archives/idr/2004-09/msg00023.html
>  
> :-)

That message was about weights and local-pref.  It appears to have
nothing to do with AS Sets.  Is it possible you got the URL wrong?

Curtis

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

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Sat, 10 Sep 2005 11:09:52 +0000
Cc: [email-masked]
Sender: [email-masked]

>
>It was precisely to avoid such misleading effects that we introduced the 
>series of AS Sets.
>

then perhaps one of the authors would like to explain the arguments in this:

http://www.merit.edu/mail.archives/idr/2004-09/msg00023.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

Date: Sat, 10 Sep 2005 08:12:33 +0530
From: Glen Kent <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

--=======85384305=
Content-Type: multipart/alternative; 
	boundary="----=_Part_6676_4516227.1126320153688"

------=_Part_6676_4516227.1126320153688
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Curtis wrote:

 RFC 1771 does not have this tie breaking rule. The rule did not exist
> at all therefore it also didn't say how to count an AS_SET.

 Yes.

 There has always been clear concensus that we add this to match
> reality.
> 
> Counting all the AS in an AS_SET rather than just counting the set has
> always been considered to be "a bug" in implementations that do that.

 Isnt this *exactly* what *everybody* in this list is saying? Particularly 
the author(s) to whom you replied?
 I am amused as well curious now. Which email in this *entire* thread makes 
you think that the author thinks otherwise?
 Which is why, when you merge the SETs, you _can_ break what other people 
think from the path length. Decreasing the path length midway (by merging 
AS_SETs) IMO is a bad practise and nobody has any business doing this.
 And note, before anybody sparks a reply, I am not talking about a router 
thats doing aggregation, because that router is essentially originating a 
new prefix. I (like others) am talking of router that sits in the middle and 
suddenly decides to merge all the SETs to form one big SET before passing on 
the routes to its peer.
 Thanks
 -- 
Glen

------=_Part_6676_4516227.1126320153688
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>Curtis wrote:</div>
<div><br>&nbsp;</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">RFC 1771 does not have this tie breaking rule.&nbsp;&nbsp;The rule did not exist<br>at all therefore it also didn't say how to count an AS_SET.
</blockquote>
<div>&nbsp;</div>
<div>Yes.</div>
<div><br>&nbsp;</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">There has always been clear concensus that we add this to match<br>reality.<br><br>Counting all the AS in an AS_SET rather than just counting the set has
<br>always been considered to be &quot;a bug&quot; in implementations that do that.</blockquote>
<div>&nbsp;</div>
<div>Isnt this&nbsp;*exactly* what *everybody* in this list&nbsp;is saying? Particularly the author(s) to whom you replied?</div>
<div>&nbsp;</div>
<div>I am amused as well curious now. Which email in this *entire*&nbsp;thread makes you think that the author thinks otherwise?</div>
<div>&nbsp;</div>
<div>Which is why, when you merge the SETs, you _can_ break what other people think from&nbsp;the path length. Decreasing the path length midway (by merging AS_SETs) IMO is a bad practise and nobody has any business doing this.
</div>
<div>&nbsp;</div>
<div>And note, before anybody sparks a reply, I am not talking about a router thats doing aggregation, because that router is&nbsp;essentially originating a new prefix. I (like others) am talking of router that sits in the middle and suddenly decides to merge all the SETs to form one big SET before passing on the routes to its peer.
</div>
<div>&nbsp;</div>
<div>Thanks</div>
<div>&nbsp;</div>
<div>-- </div>
<div>Glen</div>
<div>&nbsp;</div>

------=_Part_6676_4516227.1126320153688--

--=======85384305=
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

--=======85384305=--

To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
Date: Fri, 09 Sep 2005 12:43:56 -0400
From: Curtis Villamizar <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Glen Kent writes:
>  
>  
> On 9/2/05, Curtis Villamizar <[email-masked]> wrote:
>  
> > 
> > Joel,
> > 
> > If memory serves me, AS-SETs were introduced for aggregation and AS
> > Path length wasn't in use yet. Cisco put AS Path length into their
> > implementation after rfc1771 and it became widely implemented even
> > though it differred from the spec. So we fixed the spec to match
> > running code, operational experience, and widespread deployment.
> > 
> Curtis,
>  What exactly was fixed in the spec to match the "running code, operational>  
> experience, and widespread deployment" ?
> Is it, allowing the BGP speaker to collapse multiple AS_SETs, or is it 
> counting multiple AS_SETs as 1? I dont think there is any running code that>  
> does any of the above. 
>  Are you sure we're not trying to "fix" something that aint yet broken?
>  Glen

In "9.1.2.2 Breaking Ties (Phase 2)" the following was added.

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set.

RFC 1771 does not have this tie breaking rule.  The rule did not exist
at all therefore it also didn't say how to count an AS_SET.

There has always been clear concensus that we add this to match
reality.

Counting all the AS in an AS_SET rather than just counting the set has
always been considered to be "a bug" in implementations that do that.

Curtis

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

From: "Debdas Dey" <[email-masked]>
To: <[email-masked]>
Date: Thu, 8 Sep 2005 16:27:28 +0530
Subject: [Idr] Idr] : 
Sender: [email-masked]

This is a multi-part message in MIME format.

--=======11235652=
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0094_01C5B492.341651B0"

This is a multi-part message in MIME format.

------=_NextPart_000_0094_01C5B492.341651B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

I am a new member of this group.

Can anybody please suggest about the software versions in Cisco (IOS) and Juniper (JUNOS) which implements following two drafts:

                1.    draft-ietf-idr-bgp-ext-communities-09.txt
                2.    draft-ietf-idr-dynamic-cap-07.txt

Thanks and regards,
debdas

==================================
Debdas Dey
Alumnus Software Ltd (www.alumnux.com)
Infinity, Tower-II, 2nd Floor,
Plot A3, Block GP, Sector V
Salt Lake City
Kolkata 700091
India
Phone : +91-33-23575626, +91-33-23575627, +91-33-23575628
             extn : 318
Fax : +91-33-23575268

------=_NextPart_000_0094_01C5B492.341651B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.3700.6699" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I am a new member of this group.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Can anybody please suggest about the&nbsp;software 
versions in Cisco (IOS) and Juniper (JUNOS) which implements following two 
drafts:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 1.&nbsp;&nbsp;&nbsp; 
draft-ietf-idr-bgp-ext-communities-09.txt</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 2.&nbsp;&nbsp;&nbsp; 
draft-ietf-idr-dynamic-cap-07.txt</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Thanks and regards,</FONT></DIV>
<DIV><FONT face=Arial size=2>debdas</FONT></DIV>
<DIV><FONT face=Arial size=2><BR>==================================<BR>Debdas 
Dey<BR>Alumnus Software Ltd (<A 
href="http://www.alumnux.com">www.alumnux.com</A>)<BR>Infinity, Tower-II, 2nd 
Floor,<BR>Plot A3, Block GP, Sector V<BR>Salt Lake City<BR>Kolkata 
700091<BR>India<BR>Phone : +91-33-23575626, +91-33-23575627, 
+91-33-23575628<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
extn : 318<BR>Fax : +91-33-23575268</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0094_01C5B492.341651B0--

--=======11235652=
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

--=======11235652=--

Date: Wed, 7 Sep 2005 22:55:45 +0530
From: Glen Kent <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Cc: "Joel M. Halpern" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

--=======18498199=
Content-Type: multipart/alternative; 
	boundary="----=_Part_21868_1342093.1126113945586"

------=_Part_21868_1342093.1126113945586
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 9/2/05, Curtis Villamizar <[email-masked]> wrote:

> 
> Joel,
> 
> If memory serves me, AS-SETs were introduced for aggregation and AS
> Path length wasn't in use yet. Cisco put AS Path length into their
> implementation after rfc1771 and it became widely implemented even
> though it differred from the spec. So we fixed the spec to match
> running code, operational experience, and widespread deployment.
> 
Curtis,
 What exactly was fixed in the spec to match the "running code, operational 
experience, and widespread deployment" ?
Is it, allowing the BGP speaker to collapse multiple AS_SETs, or is it 
counting multiple AS_SETs as 1? I dont think there is any running code that 
does any of the above. 
 Are you sure we're not trying to "fix" something that aint yet broken?
 Glen

------=_Part_21868_1342093.1126113945586
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<br>
<div><span class="gmail_quote">On 9/2/05, <b class="gmail_sendername">Curtis Villamizar</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Joel,<br><br>If memory serves me, AS-SETs were introduced for aggregation and AS<br>Path length wasn't in use yet.&nbsp;&nbsp;Cisco put AS Path length into their
<br>implementation after rfc1771 and it became widely implemented even<br>though it differred from the spec.&nbsp;&nbsp;So we fixed the spec to match<br>running code, operational experience, and widespread deployment.<br></blockquote>

<div>Curtis,</div>
<div>&nbsp;</div>
<div>What exactly was fixed in the spec to match the &quot;running code, operational experience, and widespread deployment&quot; ?</div>
<div>Is it, allowing the BGP speaker to collapse multiple AS_SETs, or is it counting&nbsp;multiple AS_SETs as 1? I dont think there is any running code that does any of the above. </div>
<div>&nbsp;</div>
<div>Are you sure we're not trying to &quot;fix&quot; something that aint yet broken?</div>
<div>&nbsp;</div>
<div>Glen</div>

------=_Part_21868_1342093.1126113945586--

--=======18498199=
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

--=======18498199=--

Content-class: urn:content-classes:message
Date: Wed, 7 Sep 2005 04:52:04 -0600
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [Idr] FW: 2 week Last call on draft-ietf-l3vpn-ospf-2547-04.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

--=======10259821=
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5B39A.2F7E0160"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5B39A.2F7E0160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Resending to get around mailer limit on copies. 

________________________________

From: Susan Hares 
Sent: Wednesday, September 07, 2005 6:47 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'
Subject: 2 week Last call on draft-ietf-l3vpn-ospf-2547-04.txt

This begins working group last call on draft-ietf-l3vpn-ospf-2547-04.

This last call is limited to the changes that Eric has made to the 

document (which are outlined in Eric's email below). The last call 

will end in two weeks (September 21st).

Please send any comments to the working group mailing list.

Thank-you,

Susan Hares and Yakov Rekhter 

(co-chairs, IDR) 

At 11:45 AM 8/29/2005 -0400, Eric Rosen wrote:

=================================================

> As a result of  AD  review,  significant changes have been made

> to the specification draft-ietf-l3vpn-ospf-2547.  These changes  can
be 

> seen in the latest version, draft -04.  It is believed that the draft
now

> corresponds to the implementations.

> The following issues were addressed as a result of the AD review.

> The spec was written so as to allow a single VRF to correspond to
multiple

> OSPF domains.  However, it did not make clear just which

> parameters and procedures are relative to a domain, and which are
relative to a VRF.

> This has  now been  cleared up.   However, doing so required extensive

> textual changes.

> There  are cases  where  BGP decides  to  put a  route into  the  

> VRF for a particular address prefix, and OSPF also decides to put a
route into

> the VRF for that same address prefix.  Of course, only one of these
can

> actually be used for  forwarding.  The original spec did not make it  

> adequately clear just how  a choice  between two such  routes would
be made.  This

> has been clarified.  In some cases,  the results will  be different
than  

> they would have been if the VPN were really a pure OSPF network.
These

> differences are now explained and their potential consequences pointed
out.

> The procedures for  forwarding data  traffic  on  a  sham link  

> have been clarified.  The procedures for sending OSPF control traffic
on a

> sham link have been clarified.  The role of the optional "sham link
endpoint

> address has been clarified.

> The procedures for  translating BGP-distributed  VPN-IPv4 routes

> into OSPF routes have been clarified.

> A discussion of NSSA routes has been  added.  Alex says it is not
detailed

> enough; any feedback in this area would be welcome.

> Due to the large number of changes,  Alex has asked for a new last

> call, and I expect the WG chairs to formally issue the last call
shortly.

------_=_NextPart_001_01C5B39A.2F7E0160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Resending to get around mailer limit on
copies. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> <st1:PersonName
w:st="on">Susan Hares</st1:PersonName> <br>
<b><span style='font-weight:bold'>Sent:</span></b> Wednesday, September 07,
2005 6:47 AM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]'<br>
<b><span style='font-weight:bold'>Cc:</span></b> '<st1:PersonName w:st="on">[email-masked]</st1:PersonName>';
'<st1:PersonName w:st="on">[email-masked]</st1:PersonName>'; [email-masked]';
[email-masked]'; '<st1:PersonName w:st="on">[email-masked]</st1:PersonName>';
[email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'<br>
<b><span style='font-weight:bold'>Subject:</span></b> 2 week Last call on
draft-ietf-l3vpn-ospf-2547-04.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>This begins working group
last call on draft-ietf-l3vpn-ospf-2547-04.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>This last call is limited to
the changes that Eric has made to the <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>document (which are outlined
in Eric's email below). The last call <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>will end in two weeks
(September 21st).<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>Please send any comments to
the working group mailing list.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>Thank-you,<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><st1:PersonName w:st="on"><font
 size=2 face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'>Susan
 Hares</span></font></st1:PersonName><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'> and <st1:PersonName w:st="on">Yakov
 Rekhter</st1:PersonName> <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>(co-chairs, IDR) <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>At 11:45 AM 8/29/2005 -0400,
Eric Rosen wrote:<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>=================================================<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; As a result of&nbsp;
AD&nbsp; review,&nbsp; significant changes have been made<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; to the specification
draft-ietf-l3vpn-ospf-2547.&nbsp; These changes&nbsp; can be <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; seen in the latest
version, draft -04.&nbsp; It is believed that the draft now<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; corresponds to the implementations.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; The following issues
were addressed as a result of the AD review.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; The spec was written so
as to allow a single VRF to correspond to multiple<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; OSPF domains.&nbsp;
However, it did not make clear just which<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; parameters and
procedures are relative to a domain, and which are relative to a VRF.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; This has&nbsp; now
been&nbsp; cleared up.&nbsp;&nbsp; However, doing so required extensive<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; textual changes.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; There&nbsp; are
cases&nbsp; where&nbsp; BGP decides&nbsp; to&nbsp; put a&nbsp; route into&nbsp;
the&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; VRF for a particular
address prefix, and OSPF also decides to put a route into<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; the VRF for that same
address prefix.&nbsp; Of course, only one of these can<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; actually be used
for&nbsp; forwarding.&nbsp; The original spec did not make it&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; adequately clear just
how&nbsp; a choice&nbsp; between two such&nbsp; routes would&nbsp; be
made.&nbsp; This<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; has been
clarified.&nbsp; In some cases,&nbsp; the results will&nbsp; be different
than&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; they would have been if
the VPN were really a pure OSPF network.&nbsp; These<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; differences are now
explained and their potential consequences pointed out.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt;<o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; The procedures
for&nbsp; forwarding data&nbsp; traffic&nbsp; on&nbsp; a&nbsp; sham link&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; have been
clarified.&nbsp; The procedures for sending OSPF control traffic&nbsp; on a<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; sham link have been
clarified.&nbsp; The role of the optional &quot;sham link endpoint<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; address has been
clarified.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; The procedures
for&nbsp; translating BGP-distributed&nbsp; VPN-IPv4 routes<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; into OSPF routes have
been clarified.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt;<o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; A discussion of NSSA
routes has been&nbsp; added.&nbsp; Alex says it is not detailed<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; enough; any feedback in
this area would be welcome.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; <o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; Due to the large number
of changes,&nbsp; Alex has asked for a new last<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&gt; call, and I expect the
WG chairs to formally issue the last call shortly.<o:p></o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C5B39A.2F7E0160--

--=======10259821=
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

--=======10259821=--

To: "Joel M. Halpern" <[email-masked]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
Date: Thu, 01 Sep 2005 15:01:50 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], Jeffrey Haas <[email-masked]>, Paul Jakma <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <6.2.1.2.0.20050831230250.02ee26b0@localhost>
"Joel M. Halpern" writes:
>  
> Given that path prepending is the primary (arguably the only) way for an 
> advertiser to express provider preference in a way visible to information 
> receivers, it seems that AS Path length is still our primary knob.
>  
> This would suggest that having routers along a path change the AS Path 
> length of advertisements they have (potentially shortening the length) 
> would be a very bad thing.
>  
> It was precisely to avoid such misleading effects that we introduced the 
> series of AS Sets.
>  
> Yours,
> Joel M. Halpern

Joel,

If memory serves me, AS-SETs were introduced for aggregation and AS
Path length wasn't in use yet.  Cisco put AS Path length into their
implementation after rfc1771 and it became widely implemented even
though it differred from the spec.  So we fixed the spec to match
running code, operational experience, and widespread deployment.

Curtis

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