Subject: 4 bytes ASs
From: Yakov Rekhter <[email-masked]>
To: [email-masked]
Date: Wed, 31 Jan 2001 06:47:09 -0800

Folks,

As we agreed at the last WG meeting, here is the document.

Yakov.
------- Forwarded Message

Date:    Wed, 31 Jan 2001 07:15:13 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-as4bytes-00.txt

- --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-00.txt
	Pages		: 7
	Date		: 30-Jan-01
	
Currently the Autonomous System number is encoded in BGP as a two-
octets field. This document describes extensions to BGP to carry the
Autonomous System number as a four-octets field.

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

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-00.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-00.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-00.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Date: Fri, 26 Jan 2001 17:20:41 -0500
From: Vijay Gill <[email-masked]>
To: ben abarbanel <[email-masked]>
Cc: <[email-masked]>
Subject: Re: BGP Imported Routes
Sender: [email-masked]

On Fri, 26 Jan 2001, ben abarbanel wrote:

> Found a case where one of the big router vendors when receiving imported
> STATIC, CONNECTED,  ISIS and OSPF routes into BGP. Not all types for the
> same route destination are kept in the BGP L-RIB. In fact when we
> removed the "redistribute STATIC" statement from the configuration. The
> other route types for the same destination did not magically appear in
> the BGP L-RIB table. After searching in the standard I did not see any
> mention of secondary or tertiary Imported routes into BGP criteria.  It

If this is what I think this is, then see advertise-inactive

/vijay

Date: Fri, 26 Jan 2001 17:03:50 -0500
From: ben abarbanel <[email-masked]>
To: [email-masked]
Subject: BGP Imported Routes
Sender: [email-masked]

Found a case where one of the big router vendors when receiving imported
STATIC, CONNECTED,  ISIS and OSPF routes into BGP. Not all types for the
same route destination are kept in the BGP L-RIB. In fact when we
removed the "redistribute STATIC" statement from the configuration. The
other route types for the same destination did not magically appear in
the BGP L-RIB table. After searching in the standard I did not see any
mention of secondary or tertiary Imported routes into BGP criteria.  It
seems to me that we could be faced with BGP not propagating Imported
route reachability information to its peers when redistirbution
configuration changes occur. Even though the current router still has
forwarding reachability with the other route types?

Anybody had experience with this?

Thanks,
Ben

From: Anoop Ghanwani <[email-masked]>
To: "'Venu V.'" <[email-masked]>, [email-masked]
Subject: RE: Immediate Next-Hop 
Date: Fri, 26 Jan 2001 01:34:56 -0800
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0877B.3EA2D5C0
Content-Type: text/plain;
	charset="iso-8859-1"

If a router doesn't do the BGP NEXT_HOP resolution 
before installing it in the Loc-RIB, it might install
a route whose NEXT_HOP is actually unreachable.
In other words, this protects the router from installing a 
route as an "active route" in those cases where it already knows 
that BGP NEXT_HOP, and therefore the route in question, 
is in fact not reachable.  

Likewise, when the immediate next hop changes, BGP needs to
find out if and how the BGP NEXT_HOP continues to be 
reachable.  If not, it should remove the route from its 
Loc-RIB and withdraw it from its peers.  

This process also ensures that less-preferred routes get
activated and installed in those cases where the best
route's NEXT_HOP is not reachable.

-Anoop

> -----Original Message-----
> From: Venu V. [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 4:21 AM
> To: [email-masked]
> Subject: Immediate Next-Hop 
> 
> 
> Hi All,
> 
> The RFC 1771 Section 9.1.2  says that
> 
> "The local speaker MUST determine the immediate
>    next hop to the address depicted by the NEXT_HOP attribute of the
>    selected route by performing a lookup in the IGP and 
> selecting one of
>    the possible paths in the IGP.  This immediate next hop 
> MUST be used
>    when installing the selected route in the Loc-RIB.  If the route to
>    the address depicted by the NEXT_HOP attribute changes 
> such that the
>    immediate next hop changes, route selection should be 
> recalculated as
>    specified above"
> 
> I have a question regarding this section, why does BGP needs 
> to get the
> Immediate next-hop for the NEXT_HOP attribute and install in LOC_RIB?
> 
> BGP can check if the NEXT-HOP is reachable by looking into 
> FIB and if the
> Immediate next-hop changes why is route selection needs to be 
> re-calculated?
> 
> 
> Thanks,
> Venu
> 
> 
> 

------_=_NextPart_001_01C0877B.3EA2D5C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Immediate Next-Hop </TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>If a router doesn't do the BGP NEXT_HOP resolution </FONT>
<BR><FONT SIZE=2>before installing it in the Loc-RIB, it might install</FONT>
<BR><FONT SIZE=2>a route whose NEXT_HOP is actually unreachable.</FONT>
<BR><FONT SIZE=2>In other words, this protects the router from installing a </FONT>
<BR><FONT SIZE=2>route as an &quot;active route&quot; in those cases where it already knows </FONT>
<BR><FONT SIZE=2>that BGP NEXT_HOP, and therefore the route in question, </FONT>
<BR><FONT SIZE=2>is in fact not reachable.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Likewise, when the immediate next hop changes, BGP needs to</FONT>
<BR><FONT SIZE=2>find out if and how the BGP NEXT_HOP continues to be </FONT>
<BR><FONT SIZE=2>reachable.&nbsp; If not, it should remove the route from its </FONT>
<BR><FONT SIZE=2>Loc-RIB and withdraw it from its peers.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>This process also ensures that less-preferred routes get</FONT>
<BR><FONT SIZE=2>activated and installed in those cases where the best</FONT>
<BR><FONT SIZE=2>route's NEXT_HOP is not reachable.</FONT>
</P>

<P><FONT SIZE=2>-Anoop</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Venu V. [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, January 24, 2001 4:21 AM</FONT>
<BR><FONT SIZE=2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Immediate Next-Hop </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi All,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The RFC 1771 Section 9.1.2&nbsp; says that</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &quot;The local speaker MUST determine the immediate</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; next hop to the address depicted by the NEXT_HOP attribute of the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; selected route by performing a lookup in the IGP and </FONT>
<BR><FONT SIZE=2>&gt; selecting one of</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the possible paths in the IGP.&nbsp; This immediate next hop </FONT>
<BR><FONT SIZE=2>&gt; MUST be used</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; when installing the selected route in the Loc-RIB.&nbsp; If the route to</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; the address depicted by the NEXT_HOP attribute changes </FONT>
<BR><FONT SIZE=2>&gt; such that the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; immediate next hop changes, route selection should be </FONT>
<BR><FONT SIZE=2>&gt; recalculated as</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; specified above&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I have a question regarding this section, why does BGP needs </FONT>
<BR><FONT SIZE=2>&gt; to get the</FONT>
<BR><FONT SIZE=2>&gt; Immediate next-hop for the NEXT_HOP attribute and install in LOC_RIB?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; BGP can check if the NEXT-HOP is reachable by looking into </FONT>
<BR><FONT SIZE=2>&gt; FIB and if the</FONT>
<BR><FONT SIZE=2>&gt; Immediate next-hop changes why is route selection needs to be </FONT>
<BR><FONT SIZE=2>&gt; re-calculated?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; Venu</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0877B.3EA2D5C0--

From: "Venu V." <[email-masked]>
To: [email-masked]
Subject: Immediate Next-Hop 
Date: Wed, 24 Jan 2001 07:21:21 -0500
Sender: [email-masked]

Hi All,

The RFC 1771 Section 9.1.2  says that

"The local speaker MUST determine the immediate
   next hop to the address depicted by the NEXT_HOP attribute of the
   selected route by performing a lookup in the IGP and selecting one of
   the possible paths in the IGP.  This immediate next hop MUST be used
   when installing the selected route in the Loc-RIB.  If the route to
   the address depicted by the NEXT_HOP attribute changes such that the
   immediate next hop changes, route selection should be recalculated as
   specified above"

I have a question regarding this section, why does BGP needs to get the
Immediate next-hop for the NEXT_HOP attribute and install in LOC_RIB?

BGP can check if the NEXT-HOP is reachable by looking into FIB and if the
Immediate next-hop changes why is route selection needs to be re-calculated?

Thanks,
Venu

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: BGP CIDR Aggregation 
Date: Fri, 19 Jan 2001 09:27:08 -0700
Sender: [email-masked]

> I have a query about what is the standard way of performing NLRI prefix
> aggregation in BGP. Can we aggregate two routes that have same network
> prefix or do we perform aggregation only when we have (More specific/ Less
> specific routes)

More specific, sure, less specific, unlikely...

>  For example, a route "11.1.253.160/27" exists in the LOC_RIB table. The BGP
> speaker received another route "11.1.253.180/27". How do we advertise the
> routes? 

It's unlikely you received an advertisement for 11.1.253.180/27 as 
it's an invalid aggregate per there are bits in the prefix outside
the mask 255.255.255.240.  If the new route was perhaps for, say, 
11.1.253.192/27, then you could consider some type of 
aggregation, perhaps 11.1.253.128/25, which is the smallest aggregate
that contains both prefixes.

> Do we advertise both the routes or aggregate both the routes into a single
> route "11.1.253.0/24" and advertise the route?  

This is more a matter of local policy than BGP protocol behavior.

> In the second case the aggregated route also represents prefixes 
> then the initial set of prefixes present in LOC_RIB.

If I parse this correctly, it's fine, so long as the local AS
has the authority to advertise the larger aggregate.  This could
be accomplished a number of ways (e.g., via 'dynamic' proxy 
aggregation, static configuration, etc..), and is again, more 
a matter of local policy than anything.

Some of the 'dynamic aggregation' stuff which you seem to allude
to is discussed under the AGGREGATOR and ATOMIC_AGGREGATE sections
of the BGP spec.

-danny 

From: "Venu V." <[email-masked]>
To: [email-masked]
Subject: BGP CIDR Aggregation
Date: Thu, 18 Jan 2001 09:15:33 -0500
Sender: [email-masked]

Hi All,

I have a query about what is the standard way of performing NLRI prefix
aggregation in BGP. Can we aggregate two routes that have same network
prefix or do we perform aggregation only when we have (More specific/ Less
specific routes)

 For example, a route "11.1.253.160/27" exists in the LOC_RIB table. The BGP
speaker received another route "11.1.253.180/27". How do we advertise the
routes? 

Do we advertise both the routes or aggregate both the routes into a single
route "11.1.253.0/24" and advertise the route?  In the second case the
aggregated route also represents prefixes then the initial set of prefixes
present in LOC_RIB.

Thanks,
Venu

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: BGP Route Oscillation 
Date: Mon, 15 Jan 2001 18:21:50 -0700
Sender: [email-masked]

> It is worth noting that neither of the loops you describe seem
> to occur when RFC 1771 route selection rules are used, but no mention
> in the draft is made of the route selection rules you are using to
> get those results.  Since you're really talking about the effect
> of the modified route selection rules in the current BGP4 draft
> it would probably be better to mention this explicitly.

I guess you're referring to the MED talk wrt comparing MEDs only 
between routes from the same neighboring AS?  I agree that some 
explicit explanation of route selection rules should be provided.

Of course, we're also planning to dicuss how this can occur 
with other attributes considered after MED (e.g., router id).

Anyways, thanks for the input, we'll try to be more explicit in
the next version of the draft.

-danny 

To: [email-masked]
Cc: [email-masked]
Subject: Re: BGP Route Oscillation 
Date: Mon, 15 Jan 2001 17:07:05 -0800
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]

Danny,

> I do understand your point though and we'll try to convey
> something of this nature in the next revision of the draft
> (which should provide more information in terms of the 
> general looping properities of BGP).

It is worth noting that neither of the loops you describe seem
to occur when RFC 1771 route selection rules are used, but no mention
in the draft is made of the route selection rules you are using to
get those results.  Since you're really talking about the effect
of the modified route selection rules in the current BGP4 draft
it would probably be better to mention this explicitly.

Dennis Ferguson

To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP Route Oscillation 
Date: Mon, 15 Jan 2001 19:16:12 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Danny McPherson writes:
> 
> > The latter rule was always used back when routing policy was
> > configured (usually this was done based on know topology 
>             ^^ at ANS :-)

At least someone got it right.  ;-)

> > distances
> > (from the routing registry) and relative capacity of private peerings
> > and peer networks to resolve other ties in topology distance or based
> > on the request of the destination origin AS or prefix owner).  
> 
> Though a minor observation would be that this requires
> per-prefix policies, as well as near intimate knowledge
> of other networks by the network operator.  I'm not aware
> of ANY [large] provider today that performs per-prefix
> policies on routes learned from peers and I don't think
> implicitly removing this dynamic portion of route selection 
> is a viable option in today's networks.  Then again, I could 
> be wrong...

It requires per border AS policy at the very minimum but that would
mean ASx would always be preferred to ASy regardless of the origin AS
or prefix.  Per origin AS policy wouldn't work because routes
sometimes get advertised with differing origin AS, particularly
aggregates.  A subset of per origin AS policy can be converted to
prefixes based on a routing registry, leaving the bulk of the
configuration based on per border AS.  The ability to use AS path
length plus a configured metric to set local_pref would also go a long
way toward solving this without heavy reliance on registries and per
prefix policy.  AS path lenght can be biased move heavily such that
per border AS policy only resolves ties in AS path length.

What we are talking about here is usage (on what basis do we set
local_pref).

> I do understand your point though and we'll try to convey
> something of this nature in the next revision of the draft
> (which should provide more information in terms of the 
> general looping properities of BGP).

The main point is that an available workaround is to using local_pref
so no two AS advertise a given prefix at the same local_pref solves
type II churn.

> Thanks!
> 
> -danny 

De Nada,

Curtis

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: BGP Route Oscillation 
Date: Mon, 15 Jan 2001 16:22:06 -0700
Sender: [email-masked]

> The latter rule was always used back when routing policy was
> configured (usually this was done based on know topology 
            ^^ at ANS :-)

> distances
> (from the routing registry) and relative capacity of private peerings
> and peer networks to resolve other ties in topology distance or based
> on the request of the destination origin AS or prefix owner).  

Though a minor observation would be that this requires
per-prefix policies, as well as near intimate knowledge
of other networks by the network operator.  I'm not aware
of ANY [large] provider today that performs per-prefix
policies on routes learned from peers and I don't think
implicitly removing this dynamic portion of route selection 
is a viable option in today's networks.  Then again, I could 
be wrong...

I do understand your point though and we'll try to convey
something of this nature in the next revision of the draft
(which should provide more information in terms of the 
general looping properities of BGP).

Thanks!

-danny 

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP Route Oscillation 
Date: Mon, 15 Jan 2001 18:02:15 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> Folks,
> 
> Any objections to the attached ? If yes, please send them to
> the list asap (within the next 5 days).
> 
> Yakov.

Yakov,

Minor correction in section 6.2.  I've included the text as it
currently exists in the draft.

  6.2. Potential Workarounds for Type II Churn

    1) Do not accept MEDs from peers (this may not be a feasible
       alternative).

    2) Utilize other BGP attributes higher in the decision process
       so that the BGP decision algorithm never reaches the MED
       step.  As this completely overrides MEDs, Option 1 may make
       more sense.

    3) Always compare BGP MEDs, regardless of whether or not they were
       obtained from a single AS.  This is probably a bad idea since
       MEDs may be derived in a number of ways, and are typically done
       so as a matter of operator-specific policy and largely a function
       of available metric space provided by the employed IGP.  As such,
       comparing MED values for a single prefix learned from multiple
       ASs is ill-advised.  This mostly defeats the purpose of MEDs;
       Option 1 may be a more viable alternative.

    4) Future drafts will propose other solutions for Type II Churn

You might be able to loosen the restriction in bullet 2.

    2) Utilize other BGP attributes higher in the decision process so
       that the BGP decision algorithm selects a single AS before it
       reaches the MED step.

For example, if local-pref were set based on the advertising AS, then
you first eliminated all routes except those in a single AS.  In the
example, router Re would pick either X or Y based on local-pref and
never change that selection.  

This leaves two simple workarounds for the two types of problems.

  Type I:  Make inter-cluster or inter-sub-AS link metrics higher than
           intra-cluster or intra-sub-AS metrics.

  Type II: Make route selections based on local pref assigned to
           advertising AS first and then used IGP cost and MED to make
           selection among routes from the same AS.

The latter rule was always used back when routing policy was
configured (usually this was done based on know topology distances
(from the routing registry) and relative capacity of private peerings
and peer networks to resolve other ties in topology distance or based
on the request of the destination origin AS or prefix owner).  When
this method fell out of favor, it created the opportunities for route
loops in networks using RR and/or confederations (all major networks).

Curtis

To: [email-masked]
Subject: BGP Route Oscillation
Date: Mon, 15 Jan 2001 11:47:11 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Any objections to the attached ? If yes, please send them to
the list asap (within the next 5 days).

Yakov.
------- Forwarded Message

Date:    Fri, 05 Jan 2001 12:38:48 -0700
From:    Danny McPherson <[email-masked]>
To:      [email-masked], [email-masked]
Subject: BGP Route Oscillation

I'd like to ask that the IDR WG accept this draft as a WG
item and encourage solutions proposals.

Thanks!

- -danny

- ------- Forwarded Message

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-mcpherson-bgp-route-oscillation-00.txt
Date: Thu, 04 Jan 2001 07:26:57 -0500

- - --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: BGP Persistent Route Oscillation Condition
	Author(s)	: D. McPherson, V. Gill, D. Walton, A. Retana
	Filename	: draft-mcpherson-bgp-route-oscillation-00.txt
	Pages		: 18
	Date		: 03-Jan-01
	
The Border Gateway Protocol (BGP) [1] is an inter-Autonomous System
routing protocol. The primary function of a BGP speaking system is to
exchange network reachability information with other BGP systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcpherson-bgp-route-oscillation-00.tx
t

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-mcpherson-bgp-route-oscillation-00.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-mcpherson-bgp-route-oscillation-00.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-mcpherson-bgp-route-oscillation-00.txt

- - --OtherAccess
Content-Type: Message/External-body;
	name="draft-mcpherson-bgp-route-oscillation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

- - --OtherAccess--

- - --NextPart--

- ------- End of Forwarded Message

------- End of Forwarded Message

To: [email-masked]
Subject: -12.txt of BGP4
Date: Thu, 11 Jan 2001 06:56:51 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The only changes in this version are (a) the version number,
(b) the dates, and (c) authors' information for myself.

Yakov.
------- Forwarded Message

Date:    Thu, 11 Jan 2001 07:27:13 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-12.txt

- --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		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter, T. Li
	Filename	: draft-ietf-idr-bgp4-12.txt
	Pages		: 60
	Date		: 10-Jan-01
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.  It is built on experience gained with EGP as
defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
described in RFC 1092 [2] and RFC 1093 [3].

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

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-bgp4-12.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-bgp4-12.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-bgp4-12.txt

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

From: Randy Bush <[email-masked]>
To: "Peter Lewis" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: MPLS World, February 6-9, Paris
Date: Wed, 10 Jan 2001 04:24:06 -0800
Sender: [email-masked]

> Looking Farther Ahead 

slime spammer finally stops polluting ietf mailing list with his scams?
that's what i would like to see ahead.

randy

From: "Peter Lewis" <[email-masked]>
To: <[email-masked]>
Subject: MPLS World, February 6-9, Paris
Date: Wed, 10 Jan 2001 12:47:13 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0276_01C07B03.745DDA40
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

=20
MPLS World, February 6-9, Paris.=20
=20
http://www.upperside.fr/congress/congress.htm
=20
With the challenges and uncertainties engendered by the development of =
the MPLS architecture, the MPLS World Conference is, in essence, an open =
platform for debate on the future of telecommunications networks.=20

Looking Farther Ahead=20

MPLS World is preoccupied with future developments, like using MPLS in =
the access network and in the LAN. MPLambdaS, MPLS/mobility convergence =
are addressed in papers never before given. MPLS is a unique occasion =
for participants to unveil their work and expose new ideas.=20
=20
The exhibition
=20
Already 20 exhibitors for this very first MPLS exhibition. Upper Side =
will fullfill his objectives. Vendors shouldn't miss the opportunity:
http://www.upperside.fr/congress/exhi.htm

------=_NextPart_000_0276_01C07B03.745DDA40
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>&nbsp;
<DIV><FONT size=3D2><STRONG>MPLS World</STRONG>, February 6-9, Paris.=20
</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/congress/congress.htm">http://www.uppersi=
de.fr/congress/congress.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3D"Arial, Helvetica, sans-serif" =
size=3D2>With the=20
challenges and uncertainties engendered by the development of the MPLS=20
architecture, the MPLS World Conference is, in essence, an open platform =
for=20
debate on the future of telecommunications networks.=20
<BR><BR></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Arial, Helvetica, sans-serif" =
size=3D2><B>Looking=20
Farther Ahead</B> <BR><BR>MPLS World is preoccupied with future =
developments,=20
like using MPLS in the access network and in the LAN. MPLambdaS, =
MPLS/mobility=20
convergence are addressed in papers never before given. MPLS is a unique =

occasion for participants to unveil their work and expose new ideas.=20
</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Arial, Helvetica, sans-serif"=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3D"Arial, Helvetica, sans-serif" =
size=3D2><STRONG>The=20
exhibition</STRONG></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Arial, Helvetica, sans-serif"=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3D"Arial, Helvetica, sans-serif" =
size=3D2>Already 20=20
exhibitors for this very first MPLS exhibition. Upper Side will fullfill =
his=20
objectives. Vendors shouldn't miss the opportunity:</FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT face=3D"Arial, Helvetica, sans-serif" =
size=3D2><A=20
href=3D"http://www.upperside.fr/congress/exhi.htm">http://www.upperside.f=
r/congress/exhi.htm</A></FONT></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0276_01C07B03.745DDA40--

Date: Mon, 8 Jan 2001 14:27:48 -0500
From: John Hawkinson <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Nominal feedback on draft-ramachandra-bgp-ext-communities-08.txt
Sender: [email-masked]

> > I was hoping to leave that to the authors. Presumably they've already 
> > implemented something in their implementations, right?
> 
> I just thought that you have any specific prefence. But documenting
> what is implemented would be fine with me too.

My larger concern is that different vendors may do different things,
and I'd like to prevent that.

> How about (X+1)= 0x4000 and (Y+1)=0x8000 ?

Fine by me, though I'd be more inclined to consider x+1=8000 and y+1=c000,
giving the largest chunk to the IANA-assigned "official" space rather than
to the private space.

> > But you choose not to address the complexity question ;-)
> 
> I'll try to address the question, once you'll elaborate a bit on what 
> is exactly so complex in ext communities ?

Well, we used to have communities where there was one level of
hierarchy, the AS. Now we introduce many levels of hierarchy,
including 2-byte ASes, 4-byte ASes, and IP addresses. And beyond that,
new formats can be defined with Types. I'm not really certain
what a legitimate use of a new community Type would be.

I'm not objecting, mind you, but I do think that the spec isn't
terribly clear on this, and so I wonder if we're adding much more
complexity than we need, and if we couldn't just get by with, say,
4-byte ASes and nothing else.

--jhawk

Date: Mon, 8 Jan 2001 14:10:54 -0500
From: John Hawkinson <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: Nominal feedback on draft-ramachandra-bgp-ext-communities-08.txt
Sender: [email-masked]

> > a) It might be nice if the draft specified a recommended display format
> > for these things, since things are liable to get confusing with 3+ different
> > ways to look at a given community.
> 
> Please propose one.

I was hoping to leave that to the authors. Presumably they've already implemented
something in their implementations, right?

> > b) It seems wrong to have types 0x8000-0xffff be
> > "vendor-specific". Shouldn't they be "site"-specific, or such? Vendors
> > should register their types with the IANA to prevent collisions in the
> > vendor space.
> 
> How about if we'll follow the approach used by multi-protocol
> extensions. That is,  type values 0 through X are to be
> assigned by IANA using the "IETF Consensus" policy defined in RFC
> 2434. Type values (X+1) through Y are to be assigned by IANA,
> using the "First Come First Served" policy defined in RFC 2434.
> Finally type values (Y+1) through 0xffff are for "private use",
> and values in this range are not to be assigned by IANA.

That sounds good to me. I don't have any strong opinions on what the
values of X and Y should be, it's not terribly clear to me what the
use of such Type extensions will be for. Perhaps the document would
benefit by examples. But you choose not to address the complexity
question ;-)

--jhawk

Date: Mon, 8 Jan 2001 13:34:06 -0500 (EST)
To: [email-masked]
Subject: Nominal feedback on draft-ramachandra-bgp-ext-communities-08.txt
From: John Hawkinson <[email-masked]>
Sender: [email-masked]

Hi.

    I finally got around to reading
draft-ramachandra-bgp-ext-communities-08.txt; I know it (and prior versions)
have been around for a while, but there doesn't seem to have been much feedback
on IDR (at least, I don't recall any and a casual perusal of the archives
doesn't show much).

    Three brief comments:

a) It might be nice if the draft specified a recommended display format
for these things, since things are liable to get confusing with 3+ different
ways to look at a given community.

b) It seems wrong to have types 0x8000-0xffff be
"vendor-specific". Shouldn't they be "site"-specific, or such? Vendors
should register their types with the IANA to prevent collisions in the
vendor space.

c) Boy, this seems a lot more complex than what we had, or than the
minimum necessary extension. Are we sure this complexity is all
warranted?

Thanks.

--jhawk

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: BGP Route Oscillation
Date: Sat, 06 Jan 2001 09:36:16 -0700
Sender: [email-masked]

I'd like to ask that the IDR WG accept this draft as a WG
item and encourage solutions proposals.

Thanks!

-danny

- ------- Forwarded Message

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-mcpherson-bgp-route-oscillation-00.txt
Date: Thu, 04 Jan 2001 07:26:57 -0500

- - --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: BGP Persistent Route Oscillation Condition
	Author(s)	: D. McPherson, V. Gill, D. Walton, A. Retana
	Filename	: draft-mcpherson-bgp-route-oscillation-00.txt
	Pages		: 18
	Date		: 03-Jan-01
	
The Border Gateway Protocol (BGP) [1] is an inter-Autonomous System
routing protocol. The primary function of a BGP speaking system is to
exchange network reachability information with other BGP systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mcpherson-bgp-route-oscillation-00.tx
t

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-mcpherson-bgp-route-oscillation-00.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-mcpherson-bgp-route-oscillation-00.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-mcpherson-bgp-route-oscillation-00.txt

- - --OtherAccess
Content-Type: Message/External-body;
	name="draft-mcpherson-bgp-route-oscillation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

- - --OtherAccess--

- - --NextPart--

- ------- End of Forwarded Message

Date: Sat, 6 Jan 2001 04:58:05 -0500 (EST)
From: Abha Ahuja <[email-masked]>
Reply-To: abha ahuja <[email-masked]>
To: [email-masked]
Subject: Posting to the IDR list
Sender: [email-masked]

Hey All!

Just an FYI...

I'm not sure if an announcement ever went out to the list, but we set this
up similar to the NANOG list... In order to post to idr, you need to be
subscribed to the idr-post list.  When this change was made, we
automatically subscribed the idr list that was current at the time.  If
you have problems posting (and are a recent subscriber), you should double
check that you are subscribed to idr-post.

Thanks!

-abha ;)

Date: Fri, 05 Jan 2001 17:52:00 -0500
From: Xavier Briard <[email-masked]>
Organization: Tenor Networks
To: Jaihari Loganathan <[email-masked]>
Cc: "'Alvaro Retana'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: well-known communities
Sender: [email-masked]

Yes, Jaihari this is more what I meant.

As an example node C originally advertises N to node B in the following
network:

A --- B --- C[N]
N  <- N  <-

B in turn advertises network N to node A.

Subsequently C is configured to send N with a NO_ADVERTISE community. My
question was "should B send an explicit withdraw for N to node A before
STOPPING advertising it?". And the consensus seems to say "yes".

Thanks
Xavier

Jaihari Loganathan wrote:
> 
> This won't be replacement right?
> New attribute info says don't send.
> Old one advised to send.
> 
> So no new path is sent.
> Old one is withdrawn.
> 
> -----Original Message-----
> From: Alvaro Retana [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 2:39 PM
> To: Xavier Briard
> Cc: [email-masked]
> Subject: Re: well-known communities
> 
> On Fri, 5 Jan 2001, Xavier Briard wrote:
> 
> Xavier:
> 
> -> RFC1997 specifies that routes received with NO_EXPORT, NO_ADVERTISE
> -> or NO_EXPORT_SUBCONFED "MUST NOT be advertised" to certain peers.
> ->
> -> Does this also imply that a BGP speaker should send an explicit
> -> Withdraw to those peers if it USED TO advertise those routes prior
> -> to receiving them with such a community?
> 
> Note that a way to withdraw a path is to send a replacement -- which is
> what you're doing here by sending a new one (different attribute
> information).
> 
> So...yes, the 'old' path should be withdrawn.
> 
> Alvaro.

Date: Fri, 5 Jan 2001 17:48:14 -0500 (EST)
From: Alvaro Retana <[email-masked]>
To: Jaihari Loganathan <[email-masked]>
Cc: Xavier Briard <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: well-known communities
Sender: [email-masked]

On Fri, 5 Jan 2001, Jaihari Loganathan wrote:

-> This won't be replacement right? New attribute info says don't send.
-> Old one advised to send.
-> 
-> So no new path is sent.
-> Old one is withdrawn.

-> -----Original Message-----
-> From: Alvaro Retana [mailto:[email-masked]]
...
-> So...yes, the 'old' path should be withdrawn.

Yes, that's what I meant. ;-)

Alvaro.

Date: Fri, 5 Jan 2001 17:38:56 -0500 (EST)
From: Alvaro Retana <[email-masked]>
To: Xavier Briard <[email-masked]>
Cc: [email-masked]
Subject: Re: well-known communities
Sender: [email-masked]

On Fri, 5 Jan 2001, Xavier Briard wrote:

Xavier:

-> RFC1997 specifies that routes received with NO_EXPORT, NO_ADVERTISE
-> or NO_EXPORT_SUBCONFED "MUST NOT be advertised" to certain peers.
-> 
-> Does this also imply that a BGP speaker should send an explicit
-> Withdraw to those peers if it USED TO advertise those routes prior
-> to receiving them with such a community?

Note that a way to withdraw a path is to send a replacement -- which is
what you're doing here by sending a new one (different attribute
information).

So...yes, the 'old' path should be withdrawn.

Alvaro.

Date: Fri, 05 Jan 2001 13:35:13 -0500
From: Xavier Briard <[email-masked]>
Organization: Tenor Networks
To: [email-masked]
Subject: well-known communities
Sender: [email-masked]

RFC1997 specifies that routes received with NO_EXPORT, NO_ADVERTISE or
NO_EXPORT_SUBCONFED "MUST NOT be advertised" to certain peers.

Does this also imply that a BGP speaker should send an explicit Withdraw
to those peers if it USED TO advertise those routes prior to receiving
them with such a community?

Is this a correct/common interpretation?

Thanks in advance,
Xavier

--
Xavier Briard           
Tenor Networks

To: "Rijsman, Bruno" <[email-masked]>
Cc: "'Robert Raszuk'" <[email-masked]>, Yakov Rekhter <[email-masked]>, "[email-masked]'" <[email-masked]>, "BGP exploder (E-mail)" <[email-masked]>, "IDRP exploder (E-mail)" <[email-masked]>
Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question 
Reply-To: [email-masked]
Date: Thu, 04 Jan 2001 11:24:42 -0500
From: Eric Rosen <[email-masked]>
Sender: [email-masked]

Right now the draft says:

        The Label  field carries one or more  labels (that corresponds
        to the  stack of labels [MPLS-ENCAPS]). Each  label is encoded
        as  3 octets,  where the  high-order bit  contains  "Bottom of
        Stack" (as defined in [MPLS-ENCAPS]). The following high-order
        three bits  must be  zero. The remaining  20 bits  contain the
        label value.

Barring objection, I will change this to:

        The Label  field carries one or more  labels (that corresponds
        to the  stack of labels [MPLS-ENCAPS]). Each  label is encoded
        as 3  octets, where the  high-order 20 bits contain  the label
        value,  the following  three bits  must be  zero, and  the low
        order  bit   contains  "Bottom   of  Stack"  (as   defined  in
        [MPLS-ENCAPS]).

and reissue the draft.

From: "Joris Dobbelsteen" <[email-masked]>
To: "6Bone (E-mail)" <[email-masked]>, "Enum WG (E-mail)" <[email-masked]>, "FTPEXT WG (E-mail)" <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>, "IPng WG (E-mail)" <[email-masked]>, "IPTel WG (E-mail)" <[email-masked]>, "Kerberos WG (E-mail)" <[email-masked]>, "Lynx-Dev (E-mail)" <[email-masked]>, "NAT WG (E-mail)" <[email-masked]>, "OSPF WG (E-mail)" <[email-masked]>, "WebDAV WG (E-mail)" <[email-masked]>, "WREC WG (E-mail)" <[email-masked]>, "WWW WG (E-mail)" <[email-masked]>
Subject: Happy new year
Date: Mon, 1 Jan 2001 16:01:04 +0100
Importance: Normal
Sender: [email-masked]

To all WGs I'm subscribed to, nobody does it, so I'll just send it:

Happy new year and a good start of the new millennium

Hope I can say this for all members of the WGs...

- Joris