Subject: Multi Protocol Extensions to Draft Standard
From: Yakov Rekhter <[email-masked]>
To: [email-masked]
Date: Sun, 28 Nov 1999 06:03:13 -0800

Folks,

I'd like to start WG Last Call on advancing 
draft-ietf-idr-bgp4-multiprotocol-v2-03.txt
to Draft Standard.

The Last Call ends Dec 12, 1999.

Yakov.     

Date: Sun, 21 Nov 1999 10:32:57 +0200
To: [email-masked]
From: Hank Nussbacher <[email-masked]>
Subject: BGP global community strings
Sender: [email-masked]

The various comments and corrections to the initial text has been merged
into the text and can be found at:

http://www.ibm.net.il/~hank/bgp-glob-comm.txt

Comments and corrections can easily be spotted by the '|' mark in column 1
of any changed line.  

Is there interest in advancing this as a BCP I-D?

Thanks,
Hank

Date: Thu, 18 Nov 1999 16:30:17 -0800
From: Manoj Goyal <[email-masked]>
To: idr <[email-masked]>, ospf <[email-masked]>, zebra <[email-masked]>, gated <[email-masked]>
Subject: simulation of multiple routers on single machine
Sender: [email-masked]

Hi everybody,
I have a single box/machine that is supposed to
get connected to more than one ISP and enterprises.
I have to simulate multiple routers on that so that
every enterprise/ISP can configure his/her router part
without affecting other networks.
I am sorry but I don't know where else should I
post such queries:
I could not find any references on this topic,
some of you on these lists, please help me.
thanks in advance
- Manoj

To: [email-masked]
Cc: Bora Akyol <[email-masked]>, [email-masked]
Subject: Re: draft-chen-bgp-route-refresh-01.txt 
Date: Wed, 17 Nov 1999 13:46:17 -0500
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

On Thu, 11 Nov 1999 17:36:35 -0700 [email-masked] writes:
=>
=>
=>> If I read this correctly, this is a good step towards finally making BGP
=>> fault-tolerant.
=>
=>I think it's more of a step towards increasing stability (rather than 
=>introduce fault tolerance) by reducing the amount of route oscillation 
=>associated with new policy application.  Used to be that it required a BGP 
=>connection reset or "bouncing" the concerned route(s) to trigger 
=>re-advertisement so that a new policy set could be applied.  Route refresh is
> 
=>certainly better than consuming tons of memory (if/where you care) with 
=>soft-reconfiguration gunk in order to avoid this.
=>
=>> By the way, is there any chance that we can combine this ID with the IBB
=>> extension and
=>> have a complete mechanism for assuring that drop of a TCP connection or
=>> failure of a BGP thread
=>> does not hurt a BGP session. What does the WG think of such an idea.
=>
=>Seems to me they're completely separate things and that a lot more IGP intera
>ction stuff will need to be hashed out before the the IBB stuff will work.  IM
>O, they defintiely should not be combined.

I agree. Over the summer, I and colleague looked at IBB/similar capabilities
for OSPF. Depending on which cases you want to cover (software upgrade to
crash and transient loops to completely loop free), this can be a pretty
hairy problem requiring a careful organization of the solution.

My $.02,
--rohit.

To: Bora Akyol <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: draft-chen-bgp-route-refresh-01.txt 
Date: Thu, 11 Nov 1999 17:36:35 -0700
Sender: [email-masked]

> If I read this correctly, this is a good step towards finally making BGP
> fault-tolerant.

I think it's more of a step towards increasing stability (rather than 
introduce fault tolerance) by reducing the amount of route oscillation 
associated with new policy application.  Used to be that it required a BGP 
connection reset or "bouncing" the concerned route(s) to trigger 
re-advertisement so that a new policy set could be applied.  Route refresh is 
certainly better than consuming tons of memory (if/where you care) with 
soft-reconfiguration gunk in order to avoid this.

> By the way, is there any chance that we can combine this ID with the IBB
> extension and
> have a complete mechanism for assuring that drop of a TCP connection or
> failure of a BGP thread
> does not hurt a BGP session. What does the WG think of such an idea.

Seems to me they're completely separate things and that a lot more IGP interaction stuff will need to be hashed out before the the IBB stuff will work.  IMO, they defintiely should not be combined.

-danny

From: Bora Akyol <[email-masked]>
To: "'Enke Chen'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: draft-chen-bgp-route-refresh-01.txt
Date: Thu, 11 Nov 1999 09:21:06 -0800
Sender: [email-masked]

If I read this correctly, this is a good step towards finally making BGP
fault-tolerant.

By the way, is there any chance that we can combine this ID with the IBB
extension and
have a complete mechanism for assuring that drop of a TCP connection or
failure of a BGP thread
does not hurt a BGP session. What does the WG think of such an idea.

Regards

Bora Akyol
Pluris (http://www.pluris.com)

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Wednesday, November 10, 1999 11:24 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: draft-chen-bgp-route-refresh-01.txt

Hi, folks:
I would like to request that the route refresh draft
(draft-chen-bgp-route-refresh-01.txt) be considered
as an IDR Working Group document.

Thanks.  -- Enke

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: draft-chen-bgp-route-refresh-01.txt
Date: Wed, 10 Nov 1999 23:24:02 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
I would like to request that the route refresh draft
(draft-chen-bgp-route-refresh-01.txt) be considered
as an IDR Working Group document.

Thanks.  -- Enke

To: [email-masked]
Subject: WG Last Call
Date: Wed, 10 Nov 1999 14:59:35 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

I'd like to start WG Last Call on advancing draft-ietf-idr-bgp4-cap-neg-04.txt 
to a Proposed Standard.

The Last Call ends Nov 25, 1999.

Yakov.

Date: Wed, 10 Nov 1999 15:13:55 -0500 (EST)
From: <[email-masked]>
To: [email-masked]
Subject: Calling all mib implementations
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Could anyone who has implemented the 

draft-ietf-idr-bgp4-mib-04.txt 

Please contact me.  I'm completing the implementation report
for the mib so we can move the mib forward on the standards
track.

Sue

To: "Rijsman, Bruno" <[email-masked]>
Cc: Hua Kuang <[email-masked]>, BGP exploder <[email-masked]>
Subject: Re: RFC-2283 question 
Date: Tue, 09 Nov 1999 10:15:42 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

> Hua> MP_(UN)REACH_NLRI are path attributes, in RFC1771 and the later 
> Hua> BGP4 drafts, each path attribute contains a triple <type, length,
> value>,  
> Hua> this "length" here should be enough to hold the NLRIs information.
> 
> Hua,
> 
> This works fine if an MP_REACH_NLRI attribute only contains a single triple 
> <Address Family Information, Next Hop Information, Network Layer
> Reachability Information>

[clipped...]

> However, if there are multiple triples per MP_REACH_NLRI attributes (as
> allowed by RFC 2283 but not by DRAFT draft-ietf-idr-bgp-multiprotocol-v2-03) 
> there is no way to figure out how many prefixes there are in each triple:

That is precisely why the draft allows only one address family per attribute.

Yakov.

From: "Rijsman, Bruno" <[email-masked]>
To: Hua Kuang <[email-masked]>
Cc: BGP exploder <[email-masked]>
Subject: RE: RFC-2283 question
Date: Tue, 9 Nov 1999 12:31:30 -0500 
Sender: [email-masked]

Hua> MP_(UN)REACH_NLRI are path attributes, in RFC1771 and the later 
Hua> BGP4 drafts, each path attribute contains a triple <type, length,
value>,  
Hua> this "length" here should be enough to hold the NLRIs information.

Hua,

This works fine if an MP_REACH_NLRI attribute only contains a single triple 
<Address Family Information, Next Hop Information, Network Layer
Reachability Information>

+----------------------------+
| 14 (MP_REACH_NLRI)         | Path Attribute Type Code
+----------------------------+
| LEN                        | Path Attribute Length 
+----------------------------+ ........................
| 1 (IPv4)                   | AFI           ^       ^
+----------------------------+               | 9     | LEN
| 2 (multicast)              | SAFI          |       |
+----------------------------+               |       |
| 4                          | Next Hop Len  |       |
+----------------------------+               |       |
| 5.6.7.8                    | Next Hop      |       |
+----------------------------+               |       |
| 0                          | Nr of NSPAs   v       |
+----------------------------+..................     |
| 2.2.1.0 / 24               |   ^                   |
| 2.2.2.0 / 24               |   | LEN - 9           |
| 2.2.3.0 / 24               |   v                   v
+----------------------------+.........................

However, if there are multiple triples per MP_REACH_NLRI attributes (as
allowed by
RFC 2283 but not by DRAFT draft-ietf-idr-bgp-multiprotocol-v2-03) there is
no way
to figure out how many prefixes there are in each triple:

+----------------------------+
| 14 (MP_REACH_NLRI)         | Path Attribute Type Code
+----------------------------+
| LEN                        | Path Attribute Length 
+----------------------------+ ........................
| 1 (IPv4)                   | AFI           ^       ^
+----------------------------+               | ???   | LEN
| 1 (unicast)                | SAFI          |       |
+----------------------------+               |       |
| 4                          | Next Hop Len  |       |
+----------------------------+               |       |
| 1.2.3.4                    | Next Hop      |       |
+----------------------------+               |       |
| 0                          | Nr of NSPAs   |       |
+----------------------------+.....          |       |
| 1.1.1.0 / 24               |   ^           |       |
| 1.1.2.0 / 24               |   | ???       |       |
| 1.1.3.0 / 24               |   v           v       |
+----------------------------+.................      |
| 1 (IPv4)                   | AFI           ^       |
+----------------------------+               | ???   |
| 2 (multicast)              | SAFI          |       |
+----------------------------+               |       |
| 4                          | Next Hop Len  |       |
+----------------------------+               |       |
| 5.6.7.8                    | Next Hop      |       |
+----------------------------+               |       |
| 0                          | Nr of NSPAs   |       |
+----------------------------+.....          |       |
| 2.2.1.0 / 24               |   ^           |       |
| 2.2.2.0 / 24               |   | ???       |       |
| 2.2.3.0 / 24               |   v           v       v
+----------------------------+.........................

Bruno.

-----Original Message-----
From: Hua Kuang [mailto:[email-masked]]
Sent: Tuesday, November 09, 1999 12:08 PM
To: Rijsman, Bruno
Cc: BGP exploder
Subject: Re: RFC-2283 question

Bruno,

MP_(UN)REACH_NLRI
are path attributes,  in RFC1771 and the later BGP4 drafts,
each path attribute contains a triple
< type, length, value>,  this "length" here should be
enough to hold the NLRIs information.

Hua

"Rijsman, Bruno" wrote:

> RFC-2283 contains the following paragraph (which was not present in
> draft-ietf-idr-bgp4-multiprotocol-v2-03.txt) at the bottom of page 2:
>
> The [MP_REACH_NLRI] attribute contains ONE OR MORE triples <Address Family
> Information, Next Hop Information, Network Layer Reachability
Information>,
> ..."
>
> The encoding of the MP_REACH_NLRI attribute contains fields for
> * length of the next hop network address,
> * the number of SNPAs
> * the length of each SNPA
> * the length of each prefix
>
> However, the encoding of the MP_REACH_NLRI attribute does NOT contain a
> field for the number of prefixes (i.e. the number of prefixes and hence
the
> total length of the NLRI field is implicit).
>
> My question is: if the MP_REACH_NLRI contains MORE THAN ONE triple
<Address
> Family Information, Next Hop Information, Network Layer Reachability
> Information>, how do I know where one triple ends and the next begins? In
> other words, how can I find out what the number of prefixes is in a given
> triple?
>
> It seems to me that in the absence of a "number of prefixes" field, we can
> only have ONE triple per MP_REACH_NLRI attribute and therefor only ONE
type
> of NLRI (i.e. address family) per UPDATE message (since dupplicate
> attributes are not allowed). Either that or we must include a "number of
> prefixes" field in the MP_REACH_NLRI attribute...
>
> Bruno Rijsman
> Unisphere Solutions

Subject: Re: Private draft submission
To: "Alex P. Rudnev" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked]
Date: Tue, 9 Nov 1999 14:49:27 +0100
Sender: [email-masked]

Alex,

I have an URL for the last one:

http://www.co.rnp.br/documentos/draft-ietf-idr-symm-multi-prov-02.txt

but I am also intersted in the first two ones!!
I tried to find them but no way :-(

--Mike

---------------------------------------------------------------------------
Mike Portworsnick        Network Engineer
AnyWeb AG           CCIE# 4985
Switzerland              [email-masked]
---------------------------------------------------------------------------

                                                                                                                       
                    "Alex P. Rudnev"                                                                                   
                    <[email-masked]        To:     Ben Black <[email-masked]>                                      
                    om.eu.net>               cc:     Vijay Gill <[email-masked]>, Paul Traina <[email-masked]>,    
                    Sent by:                 [email-masked], [email-masked]                                     
                    [email-masked]        Subject:     Re: Private draft submission                                 
                    du                                                                                                 

                    11/09/99 02:29 PM                                                                                  

Ben, have you found this already?

On Fri, 5 Nov 1999, Ben Black wrote:

> Date: Fri, 5 Nov 1999 20:04:45 -0800
> From: Ben Black <[email-masked]>
> To: Vijay Gill <[email-masked]>
> Cc: Paul Traina <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: Private draft submission
>
> Anyone have copies of the DPA drafts around?
>
> Destination Preference Attribute for BGP
>         <draft-ietf-idr-bgp-dpa-05.txt>
>
> Application of the BGP Destination Preference Attribute in Implementing
> Symmetric Routing
>         <draft-ietf-idr-dpa-application-02.txt>
>
> Current Practice of Implementing Symmetric Routing and Load Sharing in
the
> Multi-Provider Internet
>         <draft-ietf-idr-symm-multi-prov-02.txt>
>
> They may offer an option which can be implemented entirely within the
> existing framework.
>
> On Thu, Nov 04, 1999 at 02:55:20PM -0500, Vijay Gill wrote:
> > On Thu, 4 Nov 1999, Paul Traina wrote:
> >
> > > Simple facts of life wrt. bgp metrics:
> > >
> > > (a) we don't change the tie breaking algorithm
> > > (b) any "metric" is taken as advisory, and said metric
> > >     should become a modifier to the LOCAL_PREF attribute
> > >     generated by the ingress router to an AS.
> > >
> > >
> > > So, if we were to do Vadim's old proposal of a vector of preference
> > > metrics, we'd get:
> > >
> > >     LOCAL_PREF += SUM(k1p1, k2p2, k3p3, k4p4, k5p5)
> > >
> > > where the Ks are scaler multipliers looked up in a table based upon
> > > AS number's.
> > >
> > > The big thing to realize is that all of this stuff just changes
> > > local_pref.  Changing the tie breaking logic at this point is
> > > insanity.
> >
> > No one is disagreeing on that one.
> >
> > We just need to push something that is workable and consisent and I
think
> > vadim's draft is about as useful as anything I've seen in here. Thats
for
> > sure.
> >
> > /vijay
> >
> >
>
> --
>  --b
>
>
>

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41,
N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

Date: Tue, 9 Nov 1999 16:29:16 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: Ben Black <[email-masked]>
Cc: Vijay Gill <[email-masked]>, Paul Traina <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Private draft submission
Organization: Relcom Corp.
Sender: [email-masked]

Ben, have you found this already?

On Fri, 5 Nov 1999, Ben Black wrote:

> Date: Fri, 5 Nov 1999 20:04:45 -0800
> From: Ben Black <[email-masked]>
> To: Vijay Gill <[email-masked]>
> Cc: Paul Traina <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: Private draft submission
> 
> Anyone have copies of the DPA drafts around?
> 
> Destination Preference Attribute for BGP
>         <draft-ietf-idr-bgp-dpa-05.txt>
> 
> Application of the BGP Destination Preference Attribute in Implementing
> Symmetric Routing
>         <draft-ietf-idr-dpa-application-02.txt>
> 
> Current Practice of Implementing Symmetric Routing and Load Sharing in the
> Multi-Provider Internet
>         <draft-ietf-idr-symm-multi-prov-02.txt>
> 
> They may offer an option which can be implemented entirely within the
> existing framework.
> 
> On Thu, Nov 04, 1999 at 02:55:20PM -0500, Vijay Gill wrote:
> > On Thu, 4 Nov 1999, Paul Traina wrote:
> > 
> > > Simple facts of life wrt. bgp metrics:
> > > 
> > > (a) we don't change the tie breaking algorithm
> > > (b) any "metric" is taken as advisory, and said metric
> > >     should become a modifier to the LOCAL_PREF attribute
> > >     generated by the ingress router to an AS.
> > > 
> > > 
> > > So, if we were to do Vadim's old proposal of a vector of preference
> > > metrics, we'd get:
> > > 
> > > 	LOCAL_PREF += SUM(k1p1, k2p2, k3p3, k4p4, k5p5)
> > > 
> > > where the Ks are scaler multipliers looked up in a table based upon
> > > AS number's.
> > > 
> > > The big thing to realize is that all of this stuff just changes
> > > local_pref.  Changing the tie breaking logic at this point is
> > > insanity.
> > 
> > No one is disagreeing on that one.
> > 
> > We just need to push something that is workable and consisent and I think
> > vadim's draft is about as useful as anything I've seen in here. Thats for
> > sure. 
> > 
> > /vijay
> > 
> > 
> 
> -- 
>  --b
> 
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

From: "Rijsman, Bruno" <[email-masked]>
To: BGP exploder <[email-masked]>
Subject: RFC-2283 question
Date: Mon, 8 Nov 1999 17:14:52 -0500 
Sender: [email-masked]

RFC-2283 contains the following paragraph (which was not present in
draft-ietf-idr-bgp4-multiprotocol-v2-03.txt) at the bottom of page 2: 

The [MP_REACH_NLRI] attribute contains ONE OR MORE triples <Address Family
Information, Next Hop Information, Network Layer Reachability Information>,
..."

The encoding of the MP_REACH_NLRI attribute contains fields for 
* length of the next hop network address, 
* the number of SNPAs
* the length of each SNPA
* the length of each prefix

However, the encoding of the MP_REACH_NLRI attribute does NOT contain a
field for the number of prefixes (i.e. the number of prefixes and hence the
total length of the NLRI field is implicit).

My question is: if the MP_REACH_NLRI contains MORE THAN ONE triple <Address
Family Information, Next Hop Information, Network Layer Reachability
Information>, how do I know where one triple ends and the next begins? In
other words, how can I find out what the number of prefixes is in a given
triple?

It seems to me that in the absence of a "number of prefixes" field, we can
only have ONE triple per MP_REACH_NLRI attribute and therefor only ONE type
of NLRI (i.e. address family) per UPDATE message (since dupplicate
attributes are not allowed). Either that or we must include a "number of
prefixes" field in the MP_REACH_NLRI attribute...

Bruno Rijsman
Unisphere Solutions

Date: Mon, 08 Nov 1999 11:02:44 -0800
From: Manoj Goyal <[email-masked]>
Subject: Virtual Routing
Sender: [email-masked]

Hi everybody,
can somebody provide me with docs/links about virtual
routing usually used in VPN.
I think virtual routing will not affect the 
ptotocols such as OSPF. Am I wrong?
Any help will be appreciated,
thanks
-Manoj

Date: Sat, 6 Nov 1999 20:38:28 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: Ben Black <[email-masked]>
Cc: Vijay Gill <[email-masked]>, Paul Traina <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Private draft submission
Organization: Relcom Corp.
Sender: [email-masked]

An attractive list... but where to get this drafts?

PS. Btw, the idea of community filtering is not dead, there is the draft about
it. 

On Fri, 5 Nov 1999, Ben Black wrote:

> Date: Fri, 5 Nov 1999 20:04:45 -0800
> From: Ben Black <[email-masked]>
> To: Vijay Gill <[email-masked]>
> Cc: Paul Traina <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: Private draft submission
> 
> Anyone have copies of the DPA drafts around?
> 
> Destination Preference Attribute for BGP
>         <draft-ietf-idr-bgp-dpa-05.txt>
> 
> Application of the BGP Destination Preference Attribute in Implementing
> Symmetric Routing
>         <draft-ietf-idr-dpa-application-02.txt>
> 
> Current Practice of Implementing Symmetric Routing and Load Sharing in the
> Multi-Provider Internet
>         <draft-ietf-idr-symm-multi-prov-02.txt>
> 
> They may offer an option which can be implemented entirely within the
> existing framework.
> 
> On Thu, Nov 04, 1999 at 02:55:20PM -0500, Vijay Gill wrote:
> > On Thu, 4 Nov 1999, Paul Traina wrote:
> > 
> > > Simple facts of life wrt. bgp metrics:
> > > 
> > > (a) we don't change the tie breaking algorithm
> > > (b) any "metric" is taken as advisory, and said metric
> > >     should become a modifier to the LOCAL_PREF attribute
> > >     generated by the ingress router to an AS.
> > > 
> > > 
> > > So, if we were to do Vadim's old proposal of a vector of preference
> > > metrics, we'd get:
> > > 
> > > 	LOCAL_PREF += SUM(k1p1, k2p2, k3p3, k4p4, k5p5)
> > > 
> > > where the Ks are scaler multipliers looked up in a table based upon
> > > AS number's.
> > > 
> > > The big thing to realize is that all of this stuff just changes
> > > local_pref.  Changing the tie breaking logic at this point is
> > > insanity.
> > 
> > No one is disagreeing on that one.
> > 
> > We just need to push something that is workable and consisent and I think
> > vadim's draft is about as useful as anything I've seen in here. Thats for
> > sure. 
> > 
> > /vijay
> > 
> > 
> 
> -- 
>  --b
> 
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

Date: Fri, 5 Nov 1999 20:04:45 -0800
From: Ben Black <[email-masked]>
To: Vijay Gill <[email-masked]>
Cc: Paul Traina <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

Anyone have copies of the DPA drafts around?

Destination Preference Attribute for BGP
        <draft-ietf-idr-bgp-dpa-05.txt>

Application of the BGP Destination Preference Attribute in Implementing
Symmetric Routing
        <draft-ietf-idr-dpa-application-02.txt>

Current Practice of Implementing Symmetric Routing and Load Sharing in the
Multi-Provider Internet
        <draft-ietf-idr-symm-multi-prov-02.txt>

They may offer an option which can be implemented entirely within the
existing framework.

On Thu, Nov 04, 1999 at 02:55:20PM -0500, Vijay Gill wrote:
> On Thu, 4 Nov 1999, Paul Traina wrote:
> 
> > Simple facts of life wrt. bgp metrics:
> > 
> > (a) we don't change the tie breaking algorithm
> > (b) any "metric" is taken as advisory, and said metric
> >     should become a modifier to the LOCAL_PREF attribute
> >     generated by the ingress router to an AS.
> > 
> > 
> > So, if we were to do Vadim's old proposal of a vector of preference
> > metrics, we'd get:
> > 
> > 	LOCAL_PREF += SUM(k1p1, k2p2, k3p3, k4p4, k5p5)
> > 
> > where the Ks are scaler multipliers looked up in a table based upon
> > AS number's.
> > 
> > The big thing to realize is that all of this stuff just changes
> > local_pref.  Changing the tie breaking logic at this point is
> > insanity.
> 
> No one is disagreeing on that one.
> 
> We just need to push something that is workable and consisent and I think
> vadim's draft is about as useful as anything I've seen in here. Thats for
> sure. 
> 
> /vijay
> 
> 

-- 
 --b

Date: Thu, 4 Nov 1999 14:55:20 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: Paul Traina <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

On Thu, 4 Nov 1999, Paul Traina wrote:

> Simple facts of life wrt. bgp metrics:
> 
> (a) we don't change the tie breaking algorithm
> (b) any "metric" is taken as advisory, and said metric
>     should become a modifier to the LOCAL_PREF attribute
>     generated by the ingress router to an AS.
> 
> 
> So, if we were to do Vadim's old proposal of a vector of preference
> metrics, we'd get:
> 
> 	LOCAL_PREF += SUM(k1p1, k2p2, k3p3, k4p4, k5p5)
> 
> where the Ks are scaler multipliers looked up in a table based upon
> AS number's.
> 
> The big thing to realize is that all of this stuff just changes
> local_pref.  Changing the tie breaking logic at this point is
> insanity.

No one is disagreeing on that one.

We just need to push something that is workable and consisent and I think
vadim's draft is about as useful as anything I've seen in here. Thats for
sure. 

/vijay

Date: Wed, 03 Nov 1999 18:36:25 -0500
From: Ben Abarbanel <[email-masked]>
To: Ben Black <[email-masked]>
Cc: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

But if you turn off the AS-path length, then what happens to the "kludge" of
putting multiple SAME AS numbers in the AS-path to force a better route
selection?

Thanks from another,
Ben

Ben Black wrote:

> Nobody suggested turning off the AS_PATH attribute.  What was suggested
> was turning off AS_PATH *length* as a path selection metric.
>
> On Wed, Nov 03, 1999 at 02:45:40PM -0700, Danny McPherson wrote:
> >
> > Hence the comment someways back which stated turning it off would be a bad
> > idea...
> >
> > -danny
> >
> > > The former is the first item listed.  That item is not part of the BGP
> > > path selection algorithm on any router I have ever used.  As I stated
> > > in a previous post, that AS_PATH is a loop avoidance mechanism.  Without
> > > it, loops are practically unavoidable.
> > >
> >
>
> --
>  --b

Date: Wed, 3 Nov 1999 18:24:09 -0500
From: Dorian Kim <[email-masked]>
To: Vijay Gill <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Private draft submission
Mail-Followup-To: Vijay Gill <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Nov 03, 1999 at 06:08:13PM -0500, Dorian Kim wrote:
> On Wed, Nov 03, 1999 at 04:57:51PM -0500, Vijay Gill wrote:
> > Re: http://www.kotovnik.com/~avg/old_page/draft-bgpmetric.txt
> > 
> > The only way to do this right is to do it again from the ground up for a
> > source preference metric, among other things.  This hellbrew of
> > communities that are being hashed out here need to go.  They are about as
> > useful as the as-path padding metric to influence traffic with the
> > exception that the overwhelming majority of the internet supports as
> > padding _today_.
> 
> IMO, it's actually alot worse than that. Given that in today's Internet,
> one cannot assume that a community set in one AS will transit through
> another AS w/o being reset, this proposal, if implemented can result
> in persistant loops. 

Nevermind the looping comment. It won't loop if AS path is intact.

In anycase, this proposal still isn't all that useful IMO. 

We might was well revive one of DPA proposals if this sort of thing is 
really necessary.

-dorian

Date: Wed, 3 Nov 1999 18:08:13 -0500
From: Dorian Kim <[email-masked]>
To: Vijay Gill <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Private draft submission
Mail-Followup-To: Vijay Gill <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Nov 03, 1999 at 04:57:51PM -0500, Vijay Gill wrote:
> Re: http://www.kotovnik.com/~avg/old_page/draft-bgpmetric.txt
> 
> The only way to do this right is to do it again from the ground up for a
> source preference metric, among other things.  This hellbrew of
> communities that are being hashed out here need to go.  They are about as
> useful as the as-path padding metric to influence traffic with the
> exception that the overwhelming majority of the internet supports as
> padding _today_.

IMO, it's actually alot worse than that. Given that in today's Internet,
one cannot assume that a community set in one AS will transit through
another AS w/o being reset, this proposal, if implemented can result
in persistant loops. 

-dorian

Date: Wed, 3 Nov 1999 22:32:36 +0000
From: bradley reynolds <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

> I'm in complete agreement that doing it right is the best options.  It worth 
> noting, however, that service providers also have customer to support that 
> want flexibility and if the protocols don't support it then something has to.  
so what added flexibility does this community proposal add?  i see
its functionality as a subset of the as_path length hack functionality
and at the cost of a bit more complexity.

BR

Date: Wed, 3 Nov 1999 17:17:40 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private draft submission 
Sender: [email-masked]

On Wed, 3 Nov 1999, Danny McPherson wrote:

> 
> > Please disambiguate the protocol from the policy expression semantics.
> 
> Does "new protocol" not do that?  BGPv5 better?

Changing a couple of attributes does not a new protocol make.  A new
version perhaps.

/vijay

To: Vijay Gill <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 15:17:26 -0700
Sender: [email-masked]

> Please disambiguate the protocol from the policy expression semantics.

Does "new protocol" not do that?  BGPv5 better?

-danny

Date: Wed, 3 Nov 1999 17:11:44 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private draft submission 
Sender: [email-masked]

On Wed, 3 Nov 1999, Danny McPherson wrote:

> > The only way to do this right is to do it again from the ground up for a
> > source preference metric, among other things.  This hellbrew of
> > communities that are being hashed out here need to go.
> 
> I'm in complete agreement that doing it right is the best options.  It worth 
> noting, however, that service providers also have customer to support that 
> want flexibility and if the protocols don't support it then something has to.  
> It not that providers are dreaming up these things because they want one more 
> policy to manage.

Ah yes, customers.

I work for a promising local ISP and we have a couple of those.
Currently, all this works adequately with local hacks, but if we are going
to bother with changing route maps and policy definitions around, we might
as well wait a year and do it properly.

> So, is the opinion that we should begin work on a new protocol here?

Please disambiguate the protocol from the policy expression semantics.

/vijay

To: Vijay Gill <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 15:11:13 -0700
Sender: [email-masked]

> The only way to do this right is to do it again from the ground up for a
> source preference metric, among other things.  This hellbrew of
> communities that are being hashed out here need to go.

I'm in complete agreement that doing it right is the best options.  It worth 
noting, however, that service providers also have customer to support that 
want flexibility and if the protocols don't support it then something has to.  
It not that providers are dreaming up these things because they want one more 
policy to manage.

So, is the opinion that we should begin work on a new protocol here?

-danny

Date: Wed, 3 Nov 1999 16:57:51 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private draft submission 
Sender: [email-masked]

On Wed, 3 Nov 1999, Danny McPherson wrote:

> 
> I read this a while back.  The primary goal was to avoid changes to the 
> protocol, I believe.  Perhaps provide a clean solution make this inevitable?
> 
> -danny

Re: http://www.kotovnik.com/~avg/old_page/draft-bgpmetric.txt

The only way to do this right is to do it again from the ground up for a
source preference metric, among other things.  This hellbrew of
communities that are being hashed out here need to go.  They are about as
useful as the as-path padding metric to influence traffic with the
exception that the overwhelming majority of the internet supports as
padding _today_.

/vijay

To: Vijay Gill <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 14:55:07 -0700
Sender: [email-masked]

I read this a while back.  The primary goal was to avoid changes to the 
protocol, I believe.  Perhaps provide a clean solution make this inevitable?

-danny

[]
From: Vijay Gill <[email-masked]>
To: [email-masked]
Cc: Paul Traina <[email-masked]>, [email-masked]
Subject: Re: Private draft submission

On Wed, 3 Nov 1999, Danny McPherson wrote:

> 
> > If we want to do a "source preference" metric for a route, then
> > let's actually talk about the issues involved there.  There may be
> > a way to make this safe(-er) and a more general knob than the
> > current proposal.
> 
> I agree with most of the comments above.  And have been considering more of 
> the offshoots.
> 
> Again, I'm certainly open to a "cleaner" solution.

http://www.kotovnik.com/~avg/old_page/draft-bgpmetric.txt

/vijay

Date: Wed, 3 Nov 1999 13:49:30 -0800
From: Ben Black <[email-masked]>
To: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

Nobody suggested turning off the AS_PATH attribute.  What was suggested
was turning off AS_PATH *length* as a path selection metric.

On Wed, Nov 03, 1999 at 02:45:40PM -0700, Danny McPherson wrote:
> 
> Hence the comment someways back which stated turning it off would be a bad 
> idea...
> 
> -danny
> 
> > The former is the first item listed.  That item is not part of the BGP
> > path selection algorithm on any router I have ever used.  As I stated
> > in a previous post, that AS_PATH is a loop avoidance mechanism.  Without
> > it, loops are practically unavoidable.
> >
> 

-- 
 --b

Date: Wed, 3 Nov 1999 16:46:11 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: [email-masked]
Cc: Paul Traina <[email-masked]>, [email-masked]
Subject: Re: Private draft submission 
Sender: [email-masked]

On Wed, 3 Nov 1999, Danny McPherson wrote:

> 
> > If we want to do a "source preference" metric for a route, then
> > let's actually talk about the issues involved there.  There may be
> > a way to make this safe(-er) and a more general knob than the
> > current proposal.
> 
> I agree with most of the comments above.  And have been considering more of 
> the offshoots.
> 
> Again, I'm certainly open to a "cleaner" solution.

http://www.kotovnik.com/~avg/old_page/draft-bgpmetric.txt

/vijay

To: Ben Black <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 14:45:40 -0700
Sender: [email-masked]

Hence the comment someways back which stated turning it off would be a bad 
idea...

-danny

> The former is the first item listed.  That item is not part of the BGP
> path selection algorithm on any router I have ever used.  As I stated
> in a previous post, that AS_PATH is a loop avoidance mechanism.  Without
> it, loops are practically unavoidable.
>

Date: Wed, 3 Nov 1999 13:40:56 -0800
From: Ben Black <[email-masked]>
To: [email-masked]
Cc: Vijay Gill <[email-masked]>, [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

On Wed, Nov 03, 1999 at 02:39:43PM -0700, Danny McPherson wrote:
> 
> > Of course, some AS's choosing not to honor AS path would result in
> > looping. 
> > 
> > Or do you mean some AS's choosing not to honor AS path length as a
> > desirability metric/hop count?  If so, please construct a looping of
> > routing scenario and share it with us.
> 
> The former.
> 
> -danny
> 

The former is the first item listed.  That item is not part of the BGP
path selection algorithm on any router I have ever used.  As I stated
in a previous post, that AS_PATH is a loop avoidance mechanism.  Without
it, loops are practically unavoidable.

-- 
 --b

To: Vijay Gill <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 14:39:43 -0700
Sender: [email-masked]

> Of course, some AS's choosing not to honor AS path would result in
> looping. 
> 
> Or do you mean some AS's choosing not to honor AS path length as a
> desirability metric/hop count?  If so, please construct a looping of
> routing scenario and share it with us.

The former.

-danny

To: Paul Traina <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 14:38:53 -0700
Sender: [email-masked]

> If we want to do a "source preference" metric for a route, then
> let's actually talk about the issues involved there.  There may be
> a way to make this safe(-er) and a more general knob than the
> current proposal.

I agree with most of the comments above.  And have been considering more of 
the offshoots.

Again, I'm certainly open to a "cleaner" solution.

-danny

Date: Wed, 3 Nov 1999 16:34:52 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: [email-masked]
Cc: Ben Black <[email-masked]>, [email-masked]
Subject: Re: Private draft submission 
Sender: [email-masked]

On Wed, 3 Nov 1999, Danny McPherson wrote:

> 
> > Nothing would break which is not already broken in all path-vector
> algorithms  similar to BGP.
> 
> Unless different systems along a path use the attributes.  I can think of at 
> least one  example where some ASs choosing not to honor AS path would result 
> in looping.

Of course, some AS's choosing not to honor AS path would result in
looping. 

Or do you mean some AS's choosing not to honor AS path length as a
desirability metric/hop count?  If so, please construct a looping of
routing scenario and share it with us.

/vijay

Date: Wed, 3 Nov 1999 13:34:24 -0800
From: Ben Black <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

On Wed, Nov 03, 1999 at 02:26:46PM -0700, Danny McPherson wrote:
> 
> > Nothing would break which is not already broken in all path-vector algorithms
> > similar to BGP. 
> 
> Unless different systems along a path use the attributes.  I can think of at 
> least one  example where some ASs choosing not to honor AS path would result 
> in looping.
> 

There are all sorts of examples of policies which lead to persistent non-
convergence with the existing IOS path selection algorithm.  If a strict
RFC1771 compliant BGP implementation were in use on parts of the Internet
the scenario you have in mind would likely be possible.  It is unwise to make
assumptions about the policies and decision processes of other ASes.

> > The AS_PATH attribute is a loop avoidance mechanism and is
> > what differentiates path vector from distance vector.  It is specifically not
> > a path quality metric, despite the common practice of treating it as such.
> > Now, if AS_PATH length were the *first* tie-breaking metric and the AS_PATH
> > were always an accurate reflection of the number of ASes the announcement has
> > transited, you'd have something to argue.  As it stands, neither of those is
> > true.
> 
> Agreed. 
> 
> -danny
> 

-- 
 --b

Date: Wed, 3 Nov 1999 21:30:36 +0000
From: bradley reynolds <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

> > this proposal does not provide a greater flex*ease product than
> > the current as_path length mechanisms.  
> 
> 
> >if it does provide a greater product, 
> > then that is what should be discussed in the proposal and mulled on idr.
> 
> This was provided already, I'm not clear on which parts require restating.  
> Whether you choose to honor the values is your decisions.
> 
i saw what people contended was greater flexibility/ease of implementation,
but in actuality was more difficult to implement and just as vague as
to influencing incoming paths.

so, perhaps a clear restatement would be in order so we can judge whether
this approach has any merits above and beyond the functionality afforded
by the as_path length mechanisms.

BR

To: Ben Black <[email-masked]>, [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 14:26:46 -0700
Sender: [email-masked]

> Nothing would break which is not already broken in all path-vector algorithms
> similar to BGP. 

Unless different systems along a path use the attributes.  I can think of at 
least one  example where some ASs choosing not to honor AS path would result 
in looping.

> The AS_PATH attribute is a loop avoidance mechanism and is
> what differentiates path vector from distance vector.  It is specifically not
> a path quality metric, despite the common practice of treating it as such.
> Now, if AS_PATH length were the *first* tie-breaking metric and the AS_PATH
> were always an accurate reflection of the number of ASes the announcement has
> transited, you'd have something to argue.  As it stands, neither of those is
> true.

Agreed. 

-danny

To: bradley reynolds <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 14:24:05 -0700
Sender: [email-masked]

> my suggestion is leaving
> as_path length selection in place 

no one is suggesting removing it.

> this proposal does not provide a greater flex*ease product than
> the current as_path length mechanisms.  

>if it does provide a greater product, 
> then that is what should be discussed in the proposal and mulled on idr.

This was provided already, I'm not clear on which parts require restating.  
Whether you choose to honor the values is your decisions.

-danny

Date: Wed, 3 Nov 1999 12:32:43 -0800
From: Ben Black <[email-masked]>
To: [email-masked]
Cc: bradley reynolds <[email-masked]>, [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

On Wed, Nov 03, 1999 at 06:59:33AM -0700, Danny McPherson wrote:
> 
> > I believe this last sentence addresses part of the issue.  If i am not
> > guaranteed a standard interpretation of my communities, i am left to just
> > as much uncertainty as to my inbound path.  Some networks may choose to
> > act 'correctly' while others may choose to ignore.  As j.random multihomed
> > ISP i cannot predict which will act according to this draft and which will
> > ignore, thus giving me no advantage over the as path length selection.
> 
> Perhaps someone maintaining a list of providers that support the policy set 
> would be useful here?  As with RFC1998 also, for that matter.
> 
> > what are the scaling concerns with as_path length selection and how does
> > an 'on/off' switch fix them?
> 
> IMO, an on/off switch wrt AS_PATH would likely result in breaking of other 
> things.
> 

Nothing would break which is not already broken in all path-vector algorithms
similar to BGP.  The AS_PATH attribute is a loop avoidance mechanism and is
what differentiates path vector from distance vector.  It is specifically not
a path quality metric, despite the common practice of treating it as such.
Now, if AS_PATH length were the *first* tie-breaking metric and the AS_PATH
were always an accurate reflection of the number of ASes the announcement has
transited, you'd have something to argue.  As it stands, neither of those is
true.

-- 
 --b

Date: Wed, 3 Nov 1999 20:17:40 +0000
From: bradley reynolds <[email-masked]>
To: Jessica Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

On Wed, Nov 03, 1999 at 10:35:13AM -0500, Jessica Yu wrote:
> 
> I can see the need for a LOAD_SHARE_ME global BGP commuity value 
> in addition to PREFER_ME and AVOID_ME.
> 
> When receiving multiple BGP route of the same prefix with LOAD_SHARE_ME 
> community value, the router would just install the route with the lowest 
> IGP metric to the BGP nexthop without examing ASpath,etc.  This will
> help multihomed site to do load sharing on returning traffic without
> prepending ASpath.
> 
this involves modifying the bgp selection process.   perhaps you
should write a draft explaining how you want to modify the selection
process.  

regardless,
i don't think that is what you should be advocating.  community filtering
and selection occurs as a policy outside of bgp path selection.  the filtering
or route-map et al would then update some attribute which then influences
path selection in the next round.  community values are not part of path
selection.

BR

Date: Wed, 3 Nov 1999 12:18:22 -0800
From: Ben Black <[email-masked]>
To: Jessica Yu <[email-masked]>
Cc: Hank Nussbacher <[email-masked]>, [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

This requires changing the path selection algorithm dynamically based on
communities.  I believe that falls slightly outside the scope of defining
a set of globally standardized communities.

On Wed, Nov 03, 1999 at 10:35:13AM -0500, Jessica Yu wrote:
> 
> I can see the need for a LOAD_SHARE_ME global BGP commuity value 
> in addition to PREFER_ME and AVOID_ME.
> 
> When receiving multiple BGP route of the same prefix with LOAD_SHARE_ME 
> community value, the router would just install the route with the lowest 
> IGP metric to the BGP nexthop without examing ASpath,etc.  This will
> help multihomed site to do load sharing on returning traffic without
> prepending ASpath.
> 
> Thanks!
> 
> 					--Jessica

-- 
 --b

Date: Wed, 3 Nov 1999 20:07:08 +0000
From: bradley reynolds <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

> > what are the scaling concerns with as_path length selection and how does
> > an 'on/off' switch fix them?
> 
> IMO, an on/off switch wrt AS_PATH would likely result in breaking of other 
> things.
> 
the on/off switch is the mechanism specified in the document.  i am not
suggesting people should have an on/off switch for the as_path length part
of the selection process

> > what you have specified is an on/off switch for data path back to the
> > origin.  assuming i negotiate with my direct peers to ignore these values,
> > the network outside the set of direct peers is now wholly influenced in
> > one direction.  
> 
> Not sure I fully understand your example here?  If you're suggesting that if 
> you don't send the attribute, or your peers don't accept the attribute, then 
> it's useless.  I'd agree.
>
if you announce some prefix to your two transit providers and 
assuming those providers ignore this community yet allow it to transit
their network and assuming the people outside of the set of your two transit
providers respect the community, you now have a situation where all traffic
outside of the transit provider set will come down the preferred path. 
 
> Agreed, just as with RFC1998 and any other provider-based policy.  It's simply 
> part of the value-add of selecting one provider over another.
> 
lets not bring the marketing people into this. 

> > first,it measures distance. although this is a coarse measure, i now have
> > a few more options which are slightly predictable.  for example, if i
> > purchase 1239 and 701 transit and i decide to prepend out 701, the set of
> > asns external to {1239,701} will not suddenly shift all traffic over to
> > the 1239 path. There may be a customer of a customer of a peer 1239 who
> > also has a direct connection to 701.  that person would see minimally {X P
> > 1239 O} and {701 701 O} and prefer the 701 path assuming selection got
> > that far.
> 
> Therefore, you can't influence path selection in your "customer of a customer 
> of a peers" downstream AS, hence the requirement for providing a BCP document 
> and method that introduces this flexibility .. assuming they honor the 
> attribute.  If they don't, you lose nothing over what you have today.

no, you most certainly can influence path selection through as_path prepends. 
when you start prepending, some traffic starts preferring the non-prepended
path. as you prepend further, more traffic shifts to the non-prepend path.  this
will continue in a direct relationship until you reach some limit (those people
localpreffing prefixes for example).  There are traffic shifting steps that you
go through when you start prepending.  it is not an 'all-or-nothing' proposition.

> > Thus, i can swing traffic with a finer predictable level of
> > granularity than the on-off switch in this document.
> 
> This is inaccurate.  As you suggest above, if AS_PATH values are equal then 
> it's not factored anyway, and you can't manipulate the path from non-adjacent 
> ASs.

it is not innacurate.  i did not provide an example above where as_path lengths
are equal.  
>
 
> Note, however, most implementations choose to not add a switch to ignore 
> AS_PATH and provide no manipulation capabilities to the attribute [minus some 
> prepending and private AS stuff].  Both of these for very obvious reasons, I 
i still don't see the benefit of these extra features over what is currently
offered with as_path prepending.  the 'all or nothing' proposition, in fact,
scares me.
> > something would need to be proposed that offers some 
> > (flexibility * ease of standard deployment) product greater
> > than what people have with the current tools.  it may be possible
> > with communities.  

 Most large [you define] providers rely heavily on communities for policy defini
tion because of the flexibility they provide.  If you've a better suggestion I'm
listening :-)

you are preaching to the choir on this one.  however, internal flexibility
does not endow a mechanism with global flexibility. my suggestion is leaving
as_path length selection in place because it is superior to this proposal as
written.  this proposal does not provide a greater flex*ease product than
the current as_path length mechanisms.  if it does provide a greater product, 
then that is what should be discussed in the proposal and mulled on idr.

BR

Date: Wed, 3 Nov 1999 18:17:50 +0200 (IST)
From: Hank Nussbacher <[email-masked]>
To: [email-masked]
Cc: Hank Nussbacher <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

On Wed, 3 Nov 1999 [email-masked] wrote:

Hopefully by next week there will be a revision out with all the excellent
points made here.  -Hank

> That sounds reasonable, maybe it should be also stated in the draft.
> 
> Thanks
> Sean Capshaw                          email:     [email-masked]
> 
> AT&T Global Network Services    phone:   914-899-4730  t/l 566
> 500 Mamaroneck Ave                        fax:         914-899-4549 t/l
> 566
> Harrison NY 10528                                NOC:  [email-masked]
> 
> 
> Hank Nussbacher <[email-masked]> on 11/03/99 10:39:35 AM
> 
> To: Sean Capshaw/White Plains/IBM@IBMUS
> cc: [email-masked], [email-masked]
> Subject:Re: Private draft submission
> 
> 
> 
> 
> On Wed, 3 Nov 1999 [email-masked] wrote:
> 
> Being realistic, people will still do AS prepends at the same time as
> doing these bgp communities (for quite some time - if this BCP is
> accepted) . I can imagine many distant sites that have eqi-distant AS path
> lengths and then the routing decision (after assuming ties for external vs
> internal; lowest origin; MEDs] comes down to the lower IP address.Not
> the best way to control routing, IMO.This global community method would
> solve that problem.Could be that both methods will live in harmony for
> many years to come.
> 
> -Hank
> 
> > Hi Danny,
> >
> > One could argue that using this community method is definitely more
> > flexible.Whether thatflexibility is a good thing or not depends on how
> > you look at it.
> >
> > >From a multi-homed network's perspective, using the community method to
> > assure that one of my connections is used as the primary return path and
> > the other as the secondary return path may not be best.This is because
> > distant networks have the option of not treating the community the way
> > intended.
> >
> > >From a distant networks perspective, the community based solution may be
> > preferred because now there is more flexibility wrt the way I forward
> > traffic to that muli-homed network.
> >
> > Having the best interest of both the multi-homed network and the distant
> > network in mind, I am not convinced that one method is superior over the
> > other.
> >
> > Thanks
> > Sean Capshaw                        email:     [email-masked]
> >
> > AT&T Global Network Services  phone:   914-899-4730  t/l 566
> > 500 Mamaroneck Ave                        fax:       914-899-4549 t/l
> > 566
> > Harrison NY 10528                            NOC:  [email-masked]
> >
> >
> > Danny McPherson <[email-masked]> on 11/02/99 03:57:00 PM
> >
> > Please respond to [email-masked]
> >
> > To: Sean Capshaw/White Plains/IBM@IBMUS
> > cc: [email-masked]
> > Subject:Re: Private draft submission
> >
> >
> >
> >
> >
> > AS prepending is used because nothing else is available. Communities have
> > been deployed for quite some time now and are becoming more and more
> common
> > for routing policy definition in production networks.They've been proven
> > to
> > scale nicely from a policy management perspective as well.
> >
> > A global community policy definition such as this, IMO, provides much
> more
> > flexibility for multi-AS inter-domain route preference manipulation.Also,
> > communities are optional transitive attributes of which most current
> > implementations provide extended "manipulation capabilities" for, whereas
> > AS_PATH is mandatory transitive attribute and [mostly] can't be
> > manipulated.
> >
> > The mechanisms proposed in this draft also do not in any way inhibit use
> of
> > AS
> > prepending.
> >
> > As for the "no additional router configuration" statement, unlike a
> > communities-based approach, this is solely because you can't manipulate
> the
> > AS_PATH value and [usually] can't choose to ignore it in the decision
> > algorithm.
> >
> > Also, I know of at least two router vendors that are considering
> > implementing
> > simplistic configuration capabilities to associate with these
> "Well-known"
> > communities.
> >
> > -danny
> >
> > > The current defacto BCP for this is AS path prepending.One advantage
> > this
> > > current method has is thatno additional router configuration necessary
> > by
> > > downstream networks.Honoring global communities does require additional
> > > configuration and that seems likea disadvantage to me.Is there some
> > > reason that honoring communities would do the job better than as path
> > > prepending?
> >
> >
> >
> >
> >
> >
> 
> Hank Nussbacher
> 
> 
> 
> 
> 

Hank Nussbacher

From: [email-masked]
To: Hank Nussbacher <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 3 Nov 1999 10:47:56 -0500
Subject: Re: Private draft submission
Sender: [email-masked]

That sounds reasonable, maybe it should be also stated in the draft.

Thanks
Sean Capshaw                            email:     [email-masked]

AT&T Global Network Services      phone:   914-899-4730  t/l 566
500 Mamaroneck Ave                            fax:         914-899-4549 t/l
566
Harrison NY 10528                                  NOC:  [email-masked]

Hank Nussbacher <[email-masked]> on 11/03/99 10:39:35 AM

To:   Sean Capshaw/White Plains/IBM@IBMUS
cc:   [email-masked], [email-masked]
Subject:  Re: Private draft submission

On Wed, 3 Nov 1999 [email-masked] wrote:

Being realistic, people will still do AS prepends at the same time as
doing these bgp communities (for quite some time - if this BCP is
accepted) . I can imagine many distant sites that have eqi-distant AS path
lengths and then the routing decision (after assuming ties for external vs
internal; lowest origin; MEDs] comes down to the lower IP address.  Not
the best way to control routing, IMO.  This global community method would
solve that problem.  Could be that both methods will live in harmony for
many years to come.

-Hank

> Hi Danny,
>
> One could argue that using this community method is definitely more
> flexible.Whether that flexibility is a good thing or not depends on how
> you look at it.
>
> >From a multi-homed network's perspective, using the community method to
> assure that one of my connections is used as the primary return path and
> the other as the secondary return path may not be best.This is because
> distant networks have the option of not treating the community the way
> intended.
>
> >From a distant networks perspective, the community based solution may be
> preferred because now there is more flexibility wrt the way I forward
> traffic to that muli-homed network.
>
> Having the best interest of both the multi-homed network and the distant
> network in mind, I am not convinced that one method is superior over the
> other.
>
> Thanks
> Sean Capshaw                          email:     [email-masked]
>
> AT&T Global Network Services    phone:   914-899-4730  t/l 566
> 500 Mamaroneck Ave                          fax:       914-899-4549 t/l
> 566
> Harrison NY 10528                                NOC:  [email-masked]
>
>
> Danny McPherson <[email-masked]> on 11/02/99 03:57:00 PM
>
> Please respond to [email-masked]
>
> To: Sean Capshaw/White Plains/IBM@IBMUS
> cc: [email-masked]
> Subject:Re: Private draft submission
>
>
>
>
>
> AS prepending is used because nothing else is available. Communities have
> been deployed for quite some time now and are becoming more and more
common
> for routing policy definition in production networks.They've been proven
> to
> scale nicely from a policy management perspective as well.
>
> A global community policy definition such as this, IMO, provides much
more
> flexibility for multi-AS inter-domain route preference manipulation.Also,
> communities are optional transitive attributes of which most current
> implementations provide extended "manipulation capabilities" for, whereas
> AS_PATH is mandatory transitive attribute and [mostly] can't be
> manipulated.
>
> The mechanisms proposed in this draft also do not in any way inhibit use
of
> AS
> prepending.
>
> As for the "no additional router configuration" statement, unlike a
> communities-based approach, this is solely because you can't manipulate
the
> AS_PATH value and [usually] can't choose to ignore it in the decision
> algorithm.
>
> Also, I know of at least two router vendors that are considering
> implementing
> simplistic configuration capabilities to associate with these
"Well-known"
> communities.
>
> -danny
>
> > The current defacto BCP for this is AS path prepending.One advantage
> this
> > current method has is thatno additional router configuration necessary
> by
> > downstream networks.Honoring global communities does require additional
> > configuration and that seems likea disadvantage to me.Is there some
> > reason that honoring communities would do the job better than as path
> > prepending?
>
>
>
>
>
>

Hank Nussbacher

Date: Wed, 3 Nov 1999 17:41:48 +0200 (IST)
From: Hank Nussbacher <[email-masked]>
To: Jessica Yu <[email-masked]>
Cc: Hank Nussbacher <[email-masked]>, [email-masked]
Subject: Re: Private draft submission 
Sender: [email-masked]

On Wed, 3 Nov 1999, Jessica Yu wrote:

Plz suggest other global community values.  Very easy to add.

> 
> I can see the need for a LOAD_SHARE_ME global BGP commuity value
> in addition to PREFER_ME and AVOID_ME.
> 
> When receiving multiple BGP route of the same prefix with LOAD_SHARE_ME
> community value, the router would just install the route with the lowest
> IGP metric to the BGP nexthop without examing ASpath,etc.This will
> help multihomed site to do load sharing on returning traffic without
> prepending ASpath.
> 
> Thanks!
> 
> 					--Jessica
> 

Hank Nussbacher

Date: Wed, 3 Nov 1999 17:39:35 +0200 (IST)
From: Hank Nussbacher <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

On Wed, 3 Nov 1999 [email-masked] wrote:

Being realistic, people will still do AS prepends at the same time as
doing these bgp communities (for quite some time - if this BCP is
accepted) . I can imagine many distant sites that have eqi-distant AS path
lengths and then the routing decision (after assuming ties for external vs
internal; lowest origin; MEDs] comes down to the lower IP address.  Not
the best way to control routing, IMO.  This global community method would
solve that problem.  Could be that both methods will live in harmony for
many years to come.

-Hank

> Hi Danny,
> 
> One could argue that using this community method is definitely more
> flexible.Whether that flexibility is a good thing or not depends on how
> you look at it.
> 
> >From a multi-homed network's perspective, using the community method to
> assure that one of my connections is used as the primary return path and
> the other as the secondary return path may not be best.This is because
> distant networks have the option of not treating the community the way
> intended.
> 
> >From a distant networks perspective, the community based solution may be
> preferred because now there is more flexibility wrt the way I forward
> traffic to that muli-homed network.
> 
> Having the best interest of both the multi-homed network and the distant
> network in mind, I am not convinced that one method is superior over the
> other.
> 
> Thanks
> Sean Capshaw                          email:     [email-masked]
> 
> AT&T Global Network Services    phone:   914-899-4730  t/l 566
> 500 Mamaroneck Ave                          fax:       914-899-4549 t/l
> 566
> Harrison NY 10528                                NOC:  [email-masked]
> 
> 
> Danny McPherson <[email-masked]> on 11/02/99 03:57:00 PM
> 
> Please respond to [email-masked]
> 
> To: Sean Capshaw/White Plains/IBM@IBMUS
> cc: [email-masked]
> Subject:Re: Private draft submission
> 
> 
> 
> 
> 
> AS prepending is used because nothing else is available. Communities have
> been deployed for quite some time now and are becoming more and more common
> for routing policy definition in production networks.They've been proven
> to
> scale nicely from a policy management perspective as well.
> 
> A global community policy definition such as this, IMO, provides much more
> flexibility for multi-AS inter-domain route preference manipulation.Also,
> communities are optional transitive attributes of which most current
> implementations provide extended "manipulation capabilities" for, whereas
> AS_PATH is mandatory transitive attribute and [mostly] can't be
> manipulated.
> 
> The mechanisms proposed in this draft also do not in any way inhibit use of
> AS
> prepending.
> 
> As for the "no additional router configuration" statement, unlike a
> communities-based approach, this is solely because you can't manipulate the
> AS_PATH value and [usually] can't choose to ignore it in the decision
> algorithm.
> 
> Also, I know of at least two router vendors that are considering
> implementing
> simplistic configuration capabilities to associate with these "Well-known"
> communities.
> 
> -danny
> 
> > The current defacto BCP for this is AS path prepending.One advantage
> this
> > current method has is thatno additional router configuration necessary
> by
> > downstream networks.Honoring global communities does require additional
> > configuration and that seems likea disadvantage to me.Is there some
> > reason that honoring communities would do the job better than as path
> > prepending?
> 
> 
> 
> 
> 
> 

Hank Nussbacher

Date: Wed, 03 Nov 1999 10:39:16 -0500
To: [email-masked]
From: "Stacy W. Smith" <[email-masked]>
Subject: Re: Private draft submission
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 10:22 AM 11/3/99 -0500, [email-masked] wrote:

>Having the best interest of both the multi-homed network and the distant
>network in mind, I am not convinced that one method is superior over the
>other.

You've already got a hammer.  They're proposing ADDING a screwdriver to 
your tool box (without taking away your hammer).  It will then be up to you 
to decide if the problem is a screw or a nail.

Stacy

To: Hank Nussbacher <[email-masked]>
Cc: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 10:35:13 -0500
From: Jessica Yu <[email-masked]>
Sender: [email-masked]

I can see the need for a LOAD_SHARE_ME global BGP commuity value 
in addition to PREFER_ME and AVOID_ME.

When receiving multiple BGP route of the same prefix with LOAD_SHARE_ME 
community value, the router would just install the route with the lowest 
IGP metric to the BGP nexthop without examing ASpath,etc.  This will
help multihomed site to do load sharing on returning traffic without
prepending ASpath.

Thanks!

					--Jessica

Date: Wed, 03 Nov 1999 18:21:53 +0300
To: Hank Nussbacher <[email-masked]>, [email-masked]
From: Alex Zinin <[email-masked]>
Subject: Re: Private draft submission
Sender: [email-masked]

My 2c:

At 09:29 01.11.99 +0200, Hank Nussbacher wrote:
>Comments welcome.
>
>
> 1. Introduction
>
>    ISPs as well as multi-homed Internet users have many options available
>    to select their outgoing BGP routing path.  This is commonly known as
>    "metrics".

"Metric" is known to be a numeric characteristic of a route in the routing
table. Would "attribute" be better?

[...]
>
>
>    But for ASs which are two or more AS hops distant from the local AS -
>    the routing decision is based on one metric - AS_PATH.

what about the origin code?

[...]
> 
> 3. Global BGP Community Values
>
>    BGP community values can range from 0-4,294,967,200 (0 - 0xFFFFFFFF),
>    and the values 0x00000000 - 0x0000FFFF (0:0 - 0:65535),
>    and 0xFFFF0000 - 0xFFFFFFFF (65535:0 - 65536:65535) are reserved for
>    the well known community values.
>
>    The first range has been used by some ISPs for their own purposes (in
>    contradiction to RFC1998) and therefore cannot be recommended for use in
>    this RFC, so we will use the second range.

it's not an RFC yet, "document" would be better ?

>
> 4. New communities and local policy
>
>    No doubt, in some cases an ISP cannot allow the path control as
>    described in this document. For example, common practice is for an ISP
>    to prefer their customers' routing to flow via a common peering point
>    (NAP). In this case, the ISP should make all efforts to attempt to
>    implement as much of this RFC as is possible, considering the local
>    routing constraints.

"RFC" again.
Also, it may be worth noting that local policies just take precedence
over the announced ones.

>
>
> 5. Implementation details
>
>    There are two ways to implement these new communities. 
>
>    It is possible to use existing control methods (i.e. route-maps in case
>    of CISCO IOS) to modify LOCAL_PREF for the networks with these
>    communities (see example in the appendix below). This approach allows
>    ISP to implement the described features without changing router software
>    or hardware. 

I don't think mentioning hardware is necessary.

>    If allowed by the providers policy, the AVOID_ME community
>    can change local preference to a very low value, and the PREFER_ME

"local preference" or "LOCAL_PREF" as before?

>    community - to a very high value.
>	
>    Another, more long term approach is to incorporate these communities into 
>    the router software just as NO_EXPORT and NO_ADVERTISE communities are
>    incorporated today.

Meaning?
NO_EXPORT and NO_ADVERTISE do not influence the path selection algorithm,
while the new ones are supposed to. If so it may be worth to specify exactly
how...

>
>
> 6. References
>
[...]
>
>    [4] cisco systems, cisco IOS Software Version 12.0 - Configuring
>        BGP,
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c
>        /1cprt1/1cbgp.htm#28855
>    [5] Bassam Halabi. 'Internet Routing Architecture', CiscoPress, 1997.

Have the last two ones ever been mentioned?

[...]
>
> Appendix
>
>    These appendices list cisco and Juniper systems software specific
>    configuration examples for configuring communities. These examples are
>    given purely to show a working example of how the desired effect
>    discussed in this document can be achieved. Please refer to [6] for more

[6], not [4] ?

------------------------------------------------------------------
Alex D. Zinin, Consultant
CCSI #98966
CCIE #4015

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Wed, 3 Nov 1999 10:22:01 -0500
Subject: Re: Private draft submission
Sender: [email-masked]

Hi Danny,

One could argue that using this community method is definitely more
flexible.  Whether that flexibility is a good thing or not depends on how
you look at it.

>From a multi-homed network's perspective, using the community method to
assure that one of my connections is used as the primary return path and
the other as the secondary return path may not be best.  This is because
distant networks have the option of not treating the community the way
intended.

>From a distant networks perspective, the community based solution may be
preferred because now there is more flexibility wrt the way I forward
traffic to that muli-homed network.

Having the best interest of both the multi-homed network and the distant
network in mind, I am not convinced that one method is superior over the
other.

Thanks
Sean Capshaw                            email:     [email-masked]

AT&T Global Network Services      phone:   914-899-4730  t/l 566
500 Mamaroneck Ave                            fax:         914-899-4549 t/l
566
Harrison NY 10528                                  NOC:  [email-masked]

Danny McPherson <[email-masked]> on 11/02/99 03:57:00 PM

Please respond to [email-masked]

To:   Sean Capshaw/White Plains/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: Private draft submission

AS prepending is used because nothing else is available.   Communities have
been deployed for quite some time now and are becoming more and more common
for routing policy definition in production networks.  They've been proven
to
scale nicely from a policy management perspective as well.

A global community policy definition such as this, IMO, provides much more
flexibility for multi-AS inter-domain route preference manipulation.  Also,
communities are optional transitive attributes of which most current
implementations provide extended "manipulation capabilities" for, whereas
AS_PATH is mandatory transitive attribute and [mostly] can't be
manipulated.

The mechanisms proposed in this draft also do not in any way inhibit use of
AS
prepending.

As for the "no additional router configuration" statement, unlike a
communities-based approach, this is solely because you can't manipulate the
AS_PATH value and [usually] can't choose to ignore it in the decision
algorithm.

Also, I know of at least two router vendors that are considering
implementing
simplistic configuration capabilities to associate with these "Well-known"
communities.

-danny

> The current defacto BCP for this is AS path prepending.  One advantage
this
> current method has is that  no additional router configuration necessary
by
> downstream networks.  Honoring global communities does require additional
> configuration and that seems like a disadvantage to me.  Is there some
> reason that honoring communities would do the job better than as path
> prepending?

To: bradley reynolds <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Wed, 03 Nov 1999 06:59:33 -0700
Sender: [email-masked]

> I believe this last sentence addresses part of the issue.  If i am not
> guaranteed a standard interpretation of my communities, i am left to just
> as much uncertainty as to my inbound path.  Some networks may choose to
> act 'correctly' while others may choose to ignore.  As j.random multihomed
> ISP i cannot predict which will act according to this draft and which will
> ignore, thus giving me no advantage over the as path length selection.

Perhaps someone maintaining a list of providers that support the policy set 
would be useful here?  As with RFC1998 also, for that matter.

> what are the scaling concerns with as_path length selection and how does
> an 'on/off' switch fix them?

IMO, an on/off switch wrt AS_PATH would likely result in breaking of other 
things.

> what you have specified is an on/off switch for data path back to the
> origin.  assuming i negotiate with my direct peers to ignore these values,
> the network outside the set of direct peers is now wholly influenced in
> one direction.  

Not sure I fully understand your example here?  If you're suggesting that if 
you don't send the attribute, or your peers don't accept the attribute, then 
it's useless.  I'd agree.

> should the implementation in the !(direct peer) set be random, i now
> have no way to predict traffic patterns.

Agreed, just as with RFC1998 and any other provider-based policy.  It's simply 
part of the value-add of selecting one provider over another.

> as_path length seems to be superior for a few reasons:  
> 
> first,it measures distance. although this is a coarse measure, i now have
> a few more options which are slightly predictable.  for example, if i
> purchase 1239 and 701 transit and i decide to prepend out 701, the set of
> asns external to {1239,701} will not suddenly shift all traffic over to
> the 1239 path. There may be a customer of a customer of a peer 1239 who
> also has a direct connection to 701.  that person would see minimally {X P
> 1239 O} and {701 701 O} and prefer the 701 path assuming selection got
> that far.

Therefore, you can't influence path selection in your "customer of a customer 
of a peers" downstream AS, hence the requirement for providing a BCP document 
and method that introduces this flexibility .. assuming they honor the 
attribute.  If they don't, you lose nothing over what you have today.

> Thus, i can swing traffic with a finer predictable level of
> granularity than the on-off switch in this document.

This is inaccurate.  As you suggest above, if AS_PATH values are equal then 
it's not factored anyway, and you can't manipulate the path from non-adjacent 
ASs.

> other reasons are that it is mandatory transitive, already
> deployed, and relatively well understood.  

Note, however, most implementations choose to not add a switch to ignore 
AS_PATH and provide no manipulation capabilities to the attribute [minus some 
prepending and private AS stuff].  Both of these for very obvious reasons, I 
believe.

> something would need to be proposed that offers some 
> (flexibility * ease of standard deployment) product greater
> than what people have with the current tools.  it may be possible
> with communities.  

Most large [you define] providers rely heavily on communities for policy definition because of the flexibility they provide.  If you've a better suggestion I'm listening :-)

-danny

Date: Wed, 3 Nov 1999 10:14:30 +0000
From: bradley reynolds <[email-masked]>
To: [email-masked]
Subject: [Re: Private draft submission ]
Sender: [email-masked]

sorry for dupes.. i sent this from the wrong address i believe

---------- Forwarded message ----------
Date: Wed, 3 Nov 1999 05:10:18 -0500 (EST)
From: bradley reynolds <[email-masked]>
To: [email-masked]
Subject: Re: Private draft submission

>     The purpose of this draft is to take the concept of BGP community values
>     (that has up until now only been used via neighboring Autonomous
>     Systems) and apply it globally. If an ISP does not receive or act on
>     these global BGP community values - nothing bad should happen other than
>     perhaps sub- optimum routing. 

I believe this last sentence addresses part of the issue.  If i am not
guaranteed a standard interpretation of my communities, i am left to just
as much uncertainty as to my inbound path.  Some networks may choose to
act 'correctly' while others may choose to ignore.  As j.random multihomed
ISP i cannot predict which will act according to this draft and which will
ignore, thus giving me no advantage over the as path length selection.

>     The authors believe that in order to scale and optimize inter-domain path
>     selection, there is a definite need for such a mechanism to be defined.
>     Basing that mechanism upon existing BGP attributes and leveraging several
>     years of general deployment experience with BGP communities should ease
>     deployment concerns.
>  

what are the scaling concerns with as_path length selection and how does
an 'on/off' switch fix them?

>     0xFFFFFFEF    - (PREFER_ME) Always prefer the path from which you hear 
> 
>     0xFFFFFFE0    - (AVOID_ME) Try as much as possible to avoid this path.

what you have specified is an on/off switch for data path back to the
origin.  assuming i negotiate with my direct peers to ignore these values,
the network outside the set of direct peers is now wholly influenced in
one direction.  

should the implementation in the !(direct peer) set be random, i now
have no way to predict traffic patterns.

as_path length seems to be superior for a few reasons:  

first,it measures distance. although this is a coarse measure, i now have
a few more options which are slightly predictable.  for example, if i
purchase 1239 and 701 transit and i decide to prepend out 701, the set of
asns external to {1239,701} will not suddenly shift all traffic over to
the 1239 path. There may be a customer of a customer of a peer 1239 who
also has a direct connection to 701.  that person would see minimally {X P
1239 O} and {701 701 O} and prefer the 701 path assuming selection got
that far. Thus, i can swing traffic with a finer predictable level of
granularity than the on-off switch in this document.

other reasons are that it is mandatory transitive, already
deployed, and relatively well understood.  

something would need to be proposed that offers some 
(flexibility * ease of standard deployment) product greater
than what people have with the current tools.  it may be possible
with communities.  

BR

Date: Wed, 3 Nov 1999 05:10:18 -0500 (EST)
From: bradley reynolds <[email-masked]>
To: [email-masked]
Subject: Re: Private draft submission
Sender: [email-masked]

>     The purpose of this draft is to take the concept of BGP community values
>     (that has up until now only been used via neighboring Autonomous
>     Systems) and apply it globally. If an ISP does not receive or act on
>     these global BGP community values - nothing bad should happen other than
>     perhaps sub- optimum routing. 

I believe this last sentence addresses part of the issue.  If i am not
guaranteed a standard interpretation of my communities, i am left to just
as much uncertainty as to my inbound path.  Some networks may choose to
act 'correctly' while others may choose to ignore.  As j.random multihomed
ISP i cannot predict which will act according to this draft and which will
ignore, thus giving me no advantage over the as path length selection.

>     The authors believe that in order to scale and optimize inter-domain path
>     selection, there is a definite need for such a mechanism to be defined.
>     Basing that mechanism upon existing BGP attributes and leveraging several
>     years of general deployment experience with BGP communities should ease
>     deployment concerns.
>  

what are the scaling concerns with as_path length selection and how does
an 'on/off' switch fix them?

>     0xFFFFFFEF    - (PREFER_ME) Always prefer the path from which you hear 
> 
>     0xFFFFFFE0    - (AVOID_ME) Try as much as possible to avoid this path.

what you have specified is an on/off switch for data path back to the
origin.  assuming i negotiate with my direct peers to ignore these values,
the network outside the set of direct peers is now wholly influenced in
one direction.  

should the implementation in the !(direct peer) set be random, i now
have no way to predict traffic patterns.

as_path length seems to be superior for a few reasons:  

first,it measures distance. although this is a coarse measure, i now have
a few more options which are slightly predictable.  for example, if i
purchase 1239 and 701 transit and i decide to prepend out 701, the set of
asns external to {1239,701} will not suddenly shift all traffic over to
the 1239 path. There may be a customer of a customer of a peer 1239 who
also has a direct connection to 701.  that person would see minimally {X P
1239 O} and {701 701 O} and prefer the 701 path assuming selection got
that far. Thus, i can swing traffic with a finer predictable level of
granularity than the on-off switch in this document.

other reasons are that it is mandatory transitive, already
deployed, and relatively well understood.  

something would need to be proposed that offers some 
(flexibility * ease of standard deployment) product greater
than what people have with the current tools.  it may be possible
with communities.  

BR

To: [email-masked]
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Private draft submission 
Date: Tue, 02 Nov 1999 13:57:00 -0700
Sender: [email-masked]

AS prepending is used because nothing else is available.   Communities have 
been deployed for quite some time now and are becoming more and more common 
for routing policy definition in production networks.  They've been proven to 
scale nicely from a policy management perspective as well.
 
A global community policy definition such as this, IMO, provides much more 
flexibility for multi-AS inter-domain route preference manipulation.  Also, 
communities are optional transitive attributes of which most current 
implementations provide extended "manipulation capabilities" for, whereas 
AS_PATH is mandatory transitive attribute and [mostly] can't be manipulated.

The mechanisms proposed in this draft also do not in any way inhibit use of AS 
prepending.

As for the "no additional router configuration" statement, unlike a 
communities-based approach, this is solely because you can't manipulate the 
AS_PATH value and [usually] can't choose to ignore it in the decision 
algorithm.

Also, I know of at least two router vendors that are considering implementing 
simplistic configuration capabilities to associate with these "Well-known" 
communities.

-danny

> The current defacto BCP for this is AS path prepending.  One advantage this
> current method has is that  no additional router configuration necessary by
> downstream networks.  Honoring global communities does require additional
> configuration and that seems like a disadvantage to me.  Is there some
> reason that honoring communities would do the job better than as path
> prepending?

From: [email-masked]
To: Hank Nussbacher <[email-masked]>
Cc: [email-masked]
Date: Tue, 2 Nov 1999 11:14:09 -0500
Subject: Re: Private draft submission
Sender: [email-masked]

Hi Hank,

The current defacto BCP for this is AS path prepending.  One advantage this
current method has is that  no additional router configuration necessary by
downstream networks.  Honoring global communities does require additional
configuration and that seems like a disadvantage to me.  Is there some
reason that honoring communities would do the job better than as path
prepending?

Thanks
Sean Capshaw                            email:     [email-masked]

AT&T Global Network Services      phone:   914-899-4730  t/l 566
500 Mamaroneck Ave                            fax:         914-899-4549 t/l
566
Harrison NY 10528                                  NOC:  [email-masked]

Hank Nussbacher <[email-masked]> on 11/01/99 02:29:22 AM

To:   [email-masked]
cc:
Subject:  Private draft submission

Comments welcome.

 INTERNET-DRAFT                                           Hank Nussbacher
 <draft-nussbacher-global-community-values-v1-00.txt>          Consultant
                                                           Alex P. Rudnev
                                                              Relcom Corp
                                                              Susan Hares
                                                                    MERIT
                                                            November 1999

                           Global BGP Community Values
               <draft-nussbacher-global-community-values-v1-00.txt>

 Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

 Abstract

    This document will present suggested global BGP community values.
    The ability for ISPs and multi-homed users of the Internet to influence
    distant routing decisions is limited to artificially lengthening the
    AS_PATH value. BGP community values are used by many ISPs throughout
    the world to influence their immediate neighbor's routing decisions,
    but these communities are provider-dependent and non-standardized.
    This BCP track draft attempts to specify global BGP community values
    that all ISPs can use to influence their local routing decisions in
    distant networks, and describes how such communities can be realized
    without violating existing routing policies.

 1. Introduction

    ISPs as well as multi-homed Internet users have many options available
    to select their outgoing BGP routing path.  This is commonly known as
    "metrics".

    But when an ISP wishes to influence the return path of packets to their
    network, they are presented with two paths: local neighbors and distant
    networks as well as two types of challenges: influencing the local
    neighbors path selection and influencing distance networks path
    selection.

    Local neighboring ISPs or BGP customers can select to set up BGP
    community values which each ISP can use to influence the routing
    decision process of their immediate neighbors. There are many different
    BGP community schemes available and it is not the purpose of this paper
    to specify these schema. RFC1998 [3] describes how to define and how to
    use such communities.

    But for ASs which are two or more AS hops distant from the local AS -
    the routing decision is based on one metric - AS_PATH.

    This means that Internet path selection comes down to a simple AS hop
    count - similar in nature to RIP hop counts. Clearly, this method
leaves
    much to be desired. The method used to influence distant routing
    behavior has been via AS prepending - a system that adds fictitious AS
    hops to the AS_PATH to artificially lengthen it.

    This method is complex and a fairly inaccurate way for influencing
    distant routing decisions. An alternative method to influence such
    routing decisions would be to use BGP communities for all distant
    ISPs, but it is not an easy task because every ISP uses it's own
    sets of communities, and not all sets can be used by transit networks.

    Since the publication of the BGP Community RFCs (RFC 1997 [2]
    and RFC 1998 [3] ) in August 1996, many ISPs have implemented community
    values and know how to pass these values onward to their peers.

    The purpose of this draft is to take the concept of BGP community
values
    (that has up until now only been used via neighboring Autonomous
    Systems) and apply it globally. If an ISP does not receive or act on
    these global BGP community values - nothing bad should happen other
than
    perhaps sub- optimum routing. But the purpose of this draft is to
define
    BCP practically regarding global community values that all ISPs should
    attempt to honor based upon these BGP community values.

    In some cases, an ISP may not be able to strictly implement these
    routing policy changes, but it's rare, when it is not possible to use
    these new global BGP communities as an additional selection factor.

    Clearly, these global BGP community values cannot be required - but
only
    highly recommended.

    The authors believe that in order to scale and optimize inter-domain
path
    selection, there is a definite need for such a mechanism to be defined.
    Basing that mechanism upon existing BGP attributes and leveraging
several
    years of general deployment experience with BGP communities should ease
    deployment concerns.

 2. Overview of the Community Attribute

    The BGP community path attribute is an optional transitive attribute of
    variable length [1,2], that share some common property. The attribute
    consists of a set of four octet values, each of which specify a
    community. The community attribute values are encoded using an AS
number
    in the first two octets, with the remaining two octets defined by the
    AS. As defined in [2], a community is a group of destinations (i.e.
    prefixes) that share some common attribute.

    Each destination can belong to multiple communities. All prefixes with
    the community attribute belong to the communities listed in the
    attribute.

    The BGP community  allows one to group a set of prefixes and perform
    routing decisions based on the identity of the group.

    The well-known communities NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE
    (0xFFFFFF02) are intuitive, and can be used for optimizing routing and
    for improving route aggregation. Another community NO_EXPORT_SUBCONFED
    has been proposed to control network advertising in case of BGP
    confederation. All these 'well-known' communities are only used between
    adjacent ASs and can not control any routing in the remote networks.

 3. Global BGP Community Values

    BGP community values can range from 0-4,294,967,200 (0 - 0xFFFFFFFF),
    and the values 0x00000000 - 0x0000FFFF (0:0 - 0:65535),
    and 0xFFFF0000 - 0xFFFFFFFF (65535:0 - 65536:65535) are reserved for
    the well known community values.

    The first range has been used by some ISPs for their own purposes (in
    contradiction to RFC1998) and therefore cannot be recommended for use
in
    this RFC, so we will use the second range.

    Below is a table of the global BGP community values and their
    meaning:

    0xFFFFFFEF    - (PREFER_ME) Always prefer the path from which you hear
                    this community value.
                    If two or more paths contain this same global
                    community value then use any tie-breaking
                    mechanisms you feel would be appropriate for your
                    environment. If you cannot prefer this path in all
                    cases, prefer it at least when it is possible
                    without violating your local routing policy. The
                    decimal value of this community is 65535:65519.

    0xFFFFFFE0    - (AVOID_ME) Try as much as possible to avoid this path.
                    If you have an alternate path to reach the prefix
                    in question, use it. If two or more paths contain
                    this same value then use any tie-breaking
                    mechanisms you feel would be appropriate for your
                    environment. If you cannot avoid this path in all
                    cases, avoid it at least when you can. The decimal
                    value of this community is 65535:65504.

    If both AVOID_ME and PREFER_ME preferences are specified, they are to
be
    ignored.

    0xFFFFFFE1 - 0xFFFFFFEE - reserved for future use

    Note: global community values do NOT override prefix matching. A more
    specific prefix always takes preference over a less specific prefix,
    irregardless of the global community value.

 4. New communities and local policy

    No doubt, in some cases an ISP cannot allow the path control as
    described in this document. For example, common practice is for an ISP
    to prefer their customers' routing to flow via a common peering point
    (NAP). In this case, the ISP should make all efforts to attempt to
    implement as much of this RFC as is possible, considering the local
    routing constraints.

 5. Implementation details

    There are two ways to implement these new communities.

    It is possible to use existing control methods (i.e. route-maps in case
    of CISCO IOS) to modify LOCAL_PREF for the networks with these
    communities (see example in the appendix below). This approach allows
    ISP to implement the described features without changing router
software
    or hardware. If allowed by the providers policy, the AVOID_ME community
    can change local preference to a very low value, and the PREFER_ME
    community - to a very high value.

    Another, more long term approach is to incorporate these communities
into
    the router software just as NO_EXPORT and NO_ADVERTISE communities are
    incorporated today.

 6. References

    [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
        RFC 1771, March 1995.

    [2] Chandra, R., Traina, P., and T. Li, "BGP Communities
        Attribute", RFC 1997, August 1996.

    [3] Chen, E., and T. Bates, "Application of the BGP Community
        Attribute in Multi-home Routing", RFC 1998, August 1996.

    [4] cisco systems, cisco IOS Software Version 12.0 - Configuring
        BGP,

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c

        /1cprt1/1cbgp.htm#28855
    [5] Bassam Halabi. 'Internet Routing Architecture', CiscoPress, 1997.

 6. Security Considerations

    Security issues are not discussed in this memo.

 7. Acknowledgments

    Thanks to Danny McPherson for reviewing this document and providing
    valuable feedback.

 8. Authors' Addresses

    Hank Nussbacher
    Internet and networking consultant
    POB 2366
    Kfar Saba 44425
    Israel
    Phone: +972 9 7663447
    EMail: [email-masked]

    Alexei Roudnev
    Senior network engineer
    The head of Network Operation Centre
    Relcom.DS network
    Pechorskaia ul. 6/2
    129344, Moscow, Russia.
    Phone: +7 095 194 1995
    Email: [email-masked]

    Susan Hares
    mail: [email-masked]

 Appendix

    These appendices list cisco and Juniper systems software specific
    configuration examples for configuring communities. These examples are
    given purely to show a working example of how the desired effect
    discussed in this document can be achieved. Please refer to [6] for
more
    specific information on cisco configuration and syntax.

 Appendix A. Cisco specific examples

 A.1 Propagating Community values

    router bgp 65100
    ! Link to ISP1
    neighbor 192.168.102.1 remote-as 65111
    neighbor 192.168.102.1 send-community

    At the minimal, since Cisco routers by default do not propagate
    community values, the above should be implemented on all BGP peers.

 A.2 Simple Community Configuration

    router bgp 65100
    ! Link to ISP1
    neighbor 192.168.102.1 remote-as 65111
    neighbor 192.168.102.1 route-map to-ISP1 out
    neighbor 192.168.102.1 send-community
    !
    route-map to-ISP1 permit 10
    set community 0xFFFFFFEF

    This example simply adds a BGP community value of 0xFFFFFFEF.

    Note: In order to use standard decimal numbers in BGP community values
    in Cisco, one has to add in IOS:
    ip bgp-community new-format

 A.3 Changing the routing path based on a certain Community value

    router bgp 65111
    ! Link to ISP2
    neighbor 192.168.102.2 remote-as 65100
    neighbor 192.168.102.2 route-map from-ISP2 in
    neighbor 192.168.102.2 send-community
    !
    route-map to-ISP2 permit 10
    match community 0xFFFFFFEF
    ! Default localpref=100; setting localpref=200 forces traffic this way
    set local-preference 200

 Appendix B. Configuration examples for JUNOS.

    The example below should attach community of 65535:65519 to
    192.168.0.0/24 (exact) when advertising to peer 192.168.102.1, and
    community of 65535:65504 to 192.168.0.0/24 and advertise it to
    the peer, then deny all other.

  [snip]

  routing-options {
      autonomous-system 65100;
  }

  protocols {
      bgp {
             group ISP1 {
               type external;
               peer-as 65111;
               export to-ISP1;
               neighbor 192.168.102.1;
             }
      }
  }

  policy-options {
       policy-statement to-ISP1 {
           term 10 {
               from {
                   route-filter 192.168.0.0/24 exact;
               }
               then {
                   community add PREFER_ME;
                   next policy;
               }
           }
           term 20 {
               from {
                   route-filter 192.168.1.0/24 exact;
               }
               then {
                   community add AVOID_ME;
                   next policy;
               }
           }
           term 30 {
               then reject;
           }
       }
       community PREFER_ME members 65535:65519;
       community AVOID_ME  members 65535:65504;
  }

    This example should match communities from the peer, pref up PREFER_ME
    communities, and pref down AVOID_ME communities, then default to 100
    explicitly.

  [snip]

    routing-options {
      autonomous-system 65111;
  }

  protocols {
      bgp {
          group ISP2 {
              type external;
              peer-as 65100;
              import from-ISP2;
              neighbor 192.168.102.2;
          }
      }
  }
  policy-options {
      policy-statement from-ISP2 {
          term 10 {
              from community PREFER_ME;
              then {
                  local-preference 200;
                  next policy;
              }
          }
          term 20 {
              from community AVOID_ME;
              then {
                  local-preference 10;
                  next policy;
              }
          }
          term 30 {
              then {
                  local-preference 100;
                  next policy;
              }
          }
      }
      community PREFER_ME members 65535:65519;
      community AVOID_ME  members 65535:65504;
  }

 Appendix C.   GateD examples

 C.1: Appending new communities to some routes

 The example below appends the AVOID_ME community (0XFFFFFFE0) to
 some routes, and to another set of routes the PREFER_ME community
 (0XFFFFFFFEF).

 bgp yes {
      group type external peeras 65001
           {
           peer 192.168.102.2;
           };
      };

 [snip]
 # export all routes from AS 65001 to 65002 and
 # export all routes from AS 65001 to 65002 and
 # add AVOID_ME
 #
 # add PREFER_ME
 #

 export proto bgp as 65002 add_comm {AVOID_ME;}
      {
      proto bgp peer as 65001 {
           192.168.0.0 masklen 16 exact;
           };
      };

 export proto bgp as 65003 add_comm (PREFER_ME;};
      {
      proto bgp peer as 65001 {
           192.168.1.0 masklen 24 exact;
           };
      };

 C.2 Changing the routing path based on a certain Community value

 bgp yes {
      group type external peeras 65002
           {
           peer 192.168.102.2;
           };
      };

 #  avoid all networks received from AS 65002
 # high preference in GateD gives avoidance
 #
 import proto bgp as 65002 comm {AVOID_ME;} pref 245
      {
      all;    #all networks received from 65002 with AVOID_ME
      };

 # low preference in GateD gives acceptance
 import proto BGP as 65002 comm { PREFER_ME; } pref 100
      {
      all;    # all networks received from 65002 with PREFER_ME
      }

Date: Mon, 01 Nov 1999 09:29:22 +0200
To: [email-masked]
From: Hank Nussbacher <[email-masked]>
Subject: Private draft submission
Sender: [email-masked]

Comments welcome.

 INTERNET-DRAFT                                           Hank Nussbacher
 <draft-nussbacher-global-community-values-v1-00.txt>          Consultant
                                                           Alex P. Rudnev
                                                              Relcom Corp
                                                              Susan Hares
                                                                    MERIT
                                                            November 1999

                           Global BGP Community Values
               <draft-nussbacher-global-community-values-v1-00.txt>

 Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

 Abstract

    This document will present suggested global BGP community values.
    The ability for ISPs and multi-homed users of the Internet to influence
    distant routing decisions is limited to artificially lengthening the
    AS_PATH value. BGP community values are used by many ISPs throughout
    the world to influence their immediate neighbor's routing decisions,
    but these communities are provider-dependent and non-standardized.
    This BCP track draft attempts to specify global BGP community values
    that all ISPs can use to influence their local routing decisions in
    distant networks, and describes how such communities can be realized 
    without violating existing routing policies.

 1. Introduction

    ISPs as well as multi-homed Internet users have many options available
    to select their outgoing BGP routing path.  This is commonly known as
    "metrics".

    But when an ISP wishes to influence the return path of packets to their
    network, they are presented with two paths: local neighbors and distant
    networks as well as two types of challenges: influencing the local
    neighbors path selection and influencing distance networks path
    selection.

    Local neighboring ISPs or BGP customers can select to set up BGP
    community values which each ISP can use to influence the routing
    decision process of their immediate neighbors. There are many different
    BGP community schemes available and it is not the purpose of this paper
    to specify these schema. RFC1998 [3] describes how to define and how to
    use such communities.

    But for ASs which are two or more AS hops distant from the local AS -
    the routing decision is based on one metric - AS_PATH.

    This means that Internet path selection comes down to a simple AS hop
    count - similar in nature to RIP hop counts. Clearly, this method leaves
    much to be desired. The method used to influence distant routing
    behavior has been via AS prepending - a system that adds fictitious AS
    hops to the AS_PATH to artificially lengthen it. 

    This method is complex and a fairly inaccurate way for influencing 
    distant routing decisions. An alternative method to influence such
    routing decisions would be to use BGP communities for all distant 
    ISPs, but it is not an easy task because every ISP uses it's own 
    sets of communities, and not all sets can be used by transit networks.

    Since the publication of the BGP Community RFCs (RFC 1997 [2]
    and RFC 1998 [3] ) in August 1996, many ISPs have implemented community
    values and know how to pass these values onward to their peers.

    The purpose of this draft is to take the concept of BGP community values
    (that has up until now only been used via neighboring Autonomous
    Systems) and apply it globally. If an ISP does not receive or act on
    these global BGP community values - nothing bad should happen other than
    perhaps sub- optimum routing. But the purpose of this draft is to define
    BCP practically regarding global community values that all ISPs should
    attempt to honor based upon these BGP community values. 

    In some cases, an ISP may not be able to strictly implement these
    routing policy changes, but it's rare, when it is not possible to use
    these new global BGP communities as an additional selection factor.

    Clearly, these global BGP community values cannot be required - but only
    highly recommended.

    The authors believe that in order to scale and optimize inter-domain path
    selection, there is a definite need for such a mechanism to be defined.
    Basing that mechanism upon existing BGP attributes and leveraging several
    years of general deployment experience with BGP communities should ease
    deployment concerns.
 
 2. Overview of the Community Attribute

    The BGP community path attribute is an optional transitive attribute of
    variable length [1,2], that share some common property. The attribute
    consists of a set of four octet values, each of which specify a
    community. The community attribute values are encoded using an AS number
    in the first two octets, with the remaining two octets defined by the
    AS. As defined in [2], a community is a group of destinations (i.e.
    prefixes) that share some common attribute.

    Each destination can belong to multiple communities. All prefixes with
    the community attribute belong to the communities listed in the
    attribute.

    The BGP community  allows one to group a set of prefixes and perform
    routing decisions based on the identity of the group.

    The well-known communities NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE
    (0xFFFFFF02) are intuitive, and can be used for optimizing routing and
    for improving route aggregation. Another community NO_EXPORT_SUBCONFED
    has been proposed to control network advertising in case of BGP
    confederation. All these 'well-known' communities are only used between
    adjacent ASs and can not control any routing in the remote networks.

 3. Global BGP Community Values

    BGP community values can range from 0-4,294,967,200 (0 - 0xFFFFFFFF),
    and the values 0x00000000 - 0x0000FFFF (0:0 - 0:65535),
    and 0xFFFF0000 - 0xFFFFFFFF (65535:0 - 65536:65535) are reserved for
    the well known community values.

    The first range has been used by some ISPs for their own purposes (in
    contradiction to RFC1998) and therefore cannot be recommended for use in
    this RFC, so we will use the second range.

    Below is a table of the global BGP community values and their
    meaning:

    0xFFFFFFEF    - (PREFER_ME) Always prefer the path from which you hear 
                    this community value.
                    If two or more paths contain this same global
                    community value then use any tie-breaking
                    mechanisms you feel would be appropriate for your
                    environment. If you cannot prefer this path in all
                    cases, prefer it at least when it is possible
                    without violating your local routing policy. The
                    decimal value of this community is 65535:65519. 

    0xFFFFFFE0    - (AVOID_ME) Try as much as possible to avoid this path.
                    If you have an alternate path to reach the prefix
                    in question, use it. If two or more paths contain
                    this same value then use any tie-breaking
                    mechanisms you feel would be appropriate for your
                    environment. If you cannot avoid this path in all
                    cases, avoid it at least when you can. The decimal
                    value of this community is 65535:65504.

    If both AVOID_ME and PREFER_ME preferences are specified, they are to be
    ignored.

    0xFFFFFFE1 - 0xFFFFFFEE - reserved for future use

    Note: global community values do NOT override prefix matching. A more
    specific prefix always takes preference over a less specific prefix,
    irregardless of the global community value.

 4. New communities and local policy

    No doubt, in some cases an ISP cannot allow the path control as
    described in this document. For example, common practice is for an ISP
    to prefer their customers' routing to flow via a common peering point
    (NAP). In this case, the ISP should make all efforts to attempt to
    implement as much of this RFC as is possible, considering the local
    routing constraints.

 5. Implementation details

    There are two ways to implement these new communities. 

    It is possible to use existing control methods (i.e. route-maps in case
    of CISCO IOS) to modify LOCAL_PREF for the networks with these
    communities (see example in the appendix below). This approach allows
    ISP to implement the described features without changing router software
    or hardware. If allowed by the providers policy, the AVOID_ME community
    can change local preference to a very low value, and the PREFER_ME
    community - to a very high value.
	
    Another, more long term approach is to incorporate these communities into 
    the router software just as NO_EXPORT and NO_ADVERTISE communities are
    incorporated today.

 6. References

    [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
        RFC 1771, March 1995.

    [2] Chandra, R., Traina, P., and T. Li, "BGP Communities
        Attribute", RFC 1997, August 1996.

    [3] Chen, E., and T. Bates, "Application of the BGP Community
        Attribute in Multi-home Routing", RFC 1998, August 1996.

    [4] cisco systems, cisco IOS Software Version 12.0 - Configuring
        BGP,

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c
        /1cprt1/1cbgp.htm#28855
    [5] Bassam Halabi. 'Internet Routing Architecture', CiscoPress, 1997.

 6. Security Considerations

    Security issues are not discussed in this memo.

 7. Acknowledgments

    Thanks to Danny McPherson for reviewing this document and providing
    valuable feedback.

 8. Authors' Addresses

    Hank Nussbacher
    Internet and networking consultant
    POB 2366
    Kfar Saba 44425
    Israel
    Phone: +972 9 7663447
    EMail: [email-masked]

    Alexei Roudnev
    Senior network engineer
    The head of Network Operation Centre
    Relcom.DS network
    Pechorskaia ul. 6/2
    129344, Moscow, Russia.
    Phone: +7 095 194 1995
    Email: [email-masked]

    Susan Hares
    mail: [email-masked]

 Appendix

    These appendices list cisco and Juniper systems software specific
    configuration examples for configuring communities. These examples are
    given purely to show a working example of how the desired effect
    discussed in this document can be achieved. Please refer to [6] for more
    specific information on cisco configuration and syntax.

 Appendix A. Cisco specific examples
 
 A.1 Propagating Community values

    router bgp 65100
    ! Link to ISP1
    neighbor 192.168.102.1 remote-as 65111
    neighbor 192.168.102.1 send-community

    At the minimal, since Cisco routers by default do not propagate
    community values, the above should be implemented on all BGP peers.

 A.2 Simple Community Configuration

    router bgp 65100
    ! Link to ISP1
    neighbor 192.168.102.1 remote-as 65111
    neighbor 192.168.102.1 route-map to-ISP1 out
    neighbor 192.168.102.1 send-community
    !
    route-map to-ISP1 permit 10
    set community 0xFFFFFFEF

    This example simply adds a BGP community value of 0xFFFFFFEF.

    Note: In order to use standard decimal numbers in BGP community values
    in Cisco, one has to add in IOS:
    ip bgp-community new-format

 A.3 Changing the routing path based on a certain Community value

    router bgp 65111
    ! Link to ISP2
    neighbor 192.168.102.2 remote-as 65100
    neighbor 192.168.102.2 route-map from-ISP2 in
    neighbor 192.168.102.2 send-community
    !
    route-map to-ISP2 permit 10
    match community 0xFFFFFFEF
    ! Default localpref=100; setting localpref=200 forces traffic this way
    set local-preference 200

 Appendix B. Configuration examples for JUNOS.

    The example below should attach community of 65535:65519 to
    192.168.0.0/24 (exact) when advertising to peer 192.168.102.1, and
    community of 65535:65504 to 192.168.0.0/24 and advertise it to
    the peer, then deny all other.

  [snip]

  routing-options {
      autonomous-system 65100;
  }

  protocols {
      bgp {
             group ISP1 {
               type external;
               peer-as 65111;
               export to-ISP1;
               neighbor 192.168.102.1;
             }
      }
  }

  policy-options {
       policy-statement to-ISP1 {
           term 10 {
               from {
                   route-filter 192.168.0.0/24 exact;
               }
               then {
                   community add PREFER_ME;
                   next policy;
               }
           }
           term 20 {
               from {
                   route-filter 192.168.1.0/24 exact;
               }
               then {
                   community add AVOID_ME;
                   next policy;
               }
           }
           term 30 {
               then reject;
           }
       }
       community PREFER_ME members 65535:65519;
       community AVOID_ME  members 65535:65504;
  }

    This example should match communities from the peer, pref up PREFER_ME
    communities, and pref down AVOID_ME communities, then default to 100
    explicitly.

  [snip]

    routing-options {
      autonomous-system 65111;
  }

  protocols {
      bgp {
          group ISP2 {
              type external;
              peer-as 65100;
              import from-ISP2;
              neighbor 192.168.102.2;
          }
      }
  }
  policy-options {
      policy-statement from-ISP2 {
          term 10 {
              from community PREFER_ME;
              then {
                  local-preference 200;
                  next policy;
              }
          }
          term 20 {
              from community AVOID_ME;
              then {
                  local-preference 10;
                  next policy;
              }
          }
          term 30 {
              then {
                  local-preference 100;
                  next policy;
              }
          }
      }
      community PREFER_ME members 65535:65519;
      community AVOID_ME  members 65535:65504;
  }

 Appendix C.   GateD examples

 C.1: Appending new communities to some routes

 The example below appends the AVOID_ME community (0XFFFFFFE0) to
 some routes, and to another set of routes the PREFER_ME community
 (0XFFFFFFFEF).

 bgp yes {
	 group type external peeras 65001
		 {
		 peer 192.168.102.2;
		 };
	 };

 [snip]
 # export all routes from AS 65001 to 65002 and
 # export all routes from AS 65001 to 65002 and
 # add AVOID_ME
 #
 # add PREFER_ME
 #

 export proto bgp as 65002 add_comm {AVOID_ME;}
	 {
	 proto bgp peer as 65001 {
		 192.168.0.0 masklen 16 exact;
		 };
	 };

 export proto bgp as 65003 add_comm (PREFER_ME;};
	 {
	 proto bgp peer as 65001 {
		 192.168.1.0 masklen 24 exact;
		 };
	 };

 C.2 Changing the routing path based on a certain Community value

 bgp yes {
	 group type external peeras 65002
		 {
		 peer 192.168.102.2;
		 };
	 };

 #  avoid all networks received from AS 65002
 # high preference in GateD gives avoidance
 #
 import proto bgp as 65002 comm {AVOID_ME;} pref 245
	 {
	 all;    #all networks received from 65002 with AVOID_ME
	 };

 # low preference in GateD gives acceptance
 import proto BGP as 65002 comm { PREFER_ME; } pref 100
	 {
	 all;    # all networks received from 65002 with PREFER_ME
	 }