Re: Issue 19) Security Considerations

[Jeffrey Haas <[e-mail]>]

Curtis wrote in a previous message:

On Thu, Apr 03, 2003 at 09:36:06AM -0500, Curtis Villamizar wrote:
> --- draft-murphy-bgp-vuln-02.txt	Wed Mar  5 21:00:00 2003
> +++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
> @@ -149,6 +149,7 @@
>  3.2.2.2 Timer events ..............................................   16
>  4 Security Considerations .........................................   16
>  4.1 Residual Risk .................................................   16
> +4.2 Practical Considerations ......................................   16
>  5 References ......................................................   17
>  6 Author's Address ................................................   18
>  
> @@ -901,6 +902,79 @@
>  Filtering is in use near some customer attachment points, but is not
>  effective near the Internet center.  The other mechanisms are still
>  controversial and are not yet in common use.
> +
> +4.2 Practical Considerations
[...]

This looks like it has good merit.  Shouldn't we add this to the document?
(Well, not "we" since Sandy is authoring it, but it seems like a good idea.)

-- 
Jeff Haas 
NextHop Technologies



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA11861 for <[e-mail]>; Wed, 30 Apr 2003 12:41:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 716499126D; Wed, 30 Apr 2003 12:40:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EF5F91273; Wed, 30 Apr 2003 12:40:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B2949126D for <[e-mail]>; Wed, 30 Apr 2003 12:40:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2170D5DE6B; Wed, 30 Apr 2003 12:40:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [65.247.36.216]) by segue.merit.edu (Postfix) with ESMTP id E6D735DE0D for <[e-mail]>; Wed, 30 Apr 2003 12:40:44 -0400 (EDT)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h3UGei5A063949 for [e-mail]; Wed, 30 Apr 2003 12:40:44 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h3UGefWB063942 for <[e-mail]>; Wed, 30 Apr 2003 12:40:41 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h3UGeNp25708 for [e-mail]; Wed, 30 Apr 2003 12:40:23 -0400 (EDT)
Date: Wed, 30 Apr 2003 12:40:23 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <001b01c2f52e$48505480$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Apr 03, 2003 at 09:36:06AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Curtis wrote in a previous message:

On Thu, Apr 03, 2003 at 09:36:06AM -0500, Curtis Villamizar wrote:
> --- draft-murphy-bgp-vuln-02.txt	Wed Mar  5 21:00:00 2003
> +++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
> @@ -149,6 +149,7 @@
>  3.2.2.2 Timer events ..............................................   16
>  4 Security Considerations .........................................   16
>  4.1 Residual Risk .................................................   16
> +4.2 Practical Considerations ......................................   16
>  5 References ......................................................   17
>  6 Author's Address ................................................   18
>  
> @@ -901,6 +902,79 @@
>  Filtering is in use near some customer attachment points, but is not
>  effective near the Internet center.  The other mechanisms are still
>  controversial and are not yet in common use.
> +
> +4.2 Practical Considerations
[...]

This looks like it has good merit.  Shouldn't we add this to the document?
(Well, not "we" since Sandy is authoring it, but it seems like a good idea.)

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA01392 for <[e-mail]>; Sun, 27 Apr 2003 23:20:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C25F3912A9; Sun, 27 Apr 2003 23:19:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97D66912AA; Sun, 27 Apr 2003 23:19:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1054D912A9 for <[e-mail]>; Sun, 27 Apr 2003 23:19:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D4DF85DE83; Sun, 27 Apr 2003 23:19:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailout1.samsung.com (u24.gpu114.samsung.co.kr [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 7B9105DE66 for <[e-mail]>; Sun, 27 Apr 2003 23:19:42 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Mon, 28 Apr 2003 12:19:40 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 28 Apr 2003 12:19:39 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 28 Apr 2003 12:19:39 +0900 (KST)
Date: Mon, 28 Apr 2003 08:46:31 +0530
From: Manav Bhatia <[e-mail]>
Subject: draft-mcpherson-bgp4-expereince-00.txt
To: [e-mail]
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <00d001c30d34$929ae0f0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <00a301c30d30$4220c120$[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi Danny,
Some comments.

Going with what the introduction of the draft says that this document
"describes additional knowledge and understanding gained in the time
between when the protocol was made a Draft Standard and when it was
submitted for Standard".

>
>    Possible applications of BGP in the Internet are documented in [RFC
>    1772].
>
>    The BGP protocol was developed by the IDR Working Group of the
>    Internet Engineering Task Force. This Working Group had a mailing
>    list, [e-mail], where discussions of protocol features and

I think it'll be "has" :-)

>    operation are held. The IDR Working Group meets regularly during the
>    Internet Engineering Task Force meetings.  Reports of these meetings
>    are published in the IETF's Proceedings.

[snip]

>
> 8.  Internal BGP In Large Autonomous Systems

[snip]

>    BGP "Route Reflector" extensions has been defined in RFC 1966 to
>    alleviate the the need for "full mesh" IBGP.

Basically defined in 1966 and then updated in 2796.

Confederations? Though you did mention them in the section 5 - this seems
to be a better place for them!

>
> 9.  Internet Dynamics

We can also mention "BGP Route Flap Damping" [RFC 2439] here.

[snip]

> 14.  AS_SET Sorting
>
>
>    AS_SETs are commonly used in BGP route aggregation. They reduce the
>    size of AS_PATH information by listing AS numbers only once
>    regardless of any number of times it might appear in process of
>    aggregation. AS_SETs are usually sorted in increasing order to
>    facilitate efficient lookups of AS numbers within them. This
>    optimization is entirely optional.

I think that we can also mention that using AS_SET with the aggregate can
cause some route instabilities due to the fact that changes in the
attribute of the individual routes being summarized translate into changes
of the aggregate itself, causing the aggregate to be constantly withdrawn
and updated.

Do we need to mention Complex AS_PATH aggregation?

Regards,
Manav



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA00717 for <[e-mail]>; Fri, 25 Apr 2003 07:46:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3253F9124A; Fri, 25 Apr 2003 07:45:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3C939124B; Fri, 25 Apr 2003 07:45:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8966A9124A for <[e-mail]>; Fri, 25 Apr 2003 07:45:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 15FCF5E216; Fri, 25 Apr 2003 07:45:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 3C3F75DE7F for <[e-mail]>; Fri, 25 Apr 2003 07:45:13 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03423; Fri, 25 Apr 2003 07:42:26 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-mcpherson-bgp4-expereince-00.txt
Date: Fri, 25 Apr 2003 07:42:26 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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


	Title		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-mcpherson-bgp4-expereince-00.txt
	Pages		: 19
	Date		: 2003-4-24
	
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for 'the second report', as
described in Section 6.0 of RFC 1264.  In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-mcpherson-bgp4-expereince-00.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA21338 for <[e-mail]>; Thu, 24 Apr 2003 09:53:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CF41591231; Thu, 24 Apr 2003 09:53:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E11A91232; Thu, 24 Apr 2003 09:53:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A79391231 for <[e-mail]>; Thu, 24 Apr 2003 09:52:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 62C0B5E3C1; Thu, 24 Apr 2003 09:52:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id ED7E05E3C0 for <[e-mail]>; Thu, 24 Apr 2003 09:52:56 -0400 (EDT)
Received: from rtp-cse-489.cisco.com (rtp-cse-489.cisco.com [64.102.51.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3ODqrlY006642; Thu, 24 Apr 2003 09:52:54 -0400 (EDT)
Received: from localhost (dwalton@localhost) by rtp-cse-489.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id h3ODqrS29835; Thu, 24 Apr 2003 09:52:53 -0400 (EDT)
Date: Thu, 24 Apr 2003 09:52:53 -0400 (EDT)
From: Daniel Walton <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP ECMP 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

                       ________________      iBGP       ______________
                       |     RR       |-----------------| non-Client |
                       |  4.0.4.43    |     (IGP : 235) | 4.0.0.106  |
                       |______________|                 |____________|
                              |                               \
                              | iBGP                           \
                              | (IGP : 60)                      \
                              |                               AS : 5646
                       _______|________                       MED: 1000
                       |    Client    |
                       |   4.0.0.10   |
                       |______________|
                         /         \
                  eBGP  /           \ eBGP
                       /             \
                      /               \
                eBGP-1                 eBGP-2
             AS  : 5696              AS  : 5646
             MED : 1000              MED : 10000
             Rid : 209.54.136.8      Rid : 207.112.244.49


Assumptions:
- * indicates the bestpath
- deterministic-med is configured

Step 1 - init state
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5696    1000    E       0       209.54.136.8
                *5646   10000   E       0       207.112.244.49
RR              -       -       -       -       -
non-Client      *5646   1000    E       0       -


Step 2 - Client and non-Client advertise bestpaths to RR
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5696    1000    E       0       209.54.136.8
                *5646   10000   E       0       207.112.244.49
RR              5646    10000   I       60      207.112.244.49
                *5646   1000    I       235     -
non-Client      *5646   1000    E       0       -


Step 3 - RR advertises bestpath to Client
       - Client selects eBGP-1 path as best
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5646    1000    I       295     -
                5646    10000   E       0       207.112.244.49
                *5696   1000    E       0       209.54.136.8
RR              5646    10000   I       60      207.112.244.49
                *5646   1000    I       235     -
non-Client      *5646   1000    E       0       -


Step 4 - RR selects eBGP-1 path as best
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5646    1000    I       295     -
                5646    10000   E       0       207.112.244.49
                *5696   1000    E       0       209.54.136.8
RR              *5696   1000    I       60      209.54.136.8
                5646    1000    I       235     -
non-Client      *5646   1000    E       0       -


Step 5 - RR withdraws his previous advertisement of 5646, MED 1000
       - Client is left with two external paths.  If he changes bestpath
         based on router-id then we will be back to step 2 (RR will know
         about eBGP-2 from Client and 5646, MED 1000 from non-client) and
         we are in MED oscillation.  If he prefers to keep his
         current bestpath then we do not oscillate.
                AS      MED     E/I     IGP     ID
                --      ---     ---     ---     --
Client          5646    10000   E       0       207.112.244.49
                5696    1000    E       0       209.54.136.8
RR              *5696   1000    I       60      209.54.136.8
                5646    1000    I       235     -
non-Client      *5646   1000    E       0       -



One point of confusion here is that the docs say we prefer the older external
path. A more accurate description is that we won't make the bestpath change if
we are comparing two external paths and make it to the router-id step in the
decision process.

Call it non-deterministic if you want but it solves MED churn in this scenario
and I have never heard a customer complain.  If they decide to start
complaining, we have a knob they can turn to enforce the router-id check.

Daniel



On Wed, 23 Apr 2003, Pedro Roque Marques wrote:

> Daniel Walton writes:
>
> Daniel,
> I don't think your message really addresses my question.
>
> > MED oscillation happens in this topology when we change our bestpath
> > based only on a difference in router-id.
>
> That is not acurate... MED oscillation happens when you have a
> circular dependency. The "oldest external" rule will, in 50% of the
> cases, on the previous example yield the same result as if you would
> select these paths based router-id. i.e. whenever the 'oldest
> external' is the lowest router-id the result is the exact same.
>
> Thus i don't think you can claim that this solves the problem that you
> mention. Although you may claim to make it less likely... at the
> expense of making it even less predictable.
>
> >  It is easy to stop the
> > oscillation here by preferring the 'oldest external' instead of
> > making a bestpath change over a router-id change which is fairly
> > arbitrary.  If only the other variations of MED churn where this
> > easy to solve :)
>
> I don't understand how the 'oldest external' rule as currently
> documented by cisco stops oscillation.
>
> It would be great if you could provide more details to substantiate
> this claim.
>
> > There is a knob to enforce the router-id comparison step if the user
> > desires.
>
> We are discussing what the 'oldest external' rule buys you and
> potential disadvantages. I'm trying to understand the
> implications...
>
> thanks,
>   Pedro.
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA20894 for <[e-mail]>; Thu, 24 Apr 2003 08:43:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B0E1B91227; Thu, 24 Apr 2003 08:43:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7882591228; Thu, 24 Apr 2003 08:43:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3395791227 for <[e-mail]>; Thu, 24 Apr 2003 08:43:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1F9AD5E39D; Thu, 24 Apr 2003 08:43:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id A17ED5E361 for <[e-mail]>; Thu, 24 Apr 2003 08:43:29 -0400 (EDT)
Received: from rtp-cse-489.cisco.com (rtp-cse-489.cisco.com [64.102.51.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3OCfclY017009; Thu, 24 Apr 2003 08:41:43 -0400 (EDT)
Received: from localhost (dwalton@localhost) by rtp-cse-489.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id h3OCfce29605; Thu, 24 Apr 2003 08:41:38 -0400 (EDT)
Date: Thu, 24 Apr 2003 08:41:38 -0400 (EDT)
From: Daniel Walton <[e-mail]>
To: Mareline Sheldon <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-walton-bgp-add-paths-01.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

My bad, I thought we included a section on possible solutions but in the end we
put in "It should be stated that protocol enhancements regarding this problem
must be pursued.  Imposing network design requirements, such as those outlined
above, are clearly an unreasonable long-term solution.  Problems such as this
should not occur under 'default' protocol configurations."

One possible solution for MED churn is to advertise your bestpath per
neighbor-AS in addition to your bestpath.  For the topo in 3.1, Rc and Rd would
need to advertise the AS 200/MED 0 path to Re in order to stop the oscillation.
There is still work to be done to determine when you should/should not advertise
extra paths in order to prevent MED churn but not carry lots of extra paths for
nothing.

Daniel

On Wed, 23 Apr 2003, Mareline Sheldon wrote:

> Dan,
>
> >
> > > 2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
> > > indicates that the path associated with the NLRI has been selected by the
> > > BGP speaker for installation into its FIB. If set to zero, then the path is
> > > not selected. Why would we ever want to advertise a path which has not been
> > > selected by BGP? If it is to withdraw a previously advertised path then a
> > > better approach would be to send it in the WITHDRAW field.
> > >
> >
> > To solve MED churn, see RFC 3345
>
> How does advertising a path which is not being used by BGP solve the MED churn. I could not
> find anything in RFC 3345 which talks of this.
>
> Regards,
> Mareline S.
>
>
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
>




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA20552 for <[e-mail]>; Thu, 24 Apr 2003 07:34:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B02F991223; Thu, 24 Apr 2003 07:34:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BDF291224; Thu, 24 Apr 2003 07:34:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36F8891223 for <[e-mail]>; Thu, 24 Apr 2003 07:34:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1744F5E352; Thu, 24 Apr 2003 07:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 6826C5E34E for <[e-mail]>; Thu, 24 Apr 2003 07:34:32 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11382; Thu, 24 Apr 2003 07:31:45 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-02.txt
Date: Thu, 24 Apr 2003 07:31:45 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: BGP-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-02.txt
	Pages		: 19
	Date		: 2003-4-23
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA18193 for <[e-mail]>; Thu, 24 Apr 2003 01:56:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D3B129121F; Thu, 24 Apr 2003 01:56:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D42291220; Thu, 24 Apr 2003 01:56:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74DEE9121F for <[e-mail]>; Thu, 24 Apr 2003 01:56:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4D8EC5E2C2; Thu, 24 Apr 2003 01:56:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by segue.merit.edu (Postfix) with SMTP id A40535E2BC for <[e-mail]>; Thu, 24 Apr 2003 01:56:02 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20301.mail.yahoo.com via HTTP; Wed, 23 Apr 2003 22:56:02 PDT
Date: Wed, 23 Apr 2003 22:56:02 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: Re: draft-walton-bgp-add-paths-01.txt
To: Daniel Walton <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Dan,

> 
> > 2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
> > indicates that the path associated with the NLRI has been selected by the
> > BGP speaker for installation into its FIB. If set to zero, then the path is
> > not selected. Why would we ever want to advertise a path which has not been
> > selected by BGP? If it is to withdraw a previously advertised path then a
> > better approach would be to send it in the WITHDRAW field.
> >
> 
> To solve MED churn, see RFC 3345

How does advertising a path which is not being used by BGP solve the MED churn. I could not
find anything in RFC 3345 which talks of this.

Regards,
Mareline S.



__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA12131 for <[e-mail]>; Wed, 23 Apr 2003 17:11:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EF7809121C; Wed, 23 Apr 2003 17:10:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF2819121E; Wed, 23 Apr 2003 17:10:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61FC89121C for <[e-mail]>; Wed, 23 Apr 2003 17:10:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4CBA35E1F9; Wed, 23 Apr 2003 17:10:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 019145E17C for <[e-mail]>; Wed, 23 Apr 2003 17:10:47 -0400 (EDT)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3NLAlu15847; Wed, 23 Apr 2003 14:10:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h3NLAls26116; Wed, 23 Apr 2003 14:10:47 -0700 (PDT) (envelope-from roque)
Date: Wed, 23 Apr 2003 14:10:47 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Daniel Walton <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP ECMP 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Daniel Walton writes:

Daniel,
I don't think your message really addresses my question.

> MED oscillation happens in this topology when we change our bestpath
> based only on a difference in router-id.

That is not acurate... MED oscillation happens when you have a
circular dependency. The "oldest external" rule will, in 50% of the
cases, on the previous example yield the same result as if you would
select these paths based router-id. i.e. whenever the 'oldest
external' is the lowest router-id the result is the exact same.

Thus i don't think you can claim that this solves the problem that you
mention. Although you may claim to make it less likely... at the
expense of making it even less predictable.

>  It is easy to stop the
> oscillation here by preferring the 'oldest external' instead of
> making a bestpath change over a router-id change which is fairly
> arbitrary.  If only the other variations of MED churn where this
> easy to solve :)

I don't understand how the 'oldest external' rule as currently
documented by cisco stops oscillation.

It would be great if you could provide more details to substantiate
this claim.

> There is a knob to enforce the router-id comparison step if the user
> desires.

We are discussing what the 'oldest external' rule buys you and
potential disadvantages. I'm trying to understand the
implications...

thanks,
  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA11378 for <[e-mail]>; Wed, 23 Apr 2003 16:25:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5829791214; Wed, 23 Apr 2003 16:24:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23BA291217; Wed, 23 Apr 2003 16:24:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B28FF91214 for <[e-mail]>; Wed, 23 Apr 2003 16:24:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 967865E1E1; Wed, 23 Apr 2003 16:24:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 2E5C85DDBD for <[e-mail]>; Wed, 23 Apr 2003 16:24:57 -0400 (EDT)
Received: from rtp-cse-489.cisco.com (rtp-cse-489.cisco.com [64.102.51.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3NKOslY008518; Wed, 23 Apr 2003 16:24:54 -0400 (EDT)
Received: from localhost (dwalton@localhost) by rtp-cse-489.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id h3NKOsi25430; Wed, 23 Apr 2003 16:24:54 -0400 (EDT)
Date: Wed, 23 Apr 2003 16:24:54 -0400 (EDT)
From: Daniel Walton <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP ECMP 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 23 Apr 2003, Pedro Roque Marques wrote:

> Daniel Walton writes:
>
> Daniel,
>
> > 9. The BGP scanner which runs once in a minute (which explains the
> > periodicity in maeeast router) validates the nexthop and calculates
> > the bestpath. At this stage, eBGP-2 is picked up as best due to
> > lower router-id.
>
> If i understand your text correctly, it is at this stage that the new
> rule of using the "oldest" of the external routes comes into play.
>
> But it would seem to me that you have 50-50 chance that the oldest
> route is the same as the lowest router-id, thus causing a loop again.
>

MED oscillation happens in this topology when we change our bestpath based only
on a difference in router-id.  It is easy to stop the oscillation here by
preferring the 'oldest external' instead of making a bestpath change over a
router-id change which is fairly arbitrary.  If only the other variations of MED
churn where this easy to solve :)

There is a knob to enforce the router-id comparison step if the user desires.

Daniel

> It seems to me that introducing this non-deterministic step wouldn't
> fix the MED oscillation problem... it just makes it non-deterministic
> when the problem will occur. Which is not necessarly a feature...
>
> regards,
>   Pedro.
>




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08738 for <[e-mail]>; Wed, 23 Apr 2003 13:52:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7079391212; Wed, 23 Apr 2003 13:51:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4421691214; Wed, 23 Apr 2003 13:51:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD1E491212 for <[e-mail]>; Wed, 23 Apr 2003 13:51:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BE9965E1BE; Wed, 23 Apr 2003 13:51:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 431EA5E1BC for <[e-mail]>; Wed, 23 Apr 2003 13:51:39 -0400 (EDT)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3NHpcu98454; Wed, 23 Apr 2003 10:51:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h3NHpcP25767; Wed, 23 Apr 2003 10:51:38 -0700 (PDT) (envelope-from roque)
Date: Wed, 23 Apr 2003 10:51:38 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Daniel Walton <[e-mail]>
Cc: <[e-mail]>
Subject: Re: BGP ECMP 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Daniel Walton writes:

Daniel,

> 9. The BGP scanner which runs once in a minute (which explains the
> periodicity in maeeast router) validates the nexthop and calculates
> the bestpath. At this stage, eBGP-2 is picked up as best due to
> lower router-id.

If i understand your text correctly, it is at this stage that the new
rule of using the "oldest" of the external routes comes into play.

But it would seem to me that you have 50-50 chance that the oldest
route is the same as the lowest router-id, thus causing a loop again.

It seems to me that introducing this non-deterministic step wouldn't
fix the MED oscillation problem... it just makes it non-deterministic
when the problem will occur. Which is not necessarly a feature...

regards,
  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06638 for <[e-mail]>; Wed, 23 Apr 2003 11:40:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7BCB091213; Wed, 23 Apr 2003 11:40:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 476BE91214; Wed, 23 Apr 2003 11:40:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A174C91213 for <[e-mail]>; Wed, 23 Apr 2003 11:40:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8A0935E19F; Wed, 23 Apr 2003 11:40:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 2117C5E0D1 for <[e-mail]>; Wed, 23 Apr 2003 11:40:39 -0400 (EDT)
Received: from rtp-cse-489.cisco.com (rtp-cse-489.cisco.com [64.102.51.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3NFeTlY016021; Wed, 23 Apr 2003 11:40:29 -0400 (EDT)
Received: from localhost (dwalton@localhost) by rtp-cse-489.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id h3NFeS824229; Wed, 23 Apr 2003 11:40:28 -0400 (EDT)
Date: Wed, 23 Apr 2003 11:40:28 -0400 (EDT)
From: Daniel Walton <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: Curtis Villamizar <[e-mail]>, Russ White <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: BGP ECMP 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 22 Apr 2003, Pedro Roque Marques wrote:

> Daniel Walton writes:
>
> >> The last step in the route selection being either router-id based
> >> or first come based is called deterministic or non-deterministic.
> >> The spec calls for deterministic selection.  If you have a route
> >> flap and the stable route is the least preferred, then
> >> deterministic selection causes a lot of route change.  The obvious
> >> answer is to damp the route flap.
>
> > Changing bestpath based on router-id can cause MED churn in some
> > topologies.
>
> >> Some providers insist on using the non-deterministic route
> >> selection (first route to arrive is preferred) then wonder why they
> >> occasionally get a few persistant route loops.
>
> > Do you have an example of when this will loop?
>
> It is not clear to me if you folks are talking about the same thing...
>
> There are two non deterministic steps in cisco's path selection as
> publicly documented(1):
> a) non-"bgp deterministic med"
> b) Step 10 (of the public algorithm) "When both paths are external,
> prefer the path that was received first".
>
> The first can only be described as a bug and can indeed lead to
> routing loops as it has been found in the field. The latter cannot
> cause routing loops as far as i can see. Selection between external
> paths can be considered a local matter.
>
> What i'm not clear about is how this rule, as documented, avoids MED
> oscillation. Would you mind giving an example ?
>
> (1) http://www.cisco.com/warp/public/459/25.shtml


This is from several years ago, before we knew what MED oscillation was:



                       ________________      iBGP       ______________
                       |     RR       |-----------------| non-Client |
                       |  4.0.4.43    |     (IGP : 235) | 4.0.0.106  |
                       |______________|                 |____________|
                              |                               \
                              | iBGP                           \
                              | (IGP : 60)                      \
                              |                               AS : 5646
                       _______|________                       MED: 1000
                       |    Client    |
                       |   4.0.0.10   |
                       |______________|
                         /         \
                  eBGP  /           \ eBGP
                       /             \
                      /               \
                eBGP-1                 eBGP-2
             AS  : 5696              AS  : 5646
             MED : 1000              MED : 10000
             Rid : 209.54.136.8      Rid : 207.112.244.49

1. Client selects eBGP-2 (MED 10000) due to router-id as the bestpath
initially. (MED is not comparable since neighboring-AS are different).

2. Client advertises this path to RR.

3. RR has 2 iBGP paths, one from non-client and another from client. It
selects the one from non-client (MED being lower).

4. RR reflects the bestpath (MED 1000) to client.

5. Client now has 3 paths, 2 eBGP and 1 iBGP. It selects eBGP-1 (MED 1000)
since iBGP path wins over eBGP-2 on MED, eBGP-1 wins over iBGP since we
prefer external over internal.

6. Client now advertises the current bestpath (MED 1000)  to RR.

7. RR which has 2 iBGP paths picks up the path from Client based on the IGP
distance as best. It poisons the route to client.

8. Client which receives the withdraw from RR silently discards it since
the iBGP path was not the current best. We calculate the bestpath only when
current bestpath is withdrawn.

9. The BGP scanner which runs once in a minute (which explains the
periodicity in maeeast router) validates the nexthop and calculates the
bestpath. At this stage, eBGP-2 is picked up as best due to lower
router-id.

10. Client advertises the new bestpath to RR and cycles again...



Daniel



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA25090 for <[e-mail]>; Tue, 22 Apr 2003 23:10:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 78D4691277; Tue, 22 Apr 2003 23:10:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4069191278; Tue, 22 Apr 2003 23:10:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB9D991277 for <[e-mail]>; Tue, 22 Apr 2003 23:10:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D97605E002; Tue, 22 Apr 2003 23:10:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailout1.samsung.com (u24.gpu114.samsung.co.kr [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 8DEC25DFFE for <[e-mail]>; Tue, 22 Apr 2003 23:10:11 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Wed, 23 Apr 2003 12:10:04 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 23 Apr 2003 12:10:04 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 23 Apr 2003 12:10:04 +0900 (KST)
Date: Wed, 23 Apr 2003 08:37:07 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: BGP ECMP
To: Russ White <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <02eb01c30945$6dc8b790$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <074a01c307f1$ce8e7060$[e-mail]> <[e-mail]> <000a01c3080a$26e3bbe0$[e-mail]> <Pine.WNT.4.53.0304221349461.528@russpc>
Sender: [e-mail]
Precedence: bulk

Russ,

> It's based on the local bestpath decision--the older route, or the better
> router id, if you're straight by the spec. What you normally do is to
> exclude some portion of the bestpath algorithm, usually just the router
id,
> to determine "equal cost" paths.

Right.

But the point is that you're still advertising only one best route to your
other peers (based on the age of the route/router ID/etc) while you may
yourself be injecting multiple entries in your FIB. It is possible
(especially in IBGP) to think of a scenario where if you advertise multiple
routes to your peer then it may be in a position to use them for its own
forwarding.

This becomes more of an issue when deploying RRs as they will be connected
to a lot of IBGP peers and it might be recieving multiple "equal cost" BGP
routes (which it might insert in its FIB) while it would be advertising
only the *best* one out and thus depriving the other peers to use those
multiple routes for load balancing.

Regards,
Manav



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA24458 for <[e-mail]>; Tue, 22 Apr 2003 22:33:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 183CB91274; Tue, 22 Apr 2003 22:33:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC0CF91277; Tue, 22 Apr 2003 22:33:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A159F91274 for <[e-mail]>; Tue, 22 Apr 2003 22:33:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 86B145DFBC; Tue, 22 Apr 2003 22:33:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id BBB4A5DEAB for <[e-mail]>; Tue, 22 Apr 2003 22:33:12 -0400 (EDT)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA61550; Tue, 22 Apr 2003 22:33:46 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Daniel Walton <[e-mail]>
Cc: Curtis Villamizar <[e-mail]>, Russ White <[e-mail]>, Manav Bhatia <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: BGP ECMP 
In-reply-to: Your message of "Tue, 22 Apr 2003 16:43:43 EDT." <[e-mail]> 
Date: Tue, 22 Apr 2003 22:33:46 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Dan
iel Walton writes:
> On Tue, 22 Apr 2003, Curtis Villamizar wrote:
> 
> 
> > Some providers insist on using the non-deterministic route selection (first
> > route to arrive is preferred) then wonder why they occasionally get a few
> > persistant route loops.
> 
> Do you have an example of when this will loop?
> 
> Daniel


You are right.  It is the non-deterministic-med that can loop.

The deterministic next hop only affects where traffic goes in the
normal everything up situation.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA20522 for <[e-mail]>; Tue, 22 Apr 2003 19:21:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D35D09125F; Tue, 22 Apr 2003 19:20:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EF2791266; Tue, 22 Apr 2003 19:20:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A5949125F for <[e-mail]>; Tue, 22 Apr 2003 19:20:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 522405DFCC; Tue, 22 Apr 2003 19:20:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 0615C5DFCB for <[e-mail]>; Tue, 22 Apr 2003 19:20:32 -0400 (EDT)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3MNKDu34484; Tue, 22 Apr 2003 16:20:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h3MNKCY23971; Tue, 22 Apr 2003 16:20:12 -0700 (PDT) (envelope-from roque)
Date: Tue, 22 Apr 2003 16:20:12 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Daniel Walton <[e-mail]>
Cc: Curtis Villamizar <[e-mail]>, Russ White <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: BGP ECMP 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Daniel Walton writes:

>> The last step in the route selection being either router-id based
>> or first come based is called deterministic or non-deterministic.
>> The spec calls for deterministic selection.  If you have a route
>> flap and the stable route is the least preferred, then
>> deterministic selection causes a lot of route change.  The obvious
>> answer is to damp the route flap.

> Changing bestpath based on router-id can cause MED churn in some
> topologies.

>> Some providers insist on using the non-deterministic route
>> selection (first route to arrive is preferred) then wonder why they
>> occasionally get a few persistant route loops.

> Do you have an example of when this will loop?

It is not clear to me if you folks are talking about the same thing...

There are two non deterministic steps in cisco's path selection as
publicly documented(1):
a) non-"bgp deterministic med"
b) Step 10 (of the public algorithm) "When both paths are external,
prefer the path that was received first".

The first can only be described as a bug and can indeed lead to
routing loops as it has been found in the field. The latter cannot
cause routing loops as far as i can see. Selection between external
paths can be considered a local matter.

What i'm not clear about is how this rule, as documented, avoids MED
oscillation. Would you mind giving an example ?

(1) http://www.cisco.com/warp/public/459/25.shtml

  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17664 for <[e-mail]>; Tue, 22 Apr 2003 17:03:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 749799126C; Tue, 22 Apr 2003 17:03:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 444A79126E; Tue, 22 Apr 2003 17:03:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F18629126C for <[e-mail]>; Tue, 22 Apr 2003 17:03:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D99695DF8E; Tue, 22 Apr 2003 17:03:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 69CBA5DF8D for <[e-mail]>; Tue, 22 Apr 2003 17:03:22 -0400 (EDT)
Received: from rtp-cse-489.cisco.com (rtp-cse-489.cisco.com [64.102.51.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3ML3K4W001795; Tue, 22 Apr 2003 17:03:20 -0400 (EDT)
Received: from localhost (dwalton@localhost) by rtp-cse-489.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id h3ML3J519870; Tue, 22 Apr 2003 17:03:19 -0400 (EDT)
Date: Tue, 22 Apr 2003 17:03:19 -0400 (EDT)
From: Daniel Walton <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-walton-bgp-add-paths-01.txt
In-Reply-To: <00d701c30889$27328570$[e-mail]>
Message-ID: <[e-mail]>
References: <00d701c30889$27328570$[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 22 Apr 2003, Manav Bhatia wrote:

> Hello,
> Some comments on the above stated draft to start with.
>
> 1. The length of the Identifier has been kept as 2 octets. Are we anticipating
> 2^16 ECMP BGP routes? I think we can use the remaining bits from the Flags to
> make our IP prefixes unique. Even if we want some space reserved for future
> extensions we don't need to keep 2 octets for making the prefix unique!
>

ack, we'll take a look at this


> 2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
> indicates that the path associated with the NLRI has been selected by the
> BGP speaker for installation into its FIB. If set to zero, then the path is
> not selected. Why would we ever want to advertise a path which has not been
> selected by BGP? If it is to withdraw a previously advertised path then a
> better approach would be to send it in the WITHDRAW field.
>

To solve MED churn, see RFC 3345


> 3. What happens when a router has already advertised some ECMP routes and
> it later receives a new ECMP BGP route. How does it advertise this one to
> its neighbors? The problem is that it would have advertised its last ECMP
> BGP route with the Lastbit set (which indicates that the particular path is
> the last one in the UPDATE message for that prefix). To now advertise this
> new path does it readvertise all the paths to that prefix OR does it just
> advertise the new path information with Bestpath bit set, FirstPath bit
> unset and LastBit set/unset (I don't know!)
>
> This seems to be ambiguous in the draft and can be worked upon.
>

Right now the plan is to remove the Lastpath section from the draft.  There are
to many cases where it causes problems.

> 4. The draft does not mention the changes required in the Decision Process.
> How does a router decide that the two BGP routes that it has are of the
> same cost?
>

hmm, so if a peer advertises me two paths with the same attributes the bestpath
decision needs a way to declare one better than the other since both paths have
the same router-id.  We can add something stating that the add-path ID can be
used as a tie-breaker in this scenario.


> 5. The Flags and the Identifier fields have been explained thrice in
> sections 2.2.1, 2.2.2. and 2.2.3. I think we can manage with just one.
>

This will be cleaned up in the next revision.

Thanks
Daniel




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA17252 for <[e-mail]>; Tue, 22 Apr 2003 16:44:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A7D469126B; Tue, 22 Apr 2003 16:44:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6333E9126C; Tue, 22 Apr 2003 16:44:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1842E9126B for <[e-mail]>; Tue, 22 Apr 2003 16:43:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F0D985DF83; Tue, 22 Apr 2003 16:43:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 862DE5DF76 for <[e-mail]>; Tue, 22 Apr 2003 16:43:58 -0400 (EDT)
Received: from rtp-cse-489.cisco.com (rtp-cse-489.cisco.com [64.102.51.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3MKhi4W025157; Tue, 22 Apr 2003 16:43:44 -0400 (EDT)
Received: from localhost (dwalton@localhost) by rtp-cse-489.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id h3MKhiY19640; Tue, 22 Apr 2003 16:43:44 -0400 (EDT)
Date: Tue, 22 Apr 2003 16:43:43 -0400 (EDT)
From: Daniel Walton <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Cc: Russ White <[e-mail]>, Manav Bhatia <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: BGP ECMP 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 22 Apr 2003, Curtis Villamizar wrote:

>
> In message <Pine.WNT.4.53.0304221349461.528@russpc>, Russ White writes:
> >
> > > > Before I comment on some your questions posted I think it is worth to
> > > > keep in mind that until now most of those implementations you may be
> > > > refering to treat multipath as a local to the box feature. As far as
> > > > advertisements to i/eBGP peers only best path is advertised as usual.
> > >
> > > What is taken as the *best* path?
> > >
> > > Say both the routes have equal AS-path lengths, LPs, etc. So which one is
> > > advertised to the downstream peers? Won't the second advertisement (if
> > > both are sent) be taken as an implict withdraw by the other peers? I thus
> > > dont think its an issue local to the box implementing multi-path.
> >
> > It's based on the local bestpath decision--the older route, or the better
> > router id, if you're straight by the spec. What you normally do is to
> > exclude some portion of the bestpath algorithm, usually just the router id,
> > to determine "equal cost" paths.
>
> The last step in the route selection being either router-id based or
> first come based is called deterministic or non-deterministic.  The
> spec calls for deterministic selection.  If you have a route flap and
> the stable route is the least preferred, then deterministic selection
> causes a lot of route change.  The obvious answer is to damp the route
> flap.

Changing bestpath based on router-id can cause MED churn in some topologies.


> Some providers insist on using the non-deterministic route selection (first
> route to arrive is preferred) then wonder why they occasionally get a few
> persistant route loops.

Do you have an example of when this will loop?


Daniel

> The deterministic selection is free of persistant route loops.
> Non-deterministic selection is not free of persistant route loops and
> that is why it is a MUST in the spec.  Some providers ask for it,
> therefore non-deterministic selection is an option on most routers.
>
> > > > Hence there is no obvious interoperability problems in mutlipath as
> > > > such.
> > >
> > > I see an obvious interoperability issue because the routes which are used
> > > and advertised by this particular router directly affects the other
> > > routers (downstream).
> >
> > A downstream router will have no idea an upstream router is doing
> > multipath. The advertisements it receives will be the same either way.
> >
> > :-)
>
> Right.
>
> > Russ
>
> Curtis
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA16289 for <[e-mail]>; Tue, 22 Apr 2003 15:55:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B343D91268; Tue, 22 Apr 2003 15:52:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DBFE9126B; Tue, 22 Apr 2003 15:52:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CD9991268 for <[e-mail]>; Tue, 22 Apr 2003 15:52:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4FC845DF4F; Tue, 22 Apr 2003 15:52:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 438EB5DE9B for <[e-mail]>; Tue, 22 Apr 2003 15:52:44 -0400 (EDT)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA57251; Tue, 22 Apr 2003 15:44:50 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Russ White <[e-mail]>
Cc: Manav Bhatia <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: BGP ECMP 
In-reply-to: Your message of "Tue, 22 Apr 2003 13:52:49 EDT." <Pine.WNT.4.53.0304221349461.528@russpc> 
Date: Tue, 22 Apr 2003 15:44:50 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <Pine.WNT.4.53.0304221349461.528@russpc>, Russ White writes:
> 
> > > Before I comment on some your questions posted I think it is worth to
> > > keep in mind that until now most of those implementations you may be
> > > refering to treat multipath as a local to the box feature. As far as
> > > advertisements to i/eBGP peers only best path is advertised as usual.
> >
> > What is taken as the *best* path?
> >
> > Say both the routes have equal AS-path lengths, LPs, etc. So which one is
> > advertised to the downstream peers? Won't the second advertisement (if
> > both are sent) be taken as an implict withdraw by the other peers? I thus
> > dont think its an issue local to the box implementing multi-path.
> 
> It's based on the local bestpath decision--the older route, or the better
> router id, if you're straight by the spec. What you normally do is to
> exclude some portion of the bestpath algorithm, usually just the router id,
> to determine "equal cost" paths.

The last step in the route selection being either router-id based or
first come based is called deterministic or non-deterministic.  The
spec calls for deterministic selection.  If you have a route flap and
the stable route is the least preferred, then deterministic selection
causes a lot of route change.  The obvious answer is to damp the route
flap.  Some providers insist on using the non-deterministic route
selection (first route to arrive is preferred) then wonder why they
occasionally get a few persistant route loops.

The deterministic selection is free of persistant route loops.
Non-deterministic selection is not free of persistant route loops and
that is why it is a MUST in the spec.  Some providers ask for it,
therefore non-deterministic selection is an option on most routers.

> > > Hence there is no obvious interoperability problems in mutlipath as
> > > such.
> >
> > I see an obvious interoperability issue because the routes which are used
> > and advertised by this particular router directly affects the other
> > routers (downstream).
> 
> A downstream router will have no idea an upstream router is doing
> multipath. The advertisements it receives will be the same either way.
> 
> :-)

Right.

> Russ

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13040 for <[e-mail]>; Tue, 22 Apr 2003 13:53:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0481791260; Tue, 22 Apr 2003 13:53:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C839091262; Tue, 22 Apr 2003 13:53:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 468A591260 for <[e-mail]>; Tue, 22 Apr 2003 13:53:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 27CAC5DF5B; Tue, 22 Apr 2003 13:53:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id B39785DF37 for <[e-mail]>; Tue, 22 Apr 2003 13:53:23 -0400 (EDT)
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3MHrLh9021235; Tue, 22 Apr 2003 13:53:21 -0400 (EDT)
Received: from russpc (rtp-vpn2-993.cisco.com [10.82.243.225]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA09677; Tue, 22 Apr 2003 13:53:20 -0400 (EDT)
Date: Tue, 22 Apr 2003 13:52:49 -0400 (Eastern Daylight Time)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: BGP ECMP
In-Reply-To: <000a01c3080a$26e3bbe0$[e-mail]>
Message-ID: <Pine.WNT.4.53.0304221349461.528@russpc>
References: <074a01c307f1$ce8e7060$[e-mail]> <[e-mail]> <000a01c3080a$26e3bbe0$[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> > Before I comment on some your questions posted I think it is worth to
> > keep in mind that until now most of those implementations you may be
> > refering to treat multipath as a local to the box feature. As far as
> > advertisements to i/eBGP peers only best path is advertised as usual.
>
> What is taken as the *best* path?
>
> Say both the routes have equal AS-path lengths, LPs, etc. So which one is
> advertised to the downstream peers? Won't the second advertisement (if
> both are sent) be taken as an implict withdraw by the other peers? I thus
> dont think its an issue local to the box implementing multi-path.

It's based on the local bestpath decision--the older route, or the better
router id, if you're straight by the spec. What you normally do is to
exclude some portion of the bestpath algorithm, usually just the router id,
to determine "equal cost" paths.

> > Hence there is no obvious interoperability problems in mutlipath as
> > such.
>
> I see an obvious interoperability issue because the routes which are used
> and advertised by this particular router directly affects the other
> routers (downstream).

A downstream router will have no idea an upstream router is doing
multipath. The advertisements it receives will be the same either way.

:-)

Russ


--
[e-mail] CCIE <>< Grace Alone


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA27759 for <[e-mail]>; Tue, 22 Apr 2003 07:43:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7FC9A91259; Tue, 22 Apr 2003 07:42:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4328E9125A; Tue, 22 Apr 2003 07:42:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 048A391259 for <[e-mail]>; Tue, 22 Apr 2003 07:42:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DBDF45DF17; Tue, 22 Apr 2003 07:42:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 61D6B5DF16 for <[e-mail]>; Tue, 22 Apr 2003 07:42:42 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03274; Tue, 22 Apr 2003 07:39:57 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-01.txt
Date: Tue, 22 Apr 2003 07:39:56 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: BGP-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-01.txt
	Pages		: 19
	Date		: 2003-4-21
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA18267 for <[e-mail]>; Tue, 22 Apr 2003 00:42:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 98F5F9124F; Tue, 22 Apr 2003 00:42:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6891591252; Tue, 22 Apr 2003 00:42:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F15BE9124F for <[e-mail]>; Tue, 22 Apr 2003 00:42:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D489B5DE6D; Tue, 22 Apr 2003 00:42:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailout1.samsung.com (u24.gpu114.samsung.co.kr [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 7F5C05DE72 for <[e-mail]>; Tue, 22 Apr 2003 00:42:21 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Tue, 22 Apr 2003 13:42:19 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 22 Apr 2003 13:42:19 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 22 Apr 2003 13:42:18 +0900 (KST)
Date: Tue, 22 Apr 2003 10:09:23 +0530
From: Manav Bhatia <[e-mail]>
Subject: draft-walton-bgp-add-paths-01.txt
To: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <00d701c30889$27328570$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk

Hello,
Some comments on the above stated draft to start with.

1. The length of the Identifier has been kept as 2 octets. Are we
anticipating 2^16 ECMP BGP routes? I think we can use the remaining bits
from the Flags to make our IP prefixes unique. Even if we want some space
reserved for future extensions we don't need to keep 2 octets for making
the
prefix unique!

2. The flags field uses 3 bits. If the first one is set (Bestpath) then it
indicates that the path associated with the NLRI has been selected by the
BGP speaker for installation into its FIB. If set to zero, then the path is
not selected. Why would we ever want to advertise a path which has not been
selected by BGP? If it is to withdraw a previously advertised path then a
better approach would be to send it in the WITHDRAW field.

3. What happens when a router has already advertised some ECMP routes and
it later receives a new ECMP BGP route. How does it advertise this one to
its neighbors? The problem is that it would have advertised its last ECMP
BGP route with the Lastbit set (which indicates that the particular path is
the last one in the UPDATE message for that prefix). To now advertise this
new path does it readvertise all the paths to that prefix OR does it just
advertise the new path information with Bestpath bit set, FirstPath bit
unset and LastBit set/unset (I don't know!)

This seems to be ambiguous in the draft and can be worked upon.

4. The draft does not mention the changes required in the Decision Process.
How does a router decide that the two BGP routes that it has are of the
same cost?

5. The Flags and the Identifier fields have been explained thrice in
sections 2.2.1, 2.2.2. and 2.2.3. I think we can manage with just one.

Regards,
Manav

----
Senior Software Engineer
Samsung India Software Operations
Bangalore - 560 001
[phone]/6 (1120)



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01202 for <[e-mail]>; Mon, 21 Apr 2003 15:16:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 17BEF9123F; Mon, 21 Apr 2003 15:15:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF9AE91241; Mon, 21 Apr 2003 15:15:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9ED5C9123F for <[e-mail]>; Mon, 21 Apr 2003 15:15:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8537D5DDAE; Mon, 21 Apr 2003 15:15:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from fire.cisco.com (firebird.cisco.com [171.68.227.73]) by segue.merit.edu (Postfix) with ESMTP id E20DE5DDC4 for <[e-mail]>; Mon, 21 Apr 2003 15:15:28 -0400 (EDT)
Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h3LJFP021274; Mon, 21 Apr 2003 12:15:25 -0700 (PDT)
Date: Mon, 21 Apr 2003 12:15:24 -0700 (PDT)
From: Shankar Vemulapalli <[e-mail]>
To: Christian Kaas-Petersen <[e-mail]>
Cc: [e-mail]
Subject: Re: VPN encoding
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

The only other comment that I can add is that these drafts will
get their own RFC # [if they get OKed] and will obsolete the older ones.

/Shankar

At 9:37am 04/08/03 +0200, Christian Kaas-Petersen wrote:
> RFC2547bis is not an RFC, but a draft. This draft can be found on
> www.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-03.txt.
>
> Christian
>
> Tim Griffin wrote:
>
> >"bis" means "twice" in latin.  in portuguese, it can be shouted after
> >a performance and means "encore"
> >
> >Mareline Sheldon wrote:
> >
> >>Shankar,
> >>I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
> >>what is this?
> >>
> >>Thanks,
> >>Mareline S.
> >>
> >>--- Shankar Ananthanarayanan Kambat <[e-mail]> wrote:
> >>
> >>>Second version of original spec with updated sections
> >>>
> >>>- Shankar K A
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Mareline Sheldon [mailto:[e-mail]]
> >>>Sent: Monday, April 07, 2003 10:46 AM
> >>>To: [e-mail]
> >>>Subject: RE: VPN encoding
> >>>
> >>>
> >>>Hello,
> >>>Thanks a lot for the info Vijay!
> >>>
> >>>Can anybody please explain me what the "bis" in RFC 2547bis stands for?
> >>>
> >>>I have come across this term "bis" on a number of occasions and i am
> >>>never able to understand
> >>>what it truly means.
> >>>
> >>>Can anybody please shed some light on that?
> >>>
> >>>Thanks,
> >>>Mareline S.
> >>>
> >>>----- Original Message -----
> >>>From: "Krishnan, Vijay G." <[e-mail]>
> >>>To: "'Mareline Sheldon'" <[e-mail]>; <[e-mail]>
> >>>Sent: Saturday, April 05, 2003 2:56 AM
> >>>Subject: RE: VPN encoding
> >>>
> >>>
> >>>>Mareline,
> >>>>
> >>>>Encoding of label in BGP updates - RFC3107
> >>>>Encoding Route Distnguisher - RFC2547bis draft
> >>>>
> >>>>-Vijay
> >>>>
> >>>>
> >>>
> >>>__________________________________________________
> >>>Do you Yahoo!?
> >>>Yahoo! Tax Center - File online, calculators, forms, and more
> >>>http://tax.yahoo.com
> >>>
> >>>>**************************Disclaimer**************************************************
> >>>>
> >>> Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged'
> >>>and 'confidential' and intended for use only by the individual or entity to which it is
> >>>addressed. You are notified that any use, copying or dissemination of the information
> >>>contained in the E-MAIL in any manner whatsoever is strictly prohibited.
> >>>
> >>>****************************************************************************************
> >>>
> >>__________________________________________________
> >>Do you Yahoo!?
> >>Yahoo! Tax Center - File online, calculators, forms, and more
> >>http://tax.yahoo.com
> >>
>
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20686 for <[e-mail]>; Mon, 21 Apr 2003 09:33:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5F3C191222; Mon, 21 Apr 2003 09:33:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24D4391223; Mon, 21 Apr 2003 09:33:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB7F591222 for <[e-mail]>; Mon, 21 Apr 2003 09:33:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 93B7D5E004; Mon, 21 Apr 2003 09:33:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailout2.samsung.com (u25.gpu114.samsung.co.kr [203.254.224.25]) by segue.merit.edu (Postfix) with ESMTP id 46FA65DFC5 for <[e-mail]>; Mon, 21 Apr 2003 09:33:13 -0400 (EDT)
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Mon, 21 Apr 2003 22:33:11 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 21 Apr 2003 22:33:11 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 21 Apr 2003 22:33:10 +0900 (KST)
Date: Mon, 21 Apr 2003 19:00:17 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: BGP ECMP
To: [e-mail]
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <000a01c3080a$26e3bbe0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <074a01c307f1$ce8e7060$[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi Robert,
I have not yet gone through the walton draft and am thus not in a position
to comment on that (will go through it in some time). Meanwhile I have some
comments inlined.

> Before I comment on some your questions posted I think it is worth to
> keep in mind that until now most of those implementations you may be
> refering to treat multipath as a local to the box feature. As far as
> advertisements to i/eBGP peers only best path is advertised as usual.

What is taken as the *best* path?

Say both the routes have equal AS-path lengths, LPs, etc. So which one is
advertised to the downstream peers? Won't the second advertisement (if both
are sent) be taken as an implict withdraw by the other peers? I thus dont
think its an issue local to the box implementing multi-path.

> Hence there is no obvious interoperability problems in mutlipath as
> such.

I see an obvious interoperability issue because the routes which are used
and advertised by this particular router directly affects the other routers
(downstream). Moreover i need a mechanism to formally announce BGP ECMP
routes to the other peers.

OR am i missing something.

> What may be possibly needed to achive multipath in a few BGP deployment
> scenarios is a way to receive more then one path for a given net. In

Exactly.

> ipv4 AF those usually will be lost on reflectors. One possible way to
> address that issue is presented in: draft-walton-bgp-add-paths-01.txt,
> but I think there indeed could be more work needed on this ground.

I have yet to go through this.

>
> > There are a lot of open issues which need to be resolved.
> >
> > - Till what stage should the decision process be run for selecting ECMP
BGP
> > routes. Till their IGP costs?
>
> Notice that IGP cost is important for IBGP multipath, but for a change
> can be With no risk ignored for networks running mpls or any other
> flavour of bgp free core.

I couldnt get you.

>
> > - What should the next hop for these ECMP BGP routes be kept as?
>
> As we advertise the best one anyway next hop is not changed. Even
> advertising multiple paths (or just multiple next hops for multipaths)
> those should remain unchanged.

Right. But we need to formalize it.

Then there can be some issues when RRs are deployed.

Thanks,
Manav



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20098 for <[e-mail]>; Mon, 21 Apr 2003 09:14:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C364391221; Mon, 21 Apr 2003 09:13:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9105791222; Mon, 21 Apr 2003 09:13:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5539F91221 for <[e-mail]>; Mon, 21 Apr 2003 09:13:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C45915E000; Mon, 21 Apr 2003 09:13:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by segue.merit.edu (Postfix) with ESMTP id 54A0E5DFFF for <[e-mail]>; Mon, 21 Apr 2003 09:13:52 -0400 (EDT)
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3LDDnmi027339; Mon, 21 Apr 2003 06:13:50 -0700 (PDT)
Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGH35794; Mon, 21 Apr 2003 06:10:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 21 Apr 2003 15:13:45 +0200
From: Robert Raszuk <[e-mail]>
Reply-To: [e-mail]
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Manav Bhatia <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP ECMP
References: <074a01c307f1$ce8e7060$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Manav,

> Some vendors seem to allow multiple BGP routes to be installed in the
> Loc-RIB for doing load balancing.  I was not able to find any IETF/non IETF
> draft/standard which talks about this and am interested in pursuing this.

Before I comment on some your questions posted I think it is worth to
keep in mind that until now most of those implementations you may be
refering to treat multipath as a local to the box feature. As far as
advertisements to i/eBGP peers only best path is advertised as usual.
Hence there is no obvious interoperability problems in mutlipath as
such. 

What may be possibly needed to achive multipath in a few BGP deployment
scenarios is a way to receive more then one path for a given net. In
ipv4 AF those usually will be lost on reflectors. One possible way to
address that issue is presented in: draft-walton-bgp-add-paths-01.txt,
but I think there indeed could be more work needed on this ground. 

> There are a lot of open issues which need to be resolved.
> 
> - Till what stage should the decision process be run for selecting ECMP BGP
> routes. Till their IGP costs? 

Notice that IGP cost is important for IBGP multipath, but for a change
can be With no risk ignored for networks running mpls or any other
flavour of bgp free core.

> - What should the next hop for these ECMP BGP routes be kept as?

As we advertise the best one anyway next hop is not changed. Even
advertising multiple paths (or just multiple next hops for multipaths)
those should remain unchanged. 

> - We need to exercise some caution as the packets here (unlike as in IGPs)
> can go outside the AS and therefore cause huge differences in delay/cost
> over "n" available paths.

Sure. I am aware that some implementations allow ebgp multipath over any
paths with different AS-PATHs, some may offer ignoring AS_PATHs only by
non-transit providers. In any case this is again local decision.

> - We need to come out with an interoperable scheme between different
> vendors.

If you mean for passing mutliple paths via RRs - I agree. Just for
selection of mutlipath candidates on a given box - I am not sure.
 
R.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA15480 for <[e-mail]>; Mon, 21 Apr 2003 06:39:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B250A9121D; Mon, 21 Apr 2003 06:38:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FACF9121F; Mon, 21 Apr 2003 06:38:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 064E19121D for <[e-mail]>; Mon, 21 Apr 2003 06:38:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E3DD25DFE9; Mon, 21 Apr 2003 06:38:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailout1.samsung.com (u24.gpu114.samsung.co.kr [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 98BFE5DFE5 for <[e-mail]>; Mon, 21 Apr 2003 06:38:57 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Mon, 21 Apr 2003 19:38:55 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 21 Apr 2003 19:38:55 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 21 Apr 2003 19:38:54 +0900 (KST)
Date: Mon, 21 Apr 2003 16:05:57 +0530
From: Manav Bhatia <[e-mail]>
Subject: BGP ECMP
To: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <074a01c307f1$ce8e7060$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk

Hello,
Some vendors seem to allow multiple BGP routes to be installed in the
Loc-RIB for doing load balancing.  I was not able to find any IETF/non IETF
draft/standard which talks about this and am interested in pursuing this.

There are a lot of open issues which need to be resolved.

- Till what stage should the decision process be run for selecting ECMP BGP
routes. Till their IGP costs? Till the point where we compare the router
IDs, etc. We need to come up with a deterministic behavior to decide how
and what BGP routes will be considered equal.
- What should the next hop for these ECMP BGP routes be kept as?
- How to advertise these multiple routes to other BGP peers, etc?
- We need to exercise some caution as the packets here (unlike as in IGPs)
can go outside the AS and therefore cause huge differences in delay/cost
over "n" available paths.
- We need to come out with an interoperable scheme between different
vendors.

This is just a tentative list of issues which we need to ponder into.

Will the IDR community be interested in working over this?

Thanks,
Manav
----
Senior Software Engineer
Samsung India Software Operations
Bangalore - 560 001
[phone]/6 (1120)



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09761 for <[e-mail]>; Mon, 14 Apr 2003 17:35:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B377191266; Mon, 14 Apr 2003 17:31:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34ADF91269; Mon, 14 Apr 2003 17:31:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C30F91266 for <[e-mail]>; Mon, 14 Apr 2003 17:31:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 524CE5DF69; Mon, 14 Apr 2003 17:31:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smtp05.freeler.nl (smtp05.freeler.nl [213.218.75.234]) by segue.merit.edu (Postfix) with ESMTP id 6C9235DDED for <[e-mail]>; Mon, 14 Apr 2003 17:31:38 -0400 (EDT)
Received: (qmail 27171 invoked from network); 14 Apr 2003 21:31:35 -0000
Received: from unknown (HELO xtreme) ([62.21.136.85]) (envelope-sender <[e-mail]>) by smtp05.freeler.nl (qmail-ldap-1.03) with SMTP for <[e-mail]>; 14 Apr 2003 21:31:35 -0000
From: "Joris Dobbelsteen" <[e-mail]>
To: "'IDR WG (E-mail)'" <[e-mail]>
Subject: RE: Issue 19) Security Considerations 
Date: Mon, 14 Apr 2003 23:32:56 +0200
Message-ID: <001201c302cd$6ba36f10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

Curtis, it was not my intension to upset you in any way. Still it looks
like I successed doing that....... Any way, we do need some feedback
from practical deployments.

My personal consideration would be not to put it in a chapter 4.2 but
get it throughout the entire draft.

Packet filters provide the good protection for IBGP sessions. These are
harder/impractical for EBGP(?).
Internal attacks and hacks on the network channels are not considered
practical.


IPSec is not recommended because at least three reasons:
TCP-MD5 is already widely implemented and deployed.
Complication in network management, because packet filters need to be
adapted for IPSec traffic (port 500 - IKE).
IPSec has higher processing demands that TCP-MD5 does, lowing the
barrier for a successful DoS attack. Hardware IPSec implementations are
considered impractical, due to the cost or performance.

This brings up your statement that IPSec covers the ports. This is not
true, when encryption (ESP) is not used. The use of intigrity (AH)
will not hide the ports, it works sorta TCP-MD5, if you want...
I also did never consider using ESP, since it was not desired and it
would be the way to 'promote' DoS attacks.
Unfortunally I don't have any insight on IPSec hardware, maybe some else
can give some insight on this.

I suppose this closes the IPSec/TCP-MD5 issue, leaving TCP-MD5 to the 
current best option.


Still this leaves EBGP open for consideration.

The use of BGP TTL Security Hack (BTSH) might be a very simple and
effective way of protecting the external routers from attacks,
especially DoS attacks. Malicious data can be prevented using TCP-MD5.
The disadvantage is that it is not deployed widely, but only requires
routers to send there traffic with an initial TTL of 255. I don't
know if this is currently possible to archieve: whether current
implementations can be set to send with an initial TTL of 255. It is
not needed for both end-points to support BTSH, although desired.
<draft-gill-btsh-01.txt>

I couldn't find any information about dynamic 4-tuple filtering
(google turns up BGP dynamic capabilities), unfortunally.

So what else can be done to prevent a EBGP session from attacks,
especially DoS attacks? Data insertion/manipulations can be guarded
against using TCP-MD5 (or similar).




- Joris

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf Of
>Curtis Villamizar
>Sent: Thursday, 3 April 2003 16:36
>To: Joris Dobbelsteen
>Cc: 'IDR WG (E-mail)'
>Subject: Re: Issue 19) Security Considerations 
>
>In message <001b01c2f52e$48505480$[e-mail]>, 
>"Joris Dobbelsteen" 
>writes:
>> [snip]
>
>Joris,
>
>Quite frankly I'm outraged at such comments.  Only by looking at
>theoretical security issues and ignoring reality (not that the two
>don't highly but imperfectly overlap) can you come to the conclusion
>that IPSEC is needed and in its current form is viable as a security
>solution for BGP.
>
>I think its about time we injected some reality into
>draft-murphy-bgp-vuln-02.txt.
>
>I've added a practical considerations section.  I stuck it in as 4.2.
>
>Comments are welcome, particularly comments from people actually
>running BGP networks or building BGP routers used by ISPs.
>
>I did not mention advanced filtering works-in-progress or proposals
>such as BTSH or dynamic 4-tuple EBGP filtering since these are not yet
>implemented or deployed afaik.  [aside: I strongly believe that BTSH
>will prove to be a viable to protect EBGP and a preferable replacement
>for current filtering which some older TTM (time-to-market) line cards
>still in use are unable to support.]
>
>I should also note that the filtering best practices are far from
>universally deployed and in some cases are difficult to fully deploy
>due to residual use of TTM line cards unable to support filtering.
>
>Note that IPSEC with port numbers exposed would be a viable security
>solution.  It would still be a greater computational burden than
>TCP-MD5 and still might be less preferred by ISPs for that reason for
>some architectures.  This change to IPSEC would at least yield two
>viable options and might encourage implementation and deployment of
>IPSEC as a security solution for BGP.
>
>Curtis
>
>
>--- draft-murphy-bgp-vuln-02.txt	Wed Mar  5 21:00:00 2003
>+++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
>@@ -149,6 +149,7 @@
> 3.2.2.2 Timer events 
>..............................................   16
> 4 Security Considerations 
>.........................................   16
> 4.1 Residual Risk 
>.................................................   16
>+4.2 Practical Considerations 
>......................................   16
> 5 References 
>......................................................   17
> 6 Author's Address 
>................................................   18
> 
>@@ -901,6 +902,79 @@
> Filtering is in use near some customer attachment points, but is not
> effective near the Internet center.  The other mechanisms are still
> controversial and are not yet in common use.
>+
>+4.2 Practical Considerations
>+
>+The primary usage of BGP is as a means to provide reachability
>+information to Autonomous Systems (AS) and to distribute external
>+reachability internally within an AS.  BGP is the routing protocol
>+used to distribute global routing information in the Internet.  BGP is
>+therefore used by all major Internet Service Providers (ISP) and many
>+smaller providers and other organizations.  
>+
>+The role which BGP plays in the Internet puts BGP implementations in
>+unique conditions and places unique security requirements on BGP.  BGP
>+is operated over interprovider interfaces in which traffic levels push
>+the state of the art in specialized packet forwarding hardware and
>+exceed the performace capabilities of hardware implementation of
>+decryption by many decimal orders of magnitude.  
>+
>+ISP networks must be and are under tight control.  The only viable
>+means to protect the network elements from Denial of Service (DoS)
>+attacks under such conditions are packet based filtering techniques
>+based on relatively simple inspections of packets.
>+
>+To protect Internal BGP (IBGP) sessions, filters are applied at all
>+borders to an ISP network which remove all traffic destined for
>+addresses of network elements internal addresses (typically contained
>+within a single prefix) and the BGP port number (179).  Packets from
>+within an ISP are not forwarded from an internal interface to the BGP
>+speaker's address on which External BGP (EBGP) sessions are supported,
>+or to a peer's EBGP address if the BGP port number is found.  With
>+appropriate consideration in router design, in the event of failure of
>+a BGP peer to provide the equivalent filtering the risk of compromise
>+can be limited to the peering session on which filtering is not
>+performed by the peer or the interface or line card on which the
>+peering is supported.  There is substantial motivation and little
>+effort for ISPs to maintain such filters.
>+
>+Being composed entirely of specialized network equipment, under strict
>+control of the ISP, the ISP network is not subject to attacks from
>+within than enterprise networks are with more generalized computing
>+systems and staff less carefully trained in the area of secure
>+procedures.  ...

For me personally, the above sentence is a little hard to understand.
You mean that ???
The Internal BGP routers (or specialized network equipment) that is under
strict control of the ISP is not subject to attacks, other than those that
are common in enterprise networks. These networks have staff that is
less carefully trained in the area of security procedures.

>+ ...........  Monitoring of traffic from within requires either
>+compromise of relatively physically secure and carefully administered
>+network elements or monitoring physical media.  Injection of traffic
>+requires either compromise of network elements or intercept and
>+replacement of traffic on physical media.
>+
>+The difficulty of compromise of network elements and of undetected
>+tapping into physical media carrying extremely high volumes of traffic
>+is much greater than the difficulty of injecting sufficient traffic
>+from outside a network to effect a DoS attack.  As a result, the
>+ability to packet filter on the basis of port numbers far exceeds the
>+need to cryptographic strength in encapsulation.
>+
>+These practical considerations yield the situation in which TCP-MD5,
>+though cryptographic weak, far better serves ISP security needs than
>+the cryptographicly much stronger IPSEC which makes packet filtering
>+infeasible.
>+
>+Use of BGP in smaller networks yields similar requirements.  The
>+capability of a single workstation with high speed interface to
>+generate false traffic far exceeds the capability of software based
>+decryption or appropriately priced cryptographic hardware.  From a
>+practical standpoint, these networks are also better served by
>+appropriate administrative care, filtering, and TCP-MD5 than by IPSEC.
>+
>+This situation is likely to persist unless either cryptographic
>+hardware becomes many orders of magnitude faster and cheaper or IPSEC
>+supports an ability to leave IP port numbers exposed.  This
>+requirement has been made known to the IPSEC WG.
>+

See above, using intigrity only (AH), leaves TCP (not IP) port numbers
readable for everyone. This security is rather an IPSec configuration
option.

>+Until such time as IPSEC is modified, there is little choice but to
>+mandate TCP-MD5 implementation and recommend TCP-MD5 usage for BGP and
>+discourage IPSEC usage for BGP.
> 
> 5.  References
> 
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA11070 for <[e-mail]>; Mon, 14 Apr 2003 01:16:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 34F3C91206; Mon, 14 Apr 2003 01:15:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04DE591207; Mon, 14 Apr 2003 01:15:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8048791206 for <[e-mail]>; Mon, 14 Apr 2003 01:15:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 66FF35DE57; Mon, 14 Apr 2003 01:15:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D69AC5DE31 for <[e-mail]>; Mon, 14 Apr 2003 01:15:29 -0400 (EDT)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h3E5FTHn070163 for [e-mail]; Mon, 14 Apr 2003 01:15:29 -0400 (EDT) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h3E5FPox070155 for <[e-mail]>; Mon, 14 Apr 2003 01:15:25 -0400 (EDT) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: Minutes of the IDR working meeting at IETF 56
Date: Mon, 14 Apr 2003 01:15:20 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Minutes of the IDR working meeting at IETF 56
Thread-Index: AcMCRNeGUiuIGw4KQhiAjkYpTvqqCQ==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id BAA11070

Wednesday, March 19 1530-1730
=============================

CHAIRS: Sue Hares ([e-mail])
	Yakov Rekhter ([e-mail])


The following was the agenda for the IDR meeting
on 3/19/2003. 

AGENDA:

 1530-1545 Administrivia (Yakov Rekhter, Sue Hares)

            Agenda Bashing
            Minutes
            Blue Sheets
            WG Document Status 

 15:45-16:10 Flexible BGP Communities (Andrew Lange)

    http://www.ietf.org/internet-drafts/draft-lange-flexible-bgp-communities-00.txt

 16:10-16:25 BGP Security Vulnerabilities Analysis (Sandy Murphy)

    http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt

===========


   1) Administrivia:

	WG document status: 
	
	The Base BGP protocol specification is complete.  The editor's thanks
	go to Andrew Lange.  
		draft-ietf-idr-bgp4-19.txt has incorporated all the comments
		we have received. draft-ietf-idr-bgp4-20.txt includes a few
		more editorial changes.

		We have completed last call the document.  The resulting document
		will be forwarded to IESG.

	This document goes with a package of documents that detail the 
	BGP4: 
		1) draft-ietf-idr-bgp4-20.txt 
		2) draft-ietf-idr-bgp4-mib-10.txt (version 1 MIB)
		3) BGP security analysis 
			draft-murphy-bgp-vuln-02.txt which will be re-issued as
			draft-ietf-idr-bgp4-vuln-01.txt

	The draft-ietf-idr-bgp4-mib-10.txt will be issued lasted call
	on the mail list which ends on 3/24.

	The BGP security analysis document needs to be reviewed and comments
	sent ASAP. 

	And a group of reports for the IESG: 
		1)  BGP-4 Protocol Analysis (Dave Meyer, Keyur Patel)
		2) Experience with the BGP-4 Protocol 
		    (Danny McPherson, Keyur Patel) 

		3) BGP implementation report 
		    (Alvaro Retano) 

	Will be uploaded as idr documents.  Please comment on
	these documents.


B) 15:46 -16:10 Flexible BGP communities

	Andrew Lange gave a presentation on BGP communities in
		BGP Flexible Communities.ppt

	A discussion ensued afterward containing the following points:
	
	a) Should this specification supercede the base communities,
	   the Extended communities or should this document only include
	   communities not specified in these two drafts?

	    Several people (Enke Chen, Yakov Rekhter) felt that it imposed
	    a deployment burden if the draft superceded these two document.
	    Additional discussion of this point

	b) Should this work continue.  
	    Several people felt this work was useful. Additional feedback
	    was given to the author.  Additional discussion will continue
	    on the list. 
	
  

c) 16:10-16:25 BGP Security Vulnerabilities Analysis (Sandy Murphy)

    http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt


    Sandy present the slides idr.vulnerabilities.ppt
    After the presentation, a discussion about the drat continued with 
    the following points:

	a) The use of unconfigured peers in the base draft.
	b) The use of TTL as an alternative security mechanisms for
	   unconfigured peers,

	c) Do we include failure scenarios where a BGP
 	   Speaker doesn't send info it was supposed to send.  
	     eg not sending a WITHDRAW
	

	d) We need to make sure the draft is clear that there
 	   are two types of attacks:
             1) Spoofs/session interrupts/disruptive attacks.
             2) Poison info attacks (sending malicious info)

 
    On Unconfigured peers (point a), the discussion centered around
    re-opening the issue of unconfigured peers.  The majority of the
    working group did not want to re-open the issue.  The general
    consensus was that an explanation for unconfigured peers be added
    to the experience draft.  

    On item b, the use of TTL as a security issue, Yakov pointed out
    that the TTL document is not even a working group document.  We
    are progressing BGP (in 3 documents base, mib, security document)
    on what is.  Sandy Murphy pointed out that TTL doesn't work
    with EBGP multi-hop.  Vijay agreed with Sandy, but indicated that
    TTL works for most cases.  Sandy pointed out that security analysis
    are required to look security in all cases.  The TTL document
    is new work and will not be discussed until the Routing ADs lift
    the hold on new work.

    On item c, the consensus was to leave this out because it
    contains no information.  There is no way to differentiate between a bug
    in an implementation and an attack for these "attacks of omission".

    On item d, Sandy Murphy indicated that it was included in the draft.
    Comments are welcomed to clarify the text.





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22090 for <[e-mail]>; Tue, 8 Apr 2003 14:17:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7333B9126D; Tue,  8 Apr 2003 14:16:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40DEF91278; Tue,  8 Apr 2003 14:16:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F42239126D for <[e-mail]>; Tue,  8 Apr 2003 14:16:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 996EC5E30D; Tue,  8 Apr 2003 14:16:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 76F965E2DA for <[e-mail]>; Tue,  8 Apr 2003 14:16:14 -0400 (EDT)
Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id F1208A04CA6; Tue,  8 Apr 2003 11:16:13 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 6D955979C1; Tue,  8 Apr 2003 11:16:13 -0700 (PDT)
To: "Krishnan, Vijay G." <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: draft-ietf-idr-bgp-identifier-02.txt 
In-Reply-To: Message from "Krishnan, Vijay G." <[e-mail]>  of "Tue, 08 Apr 2003 11:37:32 EDT." <[e-mail]> 
Date: Tue, 08 Apr 2003 11:16:13 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi, Vijay:

> Message-ID: <[e-mail]>
> From: "Krishnan, Vijay G." <[e-mail]>
> To: "'Enke Chen'" <[e-mail]>
> Cc: [e-mail]
> Subject: RE: draft-ietf-idr-bgp-identifier-02.txt 
> Date: Tue, 8 Apr 2003 11:37:32 -0400 
> 
> Hi Enke,
> 
> >Please see the following text in the Remarks Section of the draft:
> >
> >   A BGP speaker that supports the AS-wide Unique BGP Identifier can not
> >   share a BGP Identifier with its external neighbor until the remote
> >   BGP speaker is upgraded with software that supports the proposed
> >   revisions.
> 
> Is there be a way of knowing whether the peer supports AS-wide unique ID? I
> didn't see any new capability in the draft. 

BGP capability is good at dealing with optinal features. However, it does not
seem to help in this case as the BGP identifier is mandatory:

     - For an existing BGP speaker that has a globally unique identifier,
       there is no issue.

     - For an ipv6-only speaker, if the identifier is the same as that
       of the remote speaker, the session will not be up until the software
       is upgraded (regarless of whether a new capability is introduced).

Regards,

-- Enke



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18341 for <[e-mail]>; Tue, 8 Apr 2003 11:53:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 42BFD9122A; Tue,  8 Apr 2003 11:52:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 148AF9122B; Tue,  8 Apr 2003 11:52:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7C089122A for <[e-mail]>; Tue,  8 Apr 2003 11:52:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AE04D5E2B1; Tue,  8 Apr 2003 11:52:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 60DFB5E254 for <[e-mail]>; Tue,  8 Apr 2003 11:52:57 -0400 (EDT)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h38Fqu66054728 for [e-mail]; Tue, 8 Apr 2003 11:52:56 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h38Fqrox054721 for <[e-mail]>; Tue, 8 Apr 2003 11:52:53 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h38FqmH06244 for [e-mail]; Tue, 8 Apr 2003 11:52:48 -0400 (EDT)
Date: Tue, 8 Apr 2003 11:52:48 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Attention implementors of draft-ietf-idr-bgp4-mib-10
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

As part of working group last call, we are going to need an implementation
report.  If you could contact me so we can at least get parties
lined up for this, it would be handy.

As part of working group last call, the OPS folks pointed out a 
potentially worrisome issue:

Two previously documented traps, bgpEstablished and bgpBackwardTransition
were changed from the RFC 1657 definition to include in its OBJECTS
clause the bgpPeerRemoteAddr object.  This is apparently not kosher
since the INDEX of the two documented objects includes the information
included in that particular object.  

Removing the bgpPeerRemoteAddr object appears to be the correct
answer, however it potentially will affect deployed implementations
that implement the BGP traps.

I am working with the OPS folks to determine what our proper course
of action should be.  

If you have implemented these traps, please contact me so I can help
direct your concerns.  Given the operational consequences of these
objects, I would like to keep this as smooth as possible.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17937 for <[e-mail]>; Tue, 8 Apr 2003 11:37:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9AF4491228; Tue,  8 Apr 2003 11:37:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1CE99122A; Tue,  8 Apr 2003 11:37:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D18D891228 for <[e-mail]>; Tue,  8 Apr 2003 11:37:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B37ED5E2AA; Tue,  8 Apr 2003 11:37:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 1F17A5E2AD for <[e-mail]>; Tue,  8 Apr 2003 11:37:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA01098; Tue, 8 Apr 2003 11:37:32 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06362; Tue, 8 Apr 2003 11:37:33 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <2BDH7X9H>; Tue, 8 Apr 2003 11:37:33 -0400
Message-ID: <[e-mail]>
From: "Krishnan, Vijay G." <[e-mail]>
To: "'Enke Chen'" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-idr-bgp-identifier-02.txt 
Date: Tue, 8 Apr 2003 11:37:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hi Enke,

>Please see the following text in the Remarks Section of the draft:
>
>   A BGP speaker that supports the AS-wide Unique BGP Identifier can not
>   share a BGP Identifier with its external neighbor until the remote
>   BGP speaker is upgraded with software that supports the proposed
>   revisions.

Is there be a way of knowing whether the peer supports AS-wide unique ID? I
didn't see any new capability in the draft. 

regards
Vijay






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA13677 for <[e-mail]>; Tue, 8 Apr 2003 09:46:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C280A91221; Tue,  8 Apr 2003 09:45:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 905C091225; Tue,  8 Apr 2003 09:45:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24B1A91221 for <[e-mail]>; Tue,  8 Apr 2003 09:45:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 46AA85E05F; Tue,  8 Apr 2003 09:45:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 529D65DECF for <[e-mail]>; Tue,  8 Apr 2003 09:45:40 -0400 (EDT)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h38Djc5F051948; Tue, 8 Apr 2003 09:45:38 -0400 (EDT) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h38DjZox051934; Tue, 8 Apr 2003 09:45:35 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h38DjUT05731; Tue, 8 Apr 2003 09:45:30 -0400 (EDT)
Date: Tue, 8 Apr 2003 09:45:30 -0400
From: Jeffrey Haas <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: [e-mail]
Subject: Re: MIB V2: PathAttrIndex
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Apr 07, 2003 at 04:22:18PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Pedro,

On Mon, Apr 07, 2003 at 04:22:18PM -0700, Pedro Roque Marques wrote:
> It isn't clear...

I'll work with you offline to clean this up a bit.
However, suggestions on-list are always welcome.

> Specially because some of the tables refer to "received" attributes
> and "advertised" attributes.
> 
> When policy is in use a given route (the tuple <routing-table-id, prefix,
> prefixlen, source router-id>) can point to:
> 
>  - a received set of attributes.
>  - a current set of attributes
>  - a set of attributes per advertised peer.
> 
> So in order for your idea to work, i believe you need to do have the
> following mapping:
> 
>  - route 4-tuple -> Loc-Rib attribute set index.
>  - route 4-tuple -> Rib-in attribute set index.
>  - <routing-table-id, prefix, prefixlen, peer> -> Rib-out attribute
> set index.

I believe that particular table can already accomodate these mappings.  
Essentially, this is just a path attributes database.  You can place
entries for the received, used and advertised path attributes in
here.  The wording in the DESCRIPTIONs is clearly incorrect though.

For example, I'm sure you're noting:
    bgpM2PathAttrTable OBJECT-TYPE
        DESCRIPTION
            "Provides per advertised network-prefix attribute data,
             as advertised over a peering session."

> While the implementations i know of do keep information internally in
> an attribute database it is not always easy to make that index
> externally availiable.
> 
> i.e. afaik it will be required to create a mapping of external index
> -> internal db entry.

Right.  Some sort of index will need to be maintained to map from
an advertised ID to the internal data structure.  Do we consider this
overhead to be excessive?

> One must make sure that this element is not reused immediatly... the
> internal index is often reused immediatly

Exactly.

> The idea is valid... however there is some overhead involved and i
> believe you don't have the mappings necessary to support it.

I think the tables have the appropriate information, however the 
DESCRIPTIONs need work.  If I'm missing something, could you point
out a specific example?

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA02636 for <[e-mail]>; Tue, 8 Apr 2003 03:38:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5657191222; Tue,  8 Apr 2003 03:37:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FF8F91224; Tue,  8 Apr 2003 03:37:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B45691222 for <[e-mail]>; Tue,  8 Apr 2003 03:37:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 21A845E26E; Tue,  8 Apr 2003 03:37:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [213.159.160.68]) by segue.merit.edu (Postfix) with ESMTP id 84CAC5E203 for <[e-mail]>; Tue,  8 Apr 2003 03:37:34 -0400 (EDT)
Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [213.159.188.246]) by iproxy1.ericsson.dk (8.12.9/8.12.8) with ESMTP id h387eKTL028009 for <[e-mail]>; Tue, 8 Apr 2003 09:40:20 +0200 (CEST)
Received: from ted.ericsson.se (ckp.ted.dk.eu.ericsson.se [213.159.189.40]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id h387bSx11283 for <[e-mail]>; Tue, 8 Apr 2003 09:37:28 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2003 09:37:28 +0200
From: Christian Kaas-Petersen <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: VPN encoding
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

RFC2547bis is not an RFC, but a draft. This draft can be found on
www.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-03.txt.

Christian

Tim Griffin wrote:

>"bis" means "twice" in latin.  in portuguese, it can be shouted after 
>a performance and means "encore"  
>
>Mareline Sheldon wrote:
>
>>Shankar,
>>I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
>>what is this?
>>
>>Thanks,
>>Mareline S.
>>
>>--- Shankar Ananthanarayanan Kambat <[e-mail]> wrote:
>>
>>>Second version of original spec with updated sections
>>>
>>>- Shankar K A
>>>
>>>
>>>-----Original Message-----
>>>From: Mareline Sheldon [mailto:[e-mail]]
>>>Sent: Monday, April 07, 2003 10:46 AM
>>>To: [e-mail]
>>>Subject: RE: VPN encoding
>>>
>>>
>>>Hello,
>>>Thanks a lot for the info Vijay!
>>>
>>>Can anybody please explain me what the "bis" in RFC 2547bis stands for?
>>>
>>>I have come across this term "bis" on a number of occasions and i am
>>>never able to understand
>>>what it truly means.
>>>
>>>Can anybody please shed some light on that?
>>>
>>>Thanks,
>>>Mareline S.
>>>
>>>----- Original Message -----
>>>From: "Krishnan, Vijay G." <[e-mail]>
>>>To: "'Mareline Sheldon'" <[e-mail]>; <[e-mail]>
>>>Sent: Saturday, April 05, 2003 2:56 AM
>>>Subject: RE: VPN encoding
>>>
>>>
>>>>Mareline,
>>>>
>>>>Encoding of label in BGP updates - RFC3107
>>>>Encoding Route Distnguisher - RFC2547bis draft
>>>>
>>>>-Vijay
>>>>
>>>>
>>>
>>>__________________________________________________
>>>Do you Yahoo!?
>>>Yahoo! Tax Center - File online, calculators, forms, and more
>>>http://tax.yahoo.com
>>>
>>>>**************************Disclaimer**************************************************
>>>>
>>> Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged'
>>>and 'confidential' and intended for use only by the individual or entity to which it is
>>>addressed. You are notified that any use, copying or dissemination of the information
>>>contained in the E-MAIL in any manner whatsoever is strictly prohibited.
>>>
>>>****************************************************************************************
>>>
>>__________________________________________________
>>Do you Yahoo!?
>>Yahoo! Tax Center - File online, calculators, forms, and more
>>http://tax.yahoo.com
>>




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA27074 for <[e-mail]>; Tue, 8 Apr 2003 00:38:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 658AA9121F; Tue,  8 Apr 2003 00:38:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28F2491221; Tue,  8 Apr 2003 00:38:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 272A59121F for <[e-mail]>; Tue,  8 Apr 2003 00:38:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 08AF65E245; Tue,  8 Apr 2003 00:38:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 952625E231 for <[e-mail]>; Tue,  8 Apr 2003 00:38:21 -0400 (EDT)
Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id F35F6A5B45; Mon,  7 Apr 2003 21:38:20 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 4D90F15D3C1; Mon,  7 Apr 2003 21:38:20 -0700 (PDT)
To: Manav Bhatia <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: draft-ietf-idr-bgp-identifier-02.txt 
In-Reply-To: Message from Manav Bhatia <[e-mail]>  of "Tue, 08 Apr 2003 08:31:07 +0530." <0fac01c2fd7b$1b1f0e20$[e-mail]> 
Date: Mon, 07 Apr 2003 21:38:20 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi, Manav:

> Date: Tue, 08 Apr 2003 08:31:07 +0530
> From: Manav Bhatia <[e-mail]>
> Subject: Re: draft-ietf-idr-bgp-identifier-02.txt
> To: [e-mail]
> Cc: [e-mail]
> Reply-To: Manav Bhatia <[e-mail]>
> Message-id: <0fac01c2fd7b$1b1f0e20$[e-mail]>
> 
> Hi Jenny,
> Thanks for the comments. Please look inline.
> 
> > > - why is this restriction placed only for the internal peers. What if i
> > > receive an OPEN message from an external peer with the same BGP ID as
> mine?
> >
> > This draft relaxes the "uniqueness" requirement for a BGP Identifier
> > so that the BGP Identifiers only needs to be unque inside its own AS.
> > It's ok to receive the same BGP ID from an external peer as long as
> > both BGP speaker support the AS-wide Unique BGP Identifier.
> 
> Hmmm .. it means that i may have some problems if my peer doesnt implement
> this draft and i try to peer with another one which does and if both happen
> to share the same BGP ID.

Please see the following text in the Remarks Section of the draft:

   A BGP speaker that supports the AS-wide Unique BGP Identifier can not
   share a BGP Identifier with its external neighbor until the remote
   BGP speaker is upgraded with software that supports the proposed
   revisions.

> 
> Additionally, are you sure that this draft does not raise any security
> concerns [sec 6] because you are relaxing the checks on BGP ID?

No, we do not see any security issue.

> 
> > > Can it be re-phrased. I got lost! :-)
> >
> > This is not a re-phrase, just my attempt to explain the paragraph: ;-)
> >
> > In the route selection process:
> >
> > . since the BGP Identifier is not used to compare a route received from
> >   an internal neighbor and a route from an external neighbor, therefore,
> >   it's ok to have BGP Identifier unique only with the AS.
> >
> > . if two routes are received from BGP speakers with identical BGP
> Identifier,
> >   the neighbor with lower IP address is prefered. Again, there should not
> >   be a problem having only AS-wide BGP Identifier.
> 
> This makes it a lot better. Can it be put this way in the draft.

We will try to make the text clearer in the next revision.

Regards,

-- Enke






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA24168 for <[e-mail]>; Mon, 7 Apr 2003 23:03:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1405291211; Mon,  7 Apr 2003 23:03:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1DF49121C; Mon,  7 Apr 2003 23:03:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7486991211 for <[e-mail]>; Mon,  7 Apr 2003 23:03:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 62B5A5E247; Mon,  7 Apr 2003 23:03:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailout2.samsung.com (unknown [203.254.224.25]) by segue.merit.edu (Postfix) with ESMTP id 144D65E245 for <[e-mail]>; Mon,  7 Apr 2003 23:03:36 -0400 (EDT)
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 12:03:34 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 12:03:34 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 08 Apr 2003 12:03:33 +0900 (KST)
Date: Tue, 08 Apr 2003 08:31:07 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: draft-ietf-idr-bgp-identifier-02.txt
To: [e-mail]
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <0fac01c2fd7b$1b1f0e20$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi Jenny,
Thanks for the comments. Please look inline.

> > - why is this restriction placed only for the internal peers. What if i
> > receive an OPEN message from an external peer with the same BGP ID as
mine?
>
> This draft relaxes the "uniqueness" requirement for a BGP Identifier
> so that the BGP Identifiers only needs to be unque inside its own AS.
> It's ok to receive the same BGP ID from an external peer as long as
> both BGP speaker support the AS-wide Unique BGP Identifier.

Hmmm .. it means that i may have some problems if my peer doesnt implement
this draft and i try to peer with another one which does and if both happen
to share the same BGP ID.

Additionally, are you sure that this draft does not raise any security
concerns [sec 6] because you are relaxing the checks on BGP ID?

> > Can it be re-phrased. I got lost! :-)
>
> This is not a re-phrase, just my attempt to explain the paragraph: ;-)
>
> In the route selection process:
>
> . since the BGP Identifier is not used to compare a route received from
>   an internal neighbor and a route from an external neighbor, therefore,
>   it's ok to have BGP Identifier unique only with the AS.
>
> . if two routes are received from BGP speakers with identical BGP
Identifier,
>   the neighbor with lower IP address is prefered. Again, there should not
>   be a problem having only AS-wide BGP Identifier.

This makes it a lot better. Can it be put this way in the draft.

Thanks,
Manav





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA17858 for <[e-mail]>; Mon, 7 Apr 2003 19:22:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 858249120C; Mon,  7 Apr 2003 19:22:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5757791211; Mon,  7 Apr 2003 19:22:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E1F449120C for <[e-mail]>; Mon,  7 Apr 2003 19:22:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C855E5E225; Mon,  7 Apr 2003 19:22:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 75F1D5E198 for <[e-mail]>; Mon,  7 Apr 2003 19:22:22 -0400 (EDT)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h37NMIu97579; Mon, 7 Apr 2003 16:22:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h37NMI783169; Mon, 7 Apr 2003 16:22:18 -0700 (PDT) (envelope-from roque)
Date: Mon, 7 Apr 2003 16:22:18 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: MIB V2: PathAttrIndex
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Thu, Apr 03, 2003 at 06:52:55PM -0800, Pedro Roque Marques wrote:
> >     bgpM2PathAttrIndex OBJECT-TYPE

[...]

> > If i understand correctly, the intent here is to create an index that
> > can replace the full "key" on an NLRI.
> 
> In the original bgp mib, we have the following:
>         bgp4PathAttrEntry OBJECT-TYPE
>             SYNTAX     Bgp4PathAttrEntry
>             MAX-ACCESS not-accessible
>             STATUS     current
>             DESCRIPTION
>                     "Information about a path to a network."
>             INDEX { bgp4PathAttrIpAddrPrefix,
>                     bgp4PathAttrIpAddrPrefixLen,
>                     bgp4PathAttrPeer            }
>             ::= { bgp4PathAttrTable 1 }
> 
> The sequence that then follows contains all bgp-4 (rfc 1771) defined
> path attributes.
> 
> When you do a table walk, this is an amazing amount of repeated
> information in some cases, especially if you just want the prefixes.
> 
> In the v2MIB, we simply take path attributes out and refer to their
> existance in a separate table.
> 
> > However managing and assigning
> > this index is imho a very large overhead.
> 
> I had hoped not.
> 
> > Perhaps i'm being dense,
> 
> Or just as likely, the wording isn't clear.

It isn't clear...

Specially because some of the tables refer to "received" attributes
and "advertised" attributes.

When policy is in use a given route (the tuple <routing-table-id, prefix,
prefixlen, source router-id>) can point to:

 - a received set of attributes.
 - a current set of attributes
 - a set of attributes per advertised peer.

So in order for your idea to work, i believe you need to do have the
following mapping:

 - route 4-tuple -> Loc-Rib attribute set index.
 - route 4-tuple -> Rib-in attribute set index.
 - <routing-table-id, prefix, prefixlen, peer> -> Rib-out attribute
set index.

> The general thought is that any path attributes set that is received
> by a BGP speaker generally must be stored as a complete entity by the
> application in some internal form - essentially a path attributes database.
> The individual components may be stored in different fashions to
> allow for sharing of common sets of items for space-saving purposes, but
> you still need to have the original path attribute set available.
> 
> Thus, this index is simply a unique value for a given path attribute
> set within your implementation.  

OK.

> 
> I had *hoped* that this method was common enough in various implementations
> to make this something that greatly eases implementation of the
> table by utilizing a pre-existing internal data structure index.  If
> this isn't the case, then these tables need serious re-working.

While the implementations i know of do keep information internally in
an attribute database it is not always easy to make that index
externally availiable.

i.e. afaik it will be required to create a mapping of external index
-> internal db entry.

> As for the re-usability, you should be able to re-use it, but you ideally
> will need to wait "long enough" to satisfy outstanding queries.  Something
> about this timeliness should probably be mentioned in the mib.

One must make sure that this element is not reused immediatly... the
internal index is often reused immediatly

> 
> As the PathAttrIndex is used simply for grouping path attributes
> (essentially to point into a grouping of path attributes in your path
> attributes database), hopefully this isn't true.  However, as I've stated
> above, there is the base assumption that most implementations have some
> mechanism to pre-group sets of path attributes together in the database
> as they have been received.  If this is true, then indexing may add
> some overhead, but hopefully not a horrible amount.
> 

The idea is valid... however there is some overhead involved and i
believe you don't have the mappings necessary to support it.

  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA10991 for <[e-mail]>; Mon, 7 Apr 2003 15:52:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 78D729121A; Mon,  7 Apr 2003 15:51:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 489CF9121B; Mon,  7 Apr 2003 15:51:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3666D9121A for <[e-mail]>; Mon,  7 Apr 2003 15:51:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 205585E120; Mon,  7 Apr 2003 15:51:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id ED9DD5E031 for <[e-mail]>; Mon,  7 Apr 2003 15:51:36 -0400 (EDT)
Received: by mail-blue.research.att.com (Postfix, from userid 612) id C07AAB7BD1; Mon,  7 Apr 2003 15:56:32 -0400 (EDT)
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 0D129B7BA2; Mon,  7 Apr 2003 15:56:32 -0400 (EDT)
Received: from research.att.com (wold1037.research.att.com [135.207.49.37]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h37JpZV26072; Mon, 7 Apr 2003 15:51:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 07 Apr 2003 15:51:49 -0400
From: Tim Griffin <[e-mail]>
Organization: AT&T Labs Research
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Mareline Sheldon <[e-mail]>
Cc: Shankar Ananthanarayanan Kambat <[e-mail]>, [e-mail]
Subject: Re: VPN encoding
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-129.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_IN_WHITELIST autolearn=ham	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
Sender: [e-mail]
Precedence: bulk

"bis" means "twice" in latin.  in portuguese, it can be shouted after 
a performance and means "encore"  

Mareline Sheldon wrote:
> 
> Shankar,
> I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
> what is this?
> 
> Thanks,
> Mareline S.
> 
> --- Shankar Ananthanarayanan Kambat <[e-mail]> wrote:
> > Second version of original spec with updated sections
> >
> > - Shankar K A
> >
> >
> > -----Original Message-----
> > From: Mareline Sheldon [mailto:[e-mail]]
> > Sent: Monday, April 07, 2003 10:46 AM
> > To: [e-mail]
> > Subject: RE: VPN encoding
> >
> >
> > Hello,
> > Thanks a lot for the info Vijay!
> >
> > Can anybody please explain me what the "bis" in RFC 2547bis stands for?
> >
> > I have come across this term "bis" on a number of occasions and i am
> > never able to understand
> > what it truly means.
> >
> > Can anybody please shed some light on that?
> >
> > Thanks,
> > Mareline S.
> >
> > ----- Original Message -----
> > From: "Krishnan, Vijay G." <[e-mail]>
> > To: "'Mareline Sheldon'" <[e-mail]>; <[e-mail]>
> > Sent: Saturday, April 05, 2003 2:56 AM
> > Subject: RE: VPN encoding
> >
> >
> > > Mareline,
> > >
> > > Encoding of label in BGP updates - RFC3107
> > > Encoding Route Distnguisher - RFC2547bis draft
> > >
> > > -Vijay
> > >
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> > > **************************Disclaimer**************************************************
> >
> >  Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged'
> > and 'confidential' and intended for use only by the individual or entity to which it is
> > addressed. You are notified that any use, copying or dissemination of the information
> > contained in the E-MAIL in any manner whatsoever is strictly prohibited.
> >
> > ****************************************************************************************
> >
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA29401 for <[e-mail]>; Mon, 7 Apr 2003 09:41:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BBCB39120A; Mon,  7 Apr 2003 09:41:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8378091210; Mon,  7 Apr 2003 09:41:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2622B9120A for <[e-mail]>; Mon,  7 Apr 2003 09:41:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0162C5E1C6; Mon,  7 Apr 2003 09:41:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailout1.samsung.com (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id A95565E1C5 for <[e-mail]>; Mon,  7 Apr 2003 09:41:33 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Mon, 07 Apr 2003 22:41:26 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 07 Apr 2003 22:41:26 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 07 Apr 2003 22:41:25 +0900 (KST)
Date: Mon, 07 Apr 2003 19:08:58 +0530
From: Manav Bhatia <[e-mail]>
Subject: draft-ietf-idr-bgp-identifier-02.txt
To: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <0ee201c2fd0b$0db3f400$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi,
1> Section 4.2. Open Message Error  Handling states that
'If the BGP Identifier field of the OPEN message is zero, or if
 it is the same as the BGP Identifier of the local BGP speaker
 and the message is from an internal peer, then the Error Subcode
 is set to "Bad BGP Identifier"'

- why is this restriction placed only for the internal peers. What if i
receive an OPEN message from an external peer with the same BGP ID as mine?

2> Typo in section 5.
AGGREAGTOR needs to be replaced with AGGREGATOR

3> A paragraph in section 5 states
"In the route selection, where the BGP Identifier is not used
in comparing a route from an internal neighbor and a route from
an external neighbor. In addition, routes from BGP speakers with
identical BGP Identifiers have been dealt with (e.g., parallel
BGP sessions between two BGP speakers)"

Can it be re-phrased. I got lost! :-)

Regards,
Manav





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA25105 for <[e-mail]>; Mon, 7 Apr 2003 07:12:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1F3009120F; Mon,  7 Apr 2003 07:12:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6D9C91210; Mon,  7 Apr 2003 07:12:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 840D69120F for <[e-mail]>; Mon,  7 Apr 2003 07:12:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6A8365E1A0; Mon,  7 Apr 2003 07:12:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id E92055E19C for <[e-mail]>; Mon,  7 Apr 2003 07:12:19 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14898; Mon, 7 Apr 2003 07:09:47 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp-identifier-02.txt
Date: Mon, 07 Apr 2003 07:09:47 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: AS-wide Unique BGP Identifier for BGP-4
	Author(s)	: E. Chen, J. Yuan
	Filename	: draft-ietf-idr-bgp-identifier-02.txt
	Pages		: 4
	Date		: 2003-4-4
	
To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA15383 for <[e-mail]>; Mon, 7 Apr 2003 01:43:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5614491209; Mon,  7 Apr 2003 01:43:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A0109120F; Mon,  7 Apr 2003 01:43:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0779E91209 for <[e-mail]>; Mon,  7 Apr 2003 01:43:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DB7445E160; Mon,  7 Apr 2003 01:43:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by segue.merit.edu (Postfix) with SMTP id 715375E15F for <[e-mail]>; Mon,  7 Apr 2003 01:43:35 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20301.mail.yahoo.com via HTTP; Sun, 06 Apr 2003 22:43:34 PDT
Date: Sun, 6 Apr 2003 22:43:34 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: RE: VPN encoding
To: Shankar Ananthanarayanan Kambat <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Shankar,
I had figured this much out but what i wanted to know was the meaning of the term "bis" ..
what is this?

Thanks,
Mareline S.

--- Shankar Ananthanarayanan Kambat <[e-mail]> wrote:
> Second version of original spec with updated sections
> 
> - Shankar K A
> 
> 
> -----Original Message-----
> From: Mareline Sheldon [mailto:[e-mail]] 
> Sent: Monday, April 07, 2003 10:46 AM
> To: [e-mail]
> Subject: RE: VPN encoding
> 
> 
> Hello,
> Thanks a lot for the info Vijay!
> 
> Can anybody please explain me what the "bis" in RFC 2547bis stands for?
> 
> I have come across this term "bis" on a number of occasions and i am
> never able to understand
> what it truly means.
> 
> Can anybody please shed some light on that?
> 
> Thanks,
> Mareline S.
> 
> ----- Original Message ----- 
> From: "Krishnan, Vijay G." <[e-mail]>
> To: "'Mareline Sheldon'" <[e-mail]>; <[e-mail]>
> Sent: Saturday, April 05, 2003 2:56 AM
> Subject: RE: VPN encoding
> 
> 
> > Mareline,
> > 
> > Encoding of label in BGP updates - RFC3107
> > Encoding Route Distnguisher - RFC2547bis draft
> > 
> > -Vijay
> > 
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
> > **************************Disclaimer**************************************************    
>  
>  Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' 
> and 'confidential' and intended for use only by the individual or entity to which it is 
> addressed. You are notified that any use, copying or dissemination of the information 
> contained in the E-MAIL in any manner whatsoever is strictly prohibited.
> 
> ****************************************************************************************
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA15114 for <[e-mail]>; Mon, 7 Apr 2003 01:36:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 396BD91208; Mon,  7 Apr 2003 01:35:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08B049128A; Mon,  7 Apr 2003 01:35:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E651C91208 for <[e-mail]>; Mon,  7 Apr 2003 01:35:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C17585E149; Mon,  7 Apr 2003 01:35:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from wiprom2mx2.wipro.com (wiprom2mx2.wipro.com [203.197.164.42]) by segue.merit.edu (Postfix) with ESMTP id C7F8E5DFCE for <[e-mail]>; Mon,  7 Apr 2003 01:35:04 -0400 (EDT)
Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id h375Yrv12157; Mon, 7 Apr 2003 11:04:54 +0530 (IST)
Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Apr 2003 11:04:52 +0530
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ac5aa6c9-4ae4-4e54-95ce-1720522f1050"
Subject: RE: VPN encoding
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 7 Apr 2003 11:04:52 +0530
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: VPN encoding
Thread-Index: AcL8xQEfwlx2UmGxT+aTlcnwaOEYXAAAlEkA
From: "Shankar Ananthanarayanan Kambat" <[e-mail]>
To: "Mareline Sheldon" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 07 Apr 2003 05:34:52.0855 (UTC) FILETIME=[6A199C70:01C2FCC7]
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPartTM-000-ac5aa6c9-4ae4-4e54-95ce-1720522f1050
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Second version of original spec with updated sections

- Shankar K A


-----Original Message-----
From: Mareline Sheldon [mailto:[e-mail]]=20
Sent: Monday, April 07, 2003 10:46 AM
To: [e-mail]
Subject: RE: VPN encoding


Hello,
Thanks a lot for the info Vijay!

Can anybody please explain me what the "bis" in RFC 2547bis stands for?

I have come across this term "bis" on a number of occasions and i am
never able to understand
what it truly means.

Can anybody please shed some light on that?

Thanks,
Mareline S.

----- Original Message -----=20
From: "Krishnan, Vijay G." <[e-mail]>
To: "'Mareline Sheldon'" <[e-mail]>; <[e-mail]>
Sent: Saturday, April 05, 2003 2:56 AM
Subject: RE: VPN encoding


> Mareline,
>=20
> Encoding of label in BGP updates - RFC3107
> Encoding Route Distnguisher - RFC2547bis draft
>=20
> -Vijay
>=20
>=20


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

------=_NextPartTM-000-ac5aa6c9-4ae4-4e54-95ce-1720522f1050
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer**************************************************    
 
 Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' 
and 'confidential' and intended for use only by the individual or entity to which it is 
addressed. You are notified that any use, copying or dissemination of the information 
contained in the E-MAIL in any manner whatsoever is strictly prohibited.

****************************************************************************************

------=_NextPartTM-000-ac5aa6c9-4ae4-4e54-95ce-1720522f1050--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA14525 for <[e-mail]>; Mon, 7 Apr 2003 01:16:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0103991205; Mon,  7 Apr 2003 01:16:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 985DA91206; Mon,  7 Apr 2003 01:16:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 840A191205 for <[e-mail]>; Mon,  7 Apr 2003 01:16:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 67F6D5E157; Mon,  7 Apr 2003 01:16:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20310.mail.yahoo.com (web20310.mail.yahoo.com [216.136.226.91]) by segue.merit.edu (Postfix) with SMTP id E6E525DFCE for <[e-mail]>; Mon,  7 Apr 2003 01:16:04 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20310.mail.yahoo.com via HTTP; Sun, 06 Apr 2003 22:16:03 PDT
Date: Sun, 6 Apr 2003 22:16:03 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: RE: VPN encoding
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hello,
Thanks a lot for the info Vijay!

Can anybody please explain me what the "bis" in RFC 2547bis stands for?

I have come across this term "bis" on a number of occasions and i am never able to understand
what it truly means.

Can anybody please shed some light on that?

Thanks,
Mareline S.

----- Original Message ----- 
From: "Krishnan, Vijay G." <[e-mail]>
To: "'Mareline Sheldon'" <[e-mail]>; <[e-mail]>
Sent: Saturday, April 05, 2003 2:56 AM
Subject: RE: VPN encoding


> Mareline,
> 
> Encoding of label in BGP updates - RFC3107
> Encoding Route Distnguisher - RFC2547bis draft
> 
> -Vijay
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA02412 for <[e-mail]>; Fri, 4 Apr 2003 16:28:05 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C3E5891259; Fri,  4 Apr 2003 16:26:10 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F4769125A; Fri,  4 Apr 2003 16:26:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EB3291259 for <[e-mail]>; Fri,  4 Apr 2003 16:26:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5AFC75DDFB; Fri,  4 Apr 2003 16:26:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id DCDC25DD93 for <[e-mail]>; Fri,  4 Apr 2003 16:26:02 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA01608; Fri, 4 Apr 2003 16:26:00 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24966; Fri, 4 Apr 2003 16:26:01 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <2BDH50Z7>; Fri, 4 Apr 2003 16:26:01 -0500
Message-ID: <[e-mail]>
From: "Krishnan, Vijay G." <[e-mail]>
To: "'Mareline Sheldon'" <[e-mail]>, [e-mail]
Subject: RE: VPN encoding
Date: Fri, 4 Apr 2003 16:26:00 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Mareline,

Encoding of label in BGP updates - RFC3107
Encoding Route Distnguisher - RFC2547bis draft

-Vijay



-----Original Message-----
From: Mareline Sheldon [mailto:[e-mail]]
Sent: Friday, April 04, 2003 10:46 AM
To: [e-mail]
Subject: VPN encoding


Hello,
Which IETF draft/RFC explains how the MPLS/VPN information is to be encoded
inside the BGP
UPDATE message? I was unable to find this information.

What i want to know is basically which standard tells an implementor how to
put the MPLS
label, then the Route distinguisher, etc.

Any pointers in this will be really really appreciated !!!

Thanks,
Mareline S.



__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA23929 for <[e-mail]>; Fri, 4 Apr 2003 11:46:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CC75791246; Fri,  4 Apr 2003 11:46:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7659B9124B; Fri,  4 Apr 2003 11:46:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E897191246 for <[e-mail]>; Fri,  4 Apr 2003 11:46:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 125295DF47; Fri,  4 Apr 2003 11:45:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A13815DF3A for <[e-mail]>; Fri,  4 Apr 2003 11:45:47 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h34GjjH0068576; Fri, 4 Apr 2003 11:45:45 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h34Gjg9c068554; Fri, 4 Apr 2003 11:45:42 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h34Gjb017842; Fri, 4 Apr 2003 11:45:37 -0500 (EST)
Date: Fri, 4 Apr 2003 11:45:37 -0500
From: Jeffrey Haas <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: [e-mail]
Subject: Re: MIB V2: PathAttrIndex
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Apr 03, 2003 at 06:52:55PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Pedro,

On Thu, Apr 03, 2003 at 06:52:55PM -0800, Pedro Roque Marques wrote:
>     bgpM2PathAttrIndex OBJECT-TYPE
>         SYNTAX     Unsigned32
>         MAX-ACCESS read-only
>         STATUS     current
>         DESCRIPTION
>             "This value is a unique index for the per-NLRI entry
>              in the bgpM2PeerAttrTable.  It is assigned by the
>              agent at the point of creation of the bgpM2PeerAttrTable
>              row entry.  While its value is guaranteed to be unique
>              at any time, it is otherwise opaque to the management
>              application with respect to its value or the contiguity
>              of bgpM2PeerAttrIndex row instance values across rows
>              of the bgpM2PeerAttrTable.  It is used to provide an
>              index structure for other tables whose data is logically
>              per-peer, per-NLRI."
>         ::= { bgpM2NlriEntry 8 }
> 
>   I'm assuming that in the context above:
>   s/bgpM2PeerAttrTable/bgpM2NlriTable/

My typo.  Thanks for pointing it out.

> If i understand correctly, the intent here is to create an index that
> can replace the full "key" on an NLRI.

In the original bgp mib, we have the following:
        bgp4PathAttrEntry OBJECT-TYPE
            SYNTAX     Bgp4PathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION
                    "Information about a path to a network."
            INDEX { bgp4PathAttrIpAddrPrefix,
                    bgp4PathAttrIpAddrPrefixLen,
                    bgp4PathAttrPeer            }
            ::= { bgp4PathAttrTable 1 }

The sequence that then follows contains all bgp-4 (rfc 1771) defined
path attributes.

When you do a table walk, this is an amazing amount of repeated
information in some cases, especially if you just want the prefixes.

In the v2MIB, we simply take path attributes out and refer to their
existance in a separate table.

> However managing and assigning
> this index is imho a very large overhead.

I had hoped not.

> Perhaps i'm being dense,

Or just as likely, the wording isn't clear.

> but it seems to me that the overhead is
> non-trivial. Each path on any table needs to have an index, and that
> index cannot be reused when the route is deleted... meaning that one
> needs to have a mechanism to reverse lookup this index to path
> mapping.

The general idea is this.
Please take note of the following tables:
    bgpM2PathAttrTable,
    bgpM2AsPathTable,
    bgpM2PathAttrUnknownTable,
    bgpM2PathAttrOriginatorIdTable,
    bgpM2PathAttrClusterTable,
    bgpM2PathAttrCommTable,
    bgpM2PathAttrExtCommTable,
    bgpM2LinkLocalNextHopTable,

All use the bgpM2PathAttrIndex.

The general thought is that any path attributes set that is received
by a BGP speaker generally must be stored as a complete entity by the
application in some internal form - essentially a path attributes database.
The individual components may be stored in different fashions to
allow for sharing of common sets of items for space-saving purposes, but
you still need to have the original path attribute set available.

Thus, this index is simply a unique value for a given path attribute
set within your implementation.  

I had *hoped* that this method was common enough in various implementations
to make this something that greatly eases implementation of the
table by utilizing a pre-existing internal data structure index.  If
this isn't the case, then these tables need serious re-working.

If the idea happens to match your internal implementation and the above
wording needs tweaking, I would welcome suggestions with open arms.

As for the re-usability, you should be able to re-use it, but you ideally
will need to wait "long enough" to satisfy outstanding queries.  Something
about this timeliness should probably be mentioned in the mib.

> I would seem to me that the tradeof is to make
> <instance, prefix, lenght, peer-index> key for all the other tables
> that use this index. correct ?

As the PathAttrIndex is used simply for grouping path attributes
(essentially to point into a grouping of path attributes in your path
attributes database), hopefully this isn't true.  However, as I've stated
above, there is the base assumption that most implementations have some
mechanism to pre-group sets of path attributes together in the database
as they have been received.  If this is true, then indexing may add
some overhead, but hopefully not a horrible amount.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA22137 for <[e-mail]>; Fri, 4 Apr 2003 10:46:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B48CD91239; Fri,  4 Apr 2003 10:46:27 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E47091241; Fri,  4 Apr 2003 10:46:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F72791239 for <[e-mail]>; Fri,  4 Apr 2003 10:46:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 31EBA5DF71; Fri,  4 Apr 2003 10:46:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from web20307.mail.yahoo.com (web20307.mail.yahoo.com [216.136.226.88]) by segue.merit.edu (Postfix) with SMTP id D0D985DF5E for <[e-mail]>; Fri,  4 Apr 2003 10:46:18 -0500 (EST)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20307.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 07:46:18 PST
Date: Fri, 4 Apr 2003 07:46:18 -0800 (PST)
From: Mareline Sheldon <[e-mail]>
Subject: VPN encoding
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hello,
Which IETF draft/RFC explains how the MPLS/VPN information is to be encoded inside the BGP
UPDATE message? I was unable to find this information.

What i want to know is basically which standard tells an implementor how to put the MPLS
label, then the Route distinguisher, etc.

Any pointers in this will be really really appreciated !!!

Thanks,
Mareline S.



__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA28556 for <[e-mail]>; Thu, 3 Apr 2003 21:53:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F0B9F912F2; Thu,  3 Apr 2003 21:52:58 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA191912F3; Thu,  3 Apr 2003 21:52:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FE0A912F2 for <[e-mail]>; Thu,  3 Apr 2003 21:52:56 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5577C5DEB4; Thu,  3 Apr 2003 21:52:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 048645DE21 for <[e-mail]>; Thu,  3 Apr 2003 21:52:56 -0500 (EST)
Received: from bsd4-build4.juniper.net (bsd4-build4.juniper.net [172.17.28.65]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h342qtS99996; Thu, 3 Apr 2003 18:52:55 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by bsd4-build4.juniper.net (8.11.6/8.9.3) id h342qt497421; Thu, 3 Apr 2003 18:52:55 -0800 (PST) (envelope-from [e-mail])
Date: Thu, 3 Apr 2003 18:52:55 -0800 (PST)
Message-Id: <[e-mail]>
X-Authentication-Warning: bsd4-build4.juniper.net: roque set sender to [e-mail] using -f
From: Pedro Roque Marques <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: MIB V2: PathAttrIndex
Sender: [e-mail]
Precedence: bulk

Jeff,
You define...

    bgpM2PathAttrIndex OBJECT-TYPE
        SYNTAX     Unsigned32
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION
            "This value is a unique index for the per-NLRI entry
             in the bgpM2PeerAttrTable.  It is assigned by the
             agent at the point of creation of the bgpM2PeerAttrTable
             row entry.  While its value is guaranteed to be unique
             at any time, it is otherwise opaque to the management
             application with respect to its value or the contiguity
             of bgpM2PeerAttrIndex row instance values across rows
             of the bgpM2PeerAttrTable.  It is used to provide an
             index structure for other tables whose data is logically
             per-peer, per-NLRI."
        ::= { bgpM2NlriEntry 8 }

  I'm assuming that in the context above:
  s/bgpM2PeerAttrTable/bgpM2NlriTable/

If i understand correctly, the intent here is to create an index that
can replace the full "key" on an NLRI.  However managing and assigning
this index is imho a very large overhead.

Perhaps i'm being dense, but it seems to me that the overhead is
non-trivial. Each path on any table needs to have an index, and that
index cannot be reused when the route is deleted... meaning that one
needs to have a mechanism to reverse lookup this index to path
mapping.

I would seem to me that the tradeof is to make
<instance, prefix, lenght, peer-index> key for all the other tables
that use this index. correct ?

I believe i'd rather go for this second option.

  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA06491 for <[e-mail]>; Thu, 3 Apr 2003 09:38:56 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 081B9912CA; Thu,  3 Apr 2003 09:38:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9A10912CB; Thu,  3 Apr 2003 09:38:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39DDC912CA for <[e-mail]>; Thu,  3 Apr 2003 09:38:17 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 20AD35DE13; Thu,  3 Apr 2003 09:38:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 5336F5DE0C for <[e-mail]>; Thu,  3 Apr 2003 09:38:15 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA68533; Thu, 3 Apr 2003 09:36:06 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Joris Dobbelsteen" <[e-mail]>
Cc: "'IDR WG (E-mail)'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 28 Mar 2003 14:30:05 +0100." <001b01c2f52e$48505480$[e-mail]> 
Date: Thu, 03 Apr 2003 09:36:06 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <001b01c2f52e$48505480$[e-mail]>, "Joris Dobbelsteen" 
writes:
> Eric,
> 
> I would agree on it as it is, just a minor opinion:
> 
> The BGP draft might at:
>  Security Considerations
>    The authentication mechanism that an implementation
>    of BGP MUST support is specified in [RFC2385]. The
>    authentication provided by this mechanism could be
>    done on a per peer basis.
> 
> emphasize this only provide minimal security.
> "In cases where a BGP implementation accepts connections
> from unconfigured hosts, the use of IPSEC AH would couter
> these threats as well as replay attacks and would permit
> key agreement and roll-over.  If routing data confiden-
> tiality were desired, IPSEC ESP would provide that service."
> [draft-murphy-bgp-vuln-02.txt]
> 
> VERY minor notice to the vuln-draft:
> IPSec ESP would effectively defeat packet filters, as this
> hides port numbers.
> 
> - Joris


Joris,

Quite frankly I'm outraged at such comments.  Only by looking at
theoretical security issues and ignoring reality (not that the two
don't highly but imperfectly overlap) can you come to the conclusion
that IPSEC is needed and in its current form is viable as a security
solution for BGP.

I think its about time we injected some reality into
draft-murphy-bgp-vuln-02.txt.

I've added a practical considerations section.  I stuck it in as 4.2.

Comments are welcome, particularly comments from people actually
running BGP networks or building BGP routers used by ISPs.

I did not mention advanced filtering works-in-progress or proposals
such as BTSH or dynamic 4-tuple EBGP filtering since these are not yet
implemented or deployed afaik.  [aside: I strongly believe that BTSH
will prove to be a viable to protect EBGP and a preferable replacement
for current filtering which some older TTM (time-to-market) line cards
still in use are unable to support.]

I should also note that the filtering best practices are far from
universally deployed and in some cases are difficult to fully deploy
due to residual use of TTM line cards unable to support filtering.

Note that IPSEC with port numbers exposed would be a viable security
solution.  It would still be a greater computational burden than
TCP-MD5 and still might be less preferred by ISPs for that reason for
some architectures.  This change to IPSEC would at least yield two
viable options and might encourage implementation and deployment of
IPSEC as a security solution for BGP.

Curtis


--- draft-murphy-bgp-vuln-02.txt	Wed Mar  5 21:00:00 2003
+++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
@@ -149,6 +149,7 @@
 3.2.2.2 Timer events ..............................................   16
 4 Security Considerations .........................................   16
 4.1 Residual Risk .................................................   16
+4.2 Practical Considerations ......................................   16
 5 References ......................................................   17
 6 Author's Address ................................................   18
 
@@ -901,6 +902,79 @@
 Filtering is in use near some customer attachment points, but is not
 effective near the Internet center.  The other mechanisms are still
 controversial and are not yet in common use.
+
+4.2 Practical Considerations
+
+The primary usage of BGP is as a means to provide reachability
+information to Autonomous Systems (AS) and to distribute external
+reachability internally within an AS.  BGP is the routing protocol
+used to distribute global routing information in the Internet.  BGP is
+therefore used by all major Internet Service Providers (ISP) and many
+smaller providers and other organizations.  
+
+The role which BGP plays in the Internet puts BGP implementations in
+unique conditions and places unique security requirements on BGP.  BGP
+is operated over interprovider interfaces in which traffic levels push
+the state of the art in specialized packet forwarding hardware and
+exceed the performace capabilities of hardware implementation of
+decryption by many decimal orders of magnitude.  
+
+ISP networks must be and are under tight control.  The only viable
+means to protect the network elements from Denial of Service (DoS)
+attacks under such conditions are packet based filtering techniques
+based on relatively simple inspections of packets.
+
+To protect Internal BGP (IBGP) sessions, filters are applied at all
+borders to an ISP network which remove all traffic destined for
+addresses of network elements internal addresses (typically contained
+within a single prefix) and the BGP port number (179).  Packets from
+within an ISP are not forwarded from an internal interface to the BGP
+speaker's address on which External BGP (EBGP) sessions are supported,
+or to a peer's EBGP address if the BGP port number is found.  With
+appropriate consideration in router design, in the event of failure of
+a BGP peer to provide the equivalent filtering the risk of compromise
+can be limited to the peering session on which filtering is not
+performed by the peer or the interface or line card on which the
+peering is supported.  There is substantial motivation and little
+effort for ISPs to maintain such filters.
+
+Being composed entirely of specialized network equipment, under strict
+control of the ISP, the ISP network is not subject to attacks from
+within than enterprise networks are with more generalized computing
+systems and staff less carefully trained in the area of secure
+procedures.  Monitoring of traffic from within requires either
+compromise of relatively physically secure and carefully administered
+network elements or monitoring physical media.  Injection of traffic
+requires either compromise of network elements or intercept and
+replacement of traffic on physical media.
+
+The difficulty of compromise of network elements and of undetected
+tapping into physical media carrying extremely high volumes of traffic
+is much greater than the difficulty of injecting sufficient traffic
+from outside a network to effect a DoS attack.  As a result, the
+ability to packet filter on the basis of port numbers far exceeds the
+need to cryptographic strength in encapsulation.
+
+These practical considerations yield the situation in which TCP-MD5,
+though cryptographic weak, far better serves ISP security needs than
+the cryptographicly much stronger IPSEC which makes packet filtering
+infeasible.
+
+Use of BGP in smaller networks yields similar requirements.  The
+capability of a single workstation with high speed interface to
+generate false traffic far exceeds the capability of software based
+decryption or appropriately priced cryptographic hardware.  From a
+practical standpoint, these networks are also better served by
+appropriate administrative care, filtering, and TCP-MD5 than by IPSEC.
+
+This situation is likely to persist unless either cryptographic
+hardware becomes many orders of magnitude faster and cheaper or IPSEC
+supports an ability to leave IP port numbers exposed.  This
+requirement has been made known to the IPSEC WG.
+
+Until such time as IPSEC is modified, there is little choice but to
+mandate TCP-MD5 implementation and recommend TCP-MD5 usage for BGP and
+discourage IPSEC usage for BGP.
 
 5.  References
 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA16878 for <[e-mail]>; Thu, 3 Apr 2003 00:07:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B294F9122A; Thu,  3 Apr 2003 00:07:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63D40912C5; Thu,  3 Apr 2003 00:07:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6BD4F912C4 for <[e-mail]>; Thu,  3 Apr 2003 00:06:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 40B195E096; Thu,  3 Apr 2003 00:06:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id BF48B5E08D for <[e-mail]>; Thu,  3 Apr 2003 00:06:57 -0500 (EST)
Received: by sentry.gw.tislabs.com; id AAA23048; Thu, 3 Apr 2003 00:07:55 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma023036; Thu, 3 Apr 03 00:07:40 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h3356f816712; Thu, 3 Apr 2003 00:06:41 -0500 (EST)
Date: Thu, 3 Apr 2003 00:06:41 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: slides from IETF idr meeting
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Turns out that the idr list has a filter that catches base64 encoded
files and that's what happened to my messages.

So my slides from this IETF can be retrieved from ftp.tislabs.com
in /pub/rpsec/Vulnerabilitiesupdate.idr.19Mar2003.ppt

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA18805 for <[e-mail]>; Wed, 2 Apr 2003 10:09:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 147799121A; Wed,  2 Apr 2003 10:08:57 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA51C9121B; Wed,  2 Apr 2003 10:08:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C421C9121A for <[e-mail]>; Wed,  2 Apr 2003 10:08:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id AF20B5DE23; Wed,  2 Apr 2003 10:08:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 2F3725E010 for <[e-mail]>; Wed,  2 Apr 2003 10:08:55 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h32F8q8j016688 for [e-mail]; Wed, 2 Apr 2003 10:08:52 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h32F8n9c016681 for <[e-mail]>; Wed, 2 Apr 2003 10:08:49 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h32F8i505494 for [e-mail]; Wed, 2 Apr 2003 10:08:44 -0500 (EST)
Date: Wed, 2 Apr 2003 10:08:44 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-idr-bgp4-20.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Apr 01, 2003 at 07:30:59AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

IDR folk,

On Tue, Apr 01, 2003 at 07:30:59AM -0800, Yakov Rekhter wrote:
>    The data structures and FSM described in this document are conceptual
>    and do not have to be implemented precisely as described here, as long
>    as the implementations support the described functionality and their
>    externally visible behavior is the same.

As I am about to begin further work on the BGP MIBv2, the above statement
has consequences for the MIB.  If the model is purely conceptual,
do we still want to track the various flags in the MIB for the FSM?
We currently track states.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03548 for <[e-mail]>; Tue, 1 Apr 2003 11:31:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0190A912B9; Tue,  1 Apr 2003 11:31:03 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8F00912B8; Tue,  1 Apr 2003 11:30:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9FCD8912B7 for <[e-mail]>; Tue,  1 Apr 2003 11:30:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8E34E5DEEB; Tue,  1 Apr 2003 11:30:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id E7BAF5DE4A for <[e-mail]>; Tue,  1 Apr 2003 11:30:36 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA26641; Tue, 1 Apr 2003 11:31:33 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma026608; Tue, 1 Apr 03 11:31:13 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h31GUGp14081; Tue, 1 Apr 2003 11:30:16 -0500 (EST)
Date: Tue, 1 Apr 2003 11:30:16 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: context for talk and previous messages
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

I sent two messages to the list yesterday, the first containing my slides
and the second containing a correction of a typo in the first.  Only the
second made it to the list, so that message was pretty cryptic.

I tried again today, but it's been over an hour and still nothing on the list.

I suspect that "big" (200K) messages are getting shunted aside for human
oversight, and the human overseer is swamped.

So, just for context of my second message, here's the text part of my
first message that the second message corrects:



*****************************************************

Here are the slides that I presented at the idr meeting.

Sue told me that she thought that some people did not have context for my 
talk.  I thought Sue suggested my slides from the Minneapolis meeting had 
that context, but those slides are focused on status and updates.  So, for 
those who need some background, here is the recent history of the 
discussions of the draft.

Dec 01 discussion of draft-ietf-murphy-bgp-secr-04.txt
    (decided to split that draft into two)
    www.ietf.org/proceedings/01dec/slides/idr-3/index.html
Mar 02 discussion of draft-murphy-bgp-vuln-00.txt (the vulnerabilities
    half of the ..-bgp-secr draft)
    http://www.merit.edu/mail.archives/idr/2002-04/msg00004.html
    (unfortunately, slides did not make it to the proceedings)
Jul 02 mentioned in status of documents, but no presentation
Nov 02 discussion of security, but no presentation
    (draft-murphy-bgp-protect-01.txt submitted, date change only)
(***  this is the line with the typo  - my message that made it to the list 
corrected ***
  ***  this to read "draft-murphy-bgp-vuln-01.txt"                   ***)
Mar 03 status report on changes in draft draft-murphy-bgp-vuln-02.txt
    (changes needed to bring into line with FSM)
    slides attached to this message

--Sandy 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01673 for <[e-mail]>; Tue, 1 Apr 2003 10:32:56 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DBDF6912B6; Tue,  1 Apr 2003 10:31:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06800912B0; Tue,  1 Apr 2003 10:31:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA300912B6 for <[e-mail]>; Tue,  1 Apr 2003 10:31:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9E0115DECC; Tue,  1 Apr 2003 10:31:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 879E45DEC9 for <[e-mail]>; Tue,  1 Apr 2003 10:31:00 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h31FUxS57191 for <[e-mail]>; Tue, 1 Apr 2003 07:30:59 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-idr-bgp4-20.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 01 Apr 2003 07:30:59 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

The -20 version contains several (minor) editorial fixes. In addition
to the editorial fixes it contains the following in the FSM section
(the text was proposed by the Routing ADs):

   The data structures and FSM described in this document are conceptual
   and do not have to be implemented precisely as described here, as long
   as the implementations support the described functionality and their
   externally visible behavior is the same.

Yakov.
------- Forwarded Message

Date:    Tue, 01 Apr 2003 06:49:45 -0500
From:    [e-mail]
To:      IETF-Announce: ;
cc:      [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-20.txt

- --NextPart

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

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter
	Filename	: draft-ietf-idr-bgp4-20.txt
	Pages		: 86
	Date		: 2003-3-31
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protoco
l.

The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses.  This informa-
tion is sufficient to construct a graph of AS connectivity from which
routing loops may be pruned and some policy decisions at the AS level
may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.

Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy deci-
sions that can (and can not) be enforced using BGP. BGP can support
only the policies conforming to the destination-based forwarding
paradigm.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-20.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA24001 for <[e-mail]>; Tue, 1 Apr 2003 06:53:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5A5CE912AF; Tue,  1 Apr 2003 06:53:15 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17BA0912B0; Tue,  1 Apr 2003 06:53:15 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9438C912AF for <[e-mail]>; Tue,  1 Apr 2003 06:53:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 764295DE7C; Tue,  1 Apr 2003 06:53:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id C86525DDB8 for <[e-mail]>; Tue,  1 Apr 2003 06:53:12 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04985; Tue, 1 Apr 2003 06:49:45 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-20.txt
Date: Tue, 01 Apr 2003 06:49:45 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter
	Filename	: draft-ietf-idr-bgp4-20.txt
	Pages		: 86
	Date		: 2003-3-31
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses.  This informa-
tion is sufficient to construct a graph of AS connectivity from which
routing loops may be pruned and some policy decisions at the AS level
may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.

Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy deci-
sions that can (and can not) be enforced using BGP. BGP can support
only the policies conforming to the destination-based forwarding
paradigm.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-20.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--