[Idr] IDR WG meeting agenda

[Yakov Rekhter <[e-mail]>]

Folks,

Here is the agenda:

1. IDR Documents status update 5 mins

2. draft-bhatia-ecmp-routes-in-bgp-01.txt 10 mins

3. draft-ck-bgp-atm-nlri-00.txt 10 mins

4. draft-ooms-v6ops-bgp-tunnel-04.txt 10 mins

Please let Sue and myself know if we miss anything...

Yakov.

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



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17755 for <[e-mail]>; Fri, 29 Oct 2004 12:51:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZi5-00043g-0t; Fri, 29 Oct 2004 12:34:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZdk-0007sy-6S for [e-mail]; Fri, 29 Oct 2004 12:30:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13108 for <[e-mail]>; Fri, 29 Oct 2004 12:30:09 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZs3-0002hQ-8X for [e-mail]; Fri, 29 Oct 2004 12:44:59 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i9TGTeBm009217; Fri, 29 Oct 2004 09:29:40 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9TGTee65741; Fri, 29 Oct 2004 09:29:40 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 29 Oct 2004 09:29:40 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: [e-mail]
Subject: [Idr] IDR WG meeting agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

Here is the agenda:

1. IDR Documents status update 5 mins

2. draft-bhatia-ecmp-routes-in-bgp-01.txt 10 mins

3. draft-ck-bgp-atm-nlri-00.txt 10 mins

4. draft-ooms-v6ops-bgp-tunnel-04.txt 10 mins

Please let Sue and myself know if we miss anything...

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA10734 for <[e-mail]>; Sun, 24 Oct 2004 15:35:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLo7c-0005ug-TY; Sun, 24 Oct 2004 15:33:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLo6W-0005Oi-RJ for [e-mail]; Sun, 24 Oct 2004 15:32:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24984 for <[e-mail]>; Sun, 24 Oct 2004 15:32:35 -0400 (EDT)
Received: from bay17-f30.bay17.hotmail.com ([64.4.43.80] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLoJm-0003it-2y for [e-mail]; Sun, 24 Oct 2004 15:46:21 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Oct 2004 12:32:01 -0700
Received: from 219.65.133.142 by by17fd.bay17.hotmail.msn.com with HTTP; Sun, 24 Oct 2004 19:31:32 GMT
X-Originating-IP: [219.65.133.142]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] AS_SET versus AS_PATH
Date: Sun, 24 Oct 2004 19:31:32 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 24 Oct 2004 19:32:01.0640 (UTC) FILETIME=[22987680:01C4BA00]
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi Curtis,
>
>
>
>John,
>
>The above text was written with aggregation in mind which is why the
>sentence that you pointed out refers to "more detailed path
>information".  Having your own AS in the AS_SET means you can't use a
>given aggregate.  In that case, the "more detailed path information"
>is the unaggregated routes which must come to you from other paths.
>
>For the case of multipath, there are no "unaggregated routes" and so
>you can't use this route with your own AS in the AS_SET because it
>truly does loop but hopefully you have alternate.
>
>Given the following topology:
>
>
>    A ---- B
>    |      |
>    |      |
>    C ---- D ---- E
>    |             |
>     \-----F------/
>
>If a destination is learned from F by C and E, then learned from D, D
>may use C and E as a multipath.  D can advertise to B and AS_PATH of D
>[C E F].  B can advertise this to A as A B [C E F].  C cannot use that
>route.  That makes sense anyway since it is advertising the direct
>route to D.
>
>With aggregation, something meaningful could be done with more
>information.  For example, If D aggregated prefixes from C and D
>together (given that they could be aggregated), but F only sent a
>subset of prefixes in that range from C, then C could send traffic for
>the larger aggregate to D since D will either black hole it or send it
>to E.  This would not normally be done, but the aggregate could be
>accepted by C knowing that D did the aggregation before receiving
>routes from C and E.

Curtis , my point was not releated to aggregation or anything
What I was trying to point out, both in this case and in case of the 
LocaL_pref thread is that arc lengths cannot be -ve. In other words there 
has to be a <path, metric> and not just <path> else we would enter 
convergence loops.
We can increment the path/arc lenght between 2 nodes though.

>
>Can you give an example where a multipath route would have an AS_SET
>where the router receiving the route could do something useful with
>that route and more information if it had its own AS in the AS_SET?

none , but I can think of cases where , if there are 2 ECMP AS_Seq paths to 
a destination, it make make sense to send both as one could specfically 
choose to override one path. My belief is that path_length/metric cannot be 
overridden and has to exist...


>
>I don't think there is anything useful that could be done beyond
>forming the AS_SET.  If there is, then let a provider speak up and
>describe the real world situation where a solution is needed.


for that matter is AS_SET needed in the real world too?

>
>Curtis

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.com/


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA20994 for <[e-mail]>; Sat, 23 Oct 2004 00:39:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDfb-0007fG-0T; Sat, 23 Oct 2004 00:38:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDX4-0004fm-2U for [e-mail]; Sat, 23 Oct 2004 00:29:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10978 for <[e-mail]>; Sat, 23 Oct 2004 00:29:32 -0400 (EDT)
Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLDk1-0005LX-Gi for [e-mail]; Sat, 23 Oct 2004 00:42:57 -0400
Received: (qmail 86639 invoked from network); 23 Oct 2004 04:29:29 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay01.pair.com with SMTP; 23 Oct 2004 04:29:29 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i9N4Sm9N067349; Sat, 23 Oct 2004 00:28:48 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "john smith" <[e-mail]>
Subject: Re: [Idr] AS_SET versus AS_PATH 
In-reply-to: Your message of "Thu, 21 Oct 2004 18:19:56 -0000." <[e-mail]> 
Date: Sat, 23 Oct 2004 00:28:48 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"john smith" writes:
>  
>  
> hi Curtis,
>  
>  
>  
>  
> >Tony's statement is 100% accurate.  Please go back and reread the
> >parts of the BGP spec that deal with AS path and loop prevention.
>  
> yes.
>  
> >
> >Search for the word loop in the spec.
> >
> >    If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
> >    route should be excluded from the Phase 2 decision function.  AS loop
> >    detection is done by scanning the full AS path (as specified in the
> >    AS_PATH attribute), and checking that the autonomous system number of
> >    the local system does not appear in the AS path.  Operations of a BGP
> >    speaker that is configured to accept routes with its own autonomous
> >    system number in the AS path are outside the scope of this document.
> >
> >Regarding AS_SET and loop avoidance.
> >
> >       An AS_SET implies that the destinations listed in the NLRI can be
> >       reached through paths that traverse at least some of the con-
> >       stituent autonomous systems. AS_SETs provide sufficient informa-
> >       tion to avoid routing information looping; however their use may
> >       prune potentially feasible paths, since such paths are no longer
> >       listed individually as in the form of AS_SEQUENCEs. In practice
> >       this is not likely to be a problem, since once an IP packet
> >       arrives at the edge of a group of autonomous systems,
>  
> the part I like:
>  
> "the BGP
> >       speaker at that point is likely to have more detailed path infor-
> >       mation and can distinguish individual paths to destinations."
>  
>  
> ...this was my question..... as you know :)


Yeah.  Sure it was.


> >I hope that answers your questions.  This was rather easy to find, so
> >in the future could you please look at the BGP spec before posting a
> >question about BGP basics.
>  
>  
> I guess so! Sorry folks! Time to look at "Wren and Martin" and then read BGP 
> specs ;) (I like the 'MAY" on top)
>  
> -JS



John,

The above text was written with aggregation in mind which is why the
sentence that you pointed out refers to "more detailed path
information".  Having your own AS in the AS_SET means you can't use a
given aggregate.  In that case, the "more detailed path information"
is the unaggregated routes which must come to you from other paths.

For the case of multipath, there are no "unaggregated routes" and so
you can't use this route with your own AS in the AS_SET because it
truly does loop but hopefully you have alternate.

Given the following topology:


   A ---- B
   |      |
   |      |
   C ---- D ---- E
   |             |
    \-----F------/

If a destination is learned from F by C and E, then learned from D, D
may use C and E as a multipath.  D can advertise to B and AS_PATH of D
[C E F].  B can advertise this to A as A B [C E F].  C cannot use that
route.  That makes sense anyway since it is advertising the direct
route to D.

With aggregation, something meaningful could be done with more
information.  For example, If D aggregated prefixes from C and D
together (given that they could be aggregated), but F only sent a
subset of prefixes in that range from C, then C could send traffic for
the larger aggregate to D since D will either black hole it or send it
to E.  This would not normally be done, but the aggregate could be
accepted by C knowing that D did the aggregation before receiving
routes from C and E.

Can you give an example where a multipath route would have an AS_SET
where the router receiving the route could do something useful with
that route and more information if it had its own AS in the AS_SET?

I don't think there is anything useful that could be done beyond
forming the AS_SET.  If there is, then let a provider speak up and
describe the real world situation where a solution is needed.

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17295 for <[e-mail]>; Fri, 22 Oct 2004 17:16:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL68e-0008Tn-5d; Fri, 22 Oct 2004 16:35:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5jL-0007ne-Ig; Fri, 22 Oct 2004 16:09:43 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06100; Fri, 22 Oct 2004 16:09:39 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Fri, 22 Oct 2004 16:09:39 -0400
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-26.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--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, et al.
	Filename	: draft-ietf-idr-bgp4-26.txt
	Pages		: 100
	Date		: 2004-10-22
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.

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

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


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

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

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


--OtherAccess--

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

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

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA10456 for <[e-mail]>; Fri, 22 Oct 2004 02:29:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsr4-0000vo-VK; Fri, 22 Oct 2004 02:24:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsnn-0007G7-Ca for [e-mail]; Fri, 22 Oct 2004 02:21:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02713 for <[e-mail]>; Fri, 22 Oct 2004 02:21:25 -0400 (EDT)
Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKt0T-00072C-VL for [e-mail]; Fri, 22 Oct 2004 02:34:37 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: Re: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact tie-breaking rules
MIME-Version: 1.0
Date: Thu, 21 Oct 2004 23:20:50 -0700
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact tie-breaking rules
Thread-Index: AcS3/0aLSL5hTvqiTViwgBS/8Y5IGw==
From: "Enke Chen" <[e-mail]>
To: <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: be922d419820e291bde1362184dc32fd
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0185476266=="
Sender: [e-mail]
Errors-To: [e-mail]

This is a multi-part message in MIME format.

--===============0185476266==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4B7FF.468B2971"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4B7FF.468B2971
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, Tony:

In general these rules are necessary for route reflection to function =
properly,
and they have been widely deployed for at least 6 or 7 years.

Please see my comments inline.

>     * To: idr at ietf.org
>     * Subject: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact =
tie-breaking rules
>     * From: Tony Przygienda <prz at xebeo.com>
>     * Date: Tue, 19 Oct 2004 09:55:24 +0200
>=20
> Reading through bis of the RR draft stumbled over
>=20
>=20
> 9. Impact on Route Selection
>=20
>=20
>   The BGP Decision Process Tie Breaking rules (Sect. 9.1.2.2, [1]) are
>   modified as follows:
>=20
>=20
>     If a route carries the ORIGINATOR_ID attribute, then in Step f)
>     the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of
>     the BGP speaker that has advertised the route.
>

This requirement probably should be a MUST.  Route selection for IBGP =
paths
must be consistent to avoid forwarding loops.  Thus, routers within an =
AS must
have a consistent view with respect to the BGP Identifier of the router =
that
sources the route in the AS. (BGP Identifier impacts route selection.)

Forwarding loop can occur if RR is used in a network and some routers do =
not
follow this rule.

>=20
>     In addition, the following rule SHOULD be inserted between Steps
>     f) and g): a BGP Speaker SHOULD prefer a route with the shorter
>     CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route
>     does not carry the CLUSTER_LIST attribute.

When the redundent RRs within a cluster are not configured with the same =
cluster-id,
a RR may receive a route from its client directly, and from the other =
RR. With the
right combinations of peering addresses, without this rule a RR may =
select the one
from the other RR as the best path (and then withdraw its own =
advertisement), and
routing may not converge. The rule is necessary to deal with this corner =
case.

As long as routing converges, forwarding loops wouldn't form even if =
some
routers do not follow this rule. (The routes being compared are of the =
same
BGP Identifier, and thus the same next-hop anyway.)

>=20
> Now, the question comes up what to do with ECMP (which in many =
implementations
> slightly deviates from 'official' spec last I checked) especially with =
connection
> to the 'SHOULD'

I am not aware of the existence of the "offical" spec for IBGP ECMP. =
(Well I
hacked up the limited support for IBGP ECMP several years ago, and that =
seemed
to have propagated ... :-(

The first rule is important regardless of IBGP ECMP. The 2nd rule does =
not seem
to have any bearing on IBGP ECMP.

Regards,

-- Enke


>=20
> Many implementations ignore the router_id for ECMP purposes & =
load-balance
> that way and it is interesting now to think whether we can still do =
that when
>=20
> a) one route has an ORIGINATOR_ID and the other none
> b) one route has an ORIGINATOR_ID_1 !=3D ROUTER_ID_1 and =
ORIGINATOR_ID_1 !=3D ORIGINATOR_ID_2
>     BUT ROUTER_ID_1 =3D=3D ORIGINATOR_ID_2 [I admit, pathological but =
possible]
>=20
> and so on.
>=20
>=20
> Are we sure a mix of implementations old-style (ignoring the SHOULD) =
and implementations
> of new-style (take ORIGINATOR_ID always [or only sometimes] as =
ROUTER_ID) will not form
> loops with ECMP implementations ?
>=20
> The whole thing looks like another partial order in BGP route ordering =
(the first infamous
> one lead to quite a couple of med-this and med-other ... options in =
many vendors) and I
> wonder whether there is enough reason to do the same here.
>=20
> Same for CLUSTER_LIST length (albeit here I understand the scenario =
that led to the
> rule & it makes sense).
>=20
> Anyone cares to clarify and I hope I don't repeat some discussion that =
I missed on idr list ?
>=20
> 	thanks
>=20
>=20
> 	-- tony
>=20


------_=_NextPart_001_01C4B7FF.468B2971
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>Re: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact =
tie-breaking rules</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi, Tony:<BR>
<BR>
In general these rules are necessary for route reflection to function =
properly,<BR>
and they have been widely deployed for at least 6 or 7 years.<BR>
<BR>
Please see my comments inline.<BR>
<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; * To: idr at ietf.org<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; * Subject: [Idr] =
draft-ietf-idr-rfc2796bis-01: what's the exact tie-breaking rules<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; * From: Tony Przygienda &lt;prz at =
xebeo.com&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; * Date: Tue, 19 Oct 2004 09:55:24 +0200<BR>
&gt;<BR>
&gt; Reading through bis of the RR draft stumbled over<BR>
&gt;<BR>
&gt;<BR>
&gt; 9. Impact on Route Selection<BR>
&gt;<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; The BGP Decision Process Tie Breaking rules (Sect. =
9.1.2.2, [1]) are<BR>
&gt;&nbsp;&nbsp; modified as follows:<BR>
&gt;<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; If a route carries the ORIGINATOR_ID =
attribute, then in Step f)<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; the ORIGINATOR_ID SHOULD be treated as the =
BGP Identifier of<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; the BGP speaker that has advertised the =
route.<BR>
&gt;<BR>
<BR>
This requirement probably should be a MUST.&nbsp; Route selection for =
IBGP paths<BR>
must be consistent to avoid forwarding loops.&nbsp; Thus, routers within =
an AS must<BR>
have a consistent view with respect to the BGP Identifier of the router =
that<BR>
sources the route in the AS. (BGP Identifier impacts route =
selection.)<BR>
<BR>
Forwarding loop can occur if RR is used in a network and some routers do =
not<BR>
follow this rule.<BR>
<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; In addition, the following rule SHOULD be =
inserted between Steps<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; f) and g): a BGP Speaker SHOULD prefer a =
route with the shorter<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; CLUSTER_LIST length. The CLUSTER_LIST =
length is zero if a route<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; does not carry the CLUSTER_LIST =
attribute.<BR>
<BR>
When the redundent RRs within a cluster are not configured with the same =
cluster-id,<BR>
a RR may receive a route from its client directly, and from the other =
RR. With the<BR>
right combinations of peering addresses, without this rule a RR may =
select the one<BR>
from the other RR as the best path (and then withdraw its own =
advertisement), and<BR>
routing may not converge. The rule is necessary to deal with this corner =
case.<BR>
<BR>
As long as routing converges, forwarding loops wouldn't form even if =
some<BR>
routers do not follow this rule. (The routes being compared are of the =
same<BR>
BGP Identifier, and thus the same next-hop anyway.)<BR>
<BR>
&gt;<BR>
&gt; Now, the question comes up what to do with ECMP (which in many =
implementations<BR>
&gt; slightly deviates from 'official' spec last I checked) especially =
with connection<BR>
&gt; to the 'SHOULD'<BR>
<BR>
I am not aware of the existence of the &quot;offical&quot; spec for IBGP =
ECMP. (Well I<BR>
hacked up the limited support for IBGP ECMP several years ago, and that =
seemed<BR>
to have propagated ... :-(<BR>
<BR>
The first rule is important regardless of IBGP ECMP. The 2nd rule does =
not seem<BR>
to have any bearing on IBGP ECMP.<BR>
<BR>
Regards,<BR>
<BR>
-- Enke<BR>
<BR>
<BR>
&gt;<BR>
&gt; Many implementations ignore the router_id for ECMP purposes &amp; =
load-balance<BR>
&gt; that way and it is interesting now to think whether we can still do =
that when<BR>
&gt;<BR>
&gt; a) one route has an ORIGINATOR_ID and the other none<BR>
&gt; b) one route has an ORIGINATOR_ID_1 !=3D ROUTER_ID_1 and =
ORIGINATOR_ID_1 !=3D ORIGINATOR_ID_2<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; BUT ROUTER_ID_1 =3D=3D ORIGINATOR_ID_2 [I =
admit, pathological but possible]<BR>
&gt;<BR>
&gt; and so on.<BR>
&gt;<BR>
&gt;<BR>
&gt; Are we sure a mix of implementations old-style (ignoring the =
SHOULD) and implementations<BR>
&gt; of new-style (take ORIGINATOR_ID always [or only sometimes] as =
ROUTER_ID) will not form<BR>
&gt; loops with ECMP implementations ?<BR>
&gt;<BR>
&gt; The whole thing looks like another partial order in BGP route =
ordering (the first infamous<BR>
&gt; one lead to quite a couple of med-this and med-other ... options in =
many vendors) and I<BR>
&gt; wonder whether there is enough reason to do the same here.<BR>
&gt;<BR>
&gt; Same for CLUSTER_LIST length (albeit here I understand the scenario =
that led to the<BR>
&gt; rule &amp; it makes sense).<BR>
&gt;<BR>
&gt; Anyone cares to clarify and I hope I don't repeat some discussion =
that I missed on idr list ?<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; thanks<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- tony<BR>
&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4B7FF.468B2971--


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

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

--===============0185476266==--



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04711 for <[e-mail]>; Thu, 21 Oct 2004 14:54:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhm8-00052i-Hq; Thu, 21 Oct 2004 14:35:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhYU-0007ad-GJ for [e-mail]; Thu, 21 Oct 2004 14:20:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02021 for <[e-mail]>; Thu, 21 Oct 2004 14:20:52 -0400 (EDT)
Received: from bay17-f5.bay17.hotmail.com ([64.4.43.55] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhl8-0002Fc-4B for [e-mail]; Thu, 21 Oct 2004 14:34:00 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Oct 2004 11:20:16 -0700
Received: from 219.65.131.100 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 21 Oct 2004 18:19:56 GMT
X-Originating-IP: [219.65.131.100]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] AS_SET versus AS_PATH
Date: Thu, 21 Oct 2004 18:19:56 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2004 18:20:16.0446 (UTC) FILETIME=[9D42BDE0:01C4B79A]
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

hi Curtis,




>Tony's statement is 100% accurate.  Please go back and reread the
>parts of the BGP spec that deal with AS path and loop prevention.

yes.

>
>Search for the word loop in the spec.
>
>    If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
>    route should be excluded from the Phase 2 decision function.  AS loop
>    detection is done by scanning the full AS path (as specified in the
>    AS_PATH attribute), and checking that the autonomous system number of
>    the local system does not appear in the AS path.  Operations of a BGP
>    speaker that is configured to accept routes with its own autonomous
>    system number in the AS path are outside the scope of this document.
>
>Regarding AS_SET and loop avoidance.
>
>       An AS_SET implies that the destinations listed in the NLRI can be
>       reached through paths that traverse at least some of the con-
>       stituent autonomous systems. AS_SETs provide sufficient informa-
>       tion to avoid routing information looping; however their use may
>       prune potentially feasible paths, since such paths are no longer
>       listed individually as in the form of AS_SEQUENCEs. In practice
>       this is not likely to be a problem, since once an IP packet
>       arrives at the edge of a group of autonomous systems,

the part I like:

"the BGP
>       speaker at that point is likely to have more detailed path infor-
>       mation and can distinguish individual paths to destinations."


...this was my question..... as you know :)

>
>I hope that answers your questions.  This was rather easy to find, so
>in the future could you please look at the BGP spec before posting a
>question about BGP basics.


I guess so! Sorry folks! Time to look at "Wren and Martin" and then read BGP 
specs ;) (I like the 'MAY" on top)

-JS

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03395 for <[e-mail]>; Thu, 21 Oct 2004 11:57:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfCM-000805-ST; Thu, 21 Oct 2004 11:49:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKf6T-0005dP-T2 for [e-mail]; Thu, 21 Oct 2004 11:43:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14776 for <[e-mail]>; Thu, 21 Oct 2004 11:43:46 -0400 (EDT)
Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKfIw-0006Ll-Ol for [e-mail]; Thu, 21 Oct 2004 11:56:53 -0400
Received: (qmail 60211 invoked from network); 21 Oct 2004 15:43:37 -0000
Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay00.pair.com with SMTP; 21 Oct 2004 15:43:37 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id i9LFhFPh007412; Thu, 21 Oct 2004 11:43:15 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "john smith" <[e-mail]>
Subject: Re: [Idr] AS_SET versus AS_PATH 
In-reply-to: Your message of "Wed, 20 Oct 2004 19:03:37 -0000." <[e-mail]> 
Date: Thu, 21 Oct 2004 11:43:15 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"john smith" writes:
>  
>  
> so arc lengths can be negative/or the metric can decrement...?
>  
> It may/maynot lead to oscillations, but it could cause convergence issues?


John,

Tony's statement is 100% accurate.  Please go back and reread the
parts of the BGP spec that deal with AS path and loop prevention.

Search for the word loop in the spec.

   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
   route should be excluded from the Phase 2 decision function.  AS loop
   detection is done by scanning the full AS path (as specified in the
   AS_PATH attribute), and checking that the autonomous system number of
   the local system does not appear in the AS path.  Operations of a BGP
   speaker that is configured to accept routes with its own autonomous
   system number in the AS path are outside the scope of this document.

Regarding AS_SET and loop avoidance.

      An AS_SET implies that the destinations listed in the NLRI can be
      reached through paths that traverse at least some of the con-
      stituent autonomous systems. AS_SETs provide sufficient informa-
      tion to avoid routing information looping; however their use may
      prune potentially feasible paths, since such paths are no longer
      listed individually as in the form of AS_SEQUENCEs. In practice
      this is not likely to be a problem, since once an IP packet
      arrives at the edge of a group of autonomous systems, the BGP
      speaker at that point is likely to have more detailed path infor-
      mation and can distinguish individual paths to destinations.

I hope that answers your questions.  This was rather easy to find, so
in the future could you please look at the BGP spec before posting a
question about BGP basics.

Curtis


> >From: Tony Li <[e-mail]>
> >To: "john smith" <[e-mail]>
> >CC: [e-mail]
> >Subject: Re: [Idr] AS_SET versus AS_PATH
> >Date: Mon, 18 Oct 2004 11:52:26 -0700
> >
> >
> >The primary purpose of the AS_PATH is loop prevention.
> >
> >Tony
> >
> >
> >On Oct 18, 2004, at 10:48 AM, john smith wrote:
> >
> >>Hi,
> >>
> >>as far as I can understand, AS_PATH serves 2 purposes,
> >>a. it helps identify the source of the prefix
> >>
> >>b. it helps in fast convergence, (another alternative would be to use AS 
> >>and IP or originating router as the source of the route and use withdrawn 
> >>route + updates marking the NLRI), in other words, each unique upate could 
> >>consist of AS+IPv4(of originating router)+NLRI and they could be 
> >>specifically updated and withdrawn.
> >>
> >>Is my understanding correct?
> >>
> >>However, after going through draft-bhatia-ecmp and boucing it with some 
> >>people, I had a question:
> >>
> >>we retain the AS_PATH via the newly ordered AS_SET, which IMO has to be 
> >>done for all AS_SET cases as we would loose path length, and hence this 
> >>would sort of amount to a "negative arc length" when a peer propogates an 
> >>AS_SET reducing the size of the AS_PATH. This could be a potential source 
> >>of loops.
> >>
> >>Would appreciate if someone could share information on specific cases 
> >>where AS_SET has been used without retaining path length.
> >>
> >>-john

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA01584 for <[e-mail]>; Thu, 21 Oct 2004 08:01:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKanz-0001kr-LQ; Thu, 21 Oct 2004 07:08:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKLlP-0008NV-6I for [e-mail]; Wed, 20 Oct 2004 15:04:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12166 for <[e-mail]>; Wed, 20 Oct 2004 15:04:40 -0400 (EDT)
Received: from bay17-f4.bay17.hotmail.com ([64.4.43.54] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKLxk-0001rI-Vo for [e-mail]; Wed, 20 Oct 2004 15:17:35 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Oct 2004 12:04:02 -0700
Received: from 219.65.151.7 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 20 Oct 2004 19:03:37 GMT
X-Originating-IP: [219.65.151.7]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] AS_SET versus AS_PATH
Date: Wed, 20 Oct 2004 19:03:37 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Oct 2004 19:04:02.0181 (UTC) FILETIME=[8FE85B50:01C4B6D7]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

so arc lengths can be negative/or the metric can decrement...?

It may/maynot lead to oscillations, but it could cause convergence issues?

>From: Tony Li <[e-mail]>
>To: "john smith" <[e-mail]>
>CC: [e-mail]
>Subject: Re: [Idr] AS_SET versus AS_PATH
>Date: Mon, 18 Oct 2004 11:52:26 -0700
>
>
>The primary purpose of the AS_PATH is loop prevention.
>
>Tony
>
>
>On Oct 18, 2004, at 10:48 AM, john smith wrote:
>
>>Hi,
>>
>>as far as I can understand, AS_PATH serves 2 purposes,
>>a. it helps identify the source of the prefix
>>
>>b. it helps in fast convergence, (another alternative would be to use AS 
>>and IP or originating router as the source of the route and use withdrawn 
>>route + updates marking the NLRI), in other words, each unique upate could 
>>consist of AS+IPv4(of originating router)+NLRI and they could be 
>>specifically updated and withdrawn.
>>
>>Is my understanding correct?
>>
>>However, after going through draft-bhatia-ecmp and boucing it with some 
>>people, I had a question:
>>
>>we retain the AS_PATH via the newly ordered AS_SET, which IMO has to be 
>>done for all AS_SET cases as we would loose path length, and hence this 
>>would sort of amount to a "negative arc length" when a peer propogates an 
>>AS_SET reducing the size of the AS_PATH. This could be a potential source 
>>of loops.
>>
>>Would appreciate if someone could share information on specific cases 
>>where AS_SET has been used without retaining path length.
>>
>>-john
>>
>>_________________________________________________________________
>>FREE pop-up blocking with the new MSN Toolbar - get it now! 
>>http://toolbar.msn.com/
>>
>>
>>_______________________________________________
>>Idr mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/idr
>>
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA16409 for <[e-mail]>; Wed, 20 Oct 2004 00:47:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4mm-0002Ru-1o; Tue, 19 Oct 2004 20:57:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK2xy-0003B8-52 for [e-mail]; Tue, 19 Oct 2004 19:00:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26546 for <[e-mail]>; Tue, 19 Oct 2004 19:00:22 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK3AA-00062g-2j for [e-mail]; Tue, 19 Oct 2004 19:13:07 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i9JMxq949910 for <[e-mail]>; Tue, 19 Oct 2004 15:59:52 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9JMxle96854 for <[e-mail]>; Tue, 19 Oct 2004 15:59:47 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 19 Oct 2004 15:59:47 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Subject: [Idr] revised BGP security Vulnerability Analysis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,


The revised draft reflects the comments received from the IESG.

Yakov.
------- Forwarded Message

Date:    Tue, 19 Oct 2004 07:49:07 -0400
From:    [e-mail]
To:      [e-mail]
cc:      [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-vuln-01.txt

- --NextPart

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

	Title		: BGP Security Vulnerabilities Analysis
	Author(s)	: S. Murphy
	Filename	: draft-ietf-idr-bgp-vuln-01.txt
	Pages		: 24
	Date		: 2004-10-18
	
Border Gateway Protocol 4 (BGP-4), along with a host of other
infrastructure protocols designed before the Internet environment became
perilous, was originally designed with little consideration for
protection of the information it carries.  There are no mechanisms
internal to the BGP protocol to protect against attacks that modify,
delete, forge, or replay data, any of which has the potential to disrupt
overall network routing behavior.

This internet draft discusses some of the security issues with BGP
routing data dissemination.  This internet draft does not discuss
security issues with forwarding of packets.

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

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


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

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

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


- --OtherAccess--

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

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

- --NextPart--




------- End of Forwarded Message


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12274 for <[e-mail]>; Tue, 19 Oct 2004 16:25:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsmb-00073d-4Y; Tue, 19 Oct 2004 08:08:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsUG-0003tn-V4; Tue, 19 Oct 2004 07:49:09 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14486; Tue, 19 Oct 2004 07:49:07 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Tue, 19 Oct 2004 07:49:07 -0400
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-vuln-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

--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 Security Vulnerabilities Analysis
	Author(s)	: S. Murphy
	Filename	: draft-ietf-idr-bgp-vuln-01.txt
	Pages		: 24
	Date		: 2004-10-18
	
Border Gateway Protocol 4 (BGP-4), along with a host of other
infrastructure protocols designed before the Internet environment became
perilous, was originally designed with little consideration for
protection of the information it carries.  There are no mechanisms
internal to the BGP protocol to protect against attacks that modify,
delete, forge, or replay data, any of which has the potential to disrupt
overall network routing behavior.

This internet draft discusses some of the security issues with BGP
routing data dissemination.  This internet draft does not discuss
security issues with forwarding of packets.

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

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


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

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

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


--OtherAccess--

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

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

--NextPart--





Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA06927 for <[e-mail]>; Tue, 19 Oct 2004 04:43:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJpAK-0007YW-Kj; Tue, 19 Oct 2004 04:16:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJoqh-0004it-O1 for [e-mail]; Tue, 19 Oct 2004 03:56:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27926 for <[e-mail]>; Tue, 19 Oct 2004 03:55:56 -0400 (EDT)
Received: from [216.37.114.8] (helo=lxmail.xebeo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJp2l-0006ik-Ia for [e-mail]; Tue, 19 Oct 2004 04:08:32 -0400
Received: (qmail 15186 invoked from network); 19 Oct 2004 07:55:23 -0000
Received: from unknown (HELO xebeo.com) (172.16.104.132) by lxmail.nj.us.utstar.com with SMTP; 19 Oct 2004 07:55:23 -0000
Message-ID: <[e-mail]>
Date: Tue, 19 Oct 2004 09:55:24 +0200
From: Tony Przygienda <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Subject: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact tie-breaking rules
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Reading through bis of the RR draft stumbled over

>9. Impact on Route Selection
>
>   The BGP Decision Process Tie Breaking rules (Sect. 9.1.2.2, [1]) are
>   modified as follows:
>
>     If a route carries the ORIGINATOR_ID attribute, then in Step f)
>     the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of
>     the BGP speaker that has advertised the route.
>
>     In addition, the following rule SHOULD be inserted between Steps
>     f) and g): a BGP Speaker SHOULD prefer a route with the shorter
>     CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route
>     does not carry the CLUSTER_LIST attribute.



Now, the question comes up what to do with ECMP (which in many implementations
slightly deviates from 'official' spec last I checked) especially with connection
to the 'SHOULD' 

Many implementations ignore the router_id for ECMP purposes & load-balance
that way and it is interesting now to think whether we can still do that when

a) one route has an  ORIGINATOR_ID and the other none
b) one route has an  ORIGINATOR_ID_1 != ROUTER_ID_1 and ORIGINATOR_ID_1 != ORIGINATOR_ID_2 
	BUT   ROUTER_ID_1 == ORIGINATOR_ID_2   [I admit, pathological but possible]

and so on.

Are we sure a mix of implementations old-style (ignoring the SHOULD) and 
implementations of new-style (take ORIGINATOR_ID always [or only sometimes] as 
ROUTER_ID) will not form loops with ECMP implementations ? 

The whole thing looks like another partial order in BGP route ordering (the first 
infamous one lead to quite a couple of med-this and med-other ... options in many
vendors) and I wonder whether there is enough reason to do the same here.

Same for CLUSTER_LIST length (albeit here I understand the scenario that led to the 
rule & it makes sense). 

Anyone cares to clarify and I hope I don't repeat some discussion that I missed on 
idr list ? 

	thanks

	-- tony




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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA29927 for <[e-mail]>; Mon, 18 Oct 2004 15:48:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJd3f-0006ej-Kh; Mon, 18 Oct 2004 15:20:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJcd6-00039C-6l for [e-mail]; Mon, 18 Oct 2004 14:53:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12213 for <[e-mail]>; Mon, 18 Oct 2004 14:53:05 -0400 (EDT)
Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJcp0-00073m-RY for [e-mail]; Mon, 18 Oct 2004 15:05:34 -0400
Received: from [192.168.1.3] (c-67-164-0-92.client.comcast.net[67.164.0.92]) by comcast.net (sccrmhc13) with SMTP id <20041018185227016000s3che> (Authid: li.tony); Mon, 18 Oct 2004 18:52:28 +0000
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Tony Li <[e-mail]>
Subject: Re: [Idr] AS_SET versus AS_PATH
Date: Mon, 18 Oct 2004 11:52:26 -0700
To: "john smith" <[e-mail]>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

The primary purpose of the AS_PATH is loop prevention.

Tony


On Oct 18, 2004, at 10:48 AM, john smith wrote:

> Hi,
>
> as far as I can understand, AS_PATH serves 2 purposes,
> a. it helps identify the source of the prefix
>
> b. it helps in fast convergence, (another alternative would be to use 
> AS and IP or originating router as the source of the route and use 
> withdrawn route + updates marking the NLRI), in other words, each 
> unique upate could consist of AS+IPv4(of originating router)+NLRI and 
> they could be specifically updated and withdrawn.
>
> Is my understanding correct?
>
> However, after going through draft-bhatia-ecmp and boucing it with 
> some people, I had a question:
>
> we retain the AS_PATH via the newly ordered AS_SET, which IMO has to 
> be done for all AS_SET cases as we would loose path length, and hence 
> this would sort of amount to a "negative arc length" when a peer 
> propogates an AS_SET reducing the size of the AS_PATH. This could be a 
> potential source of loops.
>
> Would appreciate if someone could share information on specific cases 
> where AS_SET has been used without retaining path length.
>
> -john
>
> _________________________________________________________________
> FREE pop-up blocking with the new MSN Toolbar - get it now! 
> http://toolbar.msn.com/
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA29313 for <[e-mail]>; Mon, 18 Oct 2004 14:31:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbyb-0001SS-GY; Mon, 18 Oct 2004 14:11:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbdl-0006i6-RO for [e-mail]; Mon, 18 Oct 2004 13:49:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06117 for <[e-mail]>; Mon, 18 Oct 2004 13:49:43 -0400 (EDT)
Received: from bay17-f40.bay17.hotmail.com ([64.4.43.90] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbph-0005a5-Iq for [e-mail]; Mon, 18 Oct 2004 14:02:11 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Oct 2004 10:49:04 -0700
Received: from 219.65.152.214 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 18 Oct 2004 17:48:08 GMT
X-Originating-IP: [219.65.152.214]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Date: Mon, 18 Oct 2004 17:48:08 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 18 Oct 2004 17:49:04.0853 (UTC) FILETIME=[C2771050:01C4B53A]
X-Spam-Score: 1.0 (+)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Idr] AS_SET versus AS_PATH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi,

as far as I can understand, AS_PATH serves 2 purposes,
a. it helps identify the source of the prefix

b. it helps in fast convergence, (another alternative would be to use AS and 
IP or originating router as the source of the route and use withdrawn route 
+ updates marking the NLRI), in other words, each unique upate could consist 
of AS+IPv4(of originating router)+NLRI and they could be specifically 
updated and withdrawn.

Is my understanding correct?

However, after going through draft-bhatia-ecmp and boucing it with some 
people, I had a question:

we retain the AS_PATH via the newly ordered AS_SET, which IMO has to be done 
for all AS_SET cases as we would loose path length, and hence this would 
sort of amount to a "negative arc length" when a peer propogates an AS_SET 
reducing the size of the AS_PATH. This could be a potential source of loops.

Would appreciate if someone could share information on specific cases where 
AS_SET has been used without retaining path length.

-john

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.com/


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26383 for <[e-mail]>; Fri, 15 Oct 2004 17:49:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZnj-0001OQ-JX; Fri, 15 Oct 2004 17:39:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZbT-0003kr-07 for [e-mail]; Fri, 15 Oct 2004 17:27:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23794 for <[e-mail]>; Fri, 15 Oct 2004 17:27:07 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.194] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZmt-0005jT-64 for [e-mail]; Fri, 15 Oct 2004 17:39:00 -0400
Received: by mproxy.gmail.com with SMTP id 75so43132rnk for <[e-mail]>; Fri, 15 Oct 2004 14:27:07 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IKLr7euWx2XNrArlTDsncPmAudj2nR4S9/7n9XGKzi2XxgxOneFx4iuEe7BlVwMxn0sGbVxA6qa6VI0heBnTBAt8b0JsHmcI5itG/biycmp/Msod4swt+Hmk4Xgk0eFF0UP/j+Znb+jbTVW7y4i8yqYzBHqbW+9OMosYXnpluzk
Received: by 10.38.152.19 with SMTP id z19mr441622rnd; Fri, 15 Oct 2004 14:27:07 -0700 (PDT)
Received: by 10.38.102.21 with HTTP; Fri, 15 Oct 2004 14:27:07 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 16 Oct 2004 02:57:07 +0530
From: Glen Kent <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]> <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Glen Kent <[e-mail]>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

> > > > 1 3 3
> > > > 2 4 4
>
> If traffic to the same destination was split among these paths based
> on a somewhat arbitrary decision (usually src/dst hash) then none of
> AS 1,2,3 or 4 could learn this route and forward to it without forming
> a forwarding loop.  From the standpoint of loop suppression (which is
> after all the purpose of the AS PATH) the AS SET [ 1 2 3 4 ] is all
> that needs to be advertised and is exactly what should be advertised.

I had thought the same. But a closer inspection of the draft reveals
"However, care must be taken to ensure that the AS_PATH length of the
individual contributing AS_PATHs is retained in this 'aggregated' path
and enough information is there, to enable the receiving peer (and the
downstream peers) to detect AS loops.".

I believe its to preserve the AS_PATH length. If you make up an AS_SET
the way you suggest then you lose your PATH length information.

Affably,
Kent

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA23649 for <[e-mail]>; Fri, 15 Oct 2004 12:38:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUqI-00018i-I5; Fri, 15 Oct 2004 12:22:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUjC-00074f-EF for [e-mail]; Fri, 15 Oct 2004 12:14:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16853 for <[e-mail]>; Fri, 15 Oct 2004 12:14:47 -0400 (EDT)
Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CIUua-0003Ht-7k for [e-mail]; Fri, 15 Oct 2004 12:26:37 -0400
Received: (qmail 26368 invoked from network); 15 Oct 2004 16:14:47 -0000
Received: from 69.37.59.189.adsl.snet.net (HELO laptoy770.faster-light.net) (69.37.59.189) by relay.pair.com with SMTP; 15 Oct 2004 16:14:47 -0000
X-pair-Authenticated: 69.37.59.189
Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i9FGIN04093722; Fri, 15 Oct 2004 12:18:23 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "john smith" <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt 
In-reply-to: Your message of "Thu, 14 Oct 2004 14:11:24 -0000." <[e-mail]> 
Date: Fri, 15 Oct 2004 12:18:23 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"john smith" writes:
>  
> I would also like to know why the draft cannot keep things simple and 
> propogate all the paths as AS_PATHs instead of the proposed AS_SET manner?
>  
> Eitherways you are assuming that the presence of the ECMP_NEXT_HOP sufficies 
> to differentiate between the 2 cases. ie vanilla BGP or ECMP_CAP BGP.
>  
> -JS
>  
[... stuff deleted ...]


Its not that we couldn't modify BGP to send a pair of AS SEQ for a
multipath, but you would not make any practical gain over putting the
same information in an AS SET.

An example given was the AS paths

> > > 1 3 3
> > > 2 4 4

If traffic to the same destination was split among these paths based
on a somewhat arbitrary decision (usually src/dst hash) then none of
AS 1,2,3 or 4 could learn this route and forward to it without forming
a forwarding loop.  From the standpoint of loop suppression (which is
after all the purpose of the AS PATH) the AS SET [ 1 2 3 4 ] is all
that needs to be advertised and is exactly what should be advertised.

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA10675 for <[e-mail]>; Thu, 14 Oct 2004 10:38:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6fd-000778-RU; Thu, 14 Oct 2004 10:33:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6ZE-0004fq-6o for [e-mail]; Thu, 14 Oct 2004 10:26:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23606 for <[e-mail]>; Thu, 14 Oct 2004 10:26:53 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI6kC-0003O1-FW for [e-mail]; Thu, 14 Oct 2004 10:38:29 -0400
Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7743149; Thu, 14 Oct 2004 10:26:35 -0400
Message-Id: <5.1.0.14.0.20041014102429.02296198@localhost>
X-Sender: [e-mail]@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Oct 2004 10:26:02 -0400
To: "john smith" <[e-mail]>, [e-mail]
From: "Joel M. Halpern" <[e-mail]>
Subject: Re: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

There is no current mechanism in BGP to set two AS PATHS in the same update.
The ECMP mechanism does permit that.
However, when an ECMP participant who is using multiple paths speaks to a 
non ECMP router (one that does not support the extension) it must advertise 
an AS PATH that can be used to avoid loops.
That advertisement is where the synthesized AS_SET is required.

Yours,
Joel M. Halpern

At 02:11 PM 10/14/2004 +0000, john smith wrote:
>I would also like to know why the draft cannot keep things simple and 
>propogate all the paths as AS_PATHs instead of the proposed AS_SET manner?
>
>Eitherways you are assuming that the presence of the ECMP_NEXT_HOP 
>sufficies to differentiate between the 2 cases. ie vanilla BGP or ECMP_CAP BGP.
>
>-JS
>
>>From: "ephim  era" <[e-mail]>
>>Reply-To: ephim  era <[e-mail]>
>>To: [e-mail]
>>Subject: Re: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
>>Date: 14 Oct 2004 11:35:34 -0000
>>
>>   Hi All,
>>        Got a doubt. When OSPF is having ECMP routes and we are doing 
>> redistibution of OSPF routes to BGP, Should BGP get all 3 prefixes with 
>> different nexthops ?
>>
>>Thanks in advance,
>>Ephim
>>
>>
>>On Thu, 23 Sep 2004 Manav Bhatia wrote :
>> >Jeff,
>> >
>> > > WD_NLRI: NULL
>> > > Path Attributes:
>> > >   + Origin - IGP
>> > >   + AS_PATH - 65535
>> > >   + NEXT_HOP - 192.168.1.1
>> > >   + MP_REACH_NLRI
>> > >     o AFI - 1 (ipv4)
>> > >     o SAFI - 1 (unicast)
>> > >     o MP_NEXTHOP - 192.168.1.2
>> > >     o MP_NLRI - 10.0.1/24
>> > > NLRI: 10.0.0/24
>> > >
>> > > If one wanted to insert an IPv4/Unicast ECMP nexthop set here, which
>> > > NLRI set would it apply to?
>> >
>> >Like the other path attributes ORIGIN, AS_PATH, etc. ECMP_NEXT_HOP too
>> >applies to all the NLRIs listed in an UPDATE message. If in this case you
>> >had an additional next-hop for only 10.0.0/24, you could announce this
>> >information in the following two ways.
>> >
>> >Let the additional NEXT_HOP be 192.168.1.3
>> >
>> >(i) In addition to the above UPDATE message you could announce another one
>> >containing
>> >
>> >WD_NLRI: NULL
>> >Path Attributes:
>> >   + Origin - IGP
>> >   + AS_PATH - 65535
>> >   + ECMP_NEXT_HOP
>> >     o AFI - 1 (ipv4)
>> >     o SAFI - 1 (unicast)
>> >     o NUM NEXTHOPs - 1
>> >     o LENGTH - 4
>> >     o MP_NEXTHOP - 192.168.1.3
>> >NLRI: 10.0.0/24
>> >
>> >The IBGP peer upon receiving this UPDATE message will know that it needs to
>> >append this route rather than replace.
>> >
>> >(ii) You could announce the following two UPDATE messages.
>> >
>> >WD_NLRI: NULL
>> >Path Attributes:
>> >   + Origin - IGP
>> >   + AS_PATH - 65535
>> >   + NEXT_HOP - 192.168.1.1
>> >   + ECMP_NEXT_HOP
>> >     o AFI - 1 (ipv4)
>> >     o SAFI - 1 (unicast)
>> >     o NUM NEXTHOPs - 1
>> >     o LENGTH - 4
>> >     o MP_NEXTHOP - 192.168.1.3
>> >NLRI: 10.0.0/24
>> >
>> >and
>> >
>> >WD_NLRI: NULL
>> >Path Attributes:
>> >   + Origin - IGP
>> >   + AS_PATH - 65535
>> >   + MP_REACH_NLRI
>> >     o AFI - 1 (ipv4)
>> >     o SAFI - 1 (unicast)
>> >     o MP_NEXTHOP - 192.168.1.2
>> >     o MP_NLRI - 10.0.1/24
>> >
>> >How you advertise the routes depends upon the time (apart from your
>> >implementation) at which the information about this additional NEXT_HOP is
>> >known to the originating router.
>> >
>> >[..]
>> > > > Put the NLRI in MP_REACH_NLRI. Set the length and the address of 
>> the MP
>> > > > nexthop as Zero. Put this MP nexthop info in ECMP_NEXT_HOP and 
>> advertise
>> > > > this to your IBGP peer. It will append this route, as it has been
>> >advertised
>> > > > with ECMP_NEXT_HOP.
>> > >
>> > > I think what makes me uncomfortable with this mechanism is implicitly
>> > > using the normal NEXT_HOP as a reset mechanism.  Just from a coding
>> > > standpoint, I'd rather see either no normal nexthop and a set of
>> > > ECMP nexthops which always have an implicit withdrawal behavior
>> > > or no ECMP nexthops at all.
>> >
>> >Could you elaborate on why using the ordinary NEXT_HOP for implicit
>> >withdrawls makes you feel uneasy? We think having such a mechanism in 
>> place,
>> >makes it easier to understand the new capability (everybody is familiar 
>> with
>> >how implicit withdrawls work) and introduces no additional burden on the
>> >implementation. The way it works is that any time you receive an UPDATE
>> >message with ECMP_NEXT_HOP, you know that the route needs to be 
>> appended and
>> >not replaced!
>> >
>> >Let me explain what i think you are suggesting. Correct me if i am wrong.
>> >
>> >Lets assume we have two next-hops N1 and N2 for a NLRI. Say after some
>> >point, we get another one N3. You suggest that we should now announce
>> >ECMP_NEXT_HOP N1, N2 and N3. That way, whenever you receive a new UPDATE,
>> >you always treat that as an implicit withdraw, the way BGP works now. Is
>> >that it?
>> >
>> >I would prefer the former approach because there can be cases (L3 VPN 
>> NLRIs,
>> >etc) where the NLRI may be clubbed with some information (labels, etc) that
>> >may make it non unique. In such cases, its much easier to use the mechanism
>> >that we have described. This'll become clearer when i explain how ECMP can
>> >work with 3107.
>> >
>> > >
>> > > > IMO a PE can do load splitting in whatever manner it wants to. It
>> > > doesn't
>> > > > need to inform the other PE that there is more than one next-hop
>> > > available
>> > > > to reach a destination. Basically its something similar to what we 
>> have
>> > > done
>> > > > for EBGP peers.
>> > >
>> > > Yes, it could do whatever it wanted to.  However, RFC 3107 implicitly
>> > > expects that you only get one nexthop.  If you get more than one,
>> > > this will potentially affect the behavior.  The change in behavior
>> > > should be discussed somewhere - and I think that your draft is probably
>> > > the right place to do that.
>> > >
>> >
>> >I may be missing something, but isn't this more of an implementation
>> >specific issue?
>> >
>> >Anyways, there isn't anything in this draft that precludes this.
>> >
>> >Assume that a PE router has two next-hops to reach some NLRI x.y.z.w. 
>> Let L1
>> >and L2 be the labels associated with these next-hops. It could send this
>> >information the following way
>> >
>> >WD_NLRI: NULL
>> >Path Attributes:
>> >   + Origin - IGP
>> >   + AS_PATH - 65535
>> >   + MP_REACH_NLRI
>> >     o AFI - IPv4
>> >     o SAFI - VPN
>> >     o MP_NEXTHOP - 0::192.168.1.2
>> >     o MP_NLRI - L1:RD:x.y.z.w
>> >
>> >and
>> >
>> >WD_NLRI: NULL
>> >Path Attributes:
>> >   + Origin - IGP
>> >   + AS_PATH - 65535
>> >   + MP_REACH_NLRI
>> >     o AFI - IPv4
>> >     o SAFI - VPN
>> >     o MP_NEXTHOP - 0
>> >     o MP_NLRI - L2:RD:x.y.z.w
>> >  + ECMP_NEXT_HOP
>> >     o AFI - IPv4
>> >     o SAFI - VPN
>> >     o NUM NEXTHOPs - 1
>> >     o LENGTH - 4
>> >     o MP_NEXTHOP - 0::192.168.1.3
>> >
>> > > > ]I'm most concerned about the synthesized AS_PATH.
>> > > > ] o In some circumstances, particularly with large AS_SETs, it 
>> will not
>> > > > ]   be possible to preserve path length.
>> > > >
>> > > > Could you give me an example to illustrate this?
>> > >
>> > > 10/8 NH a Path 1 2 [<255 ASes>]
>> > > 10/8 NH b Path 3 4 [<255 ASes>]
>> >
>> >I believe, the above means that each AS_PATH contains 2 ASes in AS_SEQ and
>> >one large AS_SET containing 255 ASes against, each path having 257 ASes in
>> >AS_SEQ.
>> >
>> > >
>> > > Resulting advertisement:
>> > > 10/8 ECMP NH a,b Path [1 3] [2 4] [<first part of first path/second 
>> path>]
>> > > [<second part of first path/second path>]
>> >
>> >Refer to Sec. 16.1 on how we construct the synthetic AS Paths in cases 
>> where
>> >the contributing AS Paths consist of AS_SETs.
>> >
>> >Resulting advertisement will be:
>> >10/8 ECMP NH a,b Path [1 3] [2 4] [<255 ASes from the first path> <255 ASes
>> >in the second path>]
>> >
>> >The problem of over flowing that will occur in constructing this extremely
>> >large AS_SET is also present in ordinary BGP, and yes, something that we
>> >need to work upon!
>> >
>> > >
>> > > Note that this presumes that the set elements in the original
>> > > advertisement are disjoint and thus not prone to merging.
>> > >
>> > > The path is thus lengthened.
>> >
>> >Yes. If we have more than 255 ASes present in the AS_SET, then we may need
>> >to prepend a new segment of type AS_SET, which will increase the path
>> >length, as each AS_SET is counted as 1, irrespective of the number of ASes
>> >present in the set.
>> >
>> >However, this can be easily avoided by introducing a new path segment type
>> >AS_EXT_SET (value 3) which will have exactly the same semantics as the
>> >existing AS_SET, except that it wont be considered when counting the 
>> AS_PATH
>> >length.
>> >
>> > >
>> > > > ] o Processing ECMP routes into paths of equivalent length with many
>> > > > ]   AS_SETs will impact AS_PATH regular expression engines.
>> > > > ] o The set merging rules of BGP (9.2.2.2, draft 25) can result
>> > > > ]   in the AS_PATH being shortened.
>> > > >
>> > > > I am sorry, I didn't get this!
>> > >
>> > > As for the first:
>> > >
>> > > I get [1 3] [2 4] (rest)
>> > >
>> > > Previously I would have gotten 1 2 (rest) or 3 4 (rest).
>> > >
>> > > I can do a regular expression that says "Match 1 2 .*$" and prefer this
>> > > path.
>> >
>> >You really cant run your regular expression here that says "match 1 2 .$"
>> >because now your traffic will be split across paths "1 2 (rest)" and "3 4
>> >(rest)". Moreover, this seems to be an implementation issue and i am sure
>> >vendors can find clever ways to do this.
>> >
>> > > Per the aggregation rules, one would typically not see sets such as
>> > > [1 3] [2 4] in the net.  An implementation would typically create
>> > > [1 2 3 4] as part of aggregation.  Generating separate sets is a 
>> deviation
>> > > from the specification, but not a mandatory one:
>> > >
>> > >             - for each pair of adjacent tuples in the aggregated
>> > >             AS_PATH, if both tuples have the same type, merge them
>> > >             together, as long as doing so will not cause a segment with
>> > >             length greater than 255 to be generated.
>> > >
>> > > The multiple set element encoding doesn't break BGP, but it makes a
>> > > presumption that really isn't all that clear in -25.
>> >
>> >I am not sure if we can call this as "deviating" from the base spec.
>> >Multiprotocol extensions did something similar for NEXT_HOP attribute.
>> >
>> > > That presumption
>> > > is that an implementation will not take adjacent set elements and
>> > > merge them.  Also, it presumes that an implementation wont choose
>> > > to clean up sets of the form:
>> > >
>> > > [1 2] [3 4] [3 4]
>> > >
>> > > where the original was:
>> > > 1 3 3
>> > > 2 4 4
>> > >
>> > > As by the aggregation rules, a given set element should exist within
>> > > the AS_PATH only once.
>> > >
>> > > I suspect it would be ... instructive to find out what various
>> >implementations
>> > > do with odd AS_PATHs as would be generated by the synthetic AS_PATH.
>> >
>> >Definitely.
>> >
>> >Cheers,
>> >Manav
>> >
>> >
>> >_______________________________________________
>> >Idr mailing list
>> >[e-mail]
>> >https://www1.ietf.org/mailman/listinfo/idr
>>
>>_______________________________________________
>>Idr mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/idr
>
>_________________________________________________________________
>FREE pop-up blocking with the new MSN Toolbar - get it now! 
>http://toolbar.msn.com/
>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA10585 for <[e-mail]>; Thu, 14 Oct 2004 10:19:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6Pf-0007ma-3d; Thu, 14 Oct 2004 10:17:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6LV-0002sb-5o for [e-mail]; Thu, 14 Oct 2004 10:12:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20972 for <[e-mail]>; Thu, 14 Oct 2004 10:12:43 -0400 (EDT)
Received: from bay17-f7.bay17.hotmail.com ([64.4.43.57] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI6Wf-000328-FT for [e-mail]; Thu, 14 Oct 2004 10:24:18 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Oct 2004 07:12:03 -0700
Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 14 Oct 2004 14:11:24 GMT
X-Originating-IP: [61.16.170.194]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Date: Thu, 14 Oct 2004 14:11:24 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 14 Oct 2004 14:12:03.0334 (UTC) FILETIME=[C761F260:01C4B1F7]
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA20972
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA10585

I would also like to know why the draft cannot keep things simple and 
propogate all the paths as AS_PATHs instead of the proposed AS_SET manner?

Eitherways you are assuming that the presence of the ECMP_NEXT_HOP sufficies 
to differentiate between the 2 cases. ie vanilla BGP or ECMP_CAP BGP.

-JS

>From: "ephim  era" <[e-mail]>
>Reply-To: ephim  era <[e-mail]>
>To: [e-mail]
>Subject: Re: Re: [Idr] FW: I-D 
>ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
>Date: 14 Oct 2004 11:35:34 -0000
>
>   Hi All,
>        Got a doubt. When OSPF is having ECMP routes and we are doing 
>redistibution of OSPF routes to BGP, Should BGP get all 3 prefixes with 
>different nexthops ?
>
>Thanks in advance,
>Ephim
>
>
>On Thu, 23 Sep 2004 Manav Bhatia wrote :
> >Jeff,
> >
> > > WD_NLRI: NULL
> > > Path Attributes:
> > >   + Origin - IGP
> > >   + AS_PATH - 65535
> > >   + NEXT_HOP - 192.168.1.1
> > >   + MP_REACH_NLRI
> > >     o AFI - 1 (ipv4)
> > >     o SAFI - 1 (unicast)
> > >     o MP_NEXTHOP - 192.168.1.2
> > >     o MP_NLRI - 10.0.1/24
> > > NLRI: 10.0.0/24
> > >
> > > If one wanted to insert an IPv4/Unicast ECMP nexthop set here, which
> > > NLRI set would it apply to?
> >
> >Like the other path attributes ORIGIN, AS_PATH, etc. ECMP_NEXT_HOP too
> >applies to all the NLRIs listed in an UPDATE message. If in this case you
> >had an additional next-hop for only 10.0.0/24, you could announce this
> >information in the following two ways.
> >
> >Let the additional NEXT_HOP be 192.168.1.3
> >
> >(i) In addition to the above UPDATE message you could announce another 
>one
> >containing
> >
> >WD_NLRI: NULL
> >Path Attributes:
> >   + Origin - IGP
> >   + AS_PATH - 65535
> >   + ECMP_NEXT_HOP
> >     o AFI - 1 (ipv4)
> >     o SAFI - 1 (unicast)
> >     o NUM NEXTHOPs - 1
> >     o LENGTH - 4
> >     o MP_NEXTHOP - 192.168.1.3
> >NLRI: 10.0.0/24
> >
> >The IBGP peer upon receiving this UPDATE message will know that it needs 
>to
> >append this route rather than replace.
> >
> >(ii) You could announce the following two UPDATE messages.
> >
> >WD_NLRI: NULL
> >Path Attributes:
> >   + Origin - IGP
> >   + AS_PATH - 65535
> >   + NEXT_HOP - 192.168.1.1
> >   + ECMP_NEXT_HOP
> >     o AFI - 1 (ipv4)
> >     o SAFI - 1 (unicast)
> >     o NUM NEXTHOPs - 1
> >     o LENGTH - 4
> >     o MP_NEXTHOP - 192.168.1.3
> >NLRI: 10.0.0/24
> >
> >and
> >
> >WD_NLRI: NULL
> >Path Attributes:
> >   + Origin - IGP
> >   + AS_PATH - 65535
> >   + MP_REACH_NLRI
> >     o AFI - 1 (ipv4)
> >     o SAFI - 1 (unicast)
> >     o MP_NEXTHOP - 192.168.1.2
> >     o MP_NLRI - 10.0.1/24
> >
> >How you advertise the routes depends upon the time (apart from your
> >implementation) at which the information about this additional NEXT_HOP 
>is
> >known to the originating router.
> >
> >[..]
> > > > Put the NLRI in MP_REACH_NLRI. Set the length and the address of the 
>MP
> > > > nexthop as Zero. Put this MP nexthop info in ECMP_NEXT_HOP and 
>advertise
> > > > this to your IBGP peer. It will append this route, as it has been
> >advertised
> > > > with ECMP_NEXT_HOP.
> > >
> > > I think what makes me uncomfortable with this mechanism is implicitly
> > > using the normal NEXT_HOP as a reset mechanism.  Just from a coding
> > > standpoint, I'd rather see either no normal nexthop and a set of
> > > ECMP nexthops which always have an implicit withdrawal behavior
> > > or no ECMP nexthops at all.
> >
> >Could you elaborate on why using the ordinary NEXT_HOP for implicit
> >withdrawls makes you feel uneasy? We think having such a mechanism in 
>place,
> >makes it easier to understand the new capability (everybody is familiar 
>with
> >how implicit withdrawls work) and introduces no additional burden on the
> >implementation. The way it works is that any time you receive an UPDATE
> >message with ECMP_NEXT_HOP, you know that the route needs to be appended 
>and
> >not replaced!
> >
> >Let me explain what i think you are suggesting. Correct me if i am wrong.
> >
> >Lets assume we have two next-hops N1 and N2 for a NLRI. Say after some
> >point, we get another one N3. You suggest that we should now announce
> >ECMP_NEXT_HOP N1, N2 and N3. That way, whenever you receive a new UPDATE,
> >you always treat that as an implicit withdraw, the way BGP works now. Is
> >that it?
> >
> >I would prefer the former approach because there can be cases (L3 VPN 
>NLRIs,
> >etc) where the NLRI may be clubbed with some information (labels, etc) 
>that
> >may make it non unique. In such cases, its much easier to use the 
>mechanism
> >that we have described. This'll become clearer when i explain how ECMP 
>can
> >work with 3107.
> >
> > >
> > > > IMO a PE can do load splitting in whatever manner it wants to. It
> > > doesn't
> > > > need to inform the other PE that there is more than one next-hop
> > > available
> > > > to reach a destination. Basically its something similar to what we 
>have
> > > done
> > > > for EBGP peers.
> > >
> > > Yes, it could do whatever it wanted to.  However, RFC 3107 implicitly
> > > expects that you only get one nexthop.  If you get more than one,
> > > this will potentially affect the behavior.  The change in behavior
> > > should be discussed somewhere - and I think that your draft is 
>probably
> > > the right place to do that.
> > >
> >
> >I may be missing something, but isn't this more of an implementation
> >specific issue?
> >
> >Anyways, there isn't anything in this draft that precludes this.
> >
> >Assume that a PE router has two next-hops to reach some NLRI x.y.z.w. Let 
>L1
> >and L2 be the labels associated with these next-hops. It could send this
> >information the following way
> >
> >WD_NLRI: NULL
> >Path Attributes:
> >   + Origin - IGP
> >   + AS_PATH - 65535
> >   + MP_REACH_NLRI
> >     o AFI - IPv4
> >     o SAFI - VPN
> >     o MP_NEXTHOP - 0::192.168.1.2
> >     o MP_NLRI - L1:RD:x.y.z.w
> >
> >and
> >
> >WD_NLRI: NULL
> >Path Attributes:
> >   + Origin - IGP
> >   + AS_PATH - 65535
> >   + MP_REACH_NLRI
> >     o AFI - IPv4
> >     o SAFI - VPN
> >     o MP_NEXTHOP - 0
> >     o MP_NLRI - L2:RD:x.y.z.w
> >  + ECMP_NEXT_HOP
> >     o AFI - IPv4
> >     o SAFI - VPN
> >     o NUM NEXTHOPs - 1
> >     o LENGTH - 4
> >     o MP_NEXTHOP - 0::192.168.1.3
> >
> > > > ]I'm most concerned about the synthesized AS_PATH.
> > > > ] o In some circumstances, particularly with large AS_SETs, it will 
>not
> > > > ]   be possible to preserve path length.
> > > >
> > > > Could you give me an example to illustrate this?
> > >
> > > 10/8 NH a Path 1 2 [<255 ASes>]
> > > 10/8 NH b Path 3 4 [<255 ASes>]
> >
> >I believe, the above means that each AS_PATH contains 2 ASes in AS_SEQ 
>and
> >one large AS_SET containing 255 ASes against, each path having 257 ASes 
>in
> >AS_SEQ.
> >
> > >
> > > Resulting advertisement:
> > > 10/8 ECMP NH a,b Path [1 3] [2 4] [<first part of first path/second 
>path>]
> > > [<second part of first path/second path>]
> >
> >Refer to Sec. 16.1 on how we construct the synthetic AS Paths in cases 
>where
> >the contributing AS Paths consist of AS_SETs.
> >
> >Resulting advertisement will be:
> >10/8 ECMP NH a,b Path [1 3] [2 4] [<255 ASes from the first path> <255 
>ASes
> >in the second path>]
> >
> >The problem of over flowing that will occur in constructing this 
>extremely
> >large AS_SET is also present in ordinary BGP, and yes, something that we
> >need to work upon!
> >
> > >
> > > Note that this presumes that the set elements in the original
> > > advertisement are disjoint and thus not prone to merging.
> > >
> > > The path is thus lengthened.
> >
> >Yes. If we have more than 255 ASes present in the AS_SET, then we may 
>need
> >to prepend a new segment of type AS_SET, which will increase the path
> >length, as each AS_SET is counted as 1, irrespective of the number of 
>ASes
> >present in the set.
> >
> >However, this can be easily avoided by introducing a new path segment 
>type
> >AS_EXT_SET (value 3) which will have exactly the same semantics as the
> >existing AS_SET, except that it wont be considered when counting the 
>AS_PATH
> >length.
> >
> > >
> > > > ] o Processing ECMP routes into paths of equivalent length with many
> > > > ]   AS_SETs will impact AS_PATH regular expression engines.
> > > > ] o The set merging rules of BGP (9.2.2.2, draft 25) can result
> > > > ]   in the AS_PATH being shortened.
> > > >
> > > > I am sorry, I didn't get this!
> > >
> > > As for the first:
> > >
> > > I get [1 3] [2 4] (rest)
> > >
> > > Previously I would have gotten 1 2 (rest) or 3 4 (rest).
> > >
> > > I can do a regular expression that says "Match 1 2 .*$" and prefer 
>this
> > > path.
> >
> >You really cant run your regular expression here that says "match 1 2 .$"
> >because now your traffic will be split across paths "1 2 (rest)" and "3 4
> >(rest)". Moreover, this seems to be an implementation issue and i am sure
> >vendors can find clever ways to do this.
> >
> > > Per the aggregation rules, one would typically not see sets such as
> > > [1 3] [2 4] in the net.  An implementation would typically create
> > > [1 2 3 4] as part of aggregation.  Generating separate sets is a 
>deviation
> > > from the specification, but not a mandatory one:
> > >
> > >             - for each pair of adjacent tuples in the aggregated
> > >             AS_PATH, if both tuples have the same type, merge them
> > >             together, as long as doing so will not cause a segment 
>with
> > >             length greater than 255 to be generated.
> > >
> > > The multiple set element encoding doesn't break BGP, but it makes a
> > > presumption that really isn't all that clear in -25.
> >
> >I am not sure if we can call this as "deviating" from the base spec.
> >Multiprotocol extensions did something similar for NEXT_HOP attribute.
> >
> > > That presumption
> > > is that an implementation will not take adjacent set elements and
> > > merge them.  Also, it presumes that an implementation wont choose
> > > to clean up sets of the form:
> > >
> > > [1 2] [3 4] [3 4]
> > >
> > > where the original was:
> > > 1 3 3
> > > 2 4 4
> > >
> > > As by the aggregation rules, a given set element should exist within
> > > the AS_PATH only once.
> > >
> > > I suspect it would be ... instructive to find out what various
> >implementations
> > > do with odd AS_PATHs as would be generated by the synthetic AS_PATH.
> >
> >Definitely.
> >
> >Cheers,
> >Manav
> >
> >
> >_______________________________________________
> >Idr mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/idr
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.com/


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA08902 for <[e-mail]>; Thu, 14 Oct 2004 07:51:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI45s-0000qs-B5; Thu, 14 Oct 2004 07:48:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3tp-0006xI-Fj for [e-mail]; Thu, 14 Oct 2004 07:36:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04373 for <[e-mail]>; Thu, 14 Oct 2004 07:36:00 -0400 (EDT)
Received: from [203.199.83.246] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CI44w-0007ux-Ky for [e-mail]; Thu, 14 Oct 2004 07:47:32 -0400
Received: (qmail 896 invoked by uid 510); 14 Oct 2004 11:35:34 -0000
Date: 14 Oct 2004 11:35:34 -0000
Message-ID: <[e-mail]>
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 14 oct 2004 11:35:34 -0000
MIME-Version: 1.0
From: "ephim  era" <[e-mail]>
To: [e-mail]
Subject: Re: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ephim  era <[e-mail]>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0942720967=="
Sender: [e-mail]
Errors-To: [e-mail]

 This is a multipart mime message


--===============0942720967==
Content-type: multipart/alternative;
	boundary="Next_1097753734---0-203.199.83.246-884"

 This is a multipart mime message


--Next_1097753734---0-203.199.83.246-884
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0A&nbsp; Hi All,<BR>=0A&nbsp; &nbsp; &nbsp;  Got a doubt. When OSPF is =
having ECMP routes and we are doing redistibution of OSPF routes to BGP, Sh=
ould BGP get all 3 prefixes with different nexthops ?<BR>=0A<BR>=0AThanks i=
n advance,<BR>=0AEphim<BR>=0A<BR>=0A<BR>=0AOn Thu, 23 Sep 2004 Manav Bhatia=
 wrote :<BR>=0A&gt;Jeff,<BR>=0A&gt;<BR>=0A&gt; &gt; WD_NLRI: NULL<BR>=0A&gt=
; &gt; Path Attributes:<BR>=0A&gt; &gt;&nbsp;  + Origin - IGP<BR>=0A&gt; &g=
t;&nbsp;  + AS_PATH - 65535<BR>=0A&gt; &gt;&nbsp;  + NEXT_HOP - 192.168.1.1=
<BR>=0A&gt; &gt;&nbsp;  + MP_REACH_NLRI<BR>=0A&gt; &gt;&nbsp; &nbsp;  o AFI=
 - 1 (ipv4)<BR>=0A&gt; &gt;&nbsp; &nbsp;  o SAFI - 1 (unicast)<BR>=0A&gt; &=
gt;&nbsp; &nbsp;  o MP_NEXTHOP - 192.168.1.2<BR>=0A&gt; &gt;&nbsp; &nbsp;  =
o MP_NLRI - 10.0.1/24<BR>=0A&gt; &gt; NLRI: 10.0.0/24<BR>=0A&gt; &gt;<BR>=
=0A&gt; &gt; If one wanted to insert an IPv4/Unicast ECMP nexthop set here,=
 which<BR>=0A&gt; &gt; NLRI set would it apply to?<BR>=0A&gt;<BR>=0A&gt;Lik=
e the other path attributes ORIGIN, AS_PATH, etc. ECMP_NEXT_HOP too<BR>=0A&=
gt;applies to all the NLRIs listed in an UPDATE message. If in this case yo=
u<BR>=0A&gt;had an additional next-hop for only 10.0.0/24, you could announ=
ce this<BR>=0A&gt;information in the following two ways.<BR>=0A&gt;<BR>=0A&=
gt;Let the additional NEXT_HOP be 192.168.1.3<BR>=0A&gt;<BR>=0A&gt;(i) In a=
ddition to the above UPDATE message you could announce another one<BR>=0A&g=
t;containing<BR>=0A&gt;<BR>=0A&gt;WD_NLRI: NULL<BR>=0A&gt;Path Attributes:<=
BR>=0A&gt;&nbsp;  + Origin - IGP<BR>=0A&gt;&nbsp;  + AS_PATH - 65535<BR>=0A=
&gt;&nbsp;  + ECMP_NEXT_HOP<BR>=0A&gt;&nbsp; &nbsp;  o AFI - 1 (ipv4)<BR>=
=0A&gt;&nbsp; &nbsp;  o SAFI - 1 (unicast)<BR>=0A&gt;&nbsp; &nbsp;  o NUM N=
EXTHOPs - 1<BR>=0A&gt;&nbsp; &nbsp;  o LENGTH - 4<BR>=0A&gt;&nbsp; &nbsp;  =
o MP_NEXTHOP - 192.168.1.3<BR>=0A&gt;NLRI: 10.0.0/24<BR>=0A&gt;<BR>=0A&gt;T=
he IBGP peer upon receiving this UPDATE message will know that it needs to<=
BR>=0A&gt;append this route rather than replace.<BR>=0A&gt;<BR>=0A&gt;(ii) =
You could announce the following two UPDATE messages.<BR>=0A&gt;<BR>=0A&gt;=
WD_NLRI: NULL<BR>=0A&gt;Path Attributes:<BR>=0A&gt;&nbsp;  + Origin - IGP<B=
R>=0A&gt;&nbsp;  + AS_PATH - 65535<BR>=0A&gt;&nbsp;  + NEXT_HOP - 192.168.1=
.1<BR>=0A&gt;&nbsp;  + ECMP_NEXT_HOP<BR>=0A&gt;&nbsp; &nbsp;  o AFI - 1 (ip=
v4)<BR>=0A&gt;&nbsp; &nbsp;  o SAFI - 1 (unicast)<BR>=0A&gt;&nbsp; &nbsp;  =
o NUM NEXTHOPs - 1<BR>=0A&gt;&nbsp; &nbsp;  o LENGTH - 4<BR>=0A&gt;&nbsp; &=
nbsp;  o MP_NEXTHOP - 192.168.1.3<BR>=0A&gt;NLRI: 10.0.0/24<BR>=0A&gt;<BR>=
=0A&gt;and<BR>=0A&gt;<BR>=0A&gt;WD_NLRI: NULL<BR>=0A&gt;Path Attributes:<BR=
>=0A&gt;&nbsp;  + Origin - IGP<BR>=0A&gt;&nbsp;  + AS_PATH - 65535<BR>=0A&g=
t;&nbsp;  + MP_REACH_NLRI<BR>=0A&gt;&nbsp; &nbsp;  o AFI - 1 (ipv4)<BR>=0A&=
gt;&nbsp; &nbsp;  o SAFI - 1 (unicast)<BR>=0A&gt;&nbsp; &nbsp;  o MP_NEXTHO=
P - 192.168.1.2<BR>=0A&gt;&nbsp; &nbsp;  o MP_NLRI - 10.0.1/24<BR>=0A&gt;<B=
R>=0A&gt;How you advertise the routes depends upon the time (apart from you=
r<BR>=0A&gt;implementation) at which the information about this additional =
NEXT_HOP is<BR>=0A&gt;known to the originating router.<BR>=0A&gt;<BR>=0A&gt=
;[..]<BR>=0A&gt; &gt; &gt; Put the NLRI in MP_REACH_NLRI. Set the length an=
d the address of the MP<BR>=0A&gt; &gt; &gt; nexthop as Zero. Put this MP n=
exthop info in ECMP_NEXT_HOP and advertise<BR>=0A&gt; &gt; &gt; this to you=
r IBGP peer. It will append this route, as it has been<BR>=0A&gt;advertised=
<BR>=0A&gt; &gt; &gt; with ECMP_NEXT_HOP.<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; I=
 think what makes me uncomfortable with this mechanism is implicitly<BR>=0A=
&gt; &gt; using the normal NEXT_HOP as a reset mechanism.&nbsp; Just from a=
 coding<BR>=0A&gt; &gt; standpoint, I'd rather see either no normal nexthop=
 and a set of<BR>=0A&gt; &gt; ECMP nexthops which always have an implicit w=
ithdrawal behavior<BR>=0A&gt; &gt; or no ECMP nexthops at all.<BR>=0A&gt;<B=
R>=0A&gt;Could you elaborate on why using the ordinary NEXT_HOP for implici=
t<BR>=0A&gt;withdrawls makes you feel uneasy? We think having such a mechan=
ism in place,<BR>=0A&gt;makes it easier to understand the new capability (e=
verybody is familiar with<BR>=0A&gt;how implicit withdrawls work) and intro=
duces no additional burden on the<BR>=0A&gt;implementation. The way it work=
s is that any time you receive an UPDATE<BR>=0A&gt;message with ECMP_NEXT_H=
OP, you know that the route needs to be appended and<BR>=0A&gt;not replaced=
!<BR>=0A&gt;<BR>=0A&gt;Let me explain what i think you are suggesting. Corr=
ect me if i am wrong.<BR>=0A&gt;<BR>=0A&gt;Lets assume we have two next-hop=
s N1 and N2 for a NLRI. Say after some<BR>=0A&gt;point, we get another one =
N3. You suggest that we should now announce<BR>=0A&gt;ECMP_NEXT_HOP N1, N2 =
and N3. That way, whenever you receive a new UPDATE,<BR>=0A&gt;you always t=
reat that as an implicit withdraw, the way BGP works now. Is<BR>=0A&gt;that=
 it?<BR>=0A&gt;<BR>=0A&gt;I would prefer the former approach because there =
can be cases (L3 VPN NLRIs,<BR>=0A&gt;etc) where the NLRI may be clubbed wi=
th some information (labels, etc) that<BR>=0A&gt;may make it non unique. In=
 such cases, its much easier to use the mechanism<BR>=0A&gt;that we have de=
scribed. This'll become clearer when i explain how ECMP can<BR>=0A&gt;work =
with 3107.<BR>=0A&gt;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; &gt; IMO a PE can do =
load splitting in whatever manner it wants to. It<BR>=0A&gt; &gt; doesn't<B=
R>=0A&gt; &gt; &gt; need to inform the other PE that there is more than one=
 next-hop<BR>=0A&gt; &gt; available<BR>=0A&gt; &gt; &gt; to reach a destina=
tion. Basically its something similar to what we have<BR>=0A&gt; &gt; done<=
BR>=0A&gt; &gt; &gt; for EBGP peers.<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; Yes, i=
t could do whatever it wanted to.&nbsp; However, RFC 3107 implicitly<BR>=0A=
&gt; &gt; expects that you only get one nexthop.&nbsp; If you get more than=
 one,<BR>=0A&gt; &gt; this will potentially affect the behavior.&nbsp; The =
change in behavior<BR>=0A&gt; &gt; should be discussed somewhere - and I th=
ink that your draft is probably<BR>=0A&gt; &gt; the right place to do that.=
<BR>=0A&gt; &gt;<BR>=0A&gt;<BR>=0A&gt;I may be missing something, but isn't=
 this more of an implementation<BR>=0A&gt;specific issue?<BR>=0A&gt;<BR>=0A=
&gt;Anyways, there isn't anything in this draft that precludes this.<BR>=0A=
&gt;<BR>=0A&gt;Assume that a PE router has two next-hops to reach some NLRI=
 x.y.z.w. Let L1<BR>=0A&gt;and L2 be the labels associated with these next-=
hops. It could send this<BR>=0A&gt;information the following way<BR>=0A&gt;=
<BR>=0A&gt;WD_NLRI: NULL<BR>=0A&gt;Path Attributes:<BR>=0A&gt;&nbsp;  + Ori=
gin - IGP<BR>=0A&gt;&nbsp;  + AS_PATH - 65535<BR>=0A&gt;&nbsp;  + MP_REACH_=
NLRI<BR>=0A&gt;&nbsp; &nbsp;  o AFI - IPv4<BR>=0A&gt;&nbsp; &nbsp;  o SAFI =
- VPN<BR>=0A&gt;&nbsp; &nbsp;  o MP_NEXTHOP - 0::192.168.1.2<BR>=0A&gt;&nbs=
p; &nbsp;  o MP_NLRI - L1:RD:x.y.z.w<BR>=0A&gt;<BR>=0A&gt;and<BR>=0A&gt;<BR=
>=0A&gt;WD_NLRI: NULL<BR>=0A&gt;Path Attributes:<BR>=0A&gt;&nbsp;  + Origin=
 - IGP<BR>=0A&gt;&nbsp;  + AS_PATH - 65535<BR>=0A&gt;&nbsp;  + MP_REACH_NLR=
I<BR>=0A&gt;&nbsp; &nbsp;  o AFI - IPv4<BR>=0A&gt;&nbsp; &nbsp;  o SAFI - V=
PN<BR>=0A&gt;&nbsp; &nbsp;  o MP_NEXTHOP - 0<BR>=0A&gt;&nbsp; &nbsp;  o MP_=
NLRI - L2:RD:x.y.z.w<BR>=0A&gt;&nbsp; + ECMP_NEXT_HOP<BR>=0A&gt;&nbsp; &nbs=
p;  o AFI - IPv4<BR>=0A&gt;&nbsp; &nbsp;  o SAFI - VPN<BR>=0A&gt;&nbsp; &nb=
sp;  o NUM NEXTHOPs - 1<BR>=0A&gt;&nbsp; &nbsp;  o LENGTH - 4<BR>=0A&gt;&nb=
sp; &nbsp;  o MP_NEXTHOP - 0::192.168.1.3<BR>=0A&gt;<BR>=0A&gt; &gt; &gt; ]=
I'm most concerned about the synthesized AS_PATH.<BR>=0A&gt; &gt; &gt; ] o =
In some circumstances, particularly with large AS_SETs, it will not<BR>=0A&=
gt; &gt; &gt; ]&nbsp;  be possible to preserve path length.<BR>=0A&gt; &gt;=
 &gt;<BR>=0A&gt; &gt; &gt; Could you give me an example to illustrate this?=
<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; 10/8 NH a Path 1 2 [&lt;255 ASes&gt;]<BR>=
=0A&gt; &gt; 10/8 NH b Path 3 4 [&lt;255 ASes&gt;]<BR>=0A&gt;<BR>=0A&gt;I b=
elieve, the above means that each AS_PATH contains 2 ASes in AS_SEQ and<BR>=
=0A&gt;one large AS_SET containing 255 ASes against, each path having 257 A=
Ses in<BR>=0A&gt;AS_SEQ.<BR>=0A&gt;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; Resulti=
ng advertisement:<BR>=0A&gt; &gt; 10/8 ECMP NH a,b Path [1 3] [2 4] [&lt;fi=
rst part of first path/second path&gt;]<BR>=0A&gt; &gt; [&lt;second part of=
 first path/second path&gt;]<BR>=0A&gt;<BR>=0A&gt;Refer to Sec. 16.1 on how=
 we construct the synthetic AS Paths in cases where<BR>=0A&gt;the contribut=
ing AS Paths consist of AS_SETs.<BR>=0A&gt;<BR>=0A&gt;Resulting advertiseme=
nt will be:<BR>=0A&gt;10/8 ECMP NH a,b Path [1 3] [2 4] [&lt;255 ASes from =
the first path&gt; &lt;255 ASes<BR>=0A&gt;in the second path&gt;]<BR>=0A&gt=
;<BR>=0A&gt;The problem of over flowing that will occur in constructing thi=
s extremely<BR>=0A&gt;large AS_SET is also present in ordinary BGP, and yes=
, something that we<BR>=0A&gt;need to work upon!<BR>=0A&gt;<BR>=0A&gt; &gt;=
<BR>=0A&gt; &gt; Note that this presumes that the set elements in the origi=
nal<BR>=0A&gt; &gt; advertisement are disjoint and thus not prone to mergin=
g.<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; The path is thus lengthened.<BR>=0A&gt;<=
BR>=0A&gt;Yes. If we have more than 255 ASes present in the AS_SET, then we=
 may need<BR>=0A&gt;to prepend a new segment of type AS_SET, which will inc=
rease the path<BR>=0A&gt;length, as each AS_SET is counted as 1, irrespecti=
ve of the number of ASes<BR>=0A&gt;present in the set.<BR>=0A&gt;<BR>=0A&gt=
;However, this can be easily avoided by introducing a new path segment type=
<BR>=0A&gt;AS_EXT_SET (value 3) which will have exactly the same semantics =
as the<BR>=0A&gt;existing AS_SET, except that it wont be considered when co=
unting the AS_PATH<BR>=0A&gt;length.<BR>=0A&gt;<BR>=0A&gt; &gt;<BR>=0A&gt; =
&gt; &gt; ] o Processing ECMP routes into paths of equivalent length with m=
any<BR>=0A&gt; &gt; &gt; ]&nbsp;  AS_SETs will impact AS_PATH regular expre=
ssion engines.<BR>=0A&gt; &gt; &gt; ] o The set merging rules of BGP (9.2.2=
.2, draft 25) can result<BR>=0A&gt; &gt; &gt; ]&nbsp;  in the AS_PATH being=
 shortened.<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; I am sorry, I didn't =
get this!<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; As for the first:<BR>=0A&gt; &gt;=
<BR>=0A&gt; &gt; I get [1 3] [2 4] (rest)<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; P=
reviously I would have gotten 1 2 (rest) or 3 4 (rest).<BR>=0A&gt; &gt;<BR>=
=0A&gt; &gt; I can do a regular expression that says &quot;Match 1 2 .*$&qu=
ot; and prefer this<BR>=0A&gt; &gt; path.<BR>=0A&gt;<BR>=0A&gt;You really c=
ant run your regular expression here that says &quot;match 1 2 .$&quot;<BR>=
=0A&gt;because now your traffic will be split across paths &quot;1 2 (rest)=
&quot; and &quot;3 4<BR>=0A&gt;(rest)&quot;. Moreover, this seems to be an =
implementation issue and i am sure<BR>=0A&gt;vendors can find clever ways t=
o do this.<BR>=0A&gt;<BR>=0A&gt; &gt; Per the aggregation rules, one would =
typically not see sets such as<BR>=0A&gt; &gt; [1 3] [2 4] in the net.&nbsp=
; An implementation would typically create<BR>=0A&gt; &gt; [1 2 3 4] as par=
t of aggregation.&nbsp; Generating separate sets is a deviation<BR>=0A&gt; =
&gt; from the specification, but not a mandatory one:<BR>=0A&gt; &gt;<BR>=
=0A&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  - for each pair of a=
djacent tuples in the aggregated<BR>=0A&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;  AS_PATH, if both tuples have the same type, merge them<BR>=
=0A&gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  together, as long as=
 doing so will not cause a segment with<BR>=0A&gt; &gt;&nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp;  length greater than 255 to be generated.<BR>=0A&gt; =
&gt;<BR>=0A&gt; &gt; The multiple set element encoding doesn't break BGP, b=
ut it makes a<BR>=0A&gt; &gt; presumption that really isn't all that clear =
in -25.<BR>=0A&gt;<BR>=0A&gt;I am not sure if we can call this as &quot;dev=
iating&quot; from the base spec.<BR>=0A&gt;Multiprotocol extensions did som=
ething similar for NEXT_HOP attribute.<BR>=0A&gt;<BR>=0A&gt; &gt; That pres=
umption<BR>=0A&gt; &gt; is that an implementation will not take adjacent se=
t elements and<BR>=0A&gt; &gt; merge them.&nbsp; Also, it presumes that an =
implementation wont choose<BR>=0A&gt; &gt; to clean up sets of the form:<BR=
>=0A&gt; &gt;<BR>=0A&gt; &gt; [1 2] [3 4] [3 4]<BR>=0A&gt; &gt;<BR>=0A&gt; =
&gt; where the original was:<BR>=0A&gt; &gt; 1 3 3<BR>=0A&gt; &gt; 2 4 4<BR=
>=0A&gt; &gt;<BR>=0A&gt; &gt; As by the aggregation rules, a given set elem=
ent should exist within<BR>=0A&gt; &gt; the AS_PATH only once.<BR>=0A&gt; &=
gt;<BR>=0A&gt; &gt; I suspect it would be ... instructive to find out what =
various<BR>=0A&gt;implementations<BR>=0A&gt; &gt; do with odd AS_PATHs as w=
ould be generated by the synthetic AS_PATH.<BR>=0A&gt;<BR>=0A&gt;Definitely=
.<BR>=0A&gt;<BR>=0A&gt;Cheers,<BR>=0A&gt;Manav<BR>=0A&gt;<BR>=0A&gt;<BR>=0A=
&gt;_______________________________________________<BR>=0A&gt;Idr mailing l=
ist<BR>=0A&gt;[e-mail]<BR>=0A&gt;https://www1.ietf.org/mailman/listinfo=
/idr<BR>=0A=0A</P>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"http://clients=
.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com/Real=
Media/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 V=
SPACE=3D0 HSPACE=3D0></a>=0A
--Next_1097753734---0-203.199.83.246-884
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

 =A0Hi All,=0A       Got a doubt. When OSPF is having ECMP routes and we ar=
e doing redistibution of OSPF routes to BGP, Should BGP get all 3 prefixes =
with different nexthops ?=0A=0AThanks in advance,=0AEphim=0A=0A=0AOn Thu, 2=
3 Sep 2004 Manav Bhatia wrote :=0A>Jeff,=0A>=0A> > WD_NLRI: NULL=0A> > Path=
 Attributes:=0A> >   + Origin - IGP=0A> >   + AS_PATH - 65535=0A> >   + NEX=
T_HOP - 192.168.1.1=0A> >   + MP_REACH_NLRI=0A> >     o AFI - 1 (ipv4)=0A> =
>     o SAFI - 1 (unicast)=0A> >     o MP_NEXTHOP - 192.168.1.2=0A> >     o=
 MP_NLRI - 10.0.1/24=0A> > NLRI: 10.0.0/24=0A> >=0A> > If one wanted to ins=
ert an IPv4/Unicast ECMP nexthop set here, which=0A> > NLRI set would it ap=
ply to?=0A>=0A>Like the other path attributes ORIGIN, AS_PATH, etc. ECMP_NE=
XT_HOP too=0A>applies to all the NLRIs listed in an UPDATE message. If in t=
his case you=0A>had an additional next-hop for only 10.0.0/24, you could an=
nounce this=0A>information in the following two ways.=0A>=0A>Let the additi=
onal NEXT_HOP be 192.168.1.3=0A>=0A>(i) In addition to the above UPDATE mes=
sage you could announce another one=0A>containing=0A>=0A>WD_NLRI: NULL=0A>P=
ath Attributes:=0A>   + Origin - IGP=0A>   + AS_PATH - 65535=0A>   + ECMP_N=
EXT_HOP=0A>     o AFI - 1 (ipv4)=0A>     o SAFI - 1 (unicast)=0A>     o NUM=
 NEXTHOPs - 1=0A>     o LENGTH - 4=0A>     o MP_NEXTHOP - 192.168.1.3=0A>NL=
RI: 10.0.0/24=0A>=0A>The IBGP peer upon receiving this UPDATE message will =
know that it needs to=0A>append this route rather than replace.=0A>=0A>(ii)=
 You could announce the following two UPDATE messages.=0A>=0A>WD_NLRI: NULL=
=0A>Path Attributes:=0A>   + Origin - IGP=0A>   + AS_PATH - 65535=0A>   + N=
EXT_HOP - 192.168.1.1=0A>   + ECMP_NEXT_HOP=0A>     o AFI - 1 (ipv4)=0A>   =
  o SAFI - 1 (unicast)=0A>     o NUM NEXTHOPs - 1=0A>     o LENGTH - 4=0A> =
    o MP_NEXTHOP - 192.168.1.3=0A>NLRI: 10.0.0/24=0A>=0A>and=0A>=0A>WD_NLRI=
: NULL=0A>Path Attributes:=0A>   + Origin - IGP=0A>   + AS_PATH - 65535=0A>=
   + MP_REACH_NLRI=0A>     o AFI - 1 (ipv4)=0A>     o SAFI - 1 (unicast)=0A=
>     o MP_NEXTHOP - 192.168.1.2=0A>     o MP_NLRI - 10.0.1/24=0A>=0A>How y=
ou advertise the routes depends upon the time (apart from your=0A>implement=
ation) at which the information about this additional NEXT_HOP is=0A>known =
to the originating router.=0A>=0A>[..]=0A> > > Put the NLRI in MP_REACH_NLR=
I. Set the length and the address of the MP=0A> > > nexthop as Zero. Put th=
is MP nexthop info in ECMP_NEXT_HOP and advertise=0A> > > this to your IBGP=
 peer. It will append this route, as it has been=0A>advertised=0A> > > with=
 ECMP_NEXT_HOP.=0A> >=0A> > I think what makes me uncomfortable with this m=
echanism is implicitly=0A> > using the normal NEXT_HOP as a reset mechanism=
.  Just from a coding=0A> > standpoint, I'd rather see either no normal nex=
thop and a set of=0A> > ECMP nexthops which always have an implicit withdra=
wal behavior=0A> > or no ECMP nexthops at all.=0A>=0A>Could you elaborate o=
n why using the ordinary NEXT_HOP for implicit=0A>withdrawls makes you feel=
 uneasy? We think having such a mechanism in place,=0A>makes it easier to u=
nderstand the new capability (everybody is familiar with=0A>how implicit wi=
thdrawls work) and introduces no additional burden on the=0A>implementation=
. The way it works is that any time you receive an UPDATE=0A>message with E=
CMP_NEXT_HOP, you know that the route needs to be appended and=0A>not repla=
ced!=0A>=0A>Let me explain what i think you are suggesting. Correct me if i=
 am wrong.=0A>=0A>Lets assume we have two next-hops N1 and N2 for a NLRI. S=
ay after some=0A>point, we get another one N3. You suggest that we should n=
ow announce=0A>ECMP_NEXT_HOP N1, N2 and N3. That way, whenever you receive =
a new UPDATE,=0A>you always treat that as an implicit withdraw, the way BGP=
 works now. Is=0A>that it?=0A>=0A>I would prefer the former approach becaus=
e there can be cases (L3 VPN NLRIs,=0A>etc) where the NLRI may be clubbed w=
ith some information (labels, etc) that=0A>may make it non unique. In such =
cases, its much easier to use the mechanism=0A>that we have described. This=
'll become clearer when i explain how ECMP can=0A>work with 3107.=0A>=0A> >=
=0A> > > IMO a PE can do load splitting in whatever manner it wants to. It=
=0A> > doesn't=0A> > > need to inform the other PE that there is more than =
one next-hop=0A> > available=0A> > > to reach a destination. Basically its =
something similar to what we have=0A> > done=0A> > > for EBGP peers.=0A> >=
=0A> > Yes, it could do whatever it wanted to.  However, RFC 3107 implicitl=
y=0A> > expects that you only get one nexthop.  If you get more than one,=
=0A> > this will potentially affect the behavior.  The change in behavior=
=0A> > should be discussed somewhere - and I think that your draft is proba=
bly=0A> > the right place to do that.=0A> >=0A>=0A>I may be missing somethi=
ng, but isn't this more of an implementation=0A>specific issue?=0A>=0A>Anyw=
ays, there isn't anything in this draft that precludes this.=0A>=0A>Assume =
that a PE router has two next-hops to reach some NLRI x.y.z.w. Let L1=0A>an=
d L2 be the labels associated with these next-hops. It could send this=0A>i=
nformation the following way=0A>=0A>WD_NLRI: NULL=0A>Path Attributes:=0A>  =
 + Origin - IGP=0A>   + AS_PATH - 65535=0A>   + MP_REACH_NLRI=0A>     o AFI=
 - IPv4=0A>     o SAFI - VPN=0A>     o MP_NEXTHOP - 0::192.168.1.2=0A>     =
o MP_NLRI - L1:RD:x.y.z.w=0A>=0A>and=0A>=0A>WD_NLRI: NULL=0A>Path Attribute=
s:=0A>   + Origin - IGP=0A>   + AS_PATH - 65535=0A>   + MP_REACH_NLRI=0A>  =
   o AFI - IPv4=0A>     o SAFI - VPN=0A>     o MP_NEXTHOP - 0=0A>     o MP_=
NLRI - L2:RD:x.y.z.w=0A>  + ECMP_NEXT_HOP=0A>     o AFI - IPv4=0A>     o SA=
FI - VPN=0A>     o NUM NEXTHOPs - 1=0A>     o LENGTH - 4=0A>     o MP_NEXTH=
OP - 0::192.168.1.3=0A>=0A> > > ]I'm most concerned about the synthesized A=
S_PATH.=0A> > > ] o In some circumstances, particularly with large AS_SETs,=
 it will not=0A> > > ]   be possible to preserve path length.=0A> > >=0A> >=
 > Could you give me an example to illustrate this?=0A> >=0A> > 10/8 NH a P=
ath 1 2 [<255 ASes>]=0A> > 10/8 NH b Path 3 4 [<255 ASes>]=0A>=0A>I believe=
, the above means that each AS_PATH contains 2 ASes in AS_SEQ and=0A>one la=
rge AS_SET containing 255 ASes against, each path having 257 ASes in=0A>AS_=
SEQ.=0A>=0A> >=0A> > Resulting advertisement:=0A> > 10/8 ECMP NH a,b Path [=
1 3] [2 4] [<first part of first path/second path>]=0A> > [<second part of =
first path/second path>]=0A>=0A>Refer to Sec. 16.1 on how we construct the =
synthetic AS Paths in cases where=0A>the contributing AS Paths consist of A=
S_SETs.=0A>=0A>Resulting advertisement will be:=0A>10/8 ECMP NH a,b Path [1=
 3] [2 4] [<255 ASes from the first path> <255 ASes=0A>in the second path>]=
=0A>=0A>The problem of over flowing that will occur in constructing this ex=
tremely=0A>large AS_SET is also present in ordinary BGP, and yes, something=
 that we=0A>need to work upon!=0A>=0A> >=0A> > Note that this presumes that=
 the set elements in the original=0A> > advertisement are disjoint and thus=
 not prone to merging.=0A> >=0A> > The path is thus lengthened.=0A>=0A>Yes.=
 If we have more than 255 ASes present in the AS_SET, then we may need=0A>t=
o prepend a new segment of type AS_SET, which will increase the path=0A>len=
gth, as each AS_SET is counted as 1, irrespective of the number of ASes=0A>=
present in the set.=0A>=0A>However, this can be easily avoided by introduci=
ng a new path segment type=0A>AS_EXT_SET (value 3) which will have exactly =
the same semantics as the=0A>existing AS_SET, except that it wont be consid=
ered when counting the AS_PATH=0A>length.=0A>=0A> >=0A> > > ] o Processing =
ECMP routes into paths of equivalent length with many=0A> > > ]   AS_SETs w=
ill impact AS_PATH regular expression engines.=0A> > > ] o The set merging =
rules of BGP (9.2.2.2, draft 25) can result=0A> > > ]   in the AS_PATH bein=
g shortened.=0A> > >=0A> > > I am sorry, I didn't get this!=0A> >=0A> > As =
for the first:=0A> >=0A> > I get [1 3] [2 4] (rest)=0A> >=0A> > Previously =
I would have gotten 1 2 (rest) or 3 4 (rest).=0A> >=0A> > I can do a regula=
r expression that says "Match 1 2 .*$" and prefer this=0A> > path.=0A>=0A>Y=
ou really cant run your regular expression here that says "match 1 2 .$"=0A=
>because now your traffic will be split across paths "1 2 (rest)" and "3 4=
=0A>(rest)". Moreover, this seems to be an implementation issue and i am su=
re=0A>vendors can find clever ways to do this.=0A>=0A> > Per the aggregatio=
n rules, one would typically not see sets such as=0A> > [1 3] [2 4] in the =
net.  An implementation would typically create=0A> > [1 2 3 4] as part of a=
ggregation.  Generating separate sets is a deviation=0A> > from the specifi=
cation, but not a mandatory one:=0A> >=0A> >             - for each pair of=
 adjacent tuples in the aggregated=0A> >             AS_PATH, if both tuple=
s have the same type, merge them=0A> >             together, as long as doi=
ng so will not cause a segment with=0A> >             length greater than 2=
55 to be generated.=0A> >=0A> > The multiple set element encoding doesn't b=
reak BGP, but it makes a=0A> > presumption that really isn't all that clear=
 in -25.=0A>=0A>I am not sure if we can call this as "deviating" from the b=
ase spec.=0A>Multiprotocol extensions did something similar for NEXT_HOP at=
tribute.=0A>=0A> > That presumption=0A> > is that an implementation will no=
t take adjacent set elements and=0A> > merge them.  Also, it presumes that =
an implementation wont choose=0A> > to clean up sets of the form:=0A> >=0A>=
 > [1 2] [3 4] [3 4]=0A> >=0A> > where the original was:=0A> > 1 3 3=0A> > =
2 4 4=0A> >=0A> > As by the aggregation rules, a given set element should e=
xist within=0A> > the AS_PATH only once.=0A> >=0A> > I suspect it would be =
... instructive to find out what various=0A>implementations=0A> > do with o=
dd AS_PATHs as would be generated by the synthetic AS_PATH.=0A>=0A>Definite=
ly.=0A>=0A>Cheers,=0A>Manav=0A>=0A>=0A>____________________________________=
___________=0A>Idr mailing list=0A>[e-mail]=0A>https://www1.ietf.org/ma=
ilman/listinfo/idr=0A
--Next_1097753734---0-203.199.83.246-884--



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

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

--===============0942720967==--




Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01397 for <[e-mail]>; Wed, 13 Oct 2004 12:44:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHm8S-0004L6-5I; Wed, 13 Oct 2004 12:37:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHm4S-0003Qn-DI for [e-mail]; Wed, 13 Oct 2004 12:33:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13841; Wed, 13 Oct 2004 12:33:43 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHmFN-00009V-1W; Wed, 13 Oct 2004 12:45:05 -0400
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9DGXeTV028256;  Wed, 13 Oct 2004 11:33:41 -0500 (CDT)
Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M3HMP7P>; Wed, 13 Oct 2004 12:33:40 -0400
Message-ID: <[e-mail]>
From: "Busschbach, Peter B (Peter)" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Date: Wed, 13 Oct 2004 12:33:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: "'Malis, Andy'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: [Idr] Liaison from the MPLS & Frame Relay Alliance on draft-ck-bgp-atm- nlri-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

This email was sent to the mailing list, but for some reason hasn't come through. This is a re-send

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

This email is being sent on behalf of Rao Cherukuri, [e-mail].

Sue and Yakov,

The MPLS and Frame Relay Alliance (MFA) is working on Implementation
Agreements regarding ATM-MPLS Control Plane Interworking. This work
builds on the ATM encapsulation defined by the PWE3 WG. In the context
of this work, MFA has come to the conclusion that in certain cases it
would be advantageous to use Multi-Protocol BGP to transport ATM
reachability information between independent ATM islands across an MPLS
core network.

Internet-Draft draft-ck-bgp-atm-nlri-00.txt describes the reference
architecture, problem statement and a possible solution. Since this
draft accurately reflects the reference architecture and problem
statement that the MFA is working on, we would appreciate it if the IDR
WG would accept the draft as a Working Group document and would work
with the authors to progress this to an RFC.

Cordially,

Rao Cherukuri
Chairman, MPLS and Frame Relay Alliance Technical Committee




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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19677 for <[e-mail]>; Tue, 12 Oct 2004 13:08:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPum-0007HH-09; Tue, 12 Oct 2004 12:54:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHPqf-0005wj-Q7 for [e-mail]; Tue, 12 Oct 2004 12:50:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08215 for <[e-mail]>; Tue, 12 Oct 2004 12:50:03 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQ1R-0001zv-9m for [e-mail]; Tue, 12 Oct 2004 13:01:14 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i9CGnV976559 for <[e-mail]>; Tue, 12 Oct 2004 09:49:31 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9CGnQe86617 for <[e-mail]>; Tue, 12 Oct 2004 09:49:26 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 12 Oct 2004 09:49:26 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [Idr] changes to the IANA Consideration Section - WG Last Call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

This is to start the IDR WG Last Call on making the following change
to the IANA Consideration Section of the base BGP Spec.

The change is to replace all occurences of the following in the
IANA Consideration section:

   Future assignment are to be made using the Standards Action process
   defined in [RFC2434]. 

with 

   Future assignment are to be made using either the Standards Action process
   defined in [RFC2434], or the Early IANA Allocation process defined
   in [kompella-zinin].

and add the following to the Normative Reference:

  [kompella-zinin] Kompella, K., Zinin, A., "Early IANA Allocation of 
  Standards Track Codepoints", Work in progress


The reason for the change is in [kompella-zinin].

The WG Last Call ends Oct 26.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA16276 for <[e-mail]>; Tue, 12 Oct 2004 05:51:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHJD7-0007St-So; Tue, 12 Oct 2004 05:44:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHJ2c-0005dJ-Ok for [e-mail]; Tue, 12 Oct 2004 05:33:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03264 for <[e-mail]>; Tue, 12 Oct 2004 05:33:56 -0400 (EDT)
Received: from smtp003.mail.ukl.yahoo.com ([217.12.11.34]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHJDJ-0000vk-7k for [e-mail]; Tue, 12 Oct 2004 05:45:02 -0400
Received: from unknown (HELO pfloyd) (jsmith4112003@202.144.106.188 with login) by smtp003.mail.ukl.yahoo.com with SMTP; 12 Oct 2004 09:33:23 -0000
Message-ID: <00bf01c4b03e$aff3fc00$100218ac@pfloyd>
From: "John Smith" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 12 Oct 2004 15:04:32 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Subject: [Idr] Empty AS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Hi,

What action should a BGP speaker take when it recieves an EBGP Update with
an empty AS_PATH segment (similar to the way it recives an UPDATE from an
IBGP peer)? Should it send a NOTIFICATION message back to the sending peer?

Smith


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA05843 for <[e-mail]>; Mon, 11 Oct 2004 08:38:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzKy-0000iZ-Ot; Mon, 11 Oct 2004 08:31:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzH2-000054-Gx for [e-mail]; Mon, 11 Oct 2004 08:27:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00843 for <[e-mail]>; Mon, 11 Oct 2004 08:27:31 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGzRY-0006pR-Jl for [e-mail]; Mon, 11 Oct 2004 08:38:25 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i9BCQw961763;  Mon, 11 Oct 2004 05:26:59 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9BCQre32881; Mon, 11 Oct 2004 05:26:53 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 11 Oct 2004 05:26:53 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Cc: [e-mail]
Subject: [Idr] IDR WG agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

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

Sue & Yakov.


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13293 for <[e-mail]>; Fri, 1 Oct 2004 15:57:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTMi-0007TJ-Bq; Fri, 01 Oct 2004 15:46:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTDC-0007jS-GF for [e-mail]; Fri, 01 Oct 2004 15:37:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10264 for <[e-mail]>; Fri, 1 Oct 2004 15:36:59 -0400 (EDT)
Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDTLf-00016o-I0 for [e-mail]; Fri, 01 Oct 2004 15:45:50 -0400
Received: (qmail 66457 invoked from network); 1 Oct 2004 19:36:57 -0000
Received: from dialup-4.156.48.162.dial1.boston1.level3.net (HELO laptoy770.faster-light.net) (4.156.48.162) by relay.pair.com with SMTP; 1 Oct 2004 19:36:57 -0000
X-pair-Authenticated: 4.156.48.162
Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i91JePIS027629; Fri, 1 Oct 2004 15:40:25 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pekka Savola <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt 
In-reply-to: Your message of "Fri, 01 Oct 2004 21:25:23 +0300." <[e-mail]> 
Date: Fri, 01 Oct 2004 15:40:25 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: [e-mail], Manav Bhatia <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Pekka Savola writes:
>  
> On Thu, 30 Sep 2004, Jan Novak (janovak) wrote:
> > > AS-paths and nexthops, because the nexthops are being used.  I ask
> > > you which spec says there will be multiple BGP next-hops to begin
> > > with.
> > 
> > Nothing to be specified it just happens in the networks ??
>  
> Seems to be working reasonably well in the current usage, though?
>  
> Just make sure the operators know the limits of applicability, i.e., 
> they can shoot themselves in the foot if they aren't careful, and 
> maybe that's enough?
>  
> I'd suspect there are typically alternatives to reaching about the
> same goal, and multiple nexthops is probably one which is most
> lucrative for stub AS's.  But is there particular reason for us to
> fully 'legitimize' that approach beyond its current applicability ?  
> AFAICS, I don't think that's necessary.
>  
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



This does seem to be a solution that doesn't have any real operational
problem to solve.  The cautious approach would be to build an AS-SET
in the AS Path if using a next hop from more than one peer AS.  No new
spec required.

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA12926 for <[e-mail]>; Fri, 1 Oct 2004 15:08:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDSPK-0001R7-9p; Fri, 01 Oct 2004 14:45:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDS6g-0007AQ-UH for [e-mail]; Fri, 01 Oct 2004 14:26:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04321 for <[e-mail]>; Fri, 1 Oct 2004 14:26:11 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDSF8-0006hN-QI for [e-mail]; Fri, 01 Oct 2004 14:35:02 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i91IPOJ17864; Fri, 1 Oct 2004 21:25:24 +0300
Date: Fri, 1 Oct 2004 21:25:23 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: "Jan Novak (janovak)" <[e-mail]>
Subject: RE: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Manav Bhatia <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Thu, 30 Sep 2004, Jan Novak (janovak) wrote:
> > AS-paths and nexthops, because the nexthops are being used.  I ask
> > you which spec says there will be multiple BGP next-hops to begin
> > with.
> 
> Nothing to be specified it just happens in the networks ??

Seems to be working reasonably well in the current usage, though?

Just make sure the operators know the limits of applicability, i.e., 
they can shoot themselves in the foot if they aren't careful, and 
maybe that's enough?

I'd suspect there are typically alternatives to reaching about the
same goal, and multiple nexthops is probably one which is most
lucrative for stub AS's.  But is there particular reason for us to
fully 'legitimize' that approach beyond its current applicability ?  
AFAICS, I don't think that's necessary.

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


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA12862 for <[e-mail]>; Fri, 1 Oct 2004 15:03:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDSHr-0005DZ-JZ; Fri, 01 Oct 2004 14:37:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRum-0000aN-Ao for [e-mail]; Fri, 01 Oct 2004 14:13:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03035 for <[e-mail]>; Fri, 1 Oct 2004 14:13:53 -0400 (EDT)
Received: from smtp204.mail.sc5.yahoo.com ([216.136.130.127]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDS3H-0006Nt-0V for [e-mail]; Fri, 01 Oct 2004 14:22:43 -0400
Received: from unknown (HELO pfloyd) (tulip?rasputin@202.144.106.188 with login) by smtp204.mail.sc5.yahoo.com with SMTP; 1 Oct 2004 18:07:52 -0000
Message-ID: <012001c4a7e1$c83da5a0$100218ac@pfloyd>
From: "Tulip Rasputin" <[e-mail]>
To: "Pekka Savola" <[e-mail]>
References: <[e-mail]>
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt
Date: Fri, 1 Oct 2004 23:39:17 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

----- Original Message ----- 
From: "Pekka Savola" <[e-mail]>
To: "Manav Bhatia" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 27, 2004 4:50 PM
Subject: Re: [Idr] FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-01.txt


> On Thu, 23 Sep 2004, Manav Bhatia wrote:
> > > This seems to change the way BGP works in a relatively fundamental
> > > way, and I don't see sufficient justification for the proposed
> > > changes.
> >
> > Could you elaborate on what you mean by changing the way BGP works in a
> > "relatively fundamental way"?
>
> I said so because BGP builds on the concept of best route and just one
> next-hop, not multiple ones.  Change there would seem to be
> fundamental.

I don't know if you or the other people on this list would admit to this,
but i know for certain a few big ISPs that do split the load across multiple
BGP next-hops. And since there isn't any way to advertise this information
they don't tell anybody of this. I don't say, that this will cause loops or
has caused loops, but improper usage can certainly cause some problems.

Tulip

P.S.
BTW most of the implementations do support the capability to inject multiple
bgp paths in FIB though I don't know what exact criterion they choose to
decide which one to advertise.

>
> > All this draft says is that a router should advertise all its equal cost
BGP
> > routes to its IBGP peers *if* its using them. The reason why its
advertising
> > these routes is because its *using* them itself. YOu dont want routing
and
> > forwarding to go different ways. Then, since you are using multiple
paths,
> > you ought to tell everybody else of this. So, you construct a synthetic
> > as-path and advertise that to your EBGP peers.
>
> You asked me why not adapt BGP to advertise multiple syntentic
> AS-paths and nexthops, because the nexthops are being used.  I ask you
> which spec says there will be multiple BGP next-hops to begin with.
>
> The whole concept of multiple next-hops seems questionable to me.
> For simplicity, BGP should have only one next-hop.  Whatever happens
> below BGP (e.g., whether that next-hop address is anycasted,
> loadbalanced using IGPs, recursively resolved or whatever) should be
> irrelevant to the BGP advertisements themselves.
>
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr


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