Subject: FW: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-00.txt

From: Manav Bhatia <[email-masked]>
Date: Thu, 15 May 2003 18:38:48 +0530

Hi,
Please look into this new Internet draft which is available from the
on-line Internet-Drafts directories.

I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-00.txt
To: IETF-Announce: ;
Subject: I-D ACTION:draft-bhatia-ecmp-routes-in-bgp-00.txt
From: [email-masked]
Date: Thu, 15 May 2003 07:19:32 -0400
Reply-to: [email-masked]
Sender: [email-masked]

A New Internet-Draft is available

Title  : Advertising Equal Cost Multi-Path (ECMP) routes in BGP
Author(s) : M. Bhatia
Filename : draft-bhatia-ecmp-routes-in-bgp-00.txt
Pages  : 7
Date  : 2003-5-14

This document describes an extensible mechanism that will allow a BGP
[BGP4] speaker to advertise equal cost multi-path (ECMP) routes for a
destination to its peers without changing the semantics of the UPDATE
message.

A new BGP attribute is introduced that will be used to advertise the
multiple next hops for the feasible and the un-feasible ECMP BGP routes to
the remote peers.

The mechanisms described in this document are applicable to all routers,
both those with the ability to inject multiple routing  entries in their
forwarding table and those without (although the latter need not implement
some extensions described in this document).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-00.txt

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

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

---

From: Mireille Shammas <[email-masked]>
Date: Thu, 15 May 2003 10:38:44 -0400

Hi Manav,
In this draft you don't mention anything about ECMP in a BGP/MPLS VPN network
and more precisely ECMP between PE and CE where EBGP is used. Note that IBGP is
used to relay the MPLS label information between PEs. I think this will totally
depend on how you choose the labels on a local PE to advertise to a remote PE
to carry the VPN traffic back to the CE. Sample scenario below:

|      |-------ebgp session--------|
|                                                        |       |
| CE|-------ebgp session--------| PE1| =======IBGP/MPLS===========|PE2| .......

|      |-------ebgp session--------|
|                                                        |       |

 I am mainly interested in what will happen on PE1, and how to balance
VPN/labelled traffic coming from PE1 towards CE .
Thanks
Mireille

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 15 May 2003 12:50:40 -0400

> VPN/labelled traffic coming from PE1 towards CE .

The MPLS LSP ends at PE1.  PE2 doesn't care what happens at the other
end of the LSP.  PE1 is free to do the load split exactly as it does
now without telling PE2 that there are more than one next-hop.

The more interesting (difficult) cases are where PE1 has EBGP peers
that advertise routes with different but equal preference attributes
and it doesn't matter at all whether MPLS is in use.

The really difficult (and common) case is where equal cost routes are
advertised by two border routers into the IBGP mesh and a router
internal to the mesh splits among the two routers.  This router does
not advertise anything to BGP about this route and therefore cannot
advertise it as a multipath.

Curtis

---

From: Mareline Sheldon <[email-masked]>
Date: Sat, 17 May 2003 21:24:24 -0700 (PDT)

Manav,
Can we using this draft advertise two ECMP routes of equal preference but say, with different
AS Paths. As far as i could gather you use one additional attribute to describe equal cost
routes using the same path attributes. This way you can definitely advertise routes with all
the same attributes. But what happens say when one of my path attributes are different. Eg. AS
PATH 112 123 in one attribute and AS PATH 564 232 in the other?

Can this be done here?

Regards,
Mareline S.

>  "get draft-bhatia-ecmp-routes-in-bgp-00.txt".

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

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 19 May 2003 09:29:21 +0530

Mareline,
The design implicitly takes care of the scenario you explain.  Though I
confess that I have not been really clear on this in this version of the
draft.

To advertise two ECMP routes with different attributes we will use two
UPDATEs where each will be sent with a blank ECMP_NEXT_HOP attribute (nos.
of next-hops will be kept as zero). The receiver upon receiving such
UPDATEs will know that since the ECMP_NEXT_HOP attribute is present in the
UPDATE, it needs to be added in addition to what it has already.

I guess the following text needs to be added in the draft.

The receiver SHOULD not remove any previous route and add the route
received with an ECMP_NEXT_HOP attribute rather than replace the previous
routes.

When advertising more than one ECMP hop with identical attributes the
sender SHOULD send a single update with multiple hops listed in the
ECMP_NEXT_HOP attribute.

When advertising more than one ECMP hop which do not have identical
attributes multiple BGP updates MUST be sent with the ECMP_NEXT_HOP
attribute included to suppress route replacement.

But a more important question is that whether we need this kind of
mechanism in BGP or not. We already have multiple drafts proposed which
strive to achieve similar goals using different techniques and mechanisms.
I guess one motivation being, to allow inter-operatibility between
different vendors to allow advertisement of multiple BGP paths of same
preference.

Once we're through with the above discussion, we can sit down and look into
the nitty-gritties of each proposal.

Regards,
Manav