Subject: Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

From: "Glen Kent" <[email-masked]>
Date: Fri, 1 Sep 2006 21:51:10 +0530

Curtis,

> > Path 1 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 100 NEXT_HOP 1.1.1.1
> >
> > Path 2 - NLRI 192/8 AS_PATH {10 20} LOCAL_PREF 189 NEXT_HOP 1.1.1.1
>
> If this came from the same router then complain because the sender of
> this is broken.

This is exactly what a receiver will receive if add-paths is
implemented, because you dont differentiate between paths. You blindly
flood all the paths that you receive.

> On the priciple of "being liberal in what you accept" just toss the
> second path.

If the receiver has to ignore all such paths then why is add-paths
sending them in the first place?

> > How does this router determine which route is being used by the
> > upstream? I dont think we should progress any proposal without
> > incorporating ways to indicate which path is being actually used in
> > the forwarding.
>
> If its a multipath it is considering both to be valid.  This may be
> possible at an IX if next-hop-self is not set and there is an odd set
> of routing policies.  btw- no where in BGP does it require that
> routing policies be sane (and they can be seemingly quite wierd).  If
> the AS are 65010, 65020, and 65030, this is perfectly valid in an AS
> confederation setup.  In AS confederations you'd just forward to
> 1.1.1.1 but retain the AS paths for readvertising.

No, you didnt get my question at all. My point is that we need to
explicitly mark the route being used in fwding, as otherwise the peer
receiving multiple paths can never know which path is being used by
the router advertising these routes. You need this information for
obvious reasons. See Jeffs mail for more details.

None of the proposals currently do this which to me is rather blasphemous.

Glen

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

---

From: Enke Chen <[email-masked]>
Date: Fri, 01 Sep 2006 10:41:30 -0700

> None of the proposals currently do this which to me is rather 

The flag was in the earlier versions of the add-path draft, and got 
removed as we could not find a use of it. We will need to look at Jeff's 
example carefully to see if the flag needs to be added back.

-- Enke

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 01 Sep 2006 14:04:43 -0400

> flood all the paths that you receive.

It would not receive this from one router.  That one router would have
to pick the route with the better LOCAL_PREF.  I'm assuming we are not
modifying the way LOCAL_PREF works.

If two routers send this then it is a normal BGP case.  Since
LOCAL_PREF is included this MUST be IBGP.  Pick the higher LOCAL_PREF.
If the one router sending the route with LOCAL_PREF 100 sees the
better advertisement it will generally withdraw its own advertisement.
Neither router would be advertising a multipath if this was two
routers.

> sending them in the first place?

[Oops should have sent "pick the second".  You missed that.]

The receiver has to ignore lower LOCAL_PREF based on section 5.1.5 of
RFC-4271 (BGP).  Are you suggesting we change BGP to ignore
LOCAL_PREF?  I didn't see that in either add-path or multiple-next-hops.

> obvious reasons. See Jeffs mail for more details.

This is a different usage.  I'm assuming that a multipath means ECMP.
You seem to be assuming that all advertisements are being sent
including ones that are not being used and then complaining that there
is no way to determine which one is being used.

> None of the proposals currently do this which to me is rather blasphemous.

Maybe thats because neither of the proposals intend to send paths that
are not being used.  I think that the WG needs to decide whether that
usage is within scope for either of these proposals.  It should be
safe to assume that since it is not mentioned by either one and since
there is no support for it that it is not an intended usage.

Curtis

---

From: "Glen Kent" <[email-masked]>
Date: Sat, 2 Sep 2006 21:05:21 +0530

Curtis,

> modifying the way LOCAL_PREF works.

You probably didnt understand the add-paths proposal otherwise you
wouldnt have said this.

The idea behind add-paths is to flood every BGP advertisment to all
its peers. You dont run your decision process to decide on the routes
that need to be flooded. In this case, the router in question, will
not pick the route with a better LOCAL_PREF; it will blindly flood
both the paths to everyone.

So, contrary to what you said in your earlier mail, a reciever
_cannot_ complain if it receives such advertisements as the sender is
conforming to the add-paths proposal and it definitely aint broken.

Unless of course, if you're suggesting that add-paths proposal is
inherently broken .. ? Was this your intent?

> > sending them in the first place?

The question still stands unanswered.

> is no way to determine which one is being used.

Yes, I am. Please contact me or Jeffrey Hass (or any one of the
co-authors) offline if you have any doubts on this.

> are not being used.  I think that the WG needs to decide whether that

Really? Are you sure of what you're saying? I am marking a copy to
Enke Chen and Joel Halpern who will help you clear this gross
misunderstanding that their drafts are only meant to advertise ECMP
routes.

I find the fact rather disturbing that you have been commenting on
both of these drafts without even understanding what each one proposes
to do.

If the drafts are _only_ meant for ecmp then i see no text that talks
of how these proposals work with non add-paths/multiple_hops capable
peers.

Read ecmp-routes-in-bgp draft if you want to understand my point. The
instant you cross an ECMP domain you have to construct a "synthetic"
(I picked up this term from this draft) aspath that contains all the
AS numbers.

Glen

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 02 Sep 2006 13:09:11 -0400

> inherently broken .. ? Was this your intent?

No where in the add-paths document, at least the -05 version does it
say anything like that.  The only mention of the decision precoes is
in the intro.

   1. Introduction

   The BGP specification [RFC4271] defines an "Update-Send Process" to
   advertise the routes chosen by the Decision Process to other BGP
   speakers.  No provisions are made to allow the advertisement of
   multiple paths for the same address prefix, or Network Layer
   Reachability Information (NLRI).  In fact, a route with the same NLRI
   as a previously advertised route implicitly replaces the previous
   advertisement.

   In this document we propose a BGP extension that allows the
   advertisement of multiple paths for the same address prefix without
   the new paths implicitly replacing any previous ones.  The essence of
   the extension is that each path is identified by a path identifier in
   addition to the address prefix.

This does not advocate eliminating the decision process, only allowing
more than one next-hop.  Common practice with BGP ECMP is to consider
any pair of routes that tie at the IGP comparison step to be equal and
use both for forwarding.  This allows advertising both.  

OTOH more explanation of this brief applicability statement is needed
since here they suggest advertising routes not used.

   7. Applications

   The BGP extension specified in this document can be used by a BGP
   route reflector [RFC2796] or BGP Confederation ASBR [RFC3065] to
   advertise more than just the best path in order to eliminate
   persistent route oscillations [RFC3345], or to help achieve optimal
   routing in a network.

   Other applications are for further study.

RFC3345 may provide a hint in that the route oscillation cases involve
the decision tie break using MED.  It is possible that the authors
expected the reader to be familiar with this references and in this
case recognize that advertising routes where MED break the tie would
be sufficient to stop the oscillation.

If this was the authors intent, which it may or may not be, then it
would be better if they explicitly stated the details of this usage.

Again, add-paths is too terse.  Again, as Jeff pointed out we need to
discuss the problem space first, then look at how solutions fit into
the problem space.

> The question still stands unanswered.

Add-paths is not sending routes blindly as I pointed out above.

> co-authors) offline if you have any doubts on this.

Since this is a discussion of the problem space it can go on list.

> both of these drafts without even understanding what each one proposes

Again, I just read the drafts.  I'm not connected with either set of
authors.  Maybe a discussion of the problem space is needed.  I had
considered the BGP ECMP case.  Apparently the primary focus of
add-path is suppressing RR and confed oscillations.  In private email
Joel pointed out that an RS is a case where a router might want to
send everything without running a decision process at all.

> (I picked up this term from this draft) aspath that contains all the

That draft appears to have expired.  There is nothing with ecmp in the
filename, title, or abstract in the internet-drafts abstracts file
except one by George Swallow about MPLS ECMP.

Curtis

---

From: "Glen Kent" <[email-masked]>
Date: Sat, 2 Sep 2006 22:52:03 +0530

Curtis,

> say anything like that.  The only mention of the decision precoes is

Doesnt say what? That add-paths is used to advertise additional routes
in addition to the best ones?

>   advertise more than just the best path in order to eliminate

"advertise more than just the best path in order to eliminate".

Thus your claim that these proposals only call for advertising the
best routes (ecmp) goes for a toss.

I hope you now appreciate the question that i had earlier asked?

> If this was the authors intent, which it may or may not be, then it

Yes, this was the intent, which i thought was obvious to everyone
involved in this discussion.

Clearly I was mistaken.

> considered the BGP ECMP case.  Apparently the primary focus of

If you had considered the ECMP case, then you couldnt have been any
further from reality. Did it ever cross your mind as to how these
proposals would convey the path information to the non
add-paths/multiple-hop peer?

> send everything without running a decision process at all.

I think Joel's been quite clear on what he means by "everything".

> except one by George Swallow about MPLS ECMP.

I get this from the first google hit. The expired copy can be found at

http://tools.ietf.org/id/draft-bhatia-ecmp-routes-in-bgp-02.txt

The draft is very specific to their multiple-hop solution but the
basic idea is generic and can be extended to any proposal that
advertises ecmp routes.

>From the draft:

3. Requirements for the ECMP algorithm

   (a)  An ECMP capable peer must be able to advertise each individual
        BGP path to other ECMP capable IBGP peers.

   (b)  When advertising routes to non ECMP capable peers it must
        preserve as much of the AS Path structure as possible. This
        includes, the individual AS elements and the path length.

   We in this document propose an algorithm to advertise BGP ECMP
   routes, to both routers capable of ECMP and the ones without, so as
   to honor each of the requirements mentioned above.

Glen.