Subject: Re: [Idr] draft-bhatia-bgp-multiple-next-hops vs draft-walton-bgp-add-paths

From: Paul Jakma <[email-masked]>
Date: Fri, 1 Sep 2006 08:41:32 +0100 (IST)

On Thu, 31 Aug 2006, Curtis Villamizar wrote:

> This is true that the two peers *can* peer with the route server 
> only.  It is common practice that major providers rely on private 
> peerings rather than get their routes for other major providers 
> from a RS.  This is not a hypothetical, it is common practice. 
> You cannot dismiss existing common practice.

That wasn't my intention.

I had meant to make it clear that this is not a subtractive addition 
to BGP. The presence of an RS does not mean these private peerings 
must stop.

The ability to allow eBGP middle-men is /additive/ to any existing 
peering.

> Or distrust of anything that could become a single point of 
> failure. Some providers have more than one router at some major IX 
> and direct peer in pairs with other major providers.

Right.

> The case is where the route is not a direct customer of the 
> provider and is not getting transit to the IX through that provider 
> but is peering with another major provider with agreement to 
> exchange all routes.

That sounds an interesting case. Could you provide a diagramme for 
clarity? Is it:

 	------------- IX fabric
           |   |   |
 	 P1   P2  P3
            \ /
             C

?

> This is solvable if the RS does not accept routes for with the BGP
> identifier does not match the next-hop.

Right.

>> However, if the exit peer wants to peer with the RS, and hence
>> *remove* the need for others to advertise path with it as nexthop,
>> then that is exactly what the RS is there for, that's exactly the
>> problem the IX operators /want/ solved (they don't care about 3-p-n
>> at all).

>> If not, then *neither* add-path nor multiple-hop can help the 
>> peers involved btw..

> add-path does solve this.  The <peering,path-id> must be unique, not
> the next-hop.

The RS is policy-free regardless of which proposal it uses[1].

If the peer is not happy to provide the paths concerned to all 
clients of the RS, but wishes the paths to only be made available to 
a certain subset of peers, add-path/multiple-hop is irrelevant.

It must make other arrangements for those paths by direct peering, 
arranging for others to provide the nexthop, or by setting up an RS 
(add-path or multiple-hop, whose 'member peers' match the desired 
distribution exactly.

The mechanism here in this case makes no difference.

> You've just dismissed a real case above.

Apologies, I hadn't realised the argument was operating under the 
assumption that direct peering would be rendered illegal. ;)

> A minor misconfiguration (not setting next-hop self) could result 
> in routes being ambiguous.

That's ambigious in the same sense as the normal BGP decision process 
is ambigious. However, for an eBGP RS, the normal procedure likely 
would be to refuse non-self advertisements long before that.

> Nice try but you have a clearly flawed argument.

Or I just havn't managed to explain it clearly enough. :)

> You can still compare attributes in the above RS example to reduce 
> the multipath set to a minimal set when readvertising.  You can 
> disambiguate the advertisements with the same next hop from 
> different peers with different AS path such that you know to keep 
> two copies and delete only one of them when one router withdraws 
> the route.

Again, multiple-hop fundamentally does not want to try to 
"disambiguate" paths with same (NLRI,nexthop) - there are the same 
path.

If you *don't* have a way to detect identical paths, and suppress all 
but one when re-flooding, you end-up with high-overhead flooding and 
awful convergence.

Multiple-Hop chooses to use the next-hop as this identifier, as it is 
fundamental to the path being advertised, and will remain so for as 
long as BGP is based on DV.

> You argument that multiple-next-hops is not flawed boils down to 
> arguing that you can never have the same next hop with other 
> attributes differing.

That's not quite the argument. The argument is you must pick one.

> Enke's exmaple is is an EBGP peering example.  Next-hop-self is not 
> required by BGP.

Indeed.

And you're right, eBGP RS using multiple-hop can not replace 
advertisements that rely on 3-p-n being distributed.

But that's not the problem the IXes have, it's not the problem being 
solved.

Add-Path /could/ do it, yes. If the reliance on 3-p-n does not depend 
on application of policy... and see above about flooding 
inefficiency (which the authors may be addressing in an updated 
revision).

<snip confeds - you sent another email on that>

1. Policy-applying eBGP RSes have existed for a long time, but they
    have huge administrative overheads, hence (AFAIK), they have not
    seen any significant deployment.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A beginning is the time for taking the most delicate care that balances are
correct.
 		-- Princess Irulan, "Manual of Maud'Dib"

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 01 Sep 2006 13:44:05 -0400

> That sounds an interesting case. Could you provide a diagramme for 

Here is the example:

                      AS2 -----------------------
                       |                         \
   dest -- AS1 -IBGP- AS1 --| blocked by policy  - RS => others
   ASe                 |                         /
                      AS3 -----------------------

The AS path from AS1 would be AS1 ASe, 2 AS in the path.  AS1 and AS2
direct peer.  AS1 and AS3 direct peer.  The AS path from AS2 and AS3
area AS2 AS1 ASe and AS3 AS1 ASe, both three hops.  The RS would pick
the shortest AS path.  In this case AS1 does not export this route and
so there is a tie between AS2 and AS3 routes.  They both have the same
next-hop.

This is slightly different from Enke's example in that in Enke's
example AS1 advertises directly to RS and AS3 doesn't exist.  The AS
Path lengths would be different in this case and one route would be
(should be) preferred over the other on that basis.

Joel has been arguing that maybe we want to include the path not taken
and mark it as not taken.  Maybe that would make route changes faster
but I think the cost in terms of added state is too great.

> assumption that direct peering would be rendered illegal. ;)

For someone that doesn't understand the examples that we've been
discussing for numerous email messages you sure provide a vigorous
argument.  :-)

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 01 Sep 2006 13:44:05 -0400

Here is the example:

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 01 Sep 2006 13:44:05 -0400

Here is the example:

Curtis

---

From: Paul Jakma <[email-masked]>
Date: Fri, 1 Sep 2006 22:38:42 +0100 (IST)

>                      AS3 -----------------------

Right, we'd covered this example I had thought. But let's cover it 
again.

1. If AS1 does not want this path advertised to the RS (and hence
    all other peers) as a matter of policy, it's not going to want
    others to do so either.

2. Ignoring 1, 'others' who get this route by peering with
    AS2 and AS3 would continue to do so once an RS was introduced..

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
To err is human, to moo bovine.

---

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

>     all other peers) as a matter of policy, it's not going to want

We are talking about something that has occurred in the real world
where a provider sent routes only to its private peerings and they
sent those routes to the RS and the in effect "leaked" that way.

In one case AS1 was AS1239 and AS2 was AS690 and next-hop-self was not
being used.  AS690 had more than one router at all the major IX so
almost this exact case did exist for many months at one time.  This
was the most "publicized" case (AS1239 was rightfully not happy and
let everyone know it) but I'm sure there were others.

>     AS2 and AS3 would continue to do so once an RS was introduced..

First of all you are writing in effect "Ignoring certain things that
occasionally happen in the real world ...".

Also those "other peers" would still be getting third party routes
with the same next-hop.  There is not a full mesh of private peerings
at most IX (if any).  The existence of private peerings is not
necessarily transitive (ie: if A peers with B and B peers with C it
does not mean that A peers with C).

> regards,

Use of next-hop-self is common and almost universal on EBGP peerings
which means that third party next-hop is very rare.  As John Scudder
pointed out we can't just depricate our least favorite BGP feature.
We need to at least acknowledge a limitation such as this.

Of greateer significance is the AS confed and RR issues.

Curtis

---

From: Paul Jakma <[email-masked]>
Date: Sat, 2 Sep 2006 00:36:27 +0100 (IST)

Hi Curtis,

> let everyone know it) but I'm sure there were others.

Sure.

The eBGP RS, with multiple-hop at least, would not be able to 
propogate such leaks, unless the leaker set nexthop to self.

> occasionally happen in the real world ...".

No. I am writing "Ignoring the point made in 1". Apologies.

> does not mean that A peers with C).

Sure.

An IX offering an eBGP RS as a service to members does not impinge on 
the private peering arrangements of members. That's the point I was 
trying to make here - those peerings (and paths exchanged) are not 
invalidated in any way.

Such private peerings would also doubtless continue to be needed 
regardless of the mechanism used, if policy-free.

> Use of next-hop-self is common and almost universal on EBGP 
> peerings which means that third party next-hop is very rare.  As 
> John Scudder pointed out we can't just depricate our least favorite 
> BGP feature. We need to at least acknowledge a limitation such as 
> this.

Right, and we are.

What we're saying is that, for the eBGP RS application, multiple-hop 
'solves' only the needs of the subset of paths where both:

a) the exit-peer is willing to peer with the eBGP RS
b) the exit-peer is willing to advertise the path

It does not solve other cases, where /existing/ direct peerings will 
continue to be used to distribute the paths. If those peerings don't 
exist today, it's not working today either.

I know you and others argue this limitation is unneeded and overly 
restrictive.

However, whichever way you cut it, some "restriction" is needed 
somewhere to avoid the dire scaling of unrestricted flooding. I'll 
try mention this in another reply.

> Of greateer significance is the AS confed and RR issues.

Note that (unlike the eBGP RS / 3rd-party-nexthop objection), the AS 
Confed issue you raised does not restrict multiple-hop speakers from 
advertising the same path as they would today.

I have lost track of the RR issue, could you restate or point me at 
it privately?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Today is the first day of the rest of your life.