Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-ix-bgp-route-server-11: (with COMMENT)

[joel jaeggli <[e-mail]>]

On 6/14/16 9:19 PM, Spencer Dawkins at IETF wrote:
> Hi, Nick,
> 
> On Mon, Jun 13, 2016 at 4:35 PM, Nick Hilliard <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     Mirja Kuehlewind (IETF) wrote:
>     > Great! Thanks!
> 
>     this is now changed as follows:
> 
>     >
>     https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508
> 
>     Nick
> 
> 
> I had the same question as Mirja, but balloted No Objection because the
> discussion was already taking place in this thread.
> 
> I've looked at
> https://github.com/fooelisa/draft-jasinska-ix-bgp-route-server/commit/5fd0508,
> but I'm still confused. 
> 
> The document defines a route server as "not a router", because it
> doesn't forward packets - the text is 
> 
> Although a route server uses BGP to exchange reachability information
> with each of its clients, it does not forward traffic itself and is 
> 
>    therefore not a router. 
> 
> If the route server does prepend its own AS number to the AS_PATH, won't
> it then receive packets that it can't forward?

Nah, the AS path only counts for path selection. What matters as far as
forwarding goes is what the nexthop on the route is.

In a normally functioning exchange the routeserver will never set itself
to be the nexthop of a learned so the nexthop route will remain the
originator of the route which is another router on the same (connected)
subnet. Since the router(s) peering with the route-server all have the
subnet/netmask configured on their connected interface, they can resolve
all of the nexthops learned from the routeserver via arp.

> Can you help me understand what I'm missing here?

Probably that does it.


> Thanks!
> 
> Spencer