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

[Spencer Dawkins at IETF <[e-mail]>]

Joel,

On Tue, Jun 14, 2016 at 11:29 PM, joel jaeggli <[e-mail]> wrote:

> 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 - it does.

Spencer


> > Thanks!
> >
> > Spencer
>
>
>