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

["Glen Kent" <glen.kent at gmail.com>]

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

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?

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

The question still stands unanswered.

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

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

> > None of the proposals currently do this which to me is rather blasphemous.
> >
> > Glen
>
> 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

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

_______________________________________________
Idr mailing list
Idr at ietf.org
https://www1.ietf.org/mailman/listinfo/idr