Subject: RE: issue 11

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 30 Sep 2002 13:06:40 -0400

See below

> -----Original Message-----
> From: Mathew Richardson [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 12:57 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'; Alex Zinin; Yakov Rekhter; [email-masked]
> Subject: Re: issue 11
> 
> 
> > Abarbanel, Benjamin <[email-masked]> [Mon, 
> Sep 30, 2002 at 12:10:25PM -0400]:
> >Curtis:
> >See below
> >
> >Ben
> >
> >> -----Original Message-----
> >> From: Curtis Villamizar [mailto:[email-masked]]
> >> Sent: Monday, September 30, 2002 11:49 AM
> >> To: Alex Zinin
> >> Cc: Yakov Rekhter; [email-masked]
> >> Subject: Re: issue 11 
> >> 
> >> 
> >> 
> >> In message <[email-masked]>, Alex Zinin writes:
> >> > Yakov,
> >> > 
> >> >   If we default to putting things in different drafts, 
> we'll have a
> >> >   bunch of separate docs describing a single protocol. 
> Multipath is
> >> >   something that is normally in the heart of a routing 
> >> protocol. There
> >> >   should be a good reason to want something like this in 
> a separate
> >> >   document. Do we have one in this case?
> >> >   Thanks.
> >> > 
> >> > -- 
> >> > Alex
> >> 
> >> 
> >> Alex,
> >> 
> >> Multipath does not meet the criteria we have previously stated for
> >> adding something bases on the existance of implementations that
> >> support it.  That criteria was that the added feature was nearly
> >> universally implemented and deployed among the major 
> parties and that
> >> implementing it or not affected interoperability.
> >> 
> >>   1.  Regardless of whether a particular router has BGP multipath
> >>       enabled or disabled, its external behaviour from the 
> standpoint
> >>       of BGP protocol interaction is completely indistinguishable.
> >> 
> >    As a peer to a router that has multipath routing 
> enabled, I would like
> >    to know that this route has a twin sister route when 
> making my decision
> >    on whether to pick this route in my decision process. If 
> I did not I
> >    would bet the farm on a inconsistent route (implying the 
> AS-PATH and
> >other
> >    attributes are not always used by this route-prefix. 
> 
> <snip>
> 
> You may wish to know that, but the protocol _as deployed_ provides
> no means for that information to be conveyed.  If you call up your
> peer, and find that they are, indeed, using multipath, then you
> can make the appropriate policy decision; however, such decisions
> can't be made based on information contained within the protocol.
> 

<snip>
OK, yeah, I missed the point if we send the same destination prefix 
for two routes the receiving peer will treat the 2nd route as an update
to the first route and thus never tell that the two routes must be 
present for multi-path. OOPs, we have a hole with multi-path. 
Again we violate BGP rule 1 of "advertise to your peer what you use".

Sounds like we have a serious issue with BGP rule 1 not be honored all the
time by BGP.

> <snip>
> 
> >  If packets from the same source and destination are 
> forwarded differently
> >  via different Next Hops, intermittently, does'nt this 
> opens such problems
> >  as sequence errors and non-deterministics forwarding 
> behaviors. Creating 
> >  more confusion and latency problems at the end points? I 
> realize this is
> >  a forwarding issue, but BGP is creating the issue for forwarding
> >  to solve.
> 
> <snip>
> 
> As currently written, and deployed, the BGP protocol is not 
> creating this
> problem.  Rather, nonstandard extensions to the base spec are 
> (potentially)
> creating this problem.
> 
> >  Because there are potential issues with multipath routing. 
> We either add
> >  a dedicated section for multipath, or leave it out for now 
> as Yakov  
> >  suggested.
> 
> I'm for leaving it out now, and forever.  If we wish to document it,
> it should be in a new draft.
> 

You have my total agreement.

Ben