Subject: RE: issue 11

From: "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
Date: Fri, 27 Sep 2002 19:50:10 +0530

Hello,

    My understanding is that multiple routes would be installed in Loc-RIB
for doing load-balancing, and so would support forwarding using all of these
next-hops.

    That said, specifying what to advertise to other routers also means we
should specify completely the full behavior of this action.

    Perhaps, we can make the comment a bit stronger by saying:

% The Loc-RIB SHOULD contain only one route per destination.
% An implementation may choose to install multiple routes to
% a destination (for the purposes of load balancing).
% An implementation doing this MUST ensure that it is
% interoperable with versions that do not, and MUST
% ensure that no routing loops or inconsistent routing
% information is propagated as result of this action. The
% handling of such a configuration, however, is outside the
% scope of this RFC.

   It does seem a little too detailed, though!

Sivanand
([email-masked])

> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[email-masked]]
> Sent: Friday, September 27, 2002 7:38 PM
> To: 'Yakov Rekhter'; Jeffrey Haas
> Cc: Sivananda Ramnath - CTD, Chennai.; [email-masked]
> Subject: RE: issue 11 
> 
> 
> My only issue with this is. If we have the multiplicity of 
> several routes
> for the same destination with different next hops in the Loc-RIB, then
> we should state that we must maintain that consistency in 
> each Adj-RIB-out
> that is not policy filtered (DENY) for this destination. 
> Otherwise, we don't
> always advertise to our peers what we really use for forwarding. 
> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]]
> > Sent: Friday, September 27, 2002 9:57 AM
> > To: Jeffrey Haas
> > Cc: Sivananda Ramnath - CTD, Chennai.; [email-masked]
> > Subject: Re: issue 11 
> > 
> > 
> > Jeff,
> > 
> > > On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath 
> > - CTD, Chennai. w
> > rote:
> > > >   There is support in some router vendors to allow more 
> > than one BGP route
> > > > to be installed, for the purpose for load balancing. 
> > Given that this is a
> > > > current practice, and seems to be a useful feature as 
> > well, should we insist
> > > > that only one route be installed in the Loc-RIB ? 
> > > 
> > > When more than one instance is installed in the LocRib, how
> > > many instances are distributed to the Adj-Ribs-Out?  Is it 
> > deterministic?
> > > Does more than one vendor support this mechanism in an 
> interoperable
> > > fashion?
> > 
> > As Sivanand mentioned in his e-mail:
> > 
> >  The handling of such a configuration, however, is outside the
> >  scope of this RFC.
> > 
> > Yakov.
> > 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 27 Sep 2002 10:25:28 -0400

>    It does seem a little too detailed, though!

My concern is not that this is rope to allow operators to hang themselves
with - this is a gatling gun that allows implementers to try to
guess at useful rules and hose the Internet.  BGP, as a protocol,
is already prone to long-lived loops.  Lets not make it easier to
do this in a way thats harder to troubleshoot.

I haven't thought about this in large amounts of detail, but some
quick observations on what could be done to actually implement
this:

o The routes should be equally preferable - i.e. they need to enter
  the tie-breaking process.
o They should have the same AS_PATH
o Perhaps the path attributes should only be allowed to differ on
  NEXT_HOP.

*If* the above are true, then re-announcing any of the routes used
in the load-balancing should work fine as long as the re-announcement
is going to be a first-party nexthop.  If you have a third-party
nexthop, then you might end up with inconsistant forwarding.

I would propose that this might be something worth investing some
time over, but it shouldn't be mentioned in the base spec.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Fri, 27 Sep 2002 13:22:42 -0700

Jeff, et al

 I'm a little lost here. Considering that BGP multipath:

  - is implemented by at least two (major) vendors

  - affects core protocol mechanisms

  - is important enough to be thoroughly described
    to avoid implementation bugs

 why would we not want it in the base spec?
    
-- 
Alex

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 27 Sep 2002 13:34:00 -0700

Alex,

>  why would we not want it in the base spec?

Why not in a separate draft ?

After all, there are quite a few *optional* BGP features that are
implemented by multiple vendors, affect core protocol mechanisms,
and are important enough to be thoroughly described to avoid
implementation bugs, and are not in the base spec, but are in
separate RFCs.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 27 Sep 2002 13:53:38 -0700

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

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 27 Sep 2002 14:52:35 -0700

Alex,

>   bunch of separate docs describing a single protocol. 

Please note that I am not making any assertion on what the default
should be. Neither on whether it should apply to this particular
case. So, let's focus on how we should handle multipath, and have
a separate discussion (if desired) on what the default should be.

>    Multipath is

Time. If we are interested in getting the base spec completed within
the timeframe outlined in the current charter, we can't add
substantial new material to the spec. 

Yakov.

> >> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chenn
ai.
> >  wrote:

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Sep 2002 11:49:17 -0400

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.

  2.  In the decision process, after IGP cost is considered, some
      (most) routers are capable of considering BGP routes of equal
      cost for the purpose of forwarding and capable of putting more
      than one forwarding entry (typically a small integer number of
      entries) in the FIB.  This is entirely a local matter.

  3.  The only external sign that BGP multipath is enabled is that
      packets are forwarded differently, but still loop free.

Therefore this feature in particular does not belong in the base spec
and there is no need to even mention it.

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Mon, 30 Sep 2002 10:43:26 -0700

Curtis,

 I disagree here. In routing, node-local decisions affecting the
 routing and forwarding tables are as important as the algorithms
 describing inter-node routing proto packet exchange. From this
 perspective, multipath definitely belongs in the spec.

Alex

Monday, September 30, 2002, 8:49:17 AM, Curtis Villamizar wrote:
[...]

---

From: Alex Zinin <[email-masked]>
Date: Mon, 30 Sep 2002 11:20:34 -0700

Yakov,

[...]

> substantial new material to the spec. 

I share the concern about time. However, the issues related to best
path calculation, multipath included, seem to me to be quite important
from the perspective of interoperability and description of further
extensions. Maybe if we the chairs could get the right people together
and facilitate the process (ADs would definitely contribute to buying
the libations), such a design team could come up with solid stuff
within a month?

BTW, regarding the part of the spec describing the best path selection
algo, I remember there was a concern that it didn't really describe
what vendors actually did. Is it still the case?

Alex