Subject: Re: RP overloading: main question wrt code impact and resource sharing

From: Jeffrey Haas <[email-masked]>
Date: Sat, 2 Aug 2003 22:33:26 -0400

After playing large amounts of catchup on these threads, this message
provides the best place for me to make the points I'd want to make. :-)

On Thu, Jul 31, 2003 at 05:22:48PM -0700, Alex Zinin wrote:
> What essentially we are talking about is the most comfortable location
> of the demux point among the apps. We have two major scenarios:
> 
> The BGP-based model: in this case, there's a single demux point for
> routing and non-routing apps, and it is at the AFI/SAFI
> parsing/encoding stage. All apps are explicitly exposed to BGP.
> 
> The non-BGP model: in this case, BGP is not exposed to non-routing
> apps and the demux point for them, as well as for BGP as a whole, is
> at the TCP level.

As I posted in the routing direcorate, this is all largely about
two things: Is this appropriate to carry in BGP?  If so, what are
the consequences?

The first question is two-pronged: When we say BGP, do we mean
the protocol or the implementations of that protocol as currently
used in the Internet?  (Note that I realize by saying "the protocol"
we imply the latter by the fact that port 179 is used, etc. etc.  I
am far more concerned with the PDU format and route selection behavior.)

After chatting with some people, none of the drafts that I've looked
at grossly distort transporting information in BGP in such a
way that it it bent completely out of shape.  I think that some
of the things that are being done are unsightly and a better way
should have been created to do it (per-NLRI information binding for
example in MP-BGP extensions), but it is still servicable from an
encoding standpoint.

I hope we can put that issue behind us - I don't think it is what
we are really concerned about.

Our real issues are operational and implementation based ones.
I believe that one of the largest ones has been implied by talking
about protocol-level multiplexing.

In my opinion, we're suffering from an "all eggs in one basket" problem.
We're just arguing about what to do about it, if anything.
(I believe many operators have been yelling "stop adding eggs!" for
some time now.)

One suggested mechanism to help address part of these issues is 
multiple processes/peering sessions.  This addresses one large concern
I have in the single transport session version - which is what we
have now:  A mistake by one hunk of code will take down everything.
It's not robust.

The usual response is "don't make mistakes".  Ahem. :-)

The problem with separating things into multiple processes or peering
sessions is the fact that we will be sharing internal resources.
Common radix tries, AS Path and community databases, RIB code, etc.
To attempt to separate too much of this information into separate
instances (sandboxing) is to remove many of the efficiencies in time
and space we attempt to target when doing our implementations.

I don't think this is realistic in most cases.

Moving things into separate peering sessions also has the benefit that
we don't delay convergence of a given protocol because of queue
ordering issues for that instance.  However as (I think) Curtis noted,
we don't do enough to ensure fair queueing in our current implementations.
Why would this change?

IMO, moving things into separate sessions at least encourages developers
to put more "fairness" into their implementations for each instance.
If everything is in a single session, it is all too easy for a simple
coding mistake in the protocol code to monopolize PDU traffic for just
a single AFI/SAFI, delaying convergence of all the others.  This moves
the problem out of the protocol code for fairness and more into the
process scheduler.

The usual answer to resource monopolization is "don't do that".  Ahem.  :-)

However, there is an inherent issue with moving things to separate
peering sessions: fate sharing.  If your extension relies on information
from the base Internet IPv4 routing table, you want the things to be
in as close synchronization as possible.  This usually means you want
it in the same peering session.

One way or the other, the implementation *MUST* do what it can to
not delay sending its updates too long.  BGP is stateful; if you know
something has changed and you take forever to tell someone about it,
the network as a whole suffers.

......

This all comes down to survivability.  We know we can work around all
of these issues within our current code if the code is carefully
designed, architected to provide the "right" amount of "fairness"
and is robust.

We know from experience that the code is generally evolved rather than
designed after the initial design, generally unfair and not as
robust as we would like.

IMO, the best answer that provides for protocol-level robustness
is multiple peering sessions.  I could even live with these sessions
being layered on SCTP.  We should thus explore the mechanisms by which
we could bind the fate of the things that care about such things.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 2 Aug 2003 22:33:26 -0400

......

-- 
Jeff Haas 
NextHop Technologies