Subject: RE: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna]

From: "Tony Li" <[email-masked]>
Date: Wed, 6 Aug 2003 10:17:06 -0700

Jeff,

That's an excellent point and perhaps the question that should have
been asked instead.  The entire issue was initiated improperly by
assuming the answer.  We still don't know what problem we're trying
to solve.

The problem *I'm* interested in solving is how do we keep the control
plane stable.  Just shifting the work to another protocol does NOTHING
for that.

Tony

|    -----Original Message-----
|    From: Jeffrey Haas [mailto:[email-masked]] 
|    Sent: Wednesday, August 06, 2003 8:05 AM
|    To: Yakov Rekhter
|    Cc: Danny McPherson; [email-masked]
|    Subject: Re: Who speaks for whom [was: Re: Open Routing 
|    Area meeting in Vienna]
|    
|    
|    On Wed, Aug 06, 2003 at 07:00:40AM -0700, Yakov Rekhter wrote:
|    > With this in mind I'd like to hear from the folks who 
|    argue against
|    > adding more stuff in BGP whether they also object against adding
|    > more stuff into ISIS.
|    
|    As I think I've mentioned before, I think we each have reactions
|    much like the DNS folk who continually find stuff being shoved
|    into their working infrastructure.  
|    
|    (not specifically to Yakov)
|    Is there any way we can just frame this conversation as "how do we
|    keep from breaking things when we're working on extended them"?
|    
|    
|    -- 
|    Jeff Haas 
|    NextHop Technologies
|    
|    _______________________________________________
|    routing-discussion mailing list
|    [email-masked]
|    https://www1.ietf.org/mailman/listinfo/routing-discussion
|    

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Aug 2003 13:51:38 -0400

On Wed, Aug 06, 2003 at 10:17:06AM -0700, Tony Li wrote:
> The entire issue was initiated improperly by

I think part of the issue is many of us have a gut feel for the problem,
but nothing specific to point to.  You, as one of our elders in
the protocol biz, of all people show know some of the mistakes that
have been made and how it has impacted things.  Consider this an
exercise in imparting lore of the clued to those with less clue.

> plane stable.  Just shifting the work to another protocol does NOTHING

In general principle, I agree.  However, I'm going to pick on one
specific point as a counter-example.

BGP (yes, you knew this was coming) has a state machine that once
something enters the HOSED stated (which should probably be in the FSM :-)
that it tears down the peering session, no matter what caused it.
Simply separating out transport of the various AFI/SAFI's into
separate BGP sessions is sufficient to keep errors that do not crash
or corrupt an implementation (say, malformed packets) from tearing
down the entire session.

No, this isn't a whole new protocol.  It really does nothing other than
sandbag damage.  If you corrupt internal data structures and those
structures are shared with other AFI/SAFI's (such as your AS Path 
database), then you may corrupt the other sessions.  So, it
doesn't protect against all classes of errors like completely separate
instances of everything, but it protects against some issues.

Operationally, this means some changes to how we establish peering
and handle call collision.  

It also means that I should expect to find Sue at my cubicle with
a large club because it involves changing the FSM.

Anyway, I offer that this particular mechanism allows for some
sandbagging of the potential problem space.  It also makes it easier
for those who want to do actual full-out sandboxing by having out and
out separate processes a bit easier since you don't have to multiplex
your processes across a common transport.

There may be other "solutions", but first we need to agree that it's
a problem.  I think it might be.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Aug 2003 13:51:38 -0400

-- 
Jeff Haas 
NextHop Technologies