Subject: RE: Protocol analysis

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Aug 2005 15:41:16 -0600

Adrian:

I'd like to take this discussion up a few levels.  I like Tony Li need
to ask what the value of the protocol analysis serves.  As specified, I
find little value because I don't know the audience, purpose, reviewers
or use of such a document. 

Now my objection comes after having begged for a protocol analysis for
the latest BGP draft. 

Having convinced authors to take up the writing of a protocol analysis
for the latest BGP, they asked a few really good questions I'd like to
pose to the list:

1) Who is the final audience for the protocol analysis draft? 

	a) Is it the IESG?
	b) Is it network operators?  - Enterprise, Carriers, SOHO
	c) Is it the researcher? - At what level?  Casual researcher or 
		detailed research? 

2) What is the purpose of the analysis draft? 

	a) Is it to help the IESG evaluate the work to make sure the
standard 	maintains a certain quality as well as deployment
(implement)

	b) Is it to give notes to the operators about the protocol so
that the
	that the operations people know the ranges of places to deploy
the 	protocol?  

	c) Is it to provide a taxonomy & evaluation against the
topology?

3) Who will review the protocol analysis draft for accuracy & validity? 

4) What is the purpose of updating the protocol analysis for a widely
deployed protocol?  

	BGP is a mature protocol for Inter-Domain.  The deployments are
wide-	spread.  In fact, IMHO the public deployment of BGP is only a
portion 	of the BGP deployments.  Like the tip of an iceberg,
public BGP can be 	reviewed but much remains beneath surface.  

	So obviously the BGP protocol analysis will not change whether
is 	deployed.  Capturing all deployments of BGP may not be possible
within 	a timely fashion.  It will not satisfy a true survey for network
operators or provide the detailed analysis researchers.

I in turned asked my routing AD what the purpose of the protocol
analysis. Discussion ensued.  No firm answers were reached.  And if Alex
and Bill felt they were firm - please just re-iterate reasons here and
call me to task.)

In the end, we just tried to muddle through. Before I aid and abet
another protocol analysis, I want to know how & why I am doing it.  

Sue Hares

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 02 Aug 2005 19:27:50 -0400

In message <[email-masked]>
"Susan Hares" writes:
> to ask what the value of the protocol analysis serves.  As specified,
> I find little value because I don't know the audience, purpose,
> reviewers or use of such a document.
>  
> 	c) Is it the researcher? - At what level?  Casual researcher
> 	   or detailed research? 
>  
> 	   that the that the operations people know the ranges of
> 	   places to deploy the protocol?
>  
> 	BGP is a mature protocol for Inter-Domain.  The deployments
> 	are wide- spread.  In fact, IMHO the public deployment of BGP
> 	is only a portion of the BGP deployments.  Like the tip of an
> 	iceberg, public BGP can be reviewed but much remains beneath
> 	surface.
>  
> 	is deployed.  Capturing all deployments of BGP may not be
> 	possible within a timely fashion.  It will not satisfy a true
> 	survey for network operators or provide the detailed analysis
> 	researchers.
>  
> analysis. Discussion ensued.  No firm answers were reached.  And if
> Alex and Bill felt they were firm - please just re-iterate reasons
> here and call me to task.)
>  

Sue,

The protocol analysis does have potential to be a valuable document.
A lot has been learned about how BGP behaves in the years that it has
been deployed.  Much of it would benefit operators and implementors.
A good example is the work done by Craig Labovitz, Jen Rexford, and
many others.

The purpose of a protocol analysis for a widely deployed and well
studied protocol is to pass on the knowledge gained so that the same
implementation and configuration mistakes are not made over and over
again.

There is a lot that can be added to rfc1774 that is well accepted at
this point.  Paul covered some memory requirements and bandwidth
requirements to get an initial feed but barely touched the issues of
stability and observed advertisement and withdraw rates and their (now
better known) causes.  Wording such as "Current observations in the
NSFNET show ..." and citing operational experience in 1991 but no
recent experience makes rfc1774 a very dated document.

It might be worth putting something in the security section since MD5
vs IPSEC was a big issue and analysis of TCP vulnerability to
disruption of the session was discussed on the IDR list.  We should
also provide a pointer to Sandy's vulnerability analysis RFC.

We've learned a lot since 1995 (I hope).  Now if we can just remember
what it is we learned...  :-)

Curtis