[RRG] Re: Comments on the Design Goals I-D

[Tony Li <tli@cisco.com>]

Hi Sriram,

Thanks very much for your suggestions.

> In Section 3.8:
>
> My suggestion in Section 3.8 is to replace the top two paragraphs  
> with the following four, which are inclusive of the content of  
> original paragraphs:
>
> The routing subsystem is responsible for computing a path from any  
> point on the Internet to any other point in the Internet. The  
> quality of the routes that are computed can be measured by a number  
> of metrics. A comprehensive list of performance matrices and  
> evaluation scenarios is needed and can be perhaps fully addressed  
> in a companion I-D or annex to this document.


Well, I'm not yet convinced that that level of detail is necessary or  
beneficial.  Our goal is to recommend a routing and addressing  
architecture, but selecting specific mechanisms is out of scope.   
Getting to comprehensive, quantitative metrics is going to be very  
hard without dealing in mechanisms and our goals really should be  
focused on architectural issues.


> In Section 3.9:
>
> My suggestion in Section 3.9 is to replace the paragraph there with  
> the following (includes the content of the original paragraph):
>
> Currently, the routing subsystem is secured through a number of  
> protocol specific mechanisms of varying strength and applicability.  
> Any new architecture is required to provide at least the current  
> level of security. Given that working groups such as RPSEC and SIDR  
> have already identified systemic security weaknesses in the current  
> system, the routing security for any proposed new architectures  
> should extend beyond the current level. It should be noted that the  
> current state of the art in routing protocol security would advance  
> by the time of deployment of a new solution for addressing/routing.  
> For example, the security solutions from SIDR WG efforts in the  
> IETF will likely progress to RFCs and could be already in  
> deployment in this time frame.


Having watched those particular WGs, I don't think that we can assume  
that they will advance the state of the art in time.  ;-)

However, I do take your point that if they do so, any new  
architecture should be no worse than where the state of the art is.   
Revised text:

	  Currently, the routing subsystem is secured through a number of
	  protocol specific mechanisms of varying strength and
	  applicability.  Any new architecture is required to provide at
	  least the state of the art level of security.



> In Section 3.5:
>
> Comment: At the end of this section, "without this painful event"  
> sounds subjective.
> To clarify, please replace "end-sites to change providers without  
> this painful event." with either
> (a) "some end-sites should be allowed selectively to change  
> providers without requiring renumbering."
> or,
> (b) "end-sites should be allowed to change providers (with  
> renumbering) but consideration should be
> given to minimizing the disruptive impact of the transition."


Would you settle for:

	It is strongly desired that a new architecture allow
	end-sites to change providers with significantly less disruption.


Tony


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg