Re: draft-dube-route-reflection-harmful-00.txt

Tony Li <tli@juniper.net> Thu, 05 November 1998 21:12 UTC

Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA04949 for <idr-archive@nic.merit.edu>; Thu, 5 Nov 1998 16:12:42 -0500 (EST)
Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA20893 for idr-outgoing; Thu, 5 Nov 1998 16:07:41 -0500 (EST)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA20886 for <idr@merit.edu>; Thu, 5 Nov 1998 16:07:29 -0500 (EST)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id NAA10518; Thu, 5 Nov 1998 13:04:06 -0800 (PST)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id NAA14579; Thu, 5 Nov 1998 13:03:42 -0800 (PST)
Date: Thu, 05 Nov 1998 13:03:42 -0800
Message-Id: <199811052103.NAA14579@chimp.juniper.net>
From: Tony Li <tli@juniper.net>
To: jgs@ieng.com
CC: rohitd@dnrc.bell-labs.com, idr@merit.edu
In-reply-to: <v04102706b267b9b1a263@[207.24.215.42]> (jgs@ieng.com)
Subject: Re: draft-dube-route-reflection-harmful-00.txt
Sender: owner-idr@merit.edu
Precedence: bulk

|  That's a better characterization than ours, thank you.  Our guidelines 
|  (such as they were) were merely meant to indicate one class of 
|  configurations that are safe, we didn't mean to say that we had fully 
|  characterized all safe classes of configuration.  Do you believe that "the 
|  restriction is that clusters need to be concave" does this?


No, it's not sufficient.  It's a stronger characterization, but not a
requirement.  One might note that if all clusters make exactly the same
decision, there is no topology restriction at all.  So there is a spectrum
of answers depending on the particular flexibility that the RRs have in
computing routes.

I hypothesize (but no stronger ;-) that concavity is sufficient for
completely flexible route calculations.  Note that this is interesting
because concavity in practice means that you end up with clusters which map
pretty closely to confederations.


|  >This should certainly be fully documented, if only for truth in
|  >advertising.
|  
|  You mean, emphasized in RFC 1966?  Yup.


Yes, exactly.


|  >I believe that an appropriate way of addressing this comment would be a
|  >update of RFC 1966.
|  
|  What's the next step for doing that?


I believe that the authors should be given first shot at doing this update,
perhaps with a gentle nudge from the WG co-chairs.

Tony