ietf
[Top] [All Lists]

RE: A follow up question

2003-04-24 12:59:42
Shannon -jj Behrens wrote:
Please forgive my rough tone (in fact, I have great respect 
for you as an engineer), 

I try to avoid taking any IETF discussions personally, one way or the
other.

but it would be much more 
interesting if you wrote a document that provided solutions 
for all of the problems that people have claimed site-locals 
cause.  

I understand that is what some people want, but I think we need to first
agree on the problems that need solving. We have many opinions on why SL
creates problems, but a blatant lack of recognition of the problems that
need to be solved. 

While I hear you saying that the wg should replace 
all of the features that site-locals provide before removing 
them from the architecture, I challenge you to instead take 
the impetus of fully specifying site-locals.  

I believe the first step to doing that is to agree on the problems that
need solving, then see if there are alternative approaches. 

I do believe, 
based on other comments on the list, that such a challenge 
has existed for five years and has yet to be answered.  
Having fully specified site-locals, I do believe the wg would 
be much more willing to accept them into the architecture.  

I thought we were going there with the scoped arch document, but lacking
agreement on the problems to be solved, it became easier to spread FUD
and give up on addressing the issues than to sit down and work them
through.

Although I clearly am not capable of providing the full list 
of questions that you must answer, perhaps the following 
questions are helpful:

o In light of the fact that not every host has a DNS name, 
how do you propose multi-party P2P applications should do 
referrals? It would be helpful if you established the normal 
mode of operation for such situations.

As I said in the note to JCK, I have been imprecise about 'name' so
whatever the app uses to get a handle from the local stack is what it
needs to pass around. Doing otherwise ignores the reality that the
network does not look the same from all points.


o Should site-locals be put in DNS?  Should multiple views of 
DNS be used?  If 
so, how do you address the apparent apprehension in the DNS 
community toward multiple views (I don't know about this 
first-hand--I've only read about it 
from this list)?  Should zone information be kept in DNS?

Implementation details of a multi-faced DNS are best addressed by those
that already ship them. Any service that provides topology specific
information has to do that with an understanding of the topology being
described by that information. 


o Do you foresee all nodes being multi-site nodes?  

Certainly not all, my light switch should not be in any site except my
house. At the same time I may want it to be in multiple scopes, so I can
get to it and turn on the driveway light from the car as I approach.

If I'm at 
work and wish to 
use both my work network *and* my home network via a VPN 
connection, I expect I would want my laptop to be a 
multi-site node.  If this is the case, do I 
need to use %interface_name at the end of all IP's I give to 
applications I 
use?  How would DNS lookups work on a multi-site node if 
site-locals are stored in DNS?

The name resolver would have to track which interface / site it got
answers from because any limited scope resolution is only applicable in
that interface / site context. 


o If, as you say, we should provide site-locals because, "we 
need to meet the network manager at his comfort zone and 
provide a familiar tool," how do we 
convince the network manager not to use NAT since this is 
also a familiar tool in most people's comfort zone.  I'm not 
willing to argue that site-locals 
necessarily lead to NAT, but many people are, so you should 
probably have some answer. 

Leading people away from something comfortable requires providing
something that meets the same basic need and is easier/cheaper/more
comfortable. Many use NAT because they can't get STABLE addresses
otherwise, and NAT is simply the cost of getting that. Providing STABLE
local use prefixes simultaneously with global prefixes that may change
over time is a cheaper way to meet the need for STABLE addresses. 

* I emphasize STABLE because that is a invariant requirement by many
managers of large networks. 


o Do you envision support for Margaret's idea of multiple 
concentric rings of security (possibly using site-locals)?  
If a node in the outermost ring is not able to talk to a node 
in the innermost ring using a site-local address because of 
filtering, but is permitted to use a global address, how 
shall applications react when the site-local "hint" is 
actually misleading?

Personally I consider those security zones as different sites. This gets
into the poor definition of 'site', but we were intentionally vague
there. There is no difference between an FEC0 or 2001-w/Bellovin-Zill
flag prefix in how one would solve this problem. The fact that SL does
not provide multiple concentric security zones is not a failure of SL,
because that was not a design requirement (again we need to agree on the
problems to be solved). 


Again, I'm sure there are many more such questions, and I 
think it would be 
helpful (and in fact requisite) that you answer such 
questions in an Internet Draft in order to achieve your goal 
of restoring site-locals to the 
architecture.  I thank you for your time and *patience* if 
you have made it all the way through this message.

I agree that we need answers to all these issues, and that was the
intent of the scoped arch doc. Once people realize that they continue to
exist for any local use prefix, we will stop the nonsense about SL is
the evil that causes the problems and get back to developing the needed
documents.

Tony 





<Prev in Thread] Current Thread [Next in Thread>