[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt

Some comments below..

(Btw, as a couple of subjects were left in as 'waiting for more feedback', it would be useful to have some kind of issue tracker or web page, summary in the following drafts, or the like to keep track of comments which have been submitted but haven't been reflected..)

On Sun, 24 Oct 2004, JORDI PALET MARTINEZ wrote: 
Does the solution have to support complete 3rd parties, such as
anycasting 6to4 relays now? (Remember that 6to4 relays are stateless,
while the tunnel servers typically aren't, and this would cause
additional implications on the mechanisms.)


As explained in the Case Studies section, is up to each ISP to decide if
they want to support external users or not.

Certainly, but remember that some of the solutions we're discussing are 'inter-domain', while some others are not (like ISATAP, a possible zero-conf tunneling solution).

These two different kinds of mechanisms do have different kinds of requirements for the discovery process: certainly, something like 6to4 is pretty likely to be completely different than the rest. But we don't need an interdomain solution to 6to4 because we have one already...

Does the solution have to support those customers which momentarily
roam outside of their ISP's access network?  [E.g., as solution based
on DNS records would probably still be at least partially applicable
here]


From the users point of view, yes. Of course, users always need to rely into
available services, but if we don't provide this part of the solution, they
will never have it. Providing it, they might have it (up to the providers,
even if a few that with to provide the service).

But then you assume that the mechanism you're discovering supports this feature, which may not be true ?

My point is, that if the discovery is relatively simple, it could also be implemented (with just a couple of dozen or a hundred lines of code) in the mechanisms themselves, not a generic 'library' or the like.

I'm concerned that because there is significantly smaller amount of
incentive, and more technical challenges, for ISPs to deploy an
inter-domain anycast solution for tunnel servers, so that it would not
be actually usable for discovery.


I don't agree, 6to4 is working, and we are just extending the applicability
of 6to4 to other mechanisms.

You don't have to renumber your network when you happen to switch 6to4 relay providers, either by manually or because the routing changes. That would be inevitable with other kinds of mechanisms. Therefore such an interdomain anycast address would have limited applicability IMHO. (Only even marginally feasible if anycast was used just for discovery, and unicast used for real communication)

and 2)  the draft doesn't sufficiently describe the
mechanism/protocol/implementation requirements, and how those
interoperate with whatever the ISPs would deploy.


I'm not sure what do you mean here, but providing more details about DNS SRV
RR and anycast seems to us out of the scope of this document. There are no
_new_ requirements for the ISP, neither the client, because we are using
existing mechanism (DNS and anycast).


No, I didn't mean that, but rather what mechanisms must be implemented
in the mechanism or the host stack.  I'll try to explain below.


Ok. We can work on that in a new section, with concrete examples for
different mechanisms.


OK.

Maybe I did not write clearly enough, without assumptions.

Whether or not this discovery process is done in the host stack, or
the transition mechanism, is relatively irrelevant.

However, it is VERY MUCH relevant to this draft WHAT must be
implemented in the host stack or the mechanism to make these work.

For example, if the host would just implement DNS lookups and the ISP
just anycast, discovery process should fail.


Understood now. The client must implement the complete picture, but not the
server. I'm about to finish an updated version of the document, and will
make sure this is clear.


Good to make it clear.

FWIW, I personally aren't that fond of the requirement that the protocols/mechanisms would have to implement everything -- because that would add complexity, and might have significant disadvantages (e.g., relating to the latency of the set-up, if you have to try e.g. 3 different methods sequentially).

We are using a single name for each protocol, so whatever is implemented in
the ISP, will work for the client. I think this provides complete
interoperability !


Yes, but you also specify the inter-domain anycast in addition to DNS
lookups using SRV or A records.

Which ones must be supported in the client?  Which ones in the ISP?
There are probably half a dozen non-interoperable combinations here.

Maybe your implicit assumption is that the client supports all of
them: interdomain anycast, DNS with SRV, and DNS with A records, and
maybe even DHCP to the boot -- and tries them in some particular
order, and then it would just depend on what the ISP supports.

I don't have that assumption.  On the contrary, I think there must be
a minimal set of approaches so that 1) very little is required to
implement & deploy, and 2) there are as few interop problems as
possible.


My point of view is that both the ability to resolve SRV/A and anycast are
already available today in all the clients, so making both as part of the
requirement, will not add actually any new requirements.

Having to look up both SRV and A records adds at least (and possibly more) one round-trip. SRV requires the use of non-standard APIs AFAIR (e.g., getrrsetbyname), which may or may not be present.

And then there is inter-domain anycast..

semi-substantial
----------------

 On the other hand, shared anycast is also a very useful approach
 since it can globally identify a specific service (TEP or transition
 mechanism).

==> I think you're assuming that anycast (shared-unicast) would be allocated
an interdomain range, because otherwise it can't be globally identified.
This doesn't need to be the case.


Our intend is to use the same prefix as for 6to4, for all the mechanisms (so
we can allocate for example up to 254 new mechanisms, more than enough).


Uhh, I didn't quite understand: did you mean 192.88.99.2 for X, .3 for
Y, .4 for Z, or "similar prefix as for 6to4", like 192.88.100.0/24 for
X, .101.0/24 for Y, etc.

The former would definitely not work. 

You're right. I was actually thinking in the option that you describe in
first place, but I now realize that precisely because that problem, we use a
prefix for 6to4, instead of just one address. So need to double-check if we
need to move to the 2nd way, or there is an alternative.

A prefix might be possible for some inter-domain services, but for those that aren't, IMHO it should be dropped completely.

And even for inter-domain, I don't think there are any which would need it: Teredo had it before, but it was removed due to review from routing people (because one would need to send packet with the anycast address as the source to pierce the NATs), or just as a discovery method. For something like TSP, this wouldn't make sense because you could end up with different providers, with different prefixes. Again, this would only make marginal sense as 'discovery of the unicast address', not much else.

Hence, I'm not so sure that inter-domain anycast address is really needed now.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings