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

[JORDI PALET MARTINEZ <jordi.palet@consulintel.es>]

Hi Pekka, all,

Some comments below, in-line.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 27 Oct 2004 10:11:06 +0300 (EEST)
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org
> Asunto: 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).

Well, I should not look into existing solutions if I want to be fair ;-)
This WG probably should have been before the solutions but ...

In my opinion we can have an auto-discovery solution that work with both
inter-domain and intra-domain. Don't see the problem on that.

> 
> 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...

I don't agree. If we provide an intra-domain solution for the 6to4
discovery, combined with the existing inter-domain one, this has a lot of
advantages, in getting 6to4 more useful (lower RTT) if this is available in
the domain where the client is attached. At the same, time we are providing
a unique solution that will work the same not just for 6to4, but also for
the rest of the mechanism.

Obviously, as co-author, I'm very convinced that this is a good solution ;-)

So, I think we really need to have some other opinions from the WG !

> 
>>> 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.

Yes, that will be in an ideal world, to ask all the implementers to include
a few lines of code to support this, but that's not going to happen, I
think, so we propose a solution that not really requires that, because it
can be implemented as a higher layer to the existing code.

> 
>>> 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)

Renumbering is not an issue if you just need "connectivity" and you want to
have it as much automatically as possible.

And I guess this is the most normal case for today roaming users, those that
will be affected by renumbering when traveling.

I prefer making sure to get connectivity than anything else. Because if you
really require the same address all the time, and you don't care about
better performance, then you should use, for example TSP and all the time
the same TB, which is perfectly compatible with the proposed solution.

> 
>>>>> 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).

Not really, because if your ISP is providing the service (ideal world) then
you will try only the 1st option. If not you got for the 2nd, and only look
for the 3rd if your ISP is not providing the service, but then we provide a
last resort option.

As many ISPs provide the service, then more often you will try less options,
which is good as an automatic "phase-out".

> 
>>>> 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..
> 

Anyway, have you really calculated how much time this sequence requires in
the worst case ? I really think this is imperceptible for the user, and good
if it ensures "final working conditions".

I believe that our investigation on SRV revealed that all the OSs that today
support IPv6, already support SRV, so not an issue.

Not sure if we want to put in the text concrete OS names ...

>>>>> 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.

Yes, you're right on this, very good point. For some mechanism that will not
work inter-domain, there is no need for the prefix.

Will fix the text on this in the next version.

> 
> 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.

Well my conclusion then is that may be we need to think twice about
considering anycast for discovering the unicast address, but as I recall
that had the issue of making the implementation more complex, so may have
some trade off.

We will work on that and will come back on this point.

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



**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.