Subject: Re: Fw: [v6tc] Issue 2: service discovery: automatic or manual?

From: "Miguel Angel Diaz" <[email-masked]>
Date: Tue, 18 Jan 2005 10:14:08 +0100

>> I partially agree with your point. I also support the idea of an anycast address if:
>> 
>> 1) each transition mechanism has its own anycast address
> 
> Why? Just setup a Transition Mechanism Server or whatever, eg a simple
> webserver and a special URL on that box would retrieve the information
> which allows the client utility to figure out what to do or where to get
> the real information. Don't waste resources, there 'might' be enough,
> but then still you don't have to waste it.

Well, I'm thinking of a different approach. If every transition mechanism has its own anycast address to discover a TEP this allows that any application implementing a specific transition mechanism can contact the TEP directly.

If there is only an anycast address for a server then there is a need for handshaking, that is, client has to ask the anycast server "What kind of TEP do you support?" and then once the client has the server reply it will decide if it can use it. This approach requires more standardization for the handshake.

If every transition mechanism has its own anycast address, the client only contact the TEP and all the communications between both hosts belongs to the protocol scope. No more standardization is required. This will allow that different transition mechanism implementation could be directly and easily integrated on the OS.

> 
> Reread what I wrote (and also wrote last year in april): Service Anycast
> Prefix. Which is just so you can reach a box which can tell you 'there
> is the service for you' and from then on you can do anything possible.
> 
>> 2) the anycast address scope is global, I mean, it is applied not only
>> to the ISP domain but the whole Internet.
> 
> Why? If the service prefix is only announced to the local ISP, then only
> those will receive service from that instance. Announce it to the world
> and you give the world service. That is how anycast works, simple and
> easy.
> 
>> even under this assumptions there are several barriers which would
> 
> Which barriers?
> 
>> prevent that the anycast service will work on the whole Internet and
>> for all the transition mechanisms (see
>>
> http://www.consulintel.euro6ix.org/ietf/application_of_anycast_for_tb_implementation_v1_0.pdf). 
> 
> A few comments:
> 
> Defining anycast address as a tunnel endpoint for traditional Tunnel
> Brokers is silly, especially because that is simply a normal, well
> established use of server failover. If you meant to do global anycast
> deployment, please stick to 6to4 as you do not want the hassle of
> managing that. Next to that you might be interrested in an alternative
> approach as presented by XS26 (http://www.xs26.net) who use multiple
> tunnel servers and allow people to use multiple tunnels, thus giving
> them complete failover possibilities.
> 

[...........................................]

> Btw, when was this paper written, because it mentions 'current' a couple
> of times, but there is no publication date in the paper. 

That paper was written two years ago but only for internal proposes, so it is not public nor announced anywhere. I referenced it on the mail only to highlight several documented issues when deploying anycast services (not only from the point of view of TEP deployment):

- packet delivery on more than one anycast host when establishing the communication (TCP SYN/ACK packets)
- packets belonging to a burst being delivered on different anycast hosts
- ISPs filter bgp routes that aren't networks but hosts. This is made to prevent that routing tables become too big.
- ISPs usually filter traffic which the source address doesn't belong to its own address space. This is an issue when the traffic is originated on the anycast node.

There are lots of info about anycast issues:

* Robert Engel, Vinod Perdis, Debanjan Saha. "Using IP anycast for load distribution and server location"  http://www.zurich.ibm.com/~rha/papers/anycast-gi98.pdf
* C. Patridge, T. Mendez, W. Milliken. "Host Anycasting Service". RFC 1546. Noviembre 1993.
* Chris Metz. "IP Anycast: Point to (Any) Point Communications" http://www.cisco.com/public/cons/isp/essentials/ip-anycast-cmetz-03.pdf 
* S. Bhattacharjee, M. Ammar, E. Zegura, V. Shah and Z. Fei. "Application-Layer Anycasting" IEEE Infocom 1997. Kobe Japan.
* D. Dias, W. Kish, R. Muhkerjee, R. Tewari. "A scalable and highly available web server". Proceedings of the IEEE Computer Conference (COMPCON)". Santa Clara. Marzo 1996.

>And please be
> free to translate to spanish on page 9 and I won't fall over the various
> broken sentences (it actually reads like it has been translated by
> babelfish or something similar). I am also quite sure that there is no
> TB around that changes the users forward DNS zone, even though that is
> implied on the first page. Reverse in some cases, but even that is not
> likely.
> 

The paper was translated with M$ translator tools and it isn't as good as I whish. :-(

[..............................................] 

> The rest I only skimmed because I actually got a bit tired of reading
> the broken english and thus having to reread the sentences multiple
> times before they where understandable. If I had any knowledge of
> spanish I would ask for the most likely original spanish version, which
> I guess is much better to read than this version. I did notice a lot of
> loose references to things that totally made no relation at all to the
> subject and a lot of misassumptions. Routing for instance does not
> change every 5 seconds when staying inside the same ISP. You might be
> interested in taking a look at RIS (http://ris.ripe.net) or maybe
> playing around on the real internet with some BGP tools.

The paper was only an starting point which became on the first draft version of the tep-discovery analysis, so it isn't worth to discuss about the scenarios described on the paper.

Regards
Miguel

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

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Jan 2005 12:47:53 +0100

On Tue, 2005-01-18 at 10:14 +0100, Miguel Angel Diaz wrote:
> Well, I'm thinking of a different approach. If every transition mechanism
> has its own anycast address to discover a TEP this allows that any application
> implementing a specific transition mechanism can contact the TEP directly.
> 
> If there is only an anycast address for a server then there is a need for
> handshaking, that is, client has to ask the anycast server
> "What kind of TEP do you support?" and then once the client has the server
> reply it will decide if it can use it. This approach requires more standardization for the handshake.

What is the problem with this? Isn't the IETF about _standardizing_
methods and making them generic so that everybody can enjoy the fun?

As you are mentioning 'no handshaking', you are not going to negotiate
anything at all ?

> If every transition mechanism has its own anycast address, the client only
> contact the TEP and all the communications between both hosts belongs to the
> protocol scope. No more standardization is required. 

What is the reason then for even bothering into making such a mechanism
into a standard if it is not a standardized method of doing it in the
first place? (now that is an ugly sentence, no MS Word translator needed
for that one ;)

> This will allow that
> different transition mechanism implementation could be directly and easily integrated on the OS.

To take your 'home device', you really expect those vendors to
implement, say, 10 methods to be able to get IPv6 in the air?
There is not that much hardware available in those devices. Next to
that, how does the vendor automatically pick the best one? And how can
you be sure that one out of 10 is actually available at all ?

<SNIP>

> That paper was written two years ago but only for internal proposes, so it is not public nor announced anywhere.
> I referenced it on the mail only to highlight several documented issues when deploying anycast services
> (not only from the point of view of TEP deployment):

You referenced it but it doesn't contain anything which is actually
related to the solution you are proposing neither does it contain
anything what you actually value yourself? Why did you then reference
it, let alone write it?

> - packet delivery on more than one anycast host when establishing the communication (TCP SYN/ACK packets)

Which is why most usages of anycast only use UDP, but as have been
proven with the various root and GTLD servers, TCP works quite well too
for eg EDNS.

> - packets belonging to a burst being delivered on different anycast hosts

BGP routing is not that flaky. This might occur when you have two routes
with the same metric, but I am still to see this happening in any case
but loadbalanced servers which can handle these cases anyway.

> - ISPs filter bgp routes that aren't networks but hosts. This is made to prevent that routing tables become too big.

Usually ISP's filter >/24. That is why anycast prefixes are /24 also,
see for instance the 6to4 prefix. This does not get filtered. This is
also the reason why I propose a _single_ service anycast prefix, as that
would avoid the problem that for every single mechanism, as you are
apparently targeting at, there would be the need for a /24, while one
would suffice with ease.

> - ISPs usually filter traffic which the source address doesn't belong to its own address space.

They should *always* be doing this. If they are not doing any source
filtering they should be shot by the anti-DDOS folks on the spot.

>  This is an issue when the traffic is originated on the anycast node.

I hope you are aware that most ISP's are actually capable of configuring
networks correctly.

> * Robert Engel, Vinod Perdis, Debanjan Saha. "Using IP anycast for load distribution and server location"  http://www.zurich.ibm.com/~rha/papers/anycast-gi98.pdf

I know Robert Haas, who also one of the authors, and he does not think
it to be an issue at all, at least the way I am proposing the usage of
an anycast service prefix. The above paper though is targeted at
something completely different than what this WG should be trying to
accomplish. Note also that the above paper is from 1998 and a lot of
experience has been gained in the meanwhile in the field that was
mentioned then, which was then research and now is used by common people
every day, even your dad, even though he does not know it and could not
care less.

Greets,
 Jeroen