headers
Dean Anderson | 1 Oct 2004 01:48

Re: Re: Root Anycast (fwd)

On Thu, 30 Sep 2004, John Brown CT wrote:

> Couple of points here.
> 
> 1. Typical DNS queries are via UDP, not TCP.
>     Thus the noise Dean is making here about things breaking
>     because of TCP issues, is well  noise.

Noise about TCP, yes.

>     Keep in mind that DNS queries are UDP.  The query and the response.
>     so a typical query is 2 packets, the ask and the answer.
>
>     Having DNS be based on TCP would NOT scale very well.  

We know. As you point out, TCP is still used.  

> Think about
>     it.  Before I could even make a query I would have to deal with
>     at least 3 packets for the TCP connection setup.  Then I'd send my
>     query, which would also have an TCP ACK sent as well, oh then there
>     is the answer to the query, with yet another TCP ACK.  So a single
>     DNS query would (at a min) take 7 packets, more likely 8 to 10,
>     thats 400 to 500 percent more traffic than via UDP.

We know. But people still propose things that will take big packets or 
DNSSEC, etc.

>     DNS uses TCP in special cases. Some of them, but not all of them
>     are.  1. Packet size, 2. AXFR, 3. I think TSIG / DNS SeC stuff
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Brown CT | 1 Oct 2004 02:04

Re: Re: Root Anycast (fwd)

>>    Keep in mind that from a packet path forwarding decision process,
>>    these routers are speaking other protocols as well.  There is dynamic
>>    information being shared between these closely coupled routers that
>>    lets them do the right thing.
> 
> 
> Really?  And what protocols are those?

Just thinking aloud here...

BGP
OSPF
HSRP
ISIS
EIGRP
IGRP

just to name some of the various protocols that routers use
to communicate with each other about the paths they know
about.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 1 comment |
headers
Dean Anderson | 1 Oct 2004 02:24

Re: Complaint on personal attack by John Brown


John Brown (a latecoming VOIP "expert" and self-described "radical") 
wrote:
> I realize that many on this list don't reply to the troll food that Dean 
> leaves around, but I felt it important to reply as someone thats NOT in
> any shape fashion or form, ISC or its staff.   I am somone that has done 
> the engineering work to make a different letter work better via Anycast.
> Which letter, well that doesn't matter.

Perhaps this is part of the "troll food" John is talking about:  

[the issue below turned out to be genuine abuse of Dr. Bernstein in
violation of the code of conduct, and indeed in violation of common
decency, but John Brown promoted that abuse as well. The group of
Bernstein abusers then was also associated with ISC and Paul Vixie. This
rather refutes the claim made above by John that he is "NOT in any shape
fashion or form, ISC or its staff"]

---------- Forwarded message ----------
Date: Wed, 27 Nov 2002 17:47:21 -0700
From: John M. Brown <john <at> chagres.net>
To: 'D. J. Bernstein' <djb <at> cr.yp.to>, ietf <at> ietf.org
Cc: iesg <at> ietf.org, namedroppers <at> ops.ietf.org
Subject: RE: namedroppers mismanagement, continued

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Dan, sounds like a plan.  I say all messages from
Bernstein be handled via his option #2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Anderson | 1 Oct 2004 02:07

Complaint on personal attack by John Brown


The following message by John Brown includes an inappropriate personal
attack in violation of the following sections of the ISOC Code of Conduct:  
http://www.isoc.org/members/codeconduct.shtml

7  Only offer or claim to offer opinions or services that lie within the 
   member's actual knowledge or competence.

8  In the case of financial or material conflict between personal and 
   professional interests, or between two professional interests, declare 
   this conflict to all interested parties and if appropriate in public.

9  Respect the generally accepted norms of Internet etiquette for human 
   communications, especially by avoiding communications that are false or 
   are likely to be considered as discourteous, objectionable, malicious, 
   unwanted, or causing unjustified loss of prestige. Avoid fraudulent or 
   deceptive statements. 

11 Treat all users and colleagues fairly and on equal terms.

And the message violates the following sections of the IETF Guidelines for 
Conduct RFC 3184:
http://www.ietf.org/rfc/rfc3184.txt?number=3184

1. IETF participants extend respect and courtesy to their colleagues
      at all times.

      IETF participants come from diverse origins and backgrounds and
      are equipped with multiple capabilities and ideals.  Regardless of
      these individual differences, participants treat their colleagues
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Anderson | 1 Oct 2004 02:31

Re: Re: Root Anycast (fwd)


The following message pretty clearly illustrates the frivolous nature of
John Brown's "dispute", as he is quite well aware that DNSSEC requires TCP
queries of the root servers, and in fact has been //advocating// for it.  
And he is also aware of other upcoming technologies and developments that
will both increase the size of the packets and hence increase the number
of TCP connections made on the root servers.

It is completely frivolous to claim that 'DNS queries are "mostly UDP",
and that we need not worry about TCP queries'.  We already know that at
present and historically that UDP is the common case.  Taking cheap shots
in frivolous disputes is no way to work on problems.

		--Dean

---------- Forwarded message ----------
Date: Mon, 14 Oct 2002 23:57:00 -0600
From: John M. Brown <john <at> chagres.net>
To: 'Masataka Ohta' <mohta <at> necom830.hpcl.titech.ac.jp>,
     "'Loomis, Rip'" <GILBERT.R.LOOMIS <at> saic.com>
Cc: dnsop <at> cafax.se
Subject: RE: Interim signing of the root zone.

anycast root opens the root system up to more capture,
even if its localized capture, its still capture.

Who decides on who can "anycast" the zone and how do
we know its the right zone ?

signing the root, by whatever means is decided upon, helps
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Anderson | 1 Oct 2004 02:56

Re: Re: Root Anycast (fwd)

On Thu, 30 Sep 2004, John Brown CT wrote:

> >>    Keep in mind that from a packet path forwarding decision process,
> >>    these routers are speaking other protocols as well.  There is dynamic
> >>    information being shared between these closely coupled routers that
> >>    lets them do the right thing.
> > 
> > 
> > Really?  And what protocols are those?
> 
> 
> Just thinking aloud here...
> 
> BGP
> OSPF
> HSRP
> ISIS
> EIGRP
> IGRP
> 
> just to name some of the various protocols that routers use
> to communicate with each other about the paths they know
> about.

Yes, but none of these prevent PPLB from sending packets across multiple 
paths. It seems you had best read some manuals or get some experience 
somewhere before you start blathering nonsense about things you apparently 
don't really understand.

		--Dean
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Anderson | 1 Oct 2004 02:48

Re: Re: Root Anycast (fwd)

On Thu, 30 Sep 2004, Iljitsch van Beijnum wrote:

> Note though that it's *very* hard to create a setup where packets are  
> delivered to different multicast instances, as it's hard to imagine how  
> any real-world anycast setup could match the criteria in

Its quite easy for anycast: (real names used, but not real relationships)

                Av8
              /   \
          sprint   att
              \   /
              F-root              

If Av8 turns on PPLB, traffic to F-root will go through both sprint and
att on a per-packet basis. However F-root is really anycasted, so it looks
really like this:

                              Av8

                          /           \
                  sprint                 att
                   |  |                  |  |
              ,----+--+--.            ,--+--+----.
              | router 1 |            | router 2 |  ...
              `--+-------'            `-------+--'
                 |                            |
              ,--+-------.            ,-------+--.
              | switch 1 +------------+ switch 2 |  ...
              `-+------+-'            `-+------+-'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Anderson | 1 Oct 2004 02:59

Re: Re: Root Anycast (fwd)

On Thu, 30 Sep 2004, Jim Reid wrote:

> >>>>> "Iljitsch" == Iljitsch van Beijnum <iljitsch <at> muada.com> writes:
> 
>     Iljitsch> I think the ship has sailed a long time on whether this
>     Iljitsch> was going to happen at all. However, now would be a good
>     Iljitsch> time to start a discussion on how much anycasting is
>     Iljitsch> enough. It would be good to keep a reasonable number of
>     Iljitsch> root servers non-anycasted.
> 
> The usual good sense and wise judgement of the root server operators
> will see that this happens anyway. I doubt if there's any group of
> people who are more sensitive to avoiding single points of failure.

Lack of "Good sense and wise judgement" is one of the principal problems
that got anycast deployed without adequate discussion.  Then we could talk
about incompatible and undiscussed AXFR modifications, childish personal
attacks, etc, etc, etc that also demonstrate bad judgement and bad sense.

		--Dean

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Oct 2004 10:49
Favicon

Re: Re: Root Anycast (fwd)

On 1-okt-04, at 2:48, Dean Anderson wrote:

>> Note though that it's *very* hard to create a setup where packets are
>> delivered to different multicast instances, as it's hard to imagine 
>> how
>> any real-world anycast setup could match the criteria in

> Its quite easy for anycast: (real names used, but not real 
> relationships)

>                 Av8
>               /   \
>           sprint   att
>               \   /
>               F-root

> If Av8 turns on PPLB, traffic to F-root will go through both sprint and
> att on a per-packet basis.

No, that won't happen because in order for BGP to install multiple 
paths in the routing table, the following conditions must be met:

"To be candidates for multipath, paths to the same destination need to 
have the following characteristics equal to the best path's 
characteristics:

[...]

• 	One of the following:
	◦ 	Neighboring AS or sub-AS (before the  eiBGP  Multipath feature was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johan Ihrén | 1 Oct 2004 11:37
Picon
Favicon

Re: Re: Root Anycast (fwd)

Dean,

> The following message pretty clearly illustrates the frivolous nature 
> of
> John Brown's "dispute", as he is quite well aware that DNSSEC requires 
> TCP
> queries of the root servers, and in fact has been //advocating// for 
> it.
> And he is also aware of other upcoming technologies and developments 
> that
> will both increase the size of the packets and hence increase the 
> number
> of TCP connections made on the root servers.

Nothing in the messages quoted below says anything about DNSSEC 
requiring TCP.

Nothing in the protocol specs says anything about DNSSEC requiring TCP.

In fact if you take a look at the actual protocol you'll notice that it 
is not even possible to have DNSSEC information returned unless you 
utilize EDNS(0). With EDNS(0) you'll also get the ability to advertise 
a larger UDP reassembly buffer capability than 512 bytes which more or 
less takes care of your DNSSEC worries.

Can we please stop the DNSSEC red hering now?

Johan

> It is completely frivolous to claim that 'DNS queries are "mostly UDP",
(Continue reading)

Permalink | Reply | 3 comments |

Gmane