Re: [dnsop] Re: Root Anycast (fwd)

Paul Vixie <paul@vix.com> Mon, 04 October 2004 17:52 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28282; Mon, 4 Oct 2004 13:52:50 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXAA-0000EH-6p; Mon, 04 Oct 2004 14:02:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEWrT-0002i6-2Z; Mon, 04 Oct 2004 13:42:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDmi7-000192-9U for ietf@megatron.ietf.org; Sat, 02 Oct 2004 12:26:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25325 for <ietf@ietf.org>; Sat, 2 Oct 2004 12:26:12 -0400 (EDT)
Received: from sa.vix.com ([204.152.187.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDmqn-0006H1-A3 for ietf@ietf.org; Sat, 02 Oct 2004 12:35:14 -0400
Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 582AB13E18; Sat, 2 Oct 2004 16:25:36 +0000 (GMT) (envelope-from vixie@sa.vix.com)
From: Paul Vixie <paul@vix.com>
To: ietf@ietf.org, dnsop@lists.uoregon.edu
In-Reply-To: Message from jshen@christmas.9966.org ("Joe Shen") of "Sat, 02 Oct 2004 19:45:45 +0800." <000d01c4a875$5b331190$6f02a8c0@topgun>
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Date: Sat, 02 Oct 2004 16:25:36 +0000
Message-Id: <20041002162536.582AB13E18@sa.vix.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
X-Mailman-Approved-At: Mon, 04 Oct 2004 13:42:51 -0400
Subject: Re: [dnsop] Re: Root Anycast (fwd)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793

> Is there situation that multiple root servers installed behine
> multiple routers within one AS?

yes.  that situation exists inside cogent, with c-root.

> If router-P enables PPLB, would there be some problem with TCP based
> DNS requests?

your diagram didn't make sense to me so i'll answer without reference to
"router-p".  if cogent's backbone engineering staff enabled PPLB on the
wrong set of output interfaces, all kinds of things would break, including
tcp sessions to c-root.  fortunately, their backbone engineers are smart
enough to know how to use (or not use) the tools available to them.

the rootops were pretty careful when we turned on anycast.  presumably
the other anycast services around the net, like woody's and rodney's, were
also deployed very carefully.  careful as in getting multiple experts in
a room to argue out the fine points.  careful as in monitoring the results
and making sure there weren't any unreported (or reported) failures.

anycast has worked very well.  both inter-AS and intra-AS.  the fact that
a not-clueful-enough engineer *could* build a non-working topology using
anycast and PPLB as ingredients, does not mean that anycast or PPLB are
bad.  it means you have to be clueful-enough before you use either tool.
(and remember kids, all power tools can kill.)

one hopes that an actual policy maker would find an actual expert for advice.
such an expert would be expected to have read

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s21/pplb.htm

where it says

      Restrictions

      Out-of-Sequence Packets

      Using per-packet load balancing to share the traffic load across
      available paths to a given destination can cause out-of-sequence
      packets in a particular data flow. This can result in
      unsatisfactory data transmission for video and voice streaming.

and they would know that PPLB is basically a link bundling technology used
when all members of the PPLB group start and end in the same router-pair;
in other words it could mostly turn a pair of OC3c's into an "OC6" but it
would be unsafe in any broader context, even when anycast is not in use.

now, could y'all please stop feeding the trolls?

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf