Global Vs local node data in www.root-servers.org
Hello everyone! It seems like http://www.root-servers.org/index.html has been updated after quite sometime. Seems like data about local Vs global for many of root servers nodes is incorrect. E.g for Netnod i root all nodes are marked as Global nodes. As far as I understand it means that routes announced by these nodes are announced to transit links as well to make routes visible globally. Likely that is not case here right? Same seems with L root and few others. Do we have webmaster of the project on mailing list? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2
Hi Anurag,
On 16 mrt. 2014, at 10:11, Anurag Bhatia <me@anuragbhatia.com> wrote:
Hello everyone!
It seems like http://www.root-servers.org/index.html has been updated after quite sometime.
The root-servers.org site has indeed been updated recently. We will investigate if the mentioned data errors are related to the change.
Seems like data about local Vs global for many of root servers nodes is incorrect.
Details of all instances, incl. global vs. local information, are provided directly by individual root-server operators. I will ask the responsible people to verify their instances' details, and if necessary correct these, asap. Kind regards, Romeo
E.g for Netnod i root all nodes are marked as Global nodes. As far as I understand it means that routes announced by these nodes are announced to transit links as well to make routes visible globally. Likely that is not case here right?
Same seems with L root and few others. Do we have webmaster of the project on mailing list?
Thanks.
--
Anurag Bhatia anuragbhatia.com
Linkedin | Twitter Skype: anuragbhatia.com
PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2
On 03/16/2014 03:42 AM, Romeo Zwart wrote:
Hi Anurag,
On 16 mrt. 2014, at 10:11, Anurag Bhatia <me@anuragbhatia.com <mailto:me@anuragbhatia.com>> wrote:
Hello everyone!
It seems like http://www.root-servers.org/index.html has been updated after quite sometime.
The root-servers.org <http://root-servers.org> site has indeed been updated recently. We will investigate if the mentioned data errors are related to the change.
Also FYI, a connection to https://www.root-servers.org/ gives an invalid certificate error (*.ripe.net). It would be nice if that site either got its own cert. Doug
On 16/03/2014 18:34, Doug Barton wrote:
Also FYI, a connection to https://www.root-servers.org/ gives an invalid certificate error (*.ripe.net). It would be nice if that site either got its own cert.
Hi Doug, We're aware of it, and already working on it. There should be a matching certificate in place soon. Regards, Anand Buddhdev RIPE NCC
On 03/16/2014 10:48 AM, Anand Buddhdev wrote:
On 16/03/2014 18:34, Doug Barton wrote:
Also FYI, a connection to https://www.root-servers.org/ gives an invalid certificate error (*.ripe.net). It would be nice if that site either got its own cert.
Hi Doug,
We're aware of it, and already working on it. There should be a matching certificate in place soon.
Awesome, thanks! Doug
Hello Anurag, On 16/03/14 10:11, "Anurag Bhatia" <me@anuragbhatia.com> wrote:
Hello everyone!
Same seems with L root and few others. Do we have webmaster of the project on mailing list? L-Root does not make a distinction between local and global. All of our nodes advertise the service supernets *without* the no-export community. We impose no policy on our hosts so they can choose if they want to announce our supernets to there upstreams and if so how. It is our observation that the vast majority if not all of our hosts do announce our supernets to there upstreams.
Global and Local nodes are very loosely defined terms. However general consensus of a local node is one that has a desired routing policy which does not allow the service supernets to propagate globally. As we impose no policy we mark all nodes as global. Thanks John
On 17 Mar 2014, at 7:39, John Bond <john.bond@icann.org> wrote:
Global and Local nodes are very loosely defined terms. However general consensus of a local node is one that has a desired routing policy which does not allow the service supernets to propagate globally. As we impose no policy we mark all nodes as global.
I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt the pertinent text of which is this: Two classes of node are described in this document: Global Nodes advertise their service supernets such that they are propagated globally through the routing system (i.e. they advertise them for transit), and hence potentially provide service for the entire Internet. Local Nodes advertise their service supernets such that the radius of propagation in the routing system is limited, and hence provide service for a contained local catchment area. Global Nodes provide a baseline degree of proximity to the entire Internet. Multiple global nodes are deployed to ensure that the general availability of the service does not rely on the availability or reachability of a single global node. Local Nodes provide contained regions of optimisation. Clients within the catchment area of a local node may have their queries serviced by a Local Node, rather than one of the Global Nodes. The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). We did a slightly better job in RFC 4768 (e.g. "in such a way", "potentially"): Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast Address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast Address. Joe
alas, our service predates Joe’s marvelous text. “B” provides its services locally to its upstream ISPs. We don’t play routing tricks, impose routing policy, or attempt to influence prefix announcement. /bill Neca eos omnes. Deus suos agnoscet. On 17March2014Monday, at 7:17, Joe Abley <jabley@hopcount.ca> wrote:
On 17 Mar 2014, at 7:39, John Bond <john.bond@icann.org> wrote:
Global and Local nodes are very loosely defined terms. However general consensus of a local node is one that has a desired routing policy which does not allow the service supernets to propagate globally. As we impose no policy we mark all nodes as global.
I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote
http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt
the pertinent text of which is this:
Two classes of node are described in this document:
Global Nodes advertise their service supernets such that they are propagated globally through the routing system (i.e. they advertise them for transit), and hence potentially provide service for the entire Internet.
Local Nodes advertise their service supernets such that the radius of propagation in the routing system is limited, and hence provide service for a contained local catchment area.
Global Nodes provide a baseline degree of proximity to the entire Internet. Multiple global nodes are deployed to ensure that the general availability of the service does not rely on the availability or reachability of a single global node.
Local Nodes provide contained regions of optimisation. Clients within the catchment area of a local node may have their queries serviced by a Local Node, rather than one of the Global Nodes.
The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks).
We did a slightly better job in RFC 4768 (e.g. "in such a way", "potentially"):
Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system.
Local Node: an Anycast Node providing service using a Local-Scope Anycast Address.
Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system.
Global Node: an Anycast Node providing service using a Global-Scope Anycast Address.
Joe
On 17 Mar 2014, at 10:27, manning bill <bmanning@isi.edu> wrote:
alas, our service predates Joe’s marvelous text.
“B” provides its services locally to its upstream ISPs. We don’t play routing tricks, impose routing policy, or attempt to influence prefix announcement.
In the taxonomy I just shared, that makes the origin nodes of B all "global nodes". To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. It's specifically the terms "local" and "global" in a DNS anycast context that I was apologising for :-) Joe
On Mon, Mar 17, 2014 at 11:11:40AM -0400, Joe Abley wrote:
On 17 Mar 2014, at 10:27, manning bill <bmanning@isi.edu> wrote:
alas, our service predates Joe’s marvelous text.
“B” provides its services locally to its upstream ISPs. We don’t play routing tricks, impose routing policy, or attempt to influence prefix announcement.
In the taxonomy I just shared, that makes the origin nodes of B all "global nodes".
To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time.
It's specifically the terms "local" and "global" in a DNS anycast context that I was apologising for :-)
Joe
No apology needed. I was clarifying why "B" is listed as a local node. That it doesn't fit you taxonomy is fine - but it does need an explaination. /bill
participants (8)
-
Anand Buddhdev -
Anurag Bhatia -
bmanning＠vacation.karoshi.com -
Doug Barton -
Joe Abley -
John Bond -
manning bill -
Romeo Zwart