Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-unique-origin-as-00

From: Stig Venaas <[email-masked]>
Date: Wed, 27 Apr 2011 21:09:45 -0700

Hi,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review. The purpose 
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-grow-unique-origin-as-00
Reviewer: Stig Venaas
Review Date: April 27, 2011
IETF LC End Date: Unknown
Intended Status: Best Current Practice

Summary:

The document is well written, and I only have two very minor issues.

Minor issues:

1: Regarding traceroute it says:

    enables service-level identification of a given server.  Tools such
    as traceroute are also used to determine which location a given query
    is being routed to, although it may not reveal local-scope anycast
    instances, or if there are multiple servers within a given anycast
    node, which of the servers responded to a given query, in particular
    when multiple servers within an anycast node are connected to a
    single IP router.  When utilizing these service level capabilities,

Why is local-scope emphasized here? I would think that traceroute
always gives you one node. It may be a particular global node, or a
local node, depending on your location. It may not reveal local-scope,
but it may not reveal global-scope either. They key thing is that you
get only one. And you may not know what the scope is either. Am I
missing something, or should the text be changed?

2: Regarding synchronization of instances it says:

    Additionally, while it goes without saying that anycasted services
    should always strive for exact synchronization across all instances
    of an anycasted service address, if local policies or data plane
    response manipulation techniques were to "influence" responses within
    a given region in such a way that those response are no longer
    authentic or that they diverge from what other nodes within an
    anycasted service were providing, then it should be an absolute
    necessity that those modified resources only be utilized by service
    consumers within that region or influencer's jurisdiction.

Isn't this a bit DNS centric? I can think of anycast services where
different nodes intentionally have different content. I'm not sure
if it necessarily is important to restrict it to region or jurisdiction
either. It all depends on the service.

Maybe rephrase this to point out that this may be an important issue,
depending on the service?

Nit:

In the paragraph above I found this line:

    a given region in such a way that those response are no longer
                                            ^^^^^^^^
s/response/responses

That's all I have,

Stig