[Gen-art] Gen-ART Telechat Review of draft-templin-aero-10

Pete McCann <mccap@petoni.org> Tue, 24 April 2012 04:42 UTC

Return-Path: <mccap@petoni.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D5D21F84FB for <gen-art@ietfa.amsl.com>; Mon, 23 Apr 2012 21:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnDnYXfbiM4w for <gen-art@ietfa.amsl.com>; Mon, 23 Apr 2012 21:42:50 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D25A221F850C for <gen-art@ietf.org>; Mon, 23 Apr 2012 21:42:45 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1958534qae.10 for <gen-art@ietf.org>; Mon, 23 Apr 2012 21:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=PpVH7pxe7vAljcl2mTwERqWy0Tu75r7crV4OuQhyW3c=; b=Pzhp9JpWysT5248pYrtjDFK8KGFv4anrSCGTIohVJTpwAX+6mKhlnR9Q6DN6CN3Q8Q LX1gVplJ5zF4rT7G76mSXH41WUk/7iLXokF+J7K+chcmnPT+rdM5ds+sraHZH1QB8GQv +eVAJ3cfywgWNGZhsdoqybVa7twiI9/TF30Tw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=PpVH7pxe7vAljcl2mTwERqWy0Tu75r7crV4OuQhyW3c=; b=X8ecrU2vXDWdA0I+YJrseIq8s8y/ldnqW6QI3Sz5t8LPFMeAa/ICEVlA3HC4gxIlwd KCfWiUaEjIpgEO3F/BuCQLimJ7h+GviI7gZUmcePiJbafxw7j87geu5ufSiDzFsWOEQI TN5Y9Larpda6sHYIU93VI8NZdoEmA3V4S41qytxl6X0+qHgmp29VYeFT8glD3tPDFjot PDrlmPScNaFYKi55w7yUvM8I+gKWqNidFWQ8FhFO3DbFR+k9d1eHq8oqK98DAzAaKNau k3VEFVIMLRPv7W48GRdb3n0ocwtGQTJdf4Z+ur23kWeTI3xN2ap69zmetvyEw1XtoJHz DWSw==
MIME-Version: 1.0
Received: by 10.229.106.34 with SMTP id v34mr4660230qco.57.1335242565322; Mon, 23 Apr 2012 21:42:45 -0700 (PDT)
Received: by 10.229.219.135 with HTTP; Mon, 23 Apr 2012 21:42:45 -0700 (PDT)
X-Originating-IP: [173.101.177.161]
Date: Tue, 24 Apr 2012 00:42:45 -0400
Message-ID: <CACvMsLG0C=yYYmWP4Y29fOxdkkJaTqGz7A1aXdrwOEYtHWQpzw@mail.gmail.com>
From: Pete McCann <mccap@petoni.org>
To: gen-art@ietf.org, draft-templin-aero.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkeu+0ERxUjNX38rEW0zgGkAtxrjt0b9f+VpvBroHWFQ/nQ0mpMnWCqmfVeY7/75nji7Uur
Subject: [Gen-art] Gen-ART Telechat Review of draft-templin-aero-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Apr 2012 04:42:52 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>gt;.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-templin-aero-10
Reviewer: Peter McCann
Review Date: 2012-04-23
IETF LC End Date:
IESG Telechat date: 2012-04-26

Summary: Discuss

Major issues:

Section 4.1 attempts to provide some motivation for this draft:
   In many AERO link use case scenarios (e.g., small enterprise
   networks, small and stable MANETs, etc.), routers can engage in a
   classical dynamic routing protocol (e.g., OSPF, RIP, IS-IS, etc.) so
   that routing/forwarding tables can be populated and standard
   forwarding between routers can be used.  In other scenarios (e.g.,
   large enterprise/ISP networks, cellular service provider networks,
   dynamic MANETs, etc.), this might be impractical due to routing
   protocol control message scaling issues.
However, it isn't clear to me that the mechanisms proposed in this draft
would be any more scalable than existing dynamic routing protocols.

In general, the draft appears to be mixing the concepts of service provider
and end-user networks in strange ways.  The AERO link uses host-based
mechanisms for prefix delegation, but it is intended to be a backbone of
a service provider network.  There seem to be some trust assumptions
borrowed from access links (such as the need for ingress filtering), yet
the routers on the AERO link are expected to work together in a peer-to-
peer fashion to compute direct routes to each other.  I do not feel that the
draft has adequately motivated this somewhat quirky set of assumptions.
Perhaps a deployment example that motivates why the different edge
routers cannot trust each other is in order.


Minor issues:

Section 4.4.5:
The text says to use experimental type code "100" but the ASCII art
still says "137."  Does the figure need to be changed?

Section 4.4.12:
   Eventually, any such correspondent AERO nodes will receive a NULL
   AERO Redirect message and will cease to use the egress node ('D') as
   a next hop.  They will then revert to sending packets destined to the
   EUN node ('E') via a trusted intermediate router and may subsequently
   receive new AERO Redirect messages to discover that the EUN node ('E'
   ) is now associated with a new AERO edge router.
Seems like this scenario requires that *part* of a prefix that was delegated
to D is now re-routed by the intermediate router A to a different destination.
Is that correct?  You are proposing to punch a hole in the original allocation,
and put in a more-specific (perhaps host-specific) route to E through a new
path?  What kind of protocols would be used to establish this new forwarding
state?

Nits/editorial comments:

Section 4.4.4:
   Note that on links in which link-layer address spoofing is possible,
   AERO nodes may be obliged to require the use of digital signatures.
   In that case, only the third of the above conditions can be accepted
   in order to ensure adequate data origin authentication.
Did you mean to say "only the fourth of the above conditions can be
accepted..."?

Section 5:
You say there are no IANA considerations, but do you need an experimental
ICMPv6 type code allocated?