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

[Pete McCann <[e-mail]>]

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>.

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?