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

["Fred L. Templin" <[e-mail]>]

Hello Pete,

Thank you for your comments, and please see below for proposed resolutions:

Fred
[e-mail]

>________________________________
> From: Pete McCann <[e-mail]>
>To: [e-mail]; [e-mail] 
>Sent: Monday, April 23, 2012 9:42 PM
>Subject: Gen-ART Telechat Review of draft-templin-aero-10
> 
>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.

Scaling properties of the mechanism are proportional to
the number of distinct
(ingress, egress) pairs of active communications.
Intuitively, the mechanism will
provide better scaling properties than
traditional dynamic routing protocols if
the number of active pairs is sparse
in relation to the number of nodes on the
link. Quantitative analysis would be
through experimentation after publication.

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

A deployment example could be added as a new Section
4.4 (causing existing
Sections 4.4 onward to be renumbered beginning with
Section 4.5). The new
Section could read:
 
“As a simple example, consider a large service provider
network that is extended
primarily using L2 bridges instead of L3 routers. The
network is therefore seen as
a single link by the IP layer. In that case, a new
spoofing attack vector is open to
malicious nodes on the link that could send
packets with spoofed IP source
addresses with low probability of detection,
e.g., to initiate a DoS attack directed
to some other node on the link. AERO
therefore applies to links on which attached
nodes do not necessarily trust
each other.”

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

Yes; the figure is incorrect, and will be corrected to say "100".

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

Punching a hole in a short aggregated prefix is one
possibility, but another
possibility is that the edge router is delegated many
non-aggregated long
prefixes. In that case, the mobile node can take its long
prefix to a new
edge router without the old edge router needing to punch any
holes.

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


You are correct; this was also mentioned in an earlier comment and
will be fixed in the next document version.


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

No new experimental ICMPv6 code type needs to be
allocated, since RFC4443
sets aside the value “100” as an experimental ICMPv6
code point.
>