Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-rtgwg-ipfrr-notvia-addresses-10.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 5 Feb 2013 00:06:01 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-rtgwg-ipfrr-notvia-addresses-10.txt
Reviewer: Suresh Krishnan
Review Date: 2013/02/04
IESG Telechat date: 2013/02/07

Summary: This document is almost ready for publication as an
Informational RFC but I have some comments you may wish to address.

Minor
=====

* Section 5.4

It is not clear how the next-next-hop for a DR is calculated if the
router P uses ECMP to reach the DR (i.e. there are potentially multiple
next-next-hops). Can you please clarify?

* MTU considerations

There is no discussion of the MTU issues that come up due to
encapsulation and some form of requirement for the repair endpoint to
perform path MTU discovery. This is especially important for IPv6 endpoints.

* Security Considerations

- The first sentence talks about using this mechanism disguising
delivery of a packet without talking about further details. Are you
talking about one of the issues discussed in Section 2 of RFC6169? If
so, a pointer could be useful.

- What does the term private address mean in the context of this
section? Does it mean a RFC1918 or RFC4193 address (the properties
requested seem to imply these)? If so, it might be good to make this
explicit.

Editorial
=========

* Section 1

s/based on the concept tunnelling/based on the concept of tunnelling/

Thanks
Suresh