Last Call Review of draft-ietf-rtgwg-ipfrr-notvia-addresses-10
review-ietf-rtgwg-ipfrr-notvia-addresses-10-genart-lc-krishnan-2013-02-05-00

Request Review of draft-ietf-rtgwg-ipfrr-notvia-addresses
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-01-31
Requested 2013-01-17
Authors Stewart Bryant, Stefano Previdi, Mike Shand
Draft last updated 2013-02-05
Completed reviews Genart Last Call review of -10 by Suresh Krishnan (diff)
Secdir Last Call review of -10 by Yaron Sheffer (diff)
Assignment Reviewer Suresh Krishnan
State Completed
Review review-ietf-rtgwg-ipfrr-notvia-addresses-10-genart-lc-krishnan-2013-02-05
Reviewed rev. 10 (document currently at 11)
Review result Almost Ready
Review completed: 2013-02-05

Review
review-ietf-rtgwg-ipfrr-notvia-addresses-10-genart-lc-krishnan-2013-02-05

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