Last Call Review of draft-ietf-mpls-proxy-lsp-ping-03
review-ietf-mpls-proxy-lsp-ping-03-secdir-lc-yu-2015-03-02-00

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: ready with nits

The Security Considerations section seems mostly adequate, assuming that
it is an acceptable risk to use address-based filtering.

I am a little concerned about the wording of the destination address
checks on the proxy ping requests.  Shouldn't the Proxy LSR know what
its own addresses are, and explicitly check for them?  Does "Martian"
filtering refer to all undesired destination addresses, or just reserved
ones?

There seems to be no citation for the term "Martian address" as used in
sections 3.2 and 6 of this document; RFC 3704 comes close.  If that
definition is appropriate here, perhaps this document should cite RFC
3704?  I think I have also heard "Martian" used more expansively to
refer to other address blocks that should not be routed, despite not
being formally reserved (e.g., unallocated by the responsible registry).
Perhaps that definition is more appropriate.

Editorial:

The use of destination addresses in range 127/8 seems odd to me, but I
eventually found that RFC 4379 allows the use of such loopback range
addresses for the LSP echo requests.  Is this correct?  It might be good
to briefly explain that unusual usage.

Also, I am not too familiar with the special IPv6 address ranges, but it
seems that ::FFFF:7F00:0/104 is a IPv4-mapped loopback range, and
therefore is equivalent to the 127/8 IPv4 range mentioned earlier.  I
don't know whether you need to call this out specifically.  Also, RFC
4379 uses the notation ::FFFF:127/104.  I'm not sure which of those
notations is preferred for IPv4-mapped addresses.