Last Call Review of draft-ietf-mpls-lsp-ping-relay-reply-04
review-ietf-mpls-lsp-ping-relay-reply-04-opsdir-lc-pignataro-2014-10-12-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-mpls-lsp-ping-relay-reply-04-opsdir-lc-pignataro-2014-10-12

Hi!

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

This document is on the Standards Track, and specifies extensions to LSP Ping to enable the relay of responses, useful in Inter-AS scenarios.

Summary: Not ready

Major:

I have two concerns with this doc as currently written:

1. The use of "private" versus "public" versus "routable" is not clear and confusing. What addresses should be used where? Further, I do not believe that the doc as currently defined can be used for IPv6, even when the TLV allows for IPv6 address types in the relayed stack (because of similar reasons). I'd suggest a short Definitions section explaining this, for IPv4 and IPv6.

2. I think there is a problem in the logic in Section 4.2. The text says:

   the stack.  The address entry added by the replying LSR MUST be same
   as the source IP address of Relay Echo Reply (section 4.3) or Echo
   Reply message (section 4.5) being sent. 

However, when the ASBR from the first AS is replying to the echo request from the PE in the same AS, would likely use as a source address a potentially private non-internet routable address (the address of the interface facing AS1). If that's so, should that private address be added to the stack?

Minor:

It would be quite useful if there was a section that explicitly states what are the updates to RFC 4379.

Nits:

Idnits finds a number of nits, including:

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
     document.

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'SHOULD not' in this paragraph:

  == Unused Reference: 'I-D.ietf-mpls-proxy-lsp-ping' is defined on line 621,
     but no explicit reference was found in the text


Hope this helps.

Thanks,

-- Carlos.