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 resolve these comments along with any other Last Call comments you may receive. Sorry to be so last-minute. Life happens. Tom Taylor Document: draft-ietf-mpls-proxy-lsp-ping-03 Reviewer: Tom Taylor Review Date: 2015-02-12 IETF LC End Date: 2015-02-12 IESG Telechat date: 2015-02-19 Summary: Generally well written, but a few minor issues and a number of nits and editorial suggestions. Major issues: Minor issues: 1. Section 3.1, "Proxy Echo Parameter TLV MPLS payload size field". This section describes initiator actions, but the paragraph contains the text: " When the payload size is non zero, if sending the MPLS Echo Request involves using an IP header, the Do not Fragment (DF) bit MUST be set to 1." This sentence logically belongs in Section 3.2 (3.2.4.1), which has no instructions at all regarding the payload size field. Noted that the description of the MPLS Payload Size field in Section 5.1 has a full description, but says the DF bit SHOULD be set. Is it MUST or SHOULD, and if the latter, what is the exception? 2. Section 3.2.1, third paragraph, second sentence currently reads: "If the Proxy LSR is a budnode, a MPLS proxy ping reply SHOULD be sent to the initiator with the return code set to 3 (Reply router is Egress for FEC) with return Subcode set to 0 and DS/DDMAPs only if the Proxy initiator requested information to be returned in a MPLS proxy ping reply." Do you mean that the DS/DDMAP TLV is included only if the initiator asked for it (which seems like redundant advice) or do you mean that the reply is sent only if the initiator asked for the DS/DDMAP information? 3. Same paragraph, next sentence: why SHOULD rather than MUST? What is the exception? 4. Section 3.2.1, last paragraph (dealing with MP2MP case): the second to fourth sentences read: "LSP pings sent from a leaf of a MP2MP has different behavior in this case. MPLS Echo Request are sent to all upstream/downstream neighbors. The Proxy LSRs need to be consistent with this variation in behavior." s/has/have/ to get that out of the way. Do you mean that the initiator is a leaf of the MP2MP? How does the Proxy LSR know this? Does it matter? If it is the Proxy LSR that is the leaf, the statement makes more sense. The different behavior is that the Proxy LSR always sends MPLS Echo Requests in at least one direction if it is not sending an MPLS proxy ping reply. You could refer to the previous paragraph for the remaining behavioural description. The next sentence in this paragraph has the same problem as Minor Issue 2. above, except that I see a stronger hint that the second interpretation suggested above is your intention. 5. You are creating a new IANA registry for sub-types of the Proxy Echo Parameters TLV. You need to document registration procedures as per RFC 5226. Nits/editorial comments: General: Is there a reason for capitalizing "MPLS Echo Request" but not "MPLS proxy ping request[reply]"? General: Sometimes return code text is enclosed in quotes, sometimes in parentheses. Choose one. 1. ABSTRACT third line: s/Routers/Router/ 2. Section 2.1.1, first line: s/If/if/ 3. Same section, second paragraph has both typos and editorial glitches. OLD In the case the targeted proxy LSR does not understand LSP ping Echo Request at all, like any other LSR which do not understand the messages, they MUST be dropped and no messages is set back to the initiator. NEW In the case where the targeted proxy LSR does not understand the LSP ping Echo Request at all, like any other LSR which does not understand the messages, it MUST drop them and MUST NOT(?) send any message back to the initiator. [Was the MUST NOT intended? -- PTT] 4. Section 3.1, last sentence: s/is// 5. Section 3.2, first paragraph, fourth line: s/set to/to/ 6. Same section, fifth paragraph: s/Request messages/Request message/ s/one is sent/either is sent/ 7. Same section, sixth paragraph, end of second-last line: s/an// 8. Same section, seventh paragraph: invocation is something that happens after configuration. Maybe you want to say: "If a configured filter has been invoked and an address ..." 10. Same section, later paragraph as shown below (editorial suggestion): OLD If the "Request for FEC Neighbor Address info" flag is set, a Upstream Neighbor Address TLV and/or Downstream Neighbor Address TLV(s) is/are formatted for inclusion in the MPLS proxy ping reply. If the Upstream or Downstream address is unknown they are not included in the Proxy Reply. NEW If the "Request for FEC Neighbor Address info" flag is set, the Upstream Neighbor Address and Downstream Neighbor Address TLVs are formatted for inclusion in the MPLS proxy ping reply. If the Upstream or Downstream address is unknown the corresponding TLV is omitted. 11. Same section, paragraph re detailed downstream mapping: s/LSR/Proxy LSR/ s/inclusions/inclusion/ You use the abbreviation DS/DDMAP in the following section. Perhaps, since you spell that out in this section, you might add "(DS/DDMAP)" before "TLV". 12. Same section, next paragraph: s/vary/varies/ Capitalization is inconsistent: Proxy/proxy, egress/ Egress. The last sentence is referring to Section 3.2.1. Suggest either copying that section's heading exactly or using the section number. 13. Section 3.2.1: inconsistent capitalization of "egress". 14. Section 3.2.2: s'DSMAP/DDMAP'DS/DDMAP' (3 instances) or spell out if this is a new abbreviation. In the first paragraph, mLDP is not a well-known abbreviation < http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt >, hence needs to be spelled out. ("Multipoint LDP", RFC 6826). In the second paragraph, fourth from last line: s/egresses/egress/ 15. Section 3.2.4.1 first paragraph, second sentence: OLD If Next Hop sub-TLVs were included in the received Proxy Parameters TLV, the Next_Hop_List created from the address in those sub-TLVs as adjusted above. NEW If Next Hop sub-TLVs were included in the received Proxy Echo Parameters TLV, the Next_Hop_List is created from the addresses in those sub-TLVs adjusted as described in Section 3.2. 16. Section 5.1, first paragraph: s/to either to/either to/ Why are "Composing" and "Sending" capitalized? Seventh line down, end of line, add comma after "stack". Next line: s/ie/i.e.,/ Next line: s/Proxy Reply/MPLS Proxy Ping Reply/ 17. Section 5.1, Proxy Flags field description, 0x01, first paragraph: Fourth line: s/FEC types/FEC type/ Fifth line: s/LSPs/LSP/. Following sentence: OLD The Proxy LSR MUST respond as applicable with a Upstream Neighbor Address TLV and Downstream Neighbor Address TLV(s) in the MPLS proxy ping reply message. NEW The Proxy LSR MUST respond as applicable with Upstream Neighbor Address and Downstream Neighbor Address TLV(s) in the MPLS proxy ping reply message. Following sentence: begin with "The". Last sentence: OLD for which the LSR learned bindings from. NEW from which the LSR learned bindings. 17. Section 5.1, Proxy Flags field description, 0x01, second paragraph: s/an Echo request/any MPLS Echo Request/ Second sentence: OLD Information learned with such proxy reply may be used by the proxy initiator to generate subsequent proxy requests. NEW The initiator may use information learned from the MPLS proxy ping reply that is sent instead to generate subsequent proxy requests. [Also applies to the last sentence of the 0x04 description) 18. Section 5.1, Sub-TLVs: "TLV-encoded list" means to my mind that there is a TLV type and length preceding the first Sub-TLV. Maybe you mean "List of TLV-encoded sub-TLVs"? 19. Section 5.1.1, "Next Hop Interface": why is the interface identifier 16 octets long in the case of IPv6 numbered? Should there be text saying that numbered interfaces are identified by the addresses assigned to them, unnumbered interfaces by ?? 20. Section 6, second paragrph: refers to "these points". What points? 21. IANA Considerations It would be helpful to indicate that the registries involved are found under the heading "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters".