Re: [mpls] Kathleen Moriarty's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)

["George Swallow (swallow)" <[e-mail]>]

Lizhong  -

Just a bit of word-smithing.  See inline.

   Thanks,

George



From: Lizhong Jin <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 29, 2015 at 11:03 AM
To: Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, mpls-chairs <[e-mail]<mailto:[e-mail]>>, draft-ietf-mpls-lsp-ping-relay-reply <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Kathleen Moriarty's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)

Hi, Kathleen
Thanks for the review. Please see inline below.

Regards
Lizhong

On Mon, Sep 28, 2015 at 10:45 PM, Kathleen Moriarty <[e-mail]<mailto:[e-mail]>> wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-mpls-lsp-ping-relay-reply-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this draft.  The security review from 6 months
ago hasn't been fully addressed in the draft and I think it would be
helpful to do so.  There were responses given on list, but corresponding
updates didn't happen for all of the comments.

https://www.ietf.org/mail-archive/web/secdir/current/msg05301.html

For the first comment, the response was that this mechanism does not
deprecate use of "Echo Reply".  The language in the first paragraph of
section 3 should be made clear on that point.

[Lizhong] OK, how about to change the first paragraph in section3 as below.

 This new
   message is used to replace Echo Reply message which is sent from the
   replying LSR to a relay node or from a relay node to another relay
   node. Note that the reply message from any node to the initiator will

   still be Echo Reply.

[George]

I suggest:


   [[RFC4379] defines two message types, Echo Request and Echo Reply.  This
   document defines a new message type, Relayed Echo Reply. The Relayed

   Echo Reply message is used in place of the Echo Reply message when an LSR is

   replying LSR to a relay node.


For the second comment:
    s4.1: Is the outermost label allowed to be set to 255 to support the
    “ping” mode or must it always be set to 1, 2, etc. to support
“traceroute"
    mode - as described in RFC 4379 s4.3?   I know s5 is just an example
    but it really looks like this extension is just supposed to be for
fault
    isolation.

The response via email says it is possible to set it to 255, could this
be made clear in the draft?
[Lizhong] in section4, we added that LSP ping is possible as below:

If operator has knowledge of the relay nodes,
   the initiator could do LSP Ping by directly sending Echo Request with
   Relay Node Address Stack TLV containing the already known relay
   nodes.

Is the above enough? It seems a bit redundant to say TTL is set to 255 in

Ping mode here.

I suggest


   To preform a ping operation, the initiator first discovers the relay
   nodes. Once those nodes have been discovered, the initiator includes
   the Relay Address Stack TLV any Echo Request message. The node can
   then ping as normal.  Note that in some cases, the repeated lack of
   replies to Echo Request messages may be due to a route change that
   Has impacted the necessary stack of relay nodes.  In this case the
   initiator may need to re-discover the relay nodes.


   The following sections describe the procedures for sending and receiving
   Echo Request messages with the the Relay Address Stack TLV.  These
   procedures can be used in “trace route” mode to discover the relay nodes.



The third comment was addressed, thank you.

It was also good to see the security considerations cover path discovery
as well as DoS related attacks.  Thanks for that!