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

"George Swallow (swallow)" <> Wed, 30 September 2015 15:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 74C831B5EBD; Wed, 30 Sep 2015 08:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PrWLHO22_RP2; Wed, 30 Sep 2015 08:53:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9A8B1B4497; Wed, 30 Sep 2015 08:53:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16042; q=dns/txt; s=iport; t=1443628381; x=1444837981; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QLLeBwSWWdjhiUcbfPKfsBDgHYidgnTHr0928THEwHs=; b=Y7AsY3vBLzO2yhvSCF1yec1UT+QuqBg3uakKg/Br3KJpgUcq8L3TqhFW qe8OZ70of1cBqsLw/pHiSyw+wjBoAB264t0zBCPwZunOZHcCvRebBzPT3 4EnJixwG7sLZtNjxOdq8OhyyQcLYs3eANa+erR/asj76YcqerhkXZjpTF Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.17,613,1437436800"; d="scan'208,217"; a="31499155"
Received: from ([]) by with ESMTP; 30 Sep 2015 15:53:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t8UFr0j0029214 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Sep 2015 15:53:00 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Sep 2015 10:52:59 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 30 Sep 2015 10:52:59 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 10:52:59 -0500
From: "George Swallow (swallow)" <>
To: Lizhong Jin <>, Kathleen Moriarty <>
Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)
Thread-Index: AQHQ+fxNSy2vR3mBPkOL7LOV10Al/55T778AgAFdFAA=
Date: Wed, 30 Sep 2015 15:52:59 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D23160321225ABswallowciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, draft-ietf-mpls-lsp-ping-relay-reply <>, The IESG <>, mpls-chairs <>
Subject: Re: [mpls] Kathleen Moriarty's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Sep 2015 15:53:04 -0000

Lizhong  -

Just a bit of word-smithing.  See inline.



From: Lizhong Jin <<>>
Date: Tuesday, September 29, 2015 at 11:03 AM
To: Kathleen Moriarty <<>>
Cc: The IESG <<>>, mpls-chairs <<>>, draft-ietf-mpls-lsp-ping-relay-reply <<>>, "<>" <<>>
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.


On Mon, Sep 28, 2015 at 10:45 PM, Kathleen Moriarty <<>> 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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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.

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.


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
    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

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

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!