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

Lizhong Jin <lizho.jin@gmail.com> Wed, 30 September 2015 16:00 UTC

Return-Path: <lizho.jin@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED43A1B5DC5; Wed, 30 Sep 2015 09:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKkFhHhuyNkq; Wed, 30 Sep 2015 09:00:47 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855801B5B59; Wed, 30 Sep 2015 09:00:39 -0700 (PDT)
Received: by wicge5 with SMTP id ge5so203642336wic.0; Wed, 30 Sep 2015 09:00:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P9lI1Mjw53yo0PPip8RjetT2vXvUnMSgnjPPu1rMo+I=; b=pnXk2gPlAocEyzSsBcUAVRQJ1zB3wjxihWMqnBGFI5U+55KGpbnGe7h17VFMgt/h8z runecaLxWvYu1eoroHypa6kz55+Va6QZyYPvNsU9QY9VuYXSZgQKv+oR+O4VuIZjAqpG rtetac6WyaTnnCUOWO89FTv4ODd1J4SfWw5guWqYOFHjSp6b0cxbUzfqRCgUKF+2M3ly Op6YP2PcrvWrxq0FVq4ZnI3RUJRowHgZHbRJXxFlngmI63oalpudV2215IgDmoQeWIJp xoHgQXPdm8pthrerYQ7q0mSzhBxaHQRuKtMdzLlSfZwPJb3xmbVjaBlScgDLG7q1rg3p U+NA==
MIME-Version: 1.0
X-Received: by 10.194.104.137 with SMTP id ge9mr5072260wjb.57.1443628838038; Wed, 30 Sep 2015 09:00:38 -0700 (PDT)
Received: by 10.194.236.164 with HTTP; Wed, 30 Sep 2015 09:00:37 -0700 (PDT)
In-Reply-To: <D2316032.1225AB%swallow@cisco.com>
References: <20150928144514.27528.79571.idtracker@ietfa.amsl.com> <CAH==cJzA_+AMYPRO0Fj3hmKAVZkMs4s1+-FLkUhNJ2iTEGJjnw@mail.gmail.com> <D2316032.1225AB%swallow@cisco.com>
Date: Thu, 01 Oct 2015 00:00:37 +0800
Message-ID: <CAH==cJx9Ye34mMo=zTNFDTQK=OwCFn9jG-6k0sqezkS3o731bw@mail.gmail.com>
From: Lizhong Jin <lizho.jin@gmail.com>
To: "George Swallow (swallow)" <swallow@cisco.com>
Content-Type: multipart/alternative; boundary="089e010d83881440b50520f90865"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/e6oxYB0aFK2-sXMC36ersZG6cEA>
Cc: draft-ietf-mpls-lsp-ping-relay-reply <draft-ietf-mpls-lsp-ping-relay-reply@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, The IESG <iesg@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
Subject: Re: [mpls] Kathleen Moriarty's No Objection on draft-ietf-mpls-lsp-ping-relay-reply-10: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 16:00:51 -0000

Thanks, George, I am OK with your suggestion.

Lizhong

On Wed, Sep 30, 2015 at 11:52 PM, George Swallow (swallow) <
swallow@cisco.com> wrote:

> Lizhong  -
>
> Just a bit of word-smithing.  See inline.
>
>    Thanks,
>
> George
>
>
>
> From: Lizhong Jin <lizho.jin@gmail.com>
> Date: Tuesday, September 29, 2015 at 11:03 AM
> To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
> Cc: The IESG <iesg@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>,
> draft-ietf-mpls-lsp-ping-relay-reply <
> draft-ietf-mpls-lsp-ping-relay-reply@ietf.org>, "mpls@ietf.org" <
> mpls@ietf.org>
> 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 <
> Kathleen.Moriarty.ietf@gmail.com> 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!
>>
>>
>>
>