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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 30 September 2015 16:08 UTC

Return-Path: <kathleen.moriarty.ietf@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 7C3231B5E7E; Wed, 30 Sep 2015 09:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 hQiYLFvoGMXD; Wed, 30 Sep 2015 09:08:22 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 13DB11B4652; Wed, 30 Sep 2015 09:08:22 -0700 (PDT)
Received: by wicge5 with SMTP id ge5so203982907wic.0; Wed, 30 Sep 2015 09:08:20 -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:content-transfer-encoding; bh=8LSn2dmacC3Msc24K0mMVWkFeGptq+Zy1rxsuvVW02E=; b=roXGXLp/A5fmsotm7Rmf4piC1u7o5hv0SSsMQltlVPaDu0wArgtDex4ssrSuSyvpgl 6oMAQ06MhLXK3DxoU7mdptwwbkHEPaNL576FuIF5lxNmqC4GUVQrLmsqxhKSvPKB8FE5 AdydMLuUZtXEjx1jw1V9/Uya/GNsq/nYFIiVVtAisgXRM9Nh7F8mYB0uM05Ws+10wQxl JZleibI/S8BINJdemT9n2Mb6D/r7pzib4QqHI9P8CHVD6Mv3gsf/SM3oIlgvk9Nrp1/G The78//W/O4f7Pq9XFTmDv3RcaeinGmzC071f2asbvqUEiAnbLwjaUoKkKPKO2/tW6Uw qpnQ==
MIME-Version: 1.0
X-Received: by 10.194.234.40 with SMTP id ub8mr5040002wjc.95.1443629300627; Wed, 30 Sep 2015 09:08:20 -0700 (PDT)
Received: by 10.28.214.213 with HTTP; Wed, 30 Sep 2015 09:08:20 -0700 (PDT)
In-Reply-To: <CAH==cJx9Ye34mMo=zTNFDTQK=OwCFn9jG-6k0sqezkS3o731bw@mail.gmail.com>
References: <20150928144514.27528.79571.idtracker@ietfa.amsl.com> <CAH==cJzA_+AMYPRO0Fj3hmKAVZkMs4s1+-FLkUhNJ2iTEGJjnw@mail.gmail.com> <D2316032.1225AB%swallow@cisco.com> <CAH==cJx9Ye34mMo=zTNFDTQK=OwCFn9jG-6k0sqezkS3o731bw@mail.gmail.com>
Date: Wed, 30 Sep 2015 12:08:20 -0400
Message-ID: <CAHbuEH4PBy+r08Dd2U8N1uUPEnJgd-PzPj0AXKRfN2V-0Z7Ycg@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Lizhong Jin <lizho.jin@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/VXTppZuR2BjDgDIJEoQgKfZt-18>
Cc: "mpls@ietf.org" <mpls@ietf.org>, draft-ietf-mpls-lsp-ping-relay-reply <draft-ietf-mpls-lsp-ping-relay-reply@ietf.org>, 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:08:25 -0000

Thank you both for the quick responses.  I do agree that George's
proposed text clarifies the questions better.  That text works for me.

Thanks,
Kathleen

On Wed, Sep 30, 2015 at 12:00 PM, Lizhong Jin <lizho.jin@gmail.com> wrote:
> 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>rg>, mpls-chairs <mpls-chairs@ietf.org>rg>,
>> draft-ietf-mpls-lsp-ping-relay-reply
>> <draft-ietf-mpls-lsp-ping-relay-reply@ietf.org>rg>, "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!
>>>
>>>
>>
>



-- 

Best regards,
Kathleen