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

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> wrote:
> Thanks, George, I am OK with your suggestion.
>
> Lizhong
>
>
> On Wed, Sep 30, 2015 at 11:52 PM, George Swallow (swallow)
> <[e-mail]> wrote:
>>
>> Lizhong  -
>>
>> Just a bit of word-smithing.  See inline.
>>
>>    Thanks,
>>
>> George
>>
>>
>>
>> From: Lizhong Jin <[e-mail]>
>> Date: Tuesday, September 29, 2015 at 11:03 AM
>> To: Kathleen Moriarty <[e-mail]>
>> Cc: The IESG <[e-mail]>, mpls-chairs <[e-mail]>,
>> draft-ietf-mpls-lsp-ping-relay-reply
>> <[e-mail]>, "[e-mail]"
>> <[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]> 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