Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01

Hi Qin,

Thank you for your comments.

Please see in-line with [NOBO].

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Qin Wu
> Sent: March-27-15 4:37 AM
> To: mpls@ietf.org
> Cc: mpls-chairs@tools.ietf.org
> Subject: Re: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-reply-
> mode-simple-01
> 
> Hi, Authors of draft-ietf-mpls-lsp-ping-reply-mode-simple-01:
> I have read draft-ietf-mpls-lsp-ping-reply-mode-simple-01 and think it is
ready to
> go for publication.
> Here are few editorial comments on this draft.
> 1.section 3.2 said:
> "
> 4.  If a responder LSR understands the Reply Mode Order TLV and the
>        TLV is valid, then the responder LSR MUST consider Reply Mode
>        values described in the TLV and MUST NOT use the value described
>        in the Reply Mode field of received MPLS echo request.
> "
> I think the value carried in the Reply mode Order TLV overrides the value
> included in the Reply Mode field of MPLS echo request message header,
would it
> be good to make this more clear and explicit.

[NOBO] I agree that clarification will be helpful. Let me swap items 4 and 5
and add the clarification. They will look like:

   4.  If a responder LSR understands the Reply Mode Order TLV but the
       TLV is not valid (due to conditions described in items 6, 8 and 9
       immediate below), then the responder LSR MUST only use the value
       described in the Reply Mode field of received MPLS echo request.

   5.  If a responder LSR understands the Reply Mode Order TLV and the
       TLV is valid, then the responder LSR MUST consider Reply Mode
       values described in the TLV and MUST NOT use the value described
       in the Reply Mode field of received MPLS echo request.  In other
       words, a valid Reply Mode Order TLV overrides the value specified
       in the Reply Mode field of received MPLS echo request.

> 
> 2. section 3.2 also said:
> "
> 5.  If a responder LSR understands the Reply Mode Order TLV but the
>        TLV is not valid (due to conditions  listed below), then the
>        responder LSR MUST only use the value described in the Reply Mode
>        field of received MPLS echo request.
> "
> Not sure where the conditions are specified, suggest to provide a link to
the
> conditions specified in this document

[NOBO] Good catch. Please see the corrected "link" in the texts provided as
response to your comment #1.

> 
> 3.section 4.1 said:
> "
> [RFC7110] has defined that the "Reply Path TLV" can include Sub-TLVs
>    describing multiple FECs, from which the responder LSR can chose  the
>    FEC to send the MPLS echo reply message on .
> "
> s/chose/choose
> send the MPLS echo reply message on?
> What does "on" mean here? Remove "on" from this sentence?

[NOBO] Accepted.

> 
> 4. section 4.1.2 said:
> "
>    Then the MPLS echo request message is to carry:
> 
>    o  The Reply Mode Order TLV carrying Reply Modes  {5, 2, 5} "
> Reply mode 5 is not defined in RFC4379.Where reply mode 5 is defined?

[NOBO] RFC7110.

> 
> 5. section 4.2 said:
> "
> The mechanism defined in this document will work with Proxy LSP Ping
>    defined by [I-D.ietf-mpls-proxy-lsp-ping].  MPLS proxy ping request
>    can carry a Reply Mode value and  the Reply Mode Order TLV with list
>    of Reply Mode values.
> "
> 
> Suggest To distinct reply mode value carried In the message header and
reply
> mode value carried in the Reply mode order TLV here

[NOVO] Accepted.

> 
> 6. section 4.2 said:
> "
> With these procedures, Reply Mode used by the MPLS echo
>    reply sender is propagated in the Reply Mode field to the sender of
>    MPLS proxy ping request.
> "
> I am totally confused by this last sentence.
> what does " sender" in"the MPLS echo reply" means? Are you saying reply
mode
> value in the echo rely is propagated to proxy ping request? Or propagated
to
> proxy ping reply?
> How the sender of MPLS proxy ping request is related to initiator LSR or
> responder LSR or responding node used in the document?
> It will be nice to have a consistence terminologies use.

[NOBO] You are right, that whole Proxy Ping subsection is a garbage. I
proposed we replace with followings:

4.2.  Proxy LSP Ping

   The mechanism defined in this document will work with Proxy LSP Ping
   defined by [I-D.ietf-mpls-proxy-lsp-ping].  The MPLS proxy ping
   request message can carry a Reply Mode value in the header and one or
   more Reply Mode values in the Reply Mode Order TLV.  It is
   RECOMMENDED that the Reply Mode 2 (Reply via an IPv4/IPv6 UDP packet)
   be used in the Reply Mode field of the MPLS proxy ping request
   message.

4.2.1.  Proxy LSR Sending an MPLS Echo Request

   If the proxy LSR is sending an MPLS echo request, then the proxy LSR
   MUST copy following elements from the MPLS proxy ping request message
   to the MPLS echo request message.

   o  The Reply Mode field.

   o  The Reply Mode Order TLV.

   o  The Reply Path TLV(s).  If there are more than one Reply Path
      TLVs, then then order of them MUST be preserved when copying.

4.2.2.  Proxy LSR Sending an MPLS Proxy Ping Reply

   If the proxy LSR is sending an MPLS proxy ping reply, then it is
   RECOMMENDED that the Reply Mode Order TLV be ignored and the Reply
   Mode field in the MPLS proxy ping request message be used.

What do you think?

Thanks!

-Nobo

> 
> -Qin
> -------- Forwarded Message --------
> Subject: 	working group last call for
> draft-ietf-mpls-lsp-ping-reply-mode-simple-01
> Date: 	Fri, 20 Mar 2015 14:03:52 +0000
> From: 	Ross Callon <rcallon@juniper.net>
> To: 	mpls@ietf.org <mpls@ietf.org>
> CC: 	mpls-chairs@tools.ietf.org <mpls-chairs@tools.ietf.org>, George
> Swallow (swallow) <swallow@cisco.com>, Carlos Pignataro (cpignata)
> <cpignata@cisco.com>, Loa Andersson <loa@mail01.huawei.com>, Mach Chen
> <mach.chen@huawei.com>, nobo.akiya.dev@gmail.com
> <nobo.akiya.dev@gmail.com>
> 
> 
> 
> Working Group,
> This is to initiate a working group last call on
draft-ietf-mpls-lsp-ping-reply-
> mode-simple-01.
> Because this WGLC will span the IETF in Dallas, it will be extended to
three
> weeks.
> Please send your comments to the mpls wg mailing list (_mpls@ietf.org_
> <mailto:mpls@ietf.org>).
> There are no IPR disclosures against this document. All the authors have
stated
> that they are not aware of any IPR that relates to this draft.
> This working group last call ends Friday  April 10, 2015.
> Ross
> for the MPLS WG chairs
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls