Subject: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping

From: Mach Chen <[email-masked]>
Date: Tue, 3 Jun 2014 07:44:07 +0000

Hi Sam,

Thanks for considering my comments!

See my reply inline...

Sniped the resolved parts.

> 
> 
> 2) From Mach Chen
> 
> Hi Authors,
> 
> I just reviewed the draft, here are my comments, hope this help.
> 
> General comments:
> It would be better if you could adjust the structure of the draft to put Section 3
> behind Section 5. Then the reader will not need to check definitions of the
> Messages and TLVs in the back and then return back keep reading the document.
> 
> ##RESP - I feel it is good to have description before the actual format definition.
> Either case, one has to go back and forth to understand completely. Is there any
> hard preference to your suggestion?

That's my personal feeling when I read the draft, but I am fine with the current structure. 

> Specific comments:

> 6. Section 3.2.1
> 
> 6.1 In the middle of third paragraph:
> 
> "If the Proxy LSR is a Budnode but not
>    requested to return a Proxy reply, the Proxy LSR should send packets
>    to the downstream neighbors (no Echo reply is sent to the Proxy
>    Initiator to indicate that the Proxy LSR is an egress).
> "
> 
> What packets will be sent to the downstream neighbors?
> 
> ##RESP:  "MPLS Echo Request"

It's better to make it more explicit.

> 8.  Section 3.2.4.2
> 
> "If any additional labels are pushed
>    onto the stack, their TTLs are set to 255."
> 
> what's this case? Can you clarify more about the case?
> 
> ##RESP:  Don't want to requester have have control of the ttls for tunnels not
> relevant to the FEC being tested.

It's better to add some clarification text.

Best regards,
Mach

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Jun 2014 08:07:59 +0000

Hi, Sam:
Thanks for addressing my comments.
See my reply below.
-----邮件原件-----
发件人: Sam Aldrin [mailto:[email-masked]] 
发送时间: 2014年5月29日 9:04
收件人: Mach Chen; Qin Wu
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping

Hi Mach and Qin,

Please find response to comments embedded with ##RESP.
Sorry it took a while to respond but here it is anyway.
Let know if you have any further questions. We would like to make edits, close all open items and submit a new version of the draft to complete LC.

Comments from Qin:

#1
Hi, authors:
Have a quick look at this draft, It is not clear to me why proxy LSR doesn't need to wait for The result of MPLS echo rely and then send MPLS proxy ping reply?
I know the draft says the receivers process the MPLS echo request, sending their MPLS echo replies directly back to the initiator, however why bypass proxy LSR?
What about MPLS echo request initiating by proxy LSR is lost? How does the initiator know the lost of MPLS echo request or reply?
What am I missing?

##RESP:   LSP ping is designed with initiator initiating the request and maintaining the state for the same. All the transit or responding router do not maintain any state. Requiring Proxy LSRs to manage relaying the response would require it to maintain state for the entire transaction,  including requiring the a timeout to be supplied by the initiator. This will require the change in architecture, which this draft is definitely not intending to do.

[Qin]: Okay. Thanks for your clarification. I can live with this.

#2
Also it is not very clear to me how to use reply mode 5, although the draft says "
If the Reply Mode of the message header is 1 or is 5 and no errors or modifications have occurred no MPLS proxy ping reply is sent.
"
##RESP:  There is no mention of reply mode 5. Which document are you referring to? The document refers only to mode 1, where, no reply SHOULD be sent for that mode.

   If the Reply Mode of the Proxy Request message header is "1 - do not
   reply", no MPLS proxy ping reply is sent.  Otherwise an MPLS proxy
   ping reply message or MPLS echo request should be sent as described
   below.

[Qin]: I am referred to this document, last paragraph of section 3.2 did mentions using reply mode 5.

#3
It looks to me if no MPLS proxy ping rely needs to be sent, why define reply mode 5?
###RESP:  No mention of reply mode 5. If you are referring to reply mode 1, the question is for RFC4379. All I can say is, it is there to check unidirectional errors. 

[Qin]: See above.

#4
Also there are a lot of nits and typos that need to be fixed, s/ limiting the the number/ limiting the number s/ motivaton/ motivation s/ and and all autho-rization/ and all authorization s/ Pprocedures/ Procedures s/ sub-objexts/ sub-objects s/ modificatons /modifications s/ decribed/ described s/ assigments/assignments

##RESP: Ack

#5
In section 5.2, there is no definition of reply to address field, I think it should be defined as initiator address

##RESP:  This is the address the echo reply should be sent to,  most likely the initiator, but could be something else. We will add text for the field.

[Qin]: Looks good.
#6
For Downstream Mapping objects, it is better to add a reference to RFC4379.
The references [McstPing] [mLDP] are now outdated and need to be updated to the corresponding RFC.
##RESP - Ack. Will add references.

Regards!
-Qin  

======