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

From: Sam Aldrin <[email-masked]>
Date: Wed, 28 May 2014 18:04:29 -0700

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.

#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.

#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. 

#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.

#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  

======

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?

Specific comments:

1. Section 2

If the source address of the MPLS echo request is not to be
   set to the Proxy Request source address, the initiator must include a
   Reply-to Address TLV containing the source address to use in the MPLS
   echo request.

Why we need the Reply-to Address TLV? Which address will be included in the Reply-to Address TLV? If the address is neither the initiror or the proxy LSR, this may import some security isses?

##RESP: We added this TLV for a reason, which at that time, was needed. From what we see now, the requestor IP will be used. Hence, this TLV will be removed.

2. Section 3.1

2.1 
"The message MUST contain a Target FEC Stack that describes the FEC
   being tested.  The topmost FEC in the target FEC stack is used at the
   Proxy LSR to lookup the MPLS label stack that will be used to
   encapsulate the MPLS echo request packet.
"
Seems that it only needs to carry the topmost FEC, and no need to carry other FECs. And even if carried, it does not make sense. Right?

##RESP:  reused existing target fec stack,  don’t want to restrict to topmost FEC in case there are future uses. 

2.2  
s /MPLS Proxy Ping message/MPLS proxy ping request message, need to look through the document to make them consistent. 
##RESP - Ack.

3. Section 3.1 the sixth paragraph:
"The Proxy Request reply mode is set with one of the reply modes
   defined in [RFC4379] as appropriate."

Is the reply mode here referred to the reply mode of the MPLS proxy request, or the reply mode of the Proxy Echo Parameter. I think it's the former, right? 

And section 5.1 said:
"The MPLS Proxy Echo request echo header's Reply Mode should be set to "Reply with Proxy Info"."

Seems they are self-contradictory here. 

##RESP - Not really. Sec 3 is describing the reply mode should use one of the modes defined in RFC4379. While Sec 5.1 is talking about the request to query info from proxy LSR.

4. Section 3.1 the last second paragraph:

s /DDSMAP)/(DDSMAP)

##RESP - Ack

5. Section 3.2, in the middle of the fourth paragraph.

"Other filters on FECs or MPLS echo request contents MAY be applied."

For a Proxy LSR, it will not receive any MPLS echo request, should it be the MPLS proxy ping request here?

##RESP:  The sentence is talking about proxy LSR sending MPLS echo request, not receiving.

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”

6.2 
If there is no DS/DDMAPs returned, how does the initiator determine the proxy LSR is budnode or egress?

##RESP: wanted to have the same behavior when injecting a LSP Ping at an egress.  When we ping from a bud node,  if we  don’t typically get an echo reply from ourselves,  so we wanted to provide the ability for the Proxy requester to decide whether they want a proxy reply to by send back in response to a proxy request.  is_egress return code used to indicate proxy lsr also an egress.

6.3 Last paragraph, last sentence

s / M2MP leaf /MP2MP leaf

##RESP - ack

7. Section 3.2.4.1

7.1 What's is "base MPLS echo request"? I suggest to remove the "base" here.

##RESP: Seems fine to remove.

7.2 

"If the Explicit Differentiated Services Code Point (DSCP) flag is
   set, the Requested DSCP byte is examined.  If the setting is
   permitted then the DSCP byte of the IP header of the MPLS Echo
   Request message is set to that value.  If the Proxy LSR does not
   permit explicit control for the DSCP byte, the MPLS Proxy Echo
   Parameters with the Explicit DSCP flag cleared MUST be included in
   any MPLS proxy ping reply message to indicate why an Echo Request was
   not sent.  The return code MUST be set to <tba>, "Proxy ping
   parameters need to be modified".  If the Explicit DSCP flag is not
   set, the Proxy LSR should set the Echo Request DSCP settings to the
   value normally used to source LSP ping packets."

I am not sure whether this is the right choice to let the Proxy LSR to control whether the DSCP is permitted or not. IMO, this permission should be controlled by the Receiver or Responder.

##RESP:  This section is referring to the DSCP settings in the MPLS echo request label stack and ip header not the reply dscp.   When initiating LSP pings, the sender of the lsp ping controls this setting, so it was felt that it be valuable to allow the sender of the proxy request to control this subject to restrictions imposed at the Proxy LSR.

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.

9. Section 4.2
"
 The MPLS proxy ping request message MAY contain the following
   TLVs:
"
You may also need to contain the Type 21 and 22 TLV.

##RESP:  okay, we’ll add these tlv’s to the list of tlv’s to be included in the proxy request for including into the echo requests.

10.Section 5.1

s /MPLS Proxy Echo Request message /MPLS proxy ping request message, same as the above comment 2.2
##RESP - ack

Best regards,
Mach

Cheers
-sam

> 
>> -----Original Message-----
>> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
>> Sent: Saturday, January 04, 2014 1:03 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping
>> 
>> Working Group,
>> 
>> this is to start a two week working group last call on
>> draft-ietf-mpls-proxy-lsp-ping-01.txt
>> 
>> Please send your comments to working group mailing lists ([email-masked]).
>> 
>> We will do an IPR poll on this document in parallel thee wglc.
>> 
>> There are three IPRs disclosures that relates to this document.
>> 
>> The working group last call will end Friday January 20, 2914.
>> 
>> /Loa
>> mpls wg co-chair
>> 
>> --
>> 
>> 
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls