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

From: Loa Andersson <[email-masked]>
Date: Sat, 04 Jan 2014 13:02:54 +0800

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 6 Jan 2014 07:10:18 +0000

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?

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.
"
It looks to me if no MPLS proxy ping rely needs to be sent, why define reply mode 5?

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
In section 5.2, there is no definition of reply to address field, I think it should be defined as initiator address
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.

Regards!
-Qin  
-----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,

/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

---

From: Mach Chen <[email-masked]>
Date: Sat, 18 Jan 2014 06:51:39 +0000

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.

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?

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?

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

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. 

4. Section 3.1 the last second paragraph:

s /DDSMAP)/(DDSMAP)

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?

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?

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

6.3 Last paragraph, last sentence

s / M2MP leaf /MP2MP leaf

7. Section 3.2.4.1

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

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.

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?

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.

10.Section 5.1

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

Best regards,
Mach

> Please send your comments to working group mailing lists ([email-masked]).
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 21 Jan 2014 16:42:24 +0800

Working Group,

This working group last call is closed. There has been comments,
could the authors please address the comments and re-post a new
version of the document as necessary. Please make sure that the
reviewers are comfortable with how the comments are resolved.

/Loa
mpls wg co-chair

--

---

From: Vanson Lim <[email-masked]>
Date: Mon, 27 Jan 2014 17:12:58 -0500

Loa,

Just wanted to acknowledge the receipt of this email.   Sam/George and I will meet this week to work on addressing comments.

-Vanson

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Jan 2014 11:14:31 +0800

Vansom,

OK - please ping me when you post the new version.

/Loa

On 2014-01-28 06:12, Vanson Lim wrote:
> Loa,
>
> Just wanted to acknowledge the receipt of this email.   Sam/George and I
> will meet this week to work on addressing comments.
>
> -Vanson
>
>

--