Subject: [mpls] draft-zjns-mpls-lsp-ping-relay-reply

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sun, 14 Oct 2012 19:04:03 +0200

I have been asked to review the above draft as one of the reviewers.

The doc is useful in certain MPLS scenario's as described in the draft. It could be considered to be adopted as a WG doc.

Here are some comments which would make the draft more sound.
1. Describe the behavior for devices that did not implement the additional TLVs. How would they behave.
2. Describe the behavior if the packet length would be exceeded by the Relay Node Address Stack TLV
3. Give an example in the text for the inter-AS and seamless MPLS scenario how the different devices behave with a use case
4. Describe in which scenarios this is applicable: mainly transport MPLS, but not in IP-VPN or L2-VPN scenarios

---

From: Ryan Zheng<[email-masked]>
Date: Wed, 17 Oct 2012 17:14:16 +0800

Hi Wim,

Thank you for the detailed review and insightful comments. Please see 
inline below.

Best Regards,
Ryan

"Henderickx, Wim (Wim)" <[email-masked]> wrote on 
2012-10-15 01:04:03:

> The doc is useful in certain MPLS scenario's as described in the 
> draft. It could be considered to be adopted as a WG doc.
> 
<Ryan>Yes, some description should be added to make the behavior much 
clear. The devices that did not implement the additional TLVs should set 
the return code of 2 ("One or more of the TLVs was not understood") in the 
response according to section 3 of RFC 4379. A suggested value will be 
given in IANA Consideration section of next version.

> the Relay Node Address Stack TLV
<Ryan>Good suggestion. IMO, in most cases, the packet length would not be 
exceeded by the Relay Node Address Stack TLV, thanks to the TLV procedures 
in each replying LSR described in section 4.2. That is the replying LSR 
would check the addresses of the stack in the sequence from top to bottom, 
to find out the first routable IP address. Then those address entried 
behind of the first routable IP address in the address list with K bit set 
to 0 would be deleted, and the address entry of replying LSR would be 
added. That means the addresses stack would be kept optimized by every 
replying LSR during traceroute process, and only those routable relay node 
addresses would be kept in the TLV, not all node addresses。

If the packet length was exceeded by the Relay Node Address Stack TLV 
unexpectablly, the TLV would be dropped and a new return code would help 
to notify the initiator of the situation. The case will be addressed in 
the next version.

> 3. Give an example in the text for the inter-AS and seamless MPLS 
> scenario how the different devices behave with a use case
<Ryan>OK. Will do.

> 4. Describe in which scenarios this is applicable: mainly transport 
> MPLS, but not in IP-VPN or L2-VPN scenarios
<Ryan>Yes, correct.

Hope the reply above addresses your concerns. Thank you.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 18 Oct 2012 11:50:58 +0200

Ryan, thx this indeed addresses the topics I highlighted. Please include them in the next revision

From: Ryan Zheng [mailto:[email-masked]]
Sent: woensdag 17 oktober 2012 11:14
To: Henderickx, Wim (Wim)
Cc: [email-masked]; [email-masked]'; [email-masked]; [email-masked]
Subject: Re: draft-zjns-mpls-lsp-ping-relay-reply

Hi Wim,

Thank you for the detailed review and insightful comments. Please see inline below.

Best Regards,
Ryan

> additional TLVs. How would they behave.
<Ryan>Yes, some description should be added to make the behavior much clear. The devices that did not implement the additional TLVs should set the return code of 2 ("One or more of the TLVs was not understood") in the response according to section 3 of RFC 4379. A suggested value will be given in IANA Consideration section of next version.

> the Relay Node Address Stack TLV
<Ryan>Good suggestion. IMO, in most cases, the packet length would not be exceeded by the Relay Node Address Stack TLV, thanks to the TLV procedures in each replying LSR described in section 4.2. That is the replying LSR would check the addresses of the stack in the sequence from top to bottom, to find out the first routable IP address. Then those address entried behind of the first routable IP address in the address list with K bit set to 0 would be deleted, and the address entry of replying LSR would be added. That means the addresses stack would be kept optimized by every replying LSR during traceroute process, and only those routable relay node addresses would be kept in the TLV, not all node addresses。

If the packet length was exceeded by the Relay Node Address Stack TLV unexpectablly, the TLV would be dropped and a new return code would help to notify the initiator of the situation. The case will be addressed in the next version.

<Ryan>OK. Will do.

<Ryan>Yes, correct.