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

[Ryan Zheng<[e-mail]>]

Hi Wim,

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

Best Regards,
Ryan


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

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

> 2. Describe the behavior if the packet length would be exceeded by 
> 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.