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

["Henderickx, Wim (Wim)" <[e-mail]>]

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

From: Ryan Zheng [mailto:[e-mail]]
Sent: woensdag 17 oktober 2012 11:14
To: Henderickx, Wim (Wim)
Cc: [e-mail]; '[e-mail]'; [e-mail]; [e-mail]
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


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