[mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

[Mach Chen <[e-mail]>]

Hi,

Some comments or questions below:

1. Reverse path Connectivity verification(Section)
It says:"For bi-directional LSPs, when the egress sends the echo response, 
the egress MAY attach the target FEC stack TLV [RFC4379] in the echo
   response.  The ingress (on receipt of the echo response) can use the FEC 
stack TLV to perform reverse path connectivity verification..."
But in RFC 4379(Section 4.5), it says "...The FEC Stack TLV from the echo 
request MAY be copied to the reply...", so based on the current LSP Ping 
specification and the existing implementations, the ingress will interpret 
the FEC Stack TLV is for the forward direction LSP.
For co-routed bidirectional LSP, since the FECs for both directions are the 
same, this is OK to re-use the FEC stack TLV for reverse path CV. But for 
associated bidirectional LSP, when the ingress received the echo reponse 
with a FEC stack TLV, how does it determine whether the FEC is of the 
forward direction or backward direction?  IMHO, it's better to use separate 
FEC stack TLV for each direction, especially for associated bi-dir LSP.

2. MPLS-TP LSP trace
It seems that the current draft does not consider associated bi-directional 
LSP scenarios where each direction may follow diverse paths and some MIP 
nodes can not send echo reponse along the reverse lsp directly. So there may 
be need some return path specified mechanisms to help associated 
bidirectional LSP tracing.

Best regards,
Mach