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

Hi Mach,

On 6/21/10 8:47 PM, "Mach Chen" <mach@huawei.com> wrote:
> 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.

You are right that there might be some confusion. I'll look into this.

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

In non-error cases, I believe all MIPs should be able to send the response
back on the reverse lsp path. In error cases, a MIP might be unable to send
the response (because of the fault). In such a case, the first MIP which is
unable to send the response back is the MIP where the fault is. The spec
currently says that we must reply using application control channel. We can
make that a should, so that if one wants, one can ask that the reply be sent
via UDP....if there is another available path in the network.

Thanks
Nitin

P.S: Please cc: one of the authors always, so that it's easier to dig
through the incoming email flood.

> Best regards,
> Mach
>  
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp