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

[Mach Chen <[e-mail]>]

Hi Riccardo,

Thanks for your prompt response!

I agree with the return path issue that you pointed out, and this is also my 
concern about how this problem could be handled by the draft. This issue is 
related not only to associated bidirectional LSP, but to unidirectional LSP 
and P2MP LSP that may also have no in-band return path. I personally believe 
that some mechanisms are needed to reslove the return path issue.

Best regards,
Mach



--------------------------------------------------
From: "Riccardo Martinotti" <[e-mail]>
Sent: Tuesday, June 22, 2010 12:13 PM
To: "Mach Chen" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

> Dear Mach,
> Please see inline a comment to your point 2 (I just stripped the other 
> point from the body).
>
> Regards,
> Riccardo
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Mach Chen
> Sent: martedì 22 giugno 2010 11.48
> To: [e-mail]
> Subject: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00
>
>
> Hi,
>
> Some comments or questions below:
>
> 1. [...]
>
> 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.
>
> RM> Use of MIP for on demand CV in case of associated bi-directional LSP 
> may be of less use, because in case an echo reply is not received by the 
> MEP (which sent the echo request) it is not possible to know whether the 
> problem is related to the LSP being monitored or to the return path.
>
> Best regards,
> Mach
>
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp