Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-oam-requirements-02

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:16:57 +0200

Dear Annamaria,

thanks for your comments.
please see in-line.

regards,
-m

Annamaria Fulignoli a écrit :
> Hi all,
> below are my comments on draft-ietf-mpls-tp-oam-requirements-02
> 
> 
> 1) In all the document only generic PW is mentioned. I suggest to 
> specify at the beginning that the term PWs refers to single segment PW 
> as well as Multi segment PW

ok.
> 
> 2) Section 2.2.4 Diagnostic states
> 
>   " The MPLS-TP OAM toolset MAY provide functionality to enable the
>    conduction of diagnostic tests on a PW, LSP or Section.  An example
>    of such diagnotic test would consist in looping the traffic at an
>    Intermediate Point, back to the End Point it originates from.
>    Another example of such diagnotic test would consist in estimating
>    the bandwidth of e.g., an LSP."
> 
>   I'd rephrase as the following
>   ** The MPLS-TP OAM toolset MAY provide functionality to enable the
>    conduction of diagnostic tests on a PW, LSP or Section.  An example
>    of such diagnotic test would consist in estimating the bandwidth of 
> e.g., an LSP.
>   **
>  
>   Otherwise I don't see the difference among Diagnostic functionality 
> and  ON DEMAND CV.

I do not agree with that change. We were asked to provide examples
for that diagnostic function and looping back traffic fits well here
and comes with other examples.
I agree that looping back traffic may be a way to perform connectivity
verification but there might be other ways. Removing it from here would
contradict this, suggesting it is the way to do so.
>  
> 
> 3)  RDI,  On Demand CV,  Path Trace, two way delay measurement ,  
> require a return path. They should be applied only on bidirectional 
> (co-routed or associated) path.
> 
> In case of associated bidirectional path,  that requires  the two ME  be 
> "correlated "
> In case of unidirectional path, if a return path is associated to it for 
> the only monitoring scope, this one should be even monitored and the two
> 
> ME need to be correlated.
> Besides,  MIPs are not aware of  the association of the two 
> unidirectional path or associated bidirectional path.
> In both this case MIPs cannot be addressed by these functions; in other 
> word, on demand CV , diagnostic,  route trace,  can be addressed to MIP 
> only on bidirectional co-routed path.
> 
> I think this document should detail the  applicability scope of the OAM 
> functions.  In the previous draft version there were a useful  table 
> summarizing that ;
> 
>  I expected the information were be reported for each  functionality .

The draft in its current state is a tentative balance between functional
requirements and detailed functions descriptions. We preferred not to
give too much details which would have constrained the solution scope.
Concerning the table, it had a value but it failed to catch the
specificities of the applicability cases it listed. Further it was
agreed during a mead call to remove the table and dispatch its content
in the various sub-sections. This is what we did, even if it may be
improved, I agree.
But your comment is similar to other received and we may have to
rework the draft to address these.