Re: [secdir] secdir review of draft-ietf-mpls-tp-oam-analysis-08

[Tina TSOU <[e-mail]>]

Hi Nurit,
Thank u for ur reply, comments are in line.
Have a good weekend.

Sent from my iPad

On Apr 17, 2012, at 12:18 AM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]<mailto:[e-mail]>> wrote:


Tina hi,

Thank you for your review.

Please see inline.

Best regards,

Nurit



-----Original Message-----
From: ext Tina TSOU [mailto:[e-mail]]
Sent: Saturday, March 24, 2012 8:11 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: secdir review of draft-ietf-mpls-tp-oam-analysis-08



I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.



Some comments which may not be from security aspects only are below.



1) One missing OAM function



I compared the OAM functions listed in this draft and those required in RFC5860 and find out one OAM function named Client Failure Indication (Section 2.2.10 of [RFC 5860]) is missing. I cannot see a reason for this. Since this is an informational analysis document, it is recommended to give a whole view. Specific clarifications are appreciated in the document.



<Nurit> this document provides an overview of the MPLS-TP OAM tools that are specified in separate RFCs. It was agreed by the working group that the final version of this document refers to RFCs only. draft-ietf-mpls-tp-csf on “Indication of Client Failure in MPLS-TP” was expired on September 2011, hence we cannot refer to this document.

Please note also that although the name of the FILE may confuse, this document does not make any analysis but rather presents an overview of the OAM tools. The purpose of the document is carried in the document TITLE and Abstract/Introduction. \<Nurit>

If there is no RFC to refer at the moment (perhaps FFS?), you may just reflect the simple fact in the document. This is also the purpose of an overview to let people know what is done and what is missing.



I still prefer to match the analysis or overview with the requirement RFC referenced in this document.





2) Lack of analysis about the compatibility with existing tools



It is said in this document that compatibility with the existing tools has been maintained. But there is no detailed analysis which IMHO might be of great interest to the industry and should form an important part of this analysis document.



<Nurit>

As mentioned above, the purpose of the document is to provide an overview of the MPLS-TP OA tools. It is not a detailed analysis of the tools.

Still, I think your idea is excellent, and may be a subject for another I-D. \<Nurit>

OK.



3) 1.1 Scope



In the middle of this section, under the "three objectives", the first bullet reads



   o  The OAM toolset should be developed based on existing MPLS

      architecture, technology, and toolsets.



However, in the following paragraph it is written as



   o  ITU-T OAM for Ethernet toolset as defined in [Y.1731].  This has

      been used for functionality guidelines for the performance

      measurement tools that were not previously supported in MPLS.



There seem to be conflicts between the objective (should...existing MPLS....)

<Nurit> I am afraid I cannot see the conflict between the sentences….I consulted with some colleagues and they could not see the conflict as well. \<Nurit>

and the toolset development (...tools...not...supported in MPLS). [RFC 5860] says that "...the MPLS-TP design, SHOULD as far as reasonably possible, reuse existing MPLS standards." which looks more appropriate to me as the objective. Please clarify this point.

My concern is that the objective in this document is not exactly the same as in RFC5860. It is proposed to keep aligned.





4) 1.1 Scope



The third one of the "three objectives" in this draft reads



   o  The OAM toolset developed for MPLS based transport networks needs

      to be fully inter-operable with existing MPLS OAM tools as

      documented in [RFC 5860].



I may be wrong but I find [RFC 5860] only requires OAM interoperability between distinct domains (w/wo IP capabilities). The original description is as follows:



   It is REQUIRED that OAM interoperability is achieved between distinct

   domains materializing the environments described in Section 2.1.4.

My understanding of the "OAM interoperability" mentioned here refers to MPLS-TP OAM interoperable in different domains, but not MPLS-TP OAM and MPLS OAM interoperability.



<Nurit> Section 2.1.4 to which you refer in your quote, discusses the environments.

“There are environments where IP capabilities are present in the data plane.  IP/MPLS environments are examples of such environments….”.

RFC 5860 continues to require that “When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD [14]).”

\<Nurit>





5) MPLS-TP v.s. MPLS based transport networks

The draft uses both "MPLS-TP" and "MPLS based transport networks". E.g. is it "MPLS-TP OAM" or OAM toolset developed for MPLS based transport networks?

Are they the same? Or what is the relationship between them?



<Nurit> thank you for catching this. We will clarify that they are the same. \<Nurit>



Tina