The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Hi Dan:


>Bert asked me to have a look and send any relevant comments concerning
draft-ietf-mpls-oam-requirements-02.txt. 
>I think that in general lines the document meets its goals. There are
however still issues that impact the document 
>quality and  need to be corrected before the document is further advanced.

>Content-related comments:
>1. The phrase in the Introduction - 'This memo does not, in its draft form,
specify a standard' what is this supposed to 
>mean? No I-D is a standard, but after approval will this be an
Informational RFC? (not a 'standard'. In any case this 
>phrase should be out.

OK

>2. The document uses as references several expired Internet-Drafts. This is
not acceptable, and the references should be 
>either updated, or eliminated. By the time the document will be approved as
RFC, all these references also need to be 
>RFCs, otherwise the document will be hold until normative dependencies are
being resolved.

OK

>3. Section 3.1 - examples of positive and negative false results of ICMP
need to be provided in a clear manner.

OK

>4. Should not the document say something about relationship with OAM at
other layers, and with the work being done in the >ITU, and MEF?

I think that would be useful. 

>5. Section 3.3 is quite unclear. There is no requirement here, but a list
of functions, some of them not very clear as 
>well. For example what means 'data/control plane OAM capabilities of the
LSR' and why is this part of the path 
>characterization?

I think the wording needs a bit of help (identified by Yetik as well). The
basic requirement being that there are enough data plane forwarding
variations, properly interpreting the results of a ping or traceroute
requires additional information about the path.

>6. Are 'Error detection and recovery' OAM functions, or rather functions
enabled by OAM?

I'd consider detection a function, recovery something facilitated by
detection ;-). Will consider rewording.

>7. I think that the security consideration section should include
considerations related to authentication of nodes on the >path, as well as
about possible denial of service attacks by generation of OAM traffic

I think the trust model needs some elucidation (some of this is also tackled
at a high level in the VPN security draft). I think describing the model
would also indirectly address #8.

>8. As the Security section mentions privacy concerns, should not the
requirements mention explicitly that the option of 
>protecting the traffic by using encryption is REQUIRED?

>From a technical point of view, encryption is one solution. Some form of
policy/authentication/physical security is probably a better answer, as for
example if encryption was a requirement, performing a traceroute would
require a security association with every node in the path. Having an SA
with all relevant nodes (besides issues w.r.t. scaling) would also assume
predicatable behavior which when things are broken is not necessarily true.


>Editorial comments:
>1. The I-D nits recommends to avoid using references in the Abstract
section
>2. Also in the Abstract - the acronyms VPN, SLA, and ATM are not explained,
and MPLS has an occurrence before it is 
>detailed
>3. References must be split into normative and informative sections
>4. There are two sections numbered as Sections 3
>5. As this is a requirements document, use of key-words, and reference to
RFC 2119 would be appropriate.
>6. Section 3.1, paragraph 4 - broken syntax
>7. The formatting of the document needs to be improved. For example,
spacing between paragraphs is not consistent.

Will look at the above.

>
>If you want to include me in further discussions, please address directly
the mails to me. I have un-subscribed from the 
>mpls wg list a while ago. 

Done...

thanks
Dave