Re: rtg-dir review: dpapadimitriou, prz: draft-ietf-mpls-oam-requirements-04.txt

[dimitri papadimitriou <[e-mail]>]

hi alex, you will find here below my comments on the above referenced 
document 1) Technical and 2) Editorial - see below:

1) Technical
------------

0. Section 3

"This leads to inconsistent and inefficient applicability across the 
MPLS architecture, and/or requires significant modifications to 
operational procedures and systems in order to provide consistent
and useful OAM functionality."

-> How to ensure that the proposed OAM techniques will not create more 
inconsistencies than those apparently occurring with the existing ad hoc 
methods/solutions (those that are not currently part of the proposed 
framework) - as a matter of fact these techniques are already deployed ?

1. Section 4.1

Distinction between failure and defect is not clearly reflected, it is 
therefore difficult to understand the requirement behind detection of a 
"broken LSP"

2. Section 4.1

In the sentence "... this function SHOULD be automated and performed 
from the origination of that LSP." does not say until which point this 
operation has to be performed

3. Section 4.1

The sentence "As an example of a false positive, consider the case where 
the MPLS data plane flows through a network node using a different 
output line card than the data plane does to each the next neighbor." is 
mispelled which understanding of the false positive difficult as per 
[LSP-PING] "MPLS echo request are sent along the same data path as other 
packets belonging to this FEC. An MPLS echo request also carries 
information about the FEC whose MPLS path is being verified.  This echo 
request is forwarded just like any other packet belonging to that FEC. 
In "ping" mode (basic connectivity check), the packet should reach the 
end of the path, at which point it is sent to the control plane of the 
egress LSR, which then verifies whether it is indeed an egress for the FEC."

4. Section 4.1

Is there any specific requirement for the return path of unidirectional 
LSPs to avoid "false negative" ? as this is not explicitly mentioned as 
part of this section

5. Section 4.2

The sentence "... and any mid-point LSR" does not specify what has to be 
traced inlight with the above statement "Diagnosis of defects and 
isolation of the failed component is best accomplished via a path trace 
function which can return the the entire list of LSRs and links used by 
a certain LSP (or at least the set of LSRs/links up to the location of 
the defect) is required."

6. Section 4.3

Second bullet mentions "externally visible aspects" and then points to 
"specific algorithms" - the term "externally visible" should thus refer 
to what "external" refers to ?

7. Section 4.4

This section dedicated to "performance measurement" requires more 
specific i.e. more formal definition of LSP availability (than "service 
is considered to be available")

There is no specific reference to the "one-hop delay" experienced by 
labeled packets (that included the switching delay and the transmission 
delay) and "queuing/buffering delay" creates variation in the delay 
experienced by labeled packets - more accurate definitions could thus be 
provided to describe the exact OAM&P mechanism to be supported (example 
there are several methods to take the jitter into account)

In the sentence "... so as to accurately reflect the latency ..." what 
is the expected measurement accuracy expected as part of the present 
requirements ?

8. Section 4.5

The following sentence "The capability to synchronize OAM operations is 
desired as to permit consistent measurement of service level 
agreements." should be more prescriptive than "is desired" does it mean 
optional and this synchronization is not available how it impacts the 
overall OAM operations

9. Section 4.5 (Alarm Suppression)

To what the term "device" is referring here ? The relationship between 
the reduction of the "emitted notifications" and the "fault 
notifications" flowing to the LSP egress is not described ?

10. Section 4.7

This section does not detail what is the object of the failure and the 
subject of the recovery ? nor the scope of the requirement - does it 
apply on inter-provider basis (ingress and egress belonging to separate 
networks)

2) Editorial
------------

0. As the document has less than 15/20 pages a ToC is not required but 
if one ToC is included suggestion is made to complete it with sub-sections

1. Section 2.

This section should better be split into a "Terminology" section that 
includes conceptual overview of the terms used in the document (some
of them can be more accurately defined as part of the document) and a 
"Abbreviation and Acronyms" section

2. Section 2.

The term "head-end LSR" is introduced but the core of the document make 
use of the terms "ingress LSR" are these equivalent ? or different ?
-> suggestion is made (if they are equivalent) to use a single 
terminology either ingress/egress LSR or head-end/tail-end LSR

3. Section 3.

Spell out acronyms RSVP (isn't RVSP-TE ?) and LDP

4. Section 4.1

The term "path liveliness" has not been defined in Section 2/referenced
The term "LSP problem" has not been defined in Section 2/referenced

5. Section 4.1

Add reference to ICMP-based Ping

6. Section 4.2

Sentence "The tracing capability SHOULD include the ability to trace 
recursive paths, such as when nested LSPs are used, or when LSPs enter 
and exit traffic-engineered tunnels" is the latter case not covered by 
the previous one ?

7. Section 4.3

Is the first bullet (TTL models) meant to address RFC 3443 - in this 
case suggestion is made to add this RFC as reference

what the "data/control plane OAM capabilities" means ? this would 
clarify the scope of the sentence

8. Section 4.4

suggestion is made to clarify the sentence "measure the qualitative 
aspects of OAM probing" and define the term "OAM probing"

9. Section 4.5 numbering appears twice

10. Section 4.6

Spell out AIS acronym and include as part of the "Abbreviation" section

11. Section 4.9

Include DoS acronym as part of the "Abbreviation" section

"control planes" instead of "control plaes"

12. Section 4.10

Include SP acronym as part of the "Abbreviation" section

"information"  instead of "informationr"

"inter-AS" instead of "inter-as"

13. Section 4.10.1

"For example, the LSR might ..." is meant for "For example, the LSR MAY 
..." ?

what the etc. stands for that other methods exist or what's described is 
only part of the process ?

---

Alex Zinin wrote:
> Loa asked me for an early rtg-dir review of this draft.
> 
> skill-specific: dimitri
> round-robin: tony
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-04.txt
> 
> 
>>        Title           : OAM Requirements for MPLS Networks
>>        Author(s)       : T. Nadeau, et al.
>>        Filename        : draft-ietf-mpls-oam-requirements-04.txt
>>        Pages           : 13
>>        Date            : 2004-9-2
>>        
>>As transport of diverse traffic types such as voice, frame
>>   relay, and ATM over MPLS become more common, the ability to detect, 
>>   handle and diagnose control and data plane defects becomes 
>>   critical. 
>>
>>   Detection and specification of how to handle those defects is not 
>>   only important because such defects may not only affect the 
>>   fundamental operation of an Multi-Protocol Label Switching network, 
>>   but also because they MAY impact service level specification    
>>   commitments for customers of that network.
> 
>