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

[Alex Zinin <[e-mail]>]

Thanks a lot Dimitri!
-- 
Alex
http://www.psg.com/~zinin

Sunday, October 10, 2004, 10:57:54 AM, dimitri papadimitriou wrote:
> 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.
>> 
>>