Subject: Re: [mpls] Reminder; RE: MPLS-RT review of draft-fuxh-mpls-delay-loss-te-framework

From: "Daniel King" <[email-masked]>
Date: Fri, 27 Jul 2012 20:41:55 +0100

Hi All, 

Please find my review of draft-fuxh-mpls-delay-loss-te-framework-05. 

General Comments

- The document would benefit from a Terminology/Acronym section. Some lesser
known acronyms are used and not expanded on. 
- We already have a set of existing tools to measure and report network
conditions (including RFC6374). It may be worth summarizing these in the
introduction to help identify gaps and provide further motivation for the
work.    
- Please check the use of capitals for section titles. Use them or do not
use them, just be consistent for all sections names.
- Check the use of Requirements Language in the document, it seems
inconsistent for some of the requirements. 
- The document is tough to read, perhaps down to the number of authors
providing sections of text. The document would benefit from 1-2 editors who
would interpret and translate text and requirements from the other authors,
and improve the readability of the document. 
- Management and Operational considerations/requirements also need to be
discussed and documented. 
- At least one requirement seems to mandate the development of an algorithm,
which might be vendor specific factor.   

1. What is the intention of this document? Currently, it is a combination of
a Framework, Requirements with Solution details. This is very confusing for
the reader and generally not how to write a good IETF document. I think the
authors should remove protocol and procedure details and focusing on
describing the technical aspects of the applications and requirements.
Thereby allowing a separate solution(s) documents to be created (detailing
measurement attributes, message format, procedures, operation, et al) ,
without biasing the solution or confusing the reader.  This would also allow
further solution documents to be spun out into other working groups, PCE
springs to mind when I read the draft. Of course, no point in trying to
bring PCEP extensions to the PCE WG until the dependent protocol extensions
have been agreed and are reasonably stable.   

2. Abstract. Less is more, the abstract should briefly and succinctly
summarize the document. For instance, assuming this will be the requirements
document (Intended Status should also be changed to Informational, from
Standards Track:

Deployment and usage of cloud based applications and services that use an
underlying MPLS network are expanding, the distances between the user and
the application are increasing, and applications are extremely sensitive to
delay and packet loss. Existing mechanisms exist to measure and monitor MPLS
path performance metrics for packet loss and delay, but only after the path
has been setup. It would be beneficial for MPLS network and potential path
information to be measured for the computation of services used to carry
cloud based and delay sensitive applications. 

This document provides a technical overview of application and requirements
to enable the efficient and accurate measurement of the MPLS network and
allow new performance metrics to be reported and used in the computation of
MPLS services. 

3. Introduction

Too short, I think it should provide a clearer background and motivation for
the document. A subsection defining the scope of the document would also be
beneficial. 

4. Architecture Requirements 

Perhaps this section would benefit if the authors provide an application
summary and bullet list of requirements (R1, R2, R3, etc.) this would help a
solution document clearly define which requirements it meets/solves. Also if
a vendor implements they can clearly state full compliance, or partial
compliance, a valid comment for a separate solution(s) documents as well. 

The requirements are rather broad, are they all really needed? It seems some
may be corner-cases. Again by having separate solution documents it would
allow for a solution to be developed to solve general requirements
(progressed as Standards Track) and then small corner-case solutions
(progressed as Experimental). 

The document makes far too many assumptions regarding the ability of
devices/nodes to have the capability to measure its own performance and
reported. Also the document suddenly jumps from defining requirements to
report MPLS network performance for new services, to mandating that once a
service has been setup it should be rerouted " when the end-to-end metrics
changes in a way it becomes more then desired". I think my advice here is to
keep things simple and try to focus on a specific set of use cases to solve
customers' existing problems.  

Summary

Once you decode the document it's an interesting read and I understand the
general motivation behind the work, although the uses cases would benefit
from further evidence. Currently the document is not ready for working
adoption. The document should look to clearly state its intention as a
requirements document. The current use cases need to be developed, general
uses cases expanded further and clarified, and special uses cases removed or
clearly separated. 

If it helps I would be happy to provide further assistance or clarifications
as to my comments to the authors either on or off the list. 

Br, Dan.

---

From: [email-masked]
Date: Mon, 30 Jul 2012 12:27:34 +0800

Hi Daniel,

Thanks for your review. Authors drafted the response for your comments.

Please see inline.

> known acronyms are used and not expanded on. 
Agreed. We will do that.

> introduction to help identify gaps and provide further motivation for 
the
Agreed. RFC6374 provides the mechanism to measure end-to-end LLJ after LSP 
is established. The LLJ can only be measured after the connection has been 
established, if the measurement indicates that the latency SLA is not met 
then another path is computed, set up and measured. This “trial and error
” process is inefficient. To avoid this problem a means of making an 
prediction of LLJ before a path is establish is required. This is the main 
intention of our draft.

> use them, just be consistent for all sections names.
Agreed. We will use capital for all section titles.

> inconsistent for some of the requirements. 
Agreed. We will check it.

> and improve the readability of the document. 
Agreed. 

> which might be vendor specific factor. 
Can you please identify which requirement(s) to which this could apply? We 
suggest to ignore the LLJ of node in this draft, the network operator will 
insist that the vendor provides accurate LLJ information of network 
element for more accurate end-to-end LLJ prediction. For example, the 
minimum delay may be vendor specific factor of network element. Solution 
should provide a configuration knob to the user to let them add some fixed 
value of node to the link delay.
> have been agreed and are reasonably stable. 
Agreed. We need to refine the section “Control Plane Implication” and 
remove protocol and procedure details.

> document (Intended Status should also be changed to Informational, from
Agreed. We will refine the Abstract. We may need requirement and 
framework, both of them should be Informational and detail solution could 
be Standards Track.

> the document. A subsection defining the scope of the document would also 
be
Agreed. We will add a subsection according to your suggestion.

> compliance, a valid comment for a separate solution(s) documents as 
well. 
Good suggestion.

> 
> The requirements are rather broad, are they all really needed? 
As part of above process can state what is mandatory versus desirable and 
optional.
> It seems some may be corner-cases. Again by having separate solution 
documents it would
> (progressed as Experimental). 
Again. We may need requirement and framework draft separately.

> reported. 
Good point.

> Also the document suddenly jumps from defining requirements to
* Attempt to ensure that LSP will meet performance measurement before it 
is established.
* If measurements indicate objective is not met, repeat process.

> from further evidence. 
Good point, this seems similar to what Stewart is asking in terms of 
"proof."

> Currently the document is not ready for working
> requirements document. 
Agreed. 

> The current use cases need to be developed, general
Good suggestion.

> as to my comments to the authors either on or off the list. 
Thank you, your expert assistance would be greatly appreciated.