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

From: Hejia <[email-masked]>
Date: Fri, 27 Jul 2012 14:07:49 +0000

I have reviewed draft-fuxh-mpls-delay-loss-te-framework-05 and have the following comments:

Is the document coherent?

It needs more work. The content is not so tightly organized which makes it hard to follow. For example:
- in Section 2, if I understand correctly, Sections 2.1, 2.4 and 2.5 are general requirements while Sections 2.2 and 2.3 are special cases which impose special requirements in addition to Sections 2.1, 2.4 and 2.5. But it is not easy to figure this out according to the current layout and description.
- Sections 3,4,5 seem to be further considerations of Section 2.4. But this is not explicitly expressed. The relationship between "end-to-end" and "accumulation" is not clear.
- It is suggested to change the "intended status" into "Informational" instead of "Standards Track". My understanding is that a framework draft is typically informational.

Is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?

I believe that the very basic idea in this document is nice but the details need to be revisited. I would also like to learn other's opinions.

In the Abstract it is claimed to "make a accurate end-to-end latency and loss prediction before a path is established." However, the discussion in the draft is based on several assumptions. How to evaluate "accurate" in this case? For example in Sections 3,4,5, it is pointed out that assumptions based on "sum" is used though it may not be perfect but the draft doesn't give convincing reasons/proof and use cases.  Besides, node latency is ignored for simplicity in the draft without setting specific restrictions. Just by saying "a small factor" is ambiguous. In fact whether the node latency could be ignored depends on a lot of factors, e.g. the number of nodes, the length of fiber, the processing and buffer size in the node, etc.

Another important issue is scalability which IMHO needs more analysis.

Is the document ready to be considered for WG adoption?

It is suggested to solve the issues above first before further consideration for WG adoption.

Nits

[draft-ietf-mpls-loss-delay] is now RFC 6374. RFC 6374 defines delay measurement no matter it is extremely low or not. The description in the introduction part "Extremely low latency measurements for MPLS LSP tunnels are defined in [draft-ietf-mpls-loss-delay]" is confusing.

Jia

发件人: Ross Callon [mailto:[email-masked]]
发送时间: 2012年7月13日 0:46
收件人: [email-masked]; [email-masked]; Hejia
抄送: Loa Andersson; George Swallow (swallow); Ross Callon; Martin Vigoureux; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; John E Drake
主题: MPLS-RT review of draft-fuxh-mpls-delay-loss-te-framework

Daniel, Stewart, and Jia;

You have been selected as an MPLS Review team reviewers for
draft-fuxh-mpls-delay-loss-te-framework

Stewart: You are not a normal member of the review team. We are hoping that
you can do a review since you are co-author of RFC 6374, and the WG chairs
are specifically interested in understanding the relationship between
draft-fuxh-mpls-delay-loss-te-framework and RFC 6374. If you are not able
to do this review at this time (do AD’s have something else to do prior to
IETF meetings?) then let us know and we will assign a different reviewer.

Note to authors: You have been CC’d on this email so that you can know that
this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is
the document technically sound?  We are interested in knowing whether the
document is ready to be considered for WG adoption (ie, it doesn’t have to
be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and secretary,
and CC’d to the MPLS WG email list. If necessary, comments may be sent
privately to only the WG chairs.

Are you able to review this draft by July 27, 2012 (ie, prior to the IETF
meeting in Vancouver)?

Thanks, Ross
(as MPLS WG chair)

---

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

Hi Daniel, 

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

Please see inline. 

Hejia <[email-masked]> 写于 2012-07-27 下午 10:07:49:

> - in Section 2, if I understand correctly, Sections 2.1, 2.4 and 2.5
> are general requirements while Sections 2.2 and 2.3 are special 
> cases which impose special requirements in addition to Sections 2.1,
> 2.4 and 2.5. But it is not easy to figure this out according to the 
> current layout and description. 
Agreed. We need to refine the requirement.

> - Sections 3,4,5 seem to be further considerations of Section 2.4. 
> But this is not explicitly expressed. The relationship between "end-
> to-end" and "accumulation" is not clear.
The intention of section 3, 4 and 5 is give a direction on how a optimal 
(or adequate) end-to-end path is computed based on LLJ TE information. In 
order to support establishment of LSPs meeting performance bounds across 
multiple domains, signaling extensions (e.g., accumulate the LLJ along 
path and verify the accumulation result) are needed since the IGP method 
used within a single domain is not sufficient.

> - It is suggested to change the "intended status" into 
> "Informational" instead of "Standards Track". My understanding is 
> that a framework draft is typically informational.
Agreed.

> 
> 
> Is it useful (ie, is it likely to be actually useful in operational 
> networks), and is the document technically sound?
> 
> I believe that the very basic idea in this document is nice but the 
> details need to be revisited. I would also like to learn other's 
opinions.
> 
> In the Abstract it is claimed to "make a accurate end-to-end latency
> and loss prediction before a path is established." However, the 
> discussion in the draft is based on several assumptions. How to 
> evaluate "accurate" in this case? 
“Accurate” isn’t quite right. "estimated" may be better.
The end-to-end latency value computed by path computation entity based on 
LLJ TE information it get is a estimated value.

> For example in Sections 3,4,5, it 
> is pointed out that assumptions based on "sum" is used though it may
> not be perfect but the draft doesn't give convincing reasons/proof 
> and use cases.  Besides, node latency is ignored for simplicity in 
> the draft without setting specific restrictions. Just by saying "a 
> small factor" is ambiguous. In fact whether the node latency could 
> be ignored depends on a lot of factors, e.g. the number of nodes, 
> the length of fiber, the processing and buffer size in the node, etc. 
We have ever discussed this for many times. If certain customers (mostly 
financials) care very deeply about nodal delay, 
the solution may provide a configuration knob to the user to let them add 
some fixed value of node to the link delay.

> Another important issue is scalability which IMHO needs more analysis. 
IGP flooding and state change frequency is one scaling limit.
Signaling may involve probing and retries since global state is not known 
at the origin.
PCE listening to each  IGP (area/level) and then communicating amongst 
each other (and potentially further level(s) of hierarchy) approximate a 
global state constraint that can reduce retries.
> consideration for WG adoption. 
Agreed.
> 
> 
> Nits
> 
> [draft-ietf-mpls-loss-delay] is now RFC 6374. RFC 6374 defines delay
> measurement no matter it is extremely low or not. The description in
> the introduction part "Extremely low latency measurements for MPLS 
> LSP tunnels are defined in [draft-ietf-mpls-loss-delay]" is confusing.
Agreed. We will delete this description.

> 抄送: Loa Andersson; George Swallow (swallow); Ross Callon; Martin 
> Vigoureux; [email-masked]; [email-masked]; dave.
> [email-masked]; [email-masked]; spencer.
> [email-masked]; [email-masked]; wang.
> [email-masked]; John E Drake