Subject: draft-so-yong-rtgwg-cl-framework

From: Iftekhar Hussain <[email-masked]>
Date: Fri, 27 Apr 2012 21:55:13 +0000

Dear  Authors,

Please find below some comments on the http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05.

----------------------------
2.1. Flow Identification
"Operator may have other objectives such as ...composite link energy saving, and etc. These new requirements are described in [I-D.ietf-rtgwg-cl-requirement]"
Comment:
I don't recall any energy saving related requirement (or discussion) in the [I-D.ietf-rtgwg-cl-requirement.  Suggest removing the text "energy saving etc."

2.2. Composite Link in Control Plane
"LDP follows the IGP, therefore failure to forward on  the IGP path will often result in loss of connectivity if the IGP adjacency is not withdrawn when an LDP FEC is refused.  This is a pathologic case that can occur if LDP is carried natively and there is a high volume of LDP traffic.  This situation can be avoided by carrying LDP within RSVP-TE LSP."

Comment:
Is it the loss of connectivity referring to LDP control plane connectivity only or LDP signaled LSP data plane or both?

Comment:
"Composite link capacity is aggregated capacity and MAY be larger than individual component link capacity."
Composite link aggregate capacity should always be larger than individual component link capacity. Did I misunderstand?

"...1. If no other information is available the largest microflow is bound by one of the following:"
Suggested text:
If no other information is available the largest microflow is bound (i.e., signaling extensions don't indicate a bound) by one of the following:

Comment:
Section 2.2 provides architectural guidelines e.g., "  ...Available capacity in other component links MUST be used to carry impacted traffic.  The available bandwidth after failure MUST be advertised immediately to avoid looped crankback" and provides illustrative examples e.g.,"... no microflow larger than 10 Gb/s will be present on the RSVP-TE LSP that aggregate traffic across the core, even if the core interfaces are 100 Gb/s interfaces."
In contrast, section 2.1 appears to be little bit too vague e.g., " ... technique of grouping flows, such as hashing on the flow identification criteria, becomes essential to reduce the stored state, and is an essential scaling technique.  Other means of grouping flows may be possible"
Suggestion:
Add some examples which flow identification scheme to use for composite links or add a reference to section 4.2 which discusses flow identification trade-offs.

4.1.4. Requirements for Contained LSP
Comment:
Add reference to specific relevant to requirements in I-D.ietf-rtgwg-cl-requirement] similar to section 4.1.2 and 4.1.3.

4.2. Data Plane Challenges
Comment:
Minor typo: "very course..." should be "very coarse..."
Comment:
"In practice  using the MPLS label stack alone has proven too course to acheive a reasonably good load balance, due to bin-packing issues and discrpencies between signaled bandwidth and actual traffic loads on LSP."
Suggest adding a reference to an IETF standard or best practices document that discusses these issues.

Comment:
Sections 4.2, 2.1, 2.3, appear to be somewhat redundant. Suggest trimming section 2.1 and absorbing that information in section 4.2.

3. Architecture Tradeoffs
Comment:
"Composite Link is applicable to large networks, and therefore scalability must be a major consideration."
What is a typical definition of a large network?  Suggestion: Add an example (or a forward reference to section 3.3.1 which has an example)

3.1. Scalability Motivations
Comment:
"....a large routing change to be accomplished more quickly,"
What is a typical definition of a large routing change?  Suggestion: Add an example.

7.2.5. Dynamic Multipath Balance
Comment:
"...uses a course granularity, the adjustments would have to be equally  course, in the worst case moving entire LSP"
Minor typo "course" should be "coarse".

7. Required Protocol Extensions and Mechanisms
Comment/suggestion:
Organizing section 7 as  a matrix containing something like: Requirement#, Existing Mechanisms, Gaps, Ongoing/new extensions..., might be more clearer. AT a minimum, add a traceability to each requirement in [I-D.ietf-rtgwg-cl-requirement] and the section number in framework document that addresses each requirement (or set of requirement).

Is there a minimal set of requirements which must be met to form a deployable (useful) composite link based solution?

-----------------------

Regards,
Iftekhar