Subject: [mpls] draft-li-mpls-mt-applicability-requirement-02 Comments

From: "Daniel King" <[email-masked]>
Date: Mon, 12 Sep 2011 18:47:07 +0100

Hi draft-li-mpls-mt-applicability-requirement authors, 

A great to start to an interesting area. Please find a review of
draft-li-mpls-mt-applicability-requirement-02. I have made a number of
general comments, as well as specific suggestions, and where possible
suggested text for clarity. If it would help, I can unicast a MS word
document with change modification indicators  to the current editor(s). 

1. Some of the document is rather hard to read, I suggest bulleting and
splitting some sections into sub-sections. Where possible, I have included
specific text and recommendations. 

2. Considering the document defines requirements. You might want to use
numbering for specific requirements, this will help solution developers and
they can specifically refer to requirement(s) and corresponding numbering as
necessary. 

3. There should be more emphasis on Security and Manageability
Considerations. In some cases, potential issues can be addressed by
referring to existing mechanisms. New Security and Manageability issues need
to clearly articulated, as does potential impact to network operation. 

4.  Please see specific comments, NITs and text suggestions below:

Line 8:	s/ Verison Business/ Verizon Business
Line 9:  s/ B. zhang/ B. Zhang

Line 19: I suggest further descriptive text in your abstract. Perhaps
something along the lines of:

Existing Multiple Topology (MT) technology provides a mechanism to compute
paths and direct traffic based on specific topologies. These topologies are
comprised of traffic types, links and interfaces. It would be advantageous
to extend Multiprotocol Label Switching (MPLS) to support multiple
topologies. These extensions, known as Multiprotocol Label Switching
Multiple Topology (MPLS-MT), would allow the configuration of multiple
topologies within an MPLS enabled network. 

This document describes the applicability and requirements of MPLS-MT.  The
applicability statement, use cases,  and specific requirements are presented
from the perspective of the customer (end-user), service provider and
vendors.  
<<

Line 68: Just need some constancy with  ToC. Some section headings are
capitalised, others are not. 

Line 199: This is a good introduction on the whole. I might suggest the use
of "Motivation" and "Scope" sub-sections. This would be useful for
organising the Introduction text.

Line 271:  s/ Providerprovisioned / Provider Provisioned

Line 286: s/ Multiple-Topologycan / Multiple-Topology can

Line 300:  You might want to consider the use of "Applicability" with the
addition of "Use Cases". This will help vendors with developing solutions. I
also think the initial text can be bulleted  to help with readability. 

Line 324: s/ NHLFE  / Next Hop Label Forwarding Entry (NHLFE)

Line 347: s/ subobject / sub-object

Line 355: Some minor nits with the diagram. P link, R3 interface, E-PE link
need to use lines instead of a full stop. 

Line 378: Duplicate figure name (line 367).

Line 382: s/  As stated above, MPLS-MT abstracts link state topology and
identifies it by a unique MT-ID, which need not be the same as the IGP-MT
ID. / As stated above, MPLS-MT abstracts link state topology which is
identified using a unique MT-ID. An MT-ID does not need to be the same as
the IGP-MT ID.

Line 405: General comment. I would split the section into various
sub-sections. This will help with readability and also highlight how
enhanced protection and restoration mechanisms, using MPLS-MT, can be
deployed.  

Line 408: s/ backup-mt / backup-MT

Line 411: MPLS-LDP-MT, it looks like this could be a referenced. If so, it
needs square brackets and entering as an informative or normative
references. Personally, I think you should avoid referencing potential
MPLS-MT solutions.

Line 419:  s/ undeterministic / non-deterministic

Line 423: s/ diffult / difficult

Line 426: s/ differnt / different

Line 427: s/ differnt / different

Line 463: s/ PCE / Path Computation Element. Actually are you sure the
statement is correct? The router at the domain stitching  point requires
PCC/PCE capability. If the LSP is end-to-end, then only the head-end needs
PCC/PCE capability, then it assumes the PCE performing the end-to-end path
computation has source, transit and destination domain visibility. Finally,
you might add an informative reference to relevant PCE drafts (RFC4655). 

Line 468: s/ differnt / different

Line 471: s/ singe / single

Line 477: s/ 6PE / IPv6 Provider Edge routers (6PE) and IPv6 VPN (6VPN). You
might also want to add a normative reference (RFC4798?)

Line 486: s/ gateway router,those tables / gateway router, those tables

Line 486: s/ consequentlly / consequently 

Line 489: s/ plane / IPv6 plane

Line 492: s/ intergation  / integration 

Line 493: s/ It helps to capture the data on each hop and get a thorough
view by hop by hop analyzing. /  This would also help capture data on a hop
by hop basis for further analyses.

Line 515: You start using RFC2119 terminology, if this is intended then you
will need to add the RFC2119 section/text to the start of the document. I
would also challenge the use of RFC2119 terminology for some of the
requirements, if for instance MPLS-MT services MUST have high availability
stable, how would you quantify high availability? Or perhaps provide an
informative reference to other RFCs that have definitions.  

Line 551: Just need some consistency with the use of P2P and P2MP
(point-to-point, point-to-multipoint) across the document. 

Line 578: Security. I wonder if it would be best to move this section
towards the end of the document (Security Considerations). This is also
relevant for Management requirements split across various sections, these
could be moved to a Manageability Considerations section.

Line 627: Suggest capitalising/punctuating bullet sentences. 

Line 682: s/ Diffserv / DiffServ. It would be beneficial to include some
informative references. 

Line 690: Looks to be an editor's note in the section heading. Editors notes
are fine if you want to leave them in, but you should caveat with an
additional comment . For instance: "(Editor's note to be removed before
publication - This section will include further text regarding network
resource partitioning")
 
Line 715: s/ -effective / cost-effective

Line 722: s/ MPLS -MTs / MPLS-MTs

Line 741: This section (Service Provider Capacity Sizing Projections) may
want further analyses. It's likely that  MPLS-MT will run simultaneously
with other protocols on a PE/P router. Do you want to mandate that a minimum
set of MPLS-MTs should always be supported, regardless of the size of router
(CPU/memory), etc. As performance and sizing/scalability is important you
may just want to split the relevant sections out into a new Internet Draft
that deals with  scalability and performance issues (RFC5439 - An Analysis
of Scaling Issues in MPLS-TE Core Networks, et al.). With further
quantitative analysis and demonstrable findings, specific recommendations or
requirements can be made. 

Line 767: s/ multiprovider / multi-provider

Line  818: As mentioned earlier, I think the Manageability Considerations
section should be added to the document and the relevant sections moved to
this new section. 

Line 855: You need to be careful with the use of "real-time" as it's a
relative term and subjective to each person. 

Line 927: s/ singleprovider / single-provider

---

From: "Huang Lu" <[email-masked]>
Date: Tue, 20 Sep 2011 18:50:15 +0800

Hi Dan, 

Thanks for your review and comments. 

We will need a few days to review your suggestions then we will respond to specific points as needed.

2011-09-16 

Best Regards!

Lu Huang
Research Institute of China Mobile
Floor 11, Door 2, Dacheng Plaza
No.28 Xuanwumen West Ave, Xuanwu District
Beijing 100053, China
Phone:  +86 10-15801696688-3287
Mobile: +86 13810820540
Email:  [email-masked]

---

From: "Huang Lu" <[email-masked]>
Date: Fri, 16 Sep 2011 10:55:14 +0800

Hi Dan, 

2011-09-16 

Best Regards!

Lu Huang