Subject: [mpls-tp] Last call coments on draft-ietf-mpls-tp-requirements-04.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Feb 2009 13:53:36 -0000

Hi,

Earlier today, some members of Old Dog Consulting's transport and
packet teams conducted a review of draft-ietf-mpls-tp-requirements-04.
Our requested and suggested changes are shown below.

Thanks,
Adrian

===
Requirements Language

Please delete this text. You have better language in Section 1.

===
1.  Introduction

   For many years, transport networks (e.g.  Synchronous Optical
s/e.g./e.g.,/
   Networking (SONET)/Synchronous Digital hierarchy (SDH)) have provided
s/hierarchy/Hierarchy/
   carriers with a high benchmark for reliability and operational
   simplicity.  With the accelerating growth and penetration of:

===
1.  Introduction

   Carriers will still need to cope with legacy networks (which are
   composed of many layers and technologies), thus the packet transport
   network should interwork as appropriate with other packet and
   transport networks

COMMENT: "...as appropriate..." ? Maybe just delete?

   (both horizontally and vertically).  Vertical
   interworking is also known as client/server or network interworking.
   Horizontal interworking is also known as peer-partition or service
   interworking.  For more details on each type of interworking and some
   of the issues that may arise (especially with horizontal
   interworking) see Y.1401 [ITU.Y1401.2008].

COMMENT: This section appears to announce requirements, but I don't see
them drawn out in the document. Furthermore, I would hotly debate the
need for horizontal interworking at a technology level.

===
1.  Introduction

   with transport network operations.  There is therefore the need to
   define an MPLS Transport Profile (MPLS-TP) in order to support the
s/in order to support/that supports/

===
1.  Introduction

   This document is a product of a joint ITU-IETF effort to include an
s/ITU-IETF/ITU-T and IETF/

===
1.1.  Terminology

   Bidirectional path: A path where the forward and backward directions
   follow the same route (links and nodes) across the network.
COMMENT: Not comfortable with the existence of this definition.
a. It seems redundant with  "co-routed bidirectional path"
b. It confuses the definition of "associated bidirectional path"
Suggest either:
- we don't need this definition and that we need to be globally fix
  all refs to be either co-routed or associated
or
- we loosen this to be a generic definition that encompasses both
  co-routed and associated (to allow us to use the general term when
  we don't care.

===
1.1.  Terminology

   Concatenated Segment: A serial-compound link connection as defined in
   G.805 [ITU.G805.2000].  A concatenated segment is a contiguous part
   of an LSP or multi-segment PW that comprises a set of segments and
   their interconnecting nodes in sequence.
ADD: See also "Segment".

===
1.1.  Terminology

   Co-routed bidirectional path: A bidirectional path where the forward
   and backward directions follow the same route (links and nodes)
   across its layer network.
COMMENT: "...its..." ?  s/its/the same/ ?

COMMENT: This is slightly interesting because it means that if a
bidirectional link between two adjacent nodes is made up of a
collection (LAG, bundle, etc.) of lower layer links, there is no
requirement for the co-routed path to use the same component links
in both directions. Is this the intent of the definition?

===
1.1.  Terminology

   network, depending on the actions it takes on the encapsulation(s)
s/encapsulation(s)/encapsulations/

===
1.1.  Terminology

   could be modeled as multiple logical elements.  A layer network may
   consist of zero or more sublayers.
COMMENT: Trying to think of a layer that contains no sub-layers. Seems
to me that the minimal case is that the layer is the sub-layer?

===
1.1.  Terminology

   Link: A physical or logical connection between a pair of LSRs that
   are adjacent at the (sub)layer network under consideration.  A link
   may carry zero, one or more LSPs or PWs.  A packet entering a link
   will emerge with the same label stack entry values.
COMMENT: Need to expand acronyms on first use. LSR, LSP, PW.

===
1.1.  Terminology

   Path: See Transport path.
s/path/Path/

===
1.1.  Terminology

   Ring Topology: In an MPLS-TP ring topology each LSR is connected to
   exactly two other LSRs, each via a single point-to-point
   bidirectional MPLS-TP capable data link.  A ring may also be
COMMENT: I think, according to your definition of "link" we can strike
the word "data".
COMMENT: Why do we require that a ring topology is constructed from
bidirectional links? If we allow unidirectional links, we should allow
- unidirectional ring topology where at least one of the links is
  unidirectional and there is connectivity around the ring in one
  direction
- bidirectional ring topology where all links are bidirectional and
  there is connectivity around the ring in both directions

===
1.1.  Terminology

   Section: A section is a server layer (which may be MPLS-TP or a
   different technology) which provides for encapsulation and OAM of a
   MPLS-TP transport path client layer.  A section layer may provide for
COMMENT: "...transport path client layer..."/ ?
"transport path in the client layer"?
"client layer transport path"?
"client layer"?
"transport path"?

COMMENT: Do we mean "Section" or "Section Layer"?

===
1.1.  Terminology

   Segment: A link connection as defined in G.805 [ITU.G805.2000].  A
   segment is the part of an LSP that traverses a single link or the
   part of a PW that traverses a single link (i.e. that connects a pair
   of adjacent {S|T}-PEs).
ADD: See also "Concatenated Segment."

===
1.1.  Terminology

   Transport path: A network connection as defined in G.805
s/path/Path/

===
1.1.  Terminology

   Transport path layer: A layer network which provides point-to-point
s/which/that/
   or point-to-multipoint transport paths which are used to carry a
s/which are/that may be/
   higher (client) layer network or aggregates of higher (client) layer
   networks, for example the transport service layer.  It provides for
   independent OAM (of the client OAM) in the transport of the clients.
COMMENT: Something wrong with that last sentence.

===
1.1.  Terminology

   Transport service layer: A layer network in which transport paths are
s/which/that/

===
1.1.  Terminology

   Transmission media layer: A layer network which provides sections
s/which/that/

===
1.2.  Transport network overview

   Quality-of-service mechanisms are required in the packet transport
   network to ensure the prioritization of critical services, to
   guarantee BW and to control jitter and delay.
s/BW/bandwidth/

===
1.3.  Layer network overview

   A layer network will have common features in order to support the
COMMENT: Common to what? "consistent"?

   control of forwarding, resource reservation, and OAM.  For example, a
   layer network will have a common addressing scheme for the end points
COMMENT: ditto

===
1.3.  Layer network overview

   It is sometimes useful to independently monitor a smaller domain
   within a layer network (or the transport services as the traverse
s/as the/that/
   this smaller domain) but the control of forwarding or the control of
   resource reservation involved retain their common elements.  These
   smaller monitored domains are sublayers.
COMMENT: Are they? Surely smaller monitored domains may be peer
sub-domains such as routing areas, proteciotn domains, or MEs.

   It is sometimes useful to independently control forwarding within
   smaller domain within a layer network but the control of resource
s/smaller/a smaller/
   reservation and OAM retain their common elements.  These smaller
   domains are partitions of the layer network.
COMMENT: That is the better definition.

===
2.  MPLS-TP Requirements

COMMENT: Can you restate the scope of these requirements as applying to
the toolkit not the implementation. I think this is repeatedly 
misunderstood, and restating it here may help it to be noticed.

===
2.1.  General requirements

   3   Mechanisms and capabilities MUST be able to interoperate, without
       a gateway function, with existing IETF MPLS [RFC3031] and IETF
       PWE3 [RFC3985] control and data planes where appropriate.
COMMENT: I think it would be beneficial to expand upon "interoperate".
It is clear to me that there is no requirement for an MPLS-TP node to
peer (horizontally at an I-NNI) in the control plane with an MPLS node.

   4   MPLS-TP and its interfaces, both internal and external, MUST be
       sufficiently well-defined that interworking equipment supplied by
       multiple vendors will be possible both within a single network,
       and between networks.
COMMENT: Is "network" in this context a "domain" in terms of your
definitions?

===
2.2.  Layering requirements

   20  A generic and extensible solution MUST be provided to support the
       transport of one or more client layer networks (e.g.  MPLS-TP,
       Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
COMMENT: Are your example client layer networks delibertately packet
technologies? Would it be valuable to list IP and MPLS in the examples?

===
2.2.  Layering requirements

   The above are not only technology requirements, but also operational.
s/operational/operational requirements/

===
2.3.  Data plane requirements

   25  The identification of each transport path within its aggregate
       MUST be supported.
COMMENT: Is this *really* the requirement? It says that when you have an
aggregate is must be possible to look inside it and identify the 
aggregated transport paths. I don't like the "deep packet inspection"
implications! I think what you want is a reliable mechanism to perform
deagregation back to the same transport paths with the same level of
identification, when the end of the aggregation vessel is reached. I
believe it is important to state our real requirements, not some
similar requirement that might be solution-dependent.

COMMENT: "...its aggregate..." is rather non-specific. I suspect you
are refering to an MPLS-TP aggregate, not an aggregate into another
technology.

   26  A label in a particular link MUST uniquely identify the transport
       path within that link.
COMMENT: I think this requirement is back-to-front. We also use labels
for other purposes on a link. That means saying something like...
A transport path on a link MUST be uniquely identifiable by a single
label on that link.

COMMENT: I also think that we need to be clearer
on which label we are refering to, and (in the context of 25) whether
we mean the "transport path" or the "aggregate transport path", etc.

s/in/on/?
s/within/on/?

   27  A transport path's source MUST be identifiable at its destination
       within its layer network.
COMMENT: This is stated as a data plane requirement. That means that 
this requirement MUST be met without recourse to the management plane or
the control plane. I do not believe that this is a data plane
requirement. And I think it should be removed.

   28  MPLS-TP MUST be capable of using P2MP server (sub-)layer
       capabilities when supporting P2MP MPLS-TP transport paths (for
       example context-specific labels [RFC5331]).
COMMENT: I still believe that providing an example solution in the
requirements document is wrong. Note that RFC 5331 is a solution not
as example of a server capability. I propose to delete the example.

   29  It MUST be possible to operate and configure the MPLS-TP data
       (transport) plane without any IP forwarding capability in the
       MPLS-TP data plane.
COMMENT: I think this is a management plane and/or control plane
requirement, not a data plane requirement. The text may be...
The MPLS-TP data plane MUST support transmission and forwarding of
packets with MPLS headers. No assumptions are made about the ability
of the data plane to support forwarding of other technologies such
as IP.

DELETE/(transport)/

   30  MPLS-TP MUST support unidirectional, bidirectional and co-routed
       bidirectional point-to-point transport paths.
s/unidirectional, bidirectional/unidirecitonal, associated bidirectional/

   31  The forward and backward directions of a co-routed bidirectional
       transport path MUST follow the same links and nodes within its
       (sub-)layer network.
COMMENT: Delete this requirement. It is the definition of co-routed
bidirectional.

   32  The intermediate nodes at each (sub-)layer MUST be aware about
       the pairing relationship of the forward and the backward
       directions belonging to the same bidirectional transport path.
COMMENT: This requirement is achievable for co-routed bidirectional,
but conflicts with the definition of associated bidirectional. Even
if the definition were fixed, this would clearly not be achievable
where the associated bidirecitonal LSP is diversely routed.

   33  MPLS-TP MAY support transport paths with asymmetric bandwidth
s/transport paths/bidirectional transport paths/

   36  MPLS-TP SHOULD support mechanisms to enable the reserved
       bandwidth associated with a transport path to be increased
       without impacting the existing traffic on that transport path
s/path/path./

===
2.4.  Control plane requirements

   This section defines the requirements that apply to MPLS-TP when a
   control plane is deployed.
COMMENT: Suggest this has nothing to do with deployment. How about...

   This section defines the requirements that apply to an MPLS-TP 
   control plane. Note that it MUST be possible to operate an MPLS-TP
   network without using the control plane.

===
2.4.  Control plane requirements

   41  The MPLS-TP control pane SHOULD support control plane topology
s/pane/plane/

   44  The MPLS-TP control pane MUST support the configuration and
s/pane/plane/
It really is a pain.

===
2.5.  Network Management (NM) requirements

   For requirements related to NM functionality (Management Plane in
   ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements
   document [I-D.gray-mpls-tp-nm-req].
COMMENT: Have we considered that making this a normative reference means
that this I-D cannot progrss until that one has?

===
2.6.  Operation, Administration and Maintenance (OAM) requirements

   For requirements related to OAM functionality for MPLS-TP, see the
   MPLS-TP OAM requirements document
   [I-D.ietf-mpls-tp-oam-requirements].
COMMENT: Ditto

===
2.7.  Network performance management (PM) requirements

   For requirements related to PM functionality for MPLS-TP, see the
   MPLS-TP OAM requirements document
   [I-D.ietf-mpls-tp-oam-requirements].
COMMENT: Ditto

===
2.8.  Recovery & Survivability requirements

   48  MPLS-TP recovery mechanisms MUST be applicable at various levels
       throughout the network including support for link, path segment
       and end-to-end path, and pseudowire segment, and end-to-end
       pseudowire recovery.
COMMENT: Can we rewrite this in terms of the language defined in 
section 1.1? This would simplify to...
   48  MPLS-TP recovery mechanisms MUST be applicable at various levels
       throughout the network including support for link, segment,
       concatenated segment, and end-to-end recovery.

   51  The recovery mechanisms MUST operate in synergy with (including
       coordination of timing) the recovery mechanisms present in any
       underlying server transport network (for example, Ethernet, SDH,
       OTN, WDM) to avoid race conditions between the layers.
COMMENT: Isn't there a complementary requirement for recovery mechanisms
in client networks?

===
2.8.1.1.  Protection

   54  MPLS-TP MUST support 1+1 protection.

       C.  Unidirectional 1+1 protection for P2P connectivity is not
           required.
s.not required/NOT REQUIRED/

   55  MPLS-TP MUST support 1:n protection (including 1:1 protection).

       C.  Unidirectional 1:n protection for P2P connectivity is not
           required.
s/not required/NOT REQUIRED/

   Note: Support for extra traffic (as defined in G.870 [ITU.G870.2008])
   is not required in MPLS-TP.
s/not required/NOT REQUIRED/
COMMENT: I prefer that we retain the core reference within the IETF
where possible. Extra traffic is defined in RFC4427. Is there a problem
with that definition?

===
2.8.1.2.  Restoration

   56  The restoration LSP MUST be able to share resources with the LSP
       being replaced (sometimes known as soft rerouting).
s/LSP/transport path/ ?

===
2.8.1.3.  Sharing of protection resources

   60  MPLS-TP MUST support the sharing of protection bandwidth by
       allowing best effort traffic.
COMMENT: I assume that this means that the best effort traffic uses
the proteciton resources when they are not carrying protected traffic.
If so, how is this different from "extra traffic" that we have classed
as "not required" in section 2.8.1.1?
But perhaps it means that the protected traffic will only be delivered
as best effort after a failure. If so, this is defining a protection
class.

   62  MPLS-TP MUST support sharing of protection resources such that
       protection paths that are known not to be required concurrently
       can share the same resources.
COMMENT: How does this differ from the requirement for shared mesh
restoration in requirement 59?

===
2.8.2.  Triggers for protection, restoration, and reversion

   68  There MUST be a mechanism to allow administrative recovery
       actions to be distinguished from recovery actions initiated by
       other triggers.
COMMENT: Distinguished where in the network, when, and by whom?
"The passive voice is to be avoided"

===
2.8.3.  Management plane operation of protection and restoration

   70  It MUST be possible to configure of protection paths and
DELETE/of/

   76  When preemption is supported for recovery purposes, it MUST be
       possible for the operator to configure it.
s/recovery/restoration/

===
2.8.4.  Control plane and in-band OAM operation of recovery

   79  The MPLS-TP control plane (which is not mandatory in an MPLS-TP
       implementation) MUST support:

       C.  protection state coordination (PSC)
Suggest delete /(PSC)/ as it is not used in the document.

===
2.8.5.1.  Ring protection

   Within the context of recovery in MPLS-TP networks, the optimization
   criteria considered in ring topologies are as follows:

   d.  Minimize the amount of management plane transactions during a
       maintenance operation (e.g., ring upgrade) - less than are
       required by other recovery mechanisms.
COMMENT: Is there no equivalent optimization of control plane?

===
2.9.  QoS requirements

   105  Prioritization of critical services.
COMMENT: I believe this is open to be misconstrued. 
1. Who cares whether the service is critical?
2. What does "prioritization" actually mean? Is it priority of
access to resources?

===
2.10.  Security requirements

   For a description of the security threats relevant in the context of
   MPLS and GMPLS and the defensive techniques to combat those threats
   see the Security Framework for MPLS & GMPLS Networks
   [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].
COMMENT: Will that document be updated with specific MPLS-TP
considerations? If so, I haven't seen any move to start that work.
If not, we should start a separate I-D for MPLS-TP security.

COMMENT: The security I-D should be a normative reference if the
requirements it contains are requirements for MPLS-TP.

===
4.  Security Considerations

   For a description of the security threats relevant in the context of
   MPLS and GMPLS and the defensive techniques to combat those threats
   see the Security Framework for MPLS & GMPLS Networks
   [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].
COMMENT: I don't see how it is helpful to simply copy section 2.10 here.

===
6.2.  Informative References
COMMENT: A good number of these references are normative as they define
terms and ideas that are necessary to the understanding of this I-D.

   [RFC3031]
   [RFC3985]
   [RFC4139]
   [RFC4258]
   [RFC4427]
   [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]

===