Subject: [mpls-tp] Comments on draft-abfb-mpls-tp-control-plane-framework-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Feb 2009 22:08:04 -0000

Hi,

Some questions and comments about 
draft-abfb-mpls-tp-control-plane-framework-00.txt

Thanks,
Adrian

===
Abstract
   Backwards compatibility to MPLS is required.

Can you give me a source for that requirement?
I don't believe it is in anyway necessary, and I believe it is
severely limiting on the selection of a solution.
I would like to see this requirement removed from this document
and the text updated to remove any consequences.

===
1.1. Scope

   The LSPs provided by MPLS-TP are used as a server layer for IP,
   MPLS and PWs, as well as other MPLS-TP LSPs. The PWs are used to
   carry client signal other than IP and MPLS.

Are you making a statement that PWs are not used to carry IP and
MPLS? I am not sure that you will find consensus on this today,
and I am not sure it is in scope for your document to make such a
statement.

   The relationship
   between pseudo wires carried and MPLS-TP LSPs is exactly the
   same as between pseudo wires and MPLS LSPs in a Packet switched
   network (PSN). The PW encapsulation over MPLS-TP LSPs used in
   MPLS-TP networks is the same as for PWs over MPLS in an MPLS
   network. MPLS-TP also defines protection and restoration (or,
   collectively, recovery) functions.

I do not think that is relevant to this document either.

   [TP-SURVIVE] focuses on LSPs, and the protection
   functions that must be supported within MPLS-TP. It does not
   specify which control plane mechanisms to be used.

True, although the latest revision gives some high-level hints.

===
1.2. Basic Approach

   The basic approach taken in defining the MPLS-TP Control Plane
   framework is:

   3) MPLS PWs are used as-is by MPLS-TP including the use of
      targeted-LDP for PW signaling [RFC4447], OSPF-TE, ISIS-TE or
      MP-BGP as they apply for (MS)-PW routing.

Is it a bit premature to talk about MS-PW routing solutions?

   9) It is permissible for functions present in the GMPLS control
      plane not to be used in MPLS-TP networks, e.g. the
      possibility to merge LSPs.

Perfectly reasonable statement. Absurd example! Suggest you remove
it.

   10) One possible use of the control plane is to configure, enable
       and empower OAM functionality; this will require extensions
       to existing control plane specifications.

There is an existing WG draft for this function, so this is covered
by point 5). Nor am I clear why you have singled out one function
when you have point 7).

===
1.3. Reference Model

   Per
   MPLS-TP framework [TP-FWK], MPLS-TP control plane is based on
   GMPLS with RSVP-TE for LSP signaling and LDP for PW signaling.
   In both cases, OSPF-TE or ISIS-TE is used for dynamic routing.

I am not sure how you can say that OSPF-TE or ISIS-TE is used for
dynamic routing in the PW case. Figures 1 and 2 show targeted LDP
without the need for a TE routing protocol.

===
2.1. Primary Requirements

   These requirements are based on [TP-REQ]:

Can you please show traceability to the requirements spec?

Actually, I'm not sure it is so wise to include this section as
the requirements I-D is still in flux.

   1.  The MPLS-TP control plane must be able to interoperate
       with existing IETF MPLS control planes where appropriate.

What does "interoperate" mean? What is "appropriate". I do not
believe that there is any value in reproducing requirements without
at least explaining your interpretation.

   10. The MPLS-TP control plane must not provision transport
       paths which contain forwarding loops.

Requirement 19 in the requirements I-D does not say this.

   11. The MPLS-TP control plane must support multiple client
       layers.

Huh? What is a control plane client layer?

   12. The MPLS-TP control plane must be able to operate
       independently over server layer networks.

Can you add an explanation of this requirement. Independent of what?

===
2.2. MPLS-TP Framework Derived Requirements

   The following additional requirements are based on [TP-FWK]:

I am worried that you are deducing requirements from the framework
draft. If there are requirements there that are not in the
requirements draft they must be transplanted. If they are not in
the requirements draft, then I wonder whether they are *really*
requirements.

   60. The MPLS-TP LSP control plane must allow for
       interoperation with the MPLS-TE LSP control plane.

Hmmm. This one again. But what does it really mean?

   63. The MPLS-TP control plane must support linear, ring and
       meshed protection schemes.

In the context of 62, you need to clarify if you mean protection
of the control or data plane.

===
2.3. OAM Framework Derived Requirements

   The following additional requirements are based on [TP-OAM]:

Rather than deducing requirements from the OAM framework, shouldn't
you be using draft-ietf-mpls-tp-oam-requirements-00.txt as the
only reference?

===
3.1.1.  "In-band" and "out of band"

   For an MPLS-TP network, "in-band" is defined such that the
   control plane runs over a network set up by that same control
   plane.

   For an MPLS-TP network, "out of band" is defined such that the
   control plane runs over a network that has been established by
   other means than the control plane itself.

That makes using the GAL/GACH ambiguous!
Note that notwithstanding these definitions, you go on to define
the terms again. I much prefer the later definitions, and I
suggest you simply delete the paragraphs above.

===
3.1.2. Addressing

   MPLS-TP uses the IPv4 and IPv6 address families to identify
   MPLS-TP nodes by default for network management and signaling
   purpose.

Not sure what "by default" means in this context. How about...

MPLS-TP allows the use of the IPv4 and IPv6 address families to
identify MPLS-TP nodes for network management and signaling.

   The separation of the control and management planes
   from the data plane allows each plane to be independently
   addressable.

You have listed three planes. But nowhere have I seen a statement of
a requirement that the management and control planes are or must be
separable. Furthermore, I am not sure that we care about the
management plane within this document.

===
3.2. Signaling

   According to [RFC3471], a Generalized Label has the following
   format: "Generic MPLS labels and Frame Relay labels are encoded
   right justified aligned in 32 bits (4 octets). ATM labels are
   encoded with the VPI right justified in bits 0-15 and the VCI
   right justified in bits 16-31".

Is the quote about FR and ATM labels helpful or relevant?
I would say...

According to [RFC3471], an MPLS label is encoded in a Generalized
Label right justified aligned in 32 bits (4 octets).

   This is primarily used in RESV
   messages to encode the downstream assigned label which shall be
   used on a link or FA of an LSP, using the LABEL object (class =
   16). When the C-Type is set to 2, this LABEL object is carrying
   a Generalized Label encoded as defined in [RFC3471].

I don't think this is the primary use. I think it is used whenever
a label needs to be encoded. Why not turn this around like the other
paragraphs...

When a Resv message is used to report the downstream assigned label
which is to be used for forward direction traffic carried to the
LSR that sent the message, a LABEL object is used (class number 16).
If the C-Type is set to 2, the object carries a Generalized Label
encoded as defined in [RFC3471].

===
3.2. Signaling

Seem to be missing discussion of labels in the Explicit Route Object.

===
3.2. Signaling

   An MPLS-TP domain may be a switching point for an LSP that
   extends between client network islands.

Funny to hear a domain described as a point.

===
3.4. OAM, MEP (hierarchy) configuration & control

   and control OAM entities. This requirement is not yet addressed
   by the foreseen MPLS-TP control protocols (i.e, GMPLS for LSPs
   and T-LDP for PWs).

Please see draft-ietf-ccamp-oam-configuration-fwk-00.txt

===
3.5. Traffic engineering and constraint-based path computation

   Same approach as MPLS.  Specific algorithms out of scope.
   Similar to MPLS, but adds bidirectional and recovery path
   computation.

Why not say "identical to GMPLS"?

===
3.5.1. Relation to PCE

   Path Computation Element (PCE) may be used for path computation
Add reference to RFC 4655.

===