Subject: Re: [mpls-tp] Comments ondraft-abfb-mpls-tp-control-plane-framework-00.txt

From: <[email-masked]>
Date: Sun, 1 Mar 2009 10:57:29 -0000

Very good observations Adrian....I agree with all you have written, but
I would like to add some further remarks in a few places where prefixed
by NH=> in-line below.  I have snipped the text to my additional
remarks. 

regards, Neil 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 28 February 2009 22:08
> To: [email-masked]
> Subject: [mpls-tp] Comments 
> ondraft-abfb-mpls-tp-control-plane-framework-00.txt
> 
> 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.

NH=> Agree.  If MPLS-TP is not fixing problems in MPLS then why are we
bothering with it?  So by definition it will be different.  And I must
stress MPLS-TP will create a different layer network to MPLS.  Even
though I have remarked many times that 'MPLS is not singular' (which is
true) we should also note that MPLS does not even form a proper layer
network anyway....it can't, because it does not have consistent
Characteristic Information (CI) in the DP.  The major issue here is that
MPLS and IP traffic units can both co-exist in the 'same layer network'
(sic), but even for MPLS traffic units which do not have a globally
well-known value/function (ie part of the 0-15 set) the label field does
not have consistent semantics.  The first issue at least must be fixed
in MPLS-TP.  And this is one reason why the CP/MP protocols must be
logically OOB wrt to the DP.  

> 
> ===
> 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).

NH=> No it is not.  Let me state the architectural position yet again:
PWs only exist in MPLS because MPLS did not treat it's clients
equally/correctly...and this was because of the major inconsistent CI
issue I noted above.  This CI problem must be fixed in MPLS-TP else the
exercise will have been pointless, and MPLS-TP will not be able to claim
to be a transport network.  And when it is fixed then there is no
requirement for PWs at all in MPLS-TP.....let me just say that again so
it is very clear: **there is no requirement for PWs in MPLS-TP**.

<snipped>

> ===
> 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?

NH=> Oh its far worse than this Adrian.  If MS-PWs appear in MPLS-TP
then we can state with 100% certainty that MPLS-TP has failed in its bid
to be considered as a transport network...it is as simple as that.  And
in which case we might as well stop all work on MPLS-TP right now.

A properly defined co-ps/cs mode transport network does not generate
unnecessary co-ps/cs layer networks above it.  The only possible claim
one could make to retaining PWs (and they are actually NOT PWs) is to
make the CW an adaptation function.  But the CW is next to useless as
adaptation.  And in fact I would like the design team to explain to the
community what are the technical reasons why the CW is necessary in
MPLS-TP.

> 
>    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.

NH=> I am not sure this statement is even reasonable.  The CP/MP network
is logically different to the DP network.  Moreover, the CP/MP network
can (and invariably does) use a cl-ps mode whereas the DP network it is
controlling/managing can be co-ps or co-cs.  The co-cs mode forces this
disjoint behaviour...which is why GMPLS looks like it does.  If one does
allow merging behaviour in something that looks like the co-ps mode
(merging is impossible in the co-cs mode) then one must appeal to to a
higher layer entity to recover the lost source information.  If the
higher layer entity is a cl-ps mode network (like IP) then this can work
as a cl-ps mode network must carry absolute SA information in each of
its traffic units.

I agree that point 9 should be removed.

> 
>    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).

NH=> There is a key point which should be brought clearly out somewhere
(requirements ID?), which is that the activation/deactivation of the
defect detection/handling OAM must be synchronised to either the CP
(signalling) or MP process that sets-up/tears-down the MPLS-TP LSPs.

<snipped>

>
> 
> ===
> 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.

NH=> There must be no requirement for peer interworking of MPLS-TP and
MPLS (no matter which of its non singluar varieties one picks).  MPLS-TP
will form its own independent layer network....if it does not then again
it has failed as a transport network.  More generally, any network that
is not top-of-stack (and this includes MPLS, MPLS-TP and Ethernet just
to be really clear on these technologies at least) should never have
E-NNIs/UNIs, and (even worse) one must never try and peer interwork
different modes/technologies in non top-of-stack layer networks either.
So this requirement must be removed.
> 
>    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.

NH=> If the CP (or MP) of a co-cs/ps mode network allows connections to
be established that have loops in them, then there is something very
wrong with the CP (or MP) design.  And this means that in a properly
designed co-ps mode layer network there is no need for a TTL function in
the (child) traffic units of a (parent) connection....providing such a
function is simply not technically needed.  After connections are
established it is the job of the defect detection/handling OAM of the DP
to detect any loops (or any other misconnectivity problems) that could
occur.  The design requirement of a co-ps mode network is not like a
cl-ps network at all. 
> 
>    11. The MPLS-TP control plane must support multiple client
>        layers.
> 
> Huh? What is a control plane client layer?

NH=> Agreed.  This is a nonsense statement.
> 
>    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?

NH=> Again this is a nonsense statement....I do wonder if whoever wrote
this actually understands how the 3 different network modes actually
work?  The requirement should be phrased something like this:  The
DP/CP/MP of a client layer network must be carried transparently (noting
that 'transparency' has a very precise meaning in a transport network)
over the DP of a server layer network.
> 
> ===
> 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?

NH=> Well, if this happens I will the first to say 'MPLS-TP has failed'.

<snipped>
> 
>
> ===
> 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.

NH=> Almost right.  But you cannot dynamically configure a DP network by
the CP/MP in order for its CP/MP to *then* run on....this is a
chicken/hen situation.  What is required is that there are logical OOB
links between adjacent nodes at the bottom-of-stack level that are
automatically configured by a low meta-signalling process.  This is what
the GAL should be providing.  The CP/MP protocols then run over these
logically OOB links in order to configure the DP for it higher layer
clients.  This is all stuff that has already been done in CCAMPs for
GMPLS, because this is the forced design behaviour in the co-cs mode due
to how labelling and resource assignment must work here.
> 
>    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.

<snipped>
> 
> ===
> 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.

NH=> I agree....but the statement is architecturally wrong anyway as one
cannot talk of *client* switching points in a *server* layer
network.....the server layer network provides topological link
connections in the client layer topology (which are clearly not even
switching points in the client layer network).  I think what is meant
here is that from a higher layer client's perspective, one of the client
link connections is formed by and end-end LSP connection in the server
layer MPLS-TP network...and of course the MPLS-TP end-end LSP connection
can be recursively partitioned to show its links and subnetworks.....and
where the lowest level of recursion of a subnetwork is a node, and this
is a switching point (in whatever layer network we are considering).
<snipped to end>

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 03 Mar 2009 22:47:24 +0000

Neil,

> I agree that point 9 should be removed.

The reasonable statement is the part of the sentence before the "e.g.". It
is perfectly reasonable for the MPLS-TP CP not to make use of every
feature/function available in the GMPLS toolkit. The example of merging LSPs
should be removed, the statement before that in point 9 can stay IMO.

Ben