Subject: [PWE3] SG15Q12 liaison on MS-PW requirements

From: Stewart Bryant <[email-masked]>
Date: Thu, 22 Nov 2007 18:18:03 +0000

I have been taking a look at the following liaison statement

https://datatracker.ietf.org/liaison/372/

I replying I think that we have to strongly express
our willingness to work together and to request
requirements.  Given that we have all but completed

draft-ietf-pwe3-ms-pw-requirements-05.txt

I think that we would have to take the requirements as
as supplementary to the existing requirements.

Now I have a few concerns that we need to look at in
the document:

"Inside the T-MPLS network there is a 1:1 relationship 
between the MPLS MS-PW and the T-MPLS Channel trail; 
therefore the TMC/PW_A function is not required to 
insert a PW label. The reason is that the functionality 
of multiplexing (for vertical scalability reasons) 
multiple pseudo-wires over a single trunk is performed 
at the TMP level (by multiplexing multiple TMCs over a TMP)."

This is saying (and I think that this is a problem 
that applies to TMPLS in general that we have not
picked up on) that there is only ONE label
in the packet that does double duty between PW label
AND as MPLS label - perhaps Itallo can confirm). This
breaks the PWE3/MPLS architecture. The only way that I can
see it fitting is if we allow PHP of the PW lable
IFF there is only one PW, which seems something of
an irony!

"Given the fact that T-MPLS has the same QoS architecture 
as IP/MPLS networks, the mapping of the QoS at the client 
MPLS PW layer and the QoS at the server T-MPLS channel 
layer is straightforward."

That is true for data traffic, BUT with the re-use 
of the exp bits in the OAM I am not sure that it
holds across the whole design.

Please could others read the liaison and comment on
the correct response.

- Stewart

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Francesco Fondelli" <[email-masked]>
Date: Mon, 26 Nov 2007 15:37:51 +0100

On Nov 22, 2007 7:18 PM, Stewart Bryant <[email-masked]> wrote:
[cut]
> in the packet that does double duty between PW label
[cut]

No, IMHO that statement says something different.  G.805
terminology/methodology is
the whole point here. Even if I am far to fully understand G.805
functional architecture
I try to explain what the liaison says (at least my interpretation).
We have to agree
on few points before any dissertation:

1)
In figure 1 (liaison 2007-09-20) "T-MPLS path" *functionally matches*
a plain LSP.
This entity is just *described*, from a functional view point, in G.8110.1
(using G.805 terminology/methodology).

Please note that the entire "T-MPLS thing" can be defined as -- a *description*
of MPLS from a different view point + some additional constraints (no PHP, only
connection-oriented, etc) + a specific OAM mechanism --. I understand
this might sound strange.

2)
In figure 1 (liaison 2007-09-20) "T-MPLS channel" *functionally
matches* a plain PW.
It is so close to a PW that I call it "PW" :-)

3)
In G.805 formalism a triangle is a "trail termination" and a trapezium
is an "adaptation",
again we are talking about *functional blocks*.  If you want to
describe a network
architecture in G.805 terms you begin describing each single network
element functional
block: you'll describe what goes in ("input signal"), what comes out
("output signal") and
what a single bloody block in the middle should do ("functional block").
ITU-T people claim they can describe everything using this paradigm (SDH, MPLS,
even IP or PBB or whatever).

4)
Figure I.3 of G.8110.1 illustrates how the PWE3 concept fits within
the T-MPLS layer network model (again this is a *description*) and Figure I.4
(same rec, G.8110.1) illustrates how a MS-PW can be *described* using
the same framework.
Please note that ITU-T people say that an Appendix is just informative...
... hemmm actually is the only part of a ITU-T recommendation that I
vaguely understand.

5)
A G.805 trapezium functional block usually performs mux/demux
operations. This is
graphically represented drawing more then one incoming line (5.3.3.1.1, G.805).
However the TMC/PW trapezium (liaison fig 2) has *only one* ingress line
(in G.805 terms I guess we can say that it accepts only one client signal).

----------

Ok. If someone doesn't agree with me about above statements please
*stop reading*
and try to provide alternative interpretations.

The liaison, in my opinion, says: "We (T-MPLS guys) already have a functionally
equivalent PW in our model (i.e. T-MPLS channel trail). If we attach
this *thing*
to a PW segment we obtain a MS-PW.  Do you mind if we do something like that?".

> there is only ONE label in the packet

there are TWO labels in that packet, because the TMC/PW trapezium usually
pushes one specified new label onto the label stack (somewhere in G.8110.1 or
G.8110).

I beg the "T-MPLS design team" to produce an informational I-D to
address these terminology issues (something like rfc 4397 for
GMPLS-ASON) otherwise
this mess will never stop.  Moreover I suggest that people
understanding G.805 functional
architecture stand up and correct me about what I have just said.  I
really need someone
telling me whether I'm right or not!

> - Stewart

Ciao, my 2 cents
FF

ps
in its infinite wisdom ITU-T has made free/available all recommendations
referenced in this email (http://www.itu.int/rec/T-REC/e), I have no access
to new unpublished amendments.