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

From: Stewart Bryant <[email-masked]>
Date: Mon, 17 Dec 2007 10:08:51 +0000

Francesco Fondelli wrote:
> On Nov 22, 2007 7:18 PM, Stewart Bryant <[email-masked]> wrote:
> [cut]
>   
>> picked up on) that there is only ONE label
>> 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!
>
>   
Certainly Itallo has told me that there are two labels in the packet,
but the following text is not clear:

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

So what labels does the packet actually have at this point, and how
are their values assigned?

I think that we have to respond along the lines that we do not
understand the liaison and state that from our perspective the
requirement is that T-MPLS peering segment MUST be indistinguishable
from a MS-PS segment, and request that they restate the proposed
design proposal using same language and notation used in RFC3985 and
draft-ietf-pwe3-ms-pw-arch

- Stewart

>> - 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.
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>
>   

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