Subject: [mpls-tp] Resurfacing of the same old question :-(

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Oct 2009 21:49:39 -0000

Hi,

In today's review of the MPLS-TP Survivability Framework I was asked to add 
a short section explaining what levels of protection (link, segment, 
concatenated segment, e2e, service) were applicable in each of the MPLS LSP 
layer and the PW layer of the MPLS-TP network.

I have drafted this text, which is simple enough, and Nurit is reviewing it 
before I circulate it more widely.

But, now I have written it I am worried!

Didn't we decide in the MPLS-TP Framework that PW is a client of MPLS-TP?
Doesn't that actually mean that PW survivability is *entirely* out of scope 
for this document?
Client layer survivability is an interesting topic, and each MPLS-TP client 
layer should document its own survivability in its own document.
For example, it looks like we are observing (separate thread) that IP is an 
acceptable client of MPLS-TP. I am sure that we do not propose to document 
IP survivability techniques in this document.

So, how should the Survivability Framework be positioning PW survivability?

Thanks for any advice,
Adrian

---

From: <[email-masked]>
Date: Tue, 27 Oct 2009 22:16:38 -0000

What a wonderful and disarmingly simple/accurate post Adrian....I thank
you.  You ask for advice.  Well, the only advice I can offer comes from
cold architectural facts.  And this comes right back to something I have
spent several years trying to get (grudging) acceptance of in our
community:
-	PWs are a consequence of what we created with the LDP spin of
MPLS
-	PWs are problemantic enough when only 1-hop (ie a pretty poor
adaptation to recover from LDP merging, but one MUST have a SA label
proxy here), but go multi-hop however and its like opening Pandora's
networking box....PWs just became a full-blown layer network and now
need proper fowarding labels and everything else in the DP/CP/MP
networking toolkit, including their own resilience/survivability
story....exactly as you write below Adrian.  Now how silly does that
make MPLS-TP (and IETF) look?

If IETF want MPLS-TP to be something to be proud of then we really ought
to make sure all clients are treated equally and we don't create a
full-blown PW layer network above MPLS-TP.  Or is this truth really just
too hard to deal with now?...I have a feeling it might be.  

regards, Neil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 27 October 2009 21:50
> To: [email-masked]
> Subject: [mpls-tp] Resurfacing of the same old question :-(
> 
> Hi,
> 
> In today's review of the MPLS-TP Survivability Framework I 
> was asked to add a short section explaining what levels of 
> protection (link, segment, concatenated segment, e2e, 
> service) were applicable in each of the MPLS LSP layer and 
> the PW layer of the MPLS-TP network.
> 
> I have drafted this text, which is simple enough, and Nurit 
> is reviewing it before I circulate it more widely.
> 
> Doesn't that actually mean that PW survivability is 
> *entirely* out of scope for this document?
> Client layer survivability is an interesting topic, and each 
> MPLS-TP client layer should document its own survivability in 
> its own document.
> For example, it looks like we are observing (separate thread) 
> that IP is an acceptable client of MPLS-TP. I am sure that we 
> do not propose to document IP survivability techniques in 
> this document.
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Oct 2009 13:41:06 -0000

Hi,

I am trying this question again with a different subject line.

It would be helpful to have more answers than just Neil's (not that I don't 
value his view, but one person doesn't make consensus!)

My question:
Hasn't the work on the MPLS-TP Framework draft judged PW to be a client of 
MPLS-TP?
That is, PW is not a layer of MPLS-TP, but the client.
Doesn't that mean that PW survivability is out of scope for the MPLS-TP 
Survivability I-D?

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 27, 2009 9:49 PM
Subject: [mpls-tp] Resurfacing of the same old question :-(

> Hi,
>
> In today's review of the MPLS-TP Survivability Framework I was asked to 
> add a short section explaining what levels of protection (link, segment, 
> concatenated segment, e2e, service) were applicable in each of the MPLS 
> LSP layer and the PW layer of the MPLS-TP network.
>
> I have drafted this text, which is simple enough, and Nurit is reviewing 
> it before I circulate it more widely.
>
> Doesn't that actually mean that PW survivability is *entirely* out of 
> scope for this document?
> Client layer survivability is an interesting topic, and each MPLS-TP 
> client layer should document its own survivability in its own document.
> For example, it looks like we are observing (separate thread) that IP is 
> an acceptable client of MPLS-TP. I am sure that we do not propose to 
> document IP survivability techniques in this document.
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 28 Oct 2009 14:50:34 +0100

Hi Adrian,
This is also my understanding. 
We had many discussions on the "status" of PW in MPLS-TP and we agreed
that PW is one of the clients of MPLS-TP. Also the framework refers to
PW as a client service of MPLS-TP. 
Therefore I agree that it is out of scope for the MPLS-TP survivability
document.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Adrian Farrel
Sent: Wednesday, October 28, 2009 3:41 PM
To: [email-masked]
Subject: [mpls-tp] Is PW a layer of MPLS-TP?

Hi,

It would be helpful to have more answers than just Neil's (not that I
don't 
value his view, but one person doesn't make consensus!)

My question:
Hasn't the work on the MPLS-TP Framework draft judged PW to be a client
of 
MPLS-TP?
That is, PW is not a layer of MPLS-TP, but the client.
Doesn't that mean that PW survivability is out of scope for the MPLS-TP 
Survivability I-D?

Thanks,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 28 Oct 2009 15:08:22 +0100

Hi Adrian,

> I am trying this question again with a different subject line.

It may indeed draw more attention  ;-)

> of MPLS-TP?

YES!
This was discussed also in the drafting session (ex-MEAD meeting)
in Munchen and it was agreed / confirmed that PW is client
of MPLS-TP.

> That is, PW is not a layer of MPLS-TP, but the client.

Correct.

> Doesn't that mean that PW survivability is out of scope for the MPLS-TP 

Yes, I agree.

> Adrian

Cheers, Huub.

> ----- Original Message ----- From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
>> In today's review of the MPLS-TP Survivability Framework I was asked 
>> to add a short section explaining what levels of protection (link, 
>> segment, concatenated segment, e2e, service) were applicable in each 
>> of the MPLS LSP layer and the PW layer of the MPLS-TP network.
>>
>> I have drafted this text, which is simple enough, and Nurit is 
>> reviewing it before I circulate it more widely.
>>
>> For example, it looks like we are observing (separate thread) that IP 
>> is an acceptable client of MPLS-TP. I am sure that we do not propose 
>> to document IP survivability techniques in this document.
>>

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Malcolm Betts <[email-masked]>
Date: Wed, 28 Oct 2009 10:17:06 -0400

+1

> Behalf Of Huub van Helvoort
> Sent: Wednesday, October 28, 2009 10:08 AM
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?
> 
> Hi Adrian,
> 
> You wrote:
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Oct 2009 14:19:50 +0000

Adrian Farrel wrote:
> don't value his view, but one person doesn't make consensus!)
>
> My question:
> Hasn't the work on the MPLS-TP Framework draft judged PW to be a 
> client of MPLS-TP?
> Doesn't that mean that PW survivability is out of scope for the 
> MPLS-TP Survivability I-D?
>
> Thanks,
> Adrian
>

Adrian

It seems to me that the best way to describe MPLS-TP is as a service 
sub-layer carried
over a transport sub-layer. This is called up in the latest version of 
the -TP fwk, although
perhaps we need to make this clearer in the next version.

It also seems to me that you have written the MPLS-TP transport 
sub-layer survivability fwk
and that we also need one or more MPLS-TP service sub-layer service 
layer survivability
documents.  Thus we need an MPLS-TP service sub-layer service layer 
survivability fwk
for PW which we can shepherd in PWE3. I am not sure whether there also needs
to be an NLTS equivalent document, since although survivability is easy 
in an IP
network with dynamic routing protocols, MPLS-TP currently only describes 
static
configured network layer services and they have very similar properties 
to PWs from
a survivability point of view.

Each document should include appropriate scoping information.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Oct 2009 14:27:41 +0000

Huub
> in Munchen and it was agreed / confirmed that PW is client
No, we agreed that an MPLS-TP PW was one client of the MPLS-TP LSP, although
is is better expressed as the transport service sub-layer and the transport
path sub-layer.

>> MPLS-TP Survivability I-D?
I think it means that we need separate survivability descriptions for 
the two sublayers
since they they have different characteristics.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 16:39:03 +0200

Huub, Adrian and all,
I may be terribly wrong here, but what exactly does the statement "A PW is a client of MPLS-TP" mean?
Or  what does the opposite statement - "A PW is a layer of MPLS-TP" - mean?

How can we know whether the bottom label of the MPLS(-TP) label stack is a "PW label" or "Just another label"?

We can do that if the bottom label happens to be one of the reserved labels, e.g.., GAL. But for a "regular" label?
Taking into consideration multi-segment PWs, so that TTL in the corresponding label stack entry is unpredictable?

On the other hand, I do not see any issues whatsoever with taking PW survivability out of scope of the MPLS-TP survivability draft.
But this is NOT because PW is (or is not) a client of MPLS-TP.

Do I miss something important?

Regards,
     Sasha

> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: Wednesday, October 28, 2009 4:08 PM
> To: Adrian Farrel
> Cc: [email-masked]
> was asked

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 16:00:57 +0100

Adrian,

When I look at the MPLS-TP landscape then I see two different types of layer
networks:
1) layer network A which contains a MS-PW MEG level and zero or more LSP MEG
levels
2) layer network B which contains one or more LSP MEG levels.

With these two layer networks it is possible to construct a MPLS-TP Virtual
Channel layer network using layer network A, and to construct a MPLS-TP
Virtual Path layer network using layer netowrk B. It is also possible to
construct a MPLS-TP Virtual Section layer network using layer network B,
which would be necessary when the (non-MPLS) transmission media layer does
not support a section layer.

A MPLS-TP VP signal carries n (n>=1) MPLS-TP VC signals.

A MPLS-TP VS signal carries either n (n>=1) MPLS-TP VP signals (VP over VS),
or n (n>=1) MPLS-TP VC signals (VC over VS).

The MPLS-TP VC layer deploys MPLS-TP PW OAM within the MS-PW MEG level and
LSP OAM within the LSP MEG levels (for each MPLS-TP VC segment). As a
consequence, a MPLS-TP VC MIP function must support both PW OAM and LSP OAM;
which of these two OAM types is supported by a specific MPLS-TP VC MIP
function on an NNI port depends on the lowest MPLS-TP MEG level. MPLS_TP VC
MIP function on an NNI on a PE node must thus be configurable for PW OAM or
LSP OAM. When the MPLS-TP VC has only a MS-PW MEG level acitve, the MPLS-TP
VC MIP functions must be responsive to MPLS-TP PW OAM. When the MPLS-TP VC
has both the MS-PW MEG level and one or more LSP MEG levels active (i.e.
segment monitoring), then the MPLS-TP VC MIP function within the segment
must be responsive to LSP OAM.

The PW is as such an integral part of MPLS-TP technology and layer networks.
It represents one MEG level (the Network Connection Monitoring (NCM) MEG
level) within the MPLS-TP VC layer.

-------------------

There is an alternative view possible when MPLS-TP only provides a Virtual
Path layer network, and this MPLS-TP VP layer netowrk is combined with an
Ethernet Virtual Channel layer network. In this combination there is no
MPLS-TP Virtual Channel layer network and there is no need for any MPLS-TP
PW OAM (refer to C745, SG15 Sep/Oct 2009). The OAM used in the Virtual
Channel layer is the ETH OAM specified in Y.1731/G.8021. The "PW Label Stack
Entry" header carries the vlan_identifier information in its 20-bit PW Label
field, and the priority and drop_eligible information in its 3-bit TC field.

In this case the "PW" represents a label header and there is no PW layer (or
more precise no "layer network A" as described above and thus no "PW MEG
level"). MPLS-TP would then only contain LSPs (i.e. only a "layer network B"
as described above).

---------------------

My understanding is that both alternatives will be present in the packet
transport network; some operators have build or are building their PTN with
MPLS-TP VC included, others have build or are building their PTN without
MPLS-TP VC layer.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: woensdag 28 oktober 2009 14:41
To: [email-masked]
Subject: [mpls-tp] Is PW a layer of MPLS-TP?

Hi,

My question:

Thanks,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 16:18:14 +0100

If we consider the MPLS-TP Virtual Channel layer as the name for the MPLS-TP
service layer, then MPLS-TP VC trail starts/ends at two PW MEP functions. 

When this MPLS-TP VC is 1:1 SNC/S protected, MPLS-TP LSP MEP functions will
be activated on NNI ports (creating VC segments) to monitor the Working VC
SNC and Protection VC SNC.

When this MPLS-TP VC is 1+1 SNC/N protected, MPLS-TP PW MEP_Sink function
will be activated on NNI ports to monitor the Working VC SNC and Protection
VC SNC.

These SNC protection mechanisms can be described in a single survivability
document, i.e. similar to what has been done so far for SDH, OTN, Ethernet
in SG15.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: woensdag 28 oktober 2009 15:28
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

Huub
> This was discussed also in the drafting session (ex-MEAD meeting) in 
> Munchen and it was agreed / confirmed that PW is client of MPLS-TP.

>> MPLS-TP Survivability I-D?
I think it means that we need separate survivability descriptions for the
two sublayers since they they have different characteristics.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 17:18:53 +0200

Maarten,
Two naive questions if you do not mind:

1. Do I read you correctly that, in MPLS-TP, layering is imposed on the network in order to structure some 
   OAM entities?  Per se (in the data plane) layering  simply does not exist, and hence the way in which it
   is imposed is actually arbitrary?

2. What is the difference between the MS-PW MEG and an LSP MEG? Especially in the MPLS-TP
    landscape which presumably requires bi-directional LSPs?

My 2c,
     Sasha

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Wednesday, October 28, 2009 5:01 PM
> To: 'Adrian Farrel'; [email-masked]
> was asked to

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 28 Oct 2009 16:27:17 +0100

Sasha,
I agree that the discussion you bring in is very important, but it also
valid for MPLS networks today......
RFC3031 supports the capability of network layer protocols such as IP,
etc. (section 2.2 and more) ....
I think this discussion should be taken in the scope of the MPLS-TP
architecture......
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Alexander Vainshtein
Sent: Wednesday, October 28, 2009 4:39 PM
To: [email-masked]; Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

Huub, Adrian and all,
I may be terribly wrong here, but what exactly does the statement "A PW
is a client of MPLS-TP" mean?
Or  what does the opposite statement - "A PW is a layer of MPLS-TP" -
mean?

How can we know whether the bottom label of the MPLS(-TP) label stack is
a "PW label" or "Just another label"?

We can do that if the bottom label happens to be one of the reserved
labels, e.g.., GAL. But for a "regular" label?
Taking into consideration multi-segment PWs, so that TTL in the
corresponding label stack entry is unpredictable?

On the other hand, I do not see any issues whatsoever with taking PW
survivability out of scope of the MPLS-TP survivability draft.
But this is NOT because PW is (or is not) a client of MPLS-TP.

Regards,
     Sasha

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 28 Oct 2009 16:31:19 +0100

Hi Maarten,
I think that we need to define the network layers regardless of the OAM
architecture.....
The OAM architecture needs to fit the MPLS-TP architecture.....
Best regards,
Nurit

-----Original Message-----
Behalf Of ext Maarten Vissers

Adrian,

When I look at the MPLS-TP landscape then I see two different types of
layer
networks:
1) layer network A which contains a MS-PW MEG level and zero or more LSP
MEG
levels
2) layer network B which contains one or more LSP MEG levels.

With these two layer networks it is possible to construct a MPLS-TP
Virtual
Channel layer network using layer network A, and to construct a MPLS-TP
Virtual Path layer network using layer netowrk B. It is also possible to
construct a MPLS-TP Virtual Section layer network using layer network B,
which would be necessary when the (non-MPLS) transmission media layer
does
not support a section layer.

A MPLS-TP VS signal carries either n (n>=1) MPLS-TP VP signals (VP over
VS),
or n (n>=1) MPLS-TP VC signals (VC over VS).

The MPLS-TP VC layer deploys MPLS-TP PW OAM within the MS-PW MEG level
and
LSP OAM within the LSP MEG levels (for each MPLS-TP VC segment). As a
consequence, a MPLS-TP VC MIP function must support both PW OAM and LSP
OAM;
which of these two OAM types is supported by a specific MPLS-TP VC MIP
function on an NNI port depends on the lowest MPLS-TP MEG level. MPLS_TP
VC
MIP function on an NNI on a PE node must thus be configurable for PW OAM
or
LSP OAM. When the MPLS-TP VC has only a MS-PW MEG level acitve, the
MPLS-TP
VC MIP functions must be responsive to MPLS-TP PW OAM. When the MPLS-TP
VC
has both the MS-PW MEG level and one or more LSP MEG levels active (i.e.
segment monitoring), then the MPLS-TP VC MIP function within the segment
must be responsive to LSP OAM.

The PW is as such an integral part of MPLS-TP technology and layer
networks.
It represents one MEG level (the Network Connection Monitoring (NCM) MEG
level) within the MPLS-TP VC layer.

-------------------

There is an alternative view possible when MPLS-TP only provides a
Virtual
Path layer network, and this MPLS-TP VP layer netowrk is combined with
an
Ethernet Virtual Channel layer network. In this combination there is no
MPLS-TP Virtual Channel layer network and there is no need for any
MPLS-TP
PW OAM (refer to C745, SG15 Sep/Oct 2009). The OAM used in the Virtual
Channel layer is the ETH OAM specified in Y.1731/G.8021. The "PW Label
Stack
Entry" header carries the vlan_identifier information in its 20-bit PW
Label
field, and the priority and drop_eligible information in its 3-bit TC
field.

In this case the "PW" represents a label header and there is no PW layer
(or
more precise no "layer network A" as described above and thus no "PW MEG
level"). MPLS-TP would then only contain LSPs (i.e. only a "layer
network B"
as described above).

---------------------

My understanding is that both alternatives will be present in the packet
transport network; some operators have build or are building their PTN
with
MPLS-TP VC included, others have build or are building their PTN without
MPLS-TP VC layer.

Regards,
Maarten

-----Original Message-----
Behalf

Hi,

My question:

Thanks,
Adrian
----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 27, 2009 9:49 PM
Subject: [mpls-tp] Resurfacing of the same old question :-(

> In today's review of the MPLS-TP Survivability Framework I was asked
to 
> I have drafted this text, which is simple enough, and Nurit is
reviewing 
> For example, it looks like we are observing (separate thread) that IP
is

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 17:35:00 +0200

Nurit,
I cannot agree more: the tail (OAM) should not wag the dog (network architecture)!

And, BTW, I have not yet seen an MPLS-TP architecture draft. 
Are there any plans to provide one? 

Regards,
     Sasha

> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: Wednesday, October 28, 2009 5:31 PM
> To: ext Maarten Vissers; Adrian Farrel; [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 17:50:33 +0200

Nurit,
I am not sure if this discussion is valid for the MPLS (without TP) networks.

And I am not sure to what point exactly in Section 2.2  - Terminology - of RFC 3031 you refer.

Regards,
     Sasha

> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
> [mailto:[email-masked]] 
> Sent: Wednesday, October 28, 2009 5:27 PM
> To: Alexander Vainshtein; [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?
> 
> Sasha,

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 28 Oct 2009 16:52:23 +0100

I meant 3032...sorry. 

-----Original Message-----
From: ext Alexander Vainshtein [mailto:[email-masked]]

Sent: Wednesday, October 28, 2009 5:51 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]; Adrian Farrel
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Nurit,
I am not sure if this discussion is valid for the MPLS (without TP)
networks.

And I am not sure to what point exactly in Section 2.2  - Terminology -
of RFC 3031 you refer.

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 17:53:29 +0200

OK, thanks for the clarification.
     Sasha 

> Sent: Wednesday, October 28, 2009 5:52 PM
> To: Alexander Vainshtein
> From: ext Alexander Vainshtein 
> [mailto:[email-masked]]
>

---

From: <[email-masked]>
Date: Wed, 28 Oct 2009 16:47:43 -0000

I also agree Nurit.  Overkill/poor OAM can be just as bad as no
OAM.....in fact it can be worse, because it may itself introduce
potentially worse reliability due to increased complexity and config.
OAM for defect detection/handling needs to be as simple/sparse as
possible.  And I would not advise having TCM (as fixed preconfigured
levels) or FDI in MPLS-TP. 

regards, Neil

> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 28 October 2009 15:35
> > I think that we need to define the network layers regardless of the 
> > OAM architecture.....
> > 1) layer network A which contains a MS-PW MEG level and 
> zero or more 
> > LSP MEG levels
> > Virtual Channel layer network using layer network A, and to 
> construct 
> > a MPLS-TP Virtual Path layer network using layer netowrk B. 
> It is also 
> > possible to construct a MPLS-TP Virtual Section layer network using 
> > layer network B, which would be necessary when the (non-MPLS) 
> > transmission media layer does not support a section layer.
> > 
> > A MPLS-TP VS signal carries either n (n>=1) MPLS-TP VP signals (VP 
> > over VS), or n (n>=1) MPLS-TP VC signals (VC over VS).
> > 
> > and LSP OAM within the LSP MEG levels (for each MPLS-TP VC 
> segment). 
> > As a consequence, a MPLS-TP VC MIP function must support 
> both PW OAM 
> > and LSP OAM; which of these two OAM types is supported by a 
> specific 
> > MPLS-TP VC MIP function on an NNI port depends on the 
> lowest MPLS-TP 
> > MEG level. MPLS_TP VC MIP function on an NNI on a PE node 
> must thus be 
> > configurable for PW OAM or LSP OAM. When the MPLS-TP VC has only a 
> > MS-PW MEG level acitve, the MPLS-TP VC MIP functions must be 
> > responsive to MPLS-TP PW OAM. When the MPLS-TP VC has both 
> the MS-PW 
> > MEG level and one or more LSP MEG levels active (i.e.
> > segment monitoring), then the MPLS-TP VC MIP function within the 
> > segment must be responsive to LSP OAM.
> > 
> > It represents one MEG level (the Network Connection 
> Monitoring (NCM) 
> > MEG
> > Virtual Path layer network, and this MPLS-TP VP layer netowrk is 
> > combined with an Ethernet Virtual Channel layer network. In this 
> > combination there is no MPLS-TP Virtual Channel layer network and 
> > there is no need for any MPLS-TP PW OAM (refer to C745, 
> SG15 Sep/Oct 
> > 2009). The OAM used in the Virtual Channel layer is the ETH OAM 
> > specified in Y.1731/G.8021. The "PW Label Stack Entry" 
> header carries 
> > the vlan_identifier information in its 20-bit PW Label 
> field, and the 
> > priority and drop_eligible information in its 3-bit TC field.
> > 
> > In this case the "PW" represents a label header and there is no PW 
> > layer (or more precise no "layer network A" as described above and 
> > thus no "PW MEG level"). MPLS-TP would then only contain LSPs (i.e. 
> > only a "layer network B"
> > as described above).
> > 
> > ---------------------
> > 
> > 
> > My understanding is that both alternatives will be present in the 
> > packet transport network; some operators have build or are building 
> > their PTN with MPLS-TP VC included, others have build or 
> are building 
> > their PTN without MPLS-TP VC layer.
> > 
> > Regards,
> > Maarten
> > 
> > 
> > Behalf Of Adrian Farrel

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 20:00:39 +0100

Sasha,

See inline.. 

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 28 oktober 2009 16:19
To: Maarten Vissers
Cc: 'Adrian Farrel'; [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Maarten,

1. Do I read you correctly that, in MPLS-TP, layering is imposed on the
network in order to structure some 
   OAM entities?  Per se (in the data plane) layering  simply does not
exist, and hence the way in which it
   is imposed is actually arbitrary?

[mv] No. Layering is imposed on a transport network in order to scale the
transport network. 

[mv] A layer contains a set of transport entities that have the same
purpose; e.g. 
- customer service carrying transport entities (service/channel layer)
connecting two (or more) UNI-N ports,
- service/channel layer carrying transport entities (tunnel/path layer)
connecting two PEs.

[mv] Transport entities may be owned by multiple operators/service
providers, or may be protected. In this case the transport entity will
contain multiple maintenance entity groups.

[mv] Each maintenance entity group operates an instance of pro-active and
on-demand OAM.

[mv] There are multiple methods to identify OAM of a specific maintenance
entity group. E.g. time based (SDH, OTN), MEG level identifier based
(Ethernet), reserved label based (ATM), label stack based (MPLS-TP).

[mv] Connection management (NMS, GMPLS) controls the set up of transport
entities within a layer network. In addition, connection management controls
the activation and configuration of MEP functions within a transport entity
and the activation and configuration of protection switching within a
transport entity.

[mv] Example: to set up a 1:1 protected service/channel layer transport
entity (protected MPLS-TP VC), connection management will 
- compute the path through the network from UNI-N to UNI-N, including the
Working segment and Protection segment
- reserve bandwidth on each link traversed by the protected MPLS-TP VC
- configure the link connections in the links (supported by tunnel/path
layer transport entities), including the assignment of label values; i.e. PW
label values outside the Working/Protection segments and LSP label values
inside the Working/Protection segments
- configure the matrix connections in the PE nodes to interconnect two or
three NNI ports
- activate the SNC/S protection switching bridge and selector functions in
PE nodes
- configure the NCM MEP functions at the UNI-N ports in T-PE nodes
- activate and configure the TCM MEP functions at the NNI ports in PE nodes
at the end of the Working segment and Protection segment, including
assignment of a label value; i.e a PW label value in this case
- activate and configure the MIP functions at the NNI ports in PE nodes;
MIPs within the MPLS-TP VC outside the Working/Protection segments are
configured to react to PW OAM messages, MIPs inside the Working/Protection
segments are configured to react to LSP OAM messages.

[mv] It is unfortunate that PW OAM and LSP OAM have different frame
formats... as a consequence the MPLS-TP VC MIP functions need to be
configured to react to either PW OAM, or LSP OAM. 

2. What is the difference between the MS-PW MEG and an LSP MEG? Especially
in the MPLS-TP
    landscape which presumably requires bi-directional LSPs?

[mv] In the MPLS-TP service/channel layer transport entities (the MPLS-TP
Virtual Channels) there will always be one network connection monitoring
maintenance entity group. This MEG will be using MPLS-TP PW OAM ("PW MEG").
There may be one or more tandem connection monitoring maintenance entity
groups, which monitor a segment of the MPLS-TP VC. These MEGs will be using
MPLS-TP LSP OAM ("LSP MEG").

[mv] In the MPLS-TP tunnel/path layer transport entities (the MPLS-TP
Virtual Paths) there will always be one network connection monitoring
maintenance entity group. This MEG will be using MPLS-TP LSP OAM ("LSP
MEG"). There may be one or more tandem connection monitoring maintenance
entity groups, which monitor a segment of the MPLS-TP VP. These MEGs will be
using MPLS-TP LSP OAM ("LSP MEG").

Regards,
Maarten

My 2c,
     Sasha

> 1) layer network A which contains a MS-PW MEG level and zero or more 
> LSP MEG levels
> Virtual Channel layer network using layer network A, and to construct 
> a MPLS-TP Virtual Path layer network using layer netowrk B. It is also 
> and LSP OAM within the LSP MEG levels (for each MPLS-TP VC segment). 
> As a consequence, a MPLS-TP VC MIP function must support both PW OAM 
> and LSP OAM; which of these two OAM types is supported by a specific 
> MPLS-TP VC MIP function on an NNI port depends on the lowest MPLS-TP 
> MEG level. MPLS_TP VC MIP function on an NNI on a PE node must thus be 
> responsive to MPLS-TP PW OAM. When the MPLS-TP VC has both the MS-PW 
> there is no need for any MPLS-TP PW OAM (refer to C745, SG15 Sep/Oct 
> specified in Y.1731/G.8021. The "PW Label Stack Entry" header carries 
> the vlan_identifier information in its 20-bit PW Label field, and the 
> their PTN with MPLS-TP VC included, others have build or are building 
> =

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 21:56:19 +0200

Maarten,
Lots of thanks for a prompt response.

I must admit that I read your answer to my question #1 as following:

Layering of MPLS-TP networks is not in any way reflected in the MPLS-TP data plane.

(This is based on the fact that your description of what constitutes a layer do not refer to any data plane aspects of MPLS-TP.)

Of course, the situation is quite different with both SONET/SDH transport and ATM.

You effectively claim that transport networks must follow certain architectural rules regardless of how they actually work. Personally I find this claim highly questionable.

As for my question #2, I must admit that I find the analogy between ATM and MPLS (or MPLS-TP) inappropriate. Hence I fail to interpret your explanations.

Regards,

     Sasha

________________________________________
From: Maarten Vissers [[email-masked]]
Sent: Wednesday, October 28, 2009 9:00 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Sasha,

See inline..

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 28 oktober 2009 16:19
To: Maarten Vissers
Cc: 'Adrian Farrel'; [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Maarten,

Regards,
Maarten

My 2c,
     Sasha

---

From: <[email-masked]>
Date: Wed, 28 Oct 2009 21:11:10 +0000

Adrian,

I'll admit up front I haven't read the draft and I wasn't in the discussion
:-)

At a minimum I think you need to have such a section and highlight where
MPLS-TP plays and what role it expects from it's clients, as a hypothetical
example MPLS-TP may not offer end to end protection itself (say we only
define segment protection as in scope) and therefore would need to make this
clear and highlight that to provide end to end protection MPLS-TP needs the
client to do X, Y, Z etc.

I think some mention of survivability interaction between layers would also
be appropriate if not already in the document (e.g. In general your client
should be slower to respond than the server etc.)

HTH
Ben

---

From: Luca Martini <[email-masked]>
Date: Wed, 28 Oct 2009 16:22:24 -0600

> MPLS-TP Survivability I-D?
I thought we have established that PWs are the only defined client of 
MPLS-TP at this point. I also Believe that IP is another client of 
MPLS-TP , but we have not tackled that question yet.
So PW survivability is out of scope of mpls-tp Survivability I-D. In 
fact we already have many documents describing PW Survivability , no 
matter what the server network is ( IP/MPLS /MPLS-TP ).

Luca

---

From: <[email-masked]>
Date: Thu, 29 Oct 2009 06:58:07 -0000

Luca wrote 28 October 2009 22:22:

> I thought we have established that PWs are the only defined 
> client of MPLS-TP at this point.

NH=> The key points here are:

(i) the MPLS traffic unit should have consistent functional fields and
must not be allowed a 'peer existence' with any other layer network (eg
IP) traffic units on an MPLS interface (this is the point about the need
for consistent characteristic information in a layer network)
(ii) the defect detecting/handling OAM (which is created/removed at
MPLS-TP trail term pts) should be simple/sparse and consistent across
all LSPs in the MPLS-TP layer network (else we will have problems
detecting abitrary instances of misconnectivity)
(iii) all clients of MPLS-TP should be treated the same....and in the
case of intending to provide a *transparent transport service* then
every client bit MUST be treated equally (noting that client information
'importance' !=  client informqation 'temporal sensitivity').  One key
consequence of this is that a given LSP can only have a single QoS
class....and even if anyone baulks at this fact per se, note that it is
practically very important anyway, else we will end-up with almost
intractable criteria for entry/exit of the unavailable state for a given
LSP.

> I also Believe that IP is 
> another client of MPLS-TP , but we have not tackled that question yet.

NH=> Well, lets be really clear about IP as a traffic DP client and IP
as a CP/MP protocol (for the MPLS-TP layer network)...these belong to
very different IP layer networks.  The latter is simply the well-known
GMPLS model (though in the co-cs mode one has no choice but to take the
CP/MP logically OOB wrt to the traffic DP).

But I note you have missed MPLS-TP as a client of MPLS-TP.  This is
actually a rather important case as we will require a good client/server
solution for the LSP of party X to be *transparently* carried over the
LSP of party Y.  Note also this is very different to the S-bit
sublayering of LSPs. And I am hoping that folks can start to see why I
keep saying that S-bit sublayering is NOT a good behaviour in a
transport network.....S-bit sublayering does not create a true
client/server relationship as there is an implicit (and unstated)
assumption that such sublayers all exist under a common suite of CP/MP
protocols....which is usually not true however, eg different CP
protocols issue MPLS labels and thus MPLS label semantics are NOT
consistent but have specific context only to the CP protocol that issued
that label (bad news of course when we have misconnectivity).

Aside=> It's when we get to PWs, and esp multi-segment PWs, that we
suddenly realise (or at least we should realise) we have created a new
co-ps mode layer network here which cannot operate under the same CP/MP
as the server MPLS-TP layer network....which harps back to the
long-standing flawed aim of having a common CP instance running IP to
Optics....it just plain won't work as a *single instance of*.  If folks
still want MS-PWs in MPLS-TP then lets be very clear that this is no
longer a common adaptation function in MPLS-TP, but represents a layer
network in its own right above (or potentially even below!) MPLS-TP.

> So PW survivability is out of scope of mpls-tp Survivability 
> I-D. In fact we already have many documents describing PW 
> Survivability , no matter what the server network is ( 
> IP/MPLS /MPLS-TP ).

NH=> Exactly so Luca.  It's taken about what 7/8 years (?) since I first
started saying that MS-PWs would create a new co-ps layer network above
(at that time) MPLS.  And as you also correctly observe Luca the mere
fact we can have MS-PWs over both IP and MPLS (all spins) server layers
makes this fact very clear anyway.

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Oct 2009 12:51:40 +0100

Sasha,
 
> (This is based on the fact that your description of what constitutes a
layer do not refer to
> any data plane aspects of MPLS-TP.)
 
The data plane formats in MPLS-TP are the result of an evolution of existing
header/frame formats and capabilities in existing router implementations
(LSE header stacking). T-MPLS frame formats were an evolution of other
existing header/frame formats and capabilities present in transport
equipment.
 
T-MPLS frame formats and T-MPLS VC/VP layers had a strong coupling; i.e. a
non-reserved label stack entry header corresponded with either a VC or VP.
Segment monitoirng maintenance entity levels were encoded using a MEG Level
field, separating the fields to identify (1) a client signal in an aggregate
stream and (2) a segment maintenance entity level. This would have resulted
in a following label stack when a VP with 2 segment monitoring levels
carrying a VC with 3 segment monitoring levels would be present on an
interface:
- 217 - 6534 
which is accompanied by label stacks with values 
- 14 - MEL=0 (virtual section OAM)
- 217 - 14 - MEL=0 (virtual path, segment 1 OAM)
- 217 - 14 - MEL=1  (virtual path, segment 2 OAM)
- 217 - 14 - MEL=2 (virtual path network connection OAM)
- 217 - 6534 - 14 - MEL=0  (virtual channel, segment 1 OAM)
- 217 - 6534 - 14 - MEL=1 (virtual channel, segment 2 OAM)
- 217 - 6534 - 14 - MEL=2 (virtual channel, segment 3 OAM) 
- 217 - 6534 - 14 - MEL=3 (virtual channel, network connection OAM).
 
217 identifies the VP and 6534 identifies a VC within the VP. 14 identifies
that the payload carries OAM and the MEL identifies the different segment
and network connection OAM entities. Very simple as such, and a strong
reflection of layering in the data plane frame format encoding.
 
The choice in MPLS-TP to deploy label stack entry headers to identify
segment monitoring maintenance entity levels removed the coupling between a
label stack entry header and a layer network signal instance. That decision
**impacted the encoding of specific elements of information**, it did **not
impact the functional model of the layer network**. The above label stack
example has as such been replaced by the following:
 - 217 - 65 - 458- 6534 - 9123 - 100567 - 873 
which is accompanied by label stacks with values 
- 13 (virtual section OAM)
- 217 - 13 (virtual path, segment 1 OAM)
- 217 - 65 - 13 (virtual path, segment 2 OAM)
- 217 - 65 - 458 -13 (virtual path network connection OAM)
- 217 - 65 - 458 - 6534 - 13 (virtual channel, segment 1 OAM)
- 217 - 65 - 458 - 6534 - 9123 - 13 (virtual channel, segment 2 OAM)
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 13 (virtual channel, segment 3
OAM) 
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 873 -13 (virtual channel, network
connection OAM).
 
>From this label stack it is totally unclear if there is 
- a VC carried over a section layer with 6 segment monitoring levels, or
- a VP carried over a section layer with
  # 5 VP segment monitoring levels and a VC without segment monitoring, or
  # 4 VP segment monitoring levels and a VC with 1 segment monitoring level,
or
  # 3 VP segment monitoring levels and a VC with 2 segment monitoring
levels, or 
  # 2 VP segment monitoring levels and a VC with 3 segment monitoring
levels, or 
  # 1 VP segment monitoring levels and a VC with 4 segment monitoring
levels, or
  # no VP segment monitoring levels and a VC with 5segment monitoring
levels.
 
It is clear that there is no reflection of the layering in the data plane
frame format encoding... but this has been a choice of the group.
 
If it would be important to reflec the layering in the data plane frame
formats, then it is possible to do so in a simple means. I.e. when a label
stack entry header is added at the input of a segment MEP it is possible to
insert a reserved label value (e.g. 12) into the label field. If you do this
you restore the coupling between layering and data plane frame formats. If
you now look into the label stack, you will find label stack entry headers
with a normal label value (>=16), label stack entry headers with label value
12 and label stack entry headers with label value 13. Taking the same
example as above, you would get:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 
which is accompanied by label stacks with values 
- 13 (virtual section OAM)
- 217 - 13 (virtual path, segment 1 OAM)
- 217 - 12 - 13 (virtual path, segment 2 OAM)
- 217 - 12 - 12 -13 (virtual path network connection OAM)
- 217 - 12 - 12 - 6534 - 13 (virtual channel, segment 1 OAM)
- 217 - 12 - 12 - 6534 - 12 - 13 (virtual channel, segment 2 OAM)
- 217 - 12 - 12 - 6534 - 12 - 12 - 13 (virtual channel, segment 3 OAM) 
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 -13 (virtual channel, network
connection OAM).
 
217 identifies the VP, 6534 identifies one of the VCs within the VP. This is
immediately visible from this enhanced encoding of segment monitoring label
fields in label stack entry headers. And by counting the number of label
stack entry headers with label value 12 it is possible to identify the
different OAM frames.
 
I hope it is clear to you now that the three encodings presented above can
be used with the same VC, VP and VS layering. The layering is as such
independent of the choosen encoding. Each encoding has its pro's and con's.
The existing, middle encoding is however not friendly for us people, as it
does not give us any idea of the signal structure. In that sense it is the
worst possible encoding format.
 
Regards,
Maarten
 
  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 28 oktober 2009 20:56
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Maarten,

Layering of MPLS-TP networks is not in any way reflected in the MPLS-TP data
plane. 

(This is based on the fact that your description of what constitutes a layer
do not refer to any data plane aspects of MPLS-TP.)

Of course, the situation is quite different with both SONET/SDH transport
and ATM. 

You effectively claim that transport networks must follow certain
architectural rules regardless of how they actually work. Personally I find
this claim highly questionable.

As for my question #2, I must admit that I find the analogy between ATM and
MPLS (or MPLS-TP) inappropriate. Hence I fail to interpret your
explanations.

Regards,

     Sasha

Sasha,

See inline..

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 28 oktober 2009 16:19
To: Maarten Vissers
Cc: 'Adrian Farrel'; [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Maarten,

Regards,
Maarten

My 2c,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Oct 2009 13:18:41 +0100

Sasha,
 
I noted a small mistake in the second and third label stacks (due to
copy/paste of previous lines). Virtual channel, network connection OAM is
implemented by PW OAM and as such does not have the GAL (label_13); instead
the 4-bit nibble distinguishes between client data and OAM.
 
The following corrections have to be applied:
 
replace: 
- 217 - 65 - 458- 6534 - 9123 - 100567 - 873 
by: 
- 217 - 65 - 458- 6534 - 9123 - 100567 - 873 - nibble=0000
 
replace:
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 873 -13 (virtual channel, network
connection OAM).
by:
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 873 - nibble=0001 (virtual
channel, network connection OAM).
 
replace:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 
by:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 - nibble=0000
 
replace:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 -13 (virtual channel, network
connection OAM).
by:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 - nibble=0001 (virtual channel,
network connection OAM).
 
Regards,
Maarrten
 
  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: donderdag 29 oktober 2009 12:52
To: 'Alexander Vainshtein'
Cc: [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

Sasha,
 
layer do not refer to

 

 

 
 
Regards,
Maarten
 
  _____  

Maarten,

Regards,

     Sasha

Sasha,

See inline..

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 28 oktober 2009 16:19
To: Maarten Vissers
Cc: 'Adrian Farrel'; [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Maarten,

Regards,
Maarten

My 2c,
     Sasha

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 29 Oct 2009 09:54:31 -0700

Hi Adrian,

> Hasn't the work on the MPLS-TP Framework draft judged PW to be a client of

That is correct.

Correct.

> Doesn't that mean that PW survivability is out of scope for the MPLS-TP

Yes.

rahul

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 29 Oct 2009 10:07:16 -0700

+1 

> [mailto:[email-masked]] On Behalf Of Rahul Aggarwal
> Sent: Thursday, October 29, 2009 9:55 AM
> To: Adrian Farrel
> Cc: [email-masked]
> > > For example, it looks like we are observing (separate 
> thread) that 
> > > IP is an acceptable client of MPLS-TP. I am sure that we do not 
> > > propose to document IP survivability techniques in this document.
> > >

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Oct 2009 18:33:55 +0000

Let me ask a question?

Are you talking of MPLS-TP the  extended subset of the
output of the IETF MPLS-TP WG, or are you talking
of MPLS-TP the joint IETF/ITU-T  project to
design a transport technology?

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 29 Oct 2009 21:45:26 +0200

Stewart,
I must admit that I am completely confused.

Do you imply that there are (or will be) TWO somewhat different MPLS-TP technologies?

And if there are two, which one do we discuss on the MPLS-TP mailing list?

Regards,
     Sasha
> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Thursday, October 29, 2009 8:34 PM
> To: Rahul Aggarwal
> Cc: [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 29 Oct 2009 21:25:27 +0100

Is there a difference? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Stewart Bryant
Sent: Thursday, October 29, 2009 8:34 PM
To: Rahul Aggarwal
Cc: [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

Let me ask a question?

- Stewart

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 29 Oct 2009 21:51:16 +0100

I think it should be very clear that we have exactly one mpls-tp.

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
Sent: Thursday, October 29, 2009 10:25 PM
To: [email-masked]'; Rahul Aggarwal
Cc: [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Is there a difference? 

-----Original Message-----

Let me ask a question?

- Stewart

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 29 Oct 2009 22:24:58 +0100

Luca,
We have discussed the clients of MPLS-TP in the context of the
framework, and actually the framework refers to TWO types of clients of
MPLS-TP, PW and network service (or as is written today network client
layer client) which is compliant to MPLS RFC 3032. 
I have questions regarding PW survivability....but I'll send them using
another subject addressed to the PWE3 WG.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Luca Martini
Sent: Thursday, October 29, 2009 12:22 AM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

Luca

---

From: <[email-masked]>
Date: Thu, 29 Oct 2009 21:35:29 -0000

Is this question actually relevant Stewart? 

The reason I ask this is because it does not matter whether we are using
MPLS type X or IP type Y (or in fact anything else as a server) when
supporting a MS PW....it is the very act of making a PW *multi-hop* that
causes a dramatic change of state as to what a PW can be.  It can no
longer claim to be a non-networked adaptation role but becomes a full
blown layer network in its own right.  You no doubt remember me flagging
this warning time and time again over many years to PWE3.

Aside=> Part of the confusion IMO is also down to the digital wrapper (S
bit) sublayering treatment of stacked MPLS LSPs per se.  You don't see
this behaviour in IP (wisely!) so it would not even occur to most folks
to even think of it this way when IP is the server.

Think you just have to accept it Stewart....we created a new layer
network with MW-PWs.  But the really, really sad bit for me is that the
CW was largely a hack/fix for ECMP with LDP, as this was required to
treat non-IP and non-MPLS clients differently, but with MPLS-TP we have
to remove all the arch problems of LDP that generated PWs in the first
place!  There simply should never be any PWs in MPLS-TP....that is the
technically accurate analysis.  Now how embarassing for us is that? 

regards, Neil

> Sent: 29 October 2009 18:34
> To: Rahul Aggarwal
> Cc: [email-masked]
> Are you talking of MPLS-TP the  extended subset of the output 
> of the IETF MPLS-TP WG, or are you talking of MPLS-TP the 
> joint IETF/ITU-T  project to design a transport technology?
> 
> - Stewart

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 30 Oct 2009 16:27:22 +0100

I agree with Stewart.

Within MPLS-TP, PW represents the MPLS-TP service sub-layer while LSP
represents the MPLS-TP transport sub-layer. Both are in the scope of
MPLS-TP.

Having both in the scope of MPLS-TP does not preclude to move the PW
specific aspects outside the scope of draft-ietf-mpls-tp-survive-fwk and
in the scope of a new draft to be developed within the PWE3 WG as
discussed during the call on 27 October.

Italo

> Sent: Wednesday, October 28, 2009 3:20 PM
> To: Adrian Farrel
> Cc: BOCCI Matthew; [email-masked]

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 30 Oct 2009 16:33:52 +0100

> > Hasn't the work on the MPLS-TP Framework draft judged PW to 

This does not match my understanding of the discussion. As far as I am
aware of, we have agreed that PWs are client of MPLS-TP LSPs.

Italo 

> Sent: Thursday, October 29, 2009 5:55 PM
> To: Adrian Farrel
> Cc: [email-masked]
> thread) that IP is

---

From: <[email-masked]>
Date: Fri, 30 Oct 2009 16:34:32 +0100

+1 

Regards,
Manuel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BUSI ITALO
Sent: Friday, October 30, 2009 4:27 PM
To: [email-masked]; Adrian Farrel
Cc: BOCCI Matthew; [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

I agree with Stewart.

Italo

---

From: Lou Berger <[email-masked]>
Date: Fri, 30 Oct 2009 11:41:32 -0400

Italo,

See below.

> represents the MPLS-TP transport sub-layer. Both are in the scope of

As you know PWs, aren't the only way to provide client services in TP.
So, I think you need to scope this to only the case when PWs are used
for client adaptation.

> discussed during the call on 27 October.

I think we heard different things on this call.  I heard that the
survive-fwk document will provide the overall umbrella (not hook) for
TP, independent of the mechanism(s) used to provide the survivability.
The document will also provide the details/hooks for LSP survivability
mechanisms, and state that PW details would be covered in a separate
document.  It is this separate document that we agreed would be brought
forward by PW experts, but this document still needs to conform to the
overall / mechanism-independent portion of survive-fwk.

Lou