Subject: [PWE3] An error in RFC 4446 "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"

From: Jiang Yuan-long <[email-masked]>
Date: Tue, 18 Aug 2009 21:01:12 +0800

Hi, all:

I came accross an error in RFC 4446 "IANA Allocations for Pseudowire 
Edge to Edge Emulation (PWE3)".

In Sec 3.2, it says:
"   0x000B  IP Layer2 Transport                              [RFC3032]"

it should be:   
   0x000B  IP Layer2 Transport                        [draft-ietf-l2tpext-pwe3-ip]
   
The same problem also exists in web page version http://www.iana.org/assignments/pwe3-parameters.

I wonder how about the status of this expired WG draft, will any more work 
continue on this document or just expired as it is? 
 I also wonder whether we should define a PW type for IP payload so that
everything on PW is possible.
Any comments?
   
   Thanks,
Yuanlong Jiang

---

From: Himanshu Shah <[email-masked]>
Date: Tue, 18 Aug 2009 06:39:34 -0700

There are a couple of drafts in L2VPN WG that uses this PW type (0x000B),
such as http://tools.ietf.org/html/draft-ietf-l2vpn-arp-mediation-12
So it is not an error or problem in the RFC 3032. It is meant to carry IP payload without any data link headers.

Himanshu
Force10 networks

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
Sent: Tuesday, August 18, 2009 9:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [PWE3] An error in RFC 4446 "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"

Hi, all:

In Sec 3.2, it says:

it should be:

   Thanks,
Yuanlong Jiang

---

From: <[email-masked]>
Date: Tue, 18 Aug 2009 21:16:50 +0100

Hi Yuanlong Jiang,
 
Where you said below:
"I also wonder whether we should define a PW type for IP payload so that
everything on PW is possible"
 
This is precisely what a key consequence of MPLS-TP is, ie in the LDP
spin of MPLS we had to define PWs (one reason being that LDP requires
that IP traffic units can run native in the DP with MPLS traffic units),
but given we can't have IP in the MPLS-TP DP and we can't have LDP mp2p
merging constructs in MPLS-TP anyway (the latter point is all about
resource management determinism) then the original driver for PWs is
gone.....just a fact.  So now everything is a PW and nothing is a
PW....that is, we just have clients (any) of MPLS-TP.
 
We still have a tricky issue with the S bit that is not fully understood
IMO yet (S bit => sublayering, as opposed to true client/server
layering), which is also related to the important topic of being able to
do MPLSoverMPLS as a proper client/server relationship.
 
So what you point out below will be the case in MPLS-TP anyway (though
I'm not sure everyone is comfortable with the acceptance of this fact
yet)
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jiang Yuan-long
	Sent: 18 August 2009 14:01
	To: [email-masked]
	Cc: [email-masked]
	Subject: [PWE3] An error in RFC 4446 "IANA Allocations for
Pseudowire Edge to Edge Emulation (PWE3)"

	Hi, all:
	
	I came accross an error in RFC 4446 "IANA Allocations for
Pseudowire 
	Edge to Edge Emulation (PWE3)".
	 
	In Sec 3.2, it says:
	"   0x000B  IP Layer2 Transport
[RFC3032]"
	 
	it should be:   
	   0x000B  IP Layer2 Transport
[draft-ietf-l2tpext-pwe3-ip]
	   
	The same problem also exists in web page version
http://www.iana.org/assignments/pwe3-parameters
<http://www.iana.org/assignments/pwe3-parameters> .
	
	I wonder how about the status of this expired WG draft, will any
more work 
	continue on this document or just expired as it is? 
	I also wonder whether we should define a PW type for IP payload
so that
	everything on PW is possible.
	Any comments?
	   
	   Thanks,
	Yuanlong Jiang

---

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 19 Aug 2009 09:21:18 +0800

Himanshu,

Thanks for your instant reply. 
What I am concerned is:
1) PW type 0x000B is not defined in RFC 3032, it is defined in draft-ietf-l2tpext-pwe3-ip. 
2) MPLS LSP encapsulated IP (as in RFC 3032) may not be the same as PW 
    encapsulated IP (which may include a CW as described in RFC 4447)
3) The setup procedure of LSP and PW is a little different, and PW type field is 
    only used in the latter case. Do we really set up a PW to carry IP or just an LSP?
So this reference is misleading IMO.

But I am very glad to know that this is indeed the PW type for IP, and some 
active drafts are using this mechanism.
Thank you again for this information.

  Best Regards
Yuanlong Jiang
  ----- Original Message ----- 
  From: Himanshu Shah 
  To: Jiang Yuan-long ; [email-masked] 
  Cc: [email-masked] 
  Sent: Tuesday, August 18, 2009 9:39 PM
  Subject: RE: [PWE3] An error in RFC 4446 "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"

  Himanshu

  Force10 networks

   

  Hi, all:

  In Sec 3.2, it says:

  it should be:   

     
     Thanks,
  Yuanlong Jiang

---

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 19 Aug 2009 10:20:53 +0800

Neil,

Thank you for your reply.
As Himanshu said in the last email, 0x000B is actually the PW type for IP, 
rather than L2TP PW type for IP. So I believe it is also feasible for MPLS-TP.

I agree with you that there is some difficulty for MPLS label stack to 
operate in the same manner as client/server layering model, but an adaptation
layer such as PW functions now is indispensable.

 Best Regards
Yuanlong Jiang

  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] ; [email-masked] 
  Cc: [email-masked] 
  Sent: Wednesday, August 19, 2009 4:16 AM
  Subject: RE: [PWE3] An error in RFC 4446 "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"

  Hi Yuanlong Jiang,

  Where you said below:
  "I also wonder whether we should define a PW type for IP payload so that everything on PW is possible"

  This is precisely what a key consequence of MPLS-TP is, ie in the LDP spin of MPLS we had to define PWs (one reason being that LDP requires that IP traffic units can run native in the DP with MPLS traffic units), but given we can't have IP in the MPLS-TP DP and we can't have LDP mp2p merging constructs in MPLS-TP anyway (the latter point is all about resource management determinism) then the original driver for PWs is gone.....just a fact.  So now everything is a PW and nothing is a PW....that is, we just have clients (any) of MPLS-TP.

  We still have a tricky issue with the S bit that is not fully understood IMO yet (S bit => sublayering, as opposed to true client/server layering), which is also related to the important topic of being able to do MPLSoverMPLS as a proper client/server relationship.

  So what you point out below will be the case in MPLS-TP anyway (though I'm not sure everyone is comfortable with the acceptance of this fact yet)

  regards, Neil

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
    Sent: 18 August 2009 14:01
    To: [email-masked]
    Cc: [email-masked]
    Subject: [PWE3] An error in RFC 4446 "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"

    Hi, all:

    In Sec 3.2, it says:

    it should be:   

       
       Thanks,
    Yuanlong Jiang

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 19 Aug 2009 06:08:32 -0700

Yuanlong Jiang,

Please see section 3.4.1 of the MPLS TP Framework I-D:

http://www.ietf.org/id/draft-ietf-mpls-tp-framework-02.txt

It describes how client network layer payloads (e.g., IP and MPLS) are
carried directly, i.e., without a pseudo-wire, over an MPLS TP server
network.

Client non-network layer payloads still use pseudo-wires.

Thanks,

John

> -----Original Message-----
> From: Jiang Yuan-long [mailto:[email-masked]] 
> Sent: Tuesday, August 18, 2009 7:21 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] An error in RFC 4446 "IANA Allocations 
> for PseudowireEdge to Edge Emulation (PWE3)"
> 
> Neil,
>  
> As Himanshu said in the last email, 0x000B is actually the PW 
> type for IP, rather than L2TP PW type for IP. So I believe it 
> is also feasible for MPLS-TP.
>  
> I agree with you that there is some difficulty for MPLS label 
> stack to operate in the same manner as client/server layering 
> model, but an adaptation layer such as PW functions now is 
> indispensable.
>  
>  Best Regards
> Yuanlong Jiang
>  
>  
>  
> 
> 
> 	Subject: RE: [PWE3] An error in RFC 4446 "IANA 
> Allocations for Pseudowire Edge to Edge Emulation (PWE3)"
> 
> 	Hi Yuanlong Jiang,
> 	 
> 	Where you said below:
> 	"I also wonder whether we should define a PW type for 
> IP payload so that everything on PW is possible"
> 	 
> 	This is precisely what a key consequence of MPLS-TP is, 
> ie in the LDP spin of MPLS we had to define PWs (one reason 
> being that LDP requires that IP traffic units can run native 
> in the DP with MPLS traffic units), but given we can't have 
> IP in the MPLS-TP DP and we can't have LDP mp2p merging 
> constructs in MPLS-TP anyway (the latter point is all about 
> resource management determinism) then the original driver for 
> PWs is gone.....just a fact.  So now everything is a PW and 
> nothing is a PW....that is, we just have clients (any) of MPLS-TP.
> 	 
> 	We still have a tricky issue with the S bit that is not 
> fully understood IMO yet (S bit => sublayering, as opposed to 
> true client/server layering), which is also related to the 
> important topic of being able to do MPLSoverMPLS as a proper 
> client/server relationship.
> 	 
> 	So what you point out below will be the case in MPLS-TP 
> anyway (though I'm not sure everyone is comfortable with the 
> acceptance of this fact yet)
> 	 
> 	regards, Neil
> 	 
> 
> 
> 		From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
> 		Subject: [PWE3] An error in RFC 4446 "IANA 
> Allocations for Pseudowire Edge to Edge Emulation (PWE3)"
> 		
> 		
> 		Hi, all:
> 		
> 		The same problem also exists in web page 
> version http://www.iana.org/assignments/pwe3-parameters

---

From: Yong Lucy <[email-masked]>
Date: Wed, 19 Aug 2009 14:43:30 -0500

Hi John,

One clarification on this:

When client network layer over MPLS-TP LSP directly, the method implies that
client network layer can use this MPLS-TP LSP as a client network link
because the LSP is a bidirectional point to point connection. When client
traffic over a PW, the PW does not guarantee link characteristics.
Therefore, the method only applies to client non-network layer.

Is my understanding correct? 

Regards,
Lucy

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Drake, John E
> Sent: Wednesday, August 19, 2009 8:09 AM
> To: Jiang Yuan-long; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] An error in RFC 4446 "IANA Allocations for
> PseudowireEdge to Edge Emulation (PWE3)"
> 
> Yuanlong Jiang,
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 19 Aug 2009 13:31:15 -0700

Lucy,

I'm sorry but I don't understand your conclusion.  I think your
penultimate sentence is correct but I don't understand its relevance,
and your last sentence appears to have precipitated a layer inversion.

Section 3.4.1 deals with client network layer payloads, where 'network
layer' is defined in RFC 3031 to be "synonymous with layer 3".

Thanks,

John  

> From: Yong Lucy [mailto:[email-masked]] 
> Sent: Wednesday, August 19, 2009 12:44 PM
> To: Drake, John E; 'Jiang Yuan-long'; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] An error in RFC 4446"IANA Allocations for 
> When client network layer over MPLS-TP LSP directly, the 
> method implies that client network layer can use this MPLS-TP 
> LSP as a client network link because the LSP is a 
> bidirectional point to point connection. When client traffic 
> over a PW, the PW does not guarantee link characteristics.
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Drake, John E
> > > As Himanshu said in the last email, 0x000B is actually 
> the PW type 
> > > for IP, rather than L2TP PW type for IP. So I believe it is also 
> > > feasible for MPLS-TP.
> > >
> > > I agree with you that there is some difficulty for MPLS 
> label stack 
> > > to operate in the same manner as client/server layering 
> model, but 
> > > an adaptation layer such as PW functions now is indispensable.
> > >
> > >  Best Regards
> > > Yuanlong Jiang
> > >
> > >
> > >
> > >
> > >
> > > 	Subject: RE: [PWE3] An error in RFC 4446 "IANA Allocations for 
> ie in the 
> > > LDP spin of MPLS we had to define PWs (one reason being that LDP 
> > > requires that IP traffic units can run native in the DP with MPLS 
> > > traffic units), but given we can't have IP in the MPLS-TP 
> DP and we 
> > > can't have LDP mp2p merging constructs in MPLS-TP anyway 
> (the latter 
> > > point is all about resource management determinism) then the 
> > > original driver for PWs is gone.....just a fact.  So now 
> everything 
> > > is a PW and nothing is a PW....that is, we just have 
> clients (any) 
> > > of MPLS-TP.
> > >
> > > 	We still have a tricky issue with the S bit that is not fully 
> > > understood IMO yet (S bit => sublayering, as opposed to true 
> > > client/server layering), which is also related to the important 
> > > topic of being able to do MPLSoverMPLS as a proper client/server 
> > > relationship.
> > >
> > > 	So what you point out below will be the case in MPLS-TP anyway 
> > > (though I'm not sure everyone is comfortable with the 
> acceptance of 
> > > this fact yet)
> > >
> > > 	regards, Neil
> > >
> > >
> > >
> Allocations for 
> > > 		I also wonder whether we should define a PW 
> type for IP payload so 
> > > that

---

From: [email-masked]
Date: Thu, 20 Aug 2009 09:53:17 +0800

hi,all
I reviewed section 3.4.1 in draft-ieft-mpls-tp-framework-02, for all cient 
services, there is a unite service label(s=1) to identify procotol payload 
type, and The mapping between protocol payload type and Service Label is 
either configured or signaled.
if this section will not changed in the future. I think that it is 
unnecessary to continue to disscuss the topic.

how about all?

best regards
liu

"Drake, John E" <[email-masked]> 
发件人:  [email-masked]
2009-08-20 04:31

收件人
"Yong Lucy" <[email-masked]>, "Jiang Yuan-long" <[email-masked]>, 
<[email-masked]>, <[email-masked]>
抄送
[email-masked], [email-masked]
主题
[mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:  [PWE3] An 
error in RFC 4446"IANA Allocations      for     PseudowireEdge to Edge 
Emulation (PWE3)"

ie

Lucy,

Thanks,

John 

Allocations for 
> > >            We still have a tricky issue with the S bit that is not 
fully 
> > >            So what you point out below will be the case in MPLS-TP 
anyway 
> > >                            I came accross an error in RFC 4446 "IANA 

> > >                            The same problem also exists in web page 
version 
> > >                            I wonder how about the status of this 
expired 
> WG draft, will any 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 20 Aug 2009 10:15:13 +0800

John,

I understand that you are in favor of carrying IP in LSP directly.
But doesn it mean MPLS-TP will not support PW type 0x000B?

Please assume that MPLS-TP is interworking with IP/MPLS,
and the later is providing IP traffic with PW type 0x000B,
how to resolve this kind of scenarios? just terminate the PW
and expose the IP packets to be transported on MPLS-TP?

    Thanks
Yuanlong Jiang

----- Original Message ----- 
From: "Drake, John E" <[email-masked]>
To: "Jiang Yuan-long" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 19, 2009 9:08 PM
Subject: RE: [PWE3] An error in RFC 4446 "IANA Allocations for 
PseudowireEdge to Edge Emulation (PWE3)"

Yuanlong Jiang,

Thanks,

John

> Allocations for Pseudowire
> type for IP payload so that

---

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 20 Aug 2009 11:20:23 +0800

Hi Liu,

Mapping our discussion topic to the nomenclature of this draft, it is:
Can this service label be a PW label when the payload is IP?

Thanks,
Yuanlong
  ----- Original Message ----- 
  From: [email-masked] 
  To: Drake, John E 
  Cc: [email-masked] ; Yong Lucy ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; Jiang Yuan-long 
  Sent: Thursday, August 20, 2009 9:53 AM
  Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

  hi,all 
  I reviewed section 3.4.1 in draft-ieft-mpls-tp-framework-02, for all cient services, there is a unite service label(s=1) to identify procotol payload type, and The mapping between protocol payload type and Service Label is either configured or signaled. 
  if this section will not changed in the future. I think that it is unnecessary to continue to disscuss the topic. 

  how about all? 

  best regards 
  liu

        "Drake, John E" <[email-masked]> 
        发件人:  [email-masked] 
        2009-08-20 04:31 
       收件人 "Yong Lucy" <[email-masked]>, "Jiang Yuan-long" <[email-masked]>, <[email-masked]>, <[email-masked]>  
              抄送 [email-masked], [email-masked]  
              主题 [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:        [PWE3] An error in RFC 4446"IANA Allocations        for        PseudowireEdge to Edge Emulation (PWE3)" 

        ie 

  Lucy,

  Thanks,

  John

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 20 Aug 2009 13:49:28 +0200

Yuanlong,

IMO, all PW types should be applicable over MPLS-TP, including 0x000B.
This is widely used for IP transport using arp-mediation, where we know
that want to provide a point to point connection between ACs of
different technologies (typically Ethernet and some pt-pt technology
such as Frame Relay).

Matthew 

> Jiang Yuan-long
> Sent: 20 August 2009 03:15
> To: Drake, John E; [email-masked]; [email-masked]

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 20 Aug 2009 15:00:23 +0300

Yuanlong

The reference to an IP PW means the same as it meant in RFC 4447 section 4.1
which itself references RFC 3032 for the format,
except that 4447 also allows the use of a CW.

It certainly does NOT mean IP over L2TPv3 as in the expired draft you referenced.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
Sent: Tuesday, August 18, 2009 16:01
To: [email-masked]
Cc: [email-masked]
Subject: [PWE3] An error in RFC 4446 "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"

Hi, all:

In Sec 3.2, it says:

it should be:

   Thanks,
Yuanlong Jiang

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 20 Aug 2009 15:27:10 +0300

Matthew, Yuan-long and all,
MHO and FWIW RFC 4446 has been created as the placeholder for IANA allocations
needed by RFC 4447 which defines the control place for PWs. These allocations do not
affect the data plane of PWs. 

And hence a naive question: 

	Why are PW types (which belong solely to the PW control plane)
	are relevant for MPLS-TP (which must e able to operate without CP)?

IMHO the relevant question should be:

	Is it possible to carry "pure IP" 9without any Layer 2) as an IP PW across and MPLS-TP domain?

The answer probably is "Yes, but additional manual configuration of PW endpoints is required"
(to replace ARP mediation over LDP).

Regards,
     Sasha

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of BOCCI Matthew
> Sent: Thursday, August 20, 2009 2:49 PM
> To: Jiang Yuan-long; Drake, John E; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [PWE3] An error in RFC 4446 "IANA 
> Allocations for PseudowireEdge to Edge Emulation (PWE3)"
> 
> Yuanlong,
> 
>

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 20 Aug 2009 06:13:48 -0700

Yuanlong Jiang,

The intent of section 3.4.1 is to clarify that as described in RFC 3032,
network layer (e.g., IP and MPLS) payloads can be transported directly
over MPLS and to define a service where this is useful.

That said, we will always have pseudo-wires.

Thanks,

John   

> Sent: Wednesday, August 19, 2009 7:15 PM
> Subject: Re: [PWE3] An error in RFC 4446"IANA Allocations for 
> Please assume that MPLS-TP is interworking with IP/MPLS, and 
> the later is providing IP traffic with PW type 0x000B, how to 
> resolve this kind of scenarios? just terminate the PW and 
> expose the IP packets to be transported on MPLS-TP?
> 
>     Thanks
> Yuanlong Jiang
> 
> To: "Jiang Yuan-long" <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: [PWE3] An error in RFC 4446 "IANA Allocations 
> It describes how client network layer payloads (e.g., IP and 
> MPLS) are carried directly, i.e., without a pseudo-wire, over 
> an MPLS TP server network.
> 
> > As Himanshu said in the last email, 0x000B is actually the 
> PW type for 
> > IP, rather than L2TP PW type for IP. So I believe it is 
> also feasible 
> > for MPLS-TP.
> >
> label stack to 
> > operate in the same manner as client/server layering model, but an 
> > adaptation layer such as PW functions now is indispensable.
> >
> >  Best Regards
> > Yuanlong Jiang
> >
> >
> >
> >
> >
> > that IP traffic units can run native in the DP with MPLS traffic 
> > units), but given we can't have IP in the MPLS-TP DP and we 
> can't have 
> > LDP mp2p merging constructs in MPLS-TP anyway (the latter 
> point is all 
> > about resource management determinism) then the original driver for 
> nothing is 
> > a PW....that is, we just have clients (any) of MPLS-TP.
> >
> > client/server layering), which is also related to the 
> important topic 
> > of being able to do MPLSoverMPLS as a proper client/server 
> > relationship.
> >
> anyway (though 
> > Edge to Edge Emulation (PWE3)"
> >
> >
> > Hi, all:
> >
> > I wonder how about the status of this expired WG draft, 
> will any more 
> > work continue on this document or just expired as it is?
> > I also wonder whether we should define a PW type for IP payload so 
> > that everything on PW is possible.
> > Any comments?
> >
> >    Thanks,
> > Yuanlong Jiang
> >
> >
> > 
> 
>

---

From: Jiang Yuanlong <[email-masked]>
Date: Thu, 20 Aug 2009 23:20:19 +0800

Sasha, Matthew, Yaakov and all,

Thanks for all your clarifications and replies. 

IMO, maybe PW type 0x000B should better reference to RFC 4447,  at least IP 
Layer 2 transport is discussed there:)
When I saw "Layer2 Transport", it comes to me as "L2TP" naturally, 
and by googling "0x000B  IP Layer2 Transport", we can find its definition 
first appeared in draft-pignataro-l2tpext-pwe3-ipl2-00. These all add up to
the misunderstanding.

However, from your replies, maybe we can draw a conclusion here:
1) PWE3 has defined a PW type 0x000B for IP transport over PW;
2) This PW should also be applicable in MPLS-TP;
3) IP transport over PW is also possible in MPLS-TP.

Any other viewpoints?

   Thanks 
Yuanlong Jiang

----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: "BOCCI Matthew" <[email-masked]>; "Jiang Yuan-long" <[email-masked]>
Cc: "Drake, John E" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, August 20, 2009 8:27 PM
Subject: RE: [mpls-tp] [PWE3] An error in RFC 4446 "IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

Regards,
     Sasha

> =

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 20 Aug 2009 12:30:11 -0400

Hi Yuanlong,

One small comment in addition to what Yaakov said: Note the difference
between these two registries, that might be part of the confusion:

MPLS Pseudowire Types Registry at <http://www.iana.org/assignments/pwe3-parameters>
L2TPv3 Pseudowire Types at <http://www.iana.org/assignments/l2tp-parameters>

As Yaakov said, the "IP Layer2 Transport" MPLS PW Type is at
http://tools.ietf.org/html/rfc4447#section-4.1.

Thanks,

-- Carlos.

On 8/20/2009 8:00 AM, Yaakov Stein wrote:
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Jiang Yuan-long
> *Sent:* Tuesday, August 18, 2009 16:01
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [PWE3] An error in RFC 4446 "IANA Allocations for
> http://www.iana.org/assignments/pwe3-parameters.
>
> ------------------------------------------------------------------------
>
> L2tpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l2tpext
>

---

From: Yong Lucy <[email-masked]>
Date: Thu, 20 Aug 2009 14:14:06 -0500

Hi Jiang and John,

IMO. MPLS-TP supports two types of client: client network layer and client
non-network layer. IP can be as client in both cases. The matter is that
transport characteristics in two methods have some differences. As the
result, to carry a L3 network client, it is required to use the service
label. This is what I try to get clarification from John.

In fact, both PW label and service label are the bottom label. (S=1). This
is the importance. Separating them is to distinguish server transport
methods, not much to the payload itself. 

Regards,

Lucy

  _____  

From: Jiang Yuan-long [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2009 10:20 PM
To: [email-masked]; Drake, John E
Cc: [email-masked]; Yong Lucy; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee
RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge
Emulation (PWE3)"

Hi Liu,

Thanks,

Yuanlong

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

To: Drake, John E <mailto:[email-masked]>  

Cc: [email-masked] ; Yong Lucy <mailto:[email-masked]>  ;
[email-masked] ; [email-masked] ; [email-masked] ;
[email-masked] ; Jiang Yuan-long <mailto:[email-masked]>  

Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:
[PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge
Emulation (PWE3)"

hi,all 

how about all? 

best regards 
liu

2009-08-20 04:31 

收件人

抄送

主题

[mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:        [PWE3]
An error in RFC 4446"IANA Allocations        for        PseudowireEdge to
Edge Emulation (PWE3)"

ie

Lucy,

Thanks,

John  

Allocations for 

> > >                                   I wonder how about the status of
this expired 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Jiang Yuan-long <[email-masked]>
Date: Fri, 21 Aug 2009 09:59:02 +0800

Lucy, 

Please see my comments inline.

  Thanks 
Yuanlong Jiang
  ----- Original Message ----- 
  From: Yong Lucy 
  To: 'Jiang Yuan-long' ; [email-masked] ; 'Drake, John E' 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Friday, August 21, 2009 3:14 AM
  Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

  Hi Jiang and John,

  IMO. MPLS-TP supports two types of client: client network layer and client non-network layer. IP can be as client in both cases. The matter is that transport characteristics in two methods have some differences. As the result, to carry a L3 network client, it is required to use the service label. This is what I try to get clarification from John.

  [J]: I don't understand what you meant in the differences of transport characteristics (in the last Email, you said the PW does not guarantee link characteristics),IMO, PW can also be a bidrectional p2p connection. >From the discussion with Matthew and Sasha, I think the service label may be a PW label actually.

  In fact, both PW label and service label are the bottom label. (S=1). This is the importance. Separating them is to distinguish server transport methods, not much to the payload itself. 

  [J]: Yes, in the data plane, PW label and service label is undistinguishable. But how the egress node will process the demultiplexed IP payload? I think there are some subtle processing differences: 

    1) If the bottom label is a non-PW label, then the IP packet will be routed, as in L3VPN; 

    2) If the bottom label is a PW label, then the IP packet will just be encapsulated with some data link header and forwarded (no routing is needed), as arp-mediation draft demonstrates. 

  Do you think so?

  Regards,

  Lucy

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

  From: Jiang Yuan-long [mailto:[email-masked]] 
  Sent: Wednesday, August 19, 2009 10:20 PM
  To: [email-masked]; Drake, John E
  Cc: [email-masked]; Yong Lucy; [email-masked]; [email-masked]; [email-masked]; [email-masked]
  Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

  Hi Liu,

  Thanks,

  Yuanlong

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

    To: Drake, John E 

    hi,all 

    how about all? 

    best regards 
    liu

          2009-08-20 04:31 
         收件人
               "Yong Lucy" <[email-masked]>, "Jiang Yuan-long" <[email-masked]>, <[email-masked]>, <[email-masked]> 
               
                抄送
               
                主题
               [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:        [PWE3] An error in RFC 4446"IANA Allocations        for        PseudowireEdge to Edge Emulation (PWE3)"

                

          ie

    Lucy,

    Thanks,

    John  

--------------------------------------------------------ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Fri, 21 Aug 2009 10:37:35 +0100

Colleagues,
 
I think there are some important issues here that appear not to be being tackled correctly...and if we do not get our thinking/arch straight here these issues will not go away but surface time and time again until we are finally forced to properly resolve them.  Here is my take on the salient points.
 
1    I saw an astute observation from Sasha on the PW CP.  And he was right to raise this.  This harps back to my long-standing observation to PWE3 that once PWs become multi-hop they create a new co-ps layer network above MPLS instead of being just client/server adaptation function (1-hop case).  The deeper history behind this is related to (i) the requirement in MPLS LDP for IP to run raw in the DP to provide CP/MP functions, and (ii) the fact that LDP creates mp2p merging LSP constructs.  The important consequence of the latter point being that a PW label must convey source information semantics to recover this lost information due to lower level LDP LSP merging.  There is a further, and still largely unrecognised IMO, problem in that when PWs move from 1-hop to multi-hop entities the PW label needs to change semantic from 'source information' to 'forwarding information'......I explained this issue in detail in a (PWE3) mail to Matthew Bocci  29/11/2008...I attach for ease of reference.
 
====

2    In MPLS-TP we need to be able to deterministically manage resource (because MPLS-TP is supposed to be a next gen transport network, and resource management is a principle requirement of transport networks).  This means we must only create p2p and p2mp LSPs in MPLS-TP.....mp2p LSPs do not allow deterministic resource management because they are not single source *connection* constructs (G.800 explains why this is so). 
 
In MPLS-TP we are also required to take the CP/MP IP-based protocols out of the traffic DP and run them in the logically OOB G-ACH link between adjacent MPLS-TP nodes.....so this correctly follows the OOB CP/MP behaviour we are forced to use for the co-cs mode in GMPLS.  
 
All these factors mean that the arch conditions that created PWs in MPLS no longer exist in MPLS-TP.  Put very simply/bluntly, there is no reason to have PWs in MPLS-TP at all....that is just a technical fact.  However, such a bald technical statement could be considered rather embarrassing (for want of a better word) given how much effort has gone into PW related topics so far.  Given this, what we can therefore do is keep PWs, in-name at least, but be very clear we must not create a co-ps mode PW layer network above MPLS-TP.   And this is a very good thing because we can avoid generating a whole raft of DP/CP/MP functions unnecessarily....which addresses Sasha's observation on the PW CP above, ie there is no need for a PW CP because there is not a PW layer network in MPLS-TP, and its also addresses my previous point on the changing nature of a PW label, ie the problem goes away because MS PWs are not allowed in MPLS-TP.
 
===

3    Let me now turn to section 3.4.1 of the draft under discussion.  Firstly, I see talk of 'network layer' protocols which harps back to the flawed OSI Ref Model architecture.  We really should leave the OSI RM behind now because we should know (especially those who have been exposed to functional architecture, and in particular G.800 unified modelling of networks) that any technology that has routing/switching is a 'network layer' protocol by definition.  Further, the L1, L2 and L3 classifications of technology are meaningless at best, and the only thing that really matters is the cl-ps, co-ps and co-cs mode classification of networks....no mode is more important than the others, but each is different and all are required in a complete network architecture model.
 
===

4    It would appear from from what is said in section 3.4.1 that (i) we can miss-out the PW adaptation for *DP* IP, MPLS and MPLS-TP clients and (ii) we can select an arbitrary/normal forwarding label to identify each of these clients (S=1 in this BOS header).  I don't think this is a good idea.
 
Let me deal with the 2nd issue first:  This works fine under defect-free conditions.  But what about the case of misconnectivity (including unintended replication/merging defects)?  So here it would seem that we have a 1st-order combinatorial '2 out of 4' potential misconnectivity problem, ie across IP/MPLS/MPLS-TP/PW cases (its actually worse than this as MPLS is not singular).  If we are serious about using this 'BOS label' technique to identify the client carried under all conditions (ie including all misconnectivity cases) we really should be using labels that have a globally well-known semantic.  In func arch speak we are creating a case of consistent CI...and this is also why the OAM used on each LSP in the whole network needs to be the same, ie under any case of misconnectivity the receiving node knows how to parse and read the semantic of the information it sees (be this a label/header or OAM).
 
Wrt to the 1st issue above:  IMO it would be usually be preferable to have a single/consistent way to deal with all clients.  So no matter what they are they would always be encapsulated via a common PW adaptation function (which can include a common PID function).  This is a cleaner/consistent architectural approach.
 
====

5    There is an important issue I ducked above (on purpose, because it warrants examination on its own), and that is LSP nesting as sublayers, ie the S bit issue.  This is particularly important because there will be a requirement on MPLS-TP to be able to create a functionally decoupled case of MPLS-TPoverMPLS-TP....that is, where the MPLS-TP layer network of one party is carried transparently (all 3 traffic/control/management planes) over the (*traffic DP*) of a server MPLS-TP layer network owned by a different party.
 
 In the past we have discussed dealing with this by the insertion of a degenerate 1-hop Ethernet PW to create a 'functional breakwater' between the 2 MPLS networks.  This however in neither elegant nor efficient.  So we need a better solution IMO.
 
In the past I suggested we should select a special label from the reserved set (ie 0-15) to identify this functional breakwater between different LSP stacks (so the S bit could be treated independently in each.  So this approach would tie-in with the first case issue discussed under item 4 above, ie MPLS-TP as a client would have its own special label (just like the IP and MPLS cases too).
 
Alternatively we could use the approach discussed under the second case in item 4 above, ie a consistent treatment of all clients using a common PW adaptation (that could include a common PID function).
 
===
 
I assume some/all of the above has been discussed within the MEAD team, and it would be useful to hear what analysis/conclusions were reached on the above topics and why this was.
 
Would someone from the MEAD team (Stewart or Adrian maybe?) be able to comment on the above please?
 
thanks.....regards, Neil

	From: Jiang Yuan-long [mailto:[email-masked]] 
	Sent: 21 August 2009 02:59
	To: Yong Lucy; [email-masked]; 'Drake, John E'
	Cc: [email-masked]; Harrison,N,Neil,DEY2 R; [email-masked]
	Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

	Lucy, 

	  Thanks 
	Yuanlong Jiang

		----- Original Message ----- 
		From: Yong Lucy <mailto:[email-masked]>  
		To: 'Jiang Yuan-long' <mailto:[email-masked]>  ; [email-masked] ; 'Drake, John E' <mailto:[email-masked]>  
		Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
		Sent: Friday, August 21, 2009 3:14 AM
		Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

		Hi Jiang and John,

		[J]: I don't understand what you meant in the differences of transport characteristics (in the last Email, you said the PW does not guarantee link characteristics),IMO, PW can also be a bidrectional p2p connection. From the discussion with Matthew and Sasha, I think the service label may be a PW label actually.

		Do you think so?

		Regards,

		Lucy

		Hi Liu,

		Thanks,

		Yuanlong

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

			Cc: [email-masked] ; Yong Lucy <mailto:[email-masked]>  ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; Jiang Yuan-long <mailto:[email-masked]>  

			
			hi,all 
			
			how about all? 
			
			best regards 
			liu

			

2009-08-20 04:31 

收件人

抄送

主题

 

ie

			
			Lucy,

			
			Thanks,
			
			John  

			

Subject: RE: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Sat, 29 Nov 2008 10:43:20 +0100

Thank you Matthew.

I suspect I'm not getting across my point clearly enough.  So let me
have one more go and see if this helps.

The problems relate to the way MPLS as-is is defined.....and where
MPLS-TP is trying to correct some of these problems.

Here the specific problem is that if LDP (and/or PHP) is used then we
have a merging behaviour of symbols and thus we lose
information...specifically SA information.  Normally in the co-ps mode
this is not an issue as a connection MUST only have a single source, and
thus we do not have to add this (SA) information to the (child) traffic
units as this information is carried by the (parent) connection itself
(and known to the CP/MP).  Of course, if you violate the rules of a
connection then one suffers other problems besides a loss of SA
information, eg significant increase in OAM complexity,
non-deterministic resource management, etc. with the consequence that
the whole network has to both designed and operated to the demands of
the single most stringent customer SLA in force...so the consequences of
merging are more serious than simply a loss of SA information.

When a client of a server layer merging construct is cl-ps, such as IP,
these clients MUST carry SA in each/every traffic unit....because they
don't have a parent connection to convey this information in their layer
network by definition.  So here the loss of information in the (server)
LDP (PHP) construct is not a problem as the client can recover this
information (providing the SAs are unique in the client layer network).

So, when the client is not cl-ps (most of the PW cases) we have no
choice but to add information that recovers from the loss of SA due to
server layer LDP (PHP) merging.....in other words a PW label MUST be a
proxy for SA, and indeed this is what it is.  So providing a PW entity
is not networked (ie only 1-hop) this all works fine/good (at least
under no misconnectivity defects).

However, if we want to create a MH PW entity with flexibility of routing
choice (and don't forget there are issue of MH PW protection-switching
here which highlight the same 'flexibility of routing' requirement) then
we create a co-ps networked entity.  Now providing we don't go and
violate the rules of a connection again for this PW entity (ie only
allow it to have a single source) then its traffic units MUST contain a
label that is used for forwarding.....and this, by definition, MUST be a
proxy for the DA (assuming we are using the traditional label-swapping
approach to forwarding in the co-ps mode).

Even if the SA was provided in such traffic units a SA is NEVER used for
forwarding.....not even in the cl-ps mode.

Further, a solution to the MH PW client case SHOULD take into account
the situation where each of the link connections (ie hops) of the MH PW
are provide by *different* MPLS (or even IP) server layer PSNs....and
each of these server layer partitions could belong to a different
operating party.

For example, consider the following case:

Imagine a 3 hop MH PW, so this has 4 nodes and 3 link connections (can
extend argument to an arbitrary number of hops)

	o-----------o-----------o-----------o
	A		B		C		D

Assume the server link connections A-B and B-C are using LDP and server
layer link connection C-D is using RSVP-TE.  

This means there will be *independent* merging LSPs (of some arbitrary
number of LDP hops) in each of the A-B and B-C links.  Thus when a
client PW traffic unit from A arrives at B, B will not know it came from
A unless we add information to identify A as the source.  Similarly,
when the PW client traffic unit is sent from B to C, C will not know it
came from B unless we add information to identify B as the source (in
*this* server LDP network partition B-C).  We don't have this problem on
the link C-D because a server layer RSVP-TE LSP respects the rules of a
connection and conveys the information of C being the source of *this*
server layer link connection to D.

The labelling could work like this:

Node A imposes 3 labels:  {LDP(A-B) + Demerge(A-B)} + MHPW(A-B).  

The last label (ie MHPW(A-B)) is a normal DA forwarding label for the
MHPW A-B-C-D and it will get swapped at nodes B and C.  The former 2
labels MUST be a pair and both get removed at node B....the LDP(A-B)
label is normal forwarding across the 1st LDP network server partition
whilst the Demerge(A-B) label removes the merging in this partition, ie
to identify the MHPW as from A.

At node B the LDP(A-B) + Demerge(A-B) labels are both removed, MHPW(A-B)
label is swapped to a MHPW(B-C) label and a new pair of LDP(B-C) +
Demerge(B-C) labels imposed to get across the 2nd LDP server layer
partition.  

At node C the LDP(B-C) + Demerge(B-C) labels get removed, MPHW(B-C)
label is swapped to MHPW(C-D) label and a *single* server layer
RSVP-TE(C-D) label added.

There is no need for an end-end SA label for the MH PW *providing* there
is no merging in the PW layer.

Now we should also note at this point that there can be no notion of a
"common (ie same instance of) CP" (usually meant to imply a routing
component, but this applies to all DP/CP/MP components) straddling the
MH PW and each of the (independent) server layer MPLS networks.  Nothing
new here, the folks working on GMPLS have had to come to terms with this
issue over the years.....and as one of my colleagues said to me recently
(in the context of G.800, and directly applicable to this issue) "you
can only configure what already exists"....quite.....and putting this
slightly differently for this specific case, the routing process for the
MH PW MUST assume a different process *has already* created each of its
link connections...as these are end-end network connections in each of
the server MPLS partitions.

Hope that helps and is now clear.

regards, Neil 

> From: BOCCI Matthew [mailto:[email-masked]] 
> Sent: 28 November 2008 15:49
> To: Harrison,N,Neil,CXM R; [email-masked]
> Cc: Niven-jenkins,B,Ben,DMF R; [email-masked]
> Subject: RE: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> 
> 
>  Neil,
> 
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 27 November 2008 19:09
> > To: [email-masked]; BOCCI Matthew
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> > 
> > This is now raising questions about the semantic of the PW 
> label and 
> > the relationship of the MPLS/IP server layer CP/MP and PW CP/MP.
> > 
> > In vanilla LDP MPLS where we have mp2p merging LSPs constructs (PHP 
> > also creates merging but only on the last
> > hop) one loses information of the source.  Not a problem if 
> the client 
> > is IP as each client traffic unit carries a SA that compensates for 
> > the loss of SA information due to the lower level LDP/PHP merging.  
> > However, when one has PW clients the PW label must act as a 
> proxy for 
> > a SA of the PW.
> > For single-hop PWs there is no problem as these are not networked 
> > entities.  But when we have multi-hop PWs we do have a networked 
> > entity...and as Matthew notes below in response to Ben:
> > 
> > BNJ=> > to me that where the PSN domains are of the same 
> type then a 
> > simple
> > > > label swap ala
> > > > RFC3031 can always be performed but this is not true if the PW 
> > > > demultiplexer is an L2TP session ID or UDP port as allowed
> > > by RFC3985.
> > > 
> > MB=> Agreed. What we were trying to say was that a swap of the PW
> > > demultiplexer is performed, which in the case of MPLS is a
> > label swap.
> > 
> > The first problem here is that PW labels were originally 
> never meant 
> > to change as they were acting as a SA proxy across a single 
> hop (this 
> > was when PWs were more like an adaptation function and thus not a 
> > networked entity).  But with multi-hop PWs one really wants 
> the label 
> > to act as a DA proxy for forwarding.....and traditionally such DA 
> > proxy labels get swapped hop by hop by co-ps mode networks.
> > 
> > So what semantics does a multi-hop PW label now convey?
> 
> The semantic is the same as in the single segment case. The 
> label is the context representing th FEC for the PW, which is 
> the destination AC in both cases.
> 
> In common with other co-ps networks, we would rely on OAM to 
> detect and diagnose defects, but that is out of scope of the 
> architecture draft.
> There is some ongoing work on OAM for MS-PWs in 
> draft-ietf-pwe3-segmented-pw to address MS-PW OAM, and the 
> MPLS-TP OAM work will be applicable to MS-PWs as well.  
> 
> 
> > 
> > A further issue arises wrt the relationship of the CP/MP of the 
> > multi-hop PW entity (esp the route calculations of such) when it is 
> > served by 2 or more MPLS/IP server layer partitions that may be 
> > owned/operated by different parties.
> 
> The MS-PW routing domain is distinct from the PSN routing 
> domain (except of course that PSN tunnels and PW segments 
> terminate on the same nodes).
> However, I do agree with you that it becomes more complex if 
> you have either MPLS and IP PSN partitions, but the details 
> of how to implement this are really outside the scope of this draft.
> 
> Thanks
> 
> Matthew
> 
> 
> > 
> > regards, Neil
> >  
> > 
> > > Of Reshad Rahman (rrahman)
> > > Sent: 27 November 2008 13:37
> > > To: BOCCI Matthew
> > > Cc: Niven-jenkins,B,Ben,DMF R; pwe3
> > > Subject: Re: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> > > 
> > > Hi,
> > > 
> > > In the example below from section 1.1, PE2 is acting both as S-PE 
> > > (with
> > > PE1 and PE4 acting as T-PEs) and also as T-PE (for "local" 
> > > traffic), but I assume that for a given PW a node only 
> has one role?
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > >    Consider a single PWE3 domain, such as that shown in Figure 1. 
> > > There
> > >    are 4 PEs, and PWE3 must be provided from any PE to any
> > other PE.  
> > >    With SS-PWs, PWE3 would be achieved by establishing a
> > full mesh of
> > >    PSN tunnels between the PEs, requiring a full mesh of
> > LDP signaling
> > >    adjacencies between the PEs. Pseudowires would therefore be 
> > >    established between any PE and any other PE via a 
> single, direct 
> > > PSN
> > >    tunnel that is switched only by intermediate P-routers
> > (not shown
> > > in
> > >    the figure). A PE must terminate all the pseudowires that are 
> > > carried
> > > 
> > >    on the PSN tunnels that terminate on that PE according to the 
> > >    architecture of RFC 3985. This solution is adequate for small 
> > > numbers
> > > 
> > >    of PEs, but the number of PEs, PSN tunnels and signaling 
> > > adjacencies
> > >    will grow in proportion to the square of the number of PEs.  
> > > 
> > >    A more efficient solution for large numbers of PEs would be to 
> > >    support a partial mesh of PSN tunnels between the PEs,
> > as shown in
> > >    Figure 1. For example, consider a PWE3 service whose
> > endpoints are
> > >    PE1 and PE4. Pseudowires for this can take the path
> > PE1->PE2->PE4,
> > >    and rather than terminating at PE2, be switched between
> > ingress and
> > >    egress PSN tunnels on that PE. This requires a 
> capability in PE2 
> > > that
> > > 
> > >    can concatenate PW segments PE1-PE2 to PW segments PE2-PE4. The
> > > end-
> > >    to-end PW is known as a multi-segment PW. 
> > > 
> > >                                 ,,..--..,,_ 
> > >                             .-``           `'., 
> > >                     +-----+`                   '+-----+ 
> > >                     | PE1 |---------------------| PE2 | 
> > >                     |     |---------------------|     | 
> > >                     +-----+      PSN Tunnel     +-----+ 
> > >                     / ||                          || \ 
> > >                    /  ||                          ||  \ 
> > >                   |   ||                          ||   | 
> > >                   |   ||         PSN              ||   | 
> > >                   |   ||                          ||   | 
> > >                    \  ||                          ||  / 
> > >                     \ ||                          || / 
> > >                      \||                          ||/ 
> > >                     +-----+                     +-----+ 
> > >                     | PE3 |---------------------| PE4 | 
> > >                     |     |---------------------|     | 
> > >                     +-----+`'.,_           ,.'` +-----+ 
> > >                                 `'''---''`` 
> > >          Figure 1 Single PSN PWE3 with Partial Mesh of PSN Tunnels
> > >  
> > > 
> > > Of BOCCI Matthew
> > > Sent: Monday, November 24, 2008 10:56 AM
> > > To: Ben Niven-Jenkins; pwe3
> > > Subject: Re: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt
> > > 
> > > Ben,
> > > 
> > > Many thanks for your comments. Please see below.
> > > 
> > > Regards
> > > 
> > > Matthew
> > >  
> > > 
> > > > Colleagues,
> > > > 
> > > > While I read draft-ietf-pwe3-ms-pw-arch-05.txt I came up
> > > with a couple
> > > 
> > > > of comments/qeustions - see below.  Overall I think this
> > is a good
> > > > document and should be progressed.
> > > > 
> > > > Ben
> > > > 
> > > > 
> > > > Section 3.
> > > > " That is, 
> > > >    although a PW segment will follow the path of the PSN tunnel 
> > > > between
> > > >    S-PEs, the MS-PW is independent of the PSN tunnel routing,
> > > >    operations, signaling and maintenance."
> > > > 
> > > > What about T-PEs?
> > > 
> > > Agreed. That should read "...tunnel between S-PEs and 
> between S-PEs 
> > > and T-PEs, the MS-PW is independent..."
> > > 
> > > > 
> > > > Section 3.1
> > > > I am confused by your use of the term "layer" in the following:
> > > > 
> > > > "   PWE3 defines the Encapsulation Layer, i.e. the method 
> > > of carrying
> > > >    various payload types, and the interface to the PW
> > Demultiplexer
> > > >    Layer. It is expected that other layers will provide the
> > > following:
> > > > 
> > > >       . PSN tunnel setup, maintenance and routing
> > > > 
> > > >       . T-PE discovery "
> > > > 
> > > > To me encapsulation, demultiplexing and T-PE discovery are not 
> > > > separate layers but separate functions but if I'm the
> > only one that
> > > > thinks this then I'll concede to the use of layer in 
> this context.
> > > 
> > > These are functions, but they are provided by layers
> > outside of PWE3,
> > > assuming that e.g. the PSN is treated as a separate layer 
> from the 
> > > MS-PW. The last sentence above the bullets should be reworded to 
> > > explain this better.
> > > 
> > > 
> > > > 
> > > > Section 6
> > > > " Where the ingress and
> > > >    egress PSN domains of the S-PE are of the same type
> > e.g. they are
> > > >    both MPLS PSNs, a simple label swap operation is 
> performed, as
> > > >    described in RFC 3031 [5] Section 3.13."
> > > > 
> > > > Is the use of simple label swap only an example here? The
> > > text implies
> > > 
> > > > to me that where the PSN domains are of the same type
> > then a simple
> > > > label swap ala
> > > > RFC3031 can always be performed but this is not true if the PW 
> > > > demultiplexer is an L2TP session ID or UDP port as allowed
> > > by RFC3985.
> > > 
> > > Agreed. What we were trying to say was that a swap of the PW 
> > > demultiplexer is performed, which in the case of MPLS is a
> > label swap.
> > > 
> > > > 
> > > > Section 10
> > > > " each S-PE is a new point at which defects may occur
> > > >    along the path of the PW. In order to troubleshoot MS-PWs, 
> > > > management
> > > >    and monitoring should be able to operate on a subset of the 
> > > > segments
> > > >    of an MS-PW, as well as edge-to-edge. That is, connectivity
> > > >    verification mechanisms should be able to troubleshoot and
> > > >    differentiate the connectivity between T-PEs and 
> intermediate 
> > > > S-PEs,
> > > >    as well as T-PE to T-PE.  "
> > > > 
> > > > Have you consciously omitted S-PE to S-PE connectivity
> > verification?
> > > 
> > > No. We certainly need to include that case. I'll add this
> > to the list
> > > of mechanisms.
> > > 
> > > 
> > > >

---

From: <[email-masked]>
Date: Fri, 21 Aug 2009 17:46:50 +0100

Thanks Igor.  I'm glad someone else gets this.  We are at a watershed opportunity with MPLS-TP now.  IMO it would be very sad if we did not 'come-clean' on some of the quite significant arch issues that have dogged MPLS for a long time and fix them properly when we have the chance to.  I'd also caution against over-complexity in the DP...esp wrt OAM and Perf Monitoring metrics/objectives....we really only need a fairly simple approach here (I've outlined my views on this many times in the past so will not repeat here).
 
I hope others share these views.
 
regards, Neil

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: 21 August 2009 17:18
	To: Harrison,N,Neil,DEY2 R; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:[PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

	Hi Neil,

	I understand and share your concerns.

	I think we (IETF folks) made a subtle yet important mistake by agreeing to define MPLS-TP as a subset of MPLS needed to support packet switched transport networks. Such definition does not really define how MPLS relates to MPLS-TP. In fact, MPLS-TP becomes increasingly a superset of MPLS. What should be done IMO is as follows:

	1.	Separate MPLS into two distinct layers: 

	a)     MPLS Service layer (VPNs. PWs, VPLS, etc.);

	b)     MPLS transport layer (label-switched transport for MPLS Service layer with traffic engineering capabilities)

	2.	Call the lower layer MPLS-TP and concentrate on its enhancements: 

	a)     Make it work without CP’

	b)     Make it work for different address families;

	c)     Expose it to other clients;

	d)     Extend and improve its OAM; 

	e)     Etc.

	The important advantages of such architectural approach are:

	1.	It would be cleat for everyone how MPLS-TP relates to MPLS - it is its lower layer, nothing more and nothing less. For example. It would; be clear that PWs are NOT a part of the MPLS-TP, there is no difference between MPLS PWs and MPLS-TP PWs, and if there is anything wrong with PWs, it should be fixed outside of the MPLS-TP effort; 
	2.	It would be also clear the importance of perseverance of MPLS OAM wherever possible, and bringing in new (e.g. Y.1731) functionality only when/lf needed; 
	3.	It would provide a niche for (e.g. Ethernet) vendors to develop “pure” MPLS-TP LSRs without necessarily providing full MPLS Service layer functionality. 

	Cheers,

	Igor  

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Friday, August 21, 2009 5:38 AM
	To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

	Colleagues,

	====

	===

	===

	====

	===

	thanks.....regards, Neil

		Lucy, 

		  Thanks 

		Yuanlong Jiang

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

			Hi Jiang and John,

			Do you think so?

			Regards,

			Lucy

			Hi Liu,

			Thanks,

			Yuanlong

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

				
				hi,all 
				
				how about all? 
				
				best regards 
				liu

				

2009-08-20 04:31 

收件人

抄送

主题

 

ie

				
				Lucy,

				
				Thanks,
				
				John

---

From: Yong Lucy <[email-masked]>
Date: Fri, 21 Aug 2009 14:45:31 -0500

Two-layers approach is better framework! This also enables MPLS transport
layer supporting non-MPLS service layer such as Ethernet service layer.

Lucy

  _____  

From: Mark Sandstrom [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 12:50 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D -
NeeRE:[PWE3] An error in RFC 4446"IANA Allocationsfor PseudowireEdge to Edge
Emulation (PWE3)"

I largely agree with Neil’s views, as well as Igor’s point regarding need
for MPLS-TP transport plane standard to allow developing generic, low cost /
Gbps pure-L2 MPLS-TP LSRs that do not need to support the L2+ MPLS services
layer functions.  

Best regards,

Mark Sandstrom

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, August 21, 2009 10:47 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D -
NeeRE:[PWE3] An error in RFC 4446"IANA Allocationsfor PseudowireEdge to Edge
Emulation (PWE3)"

Thanks Igor.  I'm glad someone else gets this.  We are at a watershed
opportunity with MPLS-TP now.  IMO it would be very sad if we did not
'come-clean' on some of the quite significant arch issues that have dogged
MPLS for a long time and fix them properly when we have the chance to.  I'd
also caution against over-complexity in the DP...esp wrt OAM and Perf
Monitoring metrics/objectives....we really only need a fairly simple
approach here (I've outlined my views on this many times in the past so will
not repeat here).

regards, Neil

  _____  

From: Igor Bryskin [mailto:[email-masked]] 
Sent: 21 August 2009 17:18
To: Harrison,N,Neil,DEY2 R; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee
RE:[PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge
Emulation (PWE3)"

Hi Neil,

I think we (IETF folks) made a subtle yet important mistake by agreeing to
define MPLS-TP as a subset of MPLS needed to support packet switched
transport networks. Such definition does not really define how MPLS relates
to MPLS-TP. In fact, MPLS-TP becomes increasingly a superset of MPLS. What
should be done IMO is as follows:

b)       MPLS transport layer (label-switched transport for MPLS Service
layer with traffic engineering capabilities)

e)       Etc.

1.	It would be cleat for everyone how MPLS-TP relates to MPLS - it is
its lower layer, nothing more and nothing less. For example. It would; be
clear that PWs are NOT a part of the MPLS-TP, there is no difference between
MPLS PWs and MPLS-TP PWs, and if there is anything wrong with PWs, it should
be fixed outside of the MPLS-TP effort; 
2.	It would be also clear the importance of perseverance of MPLS OAM
wherever possible, and bringing in new (e.g. Y.1731) functionality only
when/lf needed; 
3.	It would provide a niche for (e.g. Ethernet) vendors to develop
“pure” MPLS-TP LSRs without necessarily providing full MPLS Service layer
functionality. 

Cheers,

Igor  

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, August 21, 2009 5:38 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:
[PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge
Emulation (PWE3)"

Colleagues,

I think there are some important issues here that appear not to be being
tackled correctly...and if we do not get our thinking/arch straight here
these issues will not go away but surface time and time again until we are
finally forced to properly resolve them.  Here is my take on the salient
points.

1    I saw an astute observation from Sasha on the PW CP.  And he was right
to raise this.  This harps back to my long-standing observation to PWE3 that
once PWs become multi-hop they create a new co-ps layer network above MPLS
instead of being just client/server adaptation function (1-hop case).  The
deeper history behind this is related to (i) the requirement in MPLS LDP for
IP to run raw in the DP to provide CP/MP functions, and (ii) the fact that
LDP creates mp2p merging LSP constructs.  The important consequence of the
latter point being that a PW label must convey source information semantics
to recover this lost information due to lower level LDP LSP merging.  There
is a further, and still largely unrecognised IMO, problem in that when PWs
move from 1-hop to multi-hop entities the PW label needs to change semantic
from 'source information' to 'forwarding information'......I explained this
issue in detail in a (PWE3) mail to Matthew Bocci  29/11/2008...I attach for
ease of reference.

====

2    In MPLS-TP we need to be able to deterministically manage resource
(because MPLS-TP is supposed to be a next gen transport network, and
resource management is a principle requirement of transport networks).  This
means we must only create p2p and p2mp LSPs in MPLS-TP.....mp2p LSPs do not
allow deterministic resource management because they are not single source
*connection* constructs (G.800 explains why this is so). 

In MPLS-TP we are also required to take the CP/MP IP-based protocols out of
the traffic DP and run them in the logically OOB G-ACH link between adjacent
MPLS-TP nodes.....so this correctly follows the OOB CP/MP behaviour we are
forced to use for the co-cs mode in GMPLS.  

All these factors mean that the arch conditions that created PWs in MPLS no
longer exist in MPLS-TP.  Put very simply/bluntly, there is no reason to
have PWs in MPLS-TP at all....that is just a technical fact.  However, such
a bald technical statement could be considered rather embarrassing (for want
of a better word) given how much effort has gone into PW related topics so
far.  Given this, what we can therefore do is keep PWs, in-name at least,
but be very clear we must not create a co-ps mode PW layer network above
MPLS-TP.   And this is a very good thing because we can avoid generating a
whole raft of DP/CP/MP functions unnecessarily....which addresses Sasha's
observation on the PW CP above, ie there is no need for a PW CP because
there is not a PW layer network in MPLS-TP, and its also addresses my
previous point on the changing nature of a PW label, ie the problem goes
away because MS PWs are not allowed in MPLS-TP.

===

3    Let me now turn to section 3.4.1 of the draft under discussion.
Firstly, I see talk of 'network layer' protocols which harps back to the
flawed OSI Ref Model architecture.  We really should leave the OSI RM behind
now because we should know (especially those who have been exposed to
functional architecture, and in particular G.800 unified modelling of
networks) that any technology that has routing/switching is a 'network
layer' protocol by definition.  Further, the L1, L2 and L3 classifications
of technology are meaningless at best, and the only thing that really
matters is the cl-ps, co-ps and co-cs mode classification of networks....no
mode is more important than the others, but each is different and all are
required in a complete network architecture model.

===

4    It would appear from from what is said in section 3.4.1 that (i) we can
miss-out the PW adaptation for *DP* IP, MPLS and MPLS-TP clients and (ii) we
can select an arbitrary/normal forwarding label to identify each of these
clients (S=1 in this BOS header).  I don't think this is a good idea.

Let me deal with the 2nd issue first:  This works fine under defect-free
conditions.  But what about the case of misconnectivity (including
unintended replication/merging defects)?  So here it would seem that we have
a 1st-order combinatorial '2 out of 4' potential misconnectivity problem, ie
across IP/MPLS/MPLS-TP/PW cases (its actually worse than this as MPLS is not
singular).  If we are serious about using this 'BOS label' technique to
identify the client carried under all conditions (ie including all
misconnectivity cases) we really should be using labels that have a globally
well-known semantic.  In func arch speak we are creating a case of
consistent CI...and this is also why the OAM used on each LSP in the whole
network needs to be the same, ie under any case of misconnectivity the
receiving node knows how to parse and read the semantic of the information
it sees (be this a label/header or OAM).

Wrt to the 1st issue above:  IMO it would be usually be preferable to have a
single/consistent way to deal with all clients.  So no matter what they are
they would always be encapsulated via a common PW adaptation function (which
can include a common PID function).  This is a cleaner/consistent
architectural approach.

====

5    There is an important issue I ducked above (on purpose, because it
warrants examination on its own), and that is LSP nesting as sublayers, ie
the S bit issue.  This is particularly important because there will be a
requirement on MPLS-TP to be able to create a functionally decoupled case of
MPLS-TPoverMPLS-TP....that is, where the MPLS-TP layer network of one party
is carried transparently (all 3 traffic/control/management planes) over the
(*traffic DP*) of a server MPLS-TP layer network owned by a different party.

 In the past we have discussed dealing with this by the insertion of a
degenerate 1-hop Ethernet PW to create a 'functional breakwater' between the
2 MPLS networks.  This however in neither elegant nor efficient.  So we need
a better solution IMO.

In the past I suggested we should select a special label from the reserved
set (ie 0-15) to identify this functional breakwater between different LSP
stacks (so the S bit could be treated independently in each.  So this
approach would tie-in with the first case issue discussed under item 4
above, ie MPLS-TP as a client would have its own special label (just like
the IP and MPLS cases too).

Alternatively we could use the approach discussed under the second case in
item 4 above, ie a consistent treatment of all clients using a common PW
adaptation (that could include a common PID function).

===

I assume some/all of the above has been discussed within the MEAD team, and
it would be useful to hear what analysis/conclusions were reached on the
above topics and why this was.

Would someone from the MEAD team (Stewart or Adrian maybe?) be able to
comment on the above please?

thanks.....regards, Neil

  _____  

Lucy, 

  Thanks 

Yuanlong Jiang

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

To: 'Jiang <mailto:[email-masked]>  Yuan-long' ; [email-masked] ;
'Drake, <mailto:[email-masked]>  John E' 

Cc: [email-masked] ; [email-masked] ; [email-masked] ; neil.2.
[email-masked] ; [email-masked] 

Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee
RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge
Emulation (PWE3)"

Hi Jiang and John,

[J]: I don't understand what you meant in the differences of transport
characteristics (in the last Email, you said the PW does not guarantee link
characteristics),IMO, PW can also be a bidrectional p2p connection. From the
discussion with Matthew and Sasha, I think the service label may be a PW
label actually.

[J]: Yes, in the data plane, PW label and service label is
undistinguishable. But how the egress node will process the demultiplexed IP
payload? I think there are some subtle processing differences: 

  1) If the bottom label is a non-PW label, then the IP packet will be
routed, as in L3VPN; 

  2) If the bottom label is a PW label, then the IP packet will just be
encapsulated with some data link header and forwarded (no routing is
needed), as arp-mediation draft demonstrates. 

Do you think so?

Regards,

Lucy

  _____  

Hi Liu,

Thanks,

Yuanlong

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

hi,all 

how about all? 

best regards 
liu

 

2009-08-20 04:31 

收件人

抄送

主题

 

ie

Lucy,

Thanks,

John  

Allocations for 

this expired

---

From: <[email-masked]>
Date: Sat, 22 Aug 2009 01:30:19 +0100

Igor,

In my mind the MPLS-TP effort is broadly doing what you suggest. Maybe the
clarity isn't there in all the documents but the intent is broadly aligned
IMO.

Ben

On 21/08/2009 17:18, "Igor Bryskin" <[email-masked]> wrote:

> define MPLS-TP as a subset of MPLS needed to support packet switched transport
> networks. Such definition does not really define how MPLS relates to MPLS-TP.
> In fact, MPLS-TP becomes increasingly a superset of MPLS. What should be done
> IMO is as follows:
>
> 1. Call the lower layer MPLS-TP and concentrate on its enhancements:
> 1. It would be cleat for everyone how MPLS-TP relates to MPLS - it is its
> lower layer, nothing more and nothing less. For example. It would; be clear
> that PWs are NOT a part of the MPLS-TP, there is no difference between MPLS
> PWs and MPLS-TP PWs, and if there is anything wrong with PWs, it should be
> fixed outside of the MPLS-TP effort;
> 2. It would be also clear the importance of perseverance of MPLS OAM wherever
> possible, and bringing in new (e.g. Y.1731) functionality only when/lf needed;
> 3. It would provide a niche for (e.g. Ethernet) vendors to develop “pure”
> MPLS-TP LSRs without necessarily providing full MPLS Service layer
> functionality.
>
> Cheers,
> Igor
>
>
>
> tackled correctly...and if we do not get our thinking/arch straight here these
> issues will not go away but surface time and time again until we are finally
> forced to properly resolve them.  Here is my take on the salient points.
>
> 1   I saw an astute observation from Sasha on the PW CP.  And he was right to
> raise this.  This harps back to my long-standing observation to PWE3 that once
> PWs become multi-hop they create a new co-ps layer network above MPLS instead
> of being just client/server adaptation function (1-hop case).  The deeper
> history behind this is related to (i) the requirement in MPLS LDP for IP to
> run raw in the DP to provide CP/MP functions, and (ii) the fact that LDP
> creates mp2p merging LSP constructs.  The important consequence of the latter
> point being that a PW label must convey source information semantics to
> recover this lost information due to lower level LDP LSP merging.  There is a
> further, and still largely unrecognised IMO, problem in that when PWs move
> from 1-hop to multi-hop entities the PW label needs to change semantic from
> 'source information' to 'forwarding information'......I explained this issue
> in detail in a (PWE3) mail to Matthew Bocci  29/11/2008...I attach for ease of
> reference.
>
> ====
>
>
> (because MPLS-TP is supposed to be a next gen transport network, and resource
> management is a principle requirement of transport networks).  This means we
> must only create p2p and p2mp LSPs in MPLS-TP.....mp2p LSPs do not allow
> deterministic resource management because they are not single source
> longer exist in MPLS-TP.  Put very simply/bluntly, there is no reason to have
> PWs in MPLS-TP at all....that is just a technical fact.  However, such a bald
> technical statement could be considered rather embarrassing (for want of a
> better word) given how much effort has gone into PW related topics so far.
> Given this, what we can therefore do is keep PWs, in-name at least, but be
> very clear we must not create a co-ps mode PW layer network above MPLS-TP.
> And this is a very good thing because we can avoid generating a whole raft of
> DP/CP/MP functions unnecessarily....which addresses Sasha's observation on the
> PW CP above, ie there is no need for a PW CP because there is not a PW layer
> network in MPLS-TP, and its also addresses my previous point on the changing
> nature of a PW label, ie the problem goes away because MS PWs are not allowed
> in MPLS-TP.
>
> ===
>
>
> 3   Let me now turn to section 3.4.1 of the draft under discussion. Firstly, I
> see talk of 'network layer' protocols which harps back to the flawed OSI Ref
> Model architecture.  We really should leave the OSI RM behind now because we
> should know (especially those who have been exposed to functional
> architecture, and in particular G.800 unified modelling of networks) that any
> technology that has routing/switching is a 'network layer' protocol by
> definition.  Further, the L1, L2 and L3 classifications of technology are
> meaningless at best, and the only thing that really matters is the cl-ps,
> co-ps and co-cs mode classification of networks....no mode is more important
> than the others, but each is different and all are required in a complete
> network architecture model.
>
> ===
>
>
> conditions.  But what about the case of misconnectivity (including unintended
> replication/merging defects)?  So here it would seem that we have a 1st-order
> combinatorial '2 out of 4' potential misconnectivity problem, ie across
> IP/MPLS/MPLS-TP/PW cases (its actually worse than this as MPLS is not
> well-known semantic.  In func arch speak we are creating a case of consistent
> CI...and this is also why the OAM used on each LSP in the whole network needs
> to be the same, ie under any case of misconnectivity the receiving node knows
> how to parse and read the semantic of the information it sees (be this a
> label/header or OAM).
>
> warrants examination on its own), and that is LSP nesting as sublayers, ie the
> S bit issue.  This is particularly important because there will be a
> MPLS-TPoverMPLS-TP....that is, where the MPLS-TP layer network of one party is
> carried transparently (all 3 traffic/control/management planes) over the
> degenerate 1-hop Ethernet PW to create a 'functional breakwater' between the 2
> MPLS networks.  This however in neither elegant nor efficient.  So we need a
> better solution IMO.
>
> In the past I suggested we should select a special label from the reserved set
> (ie 0-15) to identify this functional breakwater between different LSP stacks
> (so the S bit could be treated independently in each.  So this approach would
> tie-in with the first case issue discussed under item 4 above, ie MPLS-TP as a
> client would have its own special label (just like the IP and MPLS cases too).
>
> I assume some/all of the above has been discussed within the MEAD team, and it
> would be useful to hear what analysis/conclusions were reached on the above
> topics and why this was.
>
>>> To: 'Jiang Yuan-long' <mailto:[email-masked]>  ; [email-masked] ;
>>> 'Drake, John E' <mailto:[email-masked]>
>>>
>>> is
>>> the importance. Separating them is to distinguish server transport methods,
>>> not much to the payload itself.
>>>
>>> undistinguishable.
>>> But how the egress node will process the demultiplexed IP payload? I think
>>> there are some subtle processing differences:
>>>>  发件人:  [email-masked]  2009-08-20 04:31
>>>>   收件人   "Yong Lucy" <[email-masked]>, "Jiang Yuan-long"
>>>> <[email-masked]>, <[email-masked]>, <[email-masked]>
>>>>   主题   [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE:
>>>> [PWE3] An error in RFC 4446"IANA Allocations        for

---

From: [email-masked]
Date: Mon, 24 Aug 2009 10:02:40 +0800

ben and all,
I admit and agree all opinions. IMO. MPLS-TP should not be regarded as 
subset of MPLS .because MPLS-TP  will have more requirements of transport 
functions than MPLS .
if we only regard mpls-tp as subset of MPLS. it will not be good and 
helpful to develop MPLS-TP functions and standards. in addtional, it is 
diffcult for MPLS-TP 
products to be suitable for requirement of packet transport network of the 
future very well.

best regards
liu

<[email-masked]> 
2009-08-22 08:30

收件人
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] 
An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation 
(PWE3)"

Igor,

Ben

> define MPLS-TP as a subset of MPLS needed to support packet switched 
transport
> b)     MPLS transport layer (label-switched transport for MPLS Service 
layer
> with traffic engineering capabilities)
its
> 2. It would be also clear the importance of perseverance of MPLS OAM 
wherever
> From: [email-masked] [mailto:[email-masked]] On 
Behalf Of
> [email-masked]
these
> (because MPLS-TP is supposed to be a next gen transport network, and 
resource
> longer exist in MPLS-TP.  Put very simply/bluntly, there is no reason to 
have
> 3   Let me now turn to section 3.4.1 of the draft under discussion. 
Firstly, I
> conditions.  But what about the case of misconnectivity (including 
unintended
> well-known semantic.  In func arch speak we are creating a case of 
consistent
> Would someone from the MEAD team (Stewart or Adrian maybe?) be able to 
comment
> on the above please?
>>>>>>>>>>                  "I also wonder whether we should define a PW 
type
>>>>>>>>>> for
>>>>>>>>>>                  We still have a tricky issue with the S bit 
that
>>>>>>> is not fully
>>>>>>>>>>                  So what you point out below will be the case 
in
>>>>>>> MPLS-TP anyway
>>>>>>>>>>                                   Subject: [PWE3] An error in 
RFC
>>>>>>> 4446 "IANA
>>>>>>>>>>                                   I came accross an error in 
RFC
>>>>>>> 4446 "IANA
>>>>>>>>>>                                   The same problem also exists 
in
>>>>>>> web page version
>>>>>>>>>>                                   continue on this document or 
just
>>>>>>> expired as it is?
>>>>>>>>>>                                   I also wonder whether we 
should
>>>>>>> define a PW
>>>> If you have received this email in error please notify the originator 
of
>>>> the

---

From: Yong Lucy <[email-masked]>
Date: Mon, 24 Aug 2009 12:20:02 -0500

Hi Igor,

Following your logic, the relationship between MPLS-TP and PW or MPLS is
server to client. Although they all do packet transport, they belong to the
different layers. If MPLS-TP is an independent layer, it should have its own
bottom label (S=1). 

Cheers,
Lucy

> Sent: Monday, August 24, 2009 9:57 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
RE:
> Hi Ben,
> I am glad that you think this way. I am also glad that so far nobody has
> responded negatively in the context of this discussion.
> 
> However, I know for a fact that not all people view the MPLS-TP effort as
> an enhancement of MPLS lower layer. It would be greatly beneficial IMO, if
> MPLS-TP documents (requirements, framework) state clearly this intention.
> 
> Today MPLS-TP is defined as a subset of MPLS necessary to support packet-
> switched transport networks with an option to introduce new or replace
> existing MPLS machinery when/if such enhancements prove necessary. This
> could easily be interpreted as an attempt to develop a parallel technology
> for managing an existing data plane. This new technology is entitled
> borrow tools it likes from the existing technology and throw away ones it
> does not like, replacing them with new ones. The short name for such new
> technology IMO is T-MPLS, the same ITU-T effort that infuriated so much
> IETF. It does not matter that now it is called MPLS-TP. I am sure that
> ITU-T folks that started the T-MPLS are confident that they still can
> achieve the same objectives.
> 
> IETF, however, owns the MPLS data plane, and is understandably concerned
> about the havoc that could be created if/when two technologies are
> deployed in the same network. To avoid such havoc it is imperative to
> impose certain rules that:
> a) clearly identify the space/layer where the enhancements must take
place;
> b) encourage re-using existing tools vs. introducing new ones.
> 
> I find the MPLS-TP documents confusing. Let's take one example from the
> requirements document.
> 
> Section 2.1. General requirements says:
> 
> 3   Mechanisms and capabilities MUST be able to interoperate with
>        existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
>        data planes where appropriate.
> 
> Two questions:
> a) Why MPLS-TP must be able to interoperate with IETF PWE3 control and
> data planes, considering that everything developed on PWE3 belongs to MPLS
> Service layer, while MPLS-TP is only concerned with MPLS transport layer?
> IMO PWs should not be mentioned in the MPLS-TP documents at all except for
> an appendix enumerating MPLS-TP envisioned clients;
> 
> b) Why do you need to say that MPLS-TP must be interoperable with MPLS
> RFC3031, considering that MPLS-TP is meant to be a an enhanced version of
> MPLS, which means it must be backward compatible to the older version.
> This goes without saying.
> 
> Cheers,
> Igor
> 
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 21, 2009 8:30 PM
> To: Igor Bryskin; [email-masked]; [email-masked];
> “pure”
> > miss-out the PW adaptation for *DP* IP, MPLS and MPLS-TP clients and
(ii)
> we

---

From: <[email-masked]>
Date: Mon, 24 Aug 2009 19:34:41 +0100

Igor, your mail is very important and I just want to reinforce the point that we should not be unduly concerned that MPLS-TP will create a new form of MPLS layer network....MPLS is not singular today.

The really important bits however are:
-	this should remain under IETF control...as this is the right/proper home of MPLS and will ensure a single co-ordinated/responsible stds body for its future evolution
-	MPLS-TP should not be afraid to confront arch problems that have dogged other types of MPLS....this is especially important when we want it to perform a network-builder/transport role, where it must respect the single source requirements of connections in order to allow deterministic resource management.... and it must also not generate an unnecessary further co-ps mode PW layer network above it
-	MPLS-TP needs to re-use best-practice DP/CP/MP behaviours.....for example, embracing the GMPLS CP (orginally developed in CCAMPs for a co-cs mode case, where a logically OOB solution is forced) is a very good thing.  MPLS-TP should look at Y.1731 but only select OAM functions that make technical/operational sense...where I would not advocate the use of an FDI/AIS function nor would I recommend lots of nested TCM sublayers.  And I for sure would caution strongly against trying to peer it with any other non top-of-stack layer network like Ethernet.

I have one further remark below...please see in-line:

> Sent: 24 August 2009 18:45
> To: Yong Lucy; Niven-jenkins,B,Ben,DMF R; 
> Harrison,N,Neil,DEY2 R; [email-masked]; 
> Subject: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework 
> I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations 
> Hi Lucy,
> Please, see in line.
> Sent: Monday, August 24, 2009 1:20 PM
> To: Igor Bryskin; [email-masked]; 
> [email-masked]; [email-masked]; 
> Subject: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework 
> I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations 
> server to client.
> IB>> correct
>  Although they all do packet transport, they belong to the
> different layers.
> 
> IB>> correct
> 
>  If MPLS-TP is an independent layer, it should have its own
> bottom label (S=1).
> 
> IB>> It depends on how one defines client-server adaptation. 
> BTW I don't see anything wrong with an MPLS-TP layer and its 
> client sharing the same label stack. For example, one MPLS-TP 
> layer can serve another MPLS-TP layer.

NH=> Client/server has a specific meaning.  When MPLS uses the S bit it creates sublayers....this is not strict client/server, though it is far closer to client/server than nested TCM levels, which are actually more akin to arbitary horizontal partitions in a single layer network.  It is my personal view that a MPLS-TP transport network should not use S bit sublayering, at least in a manner in which the nesting is theoretically potentially unbounded.  However, I also recognise that the S bit has important MPLS history and I can therefore understand folks wanting it to be retained.  Having said that, if MPLS-TP is going to be really succesful as a next gen pkt transpart network then we do need to find an elegant way of doing MPLS-TPoverMPLS-TP as a proper client/server relationship....and thus we have to address how to deal with the S bit in this case.

What we want is a clear/unambiguous indication in the DP of where the nested LSPs of one MPLS(-TP) (server) network stop and the nested LSPs of another (client) MPLS(-TP) network start.  If you refer to my original mail I offered 2 ways to do this
-	have a DP PID function always associated with the S=1 case for *all* clients, so that includes MPLS-TP.
-	have a set of special DP labels (from the 0-15 set) reserved for specific clients.....where the most important case *if* the S bit sublayering concept is retained is for MPLS-TP.  This latter case was something I suggested a long time ago when working on the ID that used a degenerate 1 hop Ethernet PW to create the S bit 'functional breakwater' between LSP stacks belonging to different MPLS layer networks.

regards, Neil

> > Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP 
> Framework I-D - Nee
> RE:
> > > I think we (IETF folks) made a subtle yet important 
> mistake by agreeing
> > to
> > > networks. Such definition does not really define how MPLS 
> relates to
> > MPLS-TP.
> > > In fact, MPLS-TP becomes increasingly a superset of MPLS. 
> What should be
> > done
> > > IMO is as follows:
> > >
> > > lower layer, nothing more and nothing less. For example. 
> It would; be
> > clear
> > > that PWs are NOT a part of the MPLS-TP, there is no 
> difference between
> > MPLS
> > > PWs and MPLS-TP PWs, and if there is anything wrong with 
> PWs, it should
> > be
> > > possible, and bringing in new (e.g. Y.1731) functionality 
> only when/lf
> > needed;
> [mailto:[email-masked]] On
> > Behalf Of
> > > [email-masked]
> > > Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP 
> Framework I-D - Nee
> > RE:
> > > issues will not go away but surface time and time again 
> until we are
> > finally
> > > 1   I saw an astute observation from Sasha on the PW CP.  
> And he was
> > right to
> > > raise this.  This harps back to my long-standing 
> observation to PWE3
> > that once
> > > PWs become multi-hop they create a new co-ps layer 
> network above MPLS
> > instead
> > > history behind this is related to (i) the requirement in 
> MPLS LDP for IP
> > to
> > > creates mp2p merging LSP constructs.  The important 
> consequence of the
> > latter
> > > recover this lost information due to lower level LDP LSP 
> merging.  There
> > is a
> > > further, and still largely unrecognised IMO, problem in 
> that when PWs
> > move
> > > from 1-hop to multi-hop entities the PW label needs to 
> change semantic
> > from
> > > 'source information' to 'forwarding information'......I 
> explained this
> > issue
> > > in detail in a (PWE3) mail to Matthew Bocci  
> 29/11/2008...I attach for
> > ease of
> > > reference.
> > >
> > > ====
> > >
> > >
> > > management is a principle requirement of transport 
> networks).  This
> > means we
> > > In MPLS-TP we are also required to take the CP/MP 
> IP-based protocols out
> > of
> > > the traffic DP and run them in the logically OOB G-ACH 
> link between
> > adjacent
> > > MPLS-TP nodes.....so this correctly follows the OOB CP/MP 
> behaviour we
> > are
> > > All these factors mean that the arch conditions that 
> created PWs in MPLS
> > no
> > > PWs in MPLS-TP at all....that is just a technical fact.  
> However, such a
> > bald
> > > technical statement could be considered rather 
> embarrassing (for want of
> > a
> > > better word) given how much effort has gone into PW 
> related topics so
> > far.
> > > Given this, what we can therefore do is keep PWs, in-name 
> at least, but
> > be
> > > very clear we must not create a co-ps mode PW layer 
> network above MPLS-
> > TP.
> > > And this is a very good thing because we can avoid 
> generating a whole
> > raft of
> > > DP/CP/MP functions unnecessarily....which addresses 
> Sasha's observation
> > on the
> > > PW CP above, ie there is no need for a PW CP because 
> there is not a PW
> > layer
> > > network in MPLS-TP, and its also addresses my previous 
> point on the
> > changing
> > > nature of a PW label, ie the problem goes away because MS 
> PWs are not
> > allowed
> > > in MPLS-TP.
> > >
> > > ===
> > >
> > >
> > > see talk of 'network layer' protocols which harps back to 
> the flawed OSI
> > Ref
> > > architecture, and in particular G.800 unified modelling 
> of networks)
> > that any
> > > definition.  Further, the L1, L2 and L3 classifications 
> of technology
> > are
> > > 4   It would appear from from what is said in section 
> 3.4.1 that (i) we
> > can
> > > can select an arbitrary/normal forwarding label to 
> identify each of
> > these
> > > replication/merging defects)?  So here it would seem that 
> we have a 1st-
> > order
> > > misconnectivity cases) we really should be using labels 
> that have a
> > globally
> > > CI...and this is also why the OAM used on each LSP in the 
> whole network
> > needs
> > > to be the same, ie under any case of misconnectivity the 
> receiving node
> > knows
> > > Wrt to the 1st issue above:  IMO it would be usually be 
> preferable to
> > have a
> > > single/consistent way to deal with all clients.  So no 
> matter what they
> > are
> > > they would always be encapsulated via a common PW 
> adaptation function
> > (which
> > > warrants examination on its own), and that is LSP nesting 
> as sublayers,
> > ie the
> > > requirement on MPLS-TP to be able to create a 
> functionally decoupled
> > case of
> > > MPLS-TPoverMPLS-TP....that is, where the MPLS-TP layer 
> network of one
> > party is
> > > (*traffic DP*) of a server MPLS-TP layer network owned by 
> a different
> > party.
> > >
> > > degenerate 1-hop Ethernet PW to create a 'functional 
> breakwater' between
> > the 2
> > > MPLS networks.  This however in neither elegant nor 
> efficient.  So we
> > need a
> > > better solution IMO.
> > >
> > > (ie 0-15) to identify this functional breakwater between 
> different LSP
> > stacks
> > > (so the S bit could be treated independently in each.  So 
> this approach
> > would
> > > tie-in with the first case issue discussed under item 4 
> above, ie MPLS-
> > TP as a
> > > client would have its own special label (just like the IP 
> and MPLS cases
> > too).
> > >
> > > Alternatively we could use the approach discussed under 
> the second case
> > in
> > > I assume some/all of the above has been discussed within 
> the MEAD team,
> > and it
> > > would be useful to hear what analysis/conclusions were 
> reached on the
> > above
> > > topics and why this was.
> > >
> > >> Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP 
> Framework I-D -
> > Nee
> > >> RE: [PWE3] An error in RFC 4446"IANA Allocations for 
> PseudowireEdge to
> > Edge
> > >> Emulation (PWE3)"
> > >>
> > >> Lucy,
> > >>
> > >>
> > >>
> > >>> Cc: [email-masked] ; [email-masked] ; 
> [email-masked] ;
> > >>> [email-masked] ; [email-masked]
> > >>>
> > >>> Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP 
> Framework I-D
> > - Nee
> > >>> RE: [PWE3] An error in RFC 4446"IANA Allocations for 
> PseudowireEdge to
> > Edge
> > >>> Emulation (PWE3)"
> > >>>
> > >>>
> > >>> Hi Jiang and John,
> > >>>
> > >>> IMO. MPLS-TP supports two types of client: client 
> network layer and
> > client
> > >>> non-network layer. IP can be as client in both cases. 
> The matter is
> > that
> > >>> characteristics (in the last Email, you said the PW 
> does not guarantee
> > link
> > >>> characteristics),IMO, PW can also be a bidrectional p2p 
> connection.
> > From the
> > >>> discussion with Matthew and Sasha, I think the service 
> label may be a
> > PW
> > >>> label actually.
> > >>>
> > >>> In fact, both PW label and service label are the bottom 
> label. (S=1).
> > This
> > >>> is
> > >>> the importance. Separating them is to distinguish 
> server transport
> > methods,
> > >>> But how the egress node will process the demultiplexed 
> IP payload? I
> > think
> > >>>   2) If the bottom label is a PW label, then the IP 
> packet will just
> > be
> > >>> Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP 
> Framework I-D
> > - Nee
> > >>> RE: [PWE3] An error in RFC 4446"IANA Allocations for 
> PseudowireEdge to
> > Edge
> > >>> Emulation (PWE3)"
> > >>>
> > >>>
> > >>> Hi Liu,
> > >>>
> > >>>
> > >>>
> > >>>> [email-masked] ; [email-masked] ; 
> [email-masked]
> ;
> > >>>> Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP 
> Framework I-D -
> > Nee RE:
> PseudowireEdge to
> > Edge
> > >>>> I reviewed section 3.4.1 in 
> draft-ieft-mpls-tp-framework-02, for all
> > cient
> > >>>> services, there is a unite service label(s=1) to 
> identify procotol
> > payload
> > >>>> type, and The mapping between protocol payload type 
> and Service Label
> > is
> > >>>>   主题   [mpls-tp] Section 3.4.1 of the MPLS TP 
> Framework I-D - Nee
> > RE:
> > >>>>>>>>>> for IP, rather than L2TP PW type for IP. So I 
> believe it is
> > also
> > >>>>>>>>>> feasible for MPLS-TP.
> > >>>>>>>>>>
> > >>>>>>>>>>                  This is precisely what a key 
> consequence of
> > >>>>>>> MPLS-TP is,
> > >>>>>> ie in the
> > >>>>>>>>>> LDP spin of MPLS we had to define PWs (one 
> reason being that
> > LDP
> > >>>>>>>>>> requires that IP traffic units can run native in 
> the DP with
> > MPLS
> > >>>>>>>>>>                                   I wonder how 
> about the status
> > >>>>>>>>>>                                   I also wonder 
> whether we
> > >>>> ZTE Information Security Notice: The information 
> contained in this
> > mail is
> > >>>> solely property of the sender's organization. This 
> mail communication
> > is
> > >>>> are not permitted to disclose the contents of this 
> communication to
> > others.
> > >>>> This email and any files transmitted with it are 
> confidential and
> > intended
> > >>>> This message has been scanned for viruses and Spam by 
> ZTE Anti-Spam
> > system.
> 
> 
> 
>

---

From: Yong Lucy <[email-masked]>
Date: Mon, 24 Aug 2009 14:56:13 -0500

Hi Igor,

[Snipped]
Comments:
> IB>> It depends on how one defines client-server adaptation. BTW I don't
> see anything wrong with an MPLS-TP layer and its client sharing the same
> label stack. For example, one MPLS-TP layer can serve another MPLS-TP
> layer.

[LY] It is OK to have client and server to use one label stack (same label
semantics). However, the bottom label indication serves the purpose for the
server layer not to make any assumption on the labels after the bottom label
indication. MPLS-TP layer can have a label stack that allows label stacking
within the same layer. IMO. If we want a MPLS-TP layer as a server layer to
transport another MPLS-TP layer, the server layer MPLS-TP should have its
own bottom label. This is the way to differ the label stack within a layer
from the label stack outside the layer when server and client layer use the
same label semantics.

I agree this is the matter how we define client-server adaptation. I don't
see other ways to make better client/server layer demarcation. 

Cheers,
Lucy

> > > I think we (IETF folks) made a subtle yet important mistake by
> agreeing
> > to
> > > In fact, MPLS-TP becomes increasingly a superset of MPLS. What should
> be
> > done
> > > IMO is as follows:
> > >
> > > PWs and MPLS-TP PWs, and if there is anything wrong with PWs, it
> should
> > be
> > > history behind this is related to (i) the requirement in MPLS LDP for
> IP
> > to
> > > recover this lost information due to lower level LDP LSP merging.
> There
> > is a
> > > In MPLS-TP we are also required to take the CP/MP IP-based protocols
> out
> > of
> > > All these factors mean that the arch conditions that created PWs in
> MPLS
> > no
> > > PWs in MPLS-TP at all....that is just a technical fact.  However, such
> a
> > bald
> > > technical statement could be considered rather embarrassing (for want
> of
> > a
> > > Given this, what we can therefore do is keep PWs, in-name at least,
> but
> > be
> > > very clear we must not create a co-ps mode PW layer network above
> MPLS-
> > TP.
> > > DP/CP/MP functions unnecessarily....which addresses Sasha's
> observation
> > on the
> > > see talk of 'network layer' protocols which harps back to the flawed
> OSI
> > Ref
> > > 4   It would appear from from what is said in section 3.4.1 that (i)
> we
> > can
> > > replication/merging defects)?  So here it would seem that we have a
> 1st-
> > order
> > > CI...and this is also why the OAM used on each LSP in the whole
> network
> > needs
> > > to be the same, ie under any case of misconnectivity the receiving
> node
> > knows
> > > single/consistent way to deal with all clients.  So no matter what
> they
> > are
> > > warrants examination on its own), and that is LSP nesting as
sublayers,
> > > degenerate 1-hop Ethernet PW to create a 'functional breakwater'
> between
> > the 2
> > > (so the S bit could be treated independently in each.  So this
> approach
> > would
> > > tie-in with the first case issue discussed under item 4 above, ie
> MPLS-
> > TP as a
> > > client would have its own special label (just like the IP and MPLS
> cases
> > too).
> > >
> > > Alternatively we could use the approach discussed under the second
> case
> > in
> > > I assume some/all of the above has been discussed within the MEAD
team,
> > >> Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D
> -
> > Nee
> > >> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge
> to
> > Edge
> > >> Emulation (PWE3)"
> > >>
> > >> Lucy,
> > >>
> > >>
> > >>
> > >>> Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-
> D
> > - Nee
> > >>> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge
> to
> > Edge
> > >>> Emulation (PWE3)"
> > >>>
> > >>>
> > >>> Hi Jiang and John,
> > >>>
> > >>> characteristics (in the last Email, you said the PW does not
> guarantee
> > link
> > >>> discussion with Matthew and Sasha, I think the service label may be
> a
> > PW
> > >>> label actually.
> > >>>
> > >>> In fact, both PW label and service label are the bottom label.
(S=1).
> > >>> Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-
> D
> > - Nee
> > >>> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge
> to
> > Edge
> > >>> Emulation (PWE3)"
> > >>>
> > >>>
> > >>> Hi Liu,
> > >>>
> > >>>
> > >>>
> > >>>> Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D
> -
> > Nee RE:
> > >>>> I reviewed section 3.4.1 in draft-ieft-mpls-tp-framework-02, for
> all
> > cient
> > >>>> type, and The mapping between protocol payload type and Service
> Label
> > is
> important
> > >>>>>>>>>>                                   I wonder how about the
> status
> > >>>> solely property of the sender's organization. This mail
> communication
> > is

---

From: Yong Lucy <[email-masked]>
Date: Mon, 24 Aug 2009 17:07:01 -0500

Hi Neil and All,

My suggestion is to consider the bottom label (S=1) as a client/server
adaptation label on the label stack. It serves as client/server adaptation
and layer demarcation. It is client layer responsibility to generate the
client/server adaptation label and push into the label stack before send the
packets to server layer. Thus, client protocol type can be encoded in this
label and a server layer does not need to know what protocol client
executes. One MPLS-TP LSP may carry one or multiple client protocols. This
seems a clean method to me.

Regards,
Lucy

> NH=> Client/server has a specific meaning.  When MPLS uses the S bit it
> creates sublayers....this is not strict client/server, though it is far
> closer to client/server than nested TCM levels, which are actually more
> akin to arbitary horizontal partitions in a single layer network.  It is
> my personal view that a MPLS-TP transport network should not use S bit
> sublayering, at least in a manner in which the nesting is theoretically
> potentially unbounded.  However, I also recognise that the S bit has
> important MPLS history and I can therefore understand folks wanting it to
> be retained.  Having said that, if MPLS-TP is going to be really succesful
> as a next gen pkt transpart network then we do need to find an elegant way
> of doing MPLS-TPoverMPLS-TP as a proper client/server relationship....and
> thus we have to address how to deal with the S bit in this case.
> 
> What we want is a clear/unambiguous indication in the DP of where the
> nested LSPs of one MPLS(-TP) (server) network stop and the nested LSPs of
> another (client) MPLS(-TP) network start.  If you refer to my original
> mail I offered 2 ways to do this
> -	have a set of special DP labels (from the 0-15 set) reserved for
> specific clients.....where the most important case *if* the S bit
> sublayering concept is retained is for MPLS-TP.  This latter case was
> something I suggested a long time ago when working on the ID that used a
> degenerate 1 hop Ethernet PW to create the S bit 'functional breakwater'
> between LSP stacks belonging to different MPLS layer networks.
> 
> regards, Neil
> 
> >
> > Cheers,
> > Lucy
> >
> >

---

From: <[email-masked]>
Date: Mon, 24 Aug 2009 23:51:15 +0100

Thanks Lucy,

I also considered just using the S bit in the manner you suggest and rejected it on the basis that only a single S=1 labelled header was allowed in a stack of LSPs with normal forwarding headers.  This was at least my interpretation of the original LSP architectural stacking rules, ie S=1 can appear only once in such a stack.  And so to avoid cases of S=1 in consecutive headers with normal forwarding labels (which I believe would be possible otherwise) I thought it would be useful to make this unambiguously clear by using a label as a 'functional breakwater' that is not allowed to appear as a normal DP forwarding label, ie one from the 0-15 reserved set.

Aside=> We also have to consider the case of something going wrong with normal forwarding, ie misconnectivity.  This is not a new issue, but currently this can only occur within a single MPLS layer network stack and not across different MPLS layer network stacks.

Hope what I am saying here makes sense.  

regards, Neil

> Sent: 24 August 2009 23:07
> To: Harrison,N,Neil,DEY2 R; [email-masked]; 
> Niven-jenkins,B,Ben,DMF R; [email-masked]; 
> > -	have a DP PID function always associated with the S=1 
> case for *all*
> > clients, so that includes MPLS-TP.
> > > > > of being just client/server adaptation function 
> (1-hop case).  The
> > > > deeper
> > > > > Model architecture.  We really should leave the OSI 
> RM behind now
> > > > because we
> > > > > meaningless at best, and the only thing that really 
> matters is the
> > > cl-ps,
> > > > > co-ps and co-cs mode classification of networks....no 
> mode is more
> > > > important
> > > > > than the others, but each is different and all are 
> required in a
> > > > complete
> > > > > In the past I suggested we should select a special 
> label from the
> > > > reserved set
> > > > >>> result, to carry a L3 network client, it is 
> required to use the
> > > > service
> > > > >>>> Section 3.4.1 deals with client network layer 
> payloads, where
> > > > 'network
> [mailto:[email-masked]]
> > > > >>>>>> On Behalf
> > > > >>>>>>>> Of Drake, John E
> > > > >>>>>>>> It describes how client network layer payloads 
> (e.g., IP
> > > > >>>>>> and MPLS) are
> > > > >>>>>>>> carried directly, i.e., without a pseudo-wire, 
> over an MPLS
> > > > >>>>>> TP server
> > > > >>>>>>>> network.
> > > > >>>>>>>>
> > > > >>>>>>>>>>                                   Cc: 
> [email-masked]
> > > > >>>>>>>>>>                                   Edge to 
> Edge Emulation
> > > > (PWE3)".
> > > > >>>>>>>>>>                                   In Sec 
> 3.2, it says:
> > > > >>>>>>>>>>                                   "   0x000B 
>  IP Layer2
> > > > Transport
> > > > >>>>>>>>>>                                      0x000B  
> IP Layer2
> > > > Transport
> > > > >>>> confidential. Recipients named above are obligated 
> to maintain
> > > > secrecy and
> > > > >>>> solely for the use of the individual or entity to 
> whom they are
> > > > addressed.
> > > > >>>> message. Any views expressed in this message are 
> those of the
> > > > individual
> > > > >>>> sender.

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 02:26:09 +0100

Liu,

MPLS-TP will be a subset of MPLS as MPLS will be extended to encompass
MPLS-TP requirements. Therefore ultimately MPLS will be capable of
everything TP can do and more (the more is the stuff that the Itu definition
of transport network does not require).

Ben

On 24/08/2009 03:02, "[email-masked]" <[email-masked]> wrote:

>
> ben and all,
> I admit and agree all opinions. IMO. MPLS-TP should not be regarded as subset
> of MPLS .because MPLS-TP  will have more requirements of transport functions
> than MPLS .
> if we only regard mpls-tp as subset of MPLS. it will not be good and helpful
> to develop MPLS-TP functions and standards. in addtional, it is diffcult for
> MPLS-TP
> <[email-masked]> 2009-08-22 08:30
> 收件人
> <[email-masked]>, <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>, <[email-masked]>
> 抄送
> Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An
> error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation
> (PWE3)"
>
>
>
>
> Igor,
>
>> 2
>> set
>> it
> confidential. Recipients named above are obligated to maintain secrecy and are
> not permitted to disclose the contents of this communication to others.
> solely for the use of the individual or entity to whom they are addressed. If
> you have received this email in error please notify the originator of the

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 02:32:50 +0100

Igor,

On 24/08/2009 15:56, "Igor Bryskin" <[email-masked]> wrote:
> Today MPLS-TP is defined as a subset of MPLS necessary to support
> packet-switched transport networks with an option to introduce new or replace
> existing MPLS machinery when/if such enhancements prove necessary. This could
> easily be interpreted as an attempt to develop a parallel technology for
> managing an existing data plane. This new technology is entitled borrow tools
> it likes from the existing technology and throw away ones it does not like,
> replacing them with new ones. The short name for such new technology IMO is
> T-MPLS, the same ITU-T effort that infuriated so much IETF. It does not matter
> that now it is called MPLS-TP. I am sure that ITU-T folks that started the
> T-MPLS are confident that they still can achieve the same objectives.

There is a difference IMO (without wanting to get into a debate on T-MPLS).
IMO T-MPLS was developed without a full understanding of MPLS and therefore
diverged from MPLS in some key areas. MPLS-TP is being developed with a full
understanding of MPLS and therefore won't cause the same issues.

> IETF, however, owns the MPLS data plane, and is understandably concerned about
> the havoc that could be created if/when two technologies are deployed in the
> same network. To avoid such havoc it is imperative to impose certain rules
> that:
> a) clearly identify the space/layer where the enhancements must take place;
> a) Why MPLS-TP must be able to interoperate with IETF PWE3 control and data
> planes, considering that everything developed on PWE3 belongs to MPLS Service
> layer, while MPLS-TP is only concerned with MPLS transport layer? IMO PWs
> should not be mentioned in the MPLS-TP documents at all except for an appendix
> enumerating MPLS-TP envisioned clients;

MPLS-TP will carry PWs as one possible client. The way MPLS-TP does that and
the PWs themselves must be compatible with existing PWs for them to be most
useful IMO, also see point below.

> MPLS, which means it must be backward compatible to the older version. This
> goes without saying.

One would think that, but T-MPLS diverged from RFC3031 and subsequent RFCs
so it's worth making it explicit IMO.

Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 25 Aug 2009 08:08:23 +0300

Ben, Igor and all,

This email has been triggered by the following statement in Ben's last email:

MPLS-TP will carry PWs as one possible client.

IMHO and FWIW, this begs for  a question:

What else is MPLS-TP going to carry?

The ongoing discussion about MPLS-TP carrying MPLS-TP with its accompanying topics of advantages and disadvantages of setting S-bit somewhere in the label stack, using reserved labels as PIDs etc. does not look helpful to me, not in the least because I do not see any convergence there.

Please note also that, to the best of my understanding, IETF MPLS does not care whether it carries PWs or IP (its original client traffic). If you need a proof, please compare an MPLS packet that carries a P2P IP PW and an MPLS packet that carries unicast IP traffic in a 2547/4364 Layer 3 VPN...

My 2c,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, August 25, 2009 4:32 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

Igor,

Ben

---

From: [email-masked]
Date: Tue, 25 Aug 2009 15:26:01 +0800

lucy
according to your suggestion, I can't understand how client protocol type 
can be encoded in the bottom label. whether to need to extend or change 
originate field in the bottom label? or make use of other mothed to encode 
client protocol type in the bottom label.

can you clarify it.

best regards
liu

Yong Lucy <[email-masked]> 
2009-08-25 06:07

收件人
[email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked]
抄送
[email-masked], [email-masked]
主题
RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] 
An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation 
(PWE3)"

Hi Neil and All,

client/server adaptation label and push into the label stack before send 

Regards,
Lucy

case for *all*

---

From: [email-masked]
Date: Tue, 25 Aug 2009 15:33:50 +0800

ben
thank you for your replying . IMO. since mpls may be extended to realize 
and encompass MPLS-TP requirements. while from the view of requirements 
aspect or function aspect , MPLS-TP will have more than MPLS. why regard 
mpls-tp as subset of MPLS. I don't see this point.

best regards
liu

2009-08-25 09:26

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>
主题
Re: [PWE3] [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: 
An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation 
(PWE3)"

Liu,

MPLS-TP will be a subset of MPLS as MPLS will be extended to encompass
MPLS-TP requirements. Therefore ultimately MPLS will be capable of
everything TP can do and more (the more is the stuff that the Itu 
definition
of transport network does not require).

Ben

> I admit and agree all opinions. IMO. MPLS-TP should not be regarded as 
subset
> if we only regard mpls-tp as subset of MPLS. it will not be good and 
helpful
> <[email-masked]>, <[email-masked]>, 
<[email-masked]>,
>> In fact, MPLS-TP becomes increasingly a superset of MPLS. What should 
be done
layer
its
wherever
Behalf Of
>> raise this.  This harps back to my long-standing observation to PWE3 
that
>> once
IP to
>> in detail in a (PWE3) mail to Matthew Bocci  29/11/2008...I attach for 
ease
resource
>> In MPLS-TP we are also required to take the CP/MP IP-based protocols 
out of
>> All these factors mean that the arch conditions that created PWs in 
MPLS no
>> PWs in MPLS-TP at all....that is just a technical fact.  However, such 
a bald
>> technical statement could be considered rather embarrassing (for want 
of a
MPLS-TP.
>> DP/CP/MP functions unnecessarily....which addresses Sasha's observation 
on
>> 3   Let me now turn to section 3.4.1 of the draft under discussion. 
Firstly,
>> I
OSI Ref
>> miss-out the PW adaptation for *DP* IP, MPLS and MPLS-TP clients and 
(ii) we
unintended
>> replication/merging defects)?  So here it would seem that we have a 
1st-order
consistent
>> degenerate 1-hop Ethernet PW to create a 'functional breakwater' 
between the
>> tie-in with the first case issue discussed under item 4 above, ie 
MPLS-TP as
cases
- Nee
>>>> To: 'Jiang Yuan-long' <mailto:[email-masked]>  ; 
[email-masked]
>>>> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge 
to Edge
>>>> characteristics (in the last Email, you said the PW does not 
guarantee link
>>>> characteristics),IMO, PW can also be a bidrectional p2p connection. 
From
- Nee
>>>> RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge 
to Edge
>>>>> Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - 
Nee
>>>>> type, and The mapping between protocol payload type and Service 
Label is
type
that
important
in
RFC
in
just
should
>>>>>>>>>>>                                 everything on PW is possible.
communication is
>>>>> If you have received this email in error please notify the 
originator of

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 08:56:20 +0100

Thanks Sasha...you are certainly homing-in on the nub of the
matter...please see in-line for my opinion:

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: 25 August 2009 06:08
	To: Niven-jenkins,B,Ben,DMF R; [email-masked]
	Cc: [email-masked]; [email-masked]; Harrison,N,Neil,DEY2 R;
[email-masked]; [email-masked]; [email-masked];
[email-masked]
	Subject: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework
I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for
PseudowireEdge to Edge Emulation (PWE3)"

	Ben, Igor and all,

	This email has been triggered by the following statement in
Ben's last email:

		NH=> Exactly.  In order for MPLS-TP to fulfil a
transport role it has to distinguish between (i) IP as a real DP client
and (ii) IP as a CP/MP function for *this* MPLS layer network....which
also just happens to appears in the DP in MPLS as-is because of the way
it was originally designed to work based on LDP.  MPLS was principally
intended to be a IP helper, and other clients, ie PWs, were an
afterthought...ergo things like the special ECMP treatment by
sterilising the 1st nibble of the CW.  It had to be like this for the
LDP type of MPLS to function.

		Once we make the statement 'we are going to use MPLS as
a next generation transport network' then we need to treat all clients
equally and we need to use connections in order to deterministically
manage resource vectors.  Further, we also need to move the IP required
for the MPLS CP/MP out of the traffic DP and into its own logical OOB
network.  This is nothing new.  This is how the CP/MP for all co-cs mode
networks must be designed, and its exactly what GMPLS was designed to
do.

		So now we arrive at a major conclusion...which is as you
said, ie all clients are PWs...or more accurately all clients (inc) IP
are treated alike.  The adaptation function to be used can be
anything....GFP would have been a good choice (eg to align with what
existing co-cs mode transport networks use, noting it already has a PID
function), but, because of the history, seems like we will continue with
the CW.  No problem here (ignoring any judgement of how good such
adaptation is) but the really key bit is that we must not (as was
happening with MPLS) create a new MS co-ps PW layer network above MPLS.

		Aside=> This nearly happened in ITU many years ago with
GFP, ie some folks wanted to start adding functionality that would have
slowly led to GFP becoming a layer network (ie multi-segment and thus
networked).  This was stopped in time.  All you do by doing this is
chase the generic adaptation one still requires further up the stack!

		So the only problem left at this juncture is the S bit.
We should not decry its (sublayering) significance.  I am not convinced
it is that useful (at least as an unbounded stacking function) but (i)
if we want to keep it and (ii) try and stay faithful to the original
MPLS requirement that only allowed S=1 to appear once at the bottom of
an LSP stack, then we need to find some elegant way to address
MPLS(TP)overMPLS(TP).  I have suggested using a reserved label for this,
and I still think this warrants consideration.

	The ongoing discussion about MPLS-TP carrying MPLS-TP with its
accompanying topics of advantages and disadvantages of setting S-bit
somewhere in the label stack, using reserved labels as PIDs etc. does
not look helpful to me, not in the least because I do not see any
convergence there.  

	NH=> We can't just ignore this Sasha IMO....reasons given above.
This is my view at least.

	regards, Neil 

	Please note also that, to the best of my understanding, IETF
MPLS does not care whether it carries PWs or IP (its original client
traffic). If you need a proof, please compare an MPLS packet that
carries a P2P IP PW and an MPLS packet that carries unicast IP traffic
in a 2547/4364 Layer 3 VPN...

	My 2c,

	     Sasha

	________________________________________
	From: [email-masked] [[email-masked]] On
Behalf Of [email-masked] [[email-masked]]
	Sent: Tuesday, August 25, 2009 4:32 AM
	To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework
I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for
PseudowireEdge to Edge Emulation (PWE3)"
	
	Igor,
	
	> T-MPLS are confident that they still can achieve the same
objectives.
	
	There is a difference IMO (without wanting to get into a debate
on T-MPLS).
	IMO T-MPLS was developed without a full understanding of MPLS
and therefore
	diverged from MPLS in some key areas. MPLS-TP is being developed
with a full
	understanding of MPLS and therefore won't cause the same issues.
	
	> enumerating MPLS-TP envisioned clients;
	
	MPLS-TP will carry PWs as one possible client. The way MPLS-TP
does that and
	the PWs themselves must be compatible with existing PWs for them
to be most
	useful IMO, also see point below.
	
	> MPLS, which means it must be backward compatible to the older
version. This
	
	One would think that, but T-MPLS diverged from RFC3031 and
subsequent RFCs
	so it's worth making it explicit IMO.
	
	Ben

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 25 Aug 2009 09:58:13 +0200

I changed the subject, because the discussion is now about MPLS and MPLS-TP.

Ni hao Liu,

> mpls-tp as subset of MPLS. I don't see this point.

A profile is a subset.

In order to make a transport profile of MPLS that meets the
ITU-T requirements for a transport network MPLS has to be
extended with OAM functions to meet these requirements.

Once MPLS has been extended, a profile can be defined for
transport: MPLS-TP
This MPLS-TP is a subset of the (extended) MPLS.

The focus of IETF is on the extended MPLS.
The focus of ITU-T is on MPLS -TP.

Regards, Huub.

> *<[email-masked]>*
> 
> 2009-08-25 09:26
> 
> 	
> 收件人
> 	<[email-masked]>
> 抄送
> 	<[email-masked]>, <[email-masked]>, 
> <[email-masked]>, <[email-masked]>
> 主题
> 	Re: [PWE3] [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee 
> RE: An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge 
> Emulation (PWE3)"
> 
> 
> 
> Liu,
> 

> agreeing to
>  >> b)     MPLS transport layer (label-switched transport for MPLS 
> Service layer
> should be

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

---

From: [email-masked]
Date: Tue, 25 Aug 2009 16:28:58 +0800

ni hao ,huub
I am thankful for you. I completely understand your meaning. IMO, we 
should change or revise mpls-tp requirement draft. MPLS-TP is a subset of 
the extended MPLS. while not MPLS. so we maybe misunderstand this meaning.

regards
liu

Huub van Helvoort <[email-masked]> 
2009-08-25 15:58
请答复 给
[email-masked]

收件人
[email-masked]
抄送
[email-masked], [email-masked]
主题
MPLS vs MPLS-TP (changed subject)

I changed the subject, because the discussion is now about MPLS and 
MPLS-TP.

Ni hao Liu,

A profile is a subset.

Regards, Huub.

definition

>  > error in RFC 4446"IANA Allocations for PseudowireEdge to Edge 
Emulation
>  >> networks. Such definition does not really define how MPLS relates to 

> wherever
>  >> possible, and bringing in new (e.g. Y.1731) functionality only 
when/lf

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 09:38:57 +0100

Hubb...understand the sentiments but I believe we need to look at this slightly differently...please see comments in-line:

> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: 25 August 2009 08:58
> To: [email-masked]
> Subject: [mpls-tp] MPLS vs MPLS-TP (changed subject)
> 

NH=> If MPLS is extended then by definition the extended version cannot be a subset of the previous version, ie it has new components that do not appear in the original base form of MPLS.

This is not a problem at all.  But what it does mean is that MPLS-TP is a new layer network.  Sure it can (and indeed should/must) re-use existing IETF defined DP/CP/MP components where these are most suitable and best-of-breed (eg GMPLS OOB CP).

Here is an analogy to really ram home this point.  If I take an Ethernet traffic unit and replace the cl-ps CP components (eg STP, BU, SA learning/ageing) with co-ps CP components (eg GMPLS) then I create a very different layer network to the original Ethernet layer network.  They share an identical traffic unit but you cannot meaningful interconnect/network them, ie the access points of the cl-ps mode Ethernet (say 802.1d/802/1ad/802.1ah) layer network must not be able to connect to the access points of the co-ps mode Ethernet (say 802.1Qay) layer network...they lie in distinct/different layer network spaces.

Further, a transport network is a little more than OAM.  Most fundamentally a transport network is all about providing transparent and assured resource to its clients....and this starts with having proper connections.

regards, Neil 
> >  > I admit and agree all opinions. IMO. MPLS-TP should not 
> be regarded 
> > as subset
> >  > of MPLS .because MPLS-TP  will have more requirements of 
> transport 
> > functions
> >  > than MPLS .
> >  > products to be suitable for requirement of packet 
> transport network 
> > of the
> >  > future very well.
> >  >
> >  > best regards
> >  > liu
> >  >
> >  >
> >  >
> >  >
> >  > Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D 
> - Nee RE: 
> > [PWE3] An
> >  > clarity isn't there in all the documents but the intent 
> is broadly 
> > aligned
> >  > IMO.
> >  >
> >  > Ben
> >  >
> >  >
> >  >
> >  >> 1. It would be cleat for everyone how MPLS-TP relates 
> to MPLS - it 
> > is its
> >  >> lower layer, nothing more and nothing less. For 
> example. It would; 
> > be clear
> >  >> possible, and bringing in new (e.g. Y.1731) 
> functionality only when/lf
> >  >> needed;

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 25 Aug 2009 11:31:32 +0200

Neal,

> Hubb...understand the sentiments but I believe we need to look at this slightly differently...please see comments in-line:

I have the strong impression that you stopped reading my response
after writing your in-line comments.
IMO MPLS-TP is *NOT* the extended MPLS
IMO MPLS-TP is a profile (and thus a subset) of the extended MPLS.
Maybe this explains the dis-connection.

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 10:45:09 +0100

Thanks Hubb....I actually did understand what your said, ie IETF extend MPLS and MPLS-TP becomes a profile of such IETF defined extensions.....and I agree my wording is a little clumsy.   But to me the really important points are what I said after that wrt what this means for MPLS-TP (as a new layer network etc).  This is where we will either do a great job or a poor job.

regards, neil

> Behalf Of Huub van Helvoort
> Sent: 25 August 2009 10:32
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] [mpls-tp] MPLS vs MPLS-TP (changed subject)
> 
> Neal,
> 
> You replied:
> 
> > Hubb...understand the sentiments but I believe we need to 
> look at this slightly differently...please see comments in-line:
> 
> > NH=> If MPLS is extended then by definition the extended 
> version cannot be a subset of the previous version, ie it has 
> new components that do not appear in the original base form of MPLS.
> > 
> > This is not a problem at all.  But what it does mean is 
> that MPLS-TP is a new layer network.  Sure it can (and indeed 
> should/must) re-use existing IETF defined DP/CP/MP components 
> where these are most suitable and best-of-breed (eg GMPLS OOB CP).
> > 
> > Here is an analogy to really ram home this point.  If I 
> take an Ethernet traffic unit and replace the cl-ps CP 
> components (eg STP, BU, SA learning/ageing) with co-ps CP 
> components (eg GMPLS) then I create a very different layer 
> network to the original Ethernet layer network.  They share 
> an identical traffic unit but you cannot meaningful 
> interconnect/network them, ie the access points of the cl-ps 
> mode Ethernet (say 802.1d/802/1ad/802.1ah) layer network must 
> not be able to connect to the access points of the co-ps mode 
> Ethernet (say 802.1Qay) layer network...they lie in 
> distinct/different layer network spaces.
> > 
> > Further, a transport network is a little more than OAM.  
> Most fundamentally a transport network is all about providing 
> transparent and assured resource to its clients....and this 
> starts with having proper connections.
> > 
> > regards, Neil 
>  >
> >>>  > to develop MPLS-TP functions and standards. in 
> addtional, it is 
> >>> diffcult for
> >>>  > MPLS-TP
> >>>  > In my mind the MPLS-TP effort is broadly doing what 
> you suggest. 
> >>> Maybe the
> mistake by 
> >>>  >> In fact, MPLS-TP becomes increasingly a superset of 
> MPLS. What 
> >>> should be done
> >>>  >> IMO is as follows:
> >>>  >>
> difference 
> >>> between MPLS

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 25 Aug 2009 12:45:52 -0400

On Aug 25, 2009, at 4:38 AM, <[email-masked]> wrote:

> Hubb...understand the sentiments but I believe we need to look at  
> this slightly differently...please see comments in-line:
>
> NH=> If MPLS is extended then by definition the extended version  
> cannot be a subset of the previous version, ie it has new components  
> that do not appear in the original base form of MPLS.
>
> This is not a problem at all.  But what it does mean is that MPLS-TP  
> is a new layer network.  Sure it can (and indeed should/must) re-use  
> existing IETF defined DP/CP/MP components where these are most  
> suitable and best-of-breed (eg GMPLS OOB CP).

	Not exactly. Remember the direction that the MEAD team always has had  
was to fold back anything that was outside of a "subset" of MPLS into  
the main definition of MPLS.  The idea here is precisely to NOT create  
a new layered network technology.

	--Tom

> Here is an analogy to really ram home this point.  If I take an  
> Ethernet traffic unit and replace the cl-ps CP components (eg STP,  
> BU, SA learning/ageing) with co-ps CP components (eg GMPLS) then I  
> create a very different layer network to the original Ethernet layer  
> network.  They share an identical traffic unit but you cannot  
> meaningful interconnect/network them, ie the access points of the cl- 
> ps mode Ethernet (say 802.1d/802/1ad/802.1ah) layer network must not  
> be able to connect to the access points of the co-ps mode Ethernet  
> (say 802.1Qay) layer network...they lie in distinct/different layer  
> network spaces.
>
> Further, a transport network is a little more than OAM.  Most  
> fundamentally a transport network is all about providing transparent  
> and assured resource to its clients....and this starts with having  
> proper connections.
>
> regards, Neil
>>

---

From: Yong Lucy <[email-masked]>
Date: Tue, 25 Aug 2009 11:52:09 -0500

Neil,

IMO, MPLS work before did not deal with the layers or label stack related
layers. Now, we need to consider it. We like to have the single label stack
(semantics) for handling label stack within a layer and labels across client
and server layers.

You are right, S bit is used for the indication of the bottom label stack
when there is no layer concept in the data plane. Now we have the case. 

Regards,
Lucy

> Sent: Monday, August 24, 2009 5:51 PM
> To: [email-masked]; [email-masked]; benjamin.niven-
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
RE:
> I also considered just using the S bit in the manner you suggest and
> rejected it on the basis that only a single S=1 labelled header was
> allowed in a stack of LSPs with normal forwarding headers.  This was at
> least my interpretation of the original LSP architectural stacking rules,
> ie S=1 can appear only once in such a stack.  And so to avoid cases of S=1
> in consecutive headers with normal forwarding labels (which I believe
> would be possible otherwise) I thought it would be useful to make this
> unambiguously clear by using a label as a 'functional breakwater' that is
> not allowed to appear as a normal DP forwarding label, ie one from the 0-
> 15 reserved set.
> 
> Aside=> We also have to consider the case of something going wrong with
> normal forwarding, ie misconnectivity.  This is not a new issue, but
> currently this can only occur within a single MPLS layer network stack and
> not across different MPLS layer network stacks.
> 
> > > > > [email-masked] ;

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 25 Aug 2009 19:39:34 +0200

Igor,
Do you consider LDP and BGP as service layers?
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Igor Bryskin
Sent: Tuesday, August 25, 2009 5:26 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Huub,

I have no problem with extending MPLS if/when necessary to satisfy transport networks need. I also understand and agree when you say that MPLS-TP will be a subset of the extended MPLS (e.g. everything to do with the LSP merging will be outside of MPLS-TP).

The point I was trying to make is that there is a need to define what is it MPLS in this context? What exactly we are trying to extend and then use as a subset of this extended thing for MPLS-TP?

My suggestion is to separate MPLS (upper) service layer (VPNs, PWs, VPLS, BGP, LDP, etc.) from MPLS (lower) transport layer (traffic engineered LSPs via RSVP-TE) and work on extensions/enhancements of this lower layer only.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Tuesday, August 25, 2009 3:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Ni hao Liu,

A profile is a subset.

Regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 25 Aug 2009 19:41:55 +0200

Huub,
I do not agree with your observation "The focus of IETF is on the extended MPLS. The focus of ITU-T is on MPLS -TP."
The IETF put a lot of efforts in defining MPLS-TP, the profile which addresses requirements coming out of the ITU-T and from SPs. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Tuesday, August 25, 2009 10:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [PWE3] MPLS vs MPLS-TP (changed subject)

Ni hao Liu,

A profile is a subset.

Regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 25 Aug 2009 20:54:01 +0200

I agree with Malcolm.
Best regards,
Nurit

-----Original Message-----
From: ext Malcolm Betts [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 9:50 PM
To: 'Igor Bryskin'; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Igor,

Just to be sure LDP and BGP are part of the CP for the services layer,
they are not a part of the data plane (forwarding plane) of the services
layer.

Regards,

Malcolm

> Behalf Of Igor Bryskin
> Sent: Tuesday, August 25, 2009 2:00 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
> [email-masked]
> Yes. These protocols are a part of MPLS Service layer CP.
> 
> Igor
> 
> From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> [mailto:[email-masked]]
> Sent: Tuesday, August 25, 2009 1:40 PM
> To: Igor Bryskin; [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] MPLS vs MPLS-TP (changed subject)
> 
> Igor,
> Behalf Of ext Igor Bryskin
> I have no problem with extending MPLS if/when necessary to satisfy
> transport networks need. I also understand and agree when you say that
> MPLS-TP will be a subset of the extended MPLS (e.g. everything to do
> with the LSP merging will be outside of MPLS-TP).
> 
> The point I was trying to make is that there is a need to define what
> is it MPLS in this context? What exactly we are trying to extend and
> then use as a subset of this extended thing for MPLS-TP?
> 
> My suggestion is to separate MPLS (upper) service layer (VPNs, PWs,
> VPLS, BGP, LDP, etc.) from MPLS (lower) transport layer (traffic
> engineered LSPs via RSVP-TE) and work on extensions/enhancements of
> this lower layer only.
> 
> Cheers,
> Igor
> 
> >  > I admit and agree all opinions. IMO. MPLS-TP should not be
> regarded
> > as subset
> >  > products to be suitable for requirement of packet transport
> network
> > of the
> >  > future very well.
> >  >
> >  > best regards
> >  > liu
> >  >
> >  >
> >  >
> >  >
> >  > Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee
> RE:
> > [PWE3] An
> >  > clarity isn't there in all the documents but the intent is
> broadly
> > aligned
> >  > IMO.
> >  >
> >  > Ben
> >  >
> >  >
> >  >
> >  >> 1. It would be cleat for everyone how MPLS-TP relates to MPLS -
> it
> > is its
> >  >> lower layer, nothing more and nothing less. For example. It
> would;
> > be clear

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Aug 2009 21:31:05 +0100

Not quite, LDP may also be the CP for what Igor is calling
the TL.

Stewart

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>>> thank you for your replying . IMO. since mpls may be extended to
>>>       
>> realize
>>     
>>> and encompass MPLS-TP requirements. while from the view of
>>>       
>> requirements
>>     
>>> aspect or function aspect , MPLS-TP will have more than MPLS. why
>>>       
>> regard
>>     
>>> 	Re: [PWE3] [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D
>>>       
>> - Nee
>>     
>>> MPLS-TP will be a subset of MPLS as MPLS will be extended to
>>>       
>> encompass
>>     
>>>  > if we only regard mpls-tp as subset of MPLS. it will not be good
>>>       
>> and
>>     
>>> helpful
>>>  > On 21/08/2009 17:18, "Igor Bryskin" <[email-masked]>
>>>       
>> wrote:
>>     
>>>  >
>>>  >> Hi Neil,
>>>  >>
>>>  >> define MPLS-TP as a subset of MPLS needed to support packet
>>>       
>> switched
>>     
>>>  >> transport
>>>  >> 1. Call the lower layer MPLS-TP and concentrate on its
>>>       
>> enhancements:
>>     
>>>  >> 2. It would be also clear the importance of perseverance of MPLS
>>>       
>> OAM
>>     
>>> wherever
>>>  >> 3. It would provide a niche for (e.g. Ethernet) vendors to
>>>       
>> develop
>>     
>>> “pure”
>>>  >> MPLS-TP LSRs without necessarily providing full MPLS Service
>>>       
>> layer
>>     
>>>  >> functionality.
>>>  >>
>>>  >> Cheers,
>>>  >> Igor
>>>       
>> --

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Aug 2009 21:35:52 +0100

> Although the
> general name for the work is MPLS-TP (-Transport Profile) it is very
> clear that what is being defined is the superset extension, not just
> those aspects of MPLS that are require to satisfy only the requirements
> of the transport network.
>
>   
Malcolm

Please can you clarify what functions are being published as part of the
MPLS-TP project that are not required in a transport application?

Stewart

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 21:58:43 +0100

Just catching up on some of this.  Everyone is probably right for probably different reasons...and to try and make sense of this odd looking statement:

-	labels live in the DP.  But they can have quite different meanings depending on which (CP) protocol issued them.

-	and to place a slight twist on this, we can even have DP labels that belong to different DPs!....a fact that should be obvious/clear to anyone used to designing co-cs mode networks, ie there is a traffic co-cs mode DP and a CP/MP DP, where the latter usually operates on cl-ps mode principles.  GMPLS is exactly like this....and it’s a great (re-use) paradigm IMO also for the co-ps mode.

-	I often say 'MPLS is not singular', and what I really mean by this is that labels have different meanings depending on who issued them.  So a label issued by CP protocol X will have a different *traffic DP* interpretation if received at a node expecting a label issued by CP protocol Y....which becomes a practically important point when we consider cases of misconnectivity (which is why you will also often hear me say that it is even more important (in MPLS) that we must always have consistent OAM when the label characteristic information is not consistent).  This (consistent detection of misconnectivity requirement) is a largely an implicit consequence of sublayering, ie S bit behaviour.  Hope that makes sense, might not have explained it well but those with a func arch background should get what I am saying here.

-	the PW case is especially interesting and warrants closer attention.  I'll not regurgitate the reasons PWs came into being as a consequence of LDP, but they do create this interesting case of (their labels) needing to carry a SA proxy semnatic for the single hop case (to recover source information lost due to server LDP merging) and yet as soon as PWs become multi-hop they (ie their labels) need to take on a normal (DA proxy) forwarding label semantic.  However, this really all ought to be academic to MPLS-TP because here we must have proper single-source connections (to manage resource for clients) and thus must deprecate the loss of source information case.  As I responded earlier to Sasha, in MPLS-TP everything is a PW (in name at least) because all clients need to be treated equally.  But this still leaves the S bit sublayering issue....which I have already given my analysis/views on (the key case to solve IMO being MPLS(TP)overMPLS(TP) because this would give a solid basis for MPLS-TP assuming a true transport role).

regards, Neil  

> [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: 25 August 2009 19:58
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Malcolm 
> Betts; [email-masked]; [email-masked]
> I don't see what I said different.
> 
> Igor
> 
> Sent: Tuesday, August 25, 2009 2:54 PM
> To: ext Malcolm Betts; Igor Bryskin; [email-masked]; 
> [email-masked]
> To: 'Igor Bryskin'; Sprecher, Nurit (NSN - IL/Hod HaSharon); 
> [email-masked]; [email-masked]
> to MPLS -

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 08:18:14 +0100

On 25/08/2009 08:33, "[email-masked]" <[email-masked]> wrote:
> thank you for your replying . IMO. since mpls may be extended to realize and
> encompass MPLS-TP requirements. while from the view of requirements aspect or
> function aspect , MPLS-TP will have more than MPLS. why regard mpls-tp as
> subset of MPLS. I don't see this point.

Think of it like a venn diagram.

Today we have what we have with MPLS.
Tomorrow we will extend MPLS with additional functionality to address
transport network requirements not already addressed within MPLS technology
The day after tomorrow MPLS-TP will use a subset of the extended MPLS tool
kit and be a subset of that extended MPLS tool kit.

MPLS is not a fixed set of capabilities. It is and always has constantly
evolved new capabilities like most technologies do over time.

Ben

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 08:21:56 +0100

Liu

On 25/08/2009 09:28, "[email-masked]" <[email-masked]> wrote:
> ni hao ,huub 
> I am thankful for you. I completely understand your meaning. IMO, we should
> change or revise mpls-tp requirement draft. MPLS-TP is a subset of the
> extended MPLS. while not MPLS. so we maybe misunderstand this meaning.

IMO there is no need to revise the MPLS-TP requirements draft. The
definition of MPLS has never been a fixed set of capabilities.

Ben

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Aug 2009 13:38:44 +0100

I agree, and indeed it will continue to evolve for the foreseeable future.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Aug 2009 13:56:24 +0100

Igor

You originally said:

I took this to mean split it between a context layer (you only
have context cases in the (a) list ) and a delivery layer,
and delivery needs LDP as one type of CP.

However, I disagree with the split you propose in any
case. MPLS is an extremely flexible general purpose mechanism
(which is why it has been so successful) and it would
damage that generality if the split was introduced.

If you want to create some new MPLS that is special to
transport, then that's option 2.

- Stewart

Igor Bryskin wrote:
> Stewart,
>
> I suppose you refer to LDP managed LSPs which are not nested within RSVP-TE pipes. I believe that in this case there is no MPLS transport layer at all (TL=NULL): all LDP speakers participate in the MPLS Service layer CP and DP.
>
> The reason IMO why GMPLS is the choice for MPLS-TP CP (BTW neither LDP nor BGP belong to GMPLS) is that one important responsibility of MPLS-TP is to provide traffic engineering capabilities, which could be done by either MP or RSVP-TE/IGP-TE based CP.
>
> Cheers,
> Igor
>
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 21 Aug 2009 12:18:29 -0400

Hi Neil,

Cheers,
Igor

Colleagues,

====

===

===

====

===

thanks.....regards, Neil

  Thanks
Yuanlong Jiang
----- Original Message -----
From: Yong Lucy<mailto:[email-masked]>
To: 'Jiang Yuan-long'<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; 'Drake, John E'<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Friday, August 21, 2009 3:14 AM
Subject: RE: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

Hi Jiang and John,

Regards,
Lucy

________________________________
From: Jiang Yuan-long [mailto:[email-masked]]
Sent: Wednesday, August 19, 2009 10:20 PM
To: [email-masked]<mailto:[email-masked]>; Drake, John E
Cc: [email-masked]<mailto:[email-masked]>; Yong Lucy; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

Hi Liu,

Thanks,
Yuanlong
----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: Drake, John E<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> ; Yong Lucy<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Jiang Yuan-long<mailto:[email-masked]>
Sent: Thursday, August 20, 2009 9:53 AM
Subject: RE： [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

hi,all

how about all?

best regards
liu

"Drake, John E" <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2009-08-20 04:31

收件人

"Yong Lucy" <[email-masked]<mailto:[email-masked]>>, "Jiang Yuan-long" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>

抄送

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

主题

ie

Lucy,

Thanks,

John

---

From: "Mark Sandstrom" <[email-masked]>
Date: Fri, 21 Aug 2009 13:49:48 -0400

I largely agree with Neil’s views, as well as Igor’s point regarding need for MPLS-TP transport plane standard to allow developing generic, low cost / Gbps pure-L2 MPLS-TP LSRs that do not need to support the L2+ MPLS services layer functions.  

Best regards,

Mark Sandstrom

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 21, 2009 10:47 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - NeeRE:[PWE3] An error in RFC 4446"IANA Allocationsfor PseudowireEdge to Edge Emulation (PWE3)"

regards, Neil

	Hi Neil,

	e) Etc.

	Cheers,

	Igor  

	Colleagues,

	====

	===

	===

	====

	===

	thanks.....regards, Neil

		Lucy, 

		  Thanks 

		Yuanlong Jiang

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

			Hi Jiang and John,

			Do you think so?

			Regards,

			Lucy

			Hi Liu,

			Thanks,

			Yuanlong

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

				
				hi,all 
				
				how about all? 
				
				best regards 
				liu

2009-08-20 04:31 

收件人

抄送

主题

 

ie

				
				Lucy,

				
				Thanks,
				
				John

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 24 Aug 2009 10:56:46 -0400

Hi Ben,

I am glad that you think this way. I am also glad that so far nobody has responded negatively in the context of this discussion.

However, I know for a fact that not all people view the MPLS-TP effort as an enhancement of MPLS lower layer. It would be greatly beneficial IMO, if MPLS-TP documents (requirements, framework) state clearly this intention.

Today MPLS-TP is defined as a subset of MPLS necessary to support packet-switched transport networks with an option to introduce new or replace existing MPLS machinery when/if such enhancements prove necessary. This could easily be interpreted as an attempt to develop a parallel technology for managing an existing data plane. This new technology is entitled borrow tools it likes from the existing technology and throw away ones it does not like, replacing them with new ones. The short name for such new technology IMO is T-MPLS, the same ITU-T effort that infuriated so much IETF. It does not matter that now it is called MPLS-TP. I am sure that ITU-T folks that started the T-MPLS are confident that they still can achieve the same objectives.

IETF, however, owns the MPLS data plane, and is understandably concerned about the havoc that could be created if/when two technologies are deployed in the same network. To avoid such havoc it is imperative to impose certain rules that:
a) clearly identify the space/layer where the enhancements must take place;
b) encourage re-using existing tools vs. introducing new ones.

I find the MPLS-TP documents confusing. Let's take one example from the requirements document.

Two questions:
a) Why MPLS-TP must be able to interoperate with IETF PWE3 control and data planes, considering that everything developed on PWE3 belongs to MPLS Service layer, while MPLS-TP is only concerned with MPLS transport layer? IMO PWs should not be mentioned in the MPLS-TP documents at all except for an appendix enumerating MPLS-TP envisioned clients;

b) Why do you need to say that MPLS-TP must be interoperable with MPLS RFC3031, considering that MPLS-TP is meant to be a an enhanced version of MPLS, which means it must be backward compatible to the older version. This goes without saying.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 21, 2009 8:30 PM
To: Igor Bryskin; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

Igor,

Ben

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 24 Aug 2009 13:45:21 -0400

Hi Lucy,

Please, see in line.

Cheers,
Igor

-----Original Message-----
From: Yong Lucy [mailto:[email-masked]]
Sent: Monday, August 24, 2009 1:20 PM
To: Igor Bryskin; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Section 3.4.1 of the MPLS TP Framework I-D - Nee RE: [PWE3] An error in RFC 4446"IANA Allocations for PseudowireEdge to Edge Emulation (PWE3)"

Hi Igor,

IB>> correct

IB>> correct

IB>> It depends on how one defines client-server adaptation. BTW I don't see anything wrong with an MPLS-TP layer and its client sharing the same label stack. For example, one MPLS-TP layer can serve another MPLS-TP layer.

Cheers,
Lucy

place;
(ii)

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 25 Aug 2009 13:50:21 +0200

Neil,

Your analogy is broken. You are comparing a VLAN layer network with an ESP
layer network, and yes it should be obvious that the access points of the
VLAN layer network can not be connected to the access points of the ESP
layer network.

However, if you have an 802.1ad/.1ah non-traffic engineered VLAN based
network with 802.1Q CP components (STP, GVRP/MVRP) and you connect this with
a VLAN based network without those 802.1Q CP components (STP, G/MVRP) but
instead with NMS or GMPLS controlled Traffic Engineered VLAN set up, then
the access points of both the non-traffic engineered and traffic engineered
VLAN networks can be interconnected with each other.

Regards,
Maarten 

-----Original Message-----
Sent: dinsdag 25 augustus 2009 10:39

Hubb...understand the sentiments but I believe we need to look at this
slightly differently...please see comments in-line:

> In order to make a transport profile of MPLS that meets the ITU-T 
> requirements for a transport network MPLS has to be extended with OAM 
> functions to meet these requirements.

NH=> If MPLS is extended then by definition the extended version cannot be a
subset of the previous version, ie it has new components that do not appear
in the original base form of MPLS.

This is not a problem at all.  But what it does mean is that MPLS-TP is a
new layer network.  Sure it can (and indeed should/must) re-use existing
IETF defined DP/CP/MP components where these are most suitable and
best-of-breed (eg GMPLS OOB CP).

Here is an analogy to really ram home this point.  If I take an Ethernet
traffic unit and replace the cl-ps CP components (eg STP, BU, SA
learning/ageing) with co-ps CP components (eg GMPLS) then I create a very
different layer network to the original Ethernet layer network.  They share
an identical traffic unit but you cannot meaningful interconnect/network
them, ie the access points of the cl-ps mode Ethernet (say
802.1d/802/1ad/802.1ah) layer network must not be able to connect to the
access points of the co-ps mode Ethernet (say 802.1Qay) layer network...they
lie in distinct/different layer network spaces.

Further, a transport network is a little more than OAM.  Most fundamentally
a transport network is all about providing transparent and assured resource
to its clients....and this starts with having proper connections.

regards, Neil 
> >  > to develop MPLS-TP functions and standards. in addtional, it is 
> > diffcult for  > MPLS-TP  > products to be suitable for requirement 
> > of packet
> transport network
> > of the
> >  > future very well.
> >  >
> >  > best regards
> >  > liu
> >  >
> >  >
> >  >
> >  >
> >  > <[email-masked]> 2009-08-22 08:30  > 收件人
> > <[email-masked]>,  > <[email-masked]>, 
> > <[email-masked]>, <[email-masked]>  > 抄送
> >  > <[email-masked]>, <[email-masked]>  > 主题
> > agreeing to  >> define MPLS-TP as a subset of MPLS needed to support
> packet switched
> >  >> transport
> >  >> In fact, MPLS-TP becomes increasingly a superset of MPLS. What 
> > should be done  >> IMO is as follows:
> >  >>
> >  >> with traffic engineering capabilities)  >> 1. Call the lower 
> > layer MPLS-TP and concentrate on its
> enhancements:
> >  >> that PWs are NOT a part of the MPLS-TP, there is no difference 
> > between MPLS  >> PWs and MPLS-TP PWs, and if there is anything wrong
> with PWs, it
> > should be
> >  >> fixed outside of the MPLS-TP effort;  >> 2. It would be also 
> > clear the importance of
> perseverance of MPLS OAM
> > wherever

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 25 Aug 2009 10:25:36 -0400

Huub,

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Tuesday, August 25, 2009 3:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Ni hao Liu,

A profile is a subset.

Regards, Huub.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 25 Aug 2009 14:00:12 -0400

Igor

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 1:40 PM
To: Igor Bryskin; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Igor,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Igor Bryskin
Sent: Tuesday, August 25, 2009 5:26 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Huub,

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Tuesday, August 25, 2009 3:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Ni hao Liu,

A profile is a subset.

Regards, Huub.

---

From: Malcolm Betts <[email-masked]>
Date: Tue, 25 Aug 2009 14:50:06 -0400

Igor,

Regards,

Malcolm

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 25 Aug 2009 14:54:50 -0400

Correct.

Igor

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 2:50 PM
To: Igor Bryskin; 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Igor,

Regards,

Malcolm

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 25 Aug 2009 14:57:34 -0400

Igor

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 2:54 PM
To: ext Malcolm Betts; Igor Bryskin; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS vs MPLS-TP (changed subject)

I agree with Malcolm.
Best regards,
Nurit

-----Original Message-----
From: ext Malcolm Betts [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 9:50 PM
To: 'Igor Bryskin'; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Igor,

Regards,

Malcolm

---

From: Malcolm Betts <[email-masked]>
Date: Tue, 25 Aug 2009 15:00:33 -0400

Nurit,

I agree that the IETF is making a significant effort to extend MPLS to
add the capabilities necessary to meet the requirements of the Transport
network as identified by the ITU. 

The requirements of the Transport network can be met with a subset
(profile) of the full (extended) capabilities of MPLS.  Although the
general name for the work is MPLS-TP (-Transport Profile) it is very
clear that what is being defined is the superset extension, not just
those aspects of MPLS that are require to satisfy only the requirements
of the transport network.

I think that this is the point that Igor and Huub have been making.

Regards,

Malcolm 

> Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: Tuesday, August 25, 2009 1:42 PM
> Subject: Re: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)
> 
> Huub,
> I do not agree with your observation "The focus of IETF is on the
> extended MPLS. The focus of ITU-T is on MPLS -TP."
> The IETF put a lot of efforts in defining MPLS-TP, the profile which
> addresses requirements coming out of the ITU-T and from SPs.
> Best regards,
> Nurit
> 
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 25 Aug 2009 17:41:16 -0400

Stewart,

Cheers,
Igor

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2009 4:31 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Malcolm Betts; Igor Bryskin; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Stewart

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 26 Aug 2009 09:52:52 -0400

Stewart,

How in your opinion MPLS-TP CP should look like? Specifically, what protocols and applications it should borrow from MPLS CP, which should be added? Do you believe that MPLS-TP CP should be a subset of an extended MPLS CP? Or should MPLS-TP CP be identical to MPLS CP?

And the other question: do you believe there is some future for generic, low cost / Gbps pure MPLS-TP LSRs that do not need to support the MPLS services layer functions?

Thanks,
Igor  

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2009 8:56 AM
To: Igor Bryskin
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Malcolm Betts; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS vs MPLS-TP (changed subject)

Igor

You originally said:

- Stewart

---

From: Malcolm Betts <[email-masked]>
Date: Wed, 26 Aug 2009 11:20:52 -0400

Stewart,

As you know we have a few (e.g. use of IP forwarding if it is available,
associated bi-directional LSPs) but this is not the real issue.  The
MPLS-TP project in IETF is defining the extended super set, what is not
documented is which parts of "legacy MPLS" (for want of a better term)
are not required for transport network applications.  This is the issue
that has created significant debate in the MEAD team on the scope of
G.8110.1.  It is also the question that Igor has been asking, to quote
from his latest email.

" And the other question: do you believe there is some future for
generic, low cost / Gbps pure MPLS-TP LSRs that do not need to support
the MPLS services layer functions?"

This is clearly the original intention of the vendors and network
operators who attend ITU-T SG15 i.e. minimal packet capability
implemented on an essentially circuit switch transport network platform.

Regards,

Malcolm

> Sent: Tuesday, August 25, 2009 4:36 PM
> To: Malcolm Betts
> Cc: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; [email-masked];
> [email-masked]; [email-masked]; [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Aug 2009 16:27:39 +0100

> How in your opinion MPLS-TP CP should look like? Specifically, what protocols and applications it should borrow from MPLS CP, which should be added? Do you believe that MPLS-TP CP should be a subse…
In building a transport network you need GMPLS to set up the MPLS LSPs 
being used to provide the service and LDP to configure the PWs.

You only need to implement as much of those protocols as your product 
needs in the deployment. Generally the IETF leaves it up to the vendor 
to decide what functions to implement and the network operator then 
determines which of those functions they will deploy.

> And the other question: do you believe there is some future for generic, low cost / Gbps pure MPLS-TP LSRs that do not need to support the MPLS services layer functions?
There is nothing that we have so far specified that prevents you 
building a sub-set of the design. In the profile you suggest above you 
seem to be proposing a P router to be deployed in a transport network, 
seems entirely feasible to me.

Stewart

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 26 Aug 2009 11:53:53 -0400

Stewart,

Please, see in line.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2009 11:28 AM
To: Igor Bryskin
Cc: Malcolm Betts; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] MPLS vs MPLS-TP (changed subject)

In building a transport network you need GMPLS to set up the MPLS LSPs
being used to provide the service

 IB>> agree, this would be a network building for MPLS Service layer

and LDP to configure the PWs.
IB>> disagree. Configuring PWs is a function of MPLS service layer

> And the other question: do you believe there is some future for generic, >low cost / Gbps pure MPLS-TP LSRs that do not need to support the MPLS >services layer functions?
>
>   

IB>> Correct. My suggestion is to clearly identify this subset. IMO it is "pure" RSVP-TE/IGP-TE based GMPLS. In particular, these low cost / Gbps pure MPLS-TP LSRs should not talk LDP in my opinion.

Igor

Stewart

---

From: "BOCCI Matthew" <[email-masked]>
Date: Wed, 26 Aug 2009 18:58:50 +0200

Igor,

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Igor Bryskin
> Sent: 26 August 2009 16:54
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> > How in your opinion MPLS-TP CP should look like? Specifically, what
> protocols and applications it should borrow from MPLS CP, which should
be
> added? Do you believe that MPLS-TP CP should be a subset of an
extended
> MPLS CP? Or should MPLS-TP CP be identical to MPLS CP?
> >
> > And the other question: do you believe there is some future for
generic,
> >low cost / Gbps pure MPLS-TP LSRs that do not need to support the
MPLS
> >services layer functions?
> >
> >
> IB>> Correct. My suggestion is to clearly identify this subset. IMO it
is
> "pure" RSVP-TE/IGP-TE based GMPLS. In particular, these low cost /
Gbps
> pure MPLS-TP LSRs should not talk LDP in my opinion.

What you are asking for seems to be fine if all you are doing is
LSR/P-router functionality. You don't need to terminate/switch PWs and
therefore do not need to participate in LDP.

However, there are those of us who also want to deliver L2 and L3
services from PEs and carry them over MPLS-TP LSPs. The PWs supporting
some of those services use LDP, and it would also be useful to inherit
the OAM used for the underlying LSPs on those PWs. Such MPLS PWs are
inherent in supporting these packet transport services, and must be
managed as such. Therefore, they form a part of the overall architecture
for MPLS-TP.

That said, it is true that we have not explicitly described a P router
in the MPLS-TP Framework draft. Would it help if we did this and
detailed this and explained more clearly the elements of the profile
that are required for this?

Matthew

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 26 Aug 2009 18:21:47 +0100

Igor
> IB>> Correct. My suggestion is to clearly identify this subset. IMO it is "pure" RSVP-TE/IGP-TE based GMPLS. In particular, these low cost / Gbps pure MPLS-TP LSRs should not talk LDP in my opinion.

How would you propose to control the PE functionality to  set up the PWs?

Stewart

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 26 Aug 2009 14:13:00 -0400

Mathew,

[SNIP]

What you are asking for seems to be fine if all you are doing is
LSR/P-router functionality.

IB>> Right. Suppose I want to do a GMPLS and/or MP controlled P router

 You don't need to terminate/switch PWs and
therefore do not need to participate in LDP.

IB>> Correct, I just provide a network building for PEs.

However, there are those of us who also want to deliver L2 and L3
services from PEs and carry them over MPLS-TP LSPs. 

IB>> Exactly my point. I want to separate L2/L3 service provider layer from MPLS-TP LSPs layer. I want to call the MPLS-TP LSPs layer MPLS-TP and separate it from its clients (PW is one of them)

The PWs supporting
some of those services use LDP,

IB>> Correct. My question is why do we need to consider PWs in the context of MPLS-TP rather than outside of it? In IETF we do not work on everything to do with MPLS in the MPLS WG. We have PWE3, L3 VPN, L2 VPN WGs for a reason. 

 and it would also be useful to inherit
the OAM used for the underlying LSPs on those PWs. 

IB>> Nothing prevents from doing so as an effort in PWE3 WG.

Such MPLS PWs are inherent in supporting these packet transport services, and must be managed as such. Therefore, they form a part of the overall architecture for MPLS-TP.

IB>> There are some fundamental differences between MPLS-TP LSP layer and its clients. For example, MPLS-TP provides traffic engineering capabilities. It is also concerned with adaption/integration into various media (e.g. WDM) layers. PWs layer has entirely different responsibilities. That is why today people usually nest LDP-LSPs carrying PWs within RSVP-TE pipes.

IB>> It would certainly help. Still I would suggest separate frameworks for P-layer and PE-layer

Igor

Matthew

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 26 Aug 2009 20:30:28 +0200

Stewart,

With the decision to use label stacking to support segment monitoring, the
connection in the "PW" layer may be equipped with one PW label stack entry
header and one or more LSP label stack entry headers (one for each
additional MEG level). For this reason I have suggested in previous emails
to refer to this layer as the MPLS-TP VC (MVC) layer. The connections in
this MVC layer must be traffic engineered to support the CIR/EIR
requirements in the SLAs. Such MVC connections (including their possible MEG
levels) can only be set up using either NMS or an ASON/GMPLS control plane.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: woensdag 26 augustus 2009 19:22
To: Igor Bryskin
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)

Igor
>
> IB>> Correct. My suggestion is to clearly identify this subset. IMO it is
"pure" RSVP-TE/IGP-TE based GMPLS. In particular, these low cost / Gbps pure
MPLS-TP LSRs should not talk LDP in my opinion.

Stewart

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 20:02:08 +0100

Stewart,

> Igor
> >
> > IB>> Correct. My suggestion is to clearly identify this 
> subset. IMO it is "pure" RSVP-TE/IGP-TE based GMPLS. In 
> particular, these low cost / Gbps pure MPLS-TP LSRs should 
> not talk LDP in my opinion.
> >
> >   
> 

NH=> Given we should not (IMO must not) create a PW co-ps mode layer
network above MPLS-TP then PWs can only have a DP adaptation role in the
context of MPLS-TP.  We do not network adaptation functions...so I am
struggling to grasp any additional signalling requirement, eg (targeted)
LDP signalling here, above that necessary to establish/configure the
MPLS-TP LSP.

Remember that the principal technical reason for having the PW labels in
MPLS as-is is to convey source information that any potential lower
layer vanilla LDP merging LSPs lose.  Given that merging behaviour is
not allowed in MPLS-TP (ie no LDP, or PHP) then I believe the problem is
largely as Igor described it, ie the GMPLS CP (or MP) sets up MPLS-TP
LSPs and part of that set-up should cover any configuration
issues....for example, the signalling protocol should inform the DP sink
point of the expected SA it will receive in MPLS-TP LSP DP CV OAM
packets;  moreover, the activation/deactivation of OAM should be done in
sync with the MPLS-TP set-up/tear-down CP (or MP) actions.

regards, Neil

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 08:40:08 +0100

Hi Matthew....I have some questions for you...snipped to topic in-line:
 
Matthew wrote in response to Igor 26 August 2009 17:59
> the OAM used for the underlying LSPs on those PWs.

NH=> There are several things that are getting mixed-up here.  And I
think we do need a technical discussion on these points to get some
general clarity across the community.   

Firstly, in MPLS-TP there should never be a PW layer network above
MPLS-TP.  I hope the reasons for this are clear, ie I can't see how
anyone can claim MPLS-TP is providing a transpport network function if a
consequence of this is that its spawns another co-ps mode PW layer
network above it.  Do you agree with that view?

Secondly, a consequnce of the above observation is that the PW needs to
revert back to an adaptation role (whether one considers the CW useful
adaptation or not is a secondary consideration, the key point is that
this must not become a networked entity).  Do you agree with this
consequence?

Thirdly, one wants generic OAM that is associated with the trail
termination points of MPLS-TPs and is independent of which
service/client they are carrying, and it also allows one to monitor
protection LSPs that are not currently carrying any client (ie waiting
to be invoked when needed).  Do you agree with this view?

The conclusion here is that the OAM is associated with the MPLS-TP
(trail termination function) and not the PW adaptation function.  An
important corollary of this is that if any MPLS-TP LSPs suffer
misconnectivity then we should have consistent OAM on them (irrespective
of client use-case, eg IP-VPN, PW) so that the detection/handling of the
defect is done consistently.

As I also noted in an earlier mail (in response to Stewart), it will
also be important for the CP (or MP) that sets-up/tears-down the MPLS-TP
LSP to (i) inform the LSP sink(s) of the expected SA in any CV OAM pkts
and (ii) activate/deactivate the OAM in sync with LSP set-up/tear-down
actions (I think this is obvious from operational/service
considerations).  Do you agree with this requirement?

> Such MPLS PWs are
NH=> Well, they can only become the generic adaptation function in the
MPLS-TP architecture IMO.

regards, Neil

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 27 Aug 2009 14:30:42 +0200

Hi Neil,

> Sent: 27 August 2009 08:40
> To: BOCCI Matthew; [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)
> 

You are assuming that MPLS-TP only encompasses the LSP tunnel hierarchy
below the PW. Well, my question to you is where do you believe the
transport function providing the packet transport service exists? i.e.
at what (sub-)layer in the MPLS stack? 

If you are providing a transport service to e.g. Ethernet, ATM, FR etc
then the IETF specified way to do that in an MPLS network is to use a
PW. 

> this must not become a networked entity).  Do you agree with this

Nothing is forcing you to use MS-PWs. As you know, MS-PWs are only a
deployment choice in order to address some requirements that are well
documented in RFC5254. In both SS-PWs and MS-PWs, the PW is playing an
adaptation role, but even in the SS-PW case it does more than that
because it includes a multiplexing function. 

> to be invoked when needed).  Do you agree with this view?

Yes, and indeed generic OAM that can operate at all of the levels in the
MPLS network is exactly what MPLS-TP aims to provide.

> defect is done consistently.

OAM is necessary in the PW adaptation function, even in the SS-PW case,
precisely because of the multiplexing function provided by the PW label.
OAM can assure the binding of a PW instance to the service that it
provides. This is no different from LSP OAM in the case of IP over MPLS.
As mentioned above, the same MPLS-TP OAM will be applicable whether we
are talking about an LSP or a PW.

Regards

Matthew

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 14:45:33 +0100

Thanks Matthew..please see my further remarks in-line. 

> Sent: 27 August 2009 13:31
> [email-masked]
> > anyone can claim MPLS-TP is providing a transpport network 
> function if
> a
> below the PW.

NH=> Sort-of, but the key point here is that if we create a transport
network (any) then I'm struggling to see why this should generate
another layer network above it.  PWs arose because of LDP....we simply
had to add a new labelled header here to recover the lost source
information due to the LDP server.  But we don't have LDP in MPLS-TP.
In fact had we used RSVP-TE instead of LDP we would not have needed to
add a PW label to carry a single client....no other co-ps server (and
for sure no co-cs server) technology requires this. A SS-PW is one thing
(ie adaptation) but a MS-PW is a full-blown co-ps mode layer network.
Should we really be allowing this *above* MPLS-TP that is supposed to be
a transport network?

Not sure if you recall the early days of GFP, but some folks wanted to
start adding functionally and making this multi-hop (ie a switched
entity).  This would have defeated the original generic adaptation role
that GFP was designed to address, ie GFP would have become just another
layer network and we would have only suceeded in chasing the (still
required) generic adaptation function up another level.  IMO PWs should
be all about generic adaptation of clients, not the creation of another
co-ps mode layer network above MPLS/MPLS-TP.  I would have assumed this
would be obvious/agreeable.

> Well, my question to you is where do you believe the

NH=> This is an excellent question because it requires one to think
about what sublayering via a digital wrapper approach really
means....the S bit issue.  It's my personal view that arbitrary nesting
is really not required in a transport network....each 'level' should be
its own layer network.  If I look at the MPLS headers it's really only
the bottom/outer one that has a fowarding (==transport) semantic.  The
others (higher level) labels are used to carry other semantics, eg an IP
VPN (rfc4364) BGP4 issued label can identify a VRF of a specific client
VPN, a PW label must carry a source semantic to recover the loss of this
information due to any lower level LDP merging (indeed you would not
require such a label if (i) the client is cl-ps like IP, since a cl-ps
traffic unit has an absolute SA and recover the lost merging information
itself) or (ii) the client was carried over a RSVP-TE server LSP
connection say).

In addressing your question one might also make the observation that a
transport network should have the ability to 'put bits on the wire', ie
have a physical interface specification.  Indeed, we must always have a
real bottom-of-stack transport network that can modulate an EM wave else
information cannot travel over geographic distance.  So this raises an
interesting question of whether MPLS-TP should be called a 'transport
network' at all....as it still requires a real transport network
underneath it.

> Nothing is forcing you to use MS-PWs.

NH=> Understood, but that is not the point. The real issue here is what
do MS-PWs represent?...and I think its fairly obvious (at least to
anyone who comes at this with a func arch background) that they must
represent a layer network, ie they have become a switched entity by
definition of being multi-hop.  And if they do represent a layer
network:
-	their labels need to change context and have a fowarding
semantic (and not a source semantic as the case if underlaid with a
merging LDP LSP that loses source information)
-	in my mind at least it questions just what MPLS-TP is really
doing if it generates another co-ps mode layer network above
it.....where is the generic adaptation now gone to?

> As you know, MS-PWs are only a

NH=> Yes I know it is protrayed like that (ie a muxing function) but let
me ask you to consider this.  Suppose you just carried a single client
from A to Z over a server LDP network.  How would determine where it
came from when it gets to Z?  Unless the client was cl-ps like IP, you
would have no way to recover this information when you removed the LDP
forwarding header at Z => ergo you must add a PW label that carries
source information.  This point is taken for granted in all other co-ps
mode technologies that only use proper single source connections, ie the
connection itself carries the source information, and that is why we can
take a short-cuts in labelling and omit a SA label in a co-ps mode
traffic unit.  And of course one would not require a PW label if you
carried a single client over an RSVP-TE server LSP.
> precisely because of the multiplexing function provided by 

NH=> Let's go back to the case of carrying a single client over a
RSVP-TP LSP that respect the rules of a connection, ie single
source....you do not require a PW label here, and the OAM would be
associated with the RSVP-TP trail term points.  But I would most
certainly agree that in the case of MS-PWs (even if carried over RSVP-TE
LSPs, ie a different server RSVP-TE LSP per hop of the MS-PW client) you
do need an OAM function because there is no longer a congruent span of
binding between the client and its server...indeed the client is its own
layer network now and thus neewds its own OAM.
  
> provides. This is no different from LSP OAM in the case of IP 

NH=> Indeed so...IP is here most definitely its own layer network, and
IP requires its own OAM that is not associated with the server...which
might be SDH VC4 or Ethernet say.

> are talking about an LSP or a PW.

NH=> Well, in the case of MS-PWs I can understand this. But I struggle
to see why we need MS-PWs in MPLS-TP *if* MPLS-TP is supposed to be a
transport network.

regards, Neil

---

From: Yong Lucy <[email-masked]>
Date: Thu, 27 Aug 2009 09:36:11 -0500

Hi Igor, Neil, Stewart, and all,

IMO. It is not necessary to split the framework into two. Section 3.4
describes MPLS-TP client as PW or a network layer. The issue is about PW. As
we know, a PW can be established in static or dynamic way. 

The static way means that PW configuration is independent of MPLS control
plane while the dynamic way relies on MPLS control plane. IMO: Since the
dynamic pw establishment requires MPLS control plane, we need to describe
this case as a client network and not as a simple pw any more. Thus, MPLS-TP
can treat dynamic pw and MPLS LSP in the same manner, i.e. a client network.

This is also inline with operator desire, i.e. the ability to configure an
end-to-end (CE<->CE) transport path without any IP. I suggest revising the
section 3.4 in the framework draft to state this as the framework. For PW
client, it likes pw->MPLS-TP LSP->pw; For MPLS network client, it likes MPLS
(pw/lsp)->MPLS-TP-> MPLS(pw/lsp). From CE perspective, it can set up AC via
MPLS-TP PW or MPLS PW. Two methods may have different properties.

Does this make sense?

Cheers,

Lucy

> Sent: Wednesday, August 26, 2009 2:02 PM

> To: [email-masked]; [email-masked]

> > How would you propose to control the PE functionality to  set

> > up the PWs?

---

From: Jiang Yuan-long <[email-masked]>
Date: Fri, 28 Aug 2009 10:05:56 +0800

Hi Neil,

  Best regards
Yuanlong Jiang

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, August 27, 2009 9:45 PM
Subject: Re: [mpls-tp] [PWE3] MPLS vs MPLS-TP (changed subject)

> Should we really be allowing this *above* MPLS-TP that is supposed to be

[J]  But if there are multiple clients between two PEs, you must provide an 
LSP for
each of them without PW label as demultiplexer. I am afraid it may not be a
scalable scheme.

> would be obvious/agreeable.

[J] As I know, there is already an ITU-T Rec (Y.1418) focusing on the PW
layer network.  It also provides a generic adaption layer, i.e.,  PW.

>> Nothing is forcing you to use MS-PWs.

[J] Here I agree with Mattew, MS-PW is just an option.

---

From: <[email-masked]>
Date: Fri, 28 Aug 2009 13:46:12 +0100

Thanks Yaunlong...my responsese are in-line: 

> Sent: 28 August 2009 03:06
> To: Harrison,N,Neil,DEY2 R; [email-masked]; 
> [email-masked]; [email-masked]

NH=> I'm not following you here.  There is nothing to stop one muxing
lots of different higher clients *within* an LSP of the client MPLS
layer stack and carried by a single server layer MPLS LSP.  This is
normal hierarchy construction, ie LSP link connection at layer N (which
can encompasss many different layer N LSP instances) = server LSP trail
at layer N-1.

Aside=> What limits this in practice is how much of the server layer
resource is available.  Noting that this resource is *inherited* in a
recursive manner right down to the duct, ie one cannot provide more
resource to clients (at all higher levels) than the limit of the
physical resource at the very bottom of the stack, ie where we modulate
an EM wave.

If not clear what I mean by this, think of a co-cs case of a E1 single
connection carrying multiple 64k link connections (rememeber a link
connection (ie 1-hop) in client layer N network = end-end network
connection in server layer N-1 network (this can be an arbitrary no. of
hops in layer N-1)).  Now the co-cs mode *couples* labelling and
resource assignment (which is one reason its always been, and always
will be, the de facto transport network type at the very
bottom-of-stack).....time-slot start epoch = forwarding label, timeslot
*duration* = resource allocation.  Thus, in this example we can have a
max of 31 64k client link connections of a E1 trail....this is
determined by how the resource is carved up here, ie based on regular
time-slices in the co-cs mode time dimension.

When we deal with the co-ps mode labelling and resource allocation are
*not* coupled actions...further, the forwarding label MUST be explicit
in the traffic unit and its start/duration is based on a variable
epoch/time-slice.  If we respect the single source rules of a connection
we can omit a source label from the traffic unit.  If we only carry a
single client we can omit a PID label from the traffic unit.  Further,
we only need to make the destination fowarding label big enough to cater
for the max number of client N link connections we want to have on a
single hop of the N-1 server (ie this is proper muxing)....in other
words we can reduce the resolution of the fowarding label to link-unique
rather than network unique and use label-swapping (this has some OAM
operational disadvantanges however).  

Aside=> in the cl-ps mode the DA, SA must always be network
unique/present and a PID label must always be present....as there is no
connection to carry this information.

So when we are dealing with the co-ps mode we must pay particular
attention to resource allocation as well as labelling ...the co-cs mode
does all this for us as I noted above.
> layer network.  It also provides a generic adaption layer, i.e.,  PW.

NH=> One cannot always stop people doing wrong things.  The fact that a
PW layer has been created is now a fact.  I did try and warn folks not
to go here over many years.  But what we should do now is understand
this and not replicate this error in MPLS-TP.  IMO that would be
unforgivable as there is no appeal to 'I did not understand that' now.

regards, neil
> >> > Secondly, a consequnce of the above observation is that 
> the PW needs
> >> to
> >> > of client use-case, eg IP-VPN, PW) so that the 
> detection/handling of
> >> the
> >> > LSP to (i) inform the LSP sink(s) of the expected SA in 
> any CV OAM
> >> pkts

---

From: [email-masked]
Date: Sat, 29 Aug 2009 14:30:07 +0800

Neil
maybe what you said be too abstract to not completely your meaning. IMO, I 
haven't heard of the two concept of "source forwarding label" and " 
destination forwarding label" in co-ps network. 
IMO, Each node will depend on local LSP identifier or globe LSP identifier 
 to transport traffic packet in co-ps network. eg. PBT-TE ,each  packet 
for ESP will depend on ESP Identiifer( VLAN+Destination MAC) field on 
traffic unit. while for T-MPLS/MPLS/MPLS-TP , Since each node transporting 
traffic packet is based on local label. but local label must include the 
information of LSP identifier secretely.

can you clarify it.thank you.

best regards
liu

<[email-masked]> 
发件人:  [email-masked]
2009-08-28 20:46

收件人
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [PWE3] [mpls-tp]   MPLS vs MPLS-TP (changed subject)

regards, neil

---

From: <[email-masked]>
Date: Sat, 29 Aug 2009 10:32:14 +0100

Hi Liu...A more definitive explanation of how the 3 network modes arise, and what the consequences are for labelling in them, can be found in G.800 (largely written by my colleague Andy Reid).   I've written a (hopefully easier to read than G.800) internal paper on this topic, which also looks at a more optimal architecture where the 3 modes work in concert, which I could send you, but see if this description helps:
 
Note - There is more to networking that just labelling considerations....in particular one needs to understand how resource assignment works in each of the 3 modes and why, for example, a connection can only have a single-source.  This is all addressed in G.800.
 
All the 3 network modes that use directed routing (see Note) use destination forwarding, ie some label that points towards the sink point of the connection (co) or flow (cl).
 
Note - Original Ethernet does not use directed forwarding.  It uses a 'broadcast at source filter at sink approach' (at least before SAs are learnt in the DP).  Further, the addresses here are not topologically significant, ie they don't tell one where an address is, so the addresses here are actually names..  The first step to make any network mode scalable is to use addresses that are related to topology/location (but see Aside below) and some process for route calculation (which can be centralised or distributed).  Aside=> Although one should make addresses related to topology (for aggregation purposes) they should not be totally bound to topology.....if they are then one needs to change the addressing structure with any change in topology.
 
We usually do not take any source labels into account when forwarding (any mode).
 
The cl-ps mode does not create any transport constructs before it sends traffic units.  This means each traffic unit must contain all the information that is required.  And key here is an absolute DA, an absolute SA and a client payload PID....these can all be a called labels, ie DA label, SA label, PID label, in general sense.
 
The co-cs mode can apply to time, freq (eg lambda) and space (eg fibre) resource dimensions.  The time dimension of resource is of most interest.  The co-cs mode uses regular time-slices.  Each time slice has a fixed/known start epoch (this is the forwarding DA-proxy label) and (crucially) duration.....it is both these point that makes the co-cs mode fully resource deterministic at all scales....the former point allows the network to be treated as a synchronous state machine, whilst the latter point simply assigns a known/fixed resource to a client at all points in the network.  We do not need to add a SA label to the co-cs mode traffic units (time-slots) because the parent transport connection we create can only have a single source.....indeed, this single source property cannot be violated in the co-cs mode because of the 2 previous points that coupled labelling and resource assignment.  We also do not need to add a PID field providing the client is consistently the same.  {Aside=> If one does want to add a PID field one can do so with GFP which is a ngeneric adaptation function initially designed for the co-cs mode.  GFP provides other adaptation properties, like client traffic unit delineation and error checking.  Ethernet can also use GFP adaptation (eg for PBB-TE type of Ethernet where the Ethertype 0x801F has been assigned for this purpose.}
 
The co-ps mode can only apply to the time-dimension.  Here the time resource is carved-up using irregular time-slices.  This means both start epoch and duration (ie actual resource used) are decoupled actions.  Further, neither may be fixed/known in advance.....this is why more care has to be exercised here if one wants to have good control over resource allocation (ergo performance SLAs to clients).  One consequence of this is that we must add an explicit forwarding DA-proxy label to each co-ps traffic unit.  If we respect the requirement of a connection (ie single source)....which is critical for resource management considerations.....we can omit a SA label.  Similarly, if we only carry a single client we can omit a PID label (we could however add a PID, like the one found in GFP say and as used by the co-ps mode, should we require that a single/same connection carries different clients).  In other words, in the co-ps mode we require that the (parent) connection construct we create carries SA label and (usually) PID label information and thus these do not need to be carried by the (child) traffic units.
 
We can also take a further short-cut on the DA forwarding label if required.  The forwarding label must be larger enough in code-space to distinguish the largest number of clients that can appear a single link connection (=hop), noting that this link connection in layer N is provided by an end-end network connection at layer N-1.  This leads to the well-known forwarding paradigm of 'label-swapping' and it has been used by FR, ATM and MPLS.  However, there are distinct advantages (esp wrt to OAM considerations) to not swapping forwarding labels and  adding an absolute SA label to child traffic units.  This is how PBB-TE works, and it arises because the original cl-ps Ethernet traffic unit, which has absolute SA/DA labels because of its cl-ps mode origin, is re-used in PBB-TE (though PBB-TE and native cl-ps Ethernet form quite distinct/different layer networks even though they share an identical traffic unit).  One consequence of this is that such a network is self-protecting against misconnectivity defects without running any OAM at all.
 
Does that help Liu?  
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 29 August 2009 07:30
	To: Harrison,N,Neil,DEY2 R
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: Re: [PWE3] [mpls-tp] MPLS vs MPLS-TP (changed subject)

	Neil 
	maybe what you said be too abstract to not completely your meaning. IMO, I haven't heard of the two concept of "source forwarding label" and " destination forwarding label" in co-ps network. 
	IMO, Each node will depend on local LSP identifier or globe LSP identifier  to transport traffic packet in co-ps network. eg. PBT-TE ,each  packet for ESP will depend on ESP Identiifer( VLAN+Destination MAC) field on traffic unit. while for T-MPLS/MPLS/MPLS-TP , Since each node transporting traffic packet is based on local label. but local label must include the information of LSP identifier secretely. 

	best regards 
	liu

<[email-masked]> 

2009-08-28 20:46 

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
抄送
[email-masked], [email-masked] 
主题
Re: [PWE3] [mpls-tp]   MPLS vs MPLS-TP (changed subject)	

	

	

	
	
	regards, neil

---

From: [email-masked]
Date: Mon, 31 Aug 2009 10:32:51 +0800

Neil
 thank you for your explaining in detail. according to my understanding. 
is it unnecessary for co-ps network to have source label and PID label 
information in the traffic unit?  packet forwarding is only depend on 
destination label in traffic unit? eg. if a etherent service need to be 
transported by MPLS-TP LSP, it may transport the etherenet service to 
far-end PE of LSP. it is the key problem to distinguish which service the 
packet will belong to in the far-end PE if no pw label informations.

maybe my uderstanding be true?

best regards
liu

<[email-masked]> 
2009-08-29 17:32

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
主题
RE: [PWE3] [mpls-tp]   MPLS vs MPLS-TP (changed subject)

Hi Liu...A more definitive explanation of how the 3 network modes arise, 
and what the consequences are for labelling in them, can be found in G.800 
(largely written by my colleague Andy Reid).   I've written a (hopefully 
easier to read than G.800) internal paper on this topic, which also looks 
at a more optimal architecture where the 3 modes work in concert, which I 
could send you, but see if this description helps:
 
Note - There is more to networking that just labelling 
considerations....in particular one needs to understand how resource 
assignment works in each of the 3 modes and why, for example, a connection 
can only have a single-source.  This is all addressed in G.800.
 
All the 3 network modes that use directed routing (see Note) use 
destination forwarding, ie some label that points towards the sink point 
of the connection (co) or flow (cl).
 
Note - Original Ethernet does not use directed forwarding.  It uses a 
'broadcast at source filter at sink approach' (at least before SAs are 
learnt in the DP).  Further, the addresses here are not topologically 
significant, ie they don't tell one where an address is, so the addresses 
here are actually names..  The first step to make any network mode 
scalable is to use addresses that are related to topology/location (but 
see Aside below) and some process for route calculation (which can be 
centralised or distributed).  Aside=> Although one should make addresses 
related to topology (for aggregation purposes) they should not be totally 
bound to topology.....if they are then one needs to change the addressing 
structure with any change in topology.
 
We usually do not take any source labels into account when forwarding (any 
mode).
 
The cl-ps mode does not create any transport constructs before it sends 
traffic units.  This means each traffic unit must contain all the 
information that is required.  And key here is an absolute DA, an absolute 
SA and a client payload PID....these can all be a called labels, ie DA 
label, SA label, PID label, in general sense.
 
The co-cs mode can apply to time, freq (eg lambda) and space (eg fibre) 
resource dimensions.  The time dimension of resource is of most interest. 
The co-cs mode uses regular time-slices.  Each time slice has a 
fixed/known start epoch (this is the forwarding DA-proxy label) and 
(crucially) duration.....it is both these point that makes the co-cs mode 
fully resource deterministic at all scales....the former point allows the 
network to be treated as a synchronous state machine, whilst the latter 
point simply assigns a known/fixed resource to a client at all points in 
the network.  We do not need to add a SA label to the co-cs mode traffic 
units (time-slots) because the parent transport connection we create can 
only have a single source.....indeed, this single source property cannot 
be violated in the co-cs mode because of the 2 previous points that 
coupled labelling and resource assignment.  We also do not need to add a 
PID field providing the client is consistently the same.  {Aside=> If one 
does want to add a PID field one can do so with GFP which is a ngeneric 
adaptation function initially designed for the co-cs mode.  GFP provides 
other adaptation properties, like client traffic unit delineation and 
error checking.  Ethernet can also use GFP adaptation (eg for PBB-TE type 
of Ethernet where the Ethertype 0x801F has been assigned for this 
purpose.}
 
The co-ps mode can only apply to the time-dimension.  Here the time 
resource is carved-up using irregular time-slices.  This means both start 
epoch and duration (ie actual resource used) are decoupled actions. 
Further, neither may be fixed/known in advance.....this is why more care 
has to be exercised here if one wants to have good control over resource 
allocation (ergo performance SLAs to clients).  One consequence of this is 
that we must add an explicit forwarding DA-proxy label to each co-ps 
traffic unit.  If we respect the requirement of a connection (ie single 
source)....which is critical for resource management considerations.....we 
can omit a SA label.  Similarly, if we only carry a single client we can 
omit a PID label (we could however add a PID, like the one found in GFP 
say and as used by the co-ps mode, should we require that a single/same 
connection carries different clients).  In other words, in the co-ps mode 
we require that the (parent) connection construct we create carries SA 
label and (usually) PID label information and thus these do not need to be 
carried by the (child) traffic units.
 
We can also take a further short-cut on the DA forwarding label if 
required.  The forwarding label must be larger enough in code-space to 
distinguish the largest number of clients that can appear a single link 
connection (=hop), noting that this link connection in layer N is provided 
by an end-end network connection at layer N-1.  This leads to the 
well-known forwarding paradigm of 'label-swapping' and it has been used by 
FR, ATM and MPLS.  However, there are distinct advantages (esp wrt to OAM 
considerations) to not swapping forwarding labels and  adding an absolute 
SA label to child traffic units.  This is how PBB-TE works, and it arises 
because the original cl-ps Ethernet traffic unit, which has absolute SA/DA 
labels because of its cl-ps mode origin, is re-used in PBB-TE (though 
PBB-TE and native cl-ps Ethernet form quite distinct/different layer 
networks even though they share an identical traffic unit).  One 
consequence of this is that such a network is self-protecting against 
misconnectivity defects without running any OAM at all.
 
Does that help Liu? 
 
regards, Neil

From: [email-masked] [mailto:[email-masked]] 
Sent: 29 August 2009 07:30
To: Harrison,N,Neil,DEY2 R
Cc: [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] MPLS vs MPLS-TP (changed subject)

Neil 

best regards 
liu

<[email-masked]> 

收件人

regards, neil

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: <[email-masked]>
Date: Mon, 31 Aug 2009 08:35:24 +0100

Liu,
 
Please see in-line for answers....

From: [email-masked] [mailto:[email-masked]]
Sent: Mon 31/08/2009 03:32
To: Harrison,N,Neil,DEY2 R
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] [mpls-tp] MPLS vs MPLS-TP (changed subject)

Neil 
 thank you for your explaining in detail. according to my understanding. is it unnecessary for co-ps network to have source label and PID label information in the traffic unit? 
 
NH=> Yes.  The co mode (both co-cs and co-ps) create *parent* connection constructs before *child* traffic units can be sent.....this is obviously not the case for the cl-ps mode.  A connection can only have a single source if you want simple/detrministic resource management....and this is an essential requirement of a (network builder) transport network. 
 
The co-cs mode forces connections to have a single source due to the coupled nature of forwarding and resource assignment here....these actions are decoupled in the co-ps mode so one can, if one wants, break the single source rules of a connection.
 
Because a connection can only have a single source we can take 3 possible short-cuts on labelling:
- omit a SA label altogether
- omit a PID label if the connection is required to only carry a singles/same client over the connection lifetime
- reduce the scope of the (DA-proxy) fowarding label to only link unique rather than network unique.
 
Until we wrote G.800 the explanations of how labelling works, and indeed how the 3 modes come about, had never been formally analysed/written-down.
 
 packet forwarding is only depend on destination label in traffic unit? 
 
NH=> Yes.  Normal forwarding only uses a DA label...whether this is network unique (which it has to be in the case of the cl-ps mode) or link unique (a short-cut that can be used in the co modes).
 
eg. if a etherent service need to be transported by MPLS-TP LSP, it may transport the etherenet service to far-end PE of LSP. it is the key problem to distinguish which service the packet will belong to in the far-end PE if no pw label informations. 
 
NH=> You have to always remember that PWs are not a natural networking entity.  They are a consequnce of the original LDP specification of MPLS, ie because this (i) has to run IP layer traffic units raw in the DP (even though this IP is CP/MP information and not DP client information) and (ii) LDP creates merging constructs that, by definition, lose source information.  The former is a more general arch problem and requires a proper OOB CP/MP (like GMPLS) to address it, but it s the latter (merging) problem (aside=> PHP also causes last-hop merging) that means it is essential to add a higher label to correctly indentify the source (though this label is not necessary if the client is cl-ps, eg IP, providing its SA labels are unique as a client of the LDP server network).

NH=> Yes, I think you have grasped the key points.
 
regards, Neil

best regards 
liu

<[email-masked]> 

2009-08-29 17:32 

???
<[email-masked]> 
??
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
??
RE: [PWE3] [mpls-tp]   MPLS vs MPLS-TP (changed subject)	

  

  

  
  
Does that help Liu?   
  
regards, Neil 

Neil 

best regards 
liu 

<[email-masked]> 
???:  [email-masked] 

2009-08-28 20:46 

???
??
??

regards, neil