Subject: [L2tpext] 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: 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: [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 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: 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.