----------------------------------------= ---------------- ZTE Information Security Notice: The information= contained in this mail is solely prop= erty of the sender's organization. This mai= l communication is confidential. Recipients name= d above are obligated to maintain secrecy&n= bsp;and are not permitted to disclose the&n= bsp;contents of this communication to others. This email and any files transmitted with&n= bsp;it are confidential and intended solely = ;for the use of the individual or enti= ty to whom they are addressed. If you&= nbsp;have received this email in error plea= se notify the originator of the message.&nb= sp;Any views expressed in this message are&= nbsp;those of the individual sender. This message has been scanned for viruses&n= bsp;and Spam by ZTE Anti-Spam system.

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=3D1). 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:yljiang@huawei.com]
Sent: Wednesday, August = 19, 2009 10:20 PM
To: = liu.guoman@zte.com.cn; Drake, John E
Cc: l2tpext@ietf.org; = Yong Lucy; mpls-tp@ietf.org; mpls-tp-bounces@ietf.org; neil.2.harrison@bt.com; pwe3@ietf.org
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,

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: liu.guoman@zte.com.cn =

To: Drake, John E =

Cc: l2tpext@ietf.org ; Yong Lucy ; mpls-tp@ietf.org ; mpls-tp-bounces@ietf.org ; neil.2.harrison@bt.com ; pwe3@ietf.org ; Jiang = Yuan-long

Sent: Thursday, August 20, 2009 9:53 AM

Subject: RE=A3=BA [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=3D1) 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" <John.E.Drake2@boeing.com>=
=B7=A2=BC=FE=C8=CB: mpls-tp-bounces@ietf.org

2009-08-20 04:31

=CA=D5=BC=FE=C8=CB
=
"Yong Lucy" <lucyyong@huawei.com>, = "Jiang Yuan-long" <yljiang@huawei.com>, <neil.2.harrison@bt.com>, <pwe3@ietf.org> =

=B3=AD=CB=CD

l2tpext@ietf.org, mpls-tp@ietf.org =

=D6=F7=CC=E2

[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,

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

> -----Original Message-----
> From: Yong Lucy = [mailto:lucyyong@huawei.com]
> Sent: Wednesday, August 19, 2009 12:44 = PM
> To: Drake, John E; 'Jiang Yuan-long'; neil.2.harrison@bt.com;
> pwe3@ietf.org
> Cc: l2tpext@ietf.org
> Subject: RE: [PWE3] An error in RFC = 4446"IANA Allocations for
> PseudowireEdge to Edge Emulation = (PWE3)"
>
> 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
>
>
>
> > -----Original = Message-----
> > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]
> On Behalf
> > Of Drake, John E
> > Sent: Wednesday, August 19, 2009 8:09 = AM
> > To: Jiang Yuan-long; = neil.2.harrison@bt.com; pwe3@ietf.org
> > Cc: l2tpext@ietf.org
> > Subject: Re: [PWE3] An error in RFC = 4446 "IANA Allocations for
> > PseudowireEdge to Edge Emulation = (PWE3)"
> >
> > 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:yljiang@huawei.com]
> > > Sent: Tuesday, August 18, 2009 = 7:21 PM
> > > To: neil.2.harrison@bt.com; = pwe3@ietf.org
> > > Cc: = l2tpext@ietf.org
> > > Subject: Re: [PWE3] An error in = RFC 4446 "IANA Allocations for
> > > PseudowireEdge to Edge Emulation (PWE3)"
> > >
> > > 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: neil.2.harrison@bt.com
> > > = To: yljiang@huawei.com ; = pwe3@ietf.org
> > > = Cc: l2tpext@ietf.org
> > > = 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 =3D> 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: pwe3-bounces@ietf.org
> > > [mailto:pwe3-bounces@ietf.org] On = Behalf Of Jiang Yuan-long
> > > = = Sent: 18 August 2009 14:01
> > > = = To: pwe3@ietf.org
> > > = = Cc: l2tpext@ietf.org
> > > = = 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
> > >
> > >
> > >
> > = _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > = https://www.ietf.org/mailman/listinfo/pwe3
>
>
>
_______________________________________________=
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp
----------------------------------------------=
----------
ZTE Information Security Notice=
: The information contained in this mail&nb=
sp;is solely property of the sender's organ=
ization. This mail communication is confidential=
. Recipients named above are obligated to&n=
bsp;maintain secrecy and are not permitted =
to disclose the contents of this communicat=
ion to others.
This email and any files&n=
bsp;transmitted with it are confidential and&nbs=
p;intended solely for the use of the i=
ndividual or entity to whom they are a=
ddressed. If you have received this email&n=
bsp;in error please notify the originator o=
f the message. Any views expressed in =
this message are those of the individual&nb=
sp;sender.
This message has been scan=
ned for viruses and Spam by ZTE Anti-S=
pam system.