[L2tpext] 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)"

liu.guoman@zte.com.cn Thu, 20 August 2009 01:53 UTC

Return-Path: <liu.guoman@zte.com.cn>
X-Original-To: l2tpext@core3.amsl.com
Delivered-To: l2tpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F302F28C41E; Wed, 19 Aug 2009 18:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.518
X-Spam-Level:
X-Spam-Status: No, score=-94.518 tagged_above=-999 required=5 tests=[AWL=-1.728, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TueoY90eU1N4; Wed, 19 Aug 2009 18:53:48 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id DBB0428C42B; Wed, 19 Aug 2009 18:53:46 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111643655640568; Thu, 20 Aug 2009 09:33:17 +0800 (CST)
Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 5479.8546525775; Thu, 20 Aug 2009 09:45:01 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n7K1rc3V065288; Thu, 20 Aug 2009 09:53:38 +0800 (CST) (envelope-from liu.guoman@zte.com.cn)
In-Reply-To: <51661468CBD1354294533DA79E85955A01F792A9@XCH-SW-5V2.sw.nos.boeing.com>
To: "Drake, John E" <John.E.Drake2@boeing.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFD032DEEE.47144B84-ON48257618.00095168-48257618.000A755C@zte.com.cn>
From: liu.guoman@zte.com.cn
Date: Thu, 20 Aug 2009 09:53:17 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-08-20 09:53:36, Serialize complete at 2009-08-20 09:53:36
Content-Type: multipart/alternative; boundary="=_alternative 000A755948257618_="
X-MAIL: mse1.zte.com.cn n7K1rc3V065288
X-Mailman-Approved-At: Thu, 20 Aug 2009 05:58:41 -0700
Cc: l2tpext@ietf.org, Jiang Yuan-long <yljiang@huawei.com>, neil.2.harrison@bt.com, mpls-tp@ietf.org, pwe3@ietf.org, mpls-tp-bounces@ietf.org, Yong Lucy <lucyyong@huawei.com>
Subject: [L2tpext] 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)"
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2tpext>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2009 01:53:51 -0000

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" <John.E.Drake2@boeing.com> 
发件人:  mpls-tp-bounces@ietf.org
2009-08-20 04:31

收件人
"Yong Lucy" <lucyyong@huawei.com>, "Jiang Yuan-long" <yljiang@huawei.com>, 
<neil.2.harrison@bt.com>, <pwe3@ietf.org>
抄送
l2tpext@ietf.org, mpls-tp@ietf.org
主题
[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 => 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 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.