Re: [PWE3] Fw: I-D Action:draft-bryant-filsfils-fat-pw-03.txt

[Stewart Bryant <[e-mail]>]

Adrian Farrel wrote:
> Hi,
>
> I believe it would be really helpful if the filename of this draft 
> conformed to the normal conventions so that we could find it easily 
> and associated it with the PWE3 working group.
>
> For example...
> draft-filsfils-pwe3-fat-pw-00.txt

I hope we can fix that problem by issuing the next version
as draft-ietf-pwe3-fat-pw-00.txt

Stewart



From [e-mail]  Fri Mar  6 05:59:54 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF7C3A69BA; Fri,  6 Mar 2009 05:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 fkSM6BIqQjvj; Fri,  6 Mar 2009 05:59:53 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id BB4C03A6909; Fri,  6 Mar 2009 05:59:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 32F9A3B86431; Fri,  6 Mar 2009 09:00:24 -0500 (EST)
X-Virus-Scanned: amavisd-new at www.lucidvision.com
Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNhk94uzeK6Z; Fri,  6 Mar 2009 09:00:23 -0500 (EST)
Received: from [10.96.2.96] (unknown [217.39.1.35]) by lucidvision.com (Postfix) with ESMTP id CF1BF3B86426; Fri,  6 Mar 2009 09:00:21 -0500 (EST)
Message-Id: <[e-mail]>
From: Thomas Nadeau <[e-mail]>
To: Loa Andersson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 6 Mar 2009 14:00:00 +0000
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: George Swallow <[e-mail]>, [e-mail], ITU-T ad hoc team on MPLS-TP <[e-mail]>, [e-mail], [e-mail], [e-mail], David Ward <[e-mail]>, Malcolm Betts <[e-mail]>, VIGOUREUX MARTIN <[e-mail]>
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2009 13:59:54 -0000

	I think this document is ready to progress forward.

	--Tom


On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:

> All,
>
> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
> has been published.
>
> The draft is found at:
>
> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>
> Since the updates are significant this is to initiate a 2 week
> working group last call on the new version.
>
> Please send your comments to the [e-mail] mailing list.
>
> The working group last call will end on March 11.
>
> /Loa
> --  
>
>
> Loa Andersson
>
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  [phone]
>
>                                      email:   
> [e-mail]
>                                              [e-mail]
>                                              [e-mail]
>
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>


From [e-mail]  Fri Mar  6 08:41:33 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18CE3A657C; Fri,  6 Mar 2009 08:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.134
X-Spam-Level: 
X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ue-wOa8UX3YH; Fri,  6 Mar 2009 08:41:33 -0800 (PST)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id ADC033A6948; Fri,  6 Mar 2009 08:41:32 -0800 (PST)
Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 6 Mar 2009 16:42:02 +0000
Received: from 10.215.40.15 ([10.215.40.15]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri,  6 Mar 2009 16:42:01 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Fri, 06 Mar 2009 16:42:00 +0000
From: Ben Niven-Jenkins <[e-mail]>
To: Thomas Nadeau <[e-mail]>, Loa Andersson <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
Thread-Index: AcmeenhnQRpQH0GjPUmTSqrAenuIjw==
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 06 Mar 2009 16:42:02.0829 (UTC) FILETIME=[7A16E7D0:01C99E7A]
Cc: George Swallow <[e-mail]>, [e-mail], ITU-T ad hoc team on MPLS-TP <[e-mail]>, [e-mail], [e-mail], [e-mail], David Ward <[e-mail]>, Malcolm Betts <[e-mail]>, VIGOUREUX MARTIN <[e-mail]>
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2009 16:41:33 -0000

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without significant
changes to their existing support infrastructures.

Ben



On 06/03/2009 14:00, "Thomas Nadeau" <[e-mail]> wrote:

> 
> I think this document is ready to progress forward.
> 
> --Tom
> 
> 
> On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:
> 
>> All,
>> 
>> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
>> has been published.
>> 
>> The draft is found at:
>> 
>> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>> 
>> Since the updates are significant this is to initiate a 2 week
>> working group last call on the new version.
>> 
>> Please send your comments to the [e-mail] mailing list.
>> 
>> The working group last call will end on March 11.
>> 
>> /Loa
>> --  
>> 
>> 
>> Loa Andersson
>> 
>> Sr Strategy and Standards Manager
>> Ericsson ///                          phone:  [phone]
>> 
>>                                      email:
>> [e-mail]
>>                                              [e-mail]
>>                                              [e-mail]
>> 
>> 
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3


From [e-mail]  Fri Mar  6 16:30:02 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 5519E3A6B06; Fri,  6 Mar 2009 16:30:02 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri,  6 Mar 2009 16:30:02 -0800 (PST)
Cc: [e-mail]
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-oam-msg-map-09.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2009 00:30:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF.

	Title		: Pseudo Wire (PW) OAM Message Mapping
	Author(s)	: M. Morrow, M. Aissaoui, D. Allan, T. Nadeau, L. Martini
	Filename	: draft-ietf-pwe3-oam-msg-map-09.txt
	Pages		: 39
	Date		: 2009-3-2
	
This document specifies the mapping and notification of defect states 
   between a Pseudo Wire and the Attachment Circuits (AC) of the end-to-
   end emulated service. This document covers the case whereby the ACs 
   and the PWs are of the same type in accordance to the PWE3 
   architecture [RFC3985] such that a homogenous PW service can be 
   constructed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pwe3-oam-msg-map-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


From [e-mail]  Sun Mar  8 14:33:42 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973813A688E; Sun,  8 Mar 2009 14:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599]
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 JpSkzd3CJXLo; Sun,  8 Mar 2009 14:33:41 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 773FE3A6882; Sun,  8 Mar 2009 14:33:41 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n28LY6T4026055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Mar 2009 22:34:06 +0100
Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n28LY5AR003802; Sun, 8 Mar 2009 22:34:05 +0100
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 8 Mar 2009 22:34:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 8 Mar 2009 22:34:04 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
Thread-Index: AcmeenhnQRpQH0GjPUmTSqrAenuIjwBlkcxg
References: <[e-mail]> <[e-mail]>
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>
To: "ext Ben Niven-Jenkins" <[e-mail]>, "Thomas Nadeau" <[e-mail]>, "Loa Andersson" <[e-mail]>
X-OriginalArrivalTime: 08 Mar 2009 21:34:04.0896 (UTC) FILETIME=[9AE1A600:01C9A035]
Cc: George Swallow <[e-mail]>, [e-mail], ITU-T ad hoc team on MPLS-TP <[e-mail]>, [e-mail], [e-mail], [e-mail], David Ward <[e-mail]>, Malcolm Betts <[e-mail]>, VIGOUREUX MARTIN <[e-mail]>
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2009 21:33:42 -0000

Agreed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
ext Ben Niven-Jenkins
Sent: Friday, March 06, 2009 18:42
To: Thomas Nadeau; Loa Andersson
Cc: George Swallow; [e-mail]; ITU-T ad hoc team on MPLS-TP;
[e-mail]; [e-mail]; [e-mail]; David Ward; Malcolm
Betts; VIGOUREUX MARTIN
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without
significant
changes to their existing support infrastructures.

Ben



On 06/03/2009 14:00, "Thomas Nadeau" <[e-mail]> wrote:

>=20
> I think this document is ready to progress forward.
>=20
> --Tom
>=20
>=20
> On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:
>=20
>> All,
>>=20
>> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
>> has been published.
>>=20
>> The draft is found at:
>>=20
>> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>>=20
>> Since the updates are significant this is to initiate a 2 week
>> working group last call on the new version.
>>=20
>> Please send your comments to the [e-mail] mailing list.
>>=20
>> The working group last call will end on March 11.
>>=20
>> /Loa
>> -- =20
>>=20
>>=20
>> Loa Andersson
>>=20
>> Sr Strategy and Standards Manager
>> Ericsson ///                          phone:  [phone]
>>=20
>>                                      email:
>> [e-mail]
>>
[e-mail]
>>                                              [e-mail]
>>=20
>>=20
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>=20
>=20
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3

From [e-mail]  Mon Mar  9 07:47:14 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78353A6C5F for <[e-mail]>; Mon,  9 Mar 2009 07:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6]
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 bNLgwXqmyb02 for <[e-mail]>; Mon,  9 Mar 2009 07:47:14 -0700 (PDT)
Received: from napoleon.monoski.com (black.monoski.com [63.227.123.238]) by core3.amsl.com (Postfix) with ESMTP id BFFD53A6C55 for <[e-mail]>; Mon,  9 Mar 2009 07:47:13 -0700 (PDT)
Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n29Eldo3006635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 08:47:41 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Mon, 09 Mar 2009 08:47:39 -0600
From: Luca Martini <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20081209)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] Time slots for IETF 74 PWE3 meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2009 14:47:14 -0000

Dave,

Sorry , but the agenda has the version number wrong.
the filename is :
draft-martini-pwe3-iccp-01.txt

And it was published February 17th.

Luca


[e-mail] wrote:
> Dave and Luca
>
> I was searching for draft-martini-pwe3-iccp-03 on the ID site but could not find it. Has the updated draft been uploaded to the server?
>
> regards,
> Max
> ---  wrote:
> Hi All,
> So far I have the the following requests for the PWE3 sessioncurrently Monday, March 23, 2009 from 9:00-11:30am:
>
> 10 Min - draft-ietf-pwe3-oam-msg-map-08+ - Peter Busschbach
>
> 10 Min - draft-martini-pwe3-iccp-03 - Luca Martini
>
> 10 Min - draft-ietf-pwe3-segmented-pw-10 - Luca Martini
>
> 10 Min - draft-bryant-pwe3-packet-pw-00 - Stewart Bryant
>
> 10 Min - draft-bryant-filsfils-fat-pw-03 - Stewart Bryant
>
> and a few "place holders".
>
> March 4, 2009 Wednesday - Internet Draft Cut-off for initialdocument (-00) submission by 17:00 PST (01:00 Tuesday, March 5UTC/GMT), upload using IETF ID Submission Tool.
> March 9, 2009 Monday - Internet Draft final submission cut-off by17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool.
>
> Please reply to this email to let me know if you need a slot, or ifyou requested one and I've missed your request.
> Also, please note that slots needed for the joint session on MPLS-TPare being handled by Martin Vigoureux  on the MPLS and MPLS-TPlists.
>
> Thanks!
> Dave
>
>
>
>
>
> On 2/14/09 1:56 PM, "David Sinicrope" <[e-mail]> wrote:
>
> Hi All,
> Please let me know if you would like a time slot for the PWE3meeting during IETF 74.
> I'll need the desired duration, topic, presenter for each request.
> Thanks!
> Dave
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>   


From [e-mail]  Mon Mar  9 08:08:30 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B47B3A6C96 for <[e-mail]>; Mon,  9 Mar 2009 08:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.169
X-Spam-Level: 
X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 pCPdCflw49fR for <[e-mail]>; Mon,  9 Mar 2009 08:08:29 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 69C1828C1D1 for <[e-mail]>; Mon,  9 Mar 2009 08:08:21 -0700 (PDT)
Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n29F8r2s031913 for <[e-mail]>; Mon, 9 Mar 2009 16:08:54 +0100
Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 9 Mar 2009 16:08:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A0C8.F5D41AC7"
Date: Mon, 9 Mar 2009 16:08:53 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Thread-Index: AcmgyPWOuN2jJRCTSJyF9zjH3IElPQ==
From: "BOCCI Matthew" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 09 Mar 2009 15:08:53.0474 (UTC) FILETIME=[F5D04420:01C9A0C8]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2009 15:08:30 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A0C8.F5D41AC7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is the start of working group last call on
draft-ietf-pwe3-vccv-bfd-03.txt

This draft can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt

The last call will close on Monday 6th April 2009.

Please read the document and provide feedback to the PWE3 list.

Many thanks to the following, who have also kindly agreed to review the
draft and provide comments to the list:
Ben Niven-Jenkins
Mustapha Aissaoui
Luca Martini
Yaakov Stein

Best regards

Matthew




------_=_NextPart_001_01C9A0C8.F5D41AC7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>draft-ietf-pwe3-vccv-bfd-03.txt WG last call</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Courier New">This is the start of working =
group last call on draft-ietf-pwe3-vccv-bfd-03.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This draft can be found =
at:</FONT>
</P>

<P><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.t=
xt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt<=
/FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The last call will close on =
Monday 6th April 2009.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Please read the document and =
provide feedback to the PWE3 list.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Many thanks to the following, who =
have also kindly agreed to review the draft and provide comments to the =
list:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Ben Niven-Jenkins</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Mustapha Aissaoui</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Luca Martini</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Yaakov Stein</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Best regards</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Matthew</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C9A0C8.F5D41AC7--

From [e-mail]  Mon Mar  9 14:30:02 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 2A21E3A6CA8; Mon,  9 Mar 2009 14:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  9 Mar 2009 14:30:02 -0700 (PDT)
Cc: [e-mail]
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-dynamic-ms-pw-09.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2009 21:30:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF.

	Title		: Dynamic Placement of Multi Segment Pseudo Wires
	Author(s)	: L. Martini, M. Bocci, N. Bitar, H. Shah, M. Aissaoui, F. Balus
	Filename	: draft-ietf-pwe3-dynamic-ms-pw-09.txt
	Pages		: 20
	Date		: 2009-3-9
	
There is a requirement for service providers to be able to extend the
   reach of pseudo wires (PW) across multiple Packet Switched Network
   domains. A Multi-Segment PW is defined as a set of two or more
   contiguous PW segments that behave and function as a single point-
   to-point PW. This document describes extensions to the PW control
   protocol to dynamically place the segments of the multi segment
   pseudo wire among a set of Provider Edge (PE) routers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pwe3-dynamic-ms-pw-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


From [e-mail]  Tue Mar 10 03:11:18 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214A33A68F9; Tue, 10 Mar 2009 03:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 dnWKWYLBx1UC; Tue, 10 Mar 2009 03:11:17 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 221163A6920; Tue, 10 Mar 2009 03:11:16 -0700 (PDT)
Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2AABDd7018043;  Tue, 10 Mar 2009 11:11:47 +0100
Received: from [172.27.205.200] ([172.27.205.200]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 10 Mar 2009 11:11:34 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Mar 2009 11:11:34 +0100
From: Martin Vigoureux <[e-mail]>
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Mar 2009 10:11:34.0906 (UTC) FILETIME=[979C8DA0:01C9A168]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: George Swallow <[e-mail]>, [e-mail]
Subject: [PWE3] Time slots for IETF74 joint mpls-tp session
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2009 10:11:18 -0000

all,

this is reminder.
If you wish to have a presentation slot during the joint mpls-tp
session, let me know.
This session is planned Wednesday 25th, 09:00-11:30 am.

martin

From [e-mail]  Wed Mar 11 00:09:16 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397C83A67DA; Wed, 11 Mar 2009 00:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.305
X-Spam-Level: 
X-Spam-Status: No, score=-93.305 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, MISSING_HEADERS=1.292, RCVD_DOUBLE_IP_SPAM=3.798, 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 266ZSIpYjbxU; Wed, 11 Mar 2009 00:09:15 -0700 (PDT)
Received: from mail.zte.com.cn (mx1.zte.no [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 3E14B3A692C; Wed, 11 Mar 2009 00:09:10 -0700 (PDT)
Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.13291103364; Wed, 11 Mar 2009 15:32:37 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2B768rd099445; Wed, 11 Mar 2009 15:06:11 +0800 (CST) (envelope-from [e-mail])
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 11 Mar 2009 15:04:23 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-11 15:06:02, Serialize complete at 2009-03-11 15:06:02
Content-Type: multipart/alternative; boundary="=_alternative 0026FD6148257576_="
X-MAIL: mse1.zte.com.cn n2B768rd099445
Cc: [e-mail], ext Ben Niven-Jenkins <[e-mail]>, ITU-T ad hoc team on MPLS-TP <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], David Ward <[e-mail]>, George Swallow <[e-mail]>, Malcolm Betts <[e-mail]>, VIGOUREUX MARTIN <[e-mail]>
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 07:09:16 -0000

This is a multipart message in MIME format.
--=_alternative 0026FD6148257576_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

U3VwcG9ydCENCg0KDQogDQoNCg0KDQoiU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFT
aGFyb24pIiA8bnVyaXQuc3ByZWNoZXJAbnNuLmNvbT4gDQq3orz+yMs6ICBwd2UzLWJvdW5jZXNA
aWV0Zi5vcmcNCjIwMDktMDMtMDkgMDU6MzQNCg0KytW8/sjLDQoiZXh0IEJlbiBOaXZlbi1KZW5r
aW5zIiA8YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20+LCAiVGhvbWFzIE5hZGVhdSIgDQo8
dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+LCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NCrOt
y80NCkdlb3JnZSBTd2FsbG93IDxzd2FsbG93QGNpc2NvLmNvbT4sIG1wbHNAaWV0Zi5vcmcsIElU
VS1UIGFkIGhvYyB0ZWFtIG9uIA0KTVBMUy1UUCA8YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ+LCBt
cGxzLXRwQGlldGYub3JnLCBjY2FtcEBvcHMuaWV0Zi5vcmcsIA0KcHdlM0BpZXRmLm9yZywgRGF2
aWQgV2FyZCA8ZHdhcmRAY2lzY28uY29tPiwgTWFsY29sbSBCZXR0cyANCjxiZXR0czAxQG5vcnRl
bC5jb20+LCBWSUdPVVJFVVggTUFSVElOIA0KPE1hcnRpbi5WaWdvdXJldXhAYWxjYXRlbC1sdWNl
bnQuY29tPg0K1vfM4g0KUmU6IFtQV0UzXSAybmQgd2cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYt
bXBscy10cC1nYWNoLWdhbA0KDQoNCg0KDQoNCg0KQWdyZWVkLg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogcHdlMy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHdlMy1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCmV4dCBCZW4gTml2ZW4tSmVua2lucw0KU2VudDog
RnJpZGF5LCBNYXJjaCAwNiwgMjAwOSAxODo0Mg0KVG86IFRob21hcyBOYWRlYXU7IExvYSBBbmRl
cnNzb24NCkNjOiBHZW9yZ2UgU3dhbGxvdzsgbXBsc0BpZXRmLm9yZzsgSVRVLVQgYWQgaG9jIHRl
YW0gb24gTVBMUy1UUDsNCm1wbHMtdHBAaWV0Zi5vcmc7IGNjYW1wQG9wcy5pZXRmLm9yZzsgcHdl
M0BpZXRmLm9yZzsgRGF2aWQgV2FyZDsgTWFsY29sbQ0KQmV0dHM7IFZJR09VUkVVWCBNQVJUSU4N
ClN1YmplY3Q6IFJlOiBbUFdFM10gMm5kIHdnIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMt
dHAtZ2FjaC1nYWwNCg0KQWdyZWVkLg0KDQpJdCBhZGRyZXNzZXMgYSBuZWVkIGFuZCBwcm92aWRl
cyBhIHNvbHV0aW9uIGZvciBvcGVyYXRvcnMgZXZvbHZpbmcgdG8NCk1QTFMtVFAgZnJvbSB0aGVp
ciBleGlzdGluZyBkZXBsb3llZCBNUExTICYgUFcgc2VydmljZXMgd2l0aG91dA0Kc2lnbmlmaWNh
bnQNCmNoYW5nZXMgdG8gdGhlaXIgZXhpc3Rpbmcgc3VwcG9ydCBpbmZyYXN0cnVjdHVyZXMuDQoN
CkJlbg0KDQoNCg0KT24gMDYvMDMvMjAwOSAxNDowMCwgIlRob21hcyBOYWRlYXUiIDx0bmFkZWF1
QGx1Y2lkdmlzaW9uLmNvbT4gd3JvdGU6DQoNCj4gDQo+IEkgdGhpbmsgdGhpcyBkb2N1bWVudCBp
cyByZWFkeSB0byBwcm9ncmVzcyBmb3J3YXJkLg0KPiANCj4gLS1Ub20NCj4gDQo+IA0KPiBPbiBG
ZWIgMjQsIDIwMDk6MTA6MjUgQU0sIGF0IDEwOjI1IEFNLCBMb2EgQW5kZXJzc29uIHdyb3RlOg0K
PiANCj4+IEFsbCwNCj4+IA0KPj4gYW4gdXBkYXRlZCB2ZXJzaW9uICgtMDIpIG9mIHRoZSBkcmFm
dC1pZXRmLW1wbHMtdHAtZ2FjaC1nYWwNCj4+IGhhcyBiZWVuIHB1Ymxpc2hlZC4NCj4+IA0KPj4g
VGhlIGRyYWZ0IGlzIGZvdW5kIGF0Og0KPj4gDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLW1wbHMtdHAtZ2FjaC1nYWwtMDINCj4+IA0KPj4gU2luY2UgdGhlIHVwZGF0
ZXMgYXJlIHNpZ25pZmljYW50IHRoaXMgaXMgdG8gaW5pdGlhdGUgYSAyIHdlZWsNCj4+IHdvcmtp
bmcgZ3JvdXAgbGFzdCBjYWxsIG9uIHRoZSBuZXcgdmVyc2lvbi4NCj4+IA0KPj4gUGxlYXNlIHNl
bmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBtYWlsaW5nIGxpc3QuDQo+
PiANCj4+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCB3aWxsIGVuZCBvbiBNYXJjaCAxMS4N
Cj4+IA0KPj4gL0xvYQ0KPj4gLS0gDQo+PiANCj4+IA0KPj4gTG9hIEFuZGVyc3Nvbg0KPj4gDQo+
PiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXINCj4+IEVyaWNzc29uIC8vLyAgICAg
ICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICArNDYgOCA2MzIgNzcgMTQNCj4+IA0KPj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4gbG9hLmFuZGVyc3Nv
bkBlcmljc3Nvbi5jb20NCj4+DQpsb2EuYW5kZXJzc29uQHJlZGJhY2suY29tDQo+PiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4+IA0KPj4g
DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g
cHdlMyBtYWlsaW5nIGxpc3QNCj4+IHB3ZTNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0KPj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwd2UzIG1haWxpbmcgbGlzdA0KPiBwd2Uz
QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHdlMyBt
YWlsaW5nIGxpc3QNCnB3ZTNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vcHdlMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCg0KDQo=
--=_alternative 0026FD6148257576_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClN1cHBvcnQhPC9mb250
Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8
L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249
dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1
b3Q7U3ByZWNoZXIsIE51cml0IChOU04NCi0gSUwvSG9kIEhhU2hhcm9uKSZxdW90OyAmbHQ7bnVy
aXQuc3ByZWNoZXJAbnNuLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj
ZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+
DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wMy0wOSAwNTozNDwvZm9u
dD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K
PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8
/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv
dDtleHQgQmVuIE5pdmVuLUplbmtpbnMmcXVvdDsgJmx0O2JlbmphbWluLm5pdmVuLWplbmtpbnNA
YnQuY29tJmd0OywNCiZxdW90O1Rob21hcyBOYWRlYXUmcXVvdDsgJmx0O3RuYWRlYXVAbHVjaWR2
aXNpb24uY29tJmd0OywgJnF1b3Q7TG9hIEFuZGVyc3NvbiZxdW90Ow0KJmx0O2xvYUBwaS5udSZn
dDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg
c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6
ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkdlb3JnZSBTd2FsbG93ICZsdDtzd2FsbG93QGNpc2NvLmNv
bSZndDssDQptcGxzQGlldGYub3JnLCBJVFUtVCBhZCBob2MgdGVhbSBvbiBNUExTLVRQICZsdDth
aG1wbHMtdHBAbGlzdHMuaXR1LmludCZndDssDQptcGxzLXRwQGlldGYub3JnLCBjY2FtcEBvcHMu
aWV0Zi5vcmcsIHB3ZTNAaWV0Zi5vcmcsIERhdmlkIFdhcmQgJmx0O2R3YXJkQGNpc2NvLmNvbSZn
dDssDQpNYWxjb2xtIEJldHRzICZsdDtiZXR0czAxQG5vcnRlbC5jb20mZ3Q7LCBWSUdPVVJFVVgg
TUFSVElOICZsdDtNYXJ0aW4uVmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8L2ZvbnQ+
DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh
Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPlJlOiBbUFdFM10gMm5kIHdnIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1w
bHMtdHAtZ2FjaC1nYWw8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249
dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48
Zm9udCBzaXplPTI+PHR0PkFncmVlZC48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxicj4NCkZyb206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnB3ZTMtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mPGJyPg0KZXh0IEJlbiBOaXZlbi1KZW5raW5zPGJyPg0K
U2VudDogRnJpZGF5LCBNYXJjaCAwNiwgMjAwOSAxODo0Mjxicj4NClRvOiBUaG9tYXMgTmFkZWF1
OyBMb2EgQW5kZXJzc29uPGJyPg0KQ2M6IEdlb3JnZSBTd2FsbG93OyBtcGxzQGlldGYub3JnOyBJ
VFUtVCBhZCBob2MgdGVhbSBvbiBNUExTLVRQOzxicj4NCm1wbHMtdHBAaWV0Zi5vcmc7IGNjYW1w
QG9wcy5pZXRmLm9yZzsgcHdlM0BpZXRmLm9yZzsgRGF2aWQgV2FyZDsgTWFsY29sbTxicj4NCkJl
dHRzOyBWSUdPVVJFVVggTUFSVElOPGJyPg0KU3ViamVjdDogUmU6IFtQV0UzXSAybmQgd2cgbGFz
dCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1nYWNoLWdhbDxicj4NCjxicj4NCkFncmVlZC48
YnI+DQo8YnI+DQpJdCBhZGRyZXNzZXMgYSBuZWVkIGFuZCBwcm92aWRlcyBhIHNvbHV0aW9uIGZv
ciBvcGVyYXRvcnMgZXZvbHZpbmcgdG88YnI+DQpNUExTLVRQIGZyb20gdGhlaXIgZXhpc3Rpbmcg
ZGVwbG95ZWQgTVBMUyAmYW1wOyBQVyBzZXJ2aWNlcyB3aXRob3V0PGJyPg0Kc2lnbmlmaWNhbnQ8
YnI+DQpjaGFuZ2VzIHRvIHRoZWlyIGV4aXN0aW5nIHN1cHBvcnQgaW5mcmFzdHJ1Y3R1cmVzLjxi
cj4NCjxicj4NCkJlbjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDA2LzAzLzIwMDkgMTQ6MDAs
ICZxdW90O1Rob21hcyBOYWRlYXUmcXVvdDsgJmx0O3RuYWRlYXVAbHVjaWR2aXNpb24uY29tJmd0
Ow0Kd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsgdGhpcyBkb2N1bWVu
dCBpcyByZWFkeSB0byBwcm9ncmVzcyBmb3J3YXJkLjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLVRv
bTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIEZlYiAyNCwgMjAwOToxMDoyNSBB
TSwgYXQgMTA6MjUgQU0sIExvYSBBbmRlcnNzb24gd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7
Jmd0OyBBbGwsPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgYW4gdXBkYXRlZCB2ZXJzaW9u
ICgtMDIpIG9mIHRoZSBkcmFmdC1pZXRmLW1wbHMtdHAtZ2FjaC1nYWw8YnI+DQomZ3Q7Jmd0OyBo
YXMgYmVlbiBwdWJsaXNoZWQuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgVGhlIGRyYWZ0
IGlzIGZvdW5kIGF0Ojxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IGh0dHA6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy10cC1nYWNoLWdhbC0wMjxicj4NCiZndDsmZ3Q7
IDxicj4NCiZndDsmZ3Q7IFNpbmNlIHRoZSB1cGRhdGVzIGFyZSBzaWduaWZpY2FudCB0aGlzIGlz
IHRvIGluaXRpYXRlIGEgMiB3ZWVrPGJyPg0KJmd0OyZndDsgd29ya2luZyBncm91cCBsYXN0IGNh
bGwgb24gdGhlIG5ldyB2ZXJzaW9uLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFBsZWFz
ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMtdHBAaWV0Zi5vcmcgbWFpbGluZyBsaXN0
Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs
bCB3aWxsIGVuZCBvbiBNYXJjaCAxMS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAvTG9h
PGJyPg0KJmd0OyZndDsgLS0gJm5ic3A7PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJy
Pg0KJmd0OyZndDsgTG9hIEFuZGVyc3Nvbjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFNy
IFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlcjxicj4NCiZndDsmZ3Q7IEVyaWNzc29uIC8v
LyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICZuYnNwOys0NiA4IDYz
MiA3NyAxNDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtl
bWFpbDo8YnI+DQomZ3Q7Jmd0OyBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTxicj4NCiZndDsm
Z3Q7PGJyPg0KbG9hLmFuZGVyc3NvbkByZWRiYWNrLmNvbTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO2xvYUBwaS5udTxicj4NCiZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgcHdlMyBtYWlsaW5nIGxp
c3Q8YnI+DQomZ3Q7Jmd0OyBwd2UzQGlldGYub3JnPGJyPg0KJmd0OyZndDsgaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KJmd0OyBwd2UzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgcHdlM0BpZXRmLm9yZzxicj4N
CiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPGJyPg0KPGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpw
d2UzIG1haWxpbmcgbGlzdDxicj4NCnB3ZTNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdlM0Bp
ZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMzxi
cj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K
--=_alternative 0026FD6148257576_=--

From [e-mail]  Wed Mar 11 02:54:42 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B633A6B51; Wed, 11 Mar 2009 02:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 Djp-Gq7CYQNG; Wed, 11 Mar 2009 02:54:41 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 275733A67FF; Wed, 11 Mar 2009 02:54:41 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B18522089; Wed, 11 Mar 2009 10:55:01 +0100 (CET)
X-AuditID: c1b4fb3e-ae89fbb0000023da-d7-49b78a752317
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16BAD2068F; Wed, 11 Mar 2009 10:55:01 +0100 (CET)
Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 11 Mar 2009 10:55:00 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Mar 2009 10:54:59 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PWE3] poll on making draft-sprecher-mpls-tp-survive-fwk-01.txt a working group document?
thread-index: AcmYP+LnuABJVhzlRteUHABTX5NssAJ73i8Q
References: <[e-mail]>
From: "Annamaria Fulignoli" <[e-mail]>
To: "Loa Andersson" <[e-mail]>, <[e-mail]>, <[e-mail]>, "ITU-T ad hoc team on MPLS-TP" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2009 09:55:00.0768 (UTC) FILETIME=[7178E200:01C9A22F]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [PWE3] poll on making draft-sprecher-mpls-tp-survive-fwk-01.txt a working group document?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 09:54:42 -0000

I support.

BR,
Annamaria=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of =
Loa Andersson
Sent: gioved=EC 26 febbraio 2009 19.26
To: [e-mail]; [e-mail]; ITU-T ad hoc team on MPLS-TP; =
[e-mail]; [e-mail]
Subject: [PWE3] poll on making draft-sprecher-mpls-tp-survive-fwk-01.txt =
a working group document?

All,

we have received a request from the editors/authors of =
draft-sprecher-mpls-tp-survive-fwk-01.txt to make the document an mpls =
working group document.

Please send your comments to the mpls-tp mailing list.

This poll ends eob Thu Mar 12, 2009.

/Loa

--=20


Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  [phone]

                                       email:  =
[e-mail]
                                               [e-mail]
                                               [e-mail]


_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3

From [e-mail]  Wed Mar 11 07:46:21 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8755B3A6818 for <[e-mail]>; Wed, 11 Mar 2009 07:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.996
X-Spam-Level: 
X-Spam-Status: No, score=-94.996 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, PLING_QUERY=1.39, RCVD_DOUBLE_IP_SPAM=3.798, 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 f8dBQUeDAiyJ for <[e-mail]>; Wed, 11 Mar 2009 07:46:20 -0700 (PDT)
Received: from mail.zte.com.cn (mail.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id B0A823A68E6 for <[e-mail]>; Wed, 11 Mar 2009 07:46:19 -0700 (PDT)
Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.1397396305; Wed, 11 Mar 2009 23:09:28 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2BEk9u9067377 for <[e-mail]>; Wed, 11 Mar 2009 22:46:09 +0800 (CST) (envelope-from [e-mail])
In-Reply-To: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <[e-mail]>
From: [e-mail]
Date: Wed, 11 Mar 2009 22:45:39 +0800
X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-11 22:45:45, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-11 22:45:45, Serialize complete at 2009-03-11 22:45:45, S/MIME Sign failed at 2009-03-11 22:45:45: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-11 22:45:52, Serialize complete at 2009-03-11 22:45:52
Content-Type: multipart/alternative; boundary="=_alternative 0051180548257576_="
X-MAIL: mse1.zte.com.cn n2BEk9u9067377
Subject: [PWE3] Help: Can anybody provide some decs on the concept of "MPLS PW" which is in the milestone of PWE3 WG? Thank you!
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 14:46:21 -0000

This is a multipart message in MIME format.
--=_alternative 0051180548257576_=
Content-Type: text/plain; charset="US-ASCII"

Mar 2009
  
Generic Associated Channel Header LC 
Apr 2009
  
MPLS PW LC 
Jul 2009
  
PW Protection and Restoration LC 


--=_alternative 0051180548257576_=
Content-Type: text/html; charset="US-ASCII"


<table width=100%>
<tr valign=top>
<td width=18%><font size=3>Mar 2009</font>
<td width=4%><font size=3>&nbsp;&nbsp;</font>
<td width=76%><font size=3>Generic Associated Channel Header LC </font>
<tr valign=top>
<td><font size=3><b>Apr 2009</b></font>
<td><font size=3><b>&nbsp;&nbsp;</b></font>
<td><font size=3><b>MPLS PW LC </b></font>
<tr valign=top>
<td><font size=3>Jul 2009</font>
<td><font size=3>&nbsp;&nbsp;</font>
<td><font size=3>PW Protection and Restoration LC </font></table>
<br><font size=2 face="sans-serif"><br>
</font>
--=_alternative 0051180548257576_=--

From prvs=31439892d=[e-mail]  Wed Mar 11 09:04:43 2009
Return-Path: <prvs=31439892d=[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02323A6BAB for <[e-mail]>; Wed, 11 Mar 2009 09:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.163
X-Spam-Level: 
X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.435,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 JH42+2tgvSk6 for <[e-mail]>; Wed, 11 Mar 2009 09:04:35 -0700 (PDT)
Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 31CEB3A6BDD for <[e-mail]>; Wed, 11 Mar 2009 09:04:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,343,1233561600"; d="scan'208,217";a="253019"
Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 11 Mar 2009 09:05:11 -0700
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AD03F5D99E8 for <[e-mail]>; Wed, 11 Mar 2009 09:05:11 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10105-01 for <[e-mail]>; Wed, 11 Mar 2009 09:05:11 -0700 (PDT)
Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 8A8555D99E7 for <[e-mail]>; Wed, 11 Mar 2009 09:05:11 -0700 (PDT)
Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Wed, 11 Mar 2009 09:05:11 -0700
From: David Sinicrope <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Wed, 11 Mar 2009 09:05:09 -0700
Thread-Topic: [PWE3] Time slots for IETF 74 PWE3 meeting
Thread-Index: AcmO1f4o4AcNXYD1F0eyztRRXFz+YAL0CTg/Ae9A5QI=
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C5DD597516DA2euddasiredbackcom_"
MIME-Version: 1.0
Subject: Re: [PWE3] Time slots for IETF 74 PWE3 meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 16:06:31 -0000

--_000_C5DD597516DA2euddasiredbackcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The initial agenda is available at:
http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html
Please let me know if there are any questions or concerns,
Dave

On 3/1/09 2:44 PM, "David Sinicrope" <[e-mail]> wrote:

Hi All,
So far I have the the following requests for the PWE3 session currently Mon=
day, March 23, 2009 from 9:00-11:30am:

10 Min - draft-ietf-pwe3-oam-msg-map-08+ - Peter Busschbach

10 Min - draft-martini-pwe3-iccp-03 - Luca Martini

10 Min - draft-ietf-pwe3-segmented-pw-10 - Luca Martini

10 Min - draft-bryant-pwe3-packet-pw-00 - Stewart Bryant

10 Min - draft-bryant-filsfils-fat-pw-03 - Stewart Bryant

and a few "place holders".

March 4, 2009 Wednesday - Internet Draft Cut-off for initial document (-00)=
 submission by 17:00 PST (01:00 Tuesday, March 5 UTC/GMT), upload using IET=
F ID Submission Tool.
March 9, 2009 Monday - Internet Draft final submission cut-off by 17:00 PDT=
 (24:00 UTC/GMT), upload using IETF ID Submission Tool.

Please reply to this email to let me know if you need a slot, or if you req=
uested one and I've missed your request.
Also, please note that slots needed for the joint session on MPLS-TP are be=
ing handled by Martin Vigoureux  on the MPLS and MPLS-TP lists.

Thanks!
Dave





On 2/14/09 1:56 PM, "David Sinicrope" <[e-mail]> wrote:

Hi All,
Please let me know if you would like a time slot for the PWE3 meeting durin=
g IETF 74.
I'll need the desired duration, topic, presenter for each request.
Thanks!
Dave


--_000_C5DD597516DA2euddasiredbackcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [PWE3] Time slots for IETF 74 PWE3 meeting</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>The initial agenda is available at:<BR>
<a href=3D"http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html">http:=
//tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html</a><BR>
Please let me know if there are any questions or concerns,<BR>
Dave<BR>
<BR>
On 3/1/09 2:44 PM, &quot;David Sinicrope&quot; &lt;<a href=3D"euddasi@redba=
ck.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>Hi All,<BR>
So far I have the the following requests for the PWE3 session currently Mon=
day, March 23, 2009 from 9:00-11:30am:<BR>
<BR>
10 Min - draft-ietf-pwe3-oam-msg-map-08+ - Peter Busschbach <BR>
<BR>
10 Min - draft-martini-pwe3-iccp-03 &#8211; Luca Martini <BR>
<BR>
10 Min - draft-ietf-pwe3-segmented-pw-10 &#8211; Luca Martini <BR>
<BR>
10 Min - draft-bryant-pwe3-packet-pw-00 &#8211; Stewart Bryant<BR>
<BR>
10 Min - draft-bryant-filsfils-fat-pw-03 &#8211; Stewart Bryant<BR>
<BR>
and a few &#8220;place holders&#8221;. &nbsp;<BR>
<BR>
March 4, 2009 Wednesday - Internet Draft Cut-off for initial document (-00)=
 submission by 17:00 PST (01:00 Tuesday, March 5 UTC/GMT), upload using <FO=
NT COLOR=3D"#1900FF"><U>IETF ID Submission Tool</U></FONT>.<BR>
March 9, 2009 Monday - Internet Draft final submission cut-off by 17:00 PDT=
 (24:00 UTC/GMT), upload using <FONT COLOR=3D"#1900FF"><U>IETF ID Submissio=
n Tool</U></FONT>.<BR>
<BR>
Please reply to this email to let me know if you need a slot, or if you req=
uested one and I&#8217;ve missed your request.<BR>
Also, please note that slots needed for the joint session on MPLS-TP are be=
ing handled by Martin Vigoureux &nbsp;on the MPLS and MPLS-TP lists.<BR>
<BR>
Thanks!<BR>
Dave<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
On 2/14/09 1:56 PM, &quot;David Sinicrope&quot; &lt;<a href=3D"euddasi@redb=
ack.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>Hi All,<BR>
Please let me know if you would like a time slot for the PWE3 meeting durin=
g IETF 74.<BR>
I&#8217;ll need the desired duration, topic, presenter for each request.<BR=
>
Thanks!<BR>
Dave <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C5DD597516DA2euddasiredbackcom_--

From [e-mail]  Wed Mar 11 14:39:50 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E77228C1ED; Wed, 11 Mar 2009 14:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 guufcl8gkjlF; Wed, 11 Mar 2009 14:39:49 -0700 (PDT)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id EC23728C1D6; Wed, 11 Mar 2009 14:39:48 -0700 (PDT)
Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 11 Mar 2009 22:40:23 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 11 Mar 2009 22:40:22 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Mar 2009 22:40:08 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
thread-index: AcmWn8LCquJBWDfvR6uP4Wi1oXnINwL8aFQw
References: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2009 21:40:22.0737 (UTC) FILETIME=[FB54DC10:01C9A291]
Subject: Re: [PWE3] [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 21:39:50 -0000

Support.=20

-----Urspr=FCngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im =
Auftrag von Loa Andersson
Gesendet: Dienstag, 24. Februar 2009 11:25
An: [e-mail]; [e-mail]; [e-mail]; [e-mail]; =
ITU-T ad hoc team on MPLS-TP; George Swallow; Ross Callon; David Ward; =
Malcolm Betts; VIGOUREUX MARTIN
Betreff: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

All,

an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
has been published.

The draft is found at:

http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02

Since the updates are significant this is to initiate a 2 week
working group last call on the new version.

Please send your comments to the [e-mail] mailing list.

The working group last call will end on March 11.

/Loa
--=20


Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  [phone]

                                       email:  =
[e-mail]
                                               [e-mail]
                                               [e-mail]


_______________________________________________
mpls-tp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-tp

From [e-mail]  Thu Mar 12 07:17:57 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7743A6956 for <[e-mail]>; Thu, 12 Mar 2009 07:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.023
X-Spam-Level: 
X-Spam-Status: No, score=-8.023 tagged_above=-999 required=5 tests=[AWL=-1.424, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 XeoJVbh68sxy for <[e-mail]>; Thu, 12 Mar 2009 07:17:54 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3C1B13A679C for <[e-mail]>; Thu, 12 Mar 2009 07:17:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,350,1233532800"; d="scan'208";a="154760374"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 12 Mar 2009 14:18:30 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2CEIUAJ018111;  Thu, 12 Mar 2009 15:18:30 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2CEIT1U004610; Thu, 12 Mar 2009 14:18:30 GMT
Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2CEISF19641; Thu, 12 Mar 2009 14:18:28 GMT
Message-ID: <[e-mail]>
Date: Thu, 12 Mar 2009 14:18:28 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail], pwe3 <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=34380; t=1236867510; x=1237731510; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Comments=20on=20draft-ietf-pwe3-segmented-pw-11 .txt |Sender:=20; bh=NTpXdiBf5QoqeRmhMRWioSTAQFAa8QGKhIlrcrXmfWU=; b=SU7laAsH7ihKXOLJDjpiitXJWkWXRB54LLFpLv9dLHK7FB93PKT+oAoXvg Zm9vCNMHWf0Jd8PojXGVsmqiRO07l1bBCz/pexiHYJQcGozWYDp48WkNTfxs 5pdxkVLh5M;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Subject: [PWE3] Comments on draft-ietf-pwe3-segmented-pw-11.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 14:17:57 -0000

I have done a line by line review of
draft-ietf-pwe3-segmented-pw-11.txt and have a
number of comments. The overwhelming majority
of these are editorial but there are a few
technical questions most of which are
clarification issues.


I think that we need to proceed a follows:

Please will the authors need to take a look
at my comments and address the text as necessary.

Then I think that we need to do three things

1) Ask MPLS WG if they are happy with the
LDP material.

2) Ask L2TPext WG if they are happy with the
L2TP text.

3) A couple of other members if PWE3 WG need
to volunteer to read the next version in case
there is anything else that has been missed.

- Stewart

=======================================================


                          Segmented Pseudowire


                  draft-ietf-pwe3-segmented-pw-11.txt


Abstract

   This document describes how to connect pseudowires (PW) between two
   distinct PW control planes or PSN domains. The PW control planes may
   belong to independent autonomous systems, or the PSN technology is
SB> technolgy may be hetrogeneous
   heterogeneous, or a PW might need to be aggregated at a specific PSN
   point. The PW packet data units are simply switched from one PW to
   another without changing the PW payload.
SB> That is true for MPLS but MPLS <> L2TPv3 involves a little
SB> more - for example the frame relay formats are different.




2. Terminology

SB> This needs a reference to draft-ietf-pwe3-ms-pw-arch-06.txt
SB> I wonder if we need it here at all since we are going to
SB> have to make sure it survives the various editing rounds
SB> to pub remaining word for word identical to the above
SB> draft.

     - PW Terminating Provider Edge (T-PE). A PE where the customer-
       facing attachment circuits (ACs) are bound to a PW forwarder. A
       Terminating PE is present in the first and last segments of a
       MS-PW. This incorporates the functionality of a PE as defined in
       [RFC3985].

     - Single-Segment Pseudowire (SS-PW). A PW setup directly between
       two T-PE devices. Each PW in one direction of a SS-PW traverses
       one PSN tunnel that connects the two T-PEs.

     - Multi-Segment Pseudowire (MS-PW).  A static or dynamically
       configured set of two or more contiguous PW segments that behave
       and function as a single point-to-point PW. Each end of a MS-PW
       by definition MUST terminate on a T-PE.

SB> ... and to prove my point PW Segment, & S-PE have different
SB> definitions and PW Switching is not defined here but is defined
SB> in ms-pw-arch

     - PW Segment. A part of a single-segment or multi-segment PW, which
       is set up between two PE devices, T-PEs and/or S-PEs.

     - Pw Switching Provider Edge (S-PE).  A PE capable of switching the
       control and data planes of the preceding and succeeding PW
       segments in a MS-PW. The S-PE terminates the PSN tunnels of the
       preceding and succeeding segments of the MS-PW.


3. Introduction

   PWE3 defines the signaling and encapsulation techniques for
SB> Do you mean PWE3 here?
SB> Maybe you need to say PWE3 previously defined..., or
SB> maybe you should callup ms-pw requirements as a way of intro
   establishing SS-PWs between a pair of terminating PEs and in the vast
   majority of cases this will be sufficient. MS-PWs come into play in
   two general cases:

SB>RFC editor will definately change "come into play"

        -i. When it is not possible, desirable or feasible to establish
            a PW control channel between the ultimate source and
            destination PEs. At a minimum PW control channel
            establishment requires knowledge of and reachability to the
            remote (ultimate) PE IP address. The local (ultimate) PE may
SB> For consistency we should use the term T-PE (this applies
SB> in multiple places
            not have access to this information related to topology,
            operational or security constraints.

            An example is the inter-AS L2VPN scenario where the ultimate
            PEs reside in different provider networks (ASes) and it is
            the practice to MD5-key all control traffic exchanged
SB> Is MD5 ok with SEC AD? Is the correct verb "MD5-key"?
SB> Maybe you should just use the term "cryptogtaphiclly sign"
SB> effects rest of para.
            between two networks. Technically a SS-PW could be used but
            this would require MD5-keying on ALL ultimate source and
            destination PE nodes. An MS-PW allows the providers to
            confine MD5 key administration to just the PW switching
            points connecting the two domains.

<snip>

       -ii. PWE3 signaling and encapsulation protocols are different.
            The ultimate PEs are connected to networks employing
SB> Again use of undefined term ultimate
            different PW signaling and encapsulation protocols. In this
            case it is not possible to use a SS-PW. A MS-PW with the
            appropriate interworking performed at the PW switching
            points can enable PW connectivity between the ultimate PEs
            in this scenario.
<snip>


4. General Description

   A pseudowire (PW) is a tunnel established between two provider edge
   (PE) nodes to transport L2 PDUs across a packet switched network
SB> Isn't it to interconnect attachement circuits.
SB> We also support TDM which is not L2 PDU
   (PSN) as described in Figure 1 and in [RFC3985]. Many providers have
   deployed PWs as a means of migrating existing (or building new) L2VPN
   services (e.g.. Frame Relay, ATM, or Ethernet) on to a PSN.

<snip>
SB> There is a lot of overlap in this descriptive material with ms-pw arch
SB> I wonder how much of this overlap is useful?

<snip>
SB> There is something wrong with this next para. Did you snip
SB> out some preceeding text - it starts very abruptly and
SB> then strangely changes direction in the middle.
SB> I think that you need to take a look at rewording it.
SB> You might want to break it up into small bits.

   In general the approach taken is to connect the individual control
   planes by passing along any signaling information immediately upon
   reception. First the S-PE is configured to switch a SS-PW from a
   specific peer to another SS-PW destined for a different peer. No
   control messages are exchanged yet as the S-PE PE does not have
   enough information to actually initiate the PW setup messages.
   However, if a session does not already exist, a control protocol
   (LDP/L2TP) session MAY be setup. In this model the MS-PW setup is
   starting from the T-PE devices. Next once the T-PE is configured it
   sends the PW control setup messages. These messages are received, and
   immediately used to form the PW setup messages for the next SS-PW of
   the MS-PW. If one of the Switching PEs doesn't accept an LDP Label
   Mapping message then a Label Release message may be sent back to the
   originator T-PE depending on the cause of the error. LDP liberal
   label retention mode still applies, hence if a PE is simply not
   configured yet , the label mapping is stored for future use. A MS-PW
   is declared UP when all the constituent SS-PWs are UP.



5. PW Switching and Attachment Circuit Type

   The PWs in each PSN are established independently, with each PSN
   being treated as a separate PWE3 domain. For example, in Figure 2 for
SB> Again do you mean PWE3 domain or PW domain or some other sort of domain?
SB> missed out the word "the"
   case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP
   targeted session as described in [RFC4447], and at the same time a
   separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for
   PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the
   same PW type e.g. ATM VCC, Ethernet VLAN, etc.


6. Applicability

   The general applicability of MS-PWs and their relationship to L2VPNs
   is described in [MS-PW-ARCH]. The applicability of a PW type, as
   specified in the relevant RFC for that encapsulation (e.g. [RFC4717]
   for ATM), applies to each segment. This section describes further
   applicability considerations.

   In comon with SS-PWs, the performance of any segment of a MS-PW is
   equal to the performance of the PSN plus any impairments Introduced
SB> performance of the PSN less any impairments?
   by the PW layer itself. Therefore it is not possible for the MS-PW to
   provide better performance than the PSN over which it is transported.
   Furthermore, the overall performance of an MS-PW is no better than
   the worst performing segment of that MS-PW.

<snip>

7. MPLS-PW to MPLS-PW Control Plane Switching

   Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted
SB> set up PW1 (delete "a")
SB> In Fig 3 you use the term "PW Segment 1"
SB> There is no PE2 in Fig 3
   session as described in [RFC4447], at the same time a separate
   pseudowire PW3 is setup to PE3. Each PW is configured independently
   on the PEs, but on PE2 pseudowire PW1 is connected to pseudowire PW3.
   PDUs are then switched between the pseudowires at the PW label level.
   Hence the data plane does not need any special knowledge of the
   specific pseudowire type. A simple standard MPLS label swap operation
   is sufficient to connect the two PWs, and in this case the PW
   adaptation function is not used. However when pushing a new PSN label
   the TTL SHOULD be set to 255, or some other locally configured fixed
   value.
SB> The label text above is a bit clumsy you pull a number out of the
SB> hat. Do you need to call up the pipe model? Comment of QoS?

   This process can be repeated as many times as necessary, the only
   limitation to the number of S-PEs traversed is imposed by the TTL
   field of the PW MPLS Label. The setting of the TTL is a matter of
SB> PW TTL?
   local policy on the originating PE, but SHOULD be set to 255.
SB> Again do you need to say why 255?

SB> You are in control plane but then swap to TTL for
SB> a bit surely that should be in data plane?
SB> You make the raeder jump around in this section.

 <snip>

7.1. Static Control plane switching
SB> It might be helpful to the reader to call out
SB> the case numbers from the list above.

   In the case of two static control planes the S-PE MUST be configured
   to direct the MPLS packets from one PW into the other. There is no
   control protocol involved in this case. When one of the control
   planes is a simple static PW configuration and the other control
   plane is a dynamic LDP FEC 128 or generalized PW FEC, then the static
   control plane should be considered identical to an attachment circuit
   (AC) in the reference model of Figure 1. The switching point PE
   SHOULD signal the proper PW status if it detects a failure in sending
SB> What do you mean by proper?
   or receiving packets over the static PW segment.  Because the PW is
   statically configured, the status communicated to the dynamic LDP PW
   will be limited to local interface failures. In this case, the S-PE
   PE behaves in a very similar manner to a T-PE, assuming an active
   role.
SB> What do you mean by "assuming an active role"
   This means that the S-PE will immediately send the LDP Label
   Mapping message if the static PW is deemed to be UP.


7.2. Two LDP control planes using the same FEC type

   As stated in a section above, the S-PE PE should assume an initial
SB> Which section above?
SB> Not sure "once" is the right word in the para below
   passive role. This means that once independent PWs are configured on
   the switching point, the LSR does not advertise the LDP PW FEC
   mapping until it has received at least one of the two PW LDP FECs
   from a remote PE. This is necessary because the switching point LSR
   does not know a priori what the interface parameter field in the
   initial FEC advertisement will contain.

SB> PWID comes out of another hat - you need to point to a definition
SB> The next para is perhaps a little too cryptic
   The PWID is a unique number between each pair of PEs. Hence Each SS-
   PW that forms an MS-PW may have a different PWID. In the case of The
   Generalized PW FEC, the AGI/SAI/TAI may have to also be different for
   some, or sometimes all, SS-PWs.


7.2.1. FEC 129 Active/Passive T-PE Election Procedure

   When a MS-PW is signaled using FEC 129, each T-PE might independently
   start signaling the MS-PW. If the MS-PW path is not statically
   configured, in certain cases the signaling procedure could result in
   an attempt to setup each direction of the MS-PW through different
   paths.
SB> Maybe you need to clarify that you mean different S-PEs. You
SB> do not care about the PSN paths.

   To avoid this situation one of the T-PE MUST start the PW
   signaling (active role), while the other waits to receive the LDP
   label mapping before sending the respective PW LDP label mapping
   message. (passive role). When the MS-PW path not statically
   configured, the Active T-PE (the ST-PE) and the passive T-PE (the
   TT-PE) MUST be identified before signaling is initiated for a given
   MS-PW.

   The determination of which T-PE assume the active role SHOULD be done
   as follows:

   The SAII and TAII are compared as unsigned integers, if the SAII is
   bigger then the T-PE assumes the active role.
SB> Do you mean that the T-PE with the larger xAII assumes the
SB> active roll? It took a couple of parses to get that.

   The selection process to determine which T-PE assumes the active role
   MAY be superseded by manual provisioning.

SB> If the T-PE with the smaller xAII is configured to be active
SB> how does the other T-PE know?


7.3. LDP FEC 128 to LDP using the generalized FEC 129

   When a PE is using the generalized FEC 129, there are two distinct
   roles that a PE can assume: active and passive. A PE that assumes the
   active role will send the LDP PW setup message, while a passive role
   PE will simply reply to an incoming LDP PW setup message. The S-PE
   PE, will always remain passive until a PWID FEC 128 LDP message is
   received, which will cause the corresponding generalized PW FEC LDP
   message to be formed and sent. If a generalized FEC PW LDP message is
   received while the switching point PE is in a passive role, the
   corresponding PW FEC 128 LDP message will be formed and sent.

SB> It seems like the text about active passive should preceed
SB> the previous section as it seems less abrupt in nature.
SB>

   PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice
   versa.  This can be accomplished by local S-PE configuration, or by
   some other means, such as some form of auto discovery. Such other
   means are outside the scope of this document.


7.4. LDP S-PE TLV

   The edge to edge PW might traverse several switching points, in
   separate administrative domains. For management and troubleshooting
   reasons it is useful to record information about the switching points
   that the PW traverses. This is accomplished by using a S-PE TLV.

   Note that sending the S-PE TLV is OPTIONAL, however the PE or S-PE
   MUST process the TLV upon reception. The S-PE TLV is appended to the
   PW FEC at each switching point. Each S-PE can append a PW switching
   point TLV, and the order of the S-PE TLVs MUST be preserved. The S-PE
   TLV MUST be sent if VCCV operation is required beyond the first MS-PW
   segment from a T-PE.

   The S-PE TLV is encoded as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW sw TLV  (0x096D)   |     PW sw TLV  Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Variable Length Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Variable Length Value                   |
   |                               "                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SB> To be kind to people reading this in Emacs - it would be good
SB> to put in another " in the line above

   [note] LDP TLV type is pending IANA approval.
SB> Has this TLV request been approved by MPLS WG yet?

<snip>
   The PW switching Point TLV is an OPTIONAL TLV that should appear only
SB> First you should have given the TLV name when you introduced
SB> the term above.
SB> Second this repeats what you just said in para 2 of this
SB> section
   once for each switching point traversed. If the S-PE TLV is not
   present with the required sub-TLVs, VCCV operation will not function.

   For local policy reasons, a particular S-PE can filter out all S-PE
   TLVs in a label mapping message that traverses it and not include
   it's own S-PE TLV.  In this case, from any upstream PE, it will
   appear as if this particular S-PE is the T-PE. This might be
   necessary , depending on local policy if the S-PE is at the Service
   provider administrative boundary.

SB> Do you need to comment on the VCCV implications?


7.4.1. PW Switching Point Sub-TLVs
SB> The next sentence does not read right
SB> Then it all gets very abrupt in the description that follows
SB> I am not sure how many readers will figure it out

   Below are details specific to PW Switching Point Sub-TLVs described
   in this document:

     - PW ID of last PW segment traversed. This is only applicable if
       the last PW segment traversed used LDP FEC 128 to signal the PW.

       This sub-TLV type contains a PW ID in the format of the PWID
       described in [RFC4447]. This is just a 32 bit unsigned integer
       number.

     - PW Switching Point description string.

       An optional description string of text up to 80 characters long.

     - Local IP address of PW Switching Point.

       The Local IP V4 or V6 address of the PW Switching Point. This is
       an OPTIONAL Sub-TLV. In most cases this will be the local LDP
       session IP address of the S-PE.

     - Remote IP address of the last PW Switching Point traversed or of
       the T-PE

       The IP V4 or V6 address of the last PW Switching Point traversed
       or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases this
       will be the remote IP address of the LDP session. This Sub-TLV
       SHOULD only be included if there are no other S-PE TLV present
       from other S-PEs, or if the remote ip address of the LDP session
       does not correspond to the "Local IP address of PW Switching
       Point" TLV value contained in the last S-PE TLV.

     - The FEC of last PW segment traversed.

       This is only applicable if the last PW segment traversed used LDP
       FEC 129 to signal the PW.

       The Attachment Identifier of the last PW segment traversed. This
       is encoded in the following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AGI Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                    AGI  Value (contd.)                        ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AII Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                   SAII  Value (contd.)                        ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AII Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                   TAII Value (contd.)                         ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - L2 PW address of PW Switching Point (recommended format).

   This sub-TLV type contains a L2 PW address of PW Switching Point in
   the format described in [RFC5003]. This includes the AII type field ,
   and length, as well as the L2 PW address.


<snip>


7.6. PW Loop Detection

   A switching point PE SHOULD check the OPTIONAL PW switching Point
   TLV, to verify if it's own IP address appears in it. If it's IP
SB> Hopefully to determine or to check and not to verify?
SB> Or maybe to verify that it is not in it?
 
  address appears in a received PW switching Point TLV, the PE SHOULD
   break the loop, and send a label release message with the following

<snip>

8.2. Static MPLS PW and Dynamic L2TPv3 PW

   When a statically configured MPLS PW is switched to a dynamic L2TPv3
   PW, the static control plane should be considered identical to an
   attachment circuit (AC) in the reference model of Figure 1. The
   switching point PE SHOULD signal the proper PW status if it detects a
SB> Again proper?
SB> Same again in section 8.3
   failure in sending or receiving packets over the static PW. Because
   the PW is statically configured, the status communicated to the
   dynamic L2TPv3 PW will be limited to local interface failures. In
   this case, the S-PE PE behaves in a very similar manner to a T-PE,
   assuming an active role.

<snip>

SB> In case I miss it - what happens about active/passive
SB> negotiation in mixed L2TPv3/MPLS dynamic?


<snip>


8.4.3. Session Tear Down

   L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN
   message translates to a Label Withdraw message in LDP. Following are
   two example exchanges of messages between LDP and L2TPv3. The first
   is a case where an L2TPv3 T-PE initiates the termination of an MS-PW,
   the second is a case where an MPLS T-PE initiates the termination of
   an MS-PW.

   PE 1 (L2TPv3)      PW Switching Node       PE3 (MPLS/LDP)

   AC "Down"
     L2TPv3 CDN --->
                      LDP Label Withdraw  --->
                                                 AC "Down"
                                      <-- LDP Label Release

   <--------------- MH PW Data Path Down ------------------>

SB> Is there no ack back in L2TP to say that the CDN has
SB> been actioned?

<snip>


   Other interface parameter mappings will either be defined in a future
   version of this document,

SB> Is "future version...." correct IETF speak when we are about
SB> to go to RFC?


8.7. L2TPv3 and MPLS PW Data Plane

   When switching between an MPLS and L2TP PW, packets are sent in their
   entirety from one PW to the other, replacing the MPLS label stack
   with the L2TPv3 and IP header or vice versa. There are some
   situations where an additional amount of interworking must be
   provided between the two data planes at the PW switching node.

SB> You might want to note that these are described in the
SB> following sections. Note that 8.7.1 really should be part
SB> of the intro (8.7) which would fix that problem.

8.7.1. PWE3 Payload Convergence and Sequencing

   Section 5.4 of [RFC3985] discusses the purpose of the various shim
   headers necessary for enabling a pseudowire over an IP or MPLS PSN.
   For L2TPv3, the Payload Convergence and Sequencing function is
   carried out via the Default L2-Specific Sublayer defined in [L2TPv3].
   For MPLS, these two functions (together with PSN Convergence) are
   carried out via the MPLS Control Word. Since these functions are
   different between MPLS and L2TPv3, interworking between the two may
   be necessary.

   The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers
   which in some cases are not necessary to be present at all. For
   example, an Ethernet PW with sequencing disabled will generally not
   require an MPLS Control Word or L2TP Default L2-Specific Sublayer to
   be present at all. In this case, Ethernet frames are simply sent from
   one PW to the other without any modification beyond the MPLS and
   L2TP/IP encapsulation and decapsulation.

   The following section offers guidelines for how to interwork between
   L2TP and MPLS for those cases where the Payload Convergence,
   Sequencing, or PSN Convergence functions are necessary on one or both
   sides of the switching node.


8.7.2. Mapping

   The MPLS Control Word consists of (from left to right):
SB> Without a picture you can't say left to right, and even
SB> with one you mean from low order bits to high order bits.
SB> However it might be better to quote bit numbers in
SB> the text below.
SB> Maybe you need both headers in the draft to make it clear?

        -i. These bits are always zero in MPLS are not necessary to be
            mapped to L2TP.

<snip>


9.3. Signaling OAM Capabilities for Switched Pseudowires

   Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV
SB> As in?

<snip>


9.5.1. VCCV Echo Message Processing

   For example, in Figure 3, T-PE1 has the FEC128 of the segment, PW1,
   but it does not readily have the information required to compose the
   FEC128 of the following segment, PW3, if a VCCV echo request to be
   sent to T-PE2. This can be achieved by the methods described in the
   following subsections.

SB> the naming here sort of matches fig 3, but not quite.

<snip>


9.5.2.5. MS-PW Path Trace

SB> This looks the same as MS-PW Path Verification
SB> What is the difference?

<snip>

10. Mapping Switched Pseudowire Status

   In the PW switching with attachment circuits case (Figure 2), PW
   status messages indicating PW or attachment circuit faults MUST be
   mapped to fault indications or OAM messages on the connecting AC as
   defined in [PW-MSG-MAP].

   In the PW control plane switching case (Figure 3), there is no
   attachment circuit at the S-PE, but the two PWs are connected
   together.  Similarly, the status of the PWs are forwarded unchanged
   from one PW to the other by the control plane switching function.
   However, it may sometimes be necessary to communicate fault status of
   one of the locally attached SS-PW at a S-PE. For LDP this can be
   accomplished by sending an LDP notification message containing the PW
   status TLV, as well as an OPTIONAL PW switching point TLV as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification   (0x0001)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Message ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1| Status (0x0300)           |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1|                 Status Code=0x00000028                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID=0                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Message Type=0           |      PW Status TLV            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PW Status TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PW Status TLV         |            PWId FEC           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                 PWId FEC or Generalized ID FEC                |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW sw TLV  (0x096D)   |     PW sw TLV  Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Variable Length Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Only one S-PE TLV can be present in this message. This message is

SB> This is a general comment, but I think that it would
SB> be a good idea to allocate figure numbers to the TLV and
SB> protocol exchanges.
SB> This not only allows the reader to point to these
SB> components more easily, but we might want to point to
SB> in another of our documents.

<snip>


   The merging of the received LDP status and the local status for the
   PW segments at an S-PE can be summarized as follows:

        -i. When the local status for both PW segments is UP, the S-PE
SB> We kind of need a better name than "both PW segments"

<snip>

SB> You really ought to five the figure a number and point to it
SB> for the table below.

        -i. PW2 Transmit direction fault
       -ii. PW1 Transmit direction fault
      -iii. PW2 Receive direction fault
       -iv. PW1 Receive direction fault

<snip>



12. Security Considerations

   This document specifies the LDP and L2TPv3 extensions that are needed
SB> and VCCV extensions
   for setting up and maintaining pseudowires. The purpose of setting up
   pseudowires is to enable layer 2 frames to be encapsulated and
   transmitted from one end of a pseudowire to the other. Therefore we
   treat the security considerations for both the data plane and the
SB> address the security?
   control plane.

<snip>

12.2. Control Protocol Security

<snip>

   A Pseudowire connects two attachment circuits. It is important to
   make sure that LDP connections are not arbitrarily accepted from
   anywhere, or else a local attachment circuit might get connected to
   an arbitrary remote attachment circuit. Therefore an incoming session
   request MUST NOT be accepted unless its IP source address is known to
   be the source of an "eligible" peer. The set of eligible peers could
   be pre-configured (either as a list of IP addresses, or as a list of
   address/mask combinations), or it could be discovered dynamically via
   an auto-discovery protocol which is itself trusted. (Obviously if the
   auto-discovery protocol were not trusted, the set of "eligible peers"
   it produces could not be trusted.)
SB> You might want to rephase the last sentence, because it
SB> treats the reader like an idiot :)

<snip>

   For a greater degree of security, the LDP MD5 authentication key
   option, as described in section 2.9 of RFC 3036, or the Control
   Message Authentication option of [L2TPv3] MAY be used.

SB> I am worried that sec review will complain about MD5
SB> do we have to say MD5 rather than something just saying
SB> use the flavor of the month crypto authentication.

<snip>

 This provides
   integrity and authentication for the control messages, and eliminates
   the possibility of source address spoofing.  Use of the message
   authentication option does not provide privacy, but privacy of
   control messages are not usually considered to be highly urgent.
SB> urgent means "do now" I think you mean important

<snip>


13. IANA Considerations

13.1. L2TPv3 AVP

   This document uses a ne L2TP parameter, IANA already maintains a
   registry of name "Control Message Attribute Value Pair" defined by
   [RFC3438]. The following new values are required:
SB> only one value

   TBA-L2TP-AVP-1 - PW Switching Point AVP

13.2. LDP TLV TYPE

   This document uses several new LDP TLV types, IANA already maintains
SB> But you only ask for one new TLV below
   A registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The
   following value is suggested for assignment:

      TLV type  Description
       0x096D   Pseudowire Switching TLV



13.3. LDP Status Codes

   This document uses several new LDP status codes, IANA already
SB> But you only ask for one new status code below
   maintains a registry of name "STATUS CODE NAME SPACE" defined by
   RFC3036. The following value is suggested for assignment:

      Assignment E Description
      0x0000003A 0 "PW Loop Detected"


13.4. L2TPv3 Result Codes

   This document uses several new L2TPv3 status codes, IANA already
SB> ... and I only see one request below
   maintains a registry of name "L2TPv3 Result Codes" defined by
   RFCxxxx. The following value is suggested for assignment:
SB> ... you need the RFC number

      Assignment  Description
          17      "sequencing not supported"


13.5. New IANA Registries

   IANA needs to set up a registry of "PW Switching Point TLV Type".
   These are 8-bit values. Types value 1 through 3 are defined in this
   document. Type values 4 through 64 are to be assigned by IANA using
SB> you define 1 through 6 below

<snip>
  Type  Length   Description

   0x01     4     PW ID of last PW segment traversed
   0x02  variable PW Switching Point description string
   0x03    4/16   Local IP address of PW Switching Point
   0x04    4/16   Remote IP address of last PW Switching Point traversed
                  or of the T-PE
   0x05  variable AI of last PW segment traversed
   0x06     10    L2 PW address of PW Switching Point


<end>

From [e-mail]  Thu Mar 12 09:18:04 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008A028C1E4 for <[e-mail]>; Thu, 12 Mar 2009 09:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.969
X-Spam-Level: 
X-Spam-Status: No, score=-9.969 tagged_above=-999 required=5 tests=[AWL=0.630,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Frt1XjeyEyXj for <[e-mail]>; Thu, 12 Mar 2009 09:18:02 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D04D128C1F0 for <[e-mail]>; Thu, 12 Mar 2009 09:17:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,351,1233532800"; d="scan'208";a="35904799"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2009 16:18:24 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2CGIP7U028059;  Thu, 12 Mar 2009 17:18:25 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2CGIOiU019957; Thu, 12 Mar 2009 16:18:24 GMT
Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2CGIKF02780; Thu, 12 Mar 2009 16:18:20 GMT
Message-ID: <[e-mail]>
Date: Thu, 12 Mar 2009 16:18:20 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail], pwe3 <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12709; t=1236874705; x=1237738705; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Last=20call=20comments=20on=20draft-ietf-pwe3-v ccv-bfd-03 |Sender:=20; bh=P6sAsDUvKLrDxso8m62L85H1sT92ceXDf6pZ2cWlLjY=; b=vHG/1Jr++YstdX4FsoHcCLCh/morZF1Ap1GlgMv66t/20FX5d1e3kgny6O B/2MzaEQ7Nu0r1G4SQ5SwacGjs0Er4iIkF+hQDw6s2S1qWJsfZ1y9z3zq9X2 UzBD8AmTlb;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Subject: [PWE3] Last call comments on draft-ietf-pwe3-vccv-bfd-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 16:18:04 -0000

Some last call comments on draft-ietf-pwe3-vccv-bfd-03


- Stewart



Carlos

Are you going to get this reviewed in L2TPext?



              Bidirectional Forwarding Detection (BFD) for
    the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
                      draft-ietf-pwe3-vccv-bfd-03

<snip>

   The CV Type is defined as a bitmask field used to indicate the
   specific CV Type or Types (i.e., none, one or more) of VCCV packets
   that may be sent on the VCCV control channel.  The values shown below
   augment those already defined in [RFC5085].  They represent the
SB> Perhaps "also shown in paranthasis(sp) in the
SB> table below is the numerical...." might be clearer
   numerical value corresponding to the actual bit being set in the CV
   Type bitfield.

   BFD CV Types:

      The defined values for the different BFD CV Types for MPLS and
      L2TPv3 PWs are:

      Bit (Value)   Description
      ============  ====================================================
      Bit 2 (0x04)  BFD IP/UDP-encapsulated, for PW Fault Detection only
      Bit 3 (0x08)  BFD IP/UDP-encapsulated, for PW Fault Detection and
                    AC/PW Fault Status Signaling
      Bit 4 (0x10)  BFD PW-ACH-encapsulated, for PW Fault Detection only
      Bit 5 (0x20)  BFD PW-ACH-encapsulated, for PW Fault Detection and
                    AC/PW Fault Status Signaling

   It should be noted that four BFD CV Types have been defined by
   permutation of their encapsulation and functionality, see
   Section 3.3.
SB> The above is perfectly correct, but I had to think about it
SB> I wonder if there is a simpler way to say it.

<snip>


   When the downstream PE (D-PE) does not receive BFD control messages
   from its upstream peer PE (U-PE) during a certain number of
   transmission intervalS (a number provisioned by the operator as
   Detect Mult),
SB> where is Detect Mult defined - Do you mean Detect Multiplier?


 D-PE declares that the PW in its receive direction is
   down.  In other words, D-PE enters the "forward defect" state for
   this PW.  After this calculated Detection Time, D-PE declares the
SB> Perhaps clarify that Detection time is transmission interval times
SB> Detection Multiplier plus a bit.

   session Down, and signals this to the remote end via the State (Sta)
   with Diagnostic code 1 (Control Detection Time Expired).  In turn,
   U-PE declares the PW is down in its transmit direction setting the
   State to Down, and it using Diagnostic code 3 (Neighbor signaled
SB> and "if" using
   session down) in its control messages to D-PE.  U-PE enters the
   "reverse defect" state for this PW.  If needed, how it further
SB> something wrong with the English "If needed, how.....
   processes this error condition, and conveys this status to the
   attachment circuits is out of the scope of this specification, and is
   instead defined in [I-D.ietf-pwe3-oam-msg-map].

SB> Next sentence comes out of the blue - does it belong here?
   The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base]
   encapsulated as specified by the CV Type (see Section 3.2).

3.2.  BFD Encapsulation

   There are two ways in which a BFD connectivity verification packet
   may be encapsulated over the VCCV control channel.  This document
   defines four BFD CV Types (see Section 3), which can be grouped into
   two pairs of BFD CV Types from an encapsulation point of view.
SB> In next do you mean "See table...."
   Table 1 in Section 3.3 summarizes the BFD CV Types.

<snip>
 
      The IP version (IPv4 or IPv6) matches the IP version used for
SB> do you mean MUST match the IP version?
      signaling for dynamically established pseudowires, or is
SB> then this would be "or MUST be configued"

<snip>

      In this encapsulation, a "raw" BFD Control packet follows directly
      the PW-ACH, and the PW-ACH Channel Type identifies "raw" BFD.  
SB> The above does not quite read properly

<snip>
      The usage of the PW-ACH on different VCCV CC Types is specified
      for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1,
      5.1.2 and 5.1.3 of [RFC5085], in all cases depending on the use of
SB> Perhaps ", and in all cases requires the use of"
      a CW.  When VCCV carries raw BFD, the PW-ACH (Pseudowire CW's or
      L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD
      Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers,
      see Section 5.2), to allow the identification of the encased BFD
      payload when demultiplexing the VCCV control channel.  In this
      case, the BFD CV Type employed in signaling (if used) is either
      0x10 or 0x20.
SB> The above is correct. but very cryptic.


3.3.  CV Types for BFD

   Four CV Types are defined for BFD.  Table 1 summarizes the BFD CV
   Types, grouping them by encapsulation (i.e., with and without IP/UDP
   headers) and by functionality (i.e., fault detection only, or fault
   detection and status signaling).

   +----------------------------+--------------+-----------------------+
   |                            |     Fault    |  Fault Detection and  |
   |                            |   Detection  |    Status Signaling   |
   |                            |     Only     |                       |
   +----------------------------+--------------+-----------------------+
   |  BFD, IP/UDP encapsulation |     0x04     |          0x08         |
   |      (with IP/UDP Headers) |              |                       |
   |                            |              |                       |
   |  BFD, PW-ACH encapsulation |     0x10     |          0x20         |
   |   (without IP/UDP Headers) |              |                       |
   +----------------------------+--------------+-----------------------+

                 Table 1: Bitmask Values for BFD CV Types

SB> The earlier sections would be easier to read if this
SB> table was earlier in the document.

   The following list enumerates rules, restrictions and clarifications
   on the usage of BFD CV Types:

   1.  BFD CV Types used for fault detection and status signaling (i.e.,
       CV Types 0x08 and 0x20) SHOULD NOT be used when a control
       protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
       that can signal the AC/PW status to the remote endpoint of the
       PW.  More details can be found in [I-D.ietf-pwe3-oam-msg-map].

   2.  BFD CV Types used for fault detection only (i.e., CV Types 0x04
       and 0x10) can be used whether a protocol that can signal AC/PW
       status is available or not.  This includes both statically
       provisioned and dynamically signaled pseudowires.

SB> Strange sublist symbol on next
       A.  In this case, BFD is used exclusively to detect faults on the
<snip>

   3.  Pseudowires that do not use a CW or L2SS using the PW Associated
       Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e.,
       PW-ACH encapsulation of BFD, without IP/UDP headers).

       A.  PWs that use a PW-ACH include CC Type 1 (for both MPLS and
           L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]),
           and MPLS CC Types 2 and 3 when using a Control Word (as
           specified in Sections 5.1.2 and 5.1.3 of [RFC5085]).  This
           restriction stems from the fact that the PW-ACH contains a
           Protocol Identification (PID) field, the Channel Type.
SB> Please do not call the channel type a PID - it's going
SB> to get confusing.


       B.  PWs that do not use a PW-ACH can use the VCCV BFD
SB> MUST only? or can only? The the rest of the para is really
SB> quite difficult to read
           encapsulation with IP/UDP headers, including its concurrent
           use along with another CV Type that uses an encapsulation
           with IP headers (e.g., ICMP Ping or LSP Ping).  For example,
           as specified in Section 7 of [RFC4385], a Pseudowire
           operating without CW MUST NOT use the PW-ACH.

   4.  Only a single BFD CV Type can be selected and used.  All BFD CV
       Types are mutually exclusive with the rest, after selecting a BFD
SB? perhaps a "." after rest
       CV Type, a node MUST NOT use any of the other three BFD CV Types.


4.  Capability Selection

   The precedence rules for selection of various CC and CV Types is
   clearly outlined in Section 7 of [RFC5085].  This section augments
   these rules when the BFD CV Types defined herein are supported.  The
   selection of a specific BFD CV Type to use out of the four available
   CV Types defined is tied to multiple factors, as hinted in
SB> Hints are not good in a std track document :)
   Section 3.3.  

<snip>

   There may be more than one CV Type available for selection after
   considering the intersection of advertised and received BFD CV Types,
   and applying the rules in Section 3.3.  For these cases were multiple
   BFD CV Types are available for selection, the following precedence
   order applies when choosing the single BFD CV Type to use.  The
   lowest numbered item (where both ends have set the indicated flag and
   such flag is allowed by the rules above) is used:

SB> By lowest number do you mean the item nearest the top of the
SB> list below? People will get confused between the list
SB> point number and the cv type unless this it is very carefully
SB> stated how to chose from the list below.

   1.  0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
       Fault Detection and AC/PW Fault Status Signaling

   2.  0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
       Fault Detection only

   3.  0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW
       Fault Status Signaling

   4.  0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only

   This precedence order prioritizes superset of functionality and
   simplicity of encapsulation.


5.  IANA Considerations

5.1.  MPLS CV Types for the VCCV Interface Parameters Sub-TLV

   The VCCV Interface Parameters Sub-TLV codepoint is defined in
   [RFC4446], and the VCCV CV Types registry is defined in [RFC5085].
   This section lists the new BFD CV Types.

   IANA is requested to augment the "VCCV Connectivity Verification
   Types" registry in the Pseudo Wires Name Spaces, reachable from
   [IANA.pwe3-parameters].  These are bitfield values.  CV Type values
   0x04 0x08, 0x10 and 0x20 are specified in Section 3.
SB> Section 3 of this document.


      MPLS Connectivity Verification (CV) Types:

      Bit (Value)   Description
      ============  ====================================================
      Bit 2 (0x04)  BFD IP/UDP-encapsulated, for PW Fault Detection only
      Bit 3 (0x08)  BFD IP/UDP-encapsulated, for PW Fault Detection and
                    AC/PW Fault Status Signaling
      Bit 4 (0x10)  BFD PW-ACH-encapsulated, for PW Fault Detection only
      Bit 5 (0x20)  BFD PW-ACH-encapsulated, for PW Fault Detection and
                    AC/PW Fault Status Signaling

5.2.  PW Associated Channel Type

SB> The next will confuse IANA.
SB> All they want is an instruction and that instruction
SB> is to allocate 0x0007


   The PW Associated Channel Types used by VCCV rely on previously
   allocated numbers from the Pseudowire Associated Channel Types
   Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from
   [IANA.pwe3-parameters].  In particular, 0x21 (Internet Protocol
   version 4) is used whenever an IPv4 payload follows the Pseudowire
   Associated Channel Header, or 0x57 is used when an IPv6 payload
   follows the Pseudowire Associated Channel Header.

   In cases where a raw BFD Control packet follows the Pseudowire
   Associated Channel as specified in Section 3.2 (i.e., when using the
   PW-ACH-encapsulated BFD without IP/UDP headers), a new "Pseudowire
   Associated Channel Types" Registry [RFC4385] entry of 0x07 is used.
   IANA is requested to reserve a new Pseudowire Associated Channel Type
   value as follows:


     Value (in hex)  Protocol Name                      Reference
     --------------  ---------------------------------  ---------

     0x0007          BFD Control, PW-ACH encapsulation  [This document]
                     (without IP/UDP Headers)

<snip>


6.  Congestion Considerations

   The congestion considerations that apply to [RFC5085] apply to this
   mode of operation as well.

SB>... there are no additional congestion considerations


From [e-mail]  Thu Mar 12 10:51:34 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E62D28C278; Thu, 12 Mar 2009 10:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.082
X-Spam-Level: 
X-Spam-Status: No, score=-7.082 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ph1dkjcZEzOi; Thu, 12 Mar 2009 10:51:28 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9DE0F28C27A; Thu, 12 Mar 2009 10:51:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,351,1233532800"; d="scan'208";a="39552801"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Mar 2009 17:52:00 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2CHq0PW000313;  Thu, 12 Mar 2009 13:52:00 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2CHq0Xi011973; Thu, 12 Mar 2009 17:52:00 GMT
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 12 Mar 2009 13:52:00 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Mar 2009 13:51:59 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls] [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
Thread-Index: AcmeenhnQRpQH0GjPUmTSqrAenuIjwEwLsag
References: <[e-mail]> <[e-mail]>
From: "Luyuan Fang (lufang)" <[e-mail]>
To: "Ben Niven-Jenkins" <[e-mail]>, "Thomas Nadeau" <[e-mail]>, "Loa Andersson" <[e-mail]>
X-OriginalArrivalTime: 12 Mar 2009 17:52:00.0188 (UTC) FILETIME=[3E638FC0:01C9A33B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2128; t=1236880320; x=1237744320; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Luyuan=20Fang=20(lufang)=22=20<[e-mail] > |Subject:=20RE=3A=20[mpls]=20[PWE3]=202nd=20wg=20last=20cal l=20on=20draft-ietf-mpls-tp-gach-gal |Sender:=20 |To:=20=22Ben=20Niven-Jenkins=22=20<benjamin.niven-jenkins@ bt.com>,=0A=20=20=20=20=20=20=20=20=22Thomas=20Nadeau=22=20< [e-mail]>,=20=22Loa=20Andersson=22=20<loa@pi. nu>; bh=bW/L1n5TXco44JSOoK2zFEp0WgVWVrKtFgFOTe02uw0=; b=jlcuzsrWqhJXFhoV7KlM32rAVO6ys2ZJoI+08NXcZjDqiI4fYcIb6bmNhY gdoZA1U2xSsoalmLC27zEeEn5XwsdATiwlvUAWU55VhRKmpERm2o+QEjlffi OCIBLbaOj/;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Cc: [e-mail], ITU-T ad hoc team on MPLS-TP <[e-mail]>, [e-mail], [e-mail], [e-mail], David Ward <[e-mail]>, Malcolm Betts <[e-mail]>, VIGOUREUX MARTIN <[e-mail]>
Subject: Re: [PWE3] [mpls]  2nd wg last call on draft-ietf-mpls-tp-gach-gal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 17:51:34 -0000

Agreed.
Luyuan=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Ben Niven-Jenkins
Sent: 06 March 2009 11:42
To: Thomas Nadeau; Loa Andersson
Cc: [e-mail]; ITU-T ad hoc team on MPLS-TP; [e-mail];
[e-mail]; [e-mail]; David Ward; Malcolm Betts; VIGOUREUX
MARTIN
Subject: Re: [mpls] [PWE3] 2nd wg last call on
draft-ietf-mpls-tp-gach-gal

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without
significant changes to their existing support infrastructures.

Ben



On 06/03/2009 14:00, "Thomas Nadeau" <[e-mail]> wrote:

>=20
> I think this document is ready to progress forward.
>=20
> --Tom
>=20
>=20
> On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:
>=20
>> All,
>>=20
>> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal has been=20
>> published.
>>=20
>> The draft is found at:
>>=20
>> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>>=20
>> Since the updates are significant this is to initiate a 2 week=20
>> working group last call on the new version.
>>=20
>> Please send your comments to the [e-mail] mailing list.
>>=20
>> The working group last call will end on March 11.
>>=20
>> /Loa
>> --
>>=20
>>=20
>> Loa Andersson
>>=20
>> Sr Strategy and Standards Manager
>> Ericsson ///                          phone:  [phone]
>>=20
>>                                      email:
>> [e-mail]
>>
[e-mail]
>>                                              [e-mail]
>>=20
>>=20
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>=20
>=20
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls

From [e-mail]  Thu Mar 12 11:18:21 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A30128C24E for <[e-mail]>; Thu, 12 Mar 2009 11:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
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 GvL-ERaXjLmR for <[e-mail]>; Thu, 12 Mar 2009 11:18:14 -0700 (PDT)
Received: from napoleon.monoski.com (black.monoski.com [63.227.123.238]) by core3.amsl.com (Postfix) with ESMTP id EE7273A6AF5 for <[e-mail]>; Thu, 12 Mar 2009 11:17:56 -0700 (PDT)
Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n2CIFiE4009485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 12:15:44 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Thu, 12 Mar 2009 12:15:44 -0600
From: Luca Martini <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20081209)
MIME-Version: 1.0
To: "PWE3 WG (E-mail)" <[e-mail]>
Content-Type: multipart/mixed; boundary="------------020808090708080500070709"
X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1
Subject: [PWE3] [Fwd: Re: review of draft-ietf-pwe3-segmented-pw-10.txt]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 18:18:21 -0000

This is a multi-part message in MIME format.
--------------020808090708080500070709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

WG,

FYI, I also received these comments off list.
Luca


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

Hi Luca,

Apologize for a very late reply to this.

I also embedded some comments inline in the version with Matthew's
comments. The text file attached contains all my comments marked with
the "###CP>" prefix.

I realize you posted the new revision already; I had started reviewing
the document, and half-way through I went on vacations and came back
working interrupt-driven. I decided to continue embedding the comments
in the same text file, and finished just now.

I hope these are useful and clear. Please do let me know if there's
anything that needs further clarification. I did include quite a number
of comments, including both more editorial and more substantive issues.
And specifically, there are a couple of more substantive comments that
are long, dense and somewhat core.

Thanks,

-- Carlos.



--------------020808090708080500070709
Content-Type: text/plain;
 name="draft-ietf-pwe3-segmented-pw-10-MB-cpignata.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-pwe3-segmented-pw-10-MB-cpignata.txt"







Network Working Group                                       Luca Martini
Internet Draft                                                Chris Metz
Expiration Date: July 2008                            Cisco Systems Inc.
Intended status: Standards Track
                                                        Thomas D. Nadeau
Matthew Bocci                                                         BT
Florin Balus
Mustapha Aissaoui                                           Mike Duckett
Alcatel-Lucent                                                 Bellsouth

                                                            January 2008


                         Segmented Pseudo Wire
                                        ^^^^^
MB> Update to Segmented Pseudowire

                  draft-ietf-pwe3-segmented-pw-10.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes how to connect pseudowires (PW) between two
   distinct PW control planes or PSN domains. The PW control planes may
   belong to independent autonomous systems, or the PSN technology is
   heterogeneous, or a PW might need to be aggregated at a specific PSN
   point. The PW packet data units are simply switched from one PW to

###CP>           ^^^^^^^^^^^^^^^^^
###CP>           Service Data Units (SDUs instead of PDUs)?
###CP>           Using that might simplify some of the later 
###CP>           descriptions.



Martini, et al.                                                 [Page 1]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   another without changing the PW payload.


















































Martini, et al.                                                 [Page 2]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008




Table of Contents

    1        Specification of Requirements  ........................   4
    2        Terminology  ..........................................   5
    3        Introduction  .........................................   5
    4        General Description  ..................................   7
    5        PW Switching and Attachment Circuit Type  .............  10
    6        Applicability  ........................................  10
    7        PW-MPLS to PW-MPLS Control Plane Switching  ...........  10
    7.1      Static Control plane switching  .......................  11
    7.2      Two LDP control planes using the same FEC type  .......  11
    7.2.1    FEC 129 Active/Passive T-PE Election Procedure  .......  12
    7.3      LDP FEC 128 to LDP using the generalized FEC 129  .....  12
    7.4      LDP PW switching point TLV  ...........................  13
    7.4.1    PW Switching Point Sub-TLVs  ..........................  14
    7.4.2    Adaptation of Interface Parameters  ...................  15
    7.5      Group ID  .............................................  16
    7.6      PW Loop Detection  ....................................  16
    8        PW-MPLS to PW-L2TPv3 Control Plane Switching  .........  16
    8.1      Static MPLS and L2TPv3 PWs  ...........................  17
    8.2      Static MPLS PW and Dynamic L2TPv3 PW  .................  17
    8.3      Static L2TPv3 PW and Dynamic LDP/MPLS PW  .............  17
    8.4      Dynamic LDP/MPLS and L2TPv3 PWs  ......................  17
    8.4.1    Session Establishment  ................................  18
    8.4.2    Adaptation of PW Status message  ......................  18
    8.4.3    Session Tear Down  ....................................  19
    8.5      Adaptation of L2TPv3 AVPs to Interface Parameters  ....  19
    8.6      Switching Point TLV in L2TPv3  ........................  20
    8.7      L2TPv3 and MPLS PW Data Plane  ........................  20
    8.7.1    PWE3 Payload Convergence and Sequencing  ..............  21
    8.7.2    Mapping  ..............................................  21
    9        Operation And Management  .............................  22
    9.1      Extensions to VCCV to Support Switched PWs  ...........  22
    9.2      PW-MPLS to PW-MPLS OAM Data Plane Indication  .........  22
    9.3      Signaling OAM Capabilities for Switched Pseudowires  ..  23
    9.4      OAM Capability for MS-PWs Demultiplexed using MPLS  ...  23
    9.4.1    MS-PW and VCCV CC Type 1  .............................  24
    9.4.2    MS-PW and VCCV CC type 2  .............................  24
    9.4.3    MS-PW and VCCV CC type 3  .............................  24
    9.5      MS-PW VCCV Operations  ................................  24
    9.5.1    VCCV Echo Message Processing  .........................  25
    9.5.1.1  Sending a VCCV Echo Request  ..........................  26
    9.5.1.2  Receiving a VCCV Echo Request  ........................  26
    9.5.1.3  Receiving a VCCV Echo Reply  ..........................  27
    9.5.2    Detailed VCCV procedures  .............................  27
    9.5.2.1  End to End Connectivity Verification Between T-PEs  ...  27



Martini, et al.                                                 [Page 3]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


    9.5.2.2  Partial Connectivity Verification from T-PE  ..........  28
    9.5.2.3  Partial connectivity verification between S-PEs  ......  28
    9.5.2.4  MS-PW Path Verification  ..............................  29
    9.5.2.5  MS-PW Path Trace  .....................................  30
   10        Mapping Switched Pseudowire Status  ...................  31
   10.1      S-PE initiated PW status messages  ....................  32
   10.1.1    Local PW2 transmit direction fault  ...................  33
   10.1.2    Local PW1 transmit direction fault  ...................  34
   10.1.3    Local PW2 receive direction fault  ....................  34
   10.1.4    Local PW1 receive direction fault  ....................  34
   10.1.5    Clearing Faults  ......................................  34
   10.2      PW status messages and S-PE TLV processing  ...........  35
   10.3      T-PE processing of PW status messages  ................  35
   10.4      Pseudowire Status Negotiation Procedures  .............  35
   10.5      Status Dampening  .....................................  35
   11        Peering Between Autonomous Systems  ...................  35
   12        Security Considerations  ..............................  36
   12.1      Data Plane Security  ..................................  36
   12.1.1    VCCV Security considerations  .........................  36
   12.2      Control Protocol Security  ............................  36
   13        IANA Considerations  ..................................  37
   13.1      L2TPv3 AVP  ...........................................  37
   13.2      LDP TLV TYPE  .........................................  38
   13.3      LDP Status Codes  .....................................  38
   13.4      L2TPv3 Result Codes  ..................................  38
   13.5      New IANA Registries  ..................................  38
   14        Intellectual Property Statement  ......................  39
   15        Full Copyright Statement  .............................  39
   16        Acknowledgments  ......................................  40
   17        Normative References  .................................  40
   18        Informative References  ...............................  41
   19        Author Information  ...................................  42






1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].








Martini, et al.                                                 [Page 4]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


2. Terminology

###CP> It's not clear what the order of these are, and makes it a bit 
###CP> confusing to read. Is it easier to index per acronym (start the 
###CP> line with "T-PE ..." and sort alphabetically?
###CP>

     - PW Terminating Provider Edge (T-PE). A PE where the customer-
       facing attachment circuits (ACs) are bound to a PW forwarder. A
       Terminating PE is present in the first and last segments of a
       MS-PW. This incorporates the functionality of a PE as defined in
       [RFC3985].

     - Single-Segment Pseudowire (SS-PW). A PW setup directly between
       two T-PE devices. Each PW in one direction of a SS-PW traverses
       one PSN tunnel that connects the two T-PEs.

     - Multi-Segment Pseudowire (MS-PW).  A static or dynamically
       configured set of two or more contiguous PW segments that behave
       and function as a single point-to-point PW. Each end of a MS-PW
       by definition MUST terminate on a T-PE.

     - PW Segment. A part of a single-segment or multi-segment PW, which
       is set up between two PE devices, T-PEs and/or S-PEs.

     - PW Switching Provider Edge (S-PE).  A PE capable of switching the
       control and data planes of the preceding and succeeding PW
       segments in a MS-PW. The S-PE terminates the PSN tunnels of the
       preceding and succeeding segments of the MS-PW. It is therefore a

###CP> The sentence/para above is not terminated
###CP>

     - PW switching point for a MS-PW. A PW Switching Point is never the
       S-PE and the T-PE for the same MS-PW. A PW switching point runs
       necessary protocols to setup and manage PW segments with other PW
       switching points and terminating PEs.

MB> I think the above two bullets can be merged. A PW switching point is an S-PE.


3. Introduction

   PWE3 defines the signaling and encapsulation techniques for
   establishing SS-PWs between a pair of ultimate PEs and in the vast
   majority of cases this will be sufficient. MS-PWs come into play in
   two general cases:

MB> Add a reference to RFC5254

        -i. When it is not possible, desirable or feasible to establish
            a PW control channel between the ultimate source and
            destination PEs. At a minimum PW control channel
            establishment requires knowledge of and reachability to the
            remote (ultimate) PE IP address. The local (ultimate) PE may
            not have access to this information related to topology,
            operational or security constraints.

            An example is the inter-AS L2VPN scenario where the ultimate
            PEs reside in different provider networks (ASes) and it is



Martini, et al.                                                 [Page 5]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


            the practice to MD5-key all control traffic exchanged
            between two networks. Technically a SS-PW could be used but
            this would require MD5-keying on ALL ultimate source and
            destination PE nodes. An MS-PW allows the providers to
            confine MD5 key administration to just the PW switching
            points connecting the two domains.

            A second example might involve a single AS where the PW
            setup path between the ultimate PEs is computed by an
            external entity (i.e. client-layer routing protocol). Assume
            a full mesh of PWE3 control channels established between
            PE-A, PE-B and PE-C. A client-layer L2 connection tunneled
            through a PW is required between ultimate PE-A and PE-C. The
            external entity computes a PW setup path that passes through
            PE-B. This results in two discrete PW segments being built:
            one between PE-A and PE-B and one between PE-B and PE-C. The
            successful client-layer L2 connection between ultimate PE-A
            and ultimate PE-C requires that PE-B performs the PWE3
            switching process.

            A third example involves the use of PWs in hierarchical
            IP/MPLS networks.  Access networks connected to a backbone
            use PWs to transport customer payloads between customer
            sites serviced by the same access network and up to the edge
            of the backbone where they can be terminated or switched
            onto a succeeding PW segment crossing the backbone. The use
            of PWE3 switching between the access and backbone networks
            can potentially reduce the PWE3 control channels and routing
            information processed by the access network T-PEs.

            It should be noted that PWE3 switching does not help in any
            way to reduce the amount of PW state supported by each
            access network T-PE.

       -ii. PWE3 signaling and encapsulation protocols are different.

###CP>                     ^^^
###CP>                     Should this be "and/or" ?
###CP>
            The ultimate PEs are connected to networks employing
            different PW signaling and encapsulation protocols. In this
            case it is not possible to use a SS-PW. A MS-PW with the
            appropriate interworking performed at the PW switching
            points can enable PW connectivity between the ultimate PEs
            in this scenario.


   There are four different signaling protocols that are defined to
   signal PWs:

###CP> A nit: is static configuration a signaling protocol? And FEC 128 
###CP> vs. FEC 129 are also not different signaling protocols. Maybe 
###CP> "There are four different methods to set up PWs"?



Martini, et al.                                                 [Page 6]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


        -i. Static configuration of the PW (MPLS or L2TPv3).
       -ii. LDP using FEC 128
      -iii. LDP using the generalized FEC 129
       -iv. L2TPv3

###CP> It would help to add citations "[RFCxxxx]" to the above 4 types.
###CP>
4. General Description

   A pseudowire (PW) is a tunnel established between two provider edge
   (PE) nodes to transport L2 PDUs across a packet switched network
   (PSN) as described in Figure 1 and in [PWE3-ARCH]. Many providers are
   looking at PWs as a means of migrating existing (or building new)
   L2VPN services (i.e.  Frame-Relay, ATM, Ethernet) on top of a PSN by
   using PWs.                                                        



MB> Reword to the above sentence to: 
"Many providers have deployed PWs as a means of migrating existing (or building 
new) L2VPN services (e.g.. Frame Relay, ATM, or Ethernet) on to a PSN."



   PWs may span multiple autonomous systems of the same or
   different provider networks. In these scenarios PW control channels
   (i.e. targeted LDP, L2TPv3) and PWs will cross AS boundaries.

   Inter-AS L2VPN functionality is currently supported and several
   techniques employing MPLS encapsulation and LDP signaling have been
   documented [2547BIS]. It is also straightforward to support the same
               ^^^^^^^
MB> Update reference to RFC4364

   inter-AS L2VPN functionality employing L2TPv3. In this document we
   define methodology to switch a PW between two PW control planes.

###CP> "between two PW protocol plane instances."?
###CP>                                ^^^^^^^^^

         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<-------- Pseudowire ------>|          |
         |          |                            |          |
         |          |    |<-- PSN Tunnel -->|    |          |
         |          V    V                  V    V          |
         V    AC    +----+                  +----+     AC   V
   +-----+    |     | PE1|==================| PE2|     |    +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^ |     |    |==================|    |     | ^  +-----+
         ^  |       +----+                  +----+     | |  ^
         |  |   Provider Edge 1         Provider Edge 2  |  |
         |  |                                            |  |
   Customer |                                            | Customer
   Edge 1   |                                            | Edge 2
            |                                            |
      native service                               native service

                     Figure 1: PWE3 Reference Model


   There are two methods for switching a PW between two PW control
   planes. In the first method (Figure 2), the two control planes

###CP>  ^
###CP>  add "instances" ?



Martini, et al.                                                 [Page 7]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   terminate on different PEs.

                |<------------Emulated Service---------->|
                |      PSN                      PSN      |
            AC  |    |<-1->|                  |<-2->|    |  AC
            |   V    V     V                  V     V    V  |
            |   +----+     +-----+       +----+     +----+  |
   +----+   |   |    |=====|     |       |    |=====|    |  |    +----+
   |    |-------|......PW1.......|--AC1--|......PW2......|-------|    |
   | CE1|   |   |    |     |     |       |    |     |    |  |    |CE2 |
   |    |-------|......PW3.......|--AC2--|......PW4......|-------|    |
   +----+   |   |    |=====|     |       |    |=====|    |  |    +----+
        ^       +----+     +-----+       +----+     +----+       ^
        |         PE1        PE2          PE3         PE4        |
        |                     ^            ^                     |
        |                     |            |                     |
        |                  PW stitching points                   |
        |                                                        |
        |                                                        |
        |<-------------------- Emulated Service ---------------->|

            Figure 2: PW Switching using ACs Reference Model


###CP> Another "nit": RFC3985 defines "AC" as:
###CP>     "Attachment Circuit   The physical or virtual circuit 
###CP>     attaching a CE to a PE."
###CP> But here, the AC is attaching a PE to a PE.
###CP>
###CP> Should this MS-PW document update/generalize that definition?  
###CP> And/Or further point to RFC5254 ?
###CP> 

   In Figure 2, pseudowires in two separate PSNs are stitched together

###CP>                         ^^^^^^^^^^^^^^^^^
###CP> Is this really stitching together two separate "PSNs" or two 
###CP> separate "PW-Demux Domains"? I think strictly is more the latter.  
###CP> It can be the same PSN. This is a general comment, as I've seen 
###CP> in the document a few places where PSN is used with the "PW 
###CP> Demultiplexing Domain" meaining.
###CP>
###CP>
   using native service attachment circuits. PE2 and PE3 only run the
   control plane for the PSN to which they are directly attached. At PE2

###CP> ^^^^^^^^^^^^^^^^^^^^^
###CP> "control plane instance for the PW-Demux Domain"...
###CP>
   and PE3, PW1 and PW2 are connected using attachment circuit AC1,
   while PW3 and PW4 are connected using attachment circuit AC2.

           Native  |<-----------Pseudowire------------>|  Native
           Layer2  |                                   |  Layer2
          Service  |    |<-PSN1-->|     |<--PSN2->|    |  Service
           (AC)    V    V         V     V         V    V   (AC)
             |     +----+         +-----+         +----+     |
   +----+    |     | PE1|=========| PE2 |=========| PE3|     |    +----+
   |    |----------|........PW1.........|...PW3........|----------|    |
   | CE1|    |     |    |         |     |         |    |     |    |CE2 |
   |    |----------|........PW2.........|...PW4........|----------|    |
   +----+    |     |    |=========|     |=========|    |     |    +----+
        ^          +----+         +-----+         +----+     |    ^
        |      Provider Edge 1       ^        Provider Edge 3     |
        |      (Terminating PE)      |        (Terminating PE)    |
        |                            |                            |
        |                    PW switching point                   |
        |            (Optional PW adaptation function)            |
        |                                                         |
        |<------------------- Emulated Service ------------------>|


MB> This figure generated an errata for RFC5254, and was updated in the MS-PW 
architecture draft. Please can you use the corrected version from Fig 4 of the MS-PW 
arch draft.

###CP> Could this Figure 3 be moved after the next paragraph? The para 
###CP> describes Fig 3, and like this the Figure does not have 
###CP> introduction.

Martini, et al.                                                 [Page 8]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


                 Figure 3: PW Control Plane Switching Reference Model

   In Figure 3 PE2 runs two separate control planes: one toward PE1, and
   one Toward PE3. The PW switching point is at PE2 which is configured

###CP>                 ^^^^^^^^^^^^^^^^^^
###CP>                 Can you add "S-PE" for PE2?
###CP>
   to connect PW1 and PW3 together to complete the multi-hop PW between
   PE1 and PE3.  PW1 and PW3 MUST be of the same PW type, but PSN1 and
   PSN2 need not be the same technology.
   
###CP> Where it says "PW1 and PW3 MUST be of the same PW type":
###CP>      
###CP>      Should this be "the same or equivalent PW Type"? Note that 
###CP>      there are different PW Type spaces for MPLS PWs and L2TPv3 
###CP>      PWs. More comments in Section 8.
###CP>
###CP> Where it says "but PSN1 and PSN2 need not be the same 
###CP> technology":
###CP> 
###CP>      Is this referring to the "PSN1" and "PSN2" as "PSN 
###CP>      Technonogy" or to the "PW-Demux" Technology?
###CP> 
   In the latter case, if the PW
   is switched to a different technology, the PEs must adapt the PDU
   encapsulation between the different PSN technologies.

###CP> I think that the cases of MPLS over GRE, MPLS over IP directly 
###CP> [RFC 4023], MPLS over L2TPv3 [RFC 4817] can blur the meaning of 
###CP> what's being meant in the above para. Which technology type is 
###CP> being compared? I think the PW-Demux technology, not the PSN, 
###CP> right?
###CP>
   In the case
   where PSN1 and PSN2 are the same technology the PW PDU does not need
   to be modified, and PDUs are then switched between the pseudowires at
   the PW label level.

###CP> Or put a different way, PSN1 and PSN2 can be the same technology, 
###CP> IPv4. PW Segment 1 is MPLS over IP, and PW Segment 2 is L2TPv3 
###CP> over IP. So this is same PSN technology, but different PW-Demux 
###CP> technology.
###CP>
###CP> Also, note that where it says "switched between the pseudowires 
###CP> at the PW label level", it should be "at the PW Demux level".
###CP> 

   It should be noted that it is possible to adapt one PSN technology to
   a different one, for example MPLS over an IP or GRE [RFC4023]
   encapsulation, but this is outside the scope of this document.
   Further, one could perform an interworking function on the PWs
   themselves at the PW switching point, allowing conversion from one PW
   type to another, but this is also outside the scope of this document.

   This document describes procedures for building multi-segment
   pseudowires using manual configuration of the switching point PE2.
   Other documents may build on this base specification to automate the
   configuration and selection of PE2. It should also be noted that a PW
   can traverse multiple PW switching points along it's path, and the
   edge PEs will not require any specific knowledge of how many PW
   switching points the PW has traversed (though this may be reported
   for troubleshooting purposes).

MB> Replace PW switching PE with S-PW throughout

   In general the approach taken is to connect the individual control
   planes by passing along any signaling information immediately upon
   reception. First the PW switching point is configured to switch a
   SS-PW from a specific peer to another SS-PW destined for a different
   peer. No control messages are exchanged yet as the PW switching point
   PE does not have enough information to actually initiate the PW setup
   messages. However, if a session does not already exist, a control
   protocol (LDP/L2TP) session is setup. In this model the MS-PW setup
                        ^^^^^^^^^^^^^^^
MB> Not necessarily. This might depend on local policy, so I would rephrase this
to "However, if a control protocol session session does not already exist, 
a control protocol (LDP/L2TP) session MAY be setup."


   is starting from the T-PE devices. Next once the T-PE is configured
   it sends the PW control setup messages. These messages are received,
   and immediately used to form the PW setup messages for the next SS-PW
   of the MS-PW. If one of the Switching PEs doesn't accept an LDP Label
   Mapping message then a Label Release message may be sent back to the
   originator T-PE depending on the cause of the error. LDP liberal
   label retention mode still applies, hence if a PE is simply not
   configured yet , the label mapping is stored for future use. A MS-PW
   is declared UP when all the constituent SS-PWs are UP.

###CP> Does this really mean "UP" or does it mean that is declared 
###CP> "Successfully Setup"? UP has not been defined, I think it's 
###CP> referring about Setup.


Martini, et al.                                                 [Page 9]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


5. PW Switching and Attachment Circuit Type

   The PWs in each PSN are established independently, with each PSN
   being treated as a separate PWE3 domain. For example, in Figure 2 for
   case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP
   targeted session as described in [RFC4447], and at the same time a
   separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for
   PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the
   same PW type e.g. ATM VCC, Ethernet VLAN, etc.

###CP> "same PW Type", what if L2TPv3 in one segment, and LDP in the 
###CP> other segment? They cannot be the same PW Type.

6. Applicability

   The general applicability of MS-PWs and their relationship to L2VPNs
   is described in [MS-PW-ARCH]. The applicability of a PW type, as
   specified in the relevant RFC for that encapsulation (e.g. [RFC4717]
   for ATM), applies to each segment. This section describes further
   applicability considerations.

   In comon with SS-PWs, the performance of any segment of a MS-PW is
   equal to the performance of the PSN plus any impairments introduced
   by the PW layer itself. Therefore it is not possible for the MS-PW to
   provide better performance than the PSN over which it is transported.
   Furthermore, the overall performance of an MS-PW is no better than
   the worst performing segment of that MS-PW.

   Since different PSN types may be able to achieve different maximum
   performance objectives, it is necessary to carefully consider which
   PSN types are used along the path of a MS-PW.






7. PW-MPLS to PW-MPLS Control Plane Switching

MB> Should be MPLS-PW rather than PW-MPLS


   Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted
   session as described in [RFC4447], at the same time a separate
   pseudowire PW3 is setup to PE3. Each PW is configured independently
   on the PEs, but on PE2 pseudowire PW1 is connected to pseudowire PW3.
   PDUs are then switched between the pseudowires at the PW label level.
   Hence the data plane does not need any special knowledge of the
   specific pseudowire type. A simple standard MPLS label swap operation
   is sufficient to connect the two PWs, and in this case the PW
   adaptation function is not used. However when pushing a new PSN label
   the TTL SHOULD be set to 255, or some other locally configured fixed
   value.

MB> The last sentence may not be true for VCCV packets. Therefore, we should 
add a cross-reference to Section 9 here for details of how to set the PW
label TTL for VCCV packets.

###CP> Ditto.

Martini, et al.                                                [Page 10]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   This process can be repeated as many times as necessary, the only
   limitation to the number of PW switching points traversed is imposed
   by the TTL field of the PW MPLS Label. The setting of the TTL is a

###CP>                     ^^^^^^^^^^^^^
###CP>                     "MPLS PW Label" ? And for L2TPv3 (no TTL)?
###CP>
   matter of local policy on the originating PE, but SHOULD be set to
   255.

   There are three MPLS to MPLS PW control planes:

###CP> Three control planes, or 3 PW Setup methods for MPLS PWs?
###CP>
        -i. Static configuration of the PW.
       -ii. LDP using FEC 128
      -iii. LDP using the generalized FEC 129
   This results in four distinct PW switching situations that are
   significantly different, and must be considered in detail:
        -i. PW Switching between two static control planes.
       -ii. Static Control plane switching to LDP dynamic control plane.
      -iii. Two LDP control planes using the same FEC type
       -iv. LDP using FEC 128, to LDP using the generalized FEC 129


7.1. Static Control plane switching

   In the case of two static control planes the PW switching point MUST
   be configured to direct the MPLS packets from one PW into the other.
   There is no control protocol involved in this case. When one of the
   control planes is a simple static PW configuration and the other
   control plane is a dynamic LDP FEC 128 or generalized PW FEC, then
   the static control plane should be considered identical to an
   attachment circuit (AC) in the reference model of Figure 1. The
   switching point PE SHOULD signal the proper PW status if it detects a
   failure in sending or receiving packets over the static PW.  Because
                                                     ^^^^^^^^^
MB>                                                static PW segment.

   the PW is statically configured, the status communicated to the
   dynamic LDP PW will be limited to local interface failures. In this

###CP>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
###CP>            What if using BFD on statically configured
###CP>            for communicating status?
###CP>
   case, the PW switching point PE behaves in a very similar manner to a
   T-PE, assuming an active role. This means that the S-PE will
   immediately send the LDP Label Mapping message if the static PW is
   deemed to be UP.


7.2. Two LDP control planes using the same FEC type

   As stated in a section above, the PW switching point PE should assume
   an initial passive role. This means that once independent PWs are
   configured on the switching point, the LSR does not advertise the LDP
   PW FEC mapping until it has received at least one of the two PW LDP
   FECs from a remote PE. This is necessary because the switching point
   LSR does not know a priori what the interface parameter field in the
   initial FEC advertisement will contain.

   The PWID is a unique number between each pair of PEs. Hence Each SS-



Martini, et al.                                                [Page 11]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   PW that forms an MS-PW may have a different PWID. In the case of The

###CP>                    ^^^
###CP>                    "will"? since S-PE cannot reuse?

   Generalized PW FEC, the AGI/SAI/TAI may have to also be different for
   some, or sometimes all, SS-PWs.


7.2.1. FEC 129 Active/Passive T-PE Election Procedure

   When a MS-PW is signaled using FEC 129, each T-PE might independently
   start signaling the MS-PW. If the MS-PW path is not statically
   configured, in certain cases the signaling procedure could result in
   an attempt to setup each direction of the MS-PW through different
   paths. To avoid this situation one of the T-PE MUST start the PW
   signaling (active role), while the other waits to receive the LDP
   label mapping before sending the respective PW LDP label mapping
   message. (passive role). When the MS-PW path not statically

###CP>                                         ^
###CP>                                         missing "is".

   configured, the Active T-PE (the ST-PE) and the passive T-PE (the
   TT-PE) MUST be identified before signaling is initiated for a given
   MS-PW.

   The determination of which T-PE assume the active role SHOULD be done
   as follows:

   The SAII and TAII are compared as unsigned integers, if the SAII is
   bigger then the T-PE assumes the active role.

   The selection process to determine which T-PE assumes the active role
   MAY be superseded by manual provisioning.


7.3. LDP FEC 128 to LDP using the generalized FEC 129

   When a PE is using the generalized FEC 129, there are two distinct
   roles that a PE can assume: active and passive. A PE that assumes the
   active role will send the LDP PW setup message, while a passive role
   PE will simply reply to an incoming LDP PW setup message. The PW
   switching point PE, will always remain passive until a PWID FEC 128
   LDP message is received, which will cause the corresponding
   generalized PW FEC LDP message to be formed and sent. If a
   generalized FEC PW LDP message is received while the switching point
   PE is in a passive role, the corresponding PW FEC 128 LDP message
   will be formed and sent.

   PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice
   versa.  This can be accomplished by local PW switching point
   configuration, or by some other means, such as some form of auto
   discovery. Such other means are outside the scope of this document.





Martini, et al.                                                [Page 12]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


7.4. LDP PW switching point TLV

   The edge to edge PW might traverse several switching points, in
   separate administrative domains. For management and troubleshooting
   reasons it is useful to record information about the switching points
   that the PW traverses. This is accomplished by using a PW switching
   point TLV.

   Note that sending the PW switching point TLV is OPTIONAL, however the
   PE or S-PE MUST process the TLV upon reception. The PW switching
   point TLV is appended to the PW FEC at each switching point. Each S-
   PE can append a PW switching point TLV, and the order of the PW
   switching point TLVs MUST be preserved. The S-PE TLV MUST be sent if
   VCCV operation is required beyond the first MS-PW segment from a T-
   PE.

###CP> Where it says that the S-PE TLV MUST be sent for VCCV "beyond the 
###CP> 1st segment from a T-PE", should this be that the S-PE TLV MUST 
###CP> be sent for VCCV "intercepted at that S-PE, since end-to-end VCCV 
###CP> does not need the S-PE TLV" ?

   The PW switching point TLV encoded as follows:

MB> The PW switching point TLV is encoded as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW sw TLV  (0x096D)   |     PW sw TLV  Length         |

###CP> Regarding the U- and F-bits in this TLV, I wonder if the F-bit 
###CP> should be set to propagate the TLV when it's not recognized.
###CP>
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Variable Length Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Variable Length Value                   |
   |                               "                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   [note] LDP TLV type is pending IANA approval.

###CP> Can you add the U-bit and F-bit explicitly in this listing?
###CP>
###CP>
     - PW sw TLV  Length

       Specifies the total length of all the following PW switching
       point TLV fields in octets

###CP>       ^^^
###CP>       "sub-TLV" ?
###CP>
     - Type

       Encodes how the Value field is to be interpreted.

     - Length

       Specifies the length of the Value field in octets.

     - Value

       Octet string of Length octets that encodes information to be
       interpreted as specified by the Type field.



Martini, et al.                                                [Page 13]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   PW Switching point TLV Types are assigned by IANA according the the
   process defined in the "IANA Allocations" section below.

   The PW switching Point TLV is an OPTIONAL TLV that should appear only
   once for each switching point traversed. If the S-PE TLV is not
   present with the required sub-TLVs, VCCV operation will not function.

###CP>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
###CP>                                 Do you mean that "Segment VCCV 
###CP>                                 will not function"?
###CP>
   For local policy reasons, a particular S-PE can filter out all S-PE
   TLVs in a label mapping message that traverses it and not include
   it's own S-PE TLV.  In this case, from any upstream PE, it will
   appear as if this particular S-PE is the T-PE. This might be
   necessary , depending on local policy if the S-PE is at the Service
   provider administrative boundary.


7.4.1. PW Switching Point Sub-TLVs

   Below are details specific to PW Switching Point Sub-TLVs described
   in this document:

     - PW ID of last PW segment traversed. This is only applicable if
       the last PW segment traversed used LDP FEC 128 to signal the PW.

       This sub-TLV type contains a PW ID in the format of the PWID
       described in [RFC4447]. This is just a 32 bit unsigned integer
       number.

     - PW Switching Point description string.

       An optional description string of text up to 80 characters long.

###CP> Which charset encoding? ASCII / UTF-8? This will come up :)
###CP>
     - Local IP address of PW Switching Point.

       The Local IP V4 or V6 address of the PW Switching Point. This is
       an OPTIONAL Sub-TLV. In most cases this will be the local LDP
       session IP address of the S-PE.

     - Remote IP address of the last PW Switching Point traversed or of
       the T-PE

       The IP V4 or V6 address of the last PW Switching Point traversed
       or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases this
       will be the remote IP address of the LDP session. This Sub-TLV
       SHOULD only be included if there are no other S-PE TLV present
       from other S-PEs, or if the remote ip address of the LDP session
       does not correspond to the "Local IP address of PW Switching
       Point" TLV value contained in the last S-PE TLV.




Martini, et al.                                                [Page 14]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


     - The FEC of last PW segment traversed.

###CP> Should this be "Generalized PWid" (to be inline with the title 
###CP> for FEC128 above)?
###CP>
       This is only applicable if the last PW segment traversed used LDP
       FEC 129 to signal the PW.

       The Attachment Identifier of the last PW segment traversed. This
       is coded in the following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AGI Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                    AGI  Value (contd.)                        ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AII Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                   SAII  Value (contd.)                        ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   AII Type    |    Length     |      Value                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                   TAII Value (contd.)                         ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - L2 PW address of PW Switching Point (recommended format).

   This sub-TLV type contains a L2 PW address of PW Switching Point in
   the format described in [RFC5003]. This includes the AII type field ,
   and length, as well as the L2 PW address.


7.4.2. Adaptation of Interface Parameters

   [RFC4447] defines several interface parameters, which are used by the
   Network Service Processing (NSP) to adapt the PW to the Attachment
   Circuit (AC). The interface parameters are only used at the end
   points, and MUST be passed unchanged across the PW switching point.
   However the following interface parameters MAY be modified as
   follows:

     - 0x03 Optional Interface Description string This Interface
       parameter MAY be modified, or altogether removed from the FEC
       element depending on local configuration policies.




Martini, et al.                                                [Page 15]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


     - 0x09 Fragmentation indicator This parameter MAY be inserted in
       the FEC by the switching point if it is capable of re-assembly of
       fragmented PW frames according to [PWE3-FRAG].

     - 0x0C VCCV parameter This Parameter contains the CC type , and CV
       type bit fields. The CV type bit field MUST be reset to reflect
       the CV type supported by the S-PE. CC type bit field MUST have
       bit 1 "Type 2: MPLS Router Alert Label " set to 0.  The other bit
       fields MUST be reset to reflect the CC type supported by the S-
       PE.

###CP> Does this mean that the end-to-end CC and CV Types are lost in 
###CP> the process? I mean, If an OAM message is sent with a PW Label 
###CP> with a sufficiently large TTL (> number of segments), as an 
###CP> end-to-end VCCV, then the sender needs to know the different CC 
###CP> Types (the different ways the disposition T-PE can intercept VCCV 
###CP> messages) and the different CV Types (i.e., the different OAM 
###CP> protocols that can be used end-to-end in the MS-PW).
###CP>
###CP> Instead of "MUST be reset to S-PE supported values", shouldn't 
###CP> the VCCV Parameter of the T-PE be transported unchanged, and the 
###CP> VCCV Parameters of the S-PEs be send in e.g., sub-TLVs in the 
###CP> switching poitn TLV?
###CP> 
###CP> At the S-PE, I agree CC Type 2 should be 0. But also should be CC 
###CP> Type of 1 (CW), right? Since the only intercepting / exception 
###CP> processing is TTL-Expiry (Type 3 only), right? If not, what am I 
###CP> missing?

7.5. Group ID

   The Group ID (GR ID) is used to reduce the number of status messages
   that need to be sent by the PE advertising the PW FEC. The GR ID has
   local significance only, and therefore MUST be mapped to a unique GR
   ID allocated by the PW switching point PE.


7.6. PW Loop Detection

   A switching point PE SHOULD check the OPTIONAL PW switching Point
   TLV, to verify if it's own IP address appears in it. If it's IP
   address appears in a received PW switching Point TLV, the PE SHOULD
   break the loop, and send a label release message with the following
   error code:
      Assignment E Description
      0x0000003A 0 "PW Loop Detected"

   [ note: error code pending IANA allocation ]


8. PW-MPLS to PW-L2TPv3 Control Plane Switching

   Both MPLS and L2TPv3 PWs may be static or dynamic. This results in
   four possibilities when switching between L2TPv3 and MPLS.

        -i. Switching between MPLS and L2TPv3 static control planes.
       -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW.
      -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW.
       -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW.


###CP> As far as control-plane interactions, there is no difference 
###CP> between "Static L2TPv3" and "Static MPLS", right?
###CP> So then Item iii. is really covered already as MPLS PWs dynamic 
###CP> <-> MPLS PW static. Ditto for item i., static L2TPv3 vs. static 
###CP> MPLS is the same from a control-plane to static MPLS vs. static 
###CP> MPLS. No?
###CP>
###CP> Also, in all these permutations, it should be mentioned that it's 
###CP> only considering 2-segment MS-PWs.






Martini, et al.                                                [Page 16]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


8.1. Static MPLS and L2TPv3 PWs

   In the case of two static control planes, the PW switching point MUST
   be configured to direct packets from one PW into the other. There is
   no control protocol involved in this case. The configuration MUST
   include which MPLS VC Label maps to which L2TPv3 Session ID (and

###CP>           ^^^^^^^^^^^^
###CP>           MPLS PW Label
###CP>
   associated Cookie, if present) as well as which MPLS Tunnel Label
   maps to which PE destination IP address.

###CP> This case should also consider the CW vs. L2SS mappings.

8.2. Static MPLS PW and Dynamic L2TPv3 PW

   When a statically configured MPLS PW is switched to a dynamic L2TPv3
   PW, the static control plane should be considered identical to an
   attachment circuit (AC) in the reference model of Figure 1. The
   switching point PE SHOULD signal the proper PW status if it detects a
   failure in sending or receiving packets over the static PW. Because
   the PW is statically configured, the status communicated to the
   dynamic L2TPv3 PW will be limited to local interface failures. In
   this case, the PW switching point PE behaves in a very similar manner
   to a T-PE, assuming an active role.

###CP> Same comment as before, what if communicating status for static 
###CP> PWs with BFD Diags?
###CP> 

8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW

   When a statically configured L2TPv3 PW is switched to a dynamic
   LDP/MPLS PW, then the static control plane should be considered
   identical to an attachment circuit (AC) in the reference model of
   Figure 1. The switching point PE SHOULD signal the proper PW status
   (via an L2TPv3 SLI message) if it detects a failure in sending or
   receiving packets over the static PW.  Because the PW is statically
   configured, the status communicated to the dynamic LDP/MPLS PW will
   be limited to local interface failures. In this case, the PW
   switching point PE behaves in a very similar manner to a T-PE,
   assuming an active role.

###CP> Same comment as before, what if communicating status for static 
###CP> PWs with BFD Diags?
###CP> 


8.4. Dynamic LDP/MPLS and L2TPv3 PWs

   When switching between dynamic PWs, the switching point always
   assumes an initial passive role. Thus, it does not initiate an
   LDP/MPLS or L2TPv3 PW until it has received a connection request
   (Label Mapping or ICRQ) from one side of the node. Note that while
   MPLS PWs are made up of two unidirectional LSPs bonded together by
   FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a
   3-message exchange (ICRQ, ICRP and ICCN). Details of Session
   Establishment, Tear Down, and PW Status signaling are detailed below.




Martini, et al.                                                [Page 17]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


8.4.1. Session Establishment

   When the PW switching point receives an L2TPv3 ICRQ message, the
   identifying AVPs included in the message are mapped to FEC

###CP> What are the "identifying AVPs"? This is not defined and can be a 
###CP> bit confusing.
###CP>
   identifiers and sent in an LDP label mapping message. Conversely, if
   an LDP Label Mapping message is received, it is either mapped to an
   ICRP message or causes an L2TPv3 session to be initiated by sending
   an ICRQ.

###CP> This is a bit of a big comment, centered on two specific issues 
###CP> for this case:
###CP>
###CP> 1. Control plane "PW Identifiers"
###CP>      o MPLS Supports FEC 128 and FEC 129
###CP>      o L2TPv3 supports:
###CP>          * Remote Session ID AVP RFC3931 (equivalent to FEC 128) 
###CP>          * AGI AVP + Local ENd ID AVP [RFC4667] (~ FEC 129)
###CP>
###CP>      So, "FEC Type" considerations might need to the MPLS <-> 
###CP>      MPLS case might need to be considered. Or at least, the 2 
###CP>      pairs of PW Identifiers should need to be listed.
###CP>
###CP> 2. PW Types
###CP>      MPLS and L2TPv3 support different PW Type spaces (in fact 
###CP>      the PW Type is 1 bit smaller for MPLS):
###CP>
###CP>      * MPLS - "MPLS Pseudowire Types Registry" at 
###CP>      http://www.iana.org/assignments/pwe3-parameters
###CP>      * L2TPv3 - "L2TPv3 Pseudowire Types" at 
###CP>      http://www.iana.org/assignments/l2tp-parameters
###CP>
###CP>      And while there are many similarities, there are notable 
###CP>      differences. For example, a couple of the differences:
###CP>      o ATM - L2TPv3 supports a subset of the MPLS ATM Tytes
###CP>      o FR - L2TPv3 does nto have pre- post- Martini Types, and 
###CP>      supports a different encapsulation (it actually transports 
###CP>      the Q.922 header, while MPLS does not)
###CP>      o Cable - L2TPv3 supports 3 Cable PW Types that MPLS does 
###CP>      not.
###CP>      o MPLS supports FR Port mode, L2TPv3 uses HDLC.
###CP>      o MPLS supports more PW Types.
###CP>
###CP>      So I think that this document would need to provide a matrix 
###CP>      of acceptable "equivalent" PW Types. I can help with that if 
###CP>      needed.
###CP>
###CP>


   Following are two example exchanges of messages between LDP and
   L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW,
   the second is a case where an MPLS T-PE initiates an MS-PW.

      PE 1 (L2TPv3)      PW Switching Node       PE3 (MPLS/LDP)

        AC "Up"
        L2TPv3 ICRQ --->
                         LDP Label Mapping  --->
                                                    AC "UP"
                                           <--- LDP Label Mapping
                   <--- L2TPv3 ICRP
        L2TPv3 ICCN  --->
      <-------------------- MH PW Established ------------------>


      PE 1 (MPLS/LDP)      PW Switching Node       PE3 (L2TPv3)

        AC "Up"
        LDP Label Mapping --->
                              L2TPv3 ICRQ  --->
                                              <--- L2TPv3 ICRP
                         <--- LDP Label Mapping
                              L2TPv3 ICCN --->

###CP> Strictly, I think that the ICCN should come before the Label 
###CP> Mapping above.
###CP>
                                                    AC "Up"
      <-------------------- MH PW Established ------------------>


8.4.2. Adaptation of PW Status message

   L2TPv3 uses the SLI message to indicate a interface status change
   (such as the interface transitioning from "Up" or "Down"). MPLS/LDP
   PWs either signal this via an LDP Label Withdraw or the PW Status
   Notification message defined in section 4.4 of [RFC4447].



###CP> You may want to also point to 
###CP> draft-ietf-l2tpext-circuit-status-extensions that extends the 
###CP> status signalign with SLI.




Martini, et al.                                                [Page 18]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


8.4.3. Session Tear Down

   L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN
   message translates to a Label Withdraw message in LDP. Following are
   two example exchanges of messages between LDP and L2TPv3. The first
   is a case where an L2TPv3 T-PE initiates the termination of an MS-PW,
   the second is a case where an MPLS T-PE initiates the termination of
   an MS-PW.

   PE 1 (L2TPv3)      PW Switching Node       PE3 (MPLS/LDP)

   AC "Down"
     L2TPv3 CDN --->
                      LDP Label Withdraw  --->
                                                 AC "Down"
                                      <-- LDP Label Release

   <--------------- MH PW Data Path Down ------------------>



   PE 1 (MPLS LDP)     PW Switching Node       PE3 (L2TPv3)

   AC "Down"
   LDP Label Withdraw  --->
                           L2TPv3 CDN -->
                       <-- LDP Label Release

###CP> The Label Release should come before the CDN strictly, right? 
###CP>
                                                 AC "Down"

   <---------------- MH PW Data Path Down ------------------>


8.5. Adaptation of L2TPv3 AVPs to Interface Parameters

###CP> Add "sub-TLV" to Int-param
###CP>
###CP> 
   [RFC4447] defines several interface parameters which MUST be mapped
   to the equivalent AVPs in L2TPv3 setup messages.

     * Interface MTU

       The Interface MTU parameter is mapped directly to the L2TP
       Interface MTU AVP defined in [RFC4667]

     * Max Number of Concatenated ATM cells

       This interface parameter is mapped directly to the L2TP "ATM
       Maximum Concatenated Cells AVP" described in section 6 of
       [RFC4454].

###CP> The "Frame Relay Header Length Sub-TLV" Interface-parameter needs 
###CP> mapping as well. And all the TDM related ones.



Martini, et al.                                                [Page 19]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


     * Optional Interface Description String

       This string may be carried as the "Call-Information AVP"
       described in section 2.2 of [L2TP-INFOMSG]

###CP> This is section 2 of 
###CP> <http://tools.ietf.org/html/draft-ietf-l2tpext-radius-ext-nas-port-02>, 
###CP> see References comment
###CP>
     * PW Type

       The PW Type defined in [RFC4446] is mapped to the L2TPv3 "PW
       Type" AVP defined in [L2TPv3].

###CP> These do not really map, please see comment above.
###CP>
     * PW ID (FEC 128)

       For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote
       End ID" AVP defined in [L2TPv3].

     * Generalized FEC 129 SAI/TAI

       Section 4.3 of [RFC4667] defines how to encode the SAI and TAI
       parameters. These can be mapped directly.

###CP> Regarding FEC 128 and FEC 129, do they really need to be "mapped 
###CP> directly" onto each other? Shouldn't each segment be allowed to 
###CP> pick whichever value? For FEC 128 for example, what if the S-PE 
###CP> is also terminating SS-PWs using that value already?
###CP>

   Other interface parameter mappings will either be defined in a future
   version of this document, or are unsupported when switching between
   LDP/MPLS and L2TPv3 PWs.


8.6. Switching Point TLV in L2TPv3

   When translating between LDP and L2TPv3 control messages, the PW
   Switching Point TLV described earlier in this document is carried in
   a single variable length L2TP AVP present in the ICRQ, ICRP messages,
   and optionally in the ICCN message.

   The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The
   AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of
   the AVP is 6 plus the length of the series of Switching Point sub-
   TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory
   (the L2TP AVP M-bit MUST be 0).


8.7. L2TPv3 and MPLS PW Data Plane

   When switching between an MPLS and L2TP PW, packets are sent in their
   entirety from one PW to the other, replacing the MPLS label stack
   with the L2TPv3 and IP header or vice versa. There are some
   situations where an additional amount of interworking must be
   provided between the two data planes at the PW switching node.





Martini, et al.                                                [Page 20]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


8.7.1. PWE3 Payload Convergence and Sequencing

   Section 5.4 of [PWE3-ARCH] discusses the purpose of the various shim
   headers necessary for enabling a pseudowire over an IP or MPLS PSN.
   For L2TPv3, the Payload Convergence and Sequencing function is
   carried out via the Default L2-Specific Sublayer defined in [L2TPv3].
   For MPLS, these two functions (together with PSN Convergence) are
   carried out via the MPLS Control Word. Since these functions are
   different between MPLS and L2TPv3, interworking between the two may
   be necessary.

   The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers
   which in some cases are not necessary to be present at all. For
   example, an Ethernet PW with sequencing disabled will generally not
   require an MPLS Control Word or L2TP Default L2-Specific Sublayer to
   be present at all. In this case, Ethernet frames are simply sent from
   one PW to the other without any modification beyond the MPLS and
   L2TP/IP encapsulation and decapsulation.

   The following section offers guidelines for how to interwork between
   L2TP and MPLS for those cases where the Payload Convergence,
   Sequencing, or PSN Convergence functions are necessary on one or both
   sides of the switching node.

###CP> This is very well explained. But there are also cases in which 
###CP> the payload needs to be adapted, or not allowed. One such 
###CP> examples is FR DLCI PWs, in L2TPv3 the Q.922 header (DLCI, 
###CP> FECN/BECN) is transported entirely, but in MPLS is stripped and 
###CP> removed.


8.7.2. Mapping

   The MPLS Control Word consists of (from left to right):

        -i. These bits are always zero in MPLS are not necessary to be
            mapped to L2TP.

       -ii. These six bits may be used for Payload Convergence depending
            on the PW type. For ATM, the first four of these bits are
            defined in [RFC4717]. These map directly to the bits defined
            in [RFC4454]. For Frame Relay, these bits indicate how to
            set the bits in the Frame Relay header which must be
            regenerated for L2TP as it carries the Frame Relay header
            intact.

###CP> Sorry this is mentioned here (I expected it before), but it goes 
###CP> beyond CW adaptation since chagnes payload.

      -iii. L2TP determines its payload length from IP. Thus, this
            Length field need not be carried directly to L2TP. This
            Length field will have to be calculated and inserted for
            MPLS when necessary.







Martini, et al.                                                [Page 21]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


       -iv. The Default L2-Specific Sublayer has a sequence number with
            different semantics than that of the MPLS Control Word. This
            difference eliminates the possibility of supporting
            sequencing across the MS-PW by simply carrying the sequence
            number through the switching point transparently. As such,
            sequence numbers MAY be supported by checking the sequence
            numbers of packets arriving at the switching point and
            regenerating a new sequence number in the proper format for
            the PW on egress. If this type of sequence interworking at
            the switching node is not supported, and a T-PE requests
            sequencing of all packets via the L2TP control channel
            during session setup, the switching node SHOULD NOT allow
            the session to be established by sending a CDN message with
            Result Code set to 17 "sequencing not supported" (subject to
            IANA Assignment).


###CP> Sequencing "interworking" in the control plane is also more 
###CP> complex, because L2TPv3 allows three different levels of 
###CP> sequencing: 1. All packets, 2. No packets, 3. Only non-IP 
###CP> packets. MPLS OTOH only supports 1. and 2.
###CP> This needs to be mentioned as well.
###CP> However, brings another question: If the sequencing interworking 
###CP> is not supported, how is the MPLS segment tore down?
###CP>


9. Operation And Management

9.1. Extensions to VCCV to Support Switched PWs
                                   ^^^^^^^^^^^^^
MB> 9.1 Extensiond to VCCV so Support MS-PWs

   Single-hop pseudowires are signaled using the Virtual Circuit
   Connectivity Verification (VCCV) parameter included in the interface
   parameter field of the PW ID FEC TLV or the sub-TLV interface
   parameter of the Generalized PW ID FEC TLV as described in [RFC5085].
   When a switching point exist between PE nodes, it is required to be
   able to continue operating VCCV end-to-end across a switching point
   and to provide the ability to trace the path of the MS-PW over any
   number of segments.

   This document provides a method for achieving these two objectives.
   This method is based on re-using the existing VCCV CW and
   decrementing the TTL of the PW label at each hop in the path of the
   MS-PW.

###CP> This last statement implies that the only CC Type supported by 
###CP> S-PEs is TTL-Expiration, and should signal that, correct? We 
###CP> don't want the S-PE be sniffing the CW for 0001b, etc. So the 
###CP> only S-PE CV Type is TTL-Exp.
###CP> :wq


9.2. PW-MPLS to PW-MPLS OAM Data Plane Indication

   As stated above the S-PE MUST perform a standard MPLS label swap
   operation on the MPLS PW label. By the rules defined in [RFC3032] the
   PW label TTL MUST be decreased at every S-PE. Once the PW label TTL
   reaches the value of 0, the packet is sent to the control plane to be
   processed. Hence, by controlling the PW TTL value of the PW label it
   is possible to select exactly which hop will respond to the VCCV
   packet.

MV> Hence, by controlling the TTL value of the PW label it
   is possible to select exactly which PE will process the VCCV
   packet.

###CP> "And therefore, at signaling (if needed, otherwise can be only 
###CP> implied with MS-PW support), CC Type 3 (TTL-Expiry) is the only 
###CP> exception processign for OAM at S-PEs.
###CP> And consequently, the CC and CV Types from T-PE need to be 
###CP> transported transparently."




Martini, et al.                                                [Page 22]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


9.3. Signaling OAM Capabilities for Switched Pseudowires

   Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV
   parameter included in the interface parameter field of the PW ID FEC
   TLV or the sub-TLV interface parameter of the Generalized PW ID FEC
   TLV as described in [RFC5085].

   In Figure 3 T-PE1 uses the VCCV parameter included in the interface
   parameter field of the PW ID FEC TLV or the sub-TLV interface
   parameter of the Generalized PW ID FEC TLV to indicate to the far end
   T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV
   parameter as would be used if T-PE1 and T-PE2 were connected
   directly.
   
###CP> The next comment applies to the text from this point onwards.

   S-PE2, which is a PW switching point, as part of the
   adaptation function for interface parameters, processes locally the
   VCCV parameter then passes it to T-PE2. If there were multiple S-PEs
   on the path between T-PE1 and T-PE2, each would carry out the same
   processing, passing along the VCCV parameter. The local processing of
   the VCCV parameter removes CC Types specified by the originating T-PE
   that are not supported on the S-PE. For example, if T-PE1 indicates
   supports CC Types 1,2,3 and the Then the S-PE removes the Router
   Alert CC Type=2, leaving the rest of the TLV unchanged, and passes
   the modified VCCV parameter to the next S-PE along the path.

   The far end T-PE (T-PE2) receives the VCCV parameter indicating only
   the CC types that are supported by the initial T-PE (T-PE1) and all
   S-PEs along the PW path.


###CP> I don't think that this is the correct approach. For end-to-end 
###CP> VCCV, it doesn't matter which CC Types are supported by the S-PEs 
###CP> along the way. A T-PE can chose to perform end-to-end VCCV, or 
###CP> segment VCCV, and for end-to-end, if both T-PEs support CW (CC 
###CP> Type 1), then why couldn't they use it?
###CP> Note that for example, a BFD session end-to-end does not make 
###CP> sense to be intercepted in the segment, as it uses state stored 
###CP> at the T-PEs. It's end-to-end only. LSP Ping makes more sense 
###CP> hop-by-hop, and that is controlled with the PW Label TTL.
###CP> Additionally, I do not think it makes sense for an S-PE to 
###CP> support CC Type 1 (CW with 0001b), because we don't want the S-PE  
###CP> sniffing inside past the PW Label. With the current text, that 
###CP> would prevent Type 1 end-to-end (by the T-PE purposely setting 
###CP> the PW Label TTL very high).
###CP>
###CP> Finally, this text does not mention what to do with CV Types.

9.4. OAM Capability for MS-PWs Demultiplexed using MPLS

###CP>                         ^^^^^^^^^^^^^^^^^^^^^^^^
###CP>                         I think this is the correct way instead 
###CP>                         of some uses of "PSN" in the initial part 
###CP>                         of the document.

   The VCCV parameter ID is defined as follows in [RFC4446]:

        Parameter ID   Length     Description
          0x0c           4           VCCV


   The format of the VCCV parameter field is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0x0c     |       0x04    |   CC Types    |   CV Types    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          0x01 Type 1: PWE3 control word with 0001b as first nibble
                       as defined in [RFC4385].
          0x02 Type 2: MPLS Router Alert Label.
          0x04 Type 3: MPLS PW De-multiplexor Label TTL = 1 (Type 3).



Martini, et al.                                                [Page 23]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


9.4.1. MS-PW and VCCV CC Type 1

   VCCV CC type 1 can be used for MS-PWs. However, if the CW is enabled
   on user packets, VCCV CC type 1 MUST be used according to the rules
   in [RFC5085].  When using CC type 1 for MS-PWs the PE transmitting
   the VCCV packet MUST set the TTL to the appropriate value to reach
   the destination S-PE. However if the packet is destined for the T-PE,
   the TTL can be set to any value that is sufficient for the packet to
   reach the T-PE.

###CP> Do we want Type 1 at S-PEs?
###CP>
###CP> Note also that using the CC Type intersection of all T-PEs and 
###CP> all S-PEs along the way is extremely restrictive and can result 
###CP> in support holes.

9.4.2. MS-PW and VCCV CC type 2

   VCCV CC type 2 is not supported for MS-PWs and MUST be removed form a
   VCCV parameter field by the S-PE.

###CP> What if the T-PEs support Type 2 and want to run it between them 
###CP> only? (this is continuation of the commend above).

9.4.3. MS-PW and VCCV CC type 3

   VCCV CC type 3 can be used for MS-PWs, however if the CW is enabled
   VCCV type 1 is preferred according to the rules in [RFC5085]. Note
   that for using the VCCV type 3, TTL method, the PE will set the PW
   label TTL to the appropriate value necessary to reach the target PE,
   otherwise the VCCV packet might be forwarded over the AC to the CPE.


9.5. MS-PW VCCV Operations

###CP> This is a comment that applies to all this section 9.5.X. This 
###CP> section talks about the "VCCV Echo" message, the "VCCV FEC", etc.  
###CP> throughout. I believe it's referring to LSP Ping Echo, LSP Ping 
###CP> FEC TLV, etc. That is, VCCV supports ICMP Ping, MPLS Ping, 
###CP> various BFD modes.  THis section concentrates on MPLS Ping CV 
###CP> Type, and that should be explained.
###CP>
###CP>
   This document specifies four VCCV operations:
        -i. End-to-end MS-PW connectivity verification. This operation

###CP> So this mode of end-to-end MS-PW VCCV is explicitly allowed.  
###CP> Therefore, the VCCV int-parameter should be transported 
###CP> end-to-end without clearing bits.

            enables the connectivity of the MS-PW to be tested from
            source T-PE to destination T-PE.  In order to do this, the
            sending T-PE must include the FEC used in the last segment
            of the MS-PW to the destination T-PE in the VCCV-Ping echo
            request.  This information is either configured at the
            sending T-PE or is obtained by processing the corresponding
            sub-TLVs of the optional PW switching point TLV, as
            described below.
       -ii. Partial MS-PW connectivity verification. This operation
            enables the connectivity of any contiguous subset of the
            segments of a MS-PW to be tested from the source T-PE or a
            source S-PE to a destination S-PE or T-PE.  Again, the FEC
            used on the last segment to be tested must be included in
            the VCCV-Ping echo request message. This information is
            determined by the sending T-PE or S-PE as in (i) above.






Martini, et al.                                                [Page 24]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


      -iii. MS-PW path verification. This operation verifies the path of
            the MS-PW, as returned by the PW switching point TLV,
            against the actual data path of the MS-PW. The sending T-PE
            or S-PE iteratively sends a VCCV echo request to each S-PE
            along the MS-PW path, using the FEC for the corresponding
            MS-PW segment in the switching point TLV. If the PW
            switching point TLV information is correct, then a VCCV echo
            reply showing that this is a valid router for the FEC will
            be received. However, if the switching point TLV information
            is incorrect, then this operation enables the first
            incorrect switching point to be determined, but not the
            actual path of the MS-PW beyond that. This operation cannot
            be used when the MS-PW is statically configured or when the
            S-PE TLV is not suported. The processing of the PW switching
            TLV used for this operation is described below. This
            operation is OPTIONAL.
       -iv. MS-PW path trace. This operation traces the data path of the
            MS-PW using FECs included in the Target FEC stack TLV
            [RFC4379] returned by S-PEs or T-PEs in an echo reply
            message. The sending T-PE or S-PE uses this information to
            recursively test each S-PE along the path of the MS-PW in a
            single operation in a similar manner to LSP trace. This
            operation is able to determine the actual data path of the
            MS-PW, and can be used for both statically configured and
            signaled MS-PWs. Support for this operation is OPTIONAL.

   Note that the above operations rely on intermediate S-PEs and/or the
   destination T-PE to include the switching point TLV as a part of the
   MS-PW setup process, or to include the Target FEC stack TLV in the
   VCCV echo reply message. For various reasons, e.g. privacy or
   security of the S-PE/T-PE, this information may not be available to
   the source T-PE. In these cases, manual configuration of the FEC MAY
   still be used.


9.5.1. VCCV Echo Message Processing

   The challenge for the control plane is to be able to build the VCCV
   echo request packet with the necessary information to reach the
   desired S-PE or T-PE, for example the target FEC 128 PW sub-TLV of
   the downstream PW segment that the packet is destined for. This could
   be even more difficult in situations in which the MS-PW spans
   different providers and Autonomous Systems.

   For example, in Figure 3, T-PE1 has the FEC128 of the segment, PW1,
   but it does not readily have the information required to compose the
   FEC128 of the following segment, PW3, if a VCCV echo request to be
   sent to T-PE2. This can be achieved by the methods described in the



Martini, et al.                                                [Page 25]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   following subsections.


9.5.1.1. Sending a VCCV Echo Request

   When performing a partial or end-to-end connectivity or path
   verification, the sender of the echo request message requires the FEC
   of the last segment to the target S-PE/T-PE node. This information
   can either be configured manually or be obtained by inspecting  the
   corresponding sub-TLV's of the PW switching point TLV.

   The necessary S-PE sub-TLVs are :

   Type Description
   0x01 PW ID of last PW segment traversed
   0x03 Local IP address of PW Switching Point
   0x04 Remote IP address of last PW Switching Point traversed or
        of the T-PE


   When performing an OPTIONAL MS-PW path trace operation, the T-PE will
   automatically learn the target FEC by probing, one by one, the hops
   of the MS-PW path, using the FEC returned in the Target FEC stack of
   the previous VCCV echo reply.


9.5.1.2. Receiving a VCCV Echo Request

   Upon receiving a VCCV echo request the control plane on S-PEs (or the
   target node of each segment of the MS-PW) validates the request and
   responds to the request with an echo reply consisting of a return
   code of 8 (label switched at stack-depth) indicating that it is an
   S-PE and not the egress router for the MS-PW.

   S-PEs that wish to reveal their downstream next-hop in a trace
   operation should include the FEC of the downstream PW segment in the
   Target FEC stack (as per Sections 3.2 and 4.5 of [RFC4379]) of the
   echo reply message. FEC128 PWs MUST use the format shown in Section
   3.2.09 of [RFC4379] for the sub-TLV in the Target FEC stack, while
   FEC129 PWs MUST use the format shown in Section 3.2.10 of [RFC4379]
   for the sub-TLV in the Target FEC stack.  Note that an S-PE  MUST NOT
   include this FEC information in the reply if it has been configured
   not to do so for administrative reasons, for reasons  explained
   previously.

   If the node is the T-PE or the egress node of the MS-PW, it responds
   to the echo request with an echo reply with a return code of 3
   (egress router).



Martini, et al.                                                [Page 26]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


9.5.1.3. Receiving a VCCV Echo Reply

   The operation to be taken by the node receiving the echo reply in
   response to an echo request depends on the VCCV mode of operation
   described above.  See Section 9.5.2 for detailed procedures.


9.5.2. Detailed VCCV procedures

9.5.2.1. End to End Connectivity Verification Between T-PEs

   In Figure 3, if T-PE1, S-PE and T-PE2 support Control Word , the PW
   control plane will automatically negotiate the use of the CW. VCCV CC
   type 3 will function correctly whether the CW is enable or not on the
   PW. However VCCV type 1 for (which can be use for end to end
   verification only), is only supported if the CW is enabled.

   At the S-PE the data path operations include an outer label pop,
   inner label swap and new outer label push. Note that there is no
   requirement for the S-PE to inspect the CW. Thus, the end-to-end
   connectivity of the multi-segment pseudowire can be verified by
   performing all of the following steps:
        -i. T-PE forms a VCCV-ping echo request message with the FEC
            matching that of the last segment PW to the destination T-
            PE.

       -ii. T-PE sets the inner PW label TTL to the exact value to allow
            the packet to reach the far end T-PE. ( the value is
            determined by counting the number of S-PEs from the control
            plane information ) Alternatively, if CC type 1 is supported
            the packet can be encapsulated according to CC type 1 in
            [RFC5085]

      -iii. T-PE sends a VCCV packet that will follow the exact same
            data path at each S-PE as that taken by data packets.

       -iv. S-PE may performs an outer label pop, if PHP is disabled,
            and will perform an inner label swap with TTL decrement, and
            new outer label push.

        -v. There is no requirement for the S-PE to inspect the CW.

       -vi. The VCCV packet is diverted to VCCV control processing at
            the destination T-PE.







Martini, et al.                                                [Page 27]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


      -vii. Destination T-PE replies using the specified reply mode,
            i.e., reverse PW path or IP path.


9.5.2.2. Partial Connectivity Verification from T-PE

   In order to trace part of the multi-segment pseudowire, the TTL of
   the PW label may be used to force the VCCV message to 'pop out' at an
   intermediate node. When the TTL expires, the S-PE can determine that
   the packet is a VCCV packet by either checking the control word (CW)
   , or if the CW is not in use by checking for a valid IP header with
   UDP destination port 3503.  The packet should then be diverted to
   VCCV processing.

   In Figure 3, if T-PE1 sends a VCCV message with the TTL of the PW
   label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus
   verify the first segment of the pseudowire.

   The VCCV packet is built according to [RFC4379] section 3.2.9 for FEC
   128, or 3.2.10 for a FEC 129 PW. All the information necessary to
   build the VCCV LSP ping packet is collected by inspecting the S-PE
   TLVs.

   Note that this use of the TTL is subject to the caution expressed in
   [RFC5085]. If a penultimate LSR between S-PEs or between an S-PE and
   a T-PE manipulates the PW label TTL, the VCCV message may not emerge
   from the MS-PW at the correct S-PE.


9.5.2.3. Partial connectivity verification between S-PEs

   Assuming that all nodes along an MS-PW support the Control Word CC
   Type 3, VCCV between S-PEs may be accomplished using the PW label TTL
   as described above. In Figure 3, the S-PE may verify the path between
   it and T-PE2 by sending a VCCV message with the PW label TTL set to
   1. Given a more complex network with multiple S-PEs, an S-PE may
   verify the connectivity between it and an S-PE two segments away by
   sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE
   can diagnose connectivity problems by successively increasing the
   TTL.  All the information needed to build the proper VCCV echo
   request packet as described in [RFC4379] section 3.2.9 or 3.2.10 is
   obtained automatically from the LDP label mapping that contains S-PE
   TLVs.








Martini, et al.                                                [Page 28]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


9.5.2.4. MS-PW Path Verification

   As an example, in Figure 3, VCCV trace can be performed on the MS-PW
   originating from T-PE1 by a single operational command. The following
   process ensues:
        -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC
            containing the pseudowire information of the first segment
            (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC
            Stack Validation is enabled, the request may also include
            additional sub-TLV such as LDP Prefix and/or RSVP LSP
            dependent on the type of transport tunnel the segmented PW
            is riding on.

       -ii. S-PE validates the echo request with the FEC. Since it is a
            switching point between the first and second segment it
            builds an echo reply with a return code of 8 and sends the
            echo reply back to T-PE1.

      -iii. T-PE1 builds a second VCCV echo request based on the
            infomation obtained from the control plane (S-PE TLV). It
            then increments the TTL and sends it out to T-PE2. Note that
            the VCCV echo request packet is switched at the S-PE
            datapath and forwarded to the next downstream segment
            without any involvement from the control plane.

       -iv. T-PE2 receives and validates the echo request with the FEC.
            Since T-PE2 is the destination node or the egress node of
            the MS-PW it replies to T-PE1 with an echo reply with a
            return code of 3 (Egress Router).

        -v. T-PE1 receives the echo reply from T-PE2. T-PE1 is made
            aware that T-PE2 is the destination of the MS-PW because the
            echo reply has a return code of is 3. The trace process is
            completed.

   If no echo reply is received, or an error code is received from a
   particular PE, the trace process MUST stop immediately, and no
   packets MUST be sent further along the MS-PW.

   For more detail on the format of the VCCV echo packet, refer to
   [RFC5085] and [RFC4379]. The TTL here refers to that of the inner
   (PW) label TTL.









Martini, et al.                                                [Page 29]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


9.5.2.5. MS-PW Path Trace

   As an example, in Figure 3, VCCV trace can be performed on the MS-PW
   originating from T-PE1 by a single operational command. The following
   process ensues:
        -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC
            containing the pseudowire information of the first segment
            (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC
            Stack Validation is enabled, the request may also include
            additional sub-TLV such as LDP Prefix and/or RSVP LSP
            dependent on the type of transport tunnel the segmented PW
            is riding on.

       -ii. The S-PE validates the echo request with the FEC.

      -iii. The S-PE builds an echo reply with a return code of 8 and
            sends the echo reply back to T-PE1, appending the FEC128
            information for the next segment along the MS-PW to the VCCV
            echo reply packet using the Target FEC stack TLV (as per
            Sections 3.2 and 4.5 of [RFC4379]).

       -iv. T-PE1 builds a second VCCV echo request based on the
            infomation obtained from the FEC stack TLV received in the
            previous VCCV echo reply. It then increments the TTL and
            sends it out to T-PE2. Note that the VCCV echo request
            packet is switched at the S-PE datapath and forwarded to the
            next downstream segment without any involvement from the
            control plane.

        -v. T-PE2 receives and validates the echo request with the FEC.
            Since T-PE2 is the destination node or the egress node of
            the MS-PW it replies to T-PE1 with an echo reply with a
            return code of 3 (Egress Router).

       -vi. T-PE1 receives the echo reply from T-PE2. T-PE1 is made
            aware that T-PE2 is the destination of the MS-PW because the
            echo reply has a return code of is 3. The trace process is
            completed.

   If no echo reply is received, or an error code is received from a
   particular PE, the trace process MUST stop immediately, and no
   packets MUST be sent further along the MS-PW.

   For more detail on the format of the VCCV echo packet, refer to
   [RFC5085] and [RFC4379]. The TTL here refers to that of the inner
   (PW) label TTL.





Martini, et al.                                                [Page 30]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


10. Mapping Switched Pseudowire Status

###CP> For this Section, should you include/point to 
###CP> draft-ietf-l2tpext-circuit-status-extensions for L2TPv3? That 
###CP> basically allows for all the descriptions to apply to both LDP 
###CP> and L2TPv3 signaling.

   In the PW switching with attachment circuits case (Figure 2), PW
   status messages indicating PW or attachment circuit faults SHOULD be
   mapped to fault indications or OAM messages on the connecting AC as
   defined in [PW-MSG-MAP]. If the AC connecting two PWs crosses an
   administrative boundary, then the manner in which those OAM messages
   are treated at the boundary is out of scope of this draft.

   In the PW control plane switching case (Figure 3), there is no
   attachment circuit at the PW switching point, but the two PWs are
   connected together.  Similarly, the status of the PWs are forwarded
   unchanged from one PW to the other by the control plane switching
   function. However, it may sometimes be necessary to communicate fault
   status of one of the locally attached SS-PW at a PW switching point.
   For LDP this can be accomplished by sending an LDP notification
   message containing the PW status TLV, as well as an OPTIONAL PW
   switching point TLV as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification   (0x0001)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Message ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1| Status (0x0300)           |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1|                 Status Code=0x00000028                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID=0                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Message Type=0           |      PW Status TLV            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PW Status TLV                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PW Status TLV         |            PWId FEC           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                 PWId FEC or Generalized ID FEC                |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|     PW sw TLV  (0x096D)   |     PW sw TLV  Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Variable Length Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Martini, et al.                                                [Page 31]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   Only one PW switching point TLV can be present in this message. This
   message is then relayed by each PW switching point unchanged. The T-
   PE decodes the status message and the included PW switching point TLV
   to detect exactly where the fault occurred. At the T-PE if there is
   no PW switching point TLV included in the LDP status notification
   then the status message can be assumed to have originated at the
   remote T-PE.

   The merging of the received LDP status and the local status for the
   PW segments at an S-PE can be summarized as follows:

        -i. When the local status for both PW segments is UP, the S-PE
            passes any received AC or PW status bits unchanged, i.e.,
            the status notification TLV is unchanged but the PWid in the
            case of a FEC 128 TLV is set to the value of the PW segment
            of the next hop.

       -ii. When the local status for any of the PW segments is at
            fault, the S-PE always sends the local status bits
            regardless if the received status bits from the remote node
            indicated that an upstream fault has cleared. AC status bit
            are passed along unchanged.


10.1. S-PE initiated PW status messages

   The PW fault directions are defined as follows:

                         +-------+
      ---PW1 receive---->|       |-----PW2 Transmit---->
   S-PE1                 | S-PE2 |                   S-PE3
      <--PW1 Transmit----|       |<----PW2 Receive------
                         +-------+


   When a local fault is detected by the S-PE, a PW status message is
   sent in both directions along the PW. Since there are no attachment
   circuits on an S-PE, only the following status messages are relevant:

      0x00000008 - Local PSN-facing PW (ingress) Receive Fault
      0x00000010 - Local PSN-facing PW (egress) Transmit Fault


   Each S-PE needs to store only two 32-bit PW status words for each
   SS-PW: One for local failures , and one for remote failures (normally
   received from another PE). The first failure will set the appropriate
   bit in the 32-bit status word, and each subsequent failure will be
   ORed to the appropriate PW status word. In the case of the PW status



Martini, et al.                                                [Page 32]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   word storing remote failures, this rule has the effect of a logical
   OR operation with the first failure received on the particular SS-PW.

   It should be noted that remote failures received on an S-PE are just
   passed along the MS-PW unchanged while local failures detected an an
   S-PE are signalled on both SS-PWs.

   A T-PE can receive multiple failures from S-PEs along the MH-PW,
   however only the failure from the remote closest S-PE will be stored
   (last pw status message received). The PW status word received are
   just ORed to any existing remote PW status already stored on the T-
   PE.

   Given that there are two SS-PW at a particular S-PE for a particular
   MH-PW, there are for possible failure cases as follows:

        -i. PW2 Transmit direction fault
       -ii. PW1 Transmit direction fault
      -iii. PW2 Receive direction fault
       -iv. PW1 Receive direction fault

   Once a PW status notification message is initiated at a PW switching
   point for a particular PW status bit any further status message, for
   the same status bit, received from an upstream neighbor is processed
   locally and not forwarded until the PW switching point original
   status error state is cleared.

   Each S-PE along the MS-PW MUST store any PW status messages
   transiting it.  If more then one status message with the same PW
   status bit set is received by a T-PE, or S-PE  only the last PW
   status message is stored.


10.1.1. Local PW2 transmit direction fault

   When this failure occurs the S-PE will take the following actions:

     * Send a PW status message to S-PE3 containing "0x00000010 - Local
       PSN-facing PW (egress) Transmit Fault"
     * Send a PW status message to S-PE1 containing "0x00000008 - Local
       PSN-facing PW (ingress) Receive Fault"
     * Store 0x00000010 in the local PW status word for the SS-PW toward
       S-PE3.








Martini, et al.                                                [Page 33]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


10.1.2. Local PW1 transmit direction fault

   When this failure occurs the S-PE will take the following actions:

     * Send a PW status message to S-PE1 containing "0x00000010 - Local
       PSN-facing PW (egress) Transmit Fault"
     * Send a PW status message to S-PE3 containing "0x00000008 - Local
       PSN-facing PW (ingress) Receive Fault"
     * Store 0x00000010 in the local PW status word for the SS-PW toward
       S-PE1.


10.1.3. Local PW2 receive direction fault

   When this failure occurs the S-PE will take the following actions:
     * Send a PW status message to S-PE3 containing "0x00000008 - Local
       PSN-facing PW (ingress) Receive Fault"
     * Send a PW status message to S-PE1 containing "0x00000010 - Local
       PSN-facing PW (egress) Transmit Fault"
     * Store 0x00000008 in the local PW status word for the SS-PW toward
       S-PE3.


10.1.4. Local PW1 receive direction fault

   When this failure occurs the S-PE will take the following actions:
     * Send a PW status message to S-PE1 containing "0x00000008 - Local
       PSN-facing PW (ingress) Receive Fault"
     * Send a PW status message to S-PE3 containing "0x00000010 - Local
       PSN-facing PW (egress) Transmit Fault"
     * Store 0x00000008 in the local PW status word for the SS-PW toward
       S-PE1.


10.1.5. Clearing Faults

   Remote PW status fault clearing messages received by an S-PE will
   only be forwarded if there are no corresponding local faults on the
   S-PE. (local faults always supersede remote faults)

   Once the local fault has cleared, and there is no corresponding (same
   PW status bit set) remote fault, a PW status messages is sent out to
   the adjacent PEs clearing the fault.

   When a PW status fault clearing message is forwarded, the S-PE will
   always send the S-PE TLV associated with the PE which cleared the
   fault.




Martini, et al.                                                [Page 34]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


10.2. PW status messages and S-PE TLV processing

   When a PW status message is received that includes a S-PE TLV, the
   S-PE TLV information MAY be stored, along with the contents of the PW
   status Word according to the procedures described above. The S-PE TLV
   stored is always the S-PE TLV that is associated with the PE that set
   that particular last fault. If subsequent PW status message for the
   same PW status bit are received the S-PE TLV will overwrite the
   previously stored S-PE TLV.


10.3. T-PE processing of PW status messages

   The PW switching architecture is based on the concept that the T-PE
   should process the PW LDP messages in the same manner as if it was
   participating in the setup of a SS-PW. However T-PE participating a
   MS-PW, SHOULD be able to process the PW switching point TLV.
   Otherwise the processing of PW status messages , and other PW setup
   messages is exactly as described in [RFC4447].


10.4. Pseudowire Status Negotiation Procedures

   Pseudowire Status signaling methodology, defined in [RFC4447], SHOULD
   be transparent to the switching point.

MB> This sentence is unclear as it is not quite transparent if one segment supports 
PW status, and the following segment only supports PW label withdrawal. I would suggest adding:



10.5. Status Dampening

   When the PW control plane switching methodology is used to cross an
   administrative boundary it might be necessary to prevent excessive
   status signaling changes from being propagated across the
   administrative boundary.  This can be achieved by using a similar
   method as commonly employed for the BGP protocol route advertisement
   dampening. The details of this OPTIONAL algorithm are a matter of
   implementation, and are outside the scope of this document.


11. Peering Between Autonomous Systems

   The procedures outlined in this document can be employed to provision
   and manage MS-PWs crossing AS boundaries. The use of more advanced
   mechanisms involving auto-discovery and ordered PWE3 MS-PW signaling
   will be covered in a separate document.







Martini, et al.                                                [Page 35]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


12. Security Considerations

   This document specifies the LDP and L2TPv3 extensions that are needed
   for setting up and maintaining pseudowires. The purpose of setting up
   pseudowires is to enable layer 2 frames to be encapsulated and
   transmitted from one end of a pseudowire to the other. Therefore we
   treat the security considerations for both the data plane and the
   control plane.


12.1. Data Plane Security

   Data plane security consideration as discussed in [RFC4447],
   [L2TPv3], and [PWE3-ARCH] apply to this extension without any
   changes.


12.1.1. VCCV Security considerations

   The VCCV technology for MS-PW offers a method for the service
   provider to verify the data path of a specific PW. This involves
   sending a packet to a specific PE and receiving an answer which
   either confirms , or indicates that the information contained in the
   packet is incorrect. This is a very similar process to the commonly
   used IP ICMP ping , and TTL expired methods for IP networks. It
   should be noted that when using VCCV Type 3 for PW when the CW is not
   enabled, if a packet is crafted with a TTL greater then the number of
   hops along the MS-PW path, or an S-PE along the path mis-processes
   the TTL, the packet could mistakenly be forwarded out the attachment
   circuit as a native PW packet. This packet would most likely be
   treated as an error packet by the CE. However if this possibility is
   not acceptable, the CW should be enabled to guarantee that a VCCV
   packet will never be mistakenly forwarded to the AC.


12.2. Control Protocol Security

   General security considerations with regard to the use of LDP are
   specified in section 5 of RFC 3036. Security considerations with
   regard to the L2TPv3 control plane are specified in [L2TPv3]. These
   considerations apply as well to the case where LDP or L2TPv3 is used
   to set up PWs.

   A Pseudowire connects two attachment circuits. It is important to
   make sure that LDP connections are not arbitrarily accepted from
   anywhere, or else a local attachment circuit might get connected to
   an arbitrary remote attachment circuit. Therefore an incoming session
   request MUST NOT be accepted unless its IP source address is known to



Martini, et al.                                                [Page 36]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   be the source of an "eligible" peer. The set of eligible peers could
   be pre-configured (either as a list of IP addresses, or as a list of
   address/mask combinations), or it could be discovered dynamically via
   an auto-discovery protocol which is itself trusted. (Obviously if the
   auto-discovery protocol were not trusted, the set of "eligible peers"
   it produces could not be trusted.)

   Even if a connection request appears to come from an eligible peer,
   its source address may have been spoofed.  So some means of
   preventing source address spoofing must be in place.  For example, if
   all the eligible peers are in the same network, source address
   filtering at the border routers of that network could eliminate the
   possibility of source address spoofing.

   For a greater degree of security, the LDP MD5 authentication key
   option, as described in section 2.9 of RFC 3036, or the Control
   Message Authentication option of [L2TPv3] MAY be used.  This provides
   integrity and authentication for the control messages, and eliminates
   the possibility of source address spoofing.  Use of the message
   authentication option does not provide privacy, but privacy of
   control messages are not usually considered to be highly urgent.
   Both the LDP and L2TPv3 message authentication options rely on the
   configuration of pre-shared keys, making it difficult to deploy when
   the set of eligible neighbors is determined by an auto-configuration
   protocol.

   When the Generalized ID FEC Element is used, it is possible that a
   particular peer may be one of the eligible peers, but may not be the
   right one to connect to the particular attachment circuit identified
   by the particular instance of the Generalized ID FEC element.
   However, given that the peer is known to be one of the eligible peers
   (as discussed above), this would be the result of a configuration
   error, rather than a security problem.  Nevertheless, it may be
   advisable for a PE to associate each of its local attachment circuits
   with a set of eligible peers, rather than having just a single set of
   eligible peers associated with the PE as a whole.


13. IANA Considerations

13.1. L2TPv3 AVP

   This document uses a ne L2TP parameter, IANA already maintains a
   registry of name "Control Message Attribute Value Pair" defined by
   [RFC3438]. The following new values are required:

   TBA-L2TP-AVP-1 - PW Switching Point AVP




Martini, et al.                                                [Page 37]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


13.2. LDP TLV TYPE

   This document uses several new LDP TLV types, IANA already maintains
   a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The
   following value is suggested for assignment:

      TLV type  Description
       0x096D   Pseudowire Switching TLV


13.3. LDP Status Codes

   This document uses several new LDP status codes, IANA already
   maintains a registry of name "STATUS CODE NAME SPACE" defined by
   RFC3036. The following value is suggested for assignment:

      Assignment E Description
      0x0000003A 0 "PW Loop Detected"


13.4. L2TPv3 Result Codes

   This document uses several new L2TPv3 status codes, IANA already
   maintains a registry of name "L2TPv3 Result Codes" defined by
   RFCxxxx. The following value is suggested for assignment:

      Assignment  Description
          17      "sequencing not supported"


13.5. New IANA Registries

   IANA needs to set up a registry of "PW Switching Point TLV Type".
   These are 8-bit values. Types value 1 through 3 are defined in this
   document. Type values 4 through 64 are to be assigned by IANA using
   the "Expert Review" policy defined in RFC2434. Type values 65 through
   127, 0 and 255 are to be allocated using the IETF consensus policy
   defined in [RFC2434]. Types values 128 through 254 are reserved for
   vendor proprietary extensions and are to be assigned by IANA, using
   the "First Come First Served" policy defined in RFC2434.

   The Type Values are assigned as follows:









Martini, et al.                                                [Page 38]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   Type  Length   Description

   0x01     4     PW ID of last PW segment traversed
   0x02  variable PW Switching Point description string
   0x03    4/16   Local IP address of PW Switching Point
   0x04    4/16   Remote IP address of last PW Switching Point traversed
                  or of the T-PE
   0x05  variable AI of last PW segment traversed
   0x06     10    L2 PW address of PW Switching Point



14. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].


15. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND



Martini, et al.                                                [Page 39]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


16. Acknowledgments

   The authors wish to acknowledge the contributions of Satoru
   Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua,
   and Tiberiu Grigoriu.


17. Normative References

   [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3)
        Control Word for Use over an MPLS PSN", S. Bryant, et al.,
        RFC4385, February 2006.

   [RFC4446] "IANA Allocations for Pseudowire Edge to Edge
        mulation (PWE3)", L. Martini, RFC4446,  April 2006.

   [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
         et al., rfc4447 April 2006.

   [RFC3985] Stewart Bryant, et al., PWE3 Architecture,
        RFC3985

   [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y.
        draft-ietf-l3vpn-rfc2547bis-03.txt ( work in progress ),
        October 2004.

   [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau,
        M. Townsley, I. Goyret, RFC3931

   [RFC5085] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection
        Verification (VCCV),   A Control Channel for Pseudowires",
        RFC5085 December 2007.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
        IANA Considerations section in RFCs", BCP 26, RFC 2434, October
        1998.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment
        Individual Identifier (AII) Types for Aggregation", RFC5003,



Martini, et al.                                                [Page 40]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


        September 2007.
        [RFC4379] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC4379, September 2007


18. Informative References

   [RFC3985] Stewart Bryant, et al., PWE3 Architecture,
        RFC3985


   [RFC4023] "Encapsulating MPLS in IP or Generic
        Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y.
        RFC4023, March 2005.

   [PWE3-ARCH] "PWE3 Architecture" Bryant, et al.,
        draft-ietf-pwe3-arch-07.txt ( work in progress ), June 2003.

   [PWE3-FRAG] "PWE3 Fragmentation and Reassembly", A. Malis,
        W. M. Townsley, draft-ietf-pwe3-fragmentation-05.txt
        ( work in progress ) February 2004

   [RFC4667] "Layer 2 Virtual Private Network (L2VPN)
        Extensions for Layer 2 Tunneling Protocol (L2TP)", Luo, Wei,
        RFC4667, W. Luo, September 2006

   [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta,
        Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt,
        ( work in progress ), July 2004

###CP> The closest today is draft-ietf-l2tpext-radius-ext-nas-port-02, , 
###CP> which is an L2tpext WG Doc, but expired June 2008.
###CP>
###CP>
   [RFC4454] "Asynchronous Transfer Mode (ATM) over Layer 2
        Tunneling Protocol Version 3 (L2TPv3)", Singh, Townsley,
        Pignataro, RFC4454, May 2006
        ( work in progress ), March 2004.

   [RFC4717] "Encapsulation Methods for Transport of (ATM)
        MPLS Networks", Martini et al., RFC4717, December 2006

   [RFC3438]  W. M. Townsley, "Layer Two Tunneling Protocol
        (L2TP) Internet"

   [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al,
        draft-ietf-pwe3-oam-msg-map-02.txt, ( work in progress ),
        February 2005

   [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data
        Plane Failures", RFC4379, February 2006.

   [RFC3032] "MPLS Label Stack Encoding", RFC3032, January 2001

   [MS-PW-ARCH] "An Architecture for Multi-Segment Pseudo Wire Emulation
        Edge-to-Edge", Bocci et al, draft-ietf-pwe3-ms-pw-arch-03.txt
        June 2007



Martini, et al.                                                [Page 41]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008


19. Author Information


   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   e-mail: [e-mail]


   Thomas D. Nadeau
   BT
   BT Centre
   81 Newgate Street
   London,   EC1A 7AJ
   United Kingdom
   e-mail: [e-mail]


   Chris Metz
   Cisco Systems, Inc.
   e-mail: [e-mail]


   Mike Duckett
   Bellsouth
   Lindbergh Center
   D481
   575 Morosgo Dr
   Atlanta, GA  30324
   e-mail: [e-mail]


   Matthew Bocci
   Alcatel-Lucent
   Grove House, Waltham Road Rd
   White Waltham, Berks, UK. SL6 3TN
   e-mail: [e-mail]


   Florin Balus
   Alcatel-Lucent
   701 East Middlefield Rd.
   Mountain View, CA 94043
   e-mail: [e-mail]






Martini, et al.                                                [Page 42]

Internet Draft    draft-ietf-pwe3-segmented-pw-10.txt       January 2008



   Mustapha Aissaoui
   Alcatel-Lucent
   600, March Road,
   Kanata, ON, Canada
   e-mail: [e-mail]













































Martini, et al.                                                [Page 43]

###CP> Thanks !
###CP> -- Carlos Pignataro.


--------------020808090708080500070709--

From [e-mail]  Fri Mar 13 01:32:16 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E245528C1A2; Fri, 13 Mar 2009 01:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 skUHbV65F0Fk; Fri, 13 Mar 2009 01:32:10 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 126A628C177; Fri, 13 Mar 2009 01:32:03 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2B7DC21960; Fri, 13 Mar 2009 09:32:40 +0100 (CET)
X-AuditID: c1b4fb3e-ad89dbb0000023da-2d-49ba1a273ee5
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C284D222E2; Fri, 13 Mar 2009 09:32:39 +0100 (CET)
Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 13 Mar 2009 09:31:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Mar 2009 09:31:20 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PWE3] [mpls]  2nd wg last call on draft-ietf-mpls-tp-gach-gal
thread-index: AcmeenhnQRpQH0GjPUmTSqrAenuIjwEwLsagAB1zhrA=
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Annamaria Fulignoli" <[e-mail]>
To: "Luyuan Fang (lufang)" <[e-mail]>, "Ben Niven-Jenkins" <[e-mail]>, "Thomas Nadeau" <[e-mail]>, "Loa Andersson" <[e-mail]>
X-OriginalArrivalTime: 13 Mar 2009 08:31:21.0907 (UTC) FILETIME=[16D2F830:01C9A3B6]
X-Brightmail-Tracker: AAAAAA==
Cc: [e-mail], ITU-T ad hoc team on MPLS-TP <[e-mail]>, [e-mail], [e-mail], [e-mail], David Ward <[e-mail]>, Malcolm Betts <[e-mail]>, VIGOUREUX MARTIN <[e-mail]>
Subject: Re: [PWE3] [mpls]  2nd wg last call on draft-ietf-mpls-tp-gach-gal
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2009 08:32:17 -0000

Agreed
Annamaria=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of =
Luyuan Fang (lufang)
Sent: gioved=EC 12 marzo 2009 18.52
To: Ben Niven-Jenkins; Thomas Nadeau; Loa Andersson
Cc: [e-mail]; ITU-T ad hoc team on MPLS-TP; [e-mail]; =
[e-mail]; [e-mail]; David Ward; Malcolm Betts; VIGOUREUX =
MARTIN
Subject: Re: [PWE3] [mpls] 2nd wg last call on =
draft-ietf-mpls-tp-gach-gal

Agreed.
Luyuan=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of =
Ben Niven-Jenkins
Sent: 06 March 2009 11:42
To: Thomas Nadeau; Loa Andersson
Cc: [e-mail]; ITU-T ad hoc team on MPLS-TP; [e-mail]; =
[e-mail]; [e-mail]; David Ward; Malcolm Betts; VIGOUREUX =
MARTIN
Subject: Re: [mpls] [PWE3] 2nd wg last call on =
draft-ietf-mpls-tp-gach-gal

Agreed.

It addresses a need and provides a solution for operators evolving to =
MPLS-TP from their existing deployed MPLS & PW services without =
significant changes to their existing support infrastructures.

Ben



On 06/03/2009 14:00, "Thomas Nadeau" <[e-mail]> wrote:

>=20
> I think this document is ready to progress forward.
>=20
> --Tom
>=20
>=20
> On Feb 24, 2009:10:25 AM, at 10:25 AM, Loa Andersson wrote:
>=20
>> All,
>>=20
>> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal has been=20
>> published.
>>=20
>> The draft is found at:
>>=20
>> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
>>=20
>> Since the updates are significant this is to initiate a 2 week=20
>> working group last call on the new version.
>>=20
>> Please send your comments to the [e-mail] mailing list.
>>=20
>> The working group last call will end on March 11.
>>=20
>> /Loa
>> --
>>=20
>>=20
>> Loa Andersson
>>=20
>> Sr Strategy and Standards Manager
>> Ericsson ///                          phone:  [phone]
>>=20
>>                                      email:
>> [e-mail]
>>
[e-mail]
>>                                              [e-mail]
>>=20
>>=20
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>=20
>=20
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3

From [e-mail]  Fri Mar 13 04:07:03 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61D63A69D4; Fri, 13 Mar 2009 04:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.982
X-Spam-Level: 
X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 pcCKiiVRKngY; Fri, 13 Mar 2009 04:06:56 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 2E3C43A6AE9; Fri, 13 Mar 2009 04:06:55 -0700 (PDT)
Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2DB7SZl014809;  Fri, 13 Mar 2009 12:07:32 +0100
Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Mar 2009 12:07:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Mar 2009 12:06:44 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls-tp] poll on making draft-sprecher-mpls-tp-survive-fwk-01.txt a working group document?
Thread-Index: AcmYP9kd/B2/0yJoRx6ei5eVpkIeMALi++mg
References: <[e-mail]>
From: "BUSI ITALO" <[e-mail]>
To: "Loa Andersson" <[e-mail]>, <[e-mail]>, <[e-mail]>, "ITU-T ad hoc team on MPLS-TP" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Mar 2009 11:07:29.0428 (UTC) FILETIME=[E64D3D40:01C9A3CB]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Subject: Re: [PWE3] [mpls-tp] poll on making draft-sprecher-mpls-tp-survive-fwk-01.txt a working group document?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2009 11:07:03 -0000

Support

Italo=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Thursday, February 26, 2009 7:26 PM
> To: [e-mail]; [e-mail]; ITU-T ad hoc team on=20
> MPLS-TP; [e-mail]; [e-mail]
> Subject: [mpls-tp] poll on making=20
> draft-sprecher-mpls-tp-survive-fwk-01.txt a working group document?
>=20
> All,
>=20
> we have received a request from the editors/authors of
> draft-sprecher-mpls-tp-survive-fwk-01.txt to make the
> document an mpls working group document.
>=20
> Please send your comments to the mpls-tp mailing list.
>=20
> This poll ends eob Thu Mar 12, 2009.
>=20
> /Loa
>=20
> --=20
>=20
>=20
> Loa Andersson
>=20
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  [phone]
>=20
>                                        email: =20
> [e-mail]
>                                               =20
> [e-mail]
>                                                [e-mail]
>=20
>=20
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>=20

From [e-mail]  Fri Mar 13 22:19:00 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121843A6827 for <[e-mail]>; Fri, 13 Mar 2009 22:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.916
X-Spam-Level: 
X-Spam-Status: No, score=-94.916 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1, 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 6Qf4jplHh6C3 for <[e-mail]>; Fri, 13 Mar 2009 22:18:59 -0700 (PDT)
Received: from mail.zte.com.cn (unknown [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 9CE843A6838 for <[e-mail]>; Fri, 13 Mar 2009 22:18:58 -0700 (PDT)
Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 52229.1397396305; Sat, 14 Mar 2009 12:31:41 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2E47whF001442 for <[e-mail]>; Sat, 14 Mar 2009 12:07:58 +0800 (CST) (envelope-from [e-mail])
To: [e-mail]
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 14 Mar 2009 12:07:48 +0800
X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-14 12:07:54, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-14 12:07:54, Serialize complete at 2009-03-14 12:07:54, S/MIME Sign failed at 2009-03-14 12:07:54: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-14 12:07:50, Serialize complete at 2009-03-14 12:07:50
Content-Type: multipart/alternative; boundary="=_alternative 0016B23E48257579_="
X-MAIL: mse1.zte.com.cn n2E47whF001442
Subject: [PWE3] one extra ":" in page 17 of draft-ietf-pwe3-oam-msg-map-09.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 14 Mar 2009 05:19:00 -0000

This is a multipart message in MIME format.
--=_alternative 0016B23E48257579_=
Content-Type: text/plain; charset="US-ASCII"

To The Authors: 

During my reading of draft-ietf-pwe3-oam-msg-map-09.txt, I find one extra 
":" in page 17 :

  In this mode, only the following diagnostic (Diag) codes specified in 
   [BFD] will be used, they are: 

      0 - No diagnostic: <- Here it is. 

--=_alternative 0016B23E48257579_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=5 face="Courier New">To The Authors:</font><font size=3 face="Verdana">
<br>
</font><font size=5 face="Courier New"><br>
During my reading of draft-ietf-pwe3-oam-msg-map-09.txt, I find one extra
&quot;:&quot; in page 17</font><font size=3 face="Verdana"> :<br>
</font><font size=5 face="Courier New"><br>
 &nbsp;In this mode, only the following diagnostic (Diag) codes specified
in <br>
 &nbsp; [BFD] will be used, they are: <br>
<br>
 &nbsp; &nbsp; &nbsp;0 - No diagnostic: &lt;- Here it is.</font><font size=3 face="Verdana">
</font><font size=2 face="sans-serif"><br>
</font>
--=_alternative 0016B23E48257579_=--

From [e-mail]  Sun Mar 15 05:12:44 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192833A6B10 for <[e-mail]>; Sun, 15 Mar 2009 05:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.336
X-Spam-Level: 
X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.196,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067]
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 pcf8eSBmkmZQ for <[e-mail]>; Sun, 15 Mar 2009 05:12:42 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6B2553A6857 for <[e-mail]>; Sun, 15 Mar 2009 05:12:42 -0700 (PDT)
Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830);  Sun, 15 Mar 2009 12:13:21 +0000
Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Sun, 15 Mar 2009 12:13:21 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Sun, 15 Mar 2009 12:13:19 +0000
From: Ben Niven-Jenkins <[e-mail]>
To: BOCCI Matthew <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Thread-Index: AcmgyPWOuN2jJRCTSJyF9zjH3IElPQEnnewM
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 15 Mar 2009 12:13:21.0782 (UTC) FILETIME=[6EEA1960:01C9A567]
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 15 Mar 2009 12:12:44 -0000

I have reviewed the document and one substantive comment and a couple of
editorial ones.

Section 7 Security Considerations
   The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit
   procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop],
   including the use of the Generalized TTL Security Mechanism (GTSM) as
   a security mechanism.

Is use of TTL/hop limit & GTSM mentioned in the body of the draft I don't
remember seeing it?



Page 6, Paragraph that begins " When the downstream PE (D-PE) does not
receive..."

Replace

"direction setting the State to Down, and it using Diagnostic code 3"

With

"direction, setting the State to Down with Diagnostic code 3"


Last sentence of section 3.3

Replace

"All BFD CV Types are mutually exclusive with the rest"

With

"All BFD CV Types are mutually exclusive"


2nd paragraph f section 4

S/ For these cases were multiple/ For these cases where multiple/





On 09/03/2009 15:08, "BOCCI Matthew" <[e-mail]>
wrote:

> This is the start of working group last call on
> draft-ietf-pwe3-vccv-bfd-03.txt
> 
> This draft can be found at:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt
> 
> The last call will close on Monday 6th April 2009.
> 
> Please read the document and provide feedback to the PWE3 list.
> 
> Many thanks to the following, who have also kindly agreed to review the
> draft and provide comments to the list:
> Ben Niven-Jenkins
> Mustapha Aissaoui
> Luca Martini
> Yaakov Stein
> 
> Best regards
> 
> Matthew
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3


From [e-mail]  Mon Mar 16 12:52:26 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344CD3A699F for <[e-mail]>; Mon, 16 Mar 2009 12:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level: 
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=1.150,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 tVEalSBWtKSd for <[e-mail]>; Mon, 16 Mar 2009 12:52:24 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 2A7173A6878 for <[e-mail]>; Mon, 16 Mar 2009 12:52:24 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2GJr4WU021347; Mon, 16 Mar 2009 15:53:04 -0400 (EDT)
Received: from [64.102.157.181] (dhcp-64-102-157-181.cisco.com [64.102.157.181]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2GJr4lp024446;  Mon, 16 Mar 2009 15:53:04 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Mar 2009 15:53:04 -0400
From: Carlos Pignataro <[e-mail]>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail], pwe3 <[e-mail]>
Subject: Re: [PWE3] Last call comments on draft-ietf-pwe3-vccv-bfd-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2009 19:52:26 -0000

Stewart,

Thank you for the review and comments !

Please see inline: we are incorporating the comments that are acked
below into the working copy of the document, but there's also some
follow-up questions and confirmation requests below.

On 3/12/2009 12:18 PM, Stewart Bryant wrote:
> Some last call comments on draft-ietf-pwe3-vccv-bfd-03
> 
> 
> - Stewart
> 
> 
> 
> Carlos
> 
> Are you going to get this reviewed in L2TPext?
> 
> 

Yes, I sent it to the L2tpext list.

> 
>               Bidirectional Forwarding Detection (BFD) for
>     the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
>                       draft-ietf-pwe3-vccv-bfd-03
> 
> <snip>
> 
>    The CV Type is defined as a bitmask field used to indicate the
>    specific CV Type or Types (i.e., none, one or more) of VCCV packets
>    that may be sent on the VCCV control channel.  The values shown below
>    augment those already defined in [RFC5085].  They represent the
> SB> Perhaps "also shown in paranthasis(sp) in the
> SB> table below is the numerical...." might be clearer

Ack.

>    numerical value corresponding to the actual bit being set in the CV
>    Type bitfield.
> 
>    BFD CV Types:
> 
>       The defined values for the different BFD CV Types for MPLS and
>       L2TPv3 PWs are:
> 
>       Bit (Value)   Description
>       ============  ====================================================
>       Bit 2 (0x04)  BFD IP/UDP-encapsulated, for PW Fault Detection only
>       Bit 3 (0x08)  BFD IP/UDP-encapsulated, for PW Fault Detection and
>                     AC/PW Fault Status Signaling
>       Bit 4 (0x10)  BFD PW-ACH-encapsulated, for PW Fault Detection only
>       Bit 5 (0x20)  BFD PW-ACH-encapsulated, for PW Fault Detection and
>                     AC/PW Fault Status Signaling
> 
>    It should be noted that four BFD CV Types have been defined by
>    permutation of their encapsulation and functionality, see
>    Section 3.3.
> SB> The above is perfectly correct, but I had to think about it
> SB> I wonder if there is a simpler way to say it.

Yes, could you provide specific textual suggestions? Alternatively,
would this work? [changed not made yet in the working copy yet]

	It should be noted that four BFD CV Types have been defined by
	combining two types of encapsulation with two types of
	functionality, ...


> 
> <snip>
> 
> 
>    When the downstream PE (D-PE) does not receive BFD control messages
>    from its upstream peer PE (U-PE) during a certain number of
>    transmission intervalS (a number provisioned by the operator as
>    Detect Mult),
> SB> where is Detect Mult defined - Do you mean Detect Multiplier?

It's defined in S4.1 of draft-ietf-bfd-base, as "Detect Mult", expanded
as "detection time multiplier" in its description. Throughout the BFD
base spec, it's used as "The Detect Mult value ...", and that's why we
used it as-is.

Changed to "a number provisioned by the operator as "Detect Mult" or
detection time multiplier [bfd-base])". Is this better?

> 
> 
>  D-PE declares that the PW in its receive direction is
>    down.  In other words, D-PE enters the "forward defect" state for
>    this PW.  After this calculated Detection Time, D-PE declares the
> SB> Perhaps clarify that Detection time is transmission interval times
> SB> Detection Multiplier plus a bit.

I think it's slightly more complex than that, as the Detect Mult is the
one received from the remote endpoint and transmission interval is
negotiated, plus jitter, and is explained at
http://tools.ietf.org/html/draft-ietf-bfd-base-09#section-6.8.4

I think that trying to explain it here would confuse, so instead we added:
	After this calculated Detection Time (see S6.8.4 of [bfd-base]),
	D-PE

We can also add "(derived from the negotiated transit interface and the
Detect Mult, see ...)" if you think that's more clear, please let us
know. [changed not made yet in the working copy yet]


> 
>    session Down, and signals this to the remote end via the State (Sta)
>    with Diagnostic code 1 (Control Detection Time Expired).  In turn,
>    U-PE declares the PW is down in its transmit direction setting the
>    State to Down, and it using Diagnostic code 3 (Neighbor signaled
> SB> and "if" using

Actually, the "it" is extraneous and should be (is now) removed.

>    session down) in its control messages to D-PE.  U-PE enters the
>    "reverse defect" state for this PW.  If needed, how it further
> SB> something wrong with the English "If needed, how.....

Ack. Removed the "If needed, ", resulting in "How it further processes
this error condition, and potentially conveys ..." (added "potentially").

>    processes this error condition, and conveys this status to the
>    attachment circuits is out of the scope of this specification, and is
>    instead defined in [I-D.ietf-pwe3-oam-msg-map].
> 
> SB> Next sentence comes out of the blue - does it belong here?

Ack. It's a separate (single-sentence) paragraph, moved it down to after
the next title.

>    The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base]
>    encapsulated as specified by the CV Type (see Section 3.2).
> 
> 3.2.  BFD Encapsulation
> 
>    There are two ways in which a BFD connectivity verification packet
>    may be encapsulated over the VCCV control channel.  This document
>    defines four BFD CV Types (see Section 3), which can be grouped into
>    two pairs of BFD CV Types from an encapsulation point of view.
> SB> In next do you mean "See table...."

Ack.

>    Table 1 in Section 3.3 summarizes the BFD CV Types.
> 
> <snip>
>  
>       The IP version (IPv4 or IPv6) matches the IP version used for
> SB> do you mean MUST match the IP version?

Ack.

>       signaling for dynamically established pseudowires, or is
> SB> then this would be "or MUST be configued"

Ack.

> 
> <snip>
> 
>       In this encapsulation, a "raw" BFD Control packet follows directly
>       the PW-ACH, and the PW-ACH Channel Type identifies "raw" BFD.  
> SB> The above does not quite read properly

Changed to:
	In this encapsulation, a "raw" BFD Control packet follows
	directly the PW-ACH. The PW-ACH Channel Type indicates that the
	Associated Channel carries "raw" BFD.

Is this more clear?


Note that the sentence that follows reads (you did not comment on this one):

	The PW Associated Channel (PWAC) is defined in Section 5
	of <xref target="RFC4385"/>, and its Channel Type field
	is used as a payload type identifier to discriminate the VCCV
	payload types.

Should we remove it or reward the second part, based on an upcoming
comment regarding using "payload type identifier"?

> 
> <snip>
>       The usage of the PW-ACH on different VCCV CC Types is specified
>       for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1,
>       5.1.2 and 5.1.3 of [RFC5085], in all cases depending on the use of
> SB> Perhaps ", and in all cases requires the use of"

Ack. (thanks, that change clarifies a lot)

>       a CW.  When VCCV carries raw BFD, the PW-ACH (Pseudowire CW's or
>       L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD
>       Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers,
>       see Section 5.2), to allow the identification of the encased BFD
>       payload when demultiplexing the VCCV control channel.  In this
>       case, the BFD CV Type employed in signaling (if used) is either
>       0x10 or 0x20.
> SB> The above is correct. but very cryptic.

I broke the long sentence into two at "...see Section 5.2). This is to
allow...". Also changed the "In this case, " to "In this encapsulation,"
to be more precise, and moved this last sentence to a separate para
since it's not directly related. Do you have other textual suggestions?
Is that change sufficient to be more clear?

> 
> 
> 3.3.  CV Types for BFD
> 
>    Four CV Types are defined for BFD.  Table 1 summarizes the BFD CV
>    Types, grouping them by encapsulation (i.e., with and without IP/UDP
>    headers) and by functionality (i.e., fault detection only, or fault
>    detection and status signaling).
> 
>    +----------------------------+--------------+-----------------------+
>    |                            |     Fault    |  Fault Detection and  |
>    |                            |   Detection  |    Status Signaling   |
>    |                            |     Only     |                       |
>    +----------------------------+--------------+-----------------------+
>    |  BFD, IP/UDP encapsulation |     0x04     |          0x08         |
>    |      (with IP/UDP Headers) |              |                       |
>    |                            |              |                       |
>    |  BFD, PW-ACH encapsulation |     0x10     |          0x20         |
>    |   (without IP/UDP Headers) |              |                       |
>    +----------------------------+--------------+-----------------------+
> 
>                  Table 1: Bitmask Values for BFD CV Types
> 
> SB> The earlier sections would be easier to read if this
> SB> table was earlier in the document.

The table is here both as a summary and also to be easily referenced by
the subsequent text that directly cites it. This section describes the
actual CV Types, and that's why it includes the table here. Note that,
although the table is in Section 3.3, it is referenced much earlier with:

	"See Table 1 in Section 3.3 that summarizes the BFD CV Types."

Do you think that we should reference the table in other places? Or if
we move the table to earlier in the document, where specifically? At the
end of Section 3 and right before the title for Section 3.1? [no change
yet here]


> 
>    The following list enumerates rules, restrictions and clarifications
>    on the usage of BFD CV Types:
> 
>    1.  BFD CV Types used for fault detection and status signaling (i.e.,
>        CV Types 0x08 and 0x20) SHOULD NOT be used when a control
>        protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
>        that can signal the AC/PW status to the remote endpoint of the
>        PW.  More details can be found in [I-D.ietf-pwe3-oam-msg-map].
> 
>    2.  BFD CV Types used for fault detection only (i.e., CV Types 0x04
>        and 0x10) can be used whether a protocol that can signal AC/PW
>        status is available or not.  This includes both statically
>        provisioned and dynamically signaled pseudowires.
> 
> SB> Strange sublist symbol on next

Do you mean the "A.", "B." (<list style="letters">)? It's to
differentiate the hierarchical level of the list (and say 2.A). Would
you prefer numbers, symbols (bullets) or other? [no change made here yet]

>        A.  In this case, BFD is used exclusively to detect faults on the
> <snip>
> 
>    3.  Pseudowires that do not use a CW or L2SS using the PW Associated
>        Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e.,
>        PW-ACH encapsulation of BFD, without IP/UDP headers).
> 
>        A.  PWs that use a PW-ACH include CC Type 1 (for both MPLS and
>            L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]),
>            and MPLS CC Types 2 and 3 when using a Control Word (as
>            specified in Sections 5.1.2 and 5.1.3 of [RFC5085]).  This
>            restriction stems from the fact that the PW-ACH contains a
>            Protocol Identification (PID) field, the Channel Type.
> SB> Please do not call the channel type a PID - it's going
> SB> to get confusing.
> 

OK, changed to:
	This restriction stems from the fact that the encapsulation
	uses the Channel Type in the PW-ACH.

Does that work?

> 
>        B.  PWs that do not use a PW-ACH can use the VCCV BFD
> SB> MUST only? or can only? The the rest of the para is really
> SB> quite difficult to read

Not "MUST only". How's this?

     B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation
	with IP/UDP headers, as the only VCCV BFD encapsulation
	supported. Using the IP/UDP encapsulated BFD CV Types allows for
	the concurrent use of other VCCV CV Types that uses an
	encapsulation with IP headers (e.g., ICMP Ping or LSP Ping
	defined in [RFC5085]).

The rest of the para is removed. We made this change, let us know if you
have additional suggestions.

>            encapsulation with IP/UDP headers, including its concurrent
>            use along with another CV Type that uses an encapsulation
>            with IP headers (e.g., ICMP Ping or LSP Ping).  For example,
>            as specified in Section 7 of [RFC4385], a Pseudowire
>            operating without CW MUST NOT use the PW-ACH.
> 
>    4.  Only a single BFD CV Type can be selected and used.  All BFD CV
>        Types are mutually exclusive with the rest, after selecting a BFD
> SB? perhaps a "." after rest

Ack.

>        CV Type, a node MUST NOT use any of the other three BFD CV Types.
> 
> 
> 4.  Capability Selection
> 
>    The precedence rules for selection of various CC and CV Types is
>    clearly outlined in Section 7 of [RFC5085].  This section augments
>    these rules when the BFD CV Types defined herein are supported.  The
>    selection of a specific BFD CV Type to use out of the four available
>    CV Types defined is tied to multiple factors, as hinted in
> SB> Hints are not good in a std track document :)

s/as hinted/as described/

>    Section 3.3.  
> 
> <snip>
> 
>    There may be more than one CV Type available for selection after
>    considering the intersection of advertised and received BFD CV Types,
>    and applying the rules in Section 3.3.  For these cases were multiple
>    BFD CV Types are available for selection, the following precedence
>    order applies when choosing the single BFD CV Type to use.  The
>    lowest numbered item (where both ends have set the indicated flag and
>    such flag is allowed by the rules above) is used:
> 
> SB> By lowest number do you mean the item nearest the top of the
> SB> list below? People will get confused between the list
> SB> point number and the cv type unless this it is very carefully
> SB> stated how to chose from the list below.

It says the "lowest numbered item" (not the "lowest number"). And items
in the list are numbered from 1 to 4. The lowest numbered refers to "1",
which is at the top. This text was worded like this to avoid any
ambiguity or confusion. It doesn't say lowest CV type either. However,
if you think there is still room for confusion, we can replace:

	The lowest numbered item (where both ends have set the indicated
	flag and such flag is allowed by the rules above) is used:

With: [changed not made in the working copy]

	Only CV Types where both ends have set the indicated flag and
	such flag is allowed by the rules above are considered. The
	lowest numbered item from those considered (i.e., choosing from
	top to bottom) is used:

Please let us know which one you think is more clear, or provide another
suggestion.

> 
>    1.  0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
>        Fault Detection and AC/PW Fault Status Signaling
> 
>    2.  0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
>        Fault Detection only
> 
>    3.  0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW
>        Fault Status Signaling
> 
>    4.  0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only
> 
>    This precedence order prioritizes superset of functionality and
>    simplicity of encapsulation.
> 
> 
> 5.  IANA Considerations
> 
> 5.1.  MPLS CV Types for the VCCV Interface Parameters Sub-TLV
> 
>    The VCCV Interface Parameters Sub-TLV codepoint is defined in
>    [RFC4446], and the VCCV CV Types registry is defined in [RFC5085].
>    This section lists the new BFD CV Types.
> 
>    IANA is requested to augment the "VCCV Connectivity Verification
>    Types" registry in the Pseudo Wires Name Spaces, reachable from
>    [IANA.pwe3-parameters].  These are bitfield values.  CV Type values
>    0x04 0x08, 0x10 and 0x20 are specified in Section 3.
> SB> Section 3 of this document.
> 

Ack.

> 
>       MPLS Connectivity Verification (CV) Types:
> 
>       Bit (Value)   Description
>       ============  ====================================================
>       Bit 2 (0x04)  BFD IP/UDP-encapsulated, for PW Fault Detection only
>       Bit 3 (0x08)  BFD IP/UDP-encapsulated, for PW Fault Detection and
>                     AC/PW Fault Status Signaling
>       Bit 4 (0x10)  BFD PW-ACH-encapsulated, for PW Fault Detection only
>       Bit 5 (0x20)  BFD PW-ACH-encapsulated, for PW Fault Detection and
>                     AC/PW Fault Status Signaling
> 
> 5.2.  PW Associated Channel Type
> 
> SB> The next will confuse IANA.
> SB> All they want is an instruction and that instruction
> SB> is to allocate 0x0007
> 

Agreed.

See below.

> 
>    The PW Associated Channel Types used by VCCV rely on previously
>    allocated numbers from the Pseudowire Associated Channel Types
>    Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from
>    [IANA.pwe3-parameters].

Removed the text between the markers below.
--->8---
>    In particular, 0x21 (Internet Protocol
>    version 4) is used whenever an IPv4 payload follows the Pseudowire
>    Associated Channel Header, or 0x57 is used when an IPv6 payload
>    follows the Pseudowire Associated Channel Header.
> 
>    In cases where a raw BFD Control packet follows the Pseudowire
>    Associated Channel as specified in Section 3.2 (i.e., when using the
>    PW-ACH-encapsulated BFD without IP/UDP headers), a new "Pseudowire
>    Associated Channel Types" Registry [RFC4385] entry of 0x07 is used.
--->8---

The rest remains as-is.

>    IANA is requested to reserve a new Pseudowire Associated Channel Type
>    value as follows:
> 
> 
>      Value (in hex)  Protocol Name                      Reference
>      --------------  ---------------------------------  ---------
> 
>      0x0007          BFD Control, PW-ACH encapsulation  [This document]
>                      (without IP/UDP Headers)
> 
> <snip>
> 
> 
> 6.  Congestion Considerations
> 
>    The congestion considerations that apply to [RFC5085] apply to this
>    mode of operation as well.
> 
> SB>... there are no additional congestion considerations

Ack.

Thanks again,

-- Carlos.

> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 


From [e-mail]  Mon Mar 16 12:53:52 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222883A6878 for <[e-mail]>; Mon, 16 Mar 2009 12:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.613
X-Spam-Level: 
X-Spam-Status: No, score=-6.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 NWu8Fxk5lYvK for <[e-mail]>; Mon, 16 Mar 2009 12:53:51 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1936A28C1D1 for <[e-mail]>; Mon, 16 Mar 2009 12:53:51 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2GJsR9F021478; Mon, 16 Mar 2009 15:54:27 -0400 (EDT)
Received: from [64.102.157.181] (dhcp-64-102-157-181.cisco.com [64.102.157.181]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2GJsRaM025916;  Mon, 16 Mar 2009 15:54:27 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Mar 2009 15:54:27 -0400
From: Carlos Pignataro <[e-mail]>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Ben Niven-Jenkins <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: BOCCI Matthew <[e-mail]>, [e-mail]
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2009 19:53:52 -0000

Ben,

Many Thanks for your review and comments. Please see inline.

On 3/15/2009 8:13 AM, Ben Niven-Jenkins wrote:
> I have reviewed the document and one substantive comment and a couple of
> editorial ones.
> 
> Section 7 Security Considerations
>    The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit
>    procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop],
>    including the use of the Generalized TTL Security Mechanism (GTSM) as
>    a security mechanism.
> 
> Is use of TTL/hop limit & GTSM mentioned in the body of the draft I don't
> remember seeing it?
> 

Yes, it is mentioned in Section 3.2 somewhat explicitly (mentioning
TTL/Hop Limit but without mentioning GTSM), like this:

      address from the range 0:0:0:0:0:FFFF:127.0.0.0/104.  The
      rationale is explained in Section 2.1 of [RFC4379].  The Time to
      Live/Hop Limit procedures from Section 5 of
      [I-D.ietf-bfd-v4v6-1hop] apply to this encapsulation, and hence
      the TTL/Hop Limit is set to 255.

And an explicit mention of GTSM is omitted, and instead it's inherent to
the use of BFD w/IP 1hop. However, for clarity and completeness, we
should probably add something like the following to the excerpt above:

      address from the range 0:0:0:0:0:FFFF:127.0.0.0/104.  The
      rationale is explained in Section 2.1 of [RFC4379].  The Time to
      Live/Hop Limit procedures from Section 5 of

|                   ^
|                   add "and Generalized TTL Security Mechanism (GTSM) "

      [I-D.ietf-bfd-v4v6-1hop] apply to this encapsulation, and hence
      the TTL/Hop Limit is set to 255.

Would this work?

Additionally, Ack the three editorials below, changes made with your new
text.

Thanks again,

-- Carlos.

> 
> 
> Page 6, Paragraph that begins " When the downstream PE (D-PE) does not
> receive..."
> 
> Replace
> 
> "direction setting the State to Down, and it using Diagnostic code 3"
> 
> With
> 
> "direction, setting the State to Down with Diagnostic code 3"
> 
> 
> Last sentence of section 3.3
> 
> Replace
> 
> "All BFD CV Types are mutually exclusive with the rest"
> 
> With
> 
> "All BFD CV Types are mutually exclusive"
> 
> 
> 2nd paragraph f section 4
> 
> S/ For these cases were multiple/ For these cases where multiple/
> 
> 
> 
> 
> 
> On 09/03/2009 15:08, "BOCCI Matthew" <[e-mail]>
> wrote:
> 
>> This is the start of working group last call on
>> draft-ietf-pwe3-vccv-bfd-03.txt
>>
>> This draft can be found at:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt
>>
>> The last call will close on Monday 6th April 2009.
>>
>> Please read the document and provide feedback to the PWE3 list.
>>
>> Many thanks to the following, who have also kindly agreed to review the
>> draft and provide comments to the list:
>> Ben Niven-Jenkins
>> Mustapha Aissaoui
>> Luca Martini
>> Yaakov Stein
>>
>> Best regards
>>
>> Matthew
>>
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 


From [e-mail]  Tue Mar 17 07:34:46 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2F93A6A06; Tue, 17 Mar 2009 07:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level: 
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 BUajItSiKYWN; Tue, 17 Mar 2009 07:34:45 -0700 (PDT)
Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 74EAB3A67E3; Tue, 17 Mar 2009 07:34:45 -0700 (PDT)
Received: from [192.36.158.51] (wdhcp-158-51.verkstad.net [192.36.158.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 5BCBB2D84B1; Tue, 17 Mar 2009 15:35:27 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 17 Mar 2009 15:35:26 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [PWE3] poll on making the draft-beller-mpls-tp-gach-dcn
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2009 14:34:46 -0000

All,

the authors/editors of draft-beller-mpls-tp-gach-dcn has
asked us to accept the document as an MPLS Working group
document.

This is a one week poll to see if there are support for making it a
working group document, please respond to the mpls-tp mailing
list before Wednesday March 25.

/Loa

-- 


Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  [phone]

                                       email:  [e-mail]
                                               [e-mail]
                                               [e-mail]



From [e-mail]  Wed Mar 18 07:50:01 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C7A28C205; Wed, 18 Mar 2009 07:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.233
X-Spam-Level: 
X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 nFGTLnhs6ePJ; Wed, 18 Mar 2009 07:50:00 -0700 (PDT)
Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 8B51C28C20D; Wed, 18 Mar 2009 07:50:00 -0700 (PDT)
Received: from [192.36.158.51] (wdhcp-158-51.verkstad.net [192.36.158.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id C48392D84B1; Wed, 18 Mar 2009 15:50:43 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 18 Mar 2009 15:50:42 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [PWE3] working groupm last call on draft-ietf-mpls-tp-gach-gal-02 has ended
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2009 14:50:01 -0000

  All,

  the working group last call on draft-ietf-mpls-tp-gach-gal-02
  has ended.

  1. we have received the information from ITU-T ad hoc team on mpls-tp
     that the comments they have is aligned with the last call comments
     received under point 5. below in the MPLS wg last call.

  2. We have received one comment that says that the associated channel
     should not be used for OAM. Since this is the entire purpose of the
     of the associated channel the authors/editors are instructed not
     consider this comment.
  3. We have received comments that would require us to revisit the
     results of the JWT investigtaion. We will not do so, since this is
     not within our charter.
  4. We have received one comment that we are allocating too many
     experimental code points, the editors/authors are instructed to solve
     this together with the current and future RTG AD and the MEAD team
     chair.

  5. We have received a set of comments, that should be considered as
     "friendly amendments" and that should be responded to by the
     authors-editors.

  Could the authors lease update the draft and republish.

  /Loa
-- 


Loa Andersson

Sr Strategy and Standards Manager    phone:  [phone]
Ericsson ///                                 [phone] 


                                       email:  [e-mail]
                                               [e-mail]
                                               [e-mail]



From [e-mail]  Thu Mar 19 05:47:27 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495B83A6A30; Thu, 19 Mar 2009 05:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 JmiEgI6FhzHj; Thu, 19 Mar 2009 05:47:26 -0700 (PDT)
Received: from ns.elverljung.se (ns.elverljung.se [194.68.48.116]) by core3.amsl.com (Postfix) with ESMTP id 3E9B13A6A0B; Thu, 19 Mar 2009 05:47:26 -0700 (PDT)
Received: from [10.4.169.87] (bgp-ext.core.365-24.net [217.151.192.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa) by ns.elverljung.se (Postfix) with ESMTPSA id 15BB02D84B8; Thu, 19 Mar 2009 13:48:08 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 19 Mar 2009 13:48:04 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [PWE3] poll to make draft-busi-mpls-tp-oam-framework an mpls working group document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2009 12:47:27 -0000

Working Group,


the authors of draft-busi-mpls-tp-oam-framework-02-02-1.txt has
requested the document shall be accepted as a working group document.

This is a one week poll to see if there are support for making it a
working group document, please respond to the mpls-tp mailing list
before Wednesday March 26.

The document will be found at:

http://www.tla-group.com/~loa/draft-busi-mpls-tp-oam-framework-02-02-1.txt

Disclaimer: I've decided to start this poll even though the draft is not
available from the IETF repository.


/Loa

-- 


Loa Andersson

Sr Strategy and Standards Manager    phone:  [phone]
Ericsson ///                                 [phone] 


                                       email:  [e-mail]
                                               [e-mail]
                                               [e-mail]



From [e-mail]  Thu Mar 19 15:22:04 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB753A6902 for <[e-mail]>; Thu, 19 Mar 2009 15:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.282
X-Spam-Level: 
X-Spam-Status: No, score=-0.282 tagged_above=-999 required=5 tests=[AWL=2.317,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 A2FuV8y4SFck for <[e-mail]>; Thu, 19 Mar 2009 15:22:04 -0700 (PDT)
Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 0A0D33A67F5 for <[e-mail]>; Thu, 19 Mar 2009 15:22:03 -0700 (PDT)
Received: by ewy9 with SMTP id 9so556949ewy.37 for <[e-mail]>; Thu, 19 Mar 2009 15:22:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=2XB6iARbTgc5saaW4V/WpMJQEV42cipwLpYiTrHKDi8=; b=v3LC0oMtoQpxaoTdkwlQhuaAtkm1TzzL9vY2DdpCdsE6z3lkJefjz442g1niVtrHcb /i5ks6uSIp2vLkesUr82Bf/+DknsQA3tSC+E9stmMN+r6o212sHNUQOHE4VYMOHTgwXu Mqb7cxAt3W2nwbJau9YZtdY3M94Xxij1I/t7k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ra9dDZmgD6s4vKy2dsIgEkqsnbDyDjcEwIs/DqB6xAhUBqH6EYE3igYH8z5/uGMwmY t+7XYfGa5frKrfTQL0naNyOR40kVyV0fLzmI+HGBXUexJ+2hRfAr+544ysGwVJpqDyCM FEwLYoTFbXljBzqNAnMzvqaRSkVhBrY6e7qkA=
MIME-Version: 1.0
Received: by 10.216.53.199 with SMTP id g49mr1201473wec.49.1237501369057; Thu,  19 Mar 2009 15:22:49 -0700 (PDT)
Date: Thu, 19 Mar 2009 23:22:49 +0100
Message-ID: <[e-mail]>
From: Antonio Di Bacco <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=0016e6dbdf9d83033a0465803dc6
Subject: [PWE3] MEF8 CESoETH MIB
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2009 22:24:45 -0000

--0016e6dbdf9d83033a0465803dc6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi all,

which MIB is dedicated to the configuration of pseudo wires built using the
MEF8? For sure I need to configure end points mac addresses and ECID but I
don't find any mib with these parameters.

Thank you,
Antonio.

--0016e6dbdf9d83033a0465803dc6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi all,<br><br>which MIB is dedicated to the configuration of pseudo wires built using the MEF8? For sure I need to configure end points mac addresses and ECID but I don&#39;t find any mib with these parameters.<br><br>Thank you,<br>
Antonio.<br>

--0016e6dbdf9d83033a0465803dc6--

From [e-mail]  Fri Mar 20 05:29:50 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E255A3A6C6A; Fri, 20 Mar 2009 05:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 EbmKQ9YMoI7c; Fri, 20 Mar 2009 05:29:50 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id B6E383A6C6D; Fri, 20 Mar 2009 05:29:49 -0700 (PDT)
Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2KCUBdV001884;  Fri, 20 Mar 2009 13:30:33 +0100
Received: from [135.244.23.217] ([135.244.23.217]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 13:30:31 +0100
Message-ID: <[e-mail]>
Date: Fri, 20 Mar 2009 13:30:26 +0100
From: Martin Vigoureux <[e-mail]>
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Mar 2009 12:30:32.0313 (UTC) FILETIME=[A9396690:01C9A957]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [PWE3] slides for joint mpls-tp session
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2009 12:29:51 -0000

all,

could you please start sending the slides you will use
for your presentation(s). Thanks.

The joint wg session on mpls-tp is on Wednesday, 9:00-11:30 am
http://www.ietf.org/proceedings/09mar/agenda/mpls.txt

martin


From prvs=323837233=[e-mail]  Fri Mar 20 05:39:09 2009
Return-Path: <prvs=323837233=[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6C43A6C5A for <[e-mail]>; Fri, 20 Mar 2009 05:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.287
X-Spam-Level: 
X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.311,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 HbbOKb+RHm5U for <[e-mail]>; Fri, 20 Mar 2009 05:39:06 -0700 (PDT)
Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id AB5FC3A6C5E for <[e-mail]>; Fri, 20 Mar 2009 05:39:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,395,1233561600"; d="scan'208,217";a="399316"
Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 20 Mar 2009 05:39:53 -0700
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 68A7FB6BAFB for <[e-mail]>; Fri, 20 Mar 2009 05:39:53 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09027-05 for <[e-mail]>; Fri, 20 Mar 2009 05:39:53 -0700 (PDT)
Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 536DAB6BAFA for <[e-mail]>; Fri, 20 Mar 2009 05:39:53 -0700 (PDT)
Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Fri, 20 Mar 2009 05:39:53 -0700
From: David Sinicrope <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Fri, 20 Mar 2009 05:39:50 -0700
Thread-Topic: [PWE3] Time slots for IETF 74 PWE3 meeting
Thread-Index: AcmO1f4o4AcNXYD1F0eyztRRXFz+YAL0CTg/Ae9A5QIBvXPB9A==
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C5E906D61822Feuddasiredbackcom_"
MIME-Version: 1.0
Subject: Re: [PWE3] Time slots for IETF 74 PWE3 meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2009 12:39:50 -0000

--_000_C5E906D61822Feuddasiredbackcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Those on the agenda, please send me your presentation slides for the PWE3 m=
eeting as soon as possible so I can upload them to the meeting materials be=
fore the meeting.
(Try to keep this subject on the email you send them with so I don't miss a=
ny.)
Thanks!
Dave

On 3/11/09 12:05 PM, "David Sinicrope" <[e-mail]> wrote:

The initial agenda is available at:
http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html
Please let me know if there are any questions or concerns,
Dave



--_000_C5E906D61822Feuddasiredbackcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [PWE3] Time slots for IETF 74 PWE3 meeting</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'><BR>
Those on the agenda, please send me your presentation slides for the PWE3 m=
eeting as soon as possible so I can upload them to the meeting materials be=
fore the meeting.<BR>
(Try to keep this subject on the email you send them with so I don&#8217;t =
miss any.)<BR>
Thanks!<BR>
Dave</SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:1=
2pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=
=3D'font-size:11pt'><BR>
On 3/11/09 12:05 PM, &quot;David Sinicrope&quot; &lt;<a href=3D"euddasi@red=
back.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>The initial agenda is available at:<BR>
<a href=3D"http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html">http:=
//tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html</a><BR>
Please let me know if there are any questions or concerns,<BR>
Dave<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C5E906D61822Feuddasiredbackcom_--

From [e-mail]  Sun Mar 22 10:32:01 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9743A6B83 for <[e-mail]>; Sun, 22 Mar 2009 10:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
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 IXM5o6GTsDOk for <[e-mail]>; Sun, 22 Mar 2009 10:32:01 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 01DA03A68D8 for <[e-mail]>; Sun, 22 Mar 2009 10:32:00 -0700 (PDT)
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n2MHWg4q017194;  Sun, 22 Mar 2009 12:32:42 -0500 (CDT)
Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830);  Sun, 22 Mar 2009 12:32:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 22 Mar 2009 12:32:41 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
Thread-Index: AcmTi4vS7pa2reoCTsan2rtcN7xbGQXh3giQ
References: <[e-mail]>
From: "Busschbach, Peter B \(Peter\)" <[e-mail]>
To: <[e-mail]>, "pwe3" <[e-mail]>
X-OriginalArrivalTime: 22 Mar 2009 17:32:42.0295 (UTC) FILETIME=[345C9C70:01C9AB14]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: [e-mail]
Subject: Re: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 22 Mar 2009 17:32:01 -0000

Stewart,

I noticed that draft-ietf-pwe3-segmented-pw-11 consistently uses the
word "fault", whereas draft-ietf-pwe3-oam-msg-map-09 uses the word
"defect".

Colloquially, these words have the same meaning. Several standards
specifications, however, make a distinction between the two terms. In
ITU-T specs, a defect refers to the interruption of the capability of a
transport entity to transfer user or OAM information, while a fault
(failure) refers to the termination of this capability. In other words,
a fault is a persistent defect and indicates that something is really
broken.

According to this definition, draft-ietf-pwe3-segmented-pw-11 should use
the defect instead of fault. In order to create consistency between the
documents, I propose that draft-ietf-pwe3-segmented-pw-11 be modified.

Peter

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On=20
> Behalf Of Stewart Bryant
> Sent: Friday, February 20, 2009 1:46 PM
> To: pwe3
> Cc: [e-mail]
> Subject: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
>=20
> This is the start of working group last call on
>=20
> draft-ietf-pwe3-segmented-pw-11.txt
>=20
> This draft can be found at
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-
> pw-11.txt
>=20
> Monday 9th March 2009.
>=20
> Please read the document and provide feedback to the PWE3 list
>=20
> Thanks
>=20
> Stewart
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>=20

From [e-mail]  Sun Mar 22 23:58:41 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4680D3A67B5; Sun, 22 Mar 2009 23:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 pV2fkSfLI2I9; Sun, 22 Mar 2009 23:58:40 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 4F0863A67A8; Sun, 22 Mar 2009 23:58:38 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Sun, 22 Mar 2009 23:59:30 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 22 Mar 2009 23:58:33 -0700
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Mar 2009 23:58:33 -0700
Received: from 172.23.5.253 ([172.23.5.253]) by emailcorp3.jnpr.net ([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Mar 2009 06:58:32 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Mon, 23 Mar 2009 00:00:13 -0700
From: Nitin Bahadur <[e-mail]>
To: Loa Andersson <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [PWE3] poll to make draft-busi-mpls-tp-oam-framework an mpls working group document
Thread-Index: AcmrhQM7cTK48B2SREKVJgZZK3zzMg==
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Mar 2009 06:58:33.0376 (UTC) FILETIME=[C7DA1200:01C9AB84]
Subject: Re: [PWE3] poll to make draft-busi-mpls-tp-oam-framework an mpls working group document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 06:58:41 -0000

Support.

On 3/19/09 5:48 AM, "Loa Andersson" <[e-mail]> wrote:

> Working Group,
> 
> 
> the authors of draft-busi-mpls-tp-oam-framework-02-02-1.txt has
> requested the document shall be accepted as a working group document.
> 
> This is a one week poll to see if there are support for making it a
> working group document, please respond to the mpls-tp mailing list
> before Wednesday March 26.
> 
> The document will be found at:
> 
> http://www.tla-group.com/~loa/draft-busi-mpls-tp-oam-framework-02-02-1.txt
> 
> Disclaimer: I've decided to start this poll even though the draft is not
> available from the IETF repository.
> 
> 
> /Loa


From [e-mail]  Mon Mar 23 08:21:17 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7621428C14E for <[e-mail]>; Mon, 23 Mar 2009 08:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.609
X-Spam-Level: 
X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 vposbfaC9aRV for <[e-mail]>; Mon, 23 Mar 2009 08:21:16 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 7499628C14B for <[e-mail]>; Mon, 23 Mar 2009 08:21:16 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2NFM4nQ006059; Mon, 23 Mar 2009 11:22:04 -0400 (EDT)
Received: from [64.102.157.152] (dhcp-64-102-157-152.cisco.com [64.102.157.152]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2NFM3PQ014781;  Mon, 23 Mar 2009 11:22:03 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 23 Mar 2009 11:22:03 -0400
From: Carlos Pignataro <[e-mail]>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: "Busschbach, Peter B \(Peter\)" <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail], pwe3 <[e-mail]>, [e-mail]
Subject: Re: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 15:21:17 -0000

Peter,

Does this proposal apply to all instances of those words? Note for
example that the PW Status from RFC4446 and RFC4447 uses "Fault", and
the document should probably keep referring to the same terms.

Also, does this comment apply also to the vccv-bfd document? Grepping,
vccv-bfd uses "Fault Detection" and "Fault Status" in all its
definitions (and uses "defect" in one paragraph).

Finally, is is a better disposition to use the text from
draft-ietf-pwe3-oam-msg-map-09 in the definitions/terminology section?
Quote:

--->8---

   The words "defect" and "fault" are used inter-changeably to mean a
   condition which causes user packets not to be forwarded between the
   CE endpoints of the PW service.

--->8---

Thanks,

-- Carlos.

On 3/22/2009 1:32 PM, Busschbach, Peter B (Peter) wrote:
> Stewart,
> 
> I noticed that draft-ietf-pwe3-segmented-pw-11 consistently uses the
> word "fault", whereas draft-ietf-pwe3-oam-msg-map-09 uses the word
> "defect".
> 
> Colloquially, these words have the same meaning. Several standards
> specifications, however, make a distinction between the two terms. In
> ITU-T specs, a defect refers to the interruption of the capability of a
> transport entity to transfer user or OAM information, while a fault
> (failure) refers to the termination of this capability. In other words,
> a fault is a persistent defect and indicates that something is really
> broken.
> 
> According to this definition, draft-ietf-pwe3-segmented-pw-11 should use
> the defect instead of fault. In order to create consistency between the
> documents, I propose that draft-ietf-pwe3-segmented-pw-11 be modified.
> 
> Peter
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Stewart Bryant
>> Sent: Friday, February 20, 2009 1:46 PM
>> To: pwe3
>> Cc: [e-mail]
>> Subject: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
>>
>> This is the start of working group last call on
>>
>> draft-ietf-pwe3-segmented-pw-11.txt
>>
>> This draft can be found at
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-
>> pw-11.txt
>>
>> Monday 9th March 2009.
>>
>> Please read the document and provide feedback to the PWE3 list
>>
>> Thanks
>>
>> Stewart
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 

From prvs=326dc9e23=[e-mail]  Mon Mar 23 09:47:35 2009
Return-Path: <prvs=326dc9e23=[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EAD28C1D7 for <[e-mail]>; Mon, 23 Mar 2009 09:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 uDDF6E2F71rs for <[e-mail]>; Mon, 23 Mar 2009 09:47:31 -0700 (PDT)
Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id ADAEA28C1B1 for <[e-mail]>; Mon, 23 Mar 2009 09:47:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,409,1233561600"; d="scan'208,217";a="441877"
Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 23 Mar 2009 09:48:22 -0700
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1A778511B31 for <[e-mail]>; Mon, 23 Mar 2009 09:48:22 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29376-07 for <[e-mail]>; Mon, 23 Mar 2009 09:48:21 -0700 (PDT)
Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id E9F9E511B2D for <[e-mail]>; Mon, 23 Mar 2009 09:48:21 -0700 (PDT)
Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Mon, 23 Mar 2009 09:48:21 -0700
From: David Sinicrope <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Mon, 23 Mar 2009 09:48:20 -0700
Thread-Topic: [PWE3] Time slots for IETF 74 PWE3 meeting
Thread-Index: AcmO1f4o4AcNXYD1F0eyztRRXFz+YAL0CTg/Ae9A5QIBvXPB9ACfHHmIAABxGoU=
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C5ED359418474euddasiredbackcom_"
MIME-Version: 1.0
Subject: Re: [PWE3] Time slots for IETF 74 PWE3 meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 16:47:35 -0000

--_000_C5ED359418474euddasiredbackcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi All,
Thanks to those that have sent me their presentations.
I've posted the presentations I've received (4):  See http://tools.ietf.org=
/wg/pwe3/agenda.
Others on the agenda, please send me your presentations as soon as you can.
Thanks,
Dave

On 3/20/09 8:39 AM, "David Sinicrope" <[e-mail]> wrote:


Those on the agenda, please send me your presentation slides for the PWE3 m=
eeting as soon as possible so I can upload them to the meeting materials be=
fore the meeting.
(Try to keep this subject on the email you send them with so I don't miss a=
ny.)
Thanks!
Dave

On 3/11/09 12:05 PM, "David Sinicrope" <[e-mail]> wrote:

The initial agenda is available at:
http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html
Please let me know if there are any questions or concerns,
Dave




--_000_C5ED359418474euddasiredbackcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [PWE3] Time slots for IETF 74 PWE3 meeting</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'><BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>Hi All, &nbsp;<BR>
Thanks to those that have sent me their presentations. &nbsp;<BR>
I&#8217;ve posted the presentations I&#8217;ve received (4): &nbsp;See <a h=
ref=3D"http://tools.ietf.org/wg/pwe3/agenda">http://tools.ietf.org/wg/pwe3/=
agenda</a>.<BR>
Others on the agenda, please send me your presentations as soon as you can.=
<BR>
Thanks,<BR>
Dave<BR>
<BR>
On 3/20/09 8:39 AM, &quot;David Sinicrope&quot; &lt;<a href=3D"euddasi@redb=
ack.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
Those on the agenda, please send me your presentation slides for the PWE3 m=
eeting as soon as possible so I can upload them to the meeting materials be=
fore the meeting.<BR>
(Try to keep this subject on the email you send them with so I don&#8217;t =
miss any.)<BR>
Thanks!<BR>
Dave</SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:1=
2pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=
=3D'font-size:11pt'><BR>
On 3/11/09 12:05 PM, &quot;David Sinicrope&quot; &lt;<a href=3D"euddasi@red=
back.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>The initial agenda is available at:<BR>
<a href=3D"http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html">http:=
//tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html</a><BR>
Please let me know if there are any questions or concerns,<BR>
Dave<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C5ED359418474euddasiredbackcom_--

From [e-mail]  Mon Mar 23 10:42:51 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064A33A6838 for <[e-mail]>; Mon, 23 Mar 2009 10:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 qdHDzEHoqOsT for <[e-mail]>; Mon, 23 Mar 2009 10:42:50 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 7D03C3A6A8E for <[e-mail]>; Mon, 23 Mar 2009 10:42:45 -0700 (PDT)
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n2NHgorf021351; Mon, 23 Mar 2009 12:43:07 -0500 (CDT)
Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 23 Mar 2009 12:42:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Mar 2009 12:42:54 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
Thread-Index: AcmryyKJFcpUOgLyQ46pzXOPnkK6QAAEl5VA
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Busschbach, Peter B \(Peter\)" <[e-mail]>
To: "Carlos Pignataro" <[e-mail]>
X-OriginalArrivalTime: 23 Mar 2009 17:42:59.0206 (UTC) FILETIME=[CE7B8260:01C9ABDE]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: [e-mail], pwe3 <[e-mail]>, [e-mail]
Subject: Re: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 17:42:51 -0000

Carlos,

You are right that fault has been used so widely that it does not make
sense to change all occurrences. I certainly don't advocate changing
"fault detection" to "defect detection". I agree that we can refer to
the definition that you quoted and be fairly liberal in using "fault"
and "defect".

However, with respect to the segmented-pw draft, the text in section 10
is clearly an extension of the oam-msg-map draft. Therefore, I think it
should use the same terminology for states and indications.

Peter

> -----Original Message-----
> From: Carlos Pignataro [mailto:[e-mail]]=20
> Sent: Monday, March 23, 2009 8:22 AM
> To: Busschbach, Peter B (Peter)
> Cc: [e-mail]; pwe3;=20
> [e-mail]
> Subject: Re: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
>=20
> Peter,
>=20
> Does this proposal apply to all instances of those words?=20
> Note for example that the PW Status from RFC4446 and RFC4447=20
> uses "Fault", and the document should probably keep referring=20
> to the same terms.
>=20
> Also, does this comment apply also to the vccv-bfd document?=20
> Grepping, vccv-bfd uses "Fault Detection" and "Fault Status"=20
> in all its definitions (and uses "defect" in one paragraph).
>=20
> Finally, is is a better disposition to use the text from
> draft-ietf-pwe3-oam-msg-map-09 in the definitions/terminology section?
> Quote:
>=20
> --->8---
>=20
>    The words "defect" and "fault" are used inter-changeably to mean a
>    condition which causes user packets not to be forwarded between the
>    CE endpoints of the PW service.
>=20
> --->8---
>=20
> Thanks,
>=20
> -- Carlos.
>=20
> On 3/22/2009 1:32 PM, Busschbach, Peter B (Peter) wrote:
> > Stewart,
> >=20
> > I noticed that draft-ietf-pwe3-segmented-pw-11 consistently=20
> uses the=20
> > word "fault", whereas draft-ietf-pwe3-oam-msg-map-09 uses the word=20
> > "defect".
> >=20
> > Colloquially, these words have the same meaning. Several standards=20
> > specifications, however, make a distinction between the two=20
> terms. In=20
> > ITU-T specs, a defect refers to the interruption of the=20
> capability of=20
> > a transport entity to transfer user or OAM information,=20
> while a fault
> > (failure) refers to the termination of this capability. In other=20
> > words, a fault is a persistent defect and indicates that=20
> something is=20
> > really broken.
> >=20
> > According to this definition,=20
> draft-ietf-pwe3-segmented-pw-11 should=20
> > use the defect instead of fault. In order to create consistency=20
> > between the documents, I propose that=20
> draft-ietf-pwe3-segmented-pw-11 be modified.
> >=20
> > Peter
> >=20
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]=20
> On Behalf=20
> >> Of Stewart Bryant
> >> Sent: Friday, February 20, 2009 1:46 PM
> >> To: pwe3
> >> Cc: [e-mail]
> >> Subject: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
> >>
> >> This is the start of working group last call on
> >>
> >> draft-ietf-pwe3-segmented-pw-11.txt
> >>
> >> This draft can be found at
> >>
> >> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-
> >> pw-11.txt
> >>
> >> Monday 9th March 2009.
> >>
> >> Please read the document and provide feedback to the PWE3 list
> >>
> >> Thanks
> >>
> >> Stewart
> >> _______________________________________________
> >> pwe3 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/pwe3
> >>
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> >=20
>=20

From [e-mail]  Mon Mar 23 11:45:39 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C599628C11E for <[e-mail]>; Mon, 23 Mar 2009 11:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.608
X-Spam-Level: 
X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9FX7fwgO+hgm for <[e-mail]>; Mon, 23 Mar 2009 11:45:38 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id BE0C73A6981 for <[e-mail]>; Mon, 23 Mar 2009 11:45:38 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2NIkNFO019484; Mon, 23 Mar 2009 14:46:23 -0400 (EDT)
Received: from [64.102.157.152] (dhcp-64-102-157-152.cisco.com [64.102.157.152]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2NIkMVC016828;  Mon, 23 Mar 2009 14:46:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 23 Mar 2009 14:46:22 -0400
From: Carlos Pignataro <[e-mail]>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: "Busschbach, Peter B \(Peter\)" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail], pwe3 <[e-mail]>, [e-mail]
Subject: Re: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 18:45:39 -0000

Peter,

On 3/23/2009 1:42 PM, Busschbach, Peter B (Peter) wrote:
> Carlos,
> 
> You are right that fault has been used so widely that it does not make
> sense to change all occurrences. I certainly don't advocate changing
> "fault detection" to "defect detection". I agree that we can refer to
> the definition that you quoted and be fairly liberal in using "fault"
> and "defect".

Ack.

> 
> However, with respect to the segmented-pw draft, the text in section 10
> is clearly an extension of the oam-msg-map draft. Therefore, I think it
> should use the same terminology for states and indications.

I agree as well.

Thanks,

-- Carlos.

> 
> Peter
> 
>> -----Original Message-----
>> From: Carlos Pignataro [mailto:[e-mail]] 
>> Sent: Monday, March 23, 2009 8:22 AM
>> To: Busschbach, Peter B (Peter)
>> Cc: [e-mail]; pwe3; 
>> [e-mail]
>> Subject: Re: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
>>
>> Peter,
>>
>> Does this proposal apply to all instances of those words? 
>> Note for example that the PW Status from RFC4446 and RFC4447 
>> uses "Fault", and the document should probably keep referring 
>> to the same terms.
>>
>> Also, does this comment apply also to the vccv-bfd document? 
>> Grepping, vccv-bfd uses "Fault Detection" and "Fault Status" 
>> in all its definitions (and uses "defect" in one paragraph).
>>
>> Finally, is is a better disposition to use the text from
>> draft-ietf-pwe3-oam-msg-map-09 in the definitions/terminology section?
>> Quote:
>>
>> --->8---
>>
>>    The words "defect" and "fault" are used inter-changeably to mean a
>>    condition which causes user packets not to be forwarded between the
>>    CE endpoints of the PW service.
>>
>> --->8---
>>
>> Thanks,
>>
>> -- Carlos.
>>
>> On 3/22/2009 1:32 PM, Busschbach, Peter B (Peter) wrote:
>>> Stewart,
>>>
>>> I noticed that draft-ietf-pwe3-segmented-pw-11 consistently 
>> uses the 
>>> word "fault", whereas draft-ietf-pwe3-oam-msg-map-09 uses the word 
>>> "defect".
>>>
>>> Colloquially, these words have the same meaning. Several standards 
>>> specifications, however, make a distinction between the two 
>> terms. In 
>>> ITU-T specs, a defect refers to the interruption of the 
>> capability of 
>>> a transport entity to transfer user or OAM information, 
>> while a fault
>>> (failure) refers to the termination of this capability. In other 
>>> words, a fault is a persistent defect and indicates that 
>> something is 
>>> really broken.
>>>
>>> According to this definition, 
>> draft-ietf-pwe3-segmented-pw-11 should 
>>> use the defect instead of fault. In order to create consistency 
>>> between the documents, I propose that 
>> draft-ietf-pwe3-segmented-pw-11 be modified.
>>> Peter
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] 
>> On Behalf 
>>>> Of Stewart Bryant
>>>> Sent: Friday, February 20, 2009 1:46 PM
>>>> To: pwe3
>>>> Cc: [e-mail]
>>>> Subject: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
>>>>
>>>> This is the start of working group last call on
>>>>
>>>> draft-ietf-pwe3-segmented-pw-11.txt
>>>>
>>>> This draft can be found at
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-
>>>> pw-11.txt
>>>>
>>>> Monday 9th March 2009.
>>>>
>>>> Please read the document and provide feedback to the PWE3 list
>>>>
>>>> Thanks
>>>>
>>>> Stewart
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>
> 

From [e-mail]  Tue Mar 24 05:39:18 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C663A3A6D03 for <[e-mail]>; Tue, 24 Mar 2009 05:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level: 
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270,  BAYES_00=-2.599]
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 gHlHT5Kqif7C for <[e-mail]>; Tue, 24 Mar 2009 05:39:16 -0700 (PDT)
Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 8BBA73A6D08 for <[e-mail]>; Tue, 24 Mar 2009 05:39:13 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 24 Mar 2009 14:39:51 +0200
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Tue, 24 Mar 2009 14:39:51 +0200
From: Yaakov Stein <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Tue, 24 Mar 2009 14:39:46 +0200
Thread-Topic: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Thread-Index: AcmgyPWOuN2jJRCTSJyF9zjH3IElPQEnnewMAcVFsNA=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2009 12:39:18 -0000

I have a question regarding backwards compatibility.

The original VCCV drafts (versions 0-10) specified that raw BFD
is indicated by channel type zero in the CW.

Then in draft-ietf-pwe3-vccv-11 this was changed to 0x7,
and this is quoted in draft-ietf-pwe3-vccv-bfd.

Since there are existing implementations using channel type 0,=20
what does a newer implementation do when it receives a channel 0 packet ?

Y(J)S




From [e-mail]  Tue Mar 24 08:30:33 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8124628C299 for <[e-mail]>; Tue, 24 Mar 2009 08:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.607
X-Spam-Level: 
X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 0v0YFOCJWxgY for <[e-mail]>; Tue, 24 Mar 2009 08:30:32 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 6CACD28C26B for <[e-mail]>; Tue, 24 Mar 2009 08:30:32 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2OFVMmZ027534; Tue, 24 Mar 2009 11:31:22 -0400 (EDT)
Received: from [64.102.157.152] (dhcp-64-102-157-152.cisco.com [64.102.157.152]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2OFVMcT024191;  Tue, 24 Mar 2009 11:31:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 24 Mar 2009 11:31:22 -0400
From: Carlos Pignataro <[e-mail]>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Yaakov Stein <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2009 15:30:33 -0000

Hi Yaakov,

I think there's actually a two distinct (yet related) topics embedded in
the question. Here's my 2¢, and a question at the end.


1. Rules for processing ACH Channel Types

I believe this is the same topic that was covered at
<http://www.ietf.org/mail-archive/web/pwe3/current/msg10031.html>.

The thread is detailed and interesting, esp. after the fork at
<http://www.ietf.org/mail-archive/web/pwe3/current/msg10036.html>, and
it concludes that (paraphrasing):
	"the GACH/GAL draft will explicitly mention the behavior, and
	will update [RFC5085]".



2. Change in the Channel Type for BFD and backwards compatibility

There actually wasn't a change in channel type for raw BFD.

Please note that the original VCCV drafts rev -00 through -10 do not
specify a channel type of 0x0000 for raw BFD. Instead, it defined a
channel type of 0x0000 for the whole VCCV channel. This was incorrect,
as the Channel Type in the ACH can have different values depending on
what follows, values pre-defined in [RFC4385]. It was pointed out by
Sasha, yourself and myself, in this thread:
http://www.ietf.org/mail-archive/web/pwe3/current/msg08455.html
http://www.ietf.org/mail-archive/web/pwe3/current/msg08452.html
http://www.ietf.org/mail-archive/web/pwe3/current/msg08453.html


Specifically, draft-ietf-pwe3-vccv-10 says:

http://tools.ietf.org/html/draft-ietf-pwe3-vccv-10#section-4.1
  4.1. Inband VCCV (Type 1)
  ...
   The first nibble is set to 0x0001 to indicate a channel associated
   with a pseudowire [RFC4385][RFC4446]. The Format ID and the reserved
   fields are set to 0, the Version is 0, and the Channel Type is set
   to 0.

Note that this is the Section where the CC Type 1 is defined, and not
tied to any specific CV Type (it applies to LSP Ping, all BFD modes, etc).

and:
http://tools.ietf.org/html/draft-ietf-pwe3-vccv-10#section-7.1.3
  7.1.3 Channel Type
  ...
       0x00  OAM Indication (VCCV)

So this revision defines 0x00 as "OAM Indication".


This problem was pointed out in the thread I cited above, and rev-11
changed the channel type to:


http://tools.ietf.org/html/draft-ietf-pwe3-vccv-11#section-5.1
  5.1. Inband VCCV (Type 1)
  ...
   The first nibble is set to 0001b to indicate a channel associated
   with a pseudowire [RFC4385][RFC4446]. The Version and the Reserved
   fields are set to 0, the Version is 0, and the Channel Type is set
   to 0x21 for IPv4 and 0x56 for IPv6 payloads. If the payload contains
   BFD without IP/UDP headers, it MUST use 0x07 as the Channel Type
   (see 8.1.3).

(Like it breaks down the incorrect 0x00 into 0x21, 0x56 and 0x07, but
0x00 was not assigned to Raw BFD).

And:
http://tools.ietf.org/html/draft-ietf-pwe3-vccv-11#section-8.1.3
  8.1.3 Channel Type
  ...
  0007            BFD Without IP/UDP Header        [This document]


I hope this clarifies.

The question: Do you think that the vccv-bfd document needs to make any
clarifications or mentions on this respect? [I think it shouldn't (and
that was also the conclusion when discussed at
<http://www.ietf.org/mail-archive/web/pwe3/current/msg10031.html>), that
the GACH would update RFC5085, and the issue was not specific to VCCV-BFD.]

Thanks,

-- Carlos.

On 3/24/2009 8:39 AM, Yaakov Stein wrote:
> I have a question regarding backwards compatibility.
> 
> The original VCCV drafts (versions 0-10) specified that raw BFD
> is indicated by channel type zero in the CW.
> 
> Then in draft-ietf-pwe3-vccv-11 this was changed to 0x7,
> and this is quoted in draft-ietf-pwe3-vccv-bfd.
> 
> Since there are existing implementations using channel type 0, 
> what does a newer implementation do when it receives a channel 0 packet ?
> 
> Y(J)S
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 

From [e-mail]  Tue Mar 24 10:18:47 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E154C3A6A5A for <[e-mail]>; Tue, 24 Mar 2009 10:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level: 
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232,  BAYES_00=-2.599]
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 udRg3wR-D2I6 for <[e-mail]>; Tue, 24 Mar 2009 10:18:45 -0700 (PDT)
Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id BA2243A69F0 for <[e-mail]>; Tue, 24 Mar 2009 10:18:24 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 24 Mar 2009 19:19:01 +0200
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Tue, 24 Mar 2009 19:19:01 +0200
From: Yaakov Stein <[e-mail]>
To: Carlos Pignataro <[e-mail]>
Date: Tue, 24 Mar 2009 19:18:56 +0200
Thread-Topic: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Thread-Index: AcmslZv+6xsdyoRfRJmK+2B78CH/iAADhXiw
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2009 17:18:48 -0000

Carlos

Yes, I remember now the discussion about the 0 channel type
being wrong, and agree that the breakdown is right.

However, there is still the problem of what to do with a 0
(or any other undefined value).

Sorry that I missed the previous discussion on this point.

Even if it will be explained in more detail elsewhere,
it would be nice to say something to keep the documents self-contained.

Y(J)S


From [e-mail]  Tue Mar 24 10:37:39 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D2C3A6B55 for <[e-mail]>; Tue, 24 Mar 2009 10:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.607
X-Spam-Level: 
X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 raPa-DKoJWhL for <[e-mail]>; Tue, 24 Mar 2009 10:37:38 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 41A063A6D22 for <[e-mail]>; Tue, 24 Mar 2009 10:37:38 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2OHcLVc005962; Tue, 24 Mar 2009 13:38:21 -0400 (EDT)
Received: from [64.102.157.152] (dhcp-64-102-157-152.cisco.com [64.102.157.152]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2OHcL6H015831;  Tue, 24 Mar 2009 13:38:21 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 24 Mar 2009 13:38:21 -0400
From: Carlos Pignataro <[e-mail]>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Yaakov Stein <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2009 17:37:39 -0000

Yaakov,

That issue is larger than the vccv-bfd draft, and needs an update to
RFC5085 (to be done by the GAL/GACH document according to
<http://www.ietf.org/mail-archive/web/pwe3/current/msg10040.html>), plus
I think we wouldn't want to duplicate text in this doc that would need
to be kept in sync.

However, do you think we should add an Informative pointer to
<http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02#section-5> in
draft-ietf-pwe3-vccv-bfd, saying that "the procedures for handling
unrecognized or unsupported ACH Channel Types are specified in S5 of
[GACH]"? And if so, where exactly in draft-ietf-pwe3-vccv-bfd (since it
does not appear to be a proper anchor place for such text)? Other
ideas/text?

Thanks,

-- Carlos.

On 3/24/2009 1:18 PM, Yaakov Stein wrote:
> Carlos
> 
> Yes, I remember now the discussion about the 0 channel type
> being wrong, and agree that the breakdown is right.
> 
> However, there is still the problem of what to do with a 0
> (or any other undefined value).
> 
> Sorry that I missed the previous discussion on this point.
> 
> Even if it will be explained in more detail elsewhere,
> it would be nice to say something to keep the documents self-contained.
> 
> Y(J)S
> 
> 

From [e-mail]  Tue Mar 24 17:41:35 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509863A6AD8 for <[e-mail]>; Tue, 24 Mar 2009 17:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Level: 
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148,  BAYES_00=-2.599]
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 zoqfbshliyxP for <[e-mail]>; Tue, 24 Mar 2009 17:41:33 -0700 (PDT)
Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 92B393A6A5E for <[e-mail]>; Tue, 24 Mar 2009 17:41:32 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 25 Mar 2009 02:42:24 +0200
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 25 Mar 2009 02:42:23 +0200
From: Yaakov Stein <[e-mail]>
To: Carlos Pignataro <[e-mail]>
Date: Wed, 25 Mar 2009 02:42:18 +0200
Thread-Topic: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Thread-Index: Acmsp2LO0GZlZXq0RYuS6t48d0C6BwAOtddw
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2009 00:41:35 -0000

Carlos

I am not happy with putting this information in an "MPLS-TP" document,
especially one which discusses using the VCCV channel
(or whatever it is being called there) for non-PWs.

I would have no problem with a simple statement that
if non-valid channel types are received then the packet should be discarded=
.

Y(J)S

-----Original Message-----
From: Carlos Pignataro [mailto:[e-mail]]=20
Sent: Tuesday, March 24, 2009 19:38
To: Yaakov Stein
Cc: [e-mail]
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

Yaakov,

That issue is larger than the vccv-bfd draft, and needs an update to
RFC5085 (to be done by the GAL/GACH document according to
<http://www.ietf.org/mail-archive/web/pwe3/current/msg10040.html>), plus
I think we wouldn't want to duplicate text in this doc that would need
to be kept in sync.

However, do you think we should add an Informative pointer to
<http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02#section-5> in
draft-ietf-pwe3-vccv-bfd, saying that "the procedures for handling
unrecognized or unsupported ACH Channel Types are specified in S5 of
[GACH]"? And if so, where exactly in draft-ietf-pwe3-vccv-bfd (since it
does not appear to be a proper anchor place for such text)? Other
ideas/text?

Thanks,

-- Carlos.

On 3/24/2009 1:18 PM, Yaakov Stein wrote:
> Carlos
>=20
> Yes, I remember now the discussion about the 0 channel type
> being wrong, and agree that the breakdown is right.
>=20
> However, there is still the problem of what to do with a 0
> (or any other undefined value).
>=20
> Sorry that I missed the previous discussion on this point.
>=20
> Even if it will be explained in more detail elsewhere,
> it would be nice to say something to keep the documents self-contained.
>=20
> Y(J)S
>=20
>=20

From [e-mail]  Tue Mar 24 17:44:00 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6283A69E1 for <[e-mail]>; Tue, 24 Mar 2009 17:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.066
X-Spam-Level: 
X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=0.466,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067]
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 Km-PWYSBfvnx for <[e-mail]>; Tue, 24 Mar 2009 17:43:59 -0700 (PDT)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 889853A69D8 for <[e-mail]>; Tue, 24 Mar 2009 17:43:59 -0700 (PDT)
Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.102]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 25 Mar 2009 00:44:50 +0000
Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Mar 2009 00:44:49 +0000
User-Agent: Microsoft-Entourage/12.14.0.081024
Date: Tue, 24 Mar 2009 17:44:47 -0700
From: Thomas Nadeau <[e-mail]>
To: Yaakov Stein <[e-mail]>, Carlos Pignataro <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Thread-Index: Acmsp2LO0GZlZXq0RYuS6t48d0C6BwAOtddwAAAq1iM=
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 25 Mar 2009 00:44:50.0374 (UTC) FILETIME=[E786FE60:01C9ACE2]
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2009 00:44:00 -0000

On 3/24/09 5:42 PM, "Yaakov Stein" <[e-mail]> wrote:

> Carlos
> 
> I am not happy with putting this information in an "MPLS-TP" document,
> especially one which discusses using the VCCV channel
> (or whatever it is being called there) for non-PWs.
> 
> I would have no problem with a simple statement that
> if non-valid channel types are received then the packet should be discarded.

    I thought this was the default behavior, but if it helps interop, it
doesn't hurt anything so we should put it in there.

    --Tom


> 
> Y(J)S
> 
> -----Original Message-----
> From: Carlos Pignataro [mailto:[e-mail]]
> Sent: Tuesday, March 24, 2009 19:38
> To: Yaakov Stein
> Cc: [e-mail]
> Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
> 
> Yaakov,
> 
> That issue is larger than the vccv-bfd draft, and needs an update to
> RFC5085 (to be done by the GAL/GACH document according to
> <http://www.ietf.org/mail-archive/web/pwe3/current/msg10040.html>), plus
> I think we wouldn't want to duplicate text in this doc that would need
> to be kept in sync.
> 
> However, do you think we should add an Informative pointer to
> <http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02#section-5> in
> draft-ietf-pwe3-vccv-bfd, saying that "the procedures for handling
> unrecognized or unsupported ACH Channel Types are specified in S5 of
> [GACH]"? And if so, where exactly in draft-ietf-pwe3-vccv-bfd (since it
> does not appear to be a proper anchor place for such text)? Other
> ideas/text?
> 
> Thanks,
> 
> -- Carlos.
> 
> On 3/24/2009 1:18 PM, Yaakov Stein wrote:
>> Carlos
>> 
>> Yes, I remember now the discussion about the 0 channel type
>> being wrong, and agree that the breakdown is right.
>> 
>> However, there is still the problem of what to do with a 0
>> (or any other undefined value).
>> 
>> Sorry that I missed the previous discussion on this point.
>> 
>> Even if it will be explained in more detail elsewhere,
>> it would be nice to say something to keep the documents self-contained.
>> 
>> Y(J)S
>> 
>> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3


From [e-mail]  Wed Mar 25 07:43:12 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30FF28C135 for <[e-mail]>; Wed, 25 Mar 2009 07:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.773
X-Spam-Level: 
X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666]
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 SteLm3PlIeHY for <[e-mail]>; Wed, 25 Mar 2009 07:43:11 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id C390B28C108 for <[e-mail]>; Wed, 25 Mar 2009 07:43:00 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2PEhoKU014767; Wed, 25 Mar 2009 10:43:50 -0400 (EDT)
Received: from [64.102.157.152] (dhcp-64-102-157-152.cisco.com [64.102.157.152]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n2PEhnN6010976;  Wed, 25 Mar 2009 10:43:49 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Mar 2009 10:43:49 -0400
From: Carlos Pignataro <[e-mail]>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Thomas Nadeau <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Yaakov Stein <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2009 14:43:12 -0000

Yaakov, Tom,

On 3/24/2009 8:44 PM, Thomas Nadeau wrote:
> 
> 
> On 3/24/09 5:42 PM, "Yaakov Stein" <[e-mail]> wrote:
> 
>> Carlos
>>
>> I am not happy with putting this information in an "MPLS-TP" document,
>> especially one which discusses using the VCCV channel
>> (or whatever it is being called there) for non-PWs.
>>
>> I would have no problem with a simple statement that
>> if non-valid channel types are received then the packet should be discarded.
> 
>     I thought this was the default behavior, but if it helps interop, it
> doesn't hurt anything so we should put it in there.
> 

I very much agree in principle, and would like to add such statement;
but want to be a bit more cautious in practice, when also weighting in
Stewart's and Sasha's previous comments on the subject:
http://www.ietf.org/mail-archive/web/pwe3/current/msg10038.html
http://www.ietf.org/mail-archive/web/pwe3/current/msg10041.html

If we add such statement, would this document need to update RFC5085?
How do we define "non-valid channel types" in a forward-looking way and
without duplicating the text in ietf-mpls-tp-gach-gal (text welcome)?
Note that ietf-mpls-tp-gach-gal does not explicitly says it applies to
PWs. Chairs, what are your thoughts on this (esp. re. the Updates)?

If we add such statement, I think the right place would be as a
continuation of the last paragraph of Section 3.2 of ietf-pwe3-vccv-bfd.
Right?

Thanks,

-- Carlos.

>     --Tom
> 
> 
>> Y(J)S
>>
>> -----Original Message-----
>> From: Carlos Pignataro [mailto:[e-mail]]
>> Sent: Tuesday, March 24, 2009 19:38
>> To: Yaakov Stein
>> Cc: [e-mail]
>> Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
>>
>> Yaakov,
>>
>> That issue is larger than the vccv-bfd draft, and needs an update to
>> RFC5085 (to be done by the GAL/GACH document according to
>> <http://www.ietf.org/mail-archive/web/pwe3/current/msg10040.html>), plus
>> I think we wouldn't want to duplicate text in this doc that would need
>> to be kept in sync.
>>
>> However, do you think we should add an Informative pointer to
>> <http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02#section-5> in
>> draft-ietf-pwe3-vccv-bfd, saying that "the procedures for handling
>> unrecognized or unsupported ACH Channel Types are specified in S5 of
>> [GACH]"? And if so, where exactly in draft-ietf-pwe3-vccv-bfd (since it
>> does not appear to be a proper anchor place for such text)? Other
>> ideas/text?
>>
>> Thanks,
>>
>> -- Carlos.
>>
>> On 3/24/2009 1:18 PM, Yaakov Stein wrote:
>>> Carlos
>>>
>>> Yes, I remember now the discussion about the 0 channel type
>>> being wrong, and agree that the breakdown is right.
>>>
>>> However, there is still the problem of what to do with a 0
>>> (or any other undefined value).
>>>
>>> Sorry that I missed the previous discussion on this point.
>>>
>>> Even if it will be explained in more detail elsewhere,
>>> it would be nice to say something to keep the documents self-contained.
>>>
>>> Y(J)S
>>>
>>>
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 

From [e-mail]  Wed Mar 25 09:05:07 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 30) id BF99E3A6D4B; Wed, 25 Mar 2009 09:05:07 -0700 (PDT)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 25 Mar 2009 09:05:07 -0700 (PDT)
Cc: Internet Architecture Board <[e-mail]>, pwe3 mailing list <[e-mail]>, pwe3 chair <[e-mail]>, RFC Editor <[e-mail]>
Subject: [PWE3] Protocol Action: 'Definitions of Textual Conventions for Pseudowires (PW) Management' to Proposed Standard
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2009 16:05:07 -0000

The IESG has approved the following document:

- 'Definitions of Textual Conventions for Pseudowires (PW) Management '
   <draft-ietf-pwe3-pw-tc-mib-15.txt> as a Proposed Standard

This document is the product of the Pseudowire Emulation Edge to Edge 
Working Group. 

The IESG contact persons are Mark Townsley and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-15.txt

Technical Summary

This document defines a Management Information Base (MIB) module which
contains Textual Conventions (TCs) to represent commonly-used Pseudo
Wire (PW) management information. The intent is that these TCs will
be imported and used in PW-related MIB modules that would otherwise

Working Group Summary

This document has been reviewed by the experts in the PWE3 WG
and there are no outstanding issues.

Protocol Quality

This is a very simple and well written, no protocol issues are
anticipated and no outstanding technical issues exist..

Personnel
Who is the Document Shepherd for this document?

Danny McPherson ([e-mail])

Who is the Responsible Area Director?

Mark Townsley ([e-mail])


From [e-mail]  Thu Mar 26 13:23:14 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A8C3A6867 for <[e-mail]>; Thu, 26 Mar 2009 13:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.228
X-Spam-Level: 
X-Spam-Status: No, score=-17.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
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 ykvuSns38Sff for <[e-mail]>; Thu, 26 Mar 2009 13:23:13 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 8B7E33A69B9 for <[e-mail]>; Thu, 26 Mar 2009 13:23:09 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n2QKNL5g011465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Mar 2009 13:23:22 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2QKNJ8i011455; Thu, 26 Mar 2009 13:23:19 -0700 (PDT)
Date: Thu, 26 Mar 2009 13:23:19 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
From: RFC Errata System <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2009 20:23:14 -0000

The following errata report has been submitted for RFC4385,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4385&eid=1743

--------------------------------------
Type: Technical
Reported by: Yaakov (J) Stein <[e-mail]>

Section: 4, 4.1, 4.2

Original Text
-------------
The sequence number mechanism described here uses a circular unsigned
16-bit number space that excludes the value zero.
...
o The sequence number that follows 65535 (maximum unsigned 16-bit
  number) is one.
...
o If the sequence number on the packet is zero, the sequence
  integrity of the packets cannot be determined.  In this case, the
  received packet is considered to be in order.

Corrected Text
--------------
The sequence number mechanism for all PW types except the TDM PWs 
SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a 
circular unsigned 16-bit number space that excludes the value zero. 
The TDM PWs include the value zero.
...
o For all non-TDM PWs the sequence number that follows 65535 
(maximum unsigned 16-bit number) is one.
...
o If the sequence number on a non-TDM-PW packet is zero, the sequence
  integrity of the packets cannot be determined.  In this case, the
  received packet is considered to be in order.

Notes
-----
While the fact that the TDM PWs always require the sequence number and thus do not give a zero value special meaning was well-known and documented in the relevant RFCs. However, this was forgotten in this document and is causing confusion to implementers.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4385 (draft-ietf-pwe3-cw-06)
--------------------------------------
Title               : Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
Publication Date    : February 2006
Author(s)           : S. Bryant, G. Swallow, L. Martini, D. McPherson
Category            : PROPOSED STANDARD
Source              : Pseudo Wire Emulation Edge to Edge
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

From [e-mail]  Thu Mar 26 13:33:14 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6613A6987 for <[e-mail]>; Thu, 26 Mar 2009 13:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,  BAYES_00=-2.599]
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 ltseJJbY+93G for <[e-mail]>; Thu, 26 Mar 2009 13:33:13 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id E6ECA3A6867 for <[e-mail]>; Thu, 26 Mar 2009 13:32:58 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so730103qwb.31 for <[e-mail]>; Thu, 26 Mar 2009 13:33:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lEK+Hlmf9a5DriesO3r4LhGIGEk/PpkcYYi9BKGzrPw=; b=q9zpq+v0Bf+DURSxrbtvRUlntGh1GcOF8RUHPhdPnxm6W74uUhE50uvQqN71e08ylj f1+L9LCtWJoREGTUL/XpZ8vyc58BaY8ItgbiXA5lurn/Z65Nx33HrMNsxRkUaxVkWY/3 JlkYfEf0JxFIyIzs54nmP0rzrctf99yWxUBEA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ay9sx/4udX1apOyHAwoqQqX6C39vyuTMtk6dHJKe9fED9jWSxNyf8VfCOaktXAE0o1 +rnD8p3pAy5SKVsBbCHT6hCVCenRChLx9/SfMrojDLEc9VKzlwrPbDJE/OZlrT472rjl jjA4kVeUgG8EjvSxPjOScyjpEIliZOmwGrgEY=
MIME-Version: 1.0
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 26 Mar 2009 13:33:37 -0700
Received: by 10.224.73.195 with SMTP id r3mr1769742qaj.314.1238099632301; Thu,  26 Mar 2009 13:33:52 -0700 (PDT)
Message-ID: <[e-mail]>
From: "Andrew G. Malis" <[e-mail]>
To: RFC Errata System <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2009 20:33:14 -0000

This errata should also include RFC 4842 in the list of TDM PW RFCs.

Thanks,
Andy

On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
<[e-mail]> wrote:
>
> The following errata report has been submitted for RFC4385,
> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MP=
LS PSN".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4385&eid=3D1743
>
> --------------------------------------
> Type: Technical
> Reported by: Yaakov (J) Stein <[e-mail]>
>
> Section: 4, 4.1, 4.2
>
> Original Text
> -------------
> The sequence number mechanism described here uses a circular unsigned
> 16-bit number space that excludes the value zero.
> ...
> o The sequence number that follows 65535 (maximum unsigned 16-bit
> =A0number) is one.
> ...
> o If the sequence number on the packet is zero, the sequence
> =A0integrity of the packets cannot be determined. =A0In this case, the
> =A0received packet is considered to be in order.
>
> Corrected Text
> --------------
> The sequence number mechanism for all PW types except the TDM PWs
> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
> circular unsigned 16-bit number space that excludes the value zero.
> The TDM PWs include the value zero.
> ...
> o For all non-TDM PWs the sequence number that follows 65535
> (maximum unsigned 16-bit number) is one.
> ...
> o If the sequence number on a non-TDM-PW packet is zero, the sequence
> =A0integrity of the packets cannot be determined. =A0In this case, the
> =A0received packet is considered to be in order.
>
> Notes
> -----
> While the fact that the TDM PWs always require the sequence number and th=
us do not give a zero value special meaning was well-known and documented i=
n the relevant RFCs. However, this was forgotten in this document and is ca=
using confusion to implementers.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4385 (draft-ietf-pwe3-cw-06)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Pseudowire Emulation Edge-to-Edge (PW=
E3) Control Word for Use over an MPLS PSN
> Publication Date =A0 =A0: February 2006
> Author(s) =A0 =A0 =A0 =A0 =A0 : S. Bryant, G. Swallow, L. Martini, D. McP=
herson
> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Pseudo Wire Emulation Edge to Edge
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Internet
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>

From [e-mail]  Thu Mar 26 14:13:16 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021153A69FC for <[e-mail]>; Thu, 26 Mar 2009 14:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599]
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 UxgfIwOxDhMB for <[e-mail]>; Thu, 26 Mar 2009 14:13:15 -0700 (PDT)
Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id B292C3A6B99 for <[e-mail]>; Thu, 26 Mar 2009 14:12:50 -0700 (PDT)
Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 26 Mar 2009 23:11:47 +0200
Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 26 Mar 2009 23:13:43 +0200
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 26 Mar 2009 23:13:43 +0200
From: Alexander Vainshtein <[e-mail]>
To: RFC Errata System <[e-mail]>
Date: Thu, 26 Mar 2009 23:10:50 +0200
Thread-Topic: [PWE3] [Technical Errata Reported] RFC4385 (1743)
Thread-Index: AcmuUjuqJO1qhWgoTHWhP/I+oqdsZwABRtzc
Message-ID: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Mar 2009 21:13:43.0670 (UTC) FILETIME=[BE68D960:01C9AE57]
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2009 21:13:16 -0000

It may be worth noting that the ALL the TDM PW RFCs have been published AFT=
ER 4385 (which is easy to see if you compare the RFC numbers; the first TDM=
 PW RFC to go out was 4553).

So while the reporter has a point, I do not see how the problem could have =
been avoided...

My 2c.
     Sasha

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Andrew G. =
Malis [[e-mail]]
Sent: Thursday, March 26, 2009 10:33 PM
To: RFC Errata System
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];=
 [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)

This errata should also include RFC 4842 in the list of TDM PW RFCs.

Thanks,
Andy

On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
<[e-mail]> wrote:
>
> The following errata report has been submitted for RFC4385,
> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MP=
LS PSN".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4385&eid=3D1743
>
> --------------------------------------
> Type: Technical
> Reported by: Yaakov (J) Stein <[e-mail]>
>
> Section: 4, 4.1, 4.2
>
> Original Text
> -------------
> The sequence number mechanism described here uses a circular unsigned
> 16-bit number space that excludes the value zero.
> ...
> o The sequence number that follows 65535 (maximum unsigned 16-bit
>  number) is one.
> ...
> o If the sequence number on the packet is zero, the sequence
>  integrity of the packets cannot be determined.  In this case, the
>  received packet is considered to be in order.
>
> Corrected Text
> --------------
> The sequence number mechanism for all PW types except the TDM PWs
> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
> circular unsigned 16-bit number space that excludes the value zero.
> The TDM PWs include the value zero.
> ...
> o For all non-TDM PWs the sequence number that follows 65535
> (maximum unsigned 16-bit number) is one.
> ...
> o If the sequence number on a non-TDM-PW packet is zero, the sequence
>  integrity of the packets cannot be determined.  In this case, the
>  received packet is considered to be in order.
>
> Notes
> -----
> While the fact that the TDM PWs always require the sequence number and th=
us do not give a zero value special meaning was well-known and documented i=
n the relevant RFCs. However, this was forgotten in this document and is ca=
using confusion to implementers.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4385 (draft-ietf-pwe3-cw-06)
> --------------------------------------
> Title               : Pseudowire Emulation Edge-to-Edge (PWE3) Control Wo=
rd for Use over an MPLS PSN
> Publication Date    : February 2006
> Author(s)           : S. Bryant, G. Swallow, L. Martini, D. McPherson
> Category            : PROPOSED STANDARD
> Source              : Pseudo Wire Emulation Edge to Edge
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3=

From [e-mail]  Thu Mar 26 15:03:14 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0F73A6A08 for <[e-mail]>; Thu, 26 Mar 2009 15:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level: 
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.365,  BAYES_00=-2.599]
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 RhDK72iscV2q for <[e-mail]>; Thu, 26 Mar 2009 15:03:13 -0700 (PDT)
Received: from mail.baymicrosystems.com (mail.baymicrosystems.com [65.174.40.133]) by core3.amsl.com (Postfix) with ESMTP id 37AFC28C0ED for <[e-mail]>; Thu, 26 Mar 2009 15:02:58 -0700 (PDT)
Received: from [192.168.20.22] ([192.168.20.22]) (authenticated bits=0) by mail.baymicrosystems.com (8.13.5/8.13.5) with ESMTP id n2QM3ouM027367; Thu, 26 Mar 2009 15:03:51 -0700
Message-ID: <[e-mail]>
Date: Thu, 26 Mar 2009 18:01:18 -0400
From: Vikas Puri <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (X11/20061008)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: [PWE3]  InfiniBand PW's - congestion management
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2009 22:03:14 -0000

All,

   I wanted to thank everyone who participated in 
yesterday's InfiniBand pseudowire discussion and 
welcome further feedback and suggestions from the
mailing list.

   I wanted to address an open item from yesterday's 
discussion about InfiniBand PWs. Specifically, Stewart 
asked a question about how congestion within the PSN
is handled. In responding to this issue, I did not 
emphasize the method suggested in the draft and in the 
presentation that if congestion is detected at a PE, 
the PE should set the FECN bits in the IB transport 
header (going toward the attachment circuit). This 
would notify the transport source of congestion 
"somewhere" in the network. The source would, then, 
temporarily reduce its rate of packet injection 
into the network.

     However, as I hinted at in the presentation, 
congestion management is an optional feature even within 
IB. The above chain of events requires, at a minimum,
Congestion Managers to be present in an IB subnet. 

   Finally, with regard to back-pressure on the IB PW
(i.e., between the two PEs), we used Stewart's suggestion
to the Fiber Channel PW draft authors to have two
separate drafts (see attached) as guidance with regard
to what we should do with IB. We did intend to add
(or reuse) mechanisms to locally signal back, but we
want to see the base IB-encaps draft get a little further
along.

Thanks,

Vikas


Stewart Bryant wrote:
> The PWE3 chairs have reviewed the Fiber Channel draft:
>
> Encapsulation Methods for Transport of Fiber Channel frames
> Over MPLS Networks
>
> http://tools.ietf.org/html/draft-ietf-pwe3-fc-encap-08
>
> and have spent a long time thinking about how this fits in
> with the overall PWE3 architecture.
>
> It is our view that the work really describes two components:
> a reliable, congestion aware FC specific transport, which is
> then carried over a conventional PW. The PW signaling
> protocol is used to provide a number of parameters to the
> transport function.
>
> We think that it would be better if the draft was split into
> two components to reflect this.
>
> One draft should describe the transport protocol and the
> rational for developing it. This element of the protocol
> should be seen as residing in the NSP.
>
> The other draft should describe the PW for carrying that
> transport protocol and the signaling extensions needed to
> support it. This would be a regular PW.
>
> We feel that this partitioning of the work would underline
> the concept of a PW as being a relatively simple stateless
> switching function and would be more consistent with the
> multi-segment model.
>
> This restructuring means no change to the on the wire protocol.  
> We have discussed the above with the authors and with
> David Black and they have  agreed to do this split.
>
> One concern that we have is with the use of LDP to signal the
> congestion state and request a shutdown.
>
> Although FC is expected to be used in relatively low density
> applications, there is nothing to prevent high density
> implementations being built and in any case we do not want to
> set a precedent for newer PW types. We therefore think that
> work needs to be done to limit the number of PWs within an
> LDP session simultaneously requesting shutdown, perhaps by a
> restriction on the density or perhaps by introducing a group
> shutdown request. That is we should apply the PWE3 group ID
> concept to this type of PW.
>
> Finally as a WG we need to consider the tradeoffs that apply when
> an NSP wishes to take advantage of the PW signaling
> mechanism. Matthew and I propose to write a draft describing
> the use of PW signaling by the NSP, what constraints apply etc.
>
> Regards 
> Stewart & Matthew
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
   

From [e-mail]  Thu Mar 26 17:38:13 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF603A6A8E for <[e-mail]>; Thu, 26 Mar 2009 17:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.393
X-Spam-Level: 
X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.205,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 kGxHJbj9I3LX for <[e-mail]>; Thu, 26 Mar 2009 17:38:13 -0700 (PDT)
Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 4B1D328C1D8 for <[e-mail]>; Thu, 26 Mar 2009 17:37:43 -0700 (PDT)
Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 26 Mar 2009 19:38:36 -0500 (CDT)
Received: from Y73674 (dhcp-12a1.meeting.ietf.org [130.129.18.161]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 26 Mar 2009 19:38:36 -0500 (CDT)
Date: Thu, 26 Mar 2009 19:38:39 -0500
From: Lucy Yong <[e-mail]>
To: [e-mail]
Message-id: <002c01c9ae74$5fa15de0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_bqzFwahvq3GYwjk30TlAHw)"
Thread-index: AcmudF7/dKF4xUkwSNGziNklea+UIg==
Subject: [PWE3] Flow Label in fat-pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 00:38:13 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_bqzFwahvq3GYwjk30TlAHw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Bryant,

 

One comment about using flow label over a pseudowire is:  if the control
word is used in a pseudowire and non-zero sequence number is inserted, when
using flow labels, it may cause the egress PE burden to perform packet
sequencing and increase the possibility of packet out of order. Therefore,
it is better to mention in the draft that when the control word presents and
non-zero sequence number is used, the flow label should not be used or if it
is used, the constant flow label should be used.

 

Regards,

Lucy

 


--Boundary_(ID_bqzFwahvq3GYwjk30TlAHw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Tahoma;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Hi Bryant,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>One comment about using flow label over a pseudowire is: &nbsp;if
the control word is used in a pseudowire and non-zero sequence number is
inserted, when using flow labels, it may cause the egress PE burden to perform
packet sequencing and increase the possibility of packet out of order. Therefore,
it is better to mention in the draft that when the control word presents and
non-zero sequence number is used, the flow label should not be used or if it is
used, the constant flow label should be used.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Regards,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Lucy<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_bqzFwahvq3GYwjk30TlAHw)--

From [e-mail]  Thu Mar 26 19:24:11 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7193A699A; Thu, 26 Mar 2009 19:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.853
X-Spam-Level: 
X-Spam-Status: No, score=-93.853 tagged_above=-999 required=5 tests=[AWL=-1.063, 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 E6tHXHaVqmme; Thu, 26 Mar 2009 19:24:10 -0700 (PDT)
Received: from out1.zte.com.cn (out1.zte.com.cn [202.103.147.172]) by core3.amsl.com (Postfix) with ESMTP id 0B4083A6807; Thu, 26 Mar 2009 19:24:07 -0700 (PDT)
Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 64667.16409340045; Fri, 27 Mar 2009 10:22:23 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n2R2P1Cf091233; Fri, 27 Mar 2009 10:25:01 +0800 (CST) (envelope-from [e-mail])
In-Reply-To: <[e-mail]>
To: RFC Errata System <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 27 Mar 2009 10:24:46 +0800
X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-27 10:25:03, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-27 10:25:03, Serialize complete at 2009-03-27 10:25:03, S/MIME Sign failed at 2009-03-27 10:25:03:  =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-27 10:24:54, Serialize complete at 2009-03-27 10:24:54
Content-Type: multipart/alternative; boundary="=_alternative 000D47CE48257586_="
X-MAIL: mse2.zte.com.cn n2R2P1Cf091233
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [PWE3] =?gb2312?b?tPC4tDogIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVk?= =?gb2312?b?XSBSRkM0Mzg1ICgxNzQzKQ==?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 02:24:11 -0000

This is a multipart message in MIME format.
--=_alternative 000D47CE48257586_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

U0FUb1AgW1JGQzQzMzVdIG1pZ2h0IGJlIDQ1NTMsIHJpZ2h0Pw0KYW5kIDEgbW9yZSBxdWVzdGlv
biwgSSBkbyBub3QgcXVpdGUgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSBiL3cgVERNIFBXIA0K
c2VxIGFuZCBub24tVE1EIFBXIHNlcXVlbmNlICMNCg0KSW4gU0FUb1AgUkZDLCBpdCBzYXlzOg0K
Ig0KICAgU2VxdWVuY2UgbnVtYmVyIC0gdXNlZCB0byBwcm92aWRlIHRoZSBjb21tb24gUFcgc2Vx
dWVuY2luZyBmdW5jdGlvbg0KICAgICAgIGFzIHdlbGwgYXMgZGV0ZWN0aW9uIG9mIGxvc3QgcGFj
a2V0cy4gIEl0IE1VU1QgYmUgZ2VuZXJhdGVkIGluDQogICAgICAgYWNjb3JkYW5jZSB3aXRoIHRo
ZSBydWxlcyBkZWZpbmVkIGluIFNlY3Rpb24gNS4xIG9mIFtSRkMzNTUwXSBmb3INCiAgICAgICB0
aGUgUlRQIHNlcXVlbmNlIG51bWJlcjoNCg0KICAgICAgICAgbyBJdHMgc3BhY2UgaXMgYSAxNi1i
aXQgdW5zaWduZWQgY2lyY3VsYXIgc3BhY2UNCiAgICAgICAgIG8gSXRzIGluaXRpYWwgdmFsdWUg
U0hPVUxEIGJlIHJhbmRvbSAodW5wcmVkaWN0YWJsZSkuDQoNCiAgICAgICBJdCBNVVNUIGJlIGlu
Y3JlbWVudGVkIHdpdGggZWFjaCBTQVRvUCBkYXRhIHBhY2tldCBzZW50IGluIHRoZQ0KICAgICAg
IHNwZWNpZmljIFBXLg0KIg0KDQoNCg0KDQoNClJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9y
QHJmYy1lZGl0b3Iub3JnPiANCreivP7IyzogIHB3ZTMtYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0w
My0yNyAwNDoyMw0KDQrK1bz+yMsNCnN0YnJ5YW50QGNpc2NvLmNvbSwgc3dhbGxvd0BjaXNjby5j
b20sIGxtYXJ0aW5pQGNpc2NvLmNvbSwgDQpkYW5ueUBhcmJvci5uZXQsIHJkcm9tc0BjaXNjby5j
b20sIGphcmkuYXJra29AcGl1aGEubmV0LCANCnRvd25zbGV5QGNpc2NvLmNvbSwgc3RicnlhbnRA
Y2lzY28uY29tLCBtYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbQ0Ks63LzQ0KeWFha292
X3NAcmFkLmNvbSwgcHdlM0BpZXRmLm9yZywgcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZw0K1vfM
4g0KW1BXRTNdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM0Mzg1ICgxNzQzKQ0KDQoN
Cg0KDQoNCg0KDQpUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVk
IGZvciBSRkM0Mzg1LA0KIlBzZXVkb3dpcmUgRW11bGF0aW9uIEVkZ2UtdG8tRWRnZSAoUFdFMykg
Q29udHJvbCBXb3JkIGZvciBVc2Ugb3ZlciBhbiANCk1QTFMgUFNOIi4NCg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCllvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVs
b3cgYW5kIGF0Og0KaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9y
ZmM9NDM4NSZlaWQ9MTc0Mw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KVHlwZTogVGVjaG5pY2FsDQpSZXBvcnRlZCBieTogWWFha292IChKKSBTdGVpbiA8eWFha292
X3NAcmFkLmNvbT4NCg0KU2VjdGlvbjogNCwgNC4xLCA0LjINCg0KT3JpZ2luYWwgVGV4dA0KLS0t
LS0tLS0tLS0tLQ0KVGhlIHNlcXVlbmNlIG51bWJlciBtZWNoYW5pc20gZGVzY3JpYmVkIGhlcmUg
dXNlcyBhIGNpcmN1bGFyIHVuc2lnbmVkDQoxNi1iaXQgbnVtYmVyIHNwYWNlIHRoYXQgZXhjbHVk
ZXMgdGhlIHZhbHVlIHplcm8uDQouLi4NCm8gVGhlIHNlcXVlbmNlIG51bWJlciB0aGF0IGZvbGxv
d3MgNjU1MzUgKG1heGltdW0gdW5zaWduZWQgMTYtYml0DQogIG51bWJlcikgaXMgb25lLg0KLi4u
DQpvIElmIHRoZSBzZXF1ZW5jZSBudW1iZXIgb24gdGhlIHBhY2tldCBpcyB6ZXJvLCB0aGUgc2Vx
dWVuY2UNCiAgaW50ZWdyaXR5IG9mIHRoZSBwYWNrZXRzIGNhbm5vdCBiZSBkZXRlcm1pbmVkLiAg
SW4gdGhpcyBjYXNlLCB0aGUNCiAgcmVjZWl2ZWQgcGFja2V0IGlzIGNvbnNpZGVyZWQgdG8gYmUg
aW4gb3JkZXIuDQoNCkNvcnJlY3RlZCBUZXh0DQotLS0tLS0tLS0tLS0tLQ0KVGhlIHNlcXVlbmNl
IG51bWJlciBtZWNoYW5pc20gZm9yIGFsbCBQVyB0eXBlcyBleGNlcHQgdGhlIFRETSBQV3MgDQpT
QVRvUCBbUkZDNDMzNV0sIENFU29QU04gW1JGQzUwODZdLCBhbmQgVERNb0lQIFtSRkM1MDg3XSB1
c2UgYSANCmNpcmN1bGFyIHVuc2lnbmVkIDE2LWJpdCBudW1iZXIgc3BhY2UgdGhhdCBleGNsdWRl
cyB0aGUgdmFsdWUgemVyby4gDQpUaGUgVERNIFBXcyBpbmNsdWRlIHRoZSB2YWx1ZSB6ZXJvLg0K
Li4uDQpvIEZvciBhbGwgbm9uLVRETSBQV3MgdGhlIHNlcXVlbmNlIG51bWJlciB0aGF0IGZvbGxv
d3MgNjU1MzUgDQoobWF4aW11bSB1bnNpZ25lZCAxNi1iaXQgbnVtYmVyKSBpcyBvbmUuDQouLi4N
Cm8gSWYgdGhlIHNlcXVlbmNlIG51bWJlciBvbiBhIG5vbi1URE0tUFcgcGFja2V0IGlzIHplcm8s
IHRoZSBzZXF1ZW5jZQ0KICBpbnRlZ3JpdHkgb2YgdGhlIHBhY2tldHMgY2Fubm90IGJlIGRldGVy
bWluZWQuICBJbiB0aGlzIGNhc2UsIHRoZQ0KICByZWNlaXZlZCBwYWNrZXQgaXMgY29uc2lkZXJl
ZCB0byBiZSBpbiBvcmRlci4NCg0KTm90ZXMNCi0tLS0tDQpXaGlsZSB0aGUgZmFjdCB0aGF0IHRo
ZSBURE0gUFdzIGFsd2F5cyByZXF1aXJlIHRoZSBzZXF1ZW5jZSBudW1iZXIgYW5kIA0KdGh1cyBk
byBub3QgZ2l2ZSBhIHplcm8gdmFsdWUgc3BlY2lhbCBtZWFuaW5nIHdhcyB3ZWxsLWtub3duIGFu
ZCANCmRvY3VtZW50ZWQgaW4gdGhlIHJlbGV2YW50IFJGQ3MuIEhvd2V2ZXIsIHRoaXMgd2FzIGZv
cmdvdHRlbiBpbiB0aGlzIA0KZG9jdW1lbnQgYW5kIGlzIGNhdXNpbmcgY29uZnVzaW9uIHRvIGlt
cGxlbWVudGVycy4NCg0KSW5zdHJ1Y3Rpb25zOg0KLS0tLS0tLS0tLS0tLQ0KVGhpcyBlcnJhdGEg
aXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0K
dXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQg
b3INCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBw
YXJ0eSAoSUVTRykNCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhl
IHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NClJGQzQzODUgKGRyYWZ0LWlldGYtcHdlMy1jdy0wNikNCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaXRsZSAgICAgICAgICAgICAgIDogUHNldWRvd2ly
ZSBFbXVsYXRpb24gRWRnZS10by1FZGdlIChQV0UzKSBDb250cm9sIA0KV29yZCBmb3IgVXNlIG92
ZXIgYW4gTVBMUyBQU04NClB1YmxpY2F0aW9uIERhdGUgICAgOiBGZWJydWFyeSAyMDA2DQpBdXRo
b3IocykgICAgICAgICAgIDogUy4gQnJ5YW50LCBHLiBTd2FsbG93LCBMLiBNYXJ0aW5pLCBELiBN
Y1BoZXJzb24NCkNhdGVnb3J5ICAgICAgICAgICAgOiBQUk9QT1NFRCBTVEFOREFSRA0KU291cmNl
ICAgICAgICAgICAgICA6IFBzZXVkbyBXaXJlIEVtdWxhdGlvbiBFZGdlIHRvIEVkZ2UNCkFyZWEg
ICAgICAgICAgICAgICAgOiBJbnRlcm5ldA0KU3RyZWFtICAgICAgICAgICAgICA6IElFVEYNClZl
cmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KcHdlMyBtYWlsaW5nIGxpc3QNCnB3ZTNAaWV0Zi5vcmcNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0KDQoNCg==
--=_alternative 000D47CE48257586_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5TQVRvUCBbUkZDNDMzNTwvdHQ+PC9mb250Pjxmb250IHNp
emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5dDQptaWdodCBiZSA0NTUzLCByaWdodD88L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZCAxIG1vcmUgcXVlc3Rpb24sIEkg
ZG8gbm90IHF1aXRlDQp1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGIvdyBURE0gUFcgc2VxIGFu
ZCBub24tVE1EIFBXIHNlcXVlbmNlICM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPkluIFNBVG9QIFJGQywgaXQgc2F5czo8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+
PHR0PiZuYnNwOyAmbmJzcDtTZXF1ZW5jZSBudW1iZXIgLSB1c2VkIHRvIHByb3ZpZGUgdGhlDQpj
b21tb24gUFcgc2VxdWVuY2luZyBmdW5jdGlvbjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBh
cyB3ZWxsIGFzIGRldGVjdGlvbiBvZiBsb3N0IHBhY2tldHMuICZuYnNwO0l0IE1VU1QNCmJlIGdl
bmVyYXRlZCBpbjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhY2NvcmRhbmNlIHdpdGggdGhl
IHJ1bGVzIGRlZmluZWQgaW4gU2VjdGlvbiA1LjENCm9mIFtSRkMzNTUwXSBmb3I8YnI+DQogJm5i
c3A7ICZuYnNwOyAmbmJzcDsgdGhlIFJUUCBzZXF1ZW5jZSBudW1iZXI6PGJyPg0KPGJyPg0KICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvIEl0cyBzcGFjZSBpcyBhIDE2LWJpdCB1bnNpZ25l
ZCBjaXJjdWxhcg0Kc3BhY2U8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG8gSXRz
IGluaXRpYWwgdmFsdWUgU0hPVUxEIGJlIHJhbmRvbSAodW5wcmVkaWN0YWJsZSkuPGJyPg0KPGJy
Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IEl0IE1VU1QgYmUgaW5jcmVtZW50ZWQgd2l0aCBlYWNo
IFNBVG9QIGRhdGEgcGFja2V0DQpzZW50IGluIHRoZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw
OyBzcGVjaWZpYyBQVy48YnI+DQomcXVvdDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl
IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0x
IGZhY2U9InNhbnMtc2VyaWYiPjxiPlJGQyBFcnJhdGEgU3lzdGVtICZsdDtyZmMtZWRpdG9yQHJm
Yy1lZGl0b3Iub3JnJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48
Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wMy0yNyAwNDoyMzwvZm9udD4NCjx0
ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K
PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m
b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5zdGJyeWFudEBj
aXNjby5jb20sIHN3YWxsb3dAY2lzY28uY29tLA0KbG1hcnRpbmlAY2lzY28uY29tLCBkYW5ueUBh
cmJvci5uZXQsIHJkcm9tc0BjaXNjby5jb20sIGphcmkuYXJra29AcGl1aGEubmV0LA0KdG93bnNs
ZXlAY2lzY28uY29tLCBzdGJyeWFudEBjaXNjby5jb20sIG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1s
dWNlbnQuY29tPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0
Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm
b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj55YWFrb3Zfc0ByYWQuY29tLCBwd2UzQGlldGYu
b3JnLCByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8
dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi
PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bUFdFM10g
W1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzQzODUNCigxNzQzKTwvZm9udD48L3RhYmxl
Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi
cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KVGhlIGZv
bGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNDM4NSw8YnI+
DQomcXVvdDtQc2V1ZG93aXJlIEVtdWxhdGlvbiBFZGdlLXRvLUVkZ2UgKFBXRTMpIENvbnRyb2wg
V29yZCBmb3IgVXNlIG92ZXINCmFuIE1QTFMgUFNOJnF1b3Q7Ljxicj4NCjxicj4NCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWW91IG1heSByZXZpZXcgdGhlIHJl
cG9ydCBiZWxvdyBhbmQgYXQ6PGJyPg0KaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFf
c2VhcmNoLnBocD9yZmM9NDM4NSZhbXA7ZWlkPTE3NDM8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClR5cGU6IFRlY2huaWNhbDxicj4NClJlcG9y
dGVkIGJ5OiBZYWFrb3YgKEopIFN0ZWluICZsdDt5YWFrb3Zfc0ByYWQuY29tJmd0Ozxicj4NCjxi
cj4NClNlY3Rpb246IDQsIDQuMSwgNC4yPGJyPg0KPGJyPg0KT3JpZ2luYWwgVGV4dDxicj4NCi0t
LS0tLS0tLS0tLS08YnI+DQpUaGUgc2VxdWVuY2UgbnVtYmVyIG1lY2hhbmlzbSBkZXNjcmliZWQg
aGVyZSB1c2VzIGEgY2lyY3VsYXIgdW5zaWduZWQ8YnI+DQoxNi1iaXQgbnVtYmVyIHNwYWNlIHRo
YXQgZXhjbHVkZXMgdGhlIHZhbHVlIHplcm8uPGJyPg0KLi4uPGJyPg0KbyBUaGUgc2VxdWVuY2Ug
bnVtYmVyIHRoYXQgZm9sbG93cyA2NTUzNSAobWF4aW11bSB1bnNpZ25lZCAxNi1iaXQ8YnI+DQog
Jm5ic3A7bnVtYmVyKSBpcyBvbmUuPGJyPg0KLi4uPGJyPg0KbyBJZiB0aGUgc2VxdWVuY2UgbnVt
YmVyIG9uIHRoZSBwYWNrZXQgaXMgemVybywgdGhlIHNlcXVlbmNlPGJyPg0KICZuYnNwO2ludGVn
cml0eSBvZiB0aGUgcGFja2V0cyBjYW5ub3QgYmUgZGV0ZXJtaW5lZC4gJm5ic3A7SW4gdGhpcyBj
YXNlLA0KdGhlPGJyPg0KICZuYnNwO3JlY2VpdmVkIHBhY2tldCBpcyBjb25zaWRlcmVkIHRvIGJl
IGluIG9yZGVyLjxicj4NCjxicj4NCkNvcnJlY3RlZCBUZXh0PGJyPg0KLS0tLS0tLS0tLS0tLS08
YnI+DQpUaGUgc2VxdWVuY2UgbnVtYmVyIG1lY2hhbmlzbSBmb3IgYWxsIFBXIHR5cGVzIGV4Y2Vw
dCB0aGUgVERNIFBXcyA8YnI+DQpTQVRvUCBbUkZDNDMzNV0sIENFU29QU04gW1JGQzUwODZdLCBh
bmQgVERNb0lQIFtSRkM1MDg3XSB1c2UgYSA8YnI+DQpjaXJjdWxhciB1bnNpZ25lZCAxNi1iaXQg
bnVtYmVyIHNwYWNlIHRoYXQgZXhjbHVkZXMgdGhlIHZhbHVlIHplcm8uIDxicj4NClRoZSBURE0g
UFdzIGluY2x1ZGUgdGhlIHZhbHVlIHplcm8uPGJyPg0KLi4uPGJyPg0KbyBGb3IgYWxsIG5vbi1U
RE0gUFdzIHRoZSBzZXF1ZW5jZSBudW1iZXIgdGhhdCBmb2xsb3dzIDY1NTM1IDxicj4NCihtYXhp
bXVtIHVuc2lnbmVkIDE2LWJpdCBudW1iZXIpIGlzIG9uZS48YnI+DQouLi48YnI+DQpvIElmIHRo
ZSBzZXF1ZW5jZSBudW1iZXIgb24gYSBub24tVERNLVBXIHBhY2tldCBpcyB6ZXJvLCB0aGUgc2Vx
dWVuY2U8YnI+DQogJm5ic3A7aW50ZWdyaXR5IG9mIHRoZSBwYWNrZXRzIGNhbm5vdCBiZSBkZXRl
cm1pbmVkLiAmbmJzcDtJbiB0aGlzIGNhc2UsDQp0aGU8YnI+DQogJm5ic3A7cmVjZWl2ZWQgcGFj
a2V0IGlzIGNvbnNpZGVyZWQgdG8gYmUgaW4gb3JkZXIuPGJyPg0KPGJyPg0KTm90ZXM8YnI+DQot
LS0tLTxicj4NCldoaWxlIHRoZSBmYWN0IHRoYXQgdGhlIFRETSBQV3MgYWx3YXlzIHJlcXVpcmUg
dGhlIHNlcXVlbmNlIG51bWJlciBhbmQNCnRodXMgZG8gbm90IGdpdmUgYSB6ZXJvIHZhbHVlIHNw
ZWNpYWwgbWVhbmluZyB3YXMgd2VsbC1rbm93biBhbmQgZG9jdW1lbnRlZA0KaW4gdGhlIHJlbGV2
YW50IFJGQ3MuIEhvd2V2ZXIsIHRoaXMgd2FzIGZvcmdvdHRlbiBpbiB0aGlzIGRvY3VtZW50IGFu
ZA0KaXMgY2F1c2luZyBjb25mdXNpb24gdG8gaW1wbGVtZW50ZXJzLjxicj4NCjxicj4NCkluc3Ry
dWN0aW9uczo8YnI+DQotLS0tLS0tLS0tLS0tPGJyPg0KVGhpcyBlcnJhdGEgaXMgY3VycmVudGx5
IHBvc3RlZCBhcyAmcXVvdDtSZXBvcnRlZCZxdW90Oy4gSWYgbmVjZXNzYXJ5LA0KcGxlYXNlPGJy
Pg0KdXNlICZxdW90O1JlcGx5IEFsbCZxdW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxk
IGJlIHZlcmlmaWVkIG9yPGJyPg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVk
LCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKTxicj4NCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRo
ZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiA8YnI+DQo8YnI+DQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClJGQzQzODUgKGRyYWZ0
LWlldGYtcHdlMy1jdy0wNik8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLTxicj4NClRpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyA6IFBzZXVkb3dpcmUgRW11bGF0aW9uDQpFZGdlLXRvLUVkZ2UgKFBXRTMpIENvbnRy
b2wgV29yZCBmb3IgVXNlIG92ZXIgYW4gTVBMUyBQU048YnI+DQpQdWJsaWNhdGlvbiBEYXRlICZu
YnNwOyAmbmJzcDs6IEZlYnJ1YXJ5IDIwMDY8YnI+DQpBdXRob3IocykgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyA6IFMuIEJyeWFudCwgRy4gU3dhbGxvdywgTC4NCk1hcnRpbmks
IEQuIE1jUGhlcnNvbjxicj4NCkNhdGVnb3J5ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7OiBQUk9QT1NFRCBTVEFOREFSRDxicj4NClNvdXJjZSAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFBzZXVkbyBXaXJlIEVtdWxhdGlv
bg0KRWRnZSB0byBFZGdlPGJyPg0KQXJlYSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBJbnRlcm5ldDxicj4NClN0cmVhbSAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IElFVEY8YnI+DQpWZXJpZnlp
bmcgUGFydHkgJm5ic3A7ICZuYnNwOyA6IElFU0c8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdl
M0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdl
Mzxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K
--=_alternative 000D47CE48257586_=--

From [e-mail]  Thu Mar 26 19:45:48 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841CF3A693B for <[e-mail]>; Thu, 26 Mar 2009 19:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.187
X-Spam-Level: 
X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[AWL=2.785,  BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 I331eLqAfK9p for <[e-mail]>; Thu, 26 Mar 2009 19:45:47 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 48F6E3A695C for <[e-mail]>; Thu, 26 Mar 2009 19:45:47 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 27 Mar 2009 10:46:38 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 27 Mar 2009 10:46:38 +0800 (CST)
Received: from j59929 ([10.70.77.144]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 27 Mar 2009 10:46:38 +0800 (CST)
Date: Fri, 27 Mar 2009 10:46:38 +0800
From: Jiang Yuan-long <[e-mail]>
To: [e-mail]
Message-id: <018e01c9ae86$40543180$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 02:45:48 -0000

A correction to the errata:
"SAToP [RFC4335]" should be:
SAToP [RFC4553]

Regards,
Jiang

----- Original Message ----- 
From: "Andrew G. Malis" <[e-mail]>
To: "RFC Errata System" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Sent: Friday, March 27, 2009 4:33 AM
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)


This errata should also include RFC 4842 in the list of TDM PW RFCs.

Thanks,
Andy

On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
<[e-mail]> wrote:
>
> The following errata report has been submitted for RFC4385,
> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an 
> MPLS PSN".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4385&eid=1743
>
> --------------------------------------
> Type: Technical
> Reported by: Yaakov (J) Stein <[e-mail]>
>
> Section: 4, 4.1, 4.2
>
> Original Text
> -------------
> The sequence number mechanism described here uses a circular unsigned
> 16-bit number space that excludes the value zero.
> ...
> o The sequence number that follows 65535 (maximum unsigned 16-bit
> number) is one.
> ...
> o If the sequence number on the packet is zero, the sequence
> integrity of the packets cannot be determined. In this case, the
> received packet is considered to be in order.
>
> Corrected Text
> --------------
> The sequence number mechanism for all PW types except the TDM PWs
> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
> circular unsigned 16-bit number space that excludes the value zero.
> The TDM PWs include the value zero.
> ...
> o For all non-TDM PWs the sequence number that follows 65535
> (maximum unsigned 16-bit number) is one.
> ...
> o If the sequence number on a non-TDM-PW packet is zero, the sequence
> integrity of the packets cannot be determined. In this case, the
> received packet is considered to be in order.
>
> Notes
> -----
> While the fact that the TDM PWs always require the sequence number and 
> thus do not give a zero value special meaning was well-known and 
> documented in the relevant RFCs. However, this was forgotten in this 
> document and is causing confusion to implementers.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4385 (draft-ietf-pwe3-cw-06)
> --------------------------------------
> Title : Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over 
> an MPLS PSN
> Publication Date : February 2006
> Author(s) : S. Bryant, G. Swallow, L. Martini, D. McPherson
> Category : PROPOSED STANDARD
> Source : Pseudo Wire Emulation Edge to Edge
> Area : Internet
> Stream : IETF
> Verifying Party : IESG
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3 


From [e-mail]  Thu Mar 26 19:46:59 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6830B3A6966 for <[e-mail]>; Thu, 26 Mar 2009 19:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599]
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 RxxAlOESh2yP for <[e-mail]>; Thu, 26 Mar 2009 19:46:56 -0700 (PDT)
Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id 7F13F3A696C for <[e-mail]>; Thu, 26 Mar 2009 19:46:53 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 27 Mar 2009 05:47:46 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Fri, 27 Mar 2009 05:47:46 +0300
From: Yaakov Stein <[e-mail]>
To: Alexander Vainshtein <[e-mail]>, RFC Errata System <[e-mail]>
Date: Fri, 27 Mar 2009 05:47:37 +0300
Thread-Topic: [PWE3] [Technical Errata Reported] RFC4385 (1743)
Thread-Index: AcmuUjuqJO1qhWgoTHWhP/I+oqdsZwABRtzcAAuTxTA=
Message-ID: <[e-mail]>
References: <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 02:46:59 -0000

Well, the authors of 4385 knew full well about the issue,
and tried to delicately indicate this.

They say that an encap draft is allowed to propose another algorithm,
but if the algorithm described in this document is used
then the zero value is skipped.

Unfortunately, this subtlety was missed by a major vendor
whose implementation skips zero for TDM PWs, and this vendor
claims that 4385 being standards-track trumps 5086 being informative.
Furthermore, this vendor claims that the wording in SAToP and CESoPSN
does not explicitly state that the zero value is NOT skipped,
rather point to 3550, which says nothing of value.

Anyway, this misunderstanding brought a multivendor network down.

Y(J)S

 =20

-----Original Message-----
From: Alexander Vainshtein [mailto:[e-mail]]=20
Sent: Thursday, March 26, 2009 23:11
To: RFC Errata System
Cc: [e-mail]; Yaakov Stein; [e-mail]; [e-mail]; rdr=
[e-mail]; [e-mail]; [e-mail]; [e-mail]; And=
rew G. Malis
Subject: RE: [PWE3] [Technical Errata Reported] RFC4385 (1743)

It may be worth noting that the ALL the TDM PW RFCs have been published AFT=
ER 4385 (which is easy to see if you compare the RFC numbers; the first TDM=
 PW RFC to go out was 4553).

So while the reporter has a point, I do not see how the problem could have =
been avoided...

My 2c.
     Sasha

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Andrew G. =
Malis [[e-mail]]
Sent: Thursday, March 26, 2009 10:33 PM
To: RFC Errata System
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];=
 [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)

This errata should also include RFC 4842 in the list of TDM PW RFCs.

Thanks,
Andy

On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
<[e-mail]> wrote:
>
> The following errata report has been submitted for RFC4385,
> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MP=
LS PSN".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4385&eid=3D1743
>
> --------------------------------------
> Type: Technical
> Reported by: Yaakov (J) Stein <[e-mail]>
>
> Section: 4, 4.1, 4.2
>
> Original Text
> -------------
> The sequence number mechanism described here uses a circular unsigned
> 16-bit number space that excludes the value zero.
> ...
> o The sequence number that follows 65535 (maximum unsigned 16-bit
>  number) is one.
> ...
> o If the sequence number on the packet is zero, the sequence
>  integrity of the packets cannot be determined.  In this case, the
>  received packet is considered to be in order.
>
> Corrected Text
> --------------
> The sequence number mechanism for all PW types except the TDM PWs
> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
> circular unsigned 16-bit number space that excludes the value zero.
> The TDM PWs include the value zero.
> ...
> o For all non-TDM PWs the sequence number that follows 65535
> (maximum unsigned 16-bit number) is one.
> ...
> o If the sequence number on a non-TDM-PW packet is zero, the sequence
>  integrity of the packets cannot be determined.  In this case, the
>  received packet is considered to be in order.
>
> Notes
> -----
> While the fact that the TDM PWs always require the sequence number and th=
us do not give a zero value special meaning was well-known and documented i=
n the relevant RFCs. However, this was forgotten in this document and is ca=
using confusion to implementers.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4385 (draft-ietf-pwe3-cw-06)
> --------------------------------------
> Title               : Pseudowire Emulation Edge-to-Edge (PWE3) Control Wo=
rd for Use over an MPLS PSN
> Publication Date    : February 2006
> Author(s)           : S. Bryant, G. Swallow, L. Martini, D. McPherson
> Category            : PROPOSED STANDARD
> Source              : Pseudo Wire Emulation Edge to Edge
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3

From [e-mail]  Thu Mar 26 19:47:45 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B523A696C for <[e-mail]>; Thu, 26 Mar 2009 19:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level: 
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599]
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 7k8aGqhQvizb for <[e-mail]>; Thu, 26 Mar 2009 19:47:43 -0700 (PDT)
Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id BF38C3A67D9 for <[e-mail]>; Thu, 26 Mar 2009 19:47:42 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 27 Mar 2009 05:48:35 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Fri, 27 Mar 2009 05:48:35 +0300
From: Yaakov Stein <[e-mail]>
To: Jiang Yuan-long <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 27 Mar 2009 05:48:28 +0300
Thread-Topic: [PWE3] [Technical Errata Reported] RFC4385 (1743)
Thread-Index: AcmuhkXQYwJdE2DMQWKix+lgC8RqkgAADGRQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <018e01c9ae86$40543180$[e-mail]>
In-Reply-To: <018e01c9ae86$40543180$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 02:47:45 -0000

ooops  (I'm only an author, I never read the thing)

Y(J)S

-----Original Message-----
From: Jiang Yuan-long [mailto:[e-mail]]=20
Sent: Friday, March 27, 2009 05:47
To: [e-mail]
Cc: Andrew G. Malis; [e-mail]; Yaakov Stein; [e-mail]=
; [e-mail]; [e-mail]; [e-mail]; [e-mail]=
; [e-mail]
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)

A correction to the errata:
"SAToP [RFC4335]" should be:
SAToP [RFC4553]

Regards,
Jiang

----- Original Message -----=20
From: "Andrew G. Malis" <[e-mail]>
To: "RFC Errata System" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;=20
<[e-mail]>; <[e-mail]>; <[e-mail]>;=20
<[e-mail]>; <[e-mail]>
Sent: Friday, March 27, 2009 4:33 AM
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)


This errata should also include RFC 4842 in the list of TDM PW RFCs.

Thanks,
Andy

On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
<[e-mail]> wrote:
>
> The following errata report has been submitted for RFC4385,
> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an=20
> MPLS PSN".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4385&eid=3D1743
>
> --------------------------------------
> Type: Technical
> Reported by: Yaakov (J) Stein <[e-mail]>
>
> Section: 4, 4.1, 4.2
>
> Original Text
> -------------
> The sequence number mechanism described here uses a circular unsigned
> 16-bit number space that excludes the value zero.
> ...
> o The sequence number that follows 65535 (maximum unsigned 16-bit
> number) is one.
> ...
> o If the sequence number on the packet is zero, the sequence
> integrity of the packets cannot be determined. In this case, the
> received packet is considered to be in order.
>
> Corrected Text
> --------------
> The sequence number mechanism for all PW types except the TDM PWs
> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
> circular unsigned 16-bit number space that excludes the value zero.
> The TDM PWs include the value zero.
> ...
> o For all non-TDM PWs the sequence number that follows 65535
> (maximum unsigned 16-bit number) is one.
> ...
> o If the sequence number on a non-TDM-PW packet is zero, the sequence
> integrity of the packets cannot be determined. In this case, the
> received packet is considered to be in order.
>
> Notes
> -----
> While the fact that the TDM PWs always require the sequence number and=20
> thus do not give a zero value special meaning was well-known and=20
> documented in the relevant RFCs. However, this was forgotten in this=20
> document and is causing confusion to implementers.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4385 (draft-ietf-pwe3-cw-06)
> --------------------------------------
> Title : Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use ove=
r=20
> an MPLS PSN
> Publication Date : February 2006
> Author(s) : S. Bryant, G. Swallow, L. Martini, D. McPherson
> Category : PROPOSED STANDARD
> Source : Pseudo Wire Emulation Edge to Edge
> Area : Internet
> Stream : IETF
> Verifying Party : IESG
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3=20


From [e-mail]  Thu Mar 26 20:05:38 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C97C3A696C for <[e-mail]>; Thu, 26 Mar 2009 20:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.021
X-Spam-Level: **
X-Spam-Status: No, score=2.021 tagged_above=-999 required=5 tests=[AWL=-4.429,  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, SARE_SUB_ENC_GB2312=1.345]
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 TE1qvwUcgN2y for <[e-mail]>; Thu, 26 Mar 2009 20:05:33 -0700 (PDT)
Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id 09BE63A67D9 for <[e-mail]>; Thu, 26 Mar 2009 20:05:32 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 27 Mar 2009 06:06:26 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Fri, 27 Mar 2009 06:06:26 +0300
From: Yaakov Stein <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Fri, 27 Mar 2009 06:06:18 +0300
Thread-Topic: =?gb2312?B?W1BXRTNdILTwuLQ6ICBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZD?= =?gb2312?B?NDM4NSAoMTc0Myk=?=
Thread-Index: Acmug0V7JEiT/re3R+aAuu6VL/pDSQABUV+A
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D9220218216A28exrad4adradco_"
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] =?gb2312?b?tPC4tDogIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVk?= =?gb2312?b?XSBSRkM0Mzg1ICgxNzQzKQ==?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 03:05:38 -0000

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216A28exrad4adradco_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

U0FUb1AgW1JGQzQzMzVdIG1pZ2h0IGJlIDQ1NTMsIHJpZ2h0Pw0KWUpTIKhDIGlzIHRoZXJlIGEg
d2F5IHRvIHN1Ym1pdCBlcnJhdGEgb24gZXJyYXRhID8gKG1ldGEtZXJyYXRhKQ0KDQphbmQgMSBt
b3JlIHF1ZXN0aW9uLCBJIGRvIG5vdCBxdWl0ZSB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGIv
dyBURE0gUFcgc2VxIGFuZCBub24tVE1EIFBXIHNlcXVlbmNlICMNCg0KWUpTIC0gVERNIFBXcyBj
eWNsZSB0aHJvdWdoIEFMTCAxNiBiaXQgdmFsdWVzLCB3aGlsZSBub24tVERNIFBXcyBza2lwIG92
ZXIgdGhlIHplcm8gKHdoaWNoIGhhcyBzcGVjaWFsIG1lYW5pbmcpLg0KDQoNCg0K

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216A28exrad4adradco_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"SimSun","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"SimSun","serif";}
tt
	{mso-style-priority:99;
	font-family:"SimSun","serif";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><tt>SAToP [RFC4335</tt>=
<span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>] might be 4553=
,
right?<span style=3D'color:#1F497D'><o:p></o:p></span></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz=
e:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>YJS =A8C is there a way t=
o
submit errata on errata ? (meta-errata)<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>and 1 mor=
e
question, I do not quite understand the difference b/w TDM PW seq and non-T=
MD
PW sequence #</span> <br>
<br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1=
F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz=
e:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>YJS - TDM PWs cycle throu=
gh
ALL 16 bit values, while non-TDM PWs skip over the zero (which has special
meaning).<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz=
e:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span><=
/p>

</div>

</body>

</html>

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216A28exrad4adradco_--

From [e-mail]  Thu Mar 26 20:08:53 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060903A67D9 for <[e-mail]>; Thu, 26 Mar 2009 20:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.257
X-Spam-Level: 
X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.341,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 eogIBVDpK78Y for <[e-mail]>; Thu, 26 Mar 2009 20:08:50 -0700 (PDT)
Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id 16CD73A696C for <[e-mail]>; Thu, 26 Mar 2009 20:08:48 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 27 Mar 2009 06:09:17 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Fri, 27 Mar 2009 06:09:17 +0300
From: Yaakov Stein <[e-mail]>
To: Lucy Yong <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 27 Mar 2009 06:09:10 +0300
Thread-Topic: [PWE3] Flow Label in fat-pw
Thread-Index: AcmudF7/dKF4xUkwSNGziNklea+UIgAFNZ/Q
Message-ID: <[e-mail]>
References: <002c01c9ae74$5fa15de0$[e-mail]>
In-Reply-To: <002c01c9ae74$5fa15de0$[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D9220218216A29exrad4adradco_"
MIME-Version: 1.0
Subject: Re: [PWE3] Flow Label in fat-pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 03:08:53 -0000

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216A29exrad4adradco_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Lucy

Can you explain why you believe there will be misordering ?

Y(J)S

From: [e-mail] [mailto:[e-mail]] On Behalf Of Luc=
y Yong
Sent: Friday, March 27, 2009 03:39
To: [e-mail]
Subject: [PWE3] Flow Label in fat-pw

Hi Bryant,

One comment about using flow label over a pseudowire is:  if the control wo=
rd is used in a pseudowire and non-zero sequence number is inserted, when u=
sing flow labels, it may cause the egress PE burden to perform packet seque=
ncing and increase the possibility of packet out of order. Therefore, it is=
 better to mention in the draft that when the control word presents and non=
-zero sequence number is used, the flow label should not be used or if it i=
s used, the constant flow label should be used.

Regards,
Lucy


--_000_424CDC689E5CEF4D9FEADE56A378D9220218216A29exrad4adradco_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Tahoma","sans-serif";
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Lucy<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Can you explain why you believe there will be misordering ?<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Y(J)S<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> pwe3-bounces@=
ietf.org
[mailto:[e-mail]] <b>On Behalf Of </b>Lucy Yong<br>
<b>Sent:</b> Friday, March 27, 2009 03:39<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> [PWE3] Flow Label in fat-pw<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-family:"Tahoma","sans-serif"'>Hi B=
ryant,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Tahoma","sans-serif"'><o:p=
>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Tahoma","sans-serif"'>One =
comment
about using flow label over a pseudowire is: &nbsp;if the control word is u=
sed
in a pseudowire and non-zero sequence number is inserted, when using flow
labels, it may cause the egress PE burden to perform packet sequencing and
increase the possibility of packet out of order. Therefore, it is better to
mention in the draft that when the control word presents and non-zero seque=
nce
number is used, the flow label should not be used or if it is used, the
constant flow label should be used.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Tahoma","sans-serif"'><o:p=
>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Tahoma","sans-serif"'>Rega=
rds,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Tahoma","sans-serif"'>Lucy=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Tahoma","sans-serif"'><o:p=
>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216A29exrad4adradco_--

From [e-mail]  Thu Mar 26 22:28:18 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F743A688B for <[e-mail]>; Thu, 26 Mar 2009 22:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 e2U4ykIdCcJ9 for <[e-mail]>; Thu, 26 Mar 2009 22:28:16 -0700 (PDT)
Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 5C95D3A67D9 for <[e-mail]>; Thu, 26 Mar 2009 22:28:15 -0700 (PDT)
Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 27 Mar 2009 08:27:11 +0300
Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 27 Mar 2009 08:29:07 +0300
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 27 Mar 2009 08:29:06 +0300
From: Alexander Vainshtein <[e-mail]>
To: Yaakov Stein <[e-mail]>, RFC Errata System <[e-mail]>
Date: Fri, 27 Mar 2009 08:29:06 +0300
Thread-Topic: [PWE3] [Technical Errata Reported] RFC4385 (1743)
Thread-Index: AcmuUjuqJO1qhWgoTHWhP/I+oqdsZwABRtzcAAuTxTAABX5VJg==
Message-ID: <[e-mail]>
References: <[e-mail]>, <[e-mail]> <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76A8CEED9073ILPTMAIL02eci_"
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Mar 2009 05:29:07.0211 (UTC) FILETIME=[F30545B0:01C9AE9C]
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 05:28:18 -0000

--_000_A3C5DF08D38B6049839A6F553B331C76A8CEED9073ILPTMAIL02eci_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yaakov and all,

Very interesting to hear.



I wonder where the logic of one (Standards Track) RFC trumping another (an =
Informational one) comes from.

Especially since the difference in the text describing sequence number beha=
vior in RFC 4553 (Standards Track) and 5086 (Informational) is minimal.



=3D=3D=3D=3D=3D=3D quote from RFC 4553 begins =3D=3D=3D=3D=3D=3D

       Sequence number - used to provide the common PW sequencing function
       as well as detection of lost packets.  It MUST be generated in
       accordance with the rules defined in Section 5.1 of [RFC3550] for
       the RTP sequence number:

         o Its space is a 16-bit unsigned circular space
         o Its initial value SHOULD be random (unpredictable).

       It MUST be incremented with each SAToP data packet sent in the
       specific PW.

=3D=3D=3D=3D=3D=3D  quote from RFC 4553 ends  =3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D quote from RFC 5086 begins =3D=3D=3D=3D=3D=3D

   The sequence number is used to provide the common PW sequencing
   function, as well as detection of lost packets.  It MUST be generated
   in accordance with the rules defined in Section 5.1 of [RFC3550] for
   the RTP sequence number, i.e.:

   o Its space is a 16-bit unsigned circular space

   o Its initial value SHOULD be random (unpredictable)

   o It MUST be incremented with each CESoPSN data packet sent in the
     specific PW.

=3D=3D=3D=3D=3D=3D  quote from RFC 5086 ends  =3D=3D=3D=3D=3D=3D



Was it a missing bullet in the 4553 text that otherwise would kill misinter=
pretation?



Regards,

     Sasha





________________________________________
From: Yaakov Stein [[e-mail]]
Sent: Friday, March 27, 2009 5:47 AM
To: Alexander Vainshtein; RFC Errata System
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];=
 [e-mail]; [e-mail]; [e-mail]; Andrew G. Malis
Subject: RE: [PWE3] [Technical Errata Reported] RFC4385 (1743)

Well, the authors of 4385 knew full well about the issue,
and tried to delicately indicate this.

They say that an encap draft is allowed to propose another algorithm,
but if the algorithm described in this document is used
then the zero value is skipped.

Unfortunately, this subtlety was missed by a major vendor
whose implementation skips zero for TDM PWs, and this vendor
claims that 4385 being standards-track trumps 5086 being informative.
Furthermore, this vendor claims that the wording in SAToP and CESoPSN
does not explicitly state that the zero value is NOT skipped,
rather point to 3550, which says nothing of value.

Anyway, this misunderstanding brought a multivendor network down.

Y(J)S



-----Original Message-----
From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Thursday, March 26, 2009 23:11
To: RFC Errata System
Cc: [e-mail]; Yaakov Stein; [e-mail]; [e-mail]; rdr=
[e-mail]; [e-mail]; [e-mail]; [e-mail]; And=
rew G. Malis
Subject: RE: [PWE3] [Technical Errata Reported] RFC4385 (1743)

It may be worth noting that the ALL the TDM PW RFCs have been published AFT=
ER 4385 (which is easy to see if you compare the RFC numbers; the first TDM=
 PW RFC to go out was 4553).

So while the reporter has a point, I do not see how the problem could have =
been avoided...

My 2c.
     Sasha

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Andrew G. =
Malis [[e-mail]]
Sent: Thursday, March 26, 2009 10:33 PM
To: RFC Errata System
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];=
 [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)

This errata should also include RFC 4842 in the list of TDM PW RFCs.

Thanks,
Andy

On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
<[e-mail]> wrote:
>
> The following errata report has been submitted for RFC4385,
> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MP=
LS PSN".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4385&eid=3D1743
>
> --------------------------------------
> Type: Technical
> Reported by: Yaakov (J) Stein <[e-mail]>
>
> Section: 4, 4.1, 4.2
>
> Original Text
> -------------
> The sequence number mechanism described here uses a circular unsigned
> 16-bit number space that excludes the value zero.
> ...
> o The sequence number that follows 65535 (maximum unsigned 16-bit
>  number) is one.
> ...
> o If the sequence number on the packet is zero, the sequence
>  integrity of the packets cannot be determined.  In this case, the
>  received packet is considered to be in order.
>
> Corrected Text
> --------------
> The sequence number mechanism for all PW types except the TDM PWs
> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
> circular unsigned 16-bit number space that excludes the value zero.
> The TDM PWs include the value zero.
> ...
> o For all non-TDM PWs the sequence number that follows 65535
> (maximum unsigned 16-bit number) is one.
> ...
> o If the sequence number on a non-TDM-PW packet is zero, the sequence
>  integrity of the packets cannot be determined.  In this case, the
>  received packet is considered to be in order.
>
> Notes
> -----
> While the fact that the TDM PWs always require the sequence number and th=
us do not give a zero value special meaning was well-known and documented i=
n the relevant RFCs. However, this was forgotten in this document and is ca=
using confusion to implementers.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4385 (draft-ietf-pwe3-cw-06)
> --------------------------------------
> Title               : Pseudowire Emulation Edge-to-Edge (PWE3) Control Wo=
rd for Use over an MPLS PSN
> Publication Date    : February 2006
> Author(s)           : S. Bryant, G. Swallow, L. Martini, D. McPherson
> Category            : PROPOSED STANDARD
> Source              : Pseudo Wire Emulation Edge to Edge
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3

--_000_A3C5DF08D38B6049839A6F553B331C76A8CEED9073ILPTMAIL02eci_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta content=3D"MSHTML 6.00.2900.3492" name=3D"GENERATOR">
<style title=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi=3D"x">
<p>Yaakov and all, </p>
<p>Very interesting to hear.</p>
<p>&nbsp;</p>
<p>I wonder where the logic of one (Standards Track) RFC trumping another (=
an Informational one) comes from.
</p>
<p>Especially since the difference in the text describing sequence number b=
ehavior in RFC 4553 (Standards Track) and 5086 (Informational) is minimal.<=
/p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><font face=3D"times new roman">=3D=3D=3D=3D=3D=3D quote from RFC 4553 be=
gins =3D=3D=3D=3D=3D=3D </font></p>
<p><span class=3D"Apple-style-span" style=3D"WORD-SPACING: 0px; FONT: 16px =
'times new roman'; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0p=
x; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; =
orphans: 2; widows: 2; webkit-border-horizontal-spacing: 0px; webkit-border=
-vertical-spacing: 0px; webkit-text-decorations-in-effect: none; webkit-tex=
t-size-adjust: auto; webkit-text-stroke-width: 0"><font face=3D"Courier New=
">&nbsp;&nbsp;&nbsp;
 &nbsp;&nbsp; Sequence number - used to provide the common PW sequencing fu=
nction<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as well as detection of lost packets.&=
nbsp; It MUST be generated in<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; accordance with the rules defined in S=
ection 5.1 of [RFC3550] for<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the RTP sequence number:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o Its space is a 16-bit un=
signed circular space<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o Its initial value SHOULD=
 be random (unpredictable).<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It MUST be incremented with each SAToP=
 data packet sent in the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specific PW.</font></p>
</span>
<p>=3D=3D=3D=3D=3D=3D&nbsp; quote from RFC 4553 ends&nbsp; =3D=3D=3D=3D=3D=
=3D </p>
<p>=3D=3D=3D=3D=3D=3D quote from RFC 5086 begins =3D=3D=3D=3D=3D=3D <span c=
lass=3D"Apple-style-span" style=3D"WORD-SPACING: 0px; FONT: 16px 'times new=
 roman'; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-S=
PACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2=
; widows: 2; webkit-border-horizontal-spacing: 0px; webkit-border-vertical-=
spacing: 0px; webkit-text-decorations-in-effect: none; webkit-text-size-adj=
ust: auto; webkit-text-stroke-width: 0">
</p>
<pre style=3D"WORD-WRAP: break-word">   The sequence number is used to prov=
ide the common PW sequencing
   function, as well as detection of lost packets.  It MUST be generated
   in accordance with the rules defined in Section 5.1 of [RFC3550] for
   the RTP sequence number, i.e.:

   o Its space is a 16-bit unsigned circular space

   o Its initial value SHOULD be random (unpredictable)

   o It MUST be incremented with each CESoPSN data packet sent in the
     specific PW.</pre>
<p>=3D=3D=3D=3D=3D=3D&nbsp; quote from RFC 5086 ends&nbsp; =3D=3D=3D=3D=3D=
=3D </p>
<p><font face=3D"times new roman"></font></span>&nbsp;</p>
<p>Was it a missing bullet in the 4553 text that otherwise would kill misin=
terpretation?</p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><font face=3D"times new roman">Regards,</font></p>
<p><font face=3D"times new roman">&nbsp;&nbsp;&nbsp;&nbsp; Sasha</font></p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><br>
________________________________________<br>
From: Yaakov Stein [[e-mail]]<br>
Sent: Friday, March 27, 2009 5:47 AM<br>
To: Alexander Vainshtein; RFC Errata System<br>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];=
 [e-mail]; [e-mail]; [e-mail]; Andrew G. Malis<b=
r>
Subject: RE: [PWE3] [Technical Errata Reported] RFC4385 (1743)<br>
<br>
Well, the authors of 4385 knew full well about the issue,<br>
and tried to delicately indicate this.<br>
<br>
They say that an encap draft is allowed to propose another algorithm,<br>
but if the algorithm described in this document is used<br>
then the zero value is skipped.<br>
<br>
Unfortunately, this subtlety was missed by a major vendor<br>
whose implementation skips zero for TDM PWs, and this vendor<br>
claims that 4385 being standards-track trumps 5086 being informative.<br>
Furthermore, this vendor claims that the wording in SAToP and CESoPSN<br>
does not explicitly state that the zero value is NOT skipped,<br>
rather point to 3550, which says nothing of value.<br>
<br>
Anyway, this misunderstanding brought a multivendor network down.<br>
<br>
Y(J)S<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Alexander Vainshtein [mailto:[e-mail]]<br>
Sent: Thursday, March 26, 2009 23:11<br>
To: RFC Errata System<br>
Cc: [e-mail]; Yaakov Stein; [e-mail]; [e-mail]; rdr=
[e-mail]; [e-mail]; [e-mail]; [e-mail]; And=
rew G. Malis<br>
Subject: RE: [PWE3] [Technical Errata Reported] RFC4385 (1743)<br>
<br>
It may be worth noting that the ALL the TDM PW RFCs have been published AFT=
ER 4385 (which is easy to see if you compare the RFC numbers; the first TDM=
 PW RFC to go out was 4553).<br>
<br>
So while the reporter has a point, I do not see how the problem could have =
been avoided...<br>
<br>
My 2c.<br>
&nbsp;&nbsp;&nbsp;&nbsp; Sasha<br>
<br>
________________________________________<br>
From: [e-mail] [[e-mail]] On Behalf Of Andrew G. =
Malis [[e-mail]]<br>
Sent: Thursday, March 26, 2009 10:33 PM<br>
To: RFC Errata System<br>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];=
 [e-mail]; [e-mail]; [e-mail]; [e-mail]<=
br>
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)<br>
<br>
This errata should also include RFC 4842 in the list of TDM PW RFCs.<br>
<br>
Thanks,<br>
Andy<br>
<br>
On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System<br>
&lt;[e-mail]&gt; wrote:<br>
&gt;<br>
&gt; The following errata report has been submitted for RFC4385,<br>
&gt; &quot;Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use ov=
er an MPLS PSN&quot;.<br>
&gt;<br>
&gt; --------------------------------------<br>
&gt; You may review the report below and at:<br>
&gt; http://www.rfc-editor.org/errata_search.php?rfc=3D4385&amp;eid=3D1743<=
br>
&gt;<br>
&gt; --------------------------------------<br>
&gt; Type: Technical<br>
&gt; Reported by: Yaakov (J) Stein &lt;[e-mail]&gt;<br>
&gt;<br>
&gt; Section: 4, 4.1, 4.2<br>
&gt;<br>
&gt; Original Text<br>
&gt; -------------<br>
&gt; The sequence number mechanism described here uses a circular unsigned<=
br>
&gt; 16-bit number space that excludes the value zero.<br>
&gt; ...<br>
&gt; o The sequence number that follows 65535 (maximum unsigned 16-bit<br>
&gt;&nbsp; number) is one.<br>
&gt; ...<br>
&gt; o If the sequence number on the packet is zero, the sequence<br>
&gt;&nbsp; integrity of the packets cannot be determined.&nbsp; In this cas=
e, the<br>
&gt;&nbsp; received packet is considered to be in order.<br>
&gt;<br>
&gt; Corrected Text<br>
&gt; --------------<br>
&gt; The sequence number mechanism for all PW types except the TDM PWs<br>
&gt; SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a<br>
&gt; circular unsigned 16-bit number space that excludes the value zero.<br=
>
&gt; The TDM PWs include the value zero.<br>
&gt; ...<br>
&gt; o For all non-TDM PWs the sequence number that follows 65535<br>
&gt; (maximum unsigned 16-bit number) is one.<br>
&gt; ...<br>
&gt; o If the sequence number on a non-TDM-PW packet is zero, the sequence<=
br>
&gt;&nbsp; integrity of the packets cannot be determined.&nbsp; In this cas=
e, the<br>
&gt;&nbsp; received packet is considered to be in order.<br>
&gt;<br>
&gt; Notes<br>
&gt; -----<br>
&gt; While the fact that the TDM PWs always require the sequence number and=
 thus do not give a zero value special meaning was well-known and documente=
d in the relevant RFCs. However, this was forgotten in this document and is=
 causing confusion to implementers.<br>
&gt;<br>
&gt; Instructions:<br>
&gt; -------------<br>
&gt; This errata is currently posted as &quot;Reported&quot;. If necessary,=
 please<br>
&gt; use &quot;Reply All&quot; to discuss whether it should be verified or<=
br>
&gt; rejected. When a decision is reached, the verifying party (IESG)<br>
&gt; can log in to change the status and edit the report, if necessary.<br>
&gt;<br>
&gt; --------------------------------------<br>
&gt; RFC4385 (draft-ietf-pwe3-cw-06)<br>
&gt; --------------------------------------<br>
&gt; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; : Pseudowire Emulation Edge-to-Edge (PWE3) Control Word=
 for Use over an MPLS PSN<br>
&gt; Publication Date&nbsp;&nbsp;&nbsp; : February 2006<br>
&gt; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
: S. Bryant, G. Swallow, L. Martini, D. McPherson<br>
&gt; Category&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; : PROPOSED STANDARD<br>
&gt; Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; : Pseudo Wire Emulation Edge to Edge<br>
&gt; Area&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; : Internet<br>
&gt; Stream&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; : IETF<br>
&gt; Verifying Party&nbsp;&nbsp;&nbsp;&nbsp; : IESG<br>
&gt; _______________________________________________<br>
&gt; pwe3 mailing list<br>
&gt; [e-mail]<br>
&gt; https://www.ietf.org/mailman/listinfo/pwe3<br>
&gt;<br>
_______________________________________________<br>
pwe3 mailing list<br>
[e-mail]<br>
https://www.ietf.org/mailman/listinfo/pwe3</p>
</body>
</html>

--_000_A3C5DF08D38B6049839A6F553B331C76A8CEED9073ILPTMAIL02eci_--

From [e-mail]  Thu Mar 26 22:55:06 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E043A699D for <[e-mail]>; Thu, 26 Mar 2009 22:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.971
X-Spam-Level: 
X-Spam-Status: No, score=-7.971 tagged_above=-999 required=5 tests=[AWL=-1.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 QLSt1TccQR3y for <[e-mail]>; Thu, 26 Mar 2009 22:55:04 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DD5393A6825 for <[e-mail]>; Thu, 26 Mar 2009 22:55:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,431,1233532800"; d="scan'208";a="162497247"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 27 Mar 2009 05:55:57 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2R5tu2j022059;  Fri, 27 Mar 2009 06:55:56 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2R5tu1Y020472; Fri, 27 Mar 2009 05:55:56 GMT
Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2R5tmW19139; Fri, 27 Mar 2009 05:55:49 GMT
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 05:55:46 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Alexander Vainshtein <[e-mail]>
References: <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4291; t=1238133356; x=1238997356; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Re=3A=20[PWE3]=20[Technical=20Errata=20Reported ]=20RFC4385=20(1743) |Sender:=20; bh=+VxXdtHtWBuRwvFVYNyPfFXyIOFj2H1X0hBLr5OgLBg=; b=LQ4AA62UoaY5mI1fBHDaE4LWhTM3+2kmwE4S6Py2hABe/nZoVH1BCu6vaQ o/OqHCqb+3xZ1j5BiLpDElhIptTt8/LCgEP2Q0IWUgEXHPGi7Ntnr2yFmZIT 0OsrZzqi0G;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, RFC Errata System <[e-mail]>
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 05:55:06 -0000

I do not think that we should call up the TDM drafts, but to talk in 
terms of all PWs for which the s/n is mandatory. There may at some time 
be non TDM drafts that also use zero as a valid s/n.

Stewart

Alexander Vainshtein wrote:
> It may be worth noting that the ALL the TDM PW RFCs have been published AFTER 4385 (which is easy to see if you compare the RFC numbers; the first TDM PW RFC to go out was 4553).
>
> So while the reporter has a point, I do not see how the problem could have been avoided...
>
> My 2c.
>      Sasha
>
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Andrew G. Malis [[e-mail]]
> Sent: Thursday, March 26, 2009 10:33 PM
> To: RFC Errata System
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
>
> This errata should also include RFC 4842 in the list of TDM PW RFCs.
>
> Thanks,
> Andy
>
> On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
> <[e-mail]> wrote:
>   
>> The following errata report has been submitted for RFC4385,
>> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=4385&eid=1743
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Yaakov (J) Stein <[e-mail]>
>>
>> Section: 4, 4.1, 4.2
>>
>> Original Text
>> -------------
>> The sequence number mechanism described here uses a circular unsigned
>> 16-bit number space that excludes the value zero.
>> ...
>> o The sequence number that follows 65535 (maximum unsigned 16-bit
>>  number) is one.
>> ...
>> o If the sequence number on the packet is zero, the sequence
>>  integrity of the packets cannot be determined.  In this case, the
>>  received packet is considered to be in order.
>>
>> Corrected Text
>> --------------
>> The sequence number mechanism for all PW types except the TDM PWs
>> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
>> circular unsigned 16-bit number space that excludes the value zero.
>> The TDM PWs include the value zero.
>> ...
>> o For all non-TDM PWs the sequence number that follows 65535
>> (maximum unsigned 16-bit number) is one.
>> ...
>> o If the sequence number on a non-TDM-PW packet is zero, the sequence
>>  integrity of the packets cannot be determined.  In this case, the
>>  received packet is considered to be in order.
>>
>> Notes
>> -----
>> While the fact that the TDM PWs always require the sequence number and thus do not give a zero value special meaning was well-known and documented in the relevant RFCs. However, this was forgotten in this document and is causing confusion to implementers.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC4385 (draft-ietf-pwe3-cw-06)
>> --------------------------------------
>> Title               : Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
>> Publication Date    : February 2006
>> Author(s)           : S. Bryant, G. Swallow, L. Martini, D. McPherson
>> Category            : PROPOSED STANDARD
>> Source              : Pseudo Wire Emulation Edge to Edge
>> Area                : Internet
>> Stream              : IETF
>> Verifying Party     : IESG
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
>>     
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>   


From [e-mail]  Thu Mar 26 23:06:29 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D993A6A37; Thu, 26 Mar 2009 23:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.283
X-Spam-Level: 
X-Spam-Status: No, score=-4.283 tagged_above=-999 required=5 tests=[AWL=-4.979, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4,  SARE_SUB_ENC_GB2312=1.345]
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 1IGMFc+7sDPC; Thu, 26 Mar 2009 23:06:28 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7BC183A68FD; Thu, 26 Mar 2009 23:06:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,431,1233532800"; d="scan'208";a="147397963"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2009 06:07:20 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2R67KSD023590;  Fri, 27 Mar 2009 07:07:20 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2R67Jg5021654; Fri, 27 Mar 2009 06:07:19 GMT
Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2R66tW19548; Fri, 27 Mar 2009 06:06:58 GMT
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 06:06:52 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4002; t=1238134040; x=1238998040; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogW1BXRTNdIFtUZWNobm ljYWwgRXJyYXRhIFJlcG9ydA=3D=3D?=3D=0A=20=3D?GB2312?B?ZWRdIFJ GQzQzODUgKDE3NDMp?=3D |Sender:=20; bh=DTMx5M1NAsYUq9oPv9u99l2zrdea3Ac666UNkJkrI8U=; b=flwkOSLeE0TPjsa8KP7tHqJCqeR0zACYBUHj8691lLgynOk7kE8om/8Gid uP1qiPJLWi830gFbddctTXjA+NpP2/OiGZ8YclrC75+s+TC4SnvMKc6eyHx3 nIa3XpZO+V;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], RFC Errata System <[e-mail]>
Subject: Re: [PWE3] =?gb2312?b?tPC4tDogIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVk?= =?gb2312?b?XSBSRkM0Mzg1ICgxNzQzKQ==?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 06:06:29 -0000

TDM uses a circular space, the others use a space with a gap at zero.
With these PWs, zero is used to indicate that sequence numbering
is not enabled.

Stewart

[e-mail] wrote:
>
> SAToP [RFC4335] might be 4553, right?
> and 1 more question, I do not quite understand the difference b/w TDM
> PW seq and non-TMD PW sequence #
>
> In SAToP RFC, it says:
> "
> Sequence number - used to provide the common PW sequencing function
> as well as detection of lost packets. It MUST be generated in
> accordance with the rules defined in Section 5.1 of [RFC3550] for
> the RTP sequence number:
>
> o Its space is a 16-bit unsigned circular space
> o Its initial value SHOULD be random (unpredictable).
>
> It MUST be incremented with each SAToP data packet sent in the
> specific PW.
> "
>
>
>
>
> *RFC Errata System <[e-mail]>*
> ·¢¼þÈË: [e-mail]
>
> 2009-03-27 04:23
>
> 	
> ÊÕ¼þÈË
> 	[e-mail], [e-mail], [e-mail],
> [e-mail], [e-mail], [e-mail],
> [e-mail], [e-mail], [e-mail]
> ³­ËÍ
> 	[e-mail], [e-mail], [e-mail]
> Ö÷Ìâ
> 	[PWE3] [Technical Errata Reported] RFC4385 (1743)
>
>
>
> 	
>
>
>
>
>
>
> The following errata report has been submitted for RFC4385,
> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an
> MPLS PSN".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4385&eid=1743
>
> --------------------------------------
> Type: Technical
> Reported by: Yaakov (J) Stein <[e-mail]>
>
> Section: 4, 4.1, 4.2
>
> Original Text
> -------------
> The sequence number mechanism described here uses a circular unsigned
> 16-bit number space that excludes the value zero.
> ...
> o The sequence number that follows 65535 (maximum unsigned 16-bit
> number) is one.
> ...
> o If the sequence number on the packet is zero, the sequence
> integrity of the packets cannot be determined. In this case, the
> received packet is considered to be in order.
>
> Corrected Text
> --------------
> The sequence number mechanism for all PW types except the TDM PWs
> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
> circular unsigned 16-bit number space that excludes the value zero.
> The TDM PWs include the value zero.
> ...
> o For all non-TDM PWs the sequence number that follows 65535
> (maximum unsigned 16-bit number) is one.
> ...
> o If the sequence number on a non-TDM-PW packet is zero, the sequence
> integrity of the packets cannot be determined. In this case, the
> received packet is considered to be in order.
>
> Notes
> -----
> While the fact that the TDM PWs always require the sequence number and
> thus do not give a zero value special meaning was well-known and
> documented in the relevant RFCs. However, this was forgotten in this
> document and is causing confusion to implementers.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC4385 (draft-ietf-pwe3-cw-06)
> --------------------------------------
> Title : Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
> over an MPLS PSN
> Publication Date : February 2006
> Author(s) : S. Bryant, G. Swallow, L. Martini, D. McPherson
> Category : PROPOSED STANDARD
> Source : Pseudo Wire Emulation Edge to Edge
> Area : Internet
> Stream : IETF
> Verifying Party : IESG
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>


From [e-mail]  Thu Mar 26 23:09:56 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19E73A67A3 for <[e-mail]>; Thu, 26 Mar 2009 23:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.789
X-Spam-Level: 
X-Spam-Status: No, score=-7.789 tagged_above=-999 required=5 tests=[AWL=-1.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 eLYfTNbTesIf for <[e-mail]>; Thu, 26 Mar 2009 23:09:56 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0F88C3A6825 for <[e-mail]>; Thu, 26 Mar 2009 23:09:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,431,1233532800"; d="scan'208";a="162501460"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 27 Mar 2009 06:10:49 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2R6AmO5032514;  Fri, 27 Mar 2009 07:10:48 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2R6AmYx022071; Fri, 27 Mar 2009 06:10:48 GMT
Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2R6AiW19769; Fri, 27 Mar 2009 06:10:44 GMT
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 06:10:42 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Yaakov Stein <[e-mail]>
References: <002c01c9ae74$5fa15de0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1305; t=1238134248; x=1238998248; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Re=3A=20[PWE3]=20Flow=20Label=20in=20fat-pw |Sender:=20; bh=Rk+jnSvj0UO/JyY1JYeL4A6VOIVVEg5uGh419nnTKYU=; b=dtOTCZwEkmdKADyinXQUkeo02yAM38Xl+gVTb5eYG+EQPw73RyjapQAqtW fBhBVrbSneSxWr1ORziBhQceeKt47XQpNxVK7MVJ+6d5RDrHvo8HYAe/zCvX yLyrZMf2D/;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] Flow Label in fat-pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 06:09:57 -0000

Lucy is correct, we need to turn off s/n or we will have problems.

This is because the s/n is defined per pw not per flow.

Stewart

Yaakov Stein wrote:
>
> Lucy
>
>  
>
> Can you explain why you believe there will be misordering ?
>
>  
>
> Y(J)S
>
>  
>
> *From:* [e-mail] [mailto:[e-mail]] *On 
> Behalf Of *Lucy Yong
> *Sent:* Friday, March 27, 2009 03:39
> *To:* [e-mail]
> *Subject:* [PWE3] Flow Label in fat-pw
>
>  
>
> Hi Bryant,
>
>  
>
> One comment about using flow label over a pseudowire is:  if the 
> control word is used in a pseudowire and non-zero sequence number is 
> inserted, when using flow labels, it may cause the egress PE burden to 
> perform packet sequencing and increase the possibility of packet out 
> of order. Therefore, it is better to mention in the draft that when 
> the control word presents and non-zero sequence number is used, the 
> flow label should not be used or if it is used, the constant flow 
> label should be used.
>
>  
>
> Regards,
>
> Lucy
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>   


From [e-mail]  Fri Mar 27 05:52:04 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FD83A6C28 for <[e-mail]>; Fri, 27 Mar 2009 05:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.291
X-Spam-Level: 
X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308,  BAYES_00=-2.599]
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 BTzn5mk+adIu for <[e-mail]>; Fri, 27 Mar 2009 05:52:01 -0700 (PDT)
Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id 7AFE53A6BE3 for <[e-mail]>; Fri, 27 Mar 2009 05:51:58 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 27 Mar 2009 15:52:51 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Fri, 27 Mar 2009 15:52:50 +0300
From: Yaakov Stein <[e-mail]>
To: "[e-mail]" <[e-mail]>, Alexander Vainshtein <[e-mail]>
Date: Fri, 27 Mar 2009 15:52:43 +0300
Thread-Topic: [PWE3] [Technical Errata Reported] RFC4385 (1743)
Thread-Index: AcmuoLwVDvjNMPVySwi0C8ZaejCwrwAOdr0g
Message-ID: <[e-mail]>
References: <[e-mail]>, <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, RFC Errata System <[e-mail]>
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 12:52:04 -0000

Stewart

I agree that your approach is more general.

I was taking a more down-to-earth approach recognizing that all
the existing TDM encaps require the SN, while all the others don't.

However, I would be quite happy with a 4385-bis explicitly=20
calling out two cases - 1 for optional SN and one for mandatory.

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[e-mail]]=20
Sent: Friday, March 27, 2009 08:56
To: Alexander Vainshtein
Cc: RFC Errata System; [e-mail]; Yaakov Stein; [e-mail];=
 [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)

I do not think that we should call up the TDM drafts, but to talk in=20
terms of all PWs for which the s/n is mandatory. There may at some time=20
be non TDM drafts that also use zero as a valid s/n.

Stewart

Alexander Vainshtein wrote:
> It may be worth noting that the ALL the TDM PW RFCs have been published A=
FTER 4385 (which is easy to see if you compare the RFC numbers; the first T=
DM PW RFC to go out was 4553).
>
> So while the reporter has a point, I do not see how the problem could hav=
e been avoided...
>
> My 2c.
>      Sasha
>
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Andrew G=
. Malis [[e-mail]]
> Sent: Thursday, March 26, 2009 10:33 PM
> To: RFC Errata System
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]=
m; [e-mail]; [e-mail]; [e-mail]; [e-mail]=
m
> Subject: Re: [PWE3] [Technical Errata Reported] RFC4385 (1743)
>
> This errata should also include RFC 4842 in the list of TDM PW RFCs.
>
> Thanks,
> Andy
>
> On Thu, Mar 26, 2009 at 1:23 PM, RFC Errata System
> <[e-mail]> wrote:
>  =20
>> The following errata report has been submitted for RFC4385,
>> "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an M=
PLS PSN".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3D4385&eid=3D1743
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Yaakov (J) Stein <[e-mail]>
>>
>> Section: 4, 4.1, 4.2
>>
>> Original Text
>> -------------
>> The sequence number mechanism described here uses a circular unsigned
>> 16-bit number space that excludes the value zero.
>> ...
>> o The sequence number that follows 65535 (maximum unsigned 16-bit
>>  number) is one.
>> ...
>> o If the sequence number on the packet is zero, the sequence
>>  integrity of the packets cannot be determined.  In this case, the
>>  received packet is considered to be in order.
>>
>> Corrected Text
>> --------------
>> The sequence number mechanism for all PW types except the TDM PWs
>> SAToP [RFC4335], CESoPSN [RFC5086], and TDMoIP [RFC5087] use a
>> circular unsigned 16-bit number space that excludes the value zero.
>> The TDM PWs include the value zero.
>> ...
>> o For all non-TDM PWs the sequence number that follows 65535
>> (maximum unsigned 16-bit number) is one.
>> ...
>> o If the sequence number on a non-TDM-PW packet is zero, the sequence
>>  integrity of the packets cannot be determined.  In this case, the
>>  received packet is considered to be in order.
>>
>> Notes
>> -----
>> While the fact that the TDM PWs always require the sequence number and t=
hus do not give a zero value special meaning was well-known and documented =
in the relevant RFCs. However, this was forgotten in this document and is c=
ausing confusion to implementers.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC4385 (draft-ietf-pwe3-cw-06)
>> --------------------------------------
>> Title               : Pseudowire Emulation Edge-to-Edge (PWE3) Control W=
ord for Use over an MPLS PSN
>> Publication Date    : February 2006
>> Author(s)           : S. Bryant, G. Swallow, L. Martini, D. McPherson
>> Category            : PROPOSED STANDARD
>> Source              : Pseudo Wire Emulation Edge to Edge
>> Area                : Internet
>> Stream              : IETF
>> Verifying Party     : IESG
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
>>    =20
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>  =20


From [e-mail]  Fri Mar 27 05:59:06 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D4D3A6B8C for <[e-mail]>; Fri, 27 Mar 2009 05:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.306
X-Spam-Level: 
X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293,  BAYES_00=-2.599]
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 2mjOv3aNsutb for <[e-mail]>; Fri, 27 Mar 2009 05:59:04 -0700 (PDT)
Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id E7FAA3A691E for <[e-mail]>; Fri, 27 Mar 2009 05:59:02 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 27 Mar 2009 15:59:56 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Fri, 27 Mar 2009 15:59:55 +0300
From: Yaakov Stein <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Fri, 27 Mar 2009 15:59:49 +0300
Thread-Topic: [PWE3] Flow Label in fat-pw
Thread-Index: AcmuotCEdYjxxVITRk+v1OwztvkqqgAOF6uA
Message-ID: <[e-mail]>
References: <002c01c9ae74$5fa15de0$[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] Flow Label in fat-pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 12:59:06 -0000

Stewart

There are two correct ways of using sequencing with inverse muxing.

One is to define identifiable flows (fat PWs) and to use SN per flow.

The other is to not bother about flows and USE the SN per PW (PW-bonding).

Y(J)S

-----Original Message-----
From: Stewart Bryant [mailto:[e-mail]]=20
Sent: Friday, March 27, 2009 09:11
To: Yaakov Stein
Cc: Lucy Yong; [e-mail]
Subject: Re: [PWE3] Flow Label in fat-pw

Lucy is correct, we need to turn off s/n or we will have problems.

This is because the s/n is defined per pw not per flow.

Stewart

Yaakov Stein wrote:
>
> Lucy
>
> =20
>
> Can you explain why you believe there will be misordering ?
>
> =20
>
> Y(J)S
>
> =20
>
> *From:* [e-mail] [mailto:[e-mail]] *On=20
> Behalf Of *Lucy Yong
> *Sent:* Friday, March 27, 2009 03:39
> *To:* [e-mail]
> *Subject:* [PWE3] Flow Label in fat-pw
>
> =20
>
> Hi Bryant,
>
> =20
>
> One comment about using flow label over a pseudowire is:  if the=20
> control word is used in a pseudowire and non-zero sequence number is=20
> inserted, when using flow labels, it may cause the egress PE burden to=20
> perform packet sequencing and increase the possibility of packet out=20
> of order. Therefore, it is better to mention in the draft that when=20
> the control word presents and non-zero sequence number is used, the=20
> flow label should not be used or if it is used, the constant flow=20
> label should be used.
>
> =20
>
> Regards,
>
> Lucy
>
> =20
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>  =20


From [e-mail]  Fri Mar 27 16:05:42 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7694E3A69B3; Fri, 27 Mar 2009 16:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.108
X-Spam-Level: 
X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=-2.804, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345]
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 kdpePVm5UOmg; Fri, 27 Mar 2009 16:05:41 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 576623A67F5; Fri, 27 Mar 2009 16:05:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,435,1233532800"; d="scan'208";a="36976003"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2009 23:06:30 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2RN6U3G009464;  Sat, 28 Mar 2009 00:06:30 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2RN6UMn003950; Fri, 27 Mar 2009 23:06:30 GMT
Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2RN63W15988; Fri, 27 Mar 2009 23:06:25 GMT
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 23:05:59 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2908; t=1238195190; x=1239059190; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogUmU6IFtQV0UzXSBGbG 93IExhYmVsIGluIGZhdC1wdw=3D=3D?=3D |Sender:=20; bh=/pEnJpk6AizNoWlTnREjhK3p14dOtPCL1CiQ6WquYtQ=; b=e7F7FbEG1OOXQoCfGS3ws8fb+RY8Yll1abzv1gXYJH0ybcR9yfowPbpT2z bB95JzqRh+mTYXJYNrURVYozLz8h/H0ucR2cIkS4cgDZKrfoe+1FaDaJx8UO 8ZK4LGyLDJ;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
Cc: [e-mail], Yaakov Stein <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] =?gb2312?b?tPC4tDogUmU6ICBGbG93IExhYmVsIGluIGZhdC1wdw==?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 23:05:42 -0000

[e-mail] wrote:
>
> Sir
>
> Is the flow label some kind of solution for Verizon proposed CTG for
> efficient usage and more control over Trunk so that can bind multiple
> 10G links into one N*10G link instead of installing new 40G/100G system?
I will let Andy answer for himself, but my reference to LAG in the draft
this type of application.
>
> And also, could sequence# be used for ECMP balance? 
Not unless you want to do reassembly of order, which at these speeds is
very difficult. The problem is that the packets are not the same length
and so you will have to buffer then and play them out. This way we split
the flows at source into flows that must themselves be in sequence, but
which can be out of sequence relative to each other. Thus on egress no
storage is needed we simply look at the PW label and switch the packet
immediately out of the PE
>
>
> What's the trade off b/w additional flow label and the sequence #
> reuse/multi-tasking.
I do not understand the question.

Regards

Stewart
>
> Thank you.
>
>
>
> *Stewart Bryant <[e-mail]>*
> ·¢¼þÈË: [e-mail]
>
> 2009-03-27 14:10
> Çë´ð¸´ ¸ø
> [e-mail]
>
>
> 	
> ÊÕ¼þÈË
> 	Yaakov Stein <[e-mail]>
> ³­ËÍ
> 	"[e-mail]" <[e-mail]>
> Ö÷Ìâ
> 	Re: [PWE3] Flow Label in fat-pw
>
>
>
> 	
>
>
>
>
>
> Lucy is correct, we need to turn off s/n or we will have problems.
>
> This is because the s/n is defined per pw not per flow.
>
> Stewart
>
> Yaakov Stein wrote:
> >
> > Lucy
> >
> >
> >
> > Can you explain why you believe there will be misordering ?
> >
> >
> >
> > Y(J)S
> >
> >
> >
> > *From:* [e-mail] [mailto:[e-mail]] *On
> > Behalf Of *Lucy Yong
> > *Sent:* Friday, March 27, 2009 03:39
> > *To:* [e-mail]
> > *Subject:* [PWE3] Flow Label in fat-pw
> >
> >
> >
> > Hi Bryant,
> >
> >
> >
> > One comment about using flow label over a pseudowire is: if the
> > control word is used in a pseudowire and non-zero sequence number is
> > inserted, when using flow labels, it may cause the egress PE burden to
> > perform packet sequencing and increase the possibility of packet out
> > of order. Therefore, it is better to mention in the draft that when
> > the control word presents and non-zero sequence number is used, the
> > flow label should not be used or if it is used, the constant flow
> > label should be used.
> >
> >
> >
> > Regards,
> >
> > Lucy
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> >
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>


From [e-mail]  Fri Mar 27 16:08:47 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFD73A6991 for <[e-mail]>; Fri, 27 Mar 2009 16:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.68
X-Spam-Level: 
X-Spam-Status: No, score=-9.68 tagged_above=-999 required=5 tests=[AWL=0.919,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 wk8XrrKOYwFM for <[e-mail]>; Fri, 27 Mar 2009 16:08:46 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9600B3A67F5 for <[e-mail]>; Fri, 27 Mar 2009 16:08:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,435,1233532800"; d="scan'208";a="36976225"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2009 23:09:38 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2RN9bEj002538;  Sat, 28 Mar 2009 00:09:37 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2RN9b1V004502; Fri, 27 Mar 2009 23:09:37 GMT
Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2RN9ZW16162; Fri, 27 Mar 2009 23:09:36 GMT
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 23:09:35 +0000
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Yaakov Stein <[e-mail]>
References: <002c01c9ae74$5fa15de0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2105; t=1238195377; x=1239059377; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Re=3A=20[PWE3]=20Flow=20Label=20in=20fat-pw |Sender:=20; bh=0dCyWkmD7WcqogrUrwBFU/d5YoyWpxV8YPkDtYAjm7w=; b=MuAIi079JyY3B44UiNEzy2MWh8SsIVOKAnWdObZxqN2kJifxsd4cbRtC4u HzQBwu87Ak9+wefCIuanqHBzKr8LiT1CdnGzTk4PTph2arznu5iD/4vs9g/c c2f7uppCD0;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] Flow Label in fat-pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 23:08:47 -0000

Yaakov Stein wrote:
> Stewart
>
> There are two correct ways of using sequencing with inverse muxing.
>
> One is to define identifiable flows (fat PWs) and to use SN per flow.
>
> The other is to not bother about flows and USE the SN per PW (PW-bonding).
>   

I agree there are two ways, but I think the flow method is more suitable 
for 100G than
bonding.

BTW 100G is kind of too close, what number do I need to use to describe 
two generations
time.

Stewart
> Y(J)S
>
> -----Original Message-----
> From: Stewart Bryant [mailto:[e-mail]] 
> Sent: Friday, March 27, 2009 09:11
> To: Yaakov Stein
> Cc: Lucy Yong; [e-mail]
> Subject: Re: [PWE3] Flow Label in fat-pw
>
> Lucy is correct, we need to turn off s/n or we will have problems.
>
> This is because the s/n is defined per pw not per flow.
>
> Stewart
>
> Yaakov Stein wrote:
>   
>> Lucy
>>
>>  
>>
>> Can you explain why you believe there will be misordering ?
>>
>>  
>>
>> Y(J)S
>>
>>  
>>
>> *From:* [e-mail] [mailto:[e-mail]] *On 
>> Behalf Of *Lucy Yong
>> *Sent:* Friday, March 27, 2009 03:39
>> *To:* [e-mail]
>> *Subject:* [PWE3] Flow Label in fat-pw
>>
>>  
>>
>> Hi Bryant,
>>
>>  
>>
>> One comment about using flow label over a pseudowire is:  if the 
>> control word is used in a pseudowire and non-zero sequence number is 
>> inserted, when using flow labels, it may cause the egress PE burden to 
>> perform packet sequencing and increase the possibility of packet out 
>> of order. Therefore, it is better to mention in the draft that when 
>> the control word presents and non-zero sequence number is used, the 
>> flow label should not be used or if it is used, the constant flow 
>> label should be used.
>>
>>  
>>
>> Regards,
>>
>> Lucy
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pwe3
>>   
>>     
>
>
>
>   


From [e-mail]  Fri Mar 27 21:41:51 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CD93A682D for <[e-mail]>; Fri, 27 Mar 2009 21:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.6
X-Spam-Level: 
X-Spam-Status: No, score=-95.6 tagged_above=-999 required=5 tests=[AWL=1.393,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 7W8ePjx3Sqy1 for <[e-mail]>; Fri, 27 Mar 2009 21:41:50 -0700 (PDT)
Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by core3.amsl.com (Postfix) with ESMTP id C35463A6812 for <[e-mail]>; Fri, 27 Mar 2009 21:41:49 -0700 (PDT)
Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 90033.2928413318; Sat, 28 Mar 2009 12:40:12 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n2S4gdOJ027152; Sat, 28 Mar 2009 12:42:39 +0800 (CST) (envelope-from [e-mail])
In-Reply-To: <[e-mail]>
To: Yaakov Stein <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sat, 28 Mar 2009 12:42:28 +0800
X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-28 12:42:44, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-28 12:42:44, Serialize complete at 2009-03-28 12:42:44, S/MIME Sign failed at 2009-03-28 12:42:44:  =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-03-28 12:42:29, Serialize complete at 2009-03-28 12:42:29
Content-Type: multipart/alternative; boundary="=_alternative 0019E2A148257587_="
X-MAIL: mse1.zte.com.cn n2S4gdOJ027152
Cc: [e-mail]
Subject: [PWE3] =?gb2312?b?tPC4tDogUmU6ICBbVGVjaG5pY2FsIEVycmF0YSBSZXBv?= =?gb2312?b?cnRlZF0gUkZDNDM4NSAoMTc0Myk=?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 28 Mar 2009 04:41:51 -0000

This is a multipart message in MIME format.
--=_alternative 0019E2A148257587_=
Content-Type: text/plain; charset="US-ASCII"

Sir,

For the seq# space gap problem, could just make the seq# 0 be configurable 
for specific implementation so that vendors can interop with each other?

Thank you.
--=_alternative 0019E2A148257587_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif"><br>
Sir,</font>
<br>
<br><font size=2 face="sans-serif">For the seq# space gap problem, could
just make the seq# 0 be configurable for specific implementation so that
vendors can interop with each other?</font>
<br>
<br><font size=2 face="sans-serif">Thank you.</font>
--=_alternative 0019E2A148257587_=--

From [e-mail]  Sat Mar 28 22:55:40 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF123A6CA9 for <[e-mail]>; Sat, 28 Mar 2009 22:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.193
X-Spam-Level: **
X-Spam-Status: No, score=2.193 tagged_above=-999 required=5 tests=[AWL=-4.257,  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, SARE_SUB_ENC_GB2312=1.345]
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 YoEZDrOX6ODg for <[e-mail]>; Sat, 28 Mar 2009 22:55:37 -0700 (PDT)
Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id F37893A6ACF for <[e-mail]>; Sat, 28 Mar 2009 22:55:35 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 29 Mar 2009 08:56:27 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Sun, 29 Mar 2009 08:56:27 +0300
From: Yaakov Stein <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Sun, 29 Mar 2009 08:56:19 +0300
Thread-Topic: =?gb2312?B?W1BXRTNdILTwuLQ6IFJlOiAgW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRd?= =?gb2312?B?IFJGQzQzODUgKDE3NDMp?=
Thread-Index: AcmvX6nVjPx8LgcURgWzUnT+lApyVQA0vjPA
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_424CDC689E5CEF4D9FEADE56A378D9220218216C84exrad4adradco_"
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] =?gb2312?b?tPC4tDogUmU6ICBbVGVjaG5pY2FsIEVycmF0YSBSZXBv?= =?gb2312?b?cnRlZF0gUkZDNDM4NSAoMTc0Myk=?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2009 05:55:40 -0000

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216C84exrad4adradco_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

Tm8sIHRoZSBlbmNhcHN1bGF0aW9uIGRyYWZ0cyBhcmUgcXVpdGUgc3BlY2lmaWMgYWJvdXQgdGhp
cy4NCkl0IGlzIG5vdCBhIG1hdHRlciBmb3IgY29uZmlndXJhdGlvbi4NCg0KQWZ0ZXIgdGFsa2lu
ZyB3aXRoIFN0ZXdhcnQgSSB0aGluayB3ZSBoYXZlIGFncmVlZCB0aGF0IGEgbmV3IHNwaW4gb2Yg
NDM4NQ0Kc2hvdWxkIGRpc3Rpbmd1aXNoIGJldHdlZW4gZW5jYXBzIGZvciB3aGljaCB0aGUgU04g
aXMgb3B0aW9uYWwNCihlLmcuIEFUTSwgRlIsIEV0aGVybmV0KSBhbmQgdGhvc2UgZm9yIHdoaWNo
IHRoZSBTTiBpcyBtYW5kYXRvcnkgKGUuZy4gU0FUb1AsIENFU29QU04sIFRETW9JUCwgQ0VQKS4N
ClRoZSBmb3JtZXIgY2FtcCB1c2VzIHRoZSB6ZXJvIHZhbHVlIHRvIGluZGljYXRlIHRoYXQgdGhl
IFNOIGlzIG5vdCBiZWluZyB1c2VkIGFuZCB0aHVzIHNraXBzIGl0IHdoZW4gdGhlIFNOIGlzIHVz
ZWQsDQp0aGUgbGF0dGVyIG5ldmVyIHNraXAgdGhlIHplcm8gdmFsdWUuDQoNClkoSilTDQoNCkZy
b206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIGppYW5nLnhpYW93ZWlAenRlLmNvbS5jbg0KU2VudDogU2F0dXJkYXksIE1h
cmNoIDI4LCAyMDA5IDA3OjQyDQpUbzogWWFha292IFN0ZWluDQpDYzogcHdlM0BpZXRmLm9yZw0K
U3ViamVjdDogW1BXRTNdILTwuLQ6IFJlOiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZD
NDM4NSAoMTc0MykNCg0KDQoNClNpciwNCg0KRm9yIHRoZSBzZXEjIHNwYWNlIGdhcCBwcm9ibGVt
LCBjb3VsZCBqdXN0IG1ha2UgdGhlIHNlcSMgMCBiZSBjb25maWd1cmFibGUgZm9yIHNwZWNpZmlj
IGltcGxlbWVudGF0aW9uIHNvIHRoYXQgdmVuZG9ycyBjYW4gaW50ZXJvcCB3aXRoIGVhY2ggb3Ro
ZXI/DQoNClRoYW5rIHlvdS4NCg==

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216C84exrad4adradco_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dgb2312">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>

<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:PMingLiU;
	panose-1:2 1 6 1 0 1 1 1 1 1;}
@font-face
	{font-family:PMingLiU;
	panose-1:2 1 6 1 0 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"PMingLiU","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>No, the encapsulation drafts are quite specific about this.<=
o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>It is not a matter for configuration.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>After talking with Stewart I think we have agreed that a new
spin of 4385<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>should distinguish between encaps for which the SN is option=
al<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>(e.g. ATM, FR, Ethernet) and those for which the SN is manda=
tory
(e.g. SAToP, CESoPSN, TDMoIP, CEP).<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>The former camp uses the zero value to indicate that the SN =
is
not being used and thus skips it when the SN is used,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>the latter never skip the zero value.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Y(J)S<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Behalf Of </b>ji=
[e-mail]<br>
<b>Sent:</b> Saturday, March 28, 2009 07:42<br>
<b>To:</b> Yaakov Stein<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> [PWE3] </span><span lang=3DZH-TW style=3D'font-size:10.0pt'=
>=B4=F0=B8=B4</span><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: Re: [Technic=
al
Errata Reported] RFC4385 (1743)<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><br>
Sir,</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>For the s=
eq#
space gap problem, could just make the seq# 0 be configurable for specific
implementation so that vendors can interop with each other?</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Thank you=
.</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_424CDC689E5CEF4D9FEADE56A378D9220218216C84exrad4adradco_--

From [e-mail]  Sat Mar 28 23:26:20 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3395E3A6886 for <[e-mail]>; Sat, 28 Mar 2009 23:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.225
X-Spam-Level: 
X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_20=-0.74]
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 Oty5ljoSv9YV for <[e-mail]>; Sat, 28 Mar 2009 23:26:18 -0700 (PDT)
Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id AD0143A67A7 for <[e-mail]>; Sat, 28 Mar 2009 23:26:16 -0700 (PDT)
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 29 Mar 2009 09:27:11 +0300
Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Sun, 29 Mar 2009 09:27:11 +0300
From: Yaakov Stein <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Sun, 29 Mar 2009 09:27:04 +0300
Thread-Topic: [PWE3] Flow Label in fat-pw
Thread-Index: AcmvMRvihPc4FkfKQbmyaUtMDcM2rABBQYDQ
Message-ID: <[e-mail]>
References: <002c01c9ae74$5fa15de0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [PWE3] Flow Label in fat-pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2009 06:26:20 -0000

> BTW 100G is kind of too close, what number do I need to use to describe=20
> two generations time.

There are several different analogs to Moore's Law for bandwidth.

The slowest has bandwidth doubling every 2 years (slower than Moore's law
for which computational power doubles every 18 months),
while the fastest predicts a factor of 10 improvement every 2 years.

Of course the bandwidth itself depends on what you are talking about,
since at any given time wireless is slower than copper which is slower than=
 fiber.
However, Edholm's law states that all forms of infrastructure follow the sa=
me law.=20
They are just offset in time.

Y(J)S


From prvs=326dc9e23=[e-mail]  Mon Mar 23 09:34:56 2009
Return-Path: <prvs=326dc9e23=[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B51728C130 for <[e-mail]>; Mon, 23 Mar 2009 09:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.415
X-Spam-Level: 
X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.183,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 T65Bt6LMa0zW for <[e-mail]>; Mon, 23 Mar 2009 09:34:52 -0700 (PDT)
Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id A37473A697B for <[e-mail]>; Mon, 23 Mar 2009 09:34:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,409,1233561600"; d="scan'208,217";a="441600"
Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 23 Mar 2009 09:35:43 -0700
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0AFE6392258 for <[e-mail]>; Mon, 23 Mar 2009 09:35:43 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26550-02 for <[e-mail]>; Mon, 23 Mar 2009 09:35:42 -0700 (PDT)
Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id DF81C392256 for <[e-mail]>; Mon, 23 Mar 2009 09:35:42 -0700 (PDT)
Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Mon, 23 Mar 2009 09:35:42 -0700
From: David Sinicrope <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Mon, 23 Mar 2009 09:35:41 -0700
Thread-Topic: [PWE3] Time slots for IETF 74 PWE3 meeting
Thread-Index: AcmO1f4o4AcNXYD1F0eyztRRXFz+YAL0CTg/Ae9A5QIBvXPB9ACfHHmI
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C5ED329D18466euddasiredbackcom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 30 Mar 2009 06:57:34 -0700
Subject: Re: [PWE3] Time slots for IETF 74 PWE3 meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 16:37:52 -0000

--_000_C5ED329D18466euddasiredbackcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,
Thanks to those that have sent me their presentations.
I've posted the presentations I've received (4):  See http://tools.ietf.org=
/wg/pwe3/agenda.
Others on the agenda, please send me your presentations as soon as you can.
Thanks,
Dave

On 3/20/09 8:39 AM, "David Sinicrope" <[e-mail]> wrote:


Those on the agenda, please send me your presentation slides for the PWE3 m=
eeting as soon as possible so I can upload them to the meeting materials be=
fore the meeting.
(Try to keep this subject on the email you send them with so I don't miss a=
ny.)
Thanks!
Dave

On 3/11/09 12:05 PM, "David Sinicrope" <[e-mail]> wrote:

The initial agenda is available at:
http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html
Please let me know if there are any questions or concerns,
Dave




--_000_C5ED329D18466euddasiredbackcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [PWE3] Time slots for IETF 74 PWE3 meeting</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Hi All, &nbsp;<BR>
Thanks to those that have sent me their presentations. &nbsp;<BR>
I&#8217;ve posted the presentations I&#8217;ve received (4): &nbsp;See <a h=
ref=3D"http://tools.ietf.org/wg/pwe3/agenda">http://tools.ietf.org/wg/pwe3/=
agenda</a>.<BR>
Others on the agenda, please send me your presentations as soon as you can.=
<BR>
Thanks,<BR>
Dave<BR>
<BR>
On 3/20/09 8:39 AM, &quot;David Sinicrope&quot; &lt;<a href=3D"euddasi@redb=
ack.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
Those on the agenda, please send me your presentation slides for the PWE3 m=
eeting as soon as possible so I can upload them to the meeting materials be=
fore the meeting.<BR>
(Try to keep this subject on the email you send them with so I don&#8217;t =
miss any.)<BR>
Thanks!<BR>
Dave</SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:1=
2pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=
=3D'font-size:11pt'><BR>
On 3/11/09 12:05 PM, &quot;David Sinicrope&quot; &lt;<a href=3D"euddasi@red=
back.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>The initial agenda is available at:<BR>
<a href=3D"http://tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html">http:=
//tools.ietf.org/wg/pwe3/agenda?item=3Dagenda74.html</a><BR>
Please let me know if there are any questions or concerns,<BR>
Dave<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C5ED329D18466euddasiredbackcom_--

From [e-mail]  Mon Mar 30 07:05:24 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC0228C0D9 for <[e-mail]>; Mon, 30 Mar 2009 07:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.704
X-Spam-Level: 
X-Spam-Status: No, score=-7.704 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 NOhPMbhFqkTa for <[e-mail]>; Mon, 30 Mar 2009 07:05:23 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 850853A6D2E for <[e-mail]>; Mon, 30 Mar 2009 07:05:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,446,1233532800"; d="scan'208";a="276682945"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 14:06:18 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2UE6Hxl026485;  Mon, 30 Mar 2009 16:06:17 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UE6HKn026916; Mon, 30 Mar 2009 14:06:17 GMT
Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2UE6FV25223; Mon, 30 Mar 2009 15:06:16 +0100 (BST)
Message-ID: <[e-mail]>
Date: Mon, 30 Mar 2009 15:06:14 +0100
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=357; t=1238421977; x=1239285977; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Re=3A=20[PWE3]=20=3D?windows-1252?Q?=3D3F=3D3F= 3D3A_Re=3D3A__=3D5BTechnical_?=3D=0A=20=3D?windows-1252?Q?Er rata_Reported=3D5D_RFC4385_=3D281743=3D29?=3D |Sender:=20; bh=zZiOF7/2YFaGMzmh4CELaKapgwmVE22g6mlXoGEb0Io=; b=tJaKtTVXWwVdwrwMkcq4R/KBgJaNo60lBPuUM5apsitUfi7l3MX4WLd1jf RdIYBzTMzz+T4cLiLyt4RO2RzHgZtsG7pHWO6QYPqkl97QkcNoNzE/GtjhF5 Gg50wDDgXr;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Cc: Yaakov Stein <[e-mail]>, [e-mail]
Subject: Re: [PWE3] =?windows-1252?q?=3F=3F=3A_Re=3A__=5BTechnical_Errata_Repo?= =?windows-1252?q?rted=5D_RFC4385_=281743=29?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2009 14:05:24 -0000

[e-mail] wrote:
>
>
> Sir,
>
> For the seq# space gap problem, could just make the seq# 0 be 
> configurable for specific implementation so that vendors can interop 
> with each other?
That will just introduce interoperability problems for the (many) 
companies that have correctly implemented the existing specs.

Stewart

From [e-mail]  Mon Mar 30 12:33:04 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603E93A6D11 for <[e-mail]>; Mon, 30 Mar 2009 12:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 uQM1yst0PS9A for <[e-mail]>; Mon, 30 Mar 2009 12:33:03 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 96FA33A68BB for <[e-mail]>; Mon, 30 Mar 2009 12:33:03 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 30 Mar 2009 14:34:01 -0500 (CDT)
Received: from Y73674 ([10.124.12.103]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 30 Mar 2009 14:34:01 -0500 (CDT)
Date: Mon, 30 Mar 2009 14:33:59 -0500
From: Lucy Yong <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail], 'Yaakov Stein' <[e-mail]>
Message-id: <008b01c9b16e$7a1b05c0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-index: AcmvMTQnd3Hvzj6CRoGqrrj/jGOczACPABCg
References: <002c01c9ae74$5fa15de0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Cc: [e-mail]
Subject: Re: [PWE3] Flow Label in fat-pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2009 19:33:04 -0000

Stewart,

You catch my point. S/N is per PW not per flow label. 

Lucy

> -----Original Message-----
> From: Stewart Bryant [mailto:[e-mail]]
> Sent: Friday, March 27, 2009 6:10 PM
> To: Yaakov Stein
> Cc: Lucy Yong; [e-mail]
> Subject: Re: [PWE3] Flow Label in fat-pw
> 
> Yaakov Stein wrote:
> > Stewart
> >
> > There are two correct ways of using sequencing with inverse muxing.
> >
> > One is to define identifiable flows (fat PWs) and to use SN per flow.
> >
> > The other is to not bother about flows and USE the SN per PW
(PW-bonding).
> >
> 
> I agree there are two ways, but I think the flow method is more suitable
> for 100G than
> bonding.
> 
> BTW 100G is kind of too close, what number do I need to use to describe
> two generations
> time.
> 
> Stewart
> > Y(J)S
> >
> > -----Original Message-----
> > From: Stewart Bryant [mailto:[e-mail]]
> > Sent: Friday, March 27, 2009 09:11
> > To: Yaakov Stein
> > Cc: Lucy Yong; [e-mail]
> > Subject: Re: [PWE3] Flow Label in fat-pw
> >
> > Lucy is correct, we need to turn off s/n or we will have problems.
> >
> > This is because the s/n is defined per pw not per flow.
> >
> > Stewart
> >
> > Yaakov Stein wrote:
> >
> >> Lucy
> >>
> >>
> >>
> >> Can you explain why you believe there will be misordering ?
> >>
> >>
> >>
> >> Y(J)S
> >>
> >>
> >>
> >> *From:* [e-mail] [mailto:[e-mail]] *On
> >> Behalf Of *Lucy Yong
> >> *Sent:* Friday, March 27, 2009 03:39
> >> *To:* [e-mail]
> >> *Subject:* [PWE3] Flow Label in fat-pw
> >>
> >>
> >>
> >> Hi Bryant,
> >>
> >>
> >>
> >> One comment about using flow label over a pseudowire is:  if the
> >> control word is used in a pseudowire and non-zero sequence number is
> >> inserted, when using flow labels, it may cause the egress PE burden to
> >> perform packet sequencing and increase the possibility of packet out
> >> of order. Therefore, it is better to mention in the draft that when
> >> the control word presents and non-zero sequence number is used, the
> >> flow label should not be used or if it is used, the constant flow
> >> label should be used.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Lucy
> >>
> >>
> >>
> >>
------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> pwe3 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/pwe3
> >>
> >>
> >
> >
> >
> >


From [e-mail]  Mon Mar 30 12:49:28 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6AFE3A6846; Mon, 30 Mar 2009 12:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.048
X-Spam-Level: *
X-Spam-Status: No, score=1.048 tagged_above=-999 required=5 tests=[AWL=-3.647,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3,  MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345]
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 zjf8Cf7oQhAc; Mon, 30 Mar 2009 12:49:27 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id BB39F3A6D48; Mon, 30 Mar 2009 12:49:27 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Mon, 30 Mar 2009 14:50:26 -0500 (CDT)
Received: from Y73674 ([10.124.12.103]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Mon, 30 Mar 2009 14:50:25 -0500 (CDT)
Date: Mon, 30 Mar 2009 14:50:23 -0500
From: Lucy Yong <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail], [e-mail]
Message-id: <008d01c9b170$c4bd3ec0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: AcmvMLQAv0u3MqCnStuG1BS3AuiH8wCPewNQ
References: <[e-mail]> <[e-mail]>
Cc: [e-mail], 'Yaakov Stein' <[e-mail]>, [e-mail]
Subject: Re: [PWE3] =?gb2312?b?tPC4tDogUmU6ICBGbG93IExhYmVsIGluIGZhdC1wdw==?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2009 19:49:28 -0000

Hi Jiang XiaoWei,

Flow Label and CTG are different. Flow label enables sending flow =
packets in
a PW over multiple paths in the PSN that does not perform TE. CTG =
enables TE
based flow assignment over component links. CTG addresses a composite =
link
handling multiple TE flows and/or non TE flows. TE flows may be from
difference TE enabled client networks and non TE flows may be from =
different
non-TE client networks.

CTG aims on the ability to share available composite link capacity among
multiple network instances and allow one instance to reserve BW when it
uses.

Hope this help to clarify/

Regards,
Lucy

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf =
Of
> Stewart Bryant
> Sent: Friday, March 27, 2009 6:06 PM
> To: [e-mail]
> Cc: [e-mail]; Yaakov Stein; [e-mail]
> Subject: Re: [PWE3] =B4=F0=B8=B4: Re: Flow Label in fat-pw
>=20
> [e-mail] wrote:
> >
> > Sir
> >
> > Is the flow label some kind of solution for Verizon proposed CTG for
> > efficient usage and more control over Trunk so that can bind =
multiple
> > 10G links into one N*10G link instead of installing new 40G/100G =
system?
> I will let Andy answer for himself, but my reference to LAG in the =
draft
> this type of application.
> >
> > And also, could sequence# be used for ECMP balance?
> Not unless you want to do reassembly of order, which at these speeds =
is
> very difficult. The problem is that the packets are not the same =
length
> and so you will have to buffer then and play them out. This way we =
split
> the flows at source into flows that must themselves be in sequence, =
but
> which can be out of sequence relative to each other. Thus on egress no
> storage is needed we simply look at the PW label and switch the packet
> immediately out of the PE
> >
> >
> > What's the trade off b/w additional flow label and the sequence #
> > reuse/multi-tasking.
> I do not understand the question.
>=20
> Regards
>=20
> Stewart
> >
> > Thank you.
> >
> >
> >
> > *Stewart Bryant <[e-mail]>*
> > =B7=A2=BC=FE=C8=CB: [e-mail]
> >
> > 2009-03-27 14:10
> > =C7=EB=B4=F0=B8=B4 =B8=F8
> > [e-mail]
> >
> >
> >
> > =CA=D5=BC=FE=C8=CB
> > 	Yaakov Stein <[e-mail]>
> > =B3=AD=CB=CD
> > 	"[e-mail]" <[e-mail]>
> > =D6=F7=CC=E2
> > 	Re: [PWE3] Flow Label in fat-pw
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Lucy is correct, we need to turn off s/n or we will have problems.
> >
> > This is because the s/n is defined per pw not per flow.
> >
> > Stewart
> >
> > Yaakov Stein wrote:
> > >
> > > Lucy
> > >
> > >
> > >
> > > Can you explain why you believe there will be misordering ?
> > >
> > >
> > >
> > > Y(J)S
> > >
> > >
> > >
> > > *From:* [e-mail] [mailto:[e-mail]] *On
> > > Behalf Of *Lucy Yong
> > > *Sent:* Friday, March 27, 2009 03:39
> > > *To:* [e-mail]
> > > *Subject:* [PWE3] Flow Label in fat-pw
> > >
> > >
> > >
> > > Hi Bryant,
> > >
> > >
> > >
> > > One comment about using flow label over a pseudowire is: if the
> > > control word is used in a pseudowire and non-zero sequence number =
is
> > > inserted, when using flow labels, it may cause the egress PE =
burden to
> > > perform packet sequencing and increase the possibility of packet =
out
> > > of order. Therefore, it is better to mention in the draft that =
when
> > > the control word presents and non-zero sequence number is used, =
the
> > > flow label should not be used or if it is used, the constant flow
> > > label should be used.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Lucy
> > >
> > >
> > >
> > >
------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pwe3
> > >
> >
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> >
>=20
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3


From [e-mail]  Tue Mar 31 04:49:42 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F79F3A687C for <[e-mail]>; Tue, 31 Mar 2009 04:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.187
X-Spam-Level: 
X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 aqFw5lo4TVTa for <[e-mail]>; Tue, 31 Mar 2009 04:49:41 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 352063A680D for <[e-mail]>; Tue, 31 Mar 2009 04:49:41 -0700 (PDT)
Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2VBoSjE018382 for <[e-mail]>; Tue, 31 Mar 2009 13:50:37 +0200
Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 13:50:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B1F6.E6A2F4C6"
Date: Tue, 31 Mar 2009 13:50:34 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-bryant-filsfils-fat-pw-03 to WG draft?
Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJg==
From: "BOCCI Matthew" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 Mar 2009 11:50:34.0871 (UTC) FILETIME=[E6C80870:01C9B1F6]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 11:49:42 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B1F6.E6A2F4C6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is the start of a two week poll to judge the consensus to move
draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list with your approval (or
otherwise).

This poll will close on 14th April 2009.

Regards

Matthew



------_=_NextPart_001_01C9B1F6.E6A2F4C6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>draft-bryant-filsfils-fat-pw-03 to WG draft?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">This is the start of a two week poll to =
judge the consensus to move draft-bryant-filsfils-fat-pw-03</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;to a PWE3 Working Group =
draft.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please can you respond to the PWE3 list =
with your approval (or otherwise).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This poll will close on 14th April =
2009.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Matthew</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C9B1F6.E6A2F4C6--

From [e-mail]  Tue Mar 31 05:00:04 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239533A6D38; Tue, 31 Mar 2009 05:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.19
X-Spam-Level: 
X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 bOB1xq6kNlli; Tue, 31 Mar 2009 04:59:58 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 817B73A6855; Tue, 31 Mar 2009 04:59:57 -0700 (PDT)
Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2VC0q9l028703;  Tue, 31 Mar 2009 14:00:54 +0200
Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 14:00:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B1F8.57569EED"
Date: Tue, 31 Mar 2009 14:00:52 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-bryant-pwe3-packet-pw-00.txt to WG draft?
Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcA==
From: "BOCCI Matthew" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 Mar 2009 12:00:53.0974 (UTC) FILETIME=[57CBA760:01C9B1F8]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Cc: [e-mail]
Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 12:00:04 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B1F8.57569EED
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is the start of a two week poll to judge the consensus to move
draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please can you respond, *to the PWE3 list only*, with your approval (or
otherwise).

This poll will close on 14th April 2009.

Regards

Matthew




------_=_NextPart_001_01C9B1F8.57569EED
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>draft-bryant-pwe3-packet-pw-00.txt to WG draft?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">This is the start of a two week poll to =
judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 =
Working Group draft.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please can you respond, *to the PWE3 =
list only*, with your approval (or otherwise).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This poll will close on 14th April =
2009.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Matthew</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C9B1F8.57569EED--

From [e-mail]  Tue Mar 31 05:23:15 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4693A6A3C for <[e-mail]>; Tue, 31 Mar 2009 05:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level: 
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 0av87Nffg3JB for <[e-mail]>; Tue, 31 Mar 2009 05:23:14 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 3EED33A68BE for <[e-mail]>; Tue, 31 Mar 2009 05:23:14 -0700 (PDT)
Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2VCN7Ux017072 for <[e-mail]>; Tue, 31 Mar 2009 14:24:10 +0200
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 14:23:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B1FB.70CCE81B"
Date: Tue, 31 Mar 2009 14:23:04 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgABId/Q
References: <[e-mail]>
From: "HENDERICKX Wim" <[e-mail]>
To: "BOCCI Matthew" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 31 Mar 2009 12:23:42.0424 (UTC) FILETIME=[87748D80:01C9B1FB]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 12:23:15 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B1FB.70CCE81B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

support

=20

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of
BOCCI Matthew
Sent: dinsdag 31 maart 2009 13:51
To: [e-mail]
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?

=20

This is the start of a two week poll to judge the consensus to move
draft-bryant-filsfils-fat-pw-03=20
 to a PWE3 Working Group draft.=20

Please can you respond to the PWE3 list with your approval (or
otherwise).=20

This poll will close on 14th April 2009.=20

Regards=20

Matthew=20

=20


------_=_NextPart_001_01C9B1FB.70CCE81B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>draft-bryant-filsfils-fat-pw-03 to WG draft?</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0pt;
	mso-margin-bottom-alt:auto;
	margin-left:0pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>support<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] <b><span =
style=3D'font-weight:
bold'>On Behalf Of </span></b><st1:PersonName w:st=3D"on">BOCCI =
Matthew</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> dinsdag 31 maart =
2009 13:51<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [PWE3]
draft-bryant-filsfils-fat-pw-03 to WG =
draft?</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>This
is the start of a two week poll to judge the consensus to move
draft-bryant-filsfils-fat-pw-03</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;to
a PWE3 Working Group draft.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Please
can you respond to the PWE3 list with your approval (or =
otherwise).</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>This
poll will close on 14th April 2009.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Regards</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Matthew</span></font>
<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9B1FB.70CCE81B--

From [e-mail]  Tue Mar 31 05:37:11 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9873A6C34 for <[e-mail]>; Tue, 31 Mar 2009 05:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.683
X-Spam-Level: 
X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599]
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 WOOJPvOJCsp8 for <[e-mail]>; Tue, 31 Mar 2009 05:37:10 -0700 (PDT)
Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id AAB6D3A6BFF for <[e-mail]>; Tue, 31 Mar 2009 05:37:10 -0700 (PDT)
Received: by qyk36 with SMTP id 36so601593qyk.29 for <[e-mail]>; Tue, 31 Mar 2009 05:38:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :received:message-id:subject:from:to:content-type :content-transfer-encoding; bh=DKiGuGgXNNtE5OPD4QlwyByuPz9d/Xp23O+5/bg+g+M=; b=a8ANlrGaRj3e2D4euWkMg32zm/3l0dYV0Mmx5pHf66nzLxsU14HEizIfpjTQj/0Jh+ 5+K8cdJ6MQGC0F5DqNoI6Ezgdk7qj5Ozqa9rUNem215NxOMD0e573qmYHF3b1NqUWg4S DDdlS6JRH5wH/sSpnq3pZH+weq8X69YpqSYi8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ouZ7EdPudpZwywbkV+uoygfkumGt55RV/S0glGBfRKm4iZgXLr3JjQfVC97IZuv/kj RG1nay06l/VRLt0mi2GnigOpiBRAEW+0N9XEzcvjQOzpe1iJcjwmYdCrkjdaTrLQICkK EppwwLhSD+70dewI8FFgpqBohSeo0jdXGnO38=
MIME-Version: 1.0
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 31 Mar 2009 08:37:54 -0400
Received: by 10.224.60.195 with SMTP id q3mr7997795qah.106.1238503089204; Tue,  31 Mar 2009 05:38:09 -0700 (PDT)
Message-ID: <[e-mail]>
From: "Andrew G. Malis" <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 12:37:11 -0000

Approve.

2009/3/31 BOCCI Matthew <[e-mail]>:
> This is the start of a two week poll to judge the consensus to move
> draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.
>
> Please can you respond, *to the PWE3 list only*, with your approval (or
> otherwise).
>
> This poll will close on 14th April 2009.
>
> Regards
>
> Matthew

From [e-mail]  Tue Mar 31 05:39:19 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7723A6A3C for <[e-mail]>; Tue, 31 Mar 2009 05:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.649
X-Spam-Level: 
X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 CDKYyAn4KIOH for <[e-mail]>; Tue, 31 Mar 2009 05:39:18 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A13CA3A6BFF for <[e-mail]>; Tue, 31 Mar 2009 05:39:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,453,1233532800"; d="scan'208";a="164291173"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2009 12:40:17 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2VCeGTx006525;  Tue, 31 Mar 2009 14:40:16 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2VCeGi5026748; Tue, 31 Mar 2009 12:40:16 GMT
Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2VCeFl06689; Tue, 31 Mar 2009 13:40:15 +0100 (BST)
Message-ID: <[e-mail]>
Date: Tue, 31 Mar 2009 13:40:15 +0100
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=793; t=1238503216; x=1239367216; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Re=3A=20draft-ietf-pwe3-segmented-pw=20WG=20las t=20call |Sender:=20; bh=ecankww0zrK1ooAN8cxlGcAu73wj1mSiTfvJ77JWxg0=; b=UavqMXaenRld1U4qVJGxCIdxtJX+rwL+7Gzx2bhDlihG0rUq3KKhn0kBo5 8aFFxSPokye6CCF+Ns1w48ReaDukWNC/0s7t9843rlZp0ElTl5IJHrjbsSy7 HBTHrrVkAt;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Cc: pwe3 <[e-mail]>, [e-mail]
Subject: Re: [PWE3] draft-ietf-pwe3-segmented-pw WG last call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 12:39:19 -0000

Stewart Bryant wrote:
> This is the start of working group last call on
>
> draft-ietf-pwe3-segmented-pw-11.txt
>
> This draft can be found at
>
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-pw-11.txt
>
> Monday 9th March 2009.
>
> Please read the document and provide feedback to the PWE3 list
>
> Thanks
>
> Stewart
>
During last call I asked about the structure of the draft
and the inclusion of the L2TPv3 text.

This was discussed in SF and the consensus as recorded
in the minutes was to leave the text in.

The only other issues raised were editorial rather than
technical.

I would therefore like to ask the authors to make
the necessary corrections and resubmit the document.

I will then initiate the publication process.

- Stewart

From [e-mail]  Tue Mar 31 05:43:22 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF24B3A6D42 for <[e-mail]>; Tue, 31 Mar 2009 05:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level: 
X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Ss2Pybzc+wZj for <[e-mail]>; Tue, 31 Mar 2009 05:43:22 -0700 (PDT)
Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by core3.amsl.com (Postfix) with ESMTP id 0CAEB3A6CA2 for <[e-mail]>; Tue, 31 Mar 2009 05:43:21 -0700 (PDT)
Received: from cntpacas1.corp.local ([10.225.1.123]) by mx2.mybrighthouse.com (8.14.1/8.14.1) with ESMTP id n2VCiH3Z003620 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Tue, 31 Mar 2009 08:44:19 -0400
Received: from CNEMAIL.corp.local ([10.225.1.128]) by cntpacas1.corp.local ([10.225.1.123]) with mapi; Tue, 31 Mar 2009 08:44:17 -0400
From: "Mallette, Edwin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Tue, 31 Mar 2009 08:44:17 -0400
Thread-Topic: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcAABhBo5
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_DA0D6E76EA1D4D4F87F523AAF9E0CA5E4CB4550D3CCNEMAILcorplo_"
MIME-Version: 1.0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903310049
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 12:43:23 -0000

--_000_DA0D6E76EA1D4D4F87F523AAF9E0CA5E4CB4550D3CCNEMAILcorplo_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U3VwcG9ydC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHB3ZTMt
Ym91bmNlc0BpZXRmLm9yZw0KVG86IHB3ZTNAaWV0Zi5vcmcNCkNjOiBtcGxzLXRwQGlldGYub3Jn
DQpTZW50OiBUdWUgTWFyIDMxIDA4OjAwOjUyIDIwMDkNClN1YmplY3Q6IFtQV0UzXSBkcmFmdC1i
cnlhbnQtcHdlMy1wYWNrZXQtcHctMDAudHh0IHRvIFdHIGRyYWZ0Pw0KDQpUaGlzIGlzIHRoZSBz
dGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgdG8ganVkZ2UgdGhlIGNvbnNlbnN1cyB0byBtb3ZlIGRy
YWZ0LWJyeWFudC1wd2UzLXBhY2tldC1wdy0wMC50eHQgdG8gYSBQV0UzIFdvcmtpbmcgR3JvdXAg
ZHJhZnQuDQoNClBsZWFzZSBjYW4geW91IHJlc3BvbmQsICp0byB0aGUgUFdFMyBsaXN0IG9ubHkq
LCB3aXRoIHlvdXIgYXBwcm92YWwgKG9yIG90aGVyd2lzZSkuDQoNClRoaXMgcG9sbCB3aWxsIGNs
b3NlIG9uIDE0dGggQXByaWwgMjAwOS4NCg0KUmVnYXJkcw0KDQpNYXR0aGV3DQoNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhp
cyBlLW1haWwgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkLCBjb25m
aWRlbnRpYWwgb3Igb3RoZXJ3aXNlIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElmIHlvdSBh
cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBlLW1haWwsIHBsZWFzZSBub3Rp
ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSByZXR1cm4gZS1tYWlsLCBwdXJnZSBpdCBhbmQg
ZG8gbm90IGRpc3NlbWluYXRlIG9yIGNvcHkgaXQuDQo=

--_000_DA0D6E76EA1D4D4F87F523AAF9E0CA5E4CB4550D3CCNEMAILcorplo_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+
DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPHRpdGxlPmRyYWZ0LWJy
eWFudC1wd2UzLXBhY2tldC1wdy0wMC50eHQgdG8gV0cgZHJhZnQ/PC90aXRsZT4NCjwvaGVhZD4N
Cjxib2R5Pg0KPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj5TdXBw
b3J0Ljxicj4NCjwvZm9udD48L3A+DQo8cD48L3A+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUi
IGFsaWduPSJjZW50ZXIiIHRhYmluZGV4PSItMSI+DQo8Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9
IjIiPjxiPkZyb208L2I+OiBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcgPHB3ZTMtYm91bmNlc0BpZXRm
Lm9yZz4NCjxicj4NCjxiPlRvPC9iPjogcHdlM0BpZXRmLm9yZyA8cHdlM0BpZXRmLm9yZz48YnI+
DQo8Yj5DYzwvYj46IG1wbHMtdHBAaWV0Zi5vcmcgPG1wbHMtdHBAaWV0Zi5vcmc+PGJyPg0KPGI+
U2VudDwvYj46IFR1ZSBNYXIgMzEgMDg6MDA6NTIgMjAwOTxicj4NCjxiPlN1YmplY3Q8L2I+OiBb
UFdFM10gZHJhZnQtYnJ5YW50LXB3ZTMtcGFja2V0LXB3LTAwLnR4dCB0byBXRyBkcmFmdD8gPGJy
Pg0KPC9mb250Pg0KPHA+PC9wPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3J0ZiBmb3JtYXQg
LS0+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+VGhpcyBpcyB0aGUgc3RhcnQgb2Yg
YSB0d28gd2VlayBwb2xsIHRvIGp1ZGdlIHRoZSBjb25zZW5zdXMgdG8gbW92ZSBkcmFmdC1icnlh
bnQtcHdlMy1wYWNrZXQtcHctMDAudHh0IHRvIGEgUFdFMyBXb3JraW5nIEdyb3VwIGRyYWZ0Ljwv
Zm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+UGxlYXNlIGNhbiB5b3Ug
cmVzcG9uZCwgKnRvIHRoZSBQV0UzIGxpc3Qgb25seSosIHdpdGggeW91ciBhcHByb3ZhbCAob3Ig
b3RoZXJ3aXNlKS48L2ZvbnQ+DQo8L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+
VGhpcyBwb2xsIHdpbGwgY2xvc2Ugb24gMTR0aCBBcHJpbCAyMDA5LjwvZm9udD4gPC9wPg0KPHA+
PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPlJlZ2FyZHM8L2ZvbnQ+IDwvcD4NCjxwPjxmb250
IHNpemU9IjIiIGZhY2U9IkFyaWFsIj5NYXR0aGV3PC9mb250PiA8L3A+DQo8YnI+DQo8YnI+DQo8
YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPkNPTkZJ
REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZS1tYWlsIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRo
YXQgaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsIG9yIG90aGVyd2lzZSBwcm90ZWN0ZWQgZnJv
bSBkaXNjbG9zdXJlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRo
aXMgZS1tYWlsLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkNCiBieSByZXR1
cm4gZS1tYWlsLCBwdXJnZSBpdCBhbmQgZG8gbm90IGRpc3NlbWluYXRlIG9yIGNvcHkgaXQuPGJy
Pg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_DA0D6E76EA1D4D4F87F523AAF9E0CA5E4CB4550D3CCNEMAILcorplo_--

From [e-mail]  Tue Mar 31 06:15:22 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0751B3A69BA for <[e-mail]>; Tue, 31 Mar 2009 06:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 dvJmcKv8QY4O for <[e-mail]>; Tue, 31 Mar 2009 06:15:21 -0700 (PDT)
Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id 14EF73A679C for <[e-mail]>; Tue, 31 Mar 2009 06:15:21 -0700 (PDT)
Received: from smtptpa3.verizon.com (smtptpa3.verizon.com [138.83.71.176]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id n2VD72A1015523; Tue, 31 Mar 2009 09:07:02 -0400 (EDT)
Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com [138.83.131.184]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id n2VDGH0l008839; Tue, 31 Mar 2009 09:16:17 -0400 (EDT)
Received: from ftwintrmemf2.verizon.com (unknown [127.0.0.1]) by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id 9BEC0528002; Tue, 31 Mar 2009 09:16:17 -0400 (EDT)
X-AuditID: 8a5383b8-a0decbb000000632-09-49d217a1bfa8
Received: from smtptpa3.verizon.com (unknown [138.83.71.176]) by ftwintrmemf2.verizon.com (EMF) with ESMTP id 070404E4002; Tue, 31 Mar 2009 09:16:16 -0400 (EDT)
Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id n2VDGCoQ008631; Tue, 31 Mar 2009 09:16:16 -0400 (EDT)
Received: from FHDP1LUMXCV21.us.one.verizon.com ([166.68.125.50]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 09:16:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B202.DE2DCFCB"
Date: Tue, 31 Mar 2009 09:16:14 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcAACpQsA
References: <[e-mail]>
From: "Krzanowski, Roman" <[e-mail]>
To: "BOCCI Matthew" <[e-mail]>
X-OriginalArrivalTime: 31 Mar 2009 13:16:14.0794 (UTC) FILETIME=[DE6A0AA0:01C9B202]
X-Brightmail-Tracker: AAAAAA==
Cc: [e-mail]
Subject: Re: [PWE3] [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 13:15:22 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B202.DE2DCFCB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I approve

=20

From: [e-mail] [mailto:[e-mail]] On
Behalf Of BOCCI Matthew
Sent: Tuesday, March 31, 2009 8:01 AM
To: [e-mail]
Cc: [e-mail]
Subject: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

=20

This is the start of a two week poll to judge the consensus to move
draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please can you respond, *to the PWE3 list only*, with your approval (or
otherwise).=20

This poll will close on 14th April 2009.=20

Regards=20

Matthew=20

=20


------_=_NextPart_001_01C9B202.DE2DCFCB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>draft-bryant-pwe3-packet-pw-00.txt to WG draft?</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I approve<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Behalf =
Of </b>BOCCI
Matthew<br>
<b>Sent:</b> Tuesday, March 31, 2009 8:01 AM<br>
<b>To:</b> [e-mail]<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG =
draft?<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>This is the
start of a two week poll to judge the consensus to move
draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group =
draft.</span><o:p></o:p></p>

<p><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Please can
you respond, *to the PWE3 list only*, with your approval (or =
otherwise).</span>
<o:p></o:p></p>

<p><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>This poll
will close on 14th April 2009.</span> <o:p></o:p></p>

<p><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Regards</span=
>
<o:p></o:p></p>

<p><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Matthew</span=
>
<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9B202.DE2DCFCB--

From [e-mail]  Tue Mar 31 06:49:05 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEDC3A6D46 for <[e-mail]>; Tue, 31 Mar 2009 06:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level: 
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001]
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 Rsin-X9fxI+0 for <[e-mail]>; Tue, 31 Mar 2009 06:49:05 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 3B37E3A6C80 for <[e-mail]>; Tue, 31 Mar 2009 06:49:05 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 6085A2684EA; Tue, 31 Mar 2009 07:50:04 -0600 (MDT)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for [e-mail]; Tue, 31 Mar 2009 07:50:04 -0600 (MDT) (envelope-from [e-mail])
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60678; data-bytes=0
Message-Id: <[e-mail]>
From: Shane Amante <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-16-354681436
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 31 Mar 2009 07:50:02 -0600
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 13:49:06 -0000

--Apple-Mail-16-354681436
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Support.

-shane


On Mar 31, 2009, at 5:50 AM, BOCCI Matthew wrote:

> This is the start of a two week poll to judge the consensus to move  
> draft-bryant-filsfils-fat-pw-03
>  to a PWE3 Working Group draft.
>
> Please can you respond to the PWE3 list with your approval (or  
> otherwise).
>
> This poll will close on 14th April 2009.
>
> Regards
>
> Matthew
>
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3


--Apple-Mail-16-354681436
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; =
">Support.<div><br></div><div>-shane</div><div><br></div><div><br><div><di=
v>On Mar 31, 2009, at 5:50 AM, BOCCI Matthew wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"> <div> =
<!-- Converted from text/rtf format --><p><font size=3D"2" =
face=3D"Arial">This is the start of a two week poll to judge the =
consensus to move draft-bryant-filsfils-fat-pw-03</font> <br><font =
size=3D"2" face=3D"Arial">&nbsp;to a PWE3 Working Group draft.</font> =
</p><p><font size=3D"2" face=3D"Arial">Please can you respond to the =
PWE3 list with your approval (or otherwise).</font> </p><p><font =
size=3D"2" face=3D"Arial">This poll will close on 14th April =
2009.</font> </p><p><font size=3D"2" face=3D"Arial">Regards</font> =
</p><p><font size=3D"2" face=3D"Arial">Matthew</font> </p> <br> </div> =
_______________________________________________<br>pwe3 mailing =
list<br><a =
href=3D"mailto:[e-mail]">[e-mail]</a><br>https://www.ietf.org/ma=
ilman/listinfo/pwe3<br></blockquote></div><br></div></body></html>=

--Apple-Mail-16-354681436--

From [e-mail]  Tue Mar 31 06:57:35 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D614428C150 for <[e-mail]>; Tue, 31 Mar 2009 06:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.623
X-Spam-Level: 
X-Spam-Status: No, score=-9.623 tagged_above=-999 required=5 tests=[AWL=0.976,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 IV-HDZhkVpAA for <[e-mail]>; Tue, 31 Mar 2009 06:57:35 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B29AB28C141 for <[e-mail]>; Tue, 31 Mar 2009 06:57:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,453,1233532800"; d="scan'208";a="37124226"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2009 13:58:32 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2VDwWa3012845 for <[e-mail]>; Tue, 31 Mar 2009 15:58:32 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2VDwWIe028516 for <[e-mail]>; Tue, 31 Mar 2009 13:58:32 GMT
Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n2VDwVl14324; Tue, 31 Mar 2009 14:58:31 +0100 (BST)
Message-ID: <[e-mail]>
Date: Tue, 31 Mar 2009 14:58:31 +0100
From: Stewart Bryant <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: pwe3 <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=273; t=1238507912; x=1239371912; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Stewart=20Bryant=20<[e-mail]> |Subject:=20Fibre=20Channel=20Drafts=20-=20Last=20Call |Sender:=20; bh=rFNyhdL+tqvze4zrC//t57fug6LXr5B1NAZ759GJIZQ=; b=mvn1AFmGn2Op8eDkqVf0Smu3ycfFsmZePU4eUcIoKAWVoO+Jmh42iCwUkK ML5Bk0xuFm8JRSpNKLERof6Jc/u0K0If55juQzuvQkk5p4F0GzjxKU6vWy25 OUnU5TORGv;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
Subject: [PWE3] Fibre Channel Drafts - Last Call
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 13:57:35 -0000

This is the start of a four week last call on the two
Fibre Channel Drafts.

These drafts are

http://tools.ietf.org/html/draft-ietf-pwe3-fc-encap-09

and

http://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-fc-flow/

Last call will end on 28th April 2008

Stewart






From [e-mail]  Tue Mar 31 07:13:19 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8013A63C9; Tue, 31 Mar 2009 07:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.154
X-Spam-Level: 
X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 VJX14HAM8GIk; Tue, 31 Mar 2009 07:13:19 -0700 (PDT)
Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 8183F3A6C52; Tue, 31 Mar 2009 07:13:18 -0700 (PDT)
Received: by fxm2 with SMTP id 2so2458275fxm.37 for <multiple recipients>; Tue, 31 Mar 2009 07:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=10FdM57oOR3fnms+RNU3nxRvhXhWeMP8NgsO8Zue9Fg=; b=vX/nVegnAw7uqwEcZTeeFUQuNLB9mvtLAjdjwSUB3euooI906/AaejK+oyNQabBmZ+ KhaZxaHiiCZYqdD1958MzgbqO54vjK/kUUczL4AM37v4eqbcvMAwA8nN/X9h9sxV4hD9 svBAb/C0kyFV76Yrll+PXmBPmG84BY7CxrlqM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I1zOeT8KSdwG4ClrgebfFQpIoXtQt2MBudrxNE0pWfiq0I/6TKS3SYtP5ygzvm9AcO qjghhywwuXeflDxA08v/H1Yr6LIdIXzjvoUc9b5l8ZDSuJIVjiEKUDT1ovRh8nTyczA5 8U2fGqEW2dj8uXbh3YNDFv5YgLoBhBhAsiwLA=
MIME-Version: 1.0
Received: by 10.103.243.9 with SMTP id v9mr2290698mur.91.1238508856922; Tue,  31 Mar 2009 07:14:16 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 31 Mar 2009 10:14:16 -0400
Message-ID: <[e-mail]>
From: Greg Mirsky <[e-mail]>
To: BOCCI Matthew <[e-mail]>
Content-Type: multipart/alternative; boundary=0016369205b177d41604666ad010
Cc: [e-mail], [e-mail]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 14:13:19 -0000

--0016369205b177d41604666ad010
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Support,
Greg

2009/3/31 BOCCI Matthew <[e-mail]>

>  This is the start of a two week poll to judge the consensus to move
> draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.
>
> Please can you respond, *to the PWE3 list only*, with your approval (or
> otherwise).
>
> This poll will close on 14th April 2009.
>
> Regards
>
> Matthew
>
>
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

--0016369205b177d41604666ad010
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Support,<br>Greg<br><br><div class=3D"gmail_quote">2009/3/31 BOCCI Matthew =
<span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">M=
[e-mail]</a>&gt;</span><br><blockquote class=3D"gmai=
l_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0p=
t 0pt 0.8ex; padding-left: 1ex;">







<div>


<p><font size=3D"2" face=3D"Arial">This is the start of a two week poll to =
judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Wo=
rking Group draft.</font></p>

<p><font size=3D"2" face=3D"Arial">Please can you respond, *to the PWE3 lis=
t only*, with your approval (or otherwise).</font>
</p>

<p><font size=3D"2" face=3D"Arial">This poll will close on 14th April 2009.=
</font>
</p>

<p><font size=3D"2" face=3D"Arial">Regards</font>
</p>

<p><font size=3D"2" face=3D"Arial">Matthew</font>
</p>
<br>
<br>

</div>
<br>_______________________________________________<br>
pwe3 mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/pwe3</a><br>
<br></blockquote></div><br>

--0016369205b177d41604666ad010--

From [e-mail]  Tue Mar 31 10:17:10 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BEB428C14C; Tue, 31 Mar 2009 10:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.775
X-Spam-Level: 
X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=1.823,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 oP10tOI61LRZ; Tue, 31 Mar 2009 10:17:09 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 678E53A68BA; Tue, 31 Mar 2009 10:17:09 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]>; Tue, 31 Mar 2009 10:18:08 -0700 (PDT)
Received: from Y73674 ([10.124.12.103]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]>; Tue, 31 Mar 2009 10:13:01 -0700 (PDT)
Date: Tue, 31 Mar 2009 12:13:01 -0500
From: Lucy Yong <[e-mail]>
In-reply-to: <[e-mail]>
To: 'BOCCI Matthew' <[e-mail]>, [e-mail]
Message-id: <000001c9b223$f28260c0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_Dc3s3WaRJuZoskK+T2CKlQ)"
Thread-index: Acmx+FcP5L7TrJafSfatI2vSUDObcAAK1Mfg
References: <[e-mail]>
Cc: [e-mail]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 17:17:10 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_Dc3s3WaRJuZoskK+T2CKlQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Support!

 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of
BOCCI Matthew
Sent: Tuesday, March 31, 2009 7:01 AM
To: [e-mail]
Cc: [e-mail]
Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

 

This is the start of a two week poll to judge the consensus to move
draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please can you respond, *to the PWE3 list only*, with your approval (or
otherwise). 

This poll will close on 14th April 2009. 

Regards 

Matthew 

 


--Boundary_(ID_Dc3s3WaRJuZoskK+T2CKlQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>draft-bryant-pwe3-packet-pw-00.txt to WG draft?</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Tahoma;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=3 color=blue face=Tahoma><span style='font-size:
12.0pt;font-family:Tahoma;color:blue'>Support!<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 color=blue face=Tahoma><span style='font-size:
12.0pt;font-family:Tahoma;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] <b><span style='font-weight:
bold'>On Behalf Of </span></b>BOCCI Matthew<br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, March 31, 2009 7:01
AM<br>
<b><span style='font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style='font-weight:bold'>Cc:</span></b> [e-mail]<br>
<b><span style='font-weight:bold'>Subject:</span></b> [PWE3]
draft-bryant-pwe3-packet-pw-00.txt to WG draft?</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>This
is the start of a two week poll to judge the consensus to move
draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.</span></font><o:p></o:p></p>

<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Please
can you respond, *to the PWE3 list only*, with your approval (or otherwise).</span></font>
<o:p></o:p></p>

<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>This
poll will close on 14th April 2009.</span></font> <o:p></o:p></p>

<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Regards</span></font>
<o:p></o:p></p>

<p><font size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>Matthew</span></font>
<o:p></o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</body>

</html>

--Boundary_(ID_Dc3s3WaRJuZoskK+T2CKlQ)--

From [e-mail]  Tue Mar 31 10:17:10 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605BF3A68BA for <[e-mail]>; Tue, 31 Mar 2009 10:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.383
X-Spam-Level: 
X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=1.216,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 su6nCQqLy7DH for <[e-mail]>; Tue, 31 Mar 2009 10:17:09 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 81EAE28C124 for <[e-mail]>; Tue, 31 Mar 2009 10:17:09 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 31 Mar 2009 10:18:08 -0700 (PDT)
Received: from Y73674 ([10.124.12.103]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 31 Mar 2009 10:13:02 -0700 (PDT)
Date: Tue, 31 Mar 2009 12:13:01 -0500
From: Lucy Yong <[e-mail]>
To: 'Stewart Bryant' <[e-mail]>, [e-mail], "'Malis, Andrew G. (Andy)'" <[e-mail]>
Message-id: <000a01c9b223$f2da92e0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_F8hopwBC9qTZL7yqM6lrsg)"
Thread-index: AcmyI4Nnqb8cEzjOSpOy+Ti8D0psag==
Subject: [PWE3] comments on packet pw
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 17:17:10 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_F8hopwBC9qTZL7yqM6lrsg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Stewart and Andy,

 

I support this draft to become WG draft. Congratulation!!

I also have some comments on the draft:

 

1)     Since Packet PW requires using CW, it is necessary to state how to
use flow label and S/N for packet PW.

2)     It is good to have the PW status mapped to virtual interfaces.
However, each protocol interface may have its own link status protocol
running, the draft should state the procedures to determine interface
status, or require each protocol interface to turn off its link protocol
when using Packet PW

3)     Since Packet PW acts as a data link between two clients LSRs, the
draft should state link operational procedures (for client networks) over a
packet PW such as how to determine admin cost, TE metrics, etc.

4)     I assume that a Packet PW can obtain transport resiliency from server
MPLS network, it would be nice for the draft to state them and considers
that the consequence may change admin cost in client networks.

 

Cheers,

Lucy


--Boundary_(ID_F8hopwBC9qTZL7yqM6lrsg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Tahoma;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:2096785456;
	mso-list-type:hybrid;
	mso-list-template-ids:-1973661318 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Hi Stewart and Andy,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>I support this draft to become WG draft. Congratulation!!<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>I also have some comments on the draft:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><span
style='mso-list:Ignore'>1)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
face=Tahoma><span style='font-family:Tahoma'>Since Packet PW requires using CW,
it is necessary to state how to use flow label and S/N for packet PW.<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><span
style='mso-list:Ignore'>2)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
face=Tahoma><span style='font-family:Tahoma'>It is good to have the PW status
mapped to virtual interfaces. However, each protocol interface may have its own
link status protocol running, the draft should state the procedures to determine
interface status, or require each protocol interface to turn off its link
protocol when using Packet PW<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><span
style='mso-list:Ignore'>3)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
face=Tahoma><span style='font-family:Tahoma'>Since Packet PW acts as a data
link between two clients LSRs, the draft should state link operational
procedures (for client networks) over a packet PW such as how to determine admin
cost, TE metrics, etc.<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><span
style='mso-list:Ignore'>4)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
face=Tahoma><span style='font-family:Tahoma'>I assume that a Packet PW can obtain
transport resiliency from server MPLS network, it would be nice for the draft
to state them and considers that the consequence may change admin cost in
client networks.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Cheers,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Lucy<o:p></o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_F8hopwBC9qTZL7yqM6lrsg)--

From [e-mail]  Tue Mar 31 16:27:30 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDE13A6B60 for <[e-mail]>; Tue, 31 Mar 2009 16:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
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 9z3GUq++qzCT for <[e-mail]>; Tue, 31 Mar 2009 16:27:29 -0700 (PDT)
Received: from napoleon.monoski.com (black.monoski.com [63.227.123.238]) by core3.amsl.com (Postfix) with ESMTP id 9C4853A6B0F for <[e-mail]>; Tue, 31 Mar 2009 16:27:29 -0700 (PDT)
Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n2VNSLtV018624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 17:28:22 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Tue, 31 Mar 2009 17:28:21 -0600
From: Luca Martini <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20081209)
MIME-Version: 1.0
To: BOCCI Matthew <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1
Cc: [e-mail]
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 23:27:30 -0000

Support.
Luca

BOCCI Matthew wrote:
>
> This is the start of a two week poll to judge the consensus to move 
> draft-bryant-filsfils-fat-pw-03
>  to a PWE3 Working Group draft.
>
> Please can you respond to the PWE3 list with your approval (or 
> otherwise).
>
> This poll will close on 14th April 2009.
>
> Regards
>
> Matthew
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>   


From [e-mail]  Tue Mar 31 19:32:48 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDB93A687F for <[e-mail]>; Tue, 31 Mar 2009 19:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.132
X-Spam-Level: 
X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.466,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 bPvhM+J01du1 for <[e-mail]>; Tue, 31 Mar 2009 19:32:48 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 185923A68D5 for <[e-mail]>; Tue, 31 Mar 2009 19:32:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,305,1235952000";  d="scan'208,217";a="277807511"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2009 02:33:48 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n312XmTE031780;  Tue, 31 Mar 2009 19:33:48 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n312XmbH009311; Wed, 1 Apr 2009 02:33:48 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 31 Mar 2009 19:33:47 -0700
Received: from sboutros-wxp01.ciswco.com ([10.21.112.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 31 Mar 2009 19:33:47 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 31 Mar 2009 19:33:44 -0700
To: "BOCCI Matthew" <[e-mail]>, <[e-mail]>
From: Sami Boutros <[e-mail]>
In-Reply-To: <[e-mail]2.a d.alcatel.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_186835625==.ALT"
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 01 Apr 2009 02:33:47.0463 (UTC) FILETIME=[48D3DD70:01C9B272]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1906; t=1238553228; x=1239417228; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Sami=20Boutros=20<[e-mail]> |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=j6rf4GJl8FWUPYC5b15gO9nmMKTG4v99lddOabDUCII=; b=b/KscchXKKLqGBtSRGuhjbonccAZIK/os+k1Qgc4AZ35lc5eXsqN3ZAh7W 8HNG+X8sECZtM95IJXaHUCJHABQ8U2N3W3p+oFHtdKMK/cXdRMUo8NsRUL7p G826pI8J7M;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2009 02:32:48 -0000

--=====================_186835625==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Support.

Thanks,

Sami
At 04:50 AM 3/31/2009, BOCCI Matthew wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C9B1F6.E6A2F4C6"
>
>This is the start of a two week poll to judge the consensus to move 
>draft-bryant-filsfils-fat-pw-03
>  to a PWE3 Working Group draft.
>
>Please can you respond to the PWE3 list with your approval (or otherwise).
>
>This poll will close on 14th April 2009.
>
>Regards
>
>Matthew
>
>_______________________________________________
>pwe3 mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pwe3


--=====================_186835625==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Support.<br><br>
Thanks,<br><br>
Sami<br>
At 04:50 AM 3/31/2009, BOCCI Matthew wrote:<br>
<blockquote type=cite class=cite cite="">Content-class:
urn:content-classes:message<br>
Content-Type: multipart/alternative;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
boundary=&quot;----_=_NextPart_001_01C9B1F6.E6A2F4C6&quot;<br><br>
<font size=2>This is the start of a two week poll to judge the consensus
to move draft-bryant-filsfils-fat-pw-03</font> <br>
<font size=2>&nbsp;to a PWE3 Working Group draft.</font> <br><br>
<font size=2>Please can you respond to the PWE3 list with your approval
(or otherwise).</font> <br><br>
<font size=2>This poll will close on 14th April 2009.</font> <br><br>
<font size=2>Regards</font> <br><br>
<font size=2>Matthew</font> <br><br>
_______________________________________________<br>
pwe3 mailing list<br>
[e-mail]<br>
<a href="https://www.ietf.org/mailman/listinfo/pwe3" eudora="autourl">
https://www.ietf.org/mailman/listinfo/pwe3</a></blockquote></body>
<br>
</html>

--=====================_186835625==.ALT--


From [e-mail]  Tue Mar 31 22:43:19 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE55E3A6B0B; Tue, 31 Mar 2009 22:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 0xmDLy36b9Oc; Tue, 31 Mar 2009 22:43:19 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0D3753A6823; Tue, 31 Mar 2009 22:43:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="148928775"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2009 05:44:17 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n315iHlu023539;  Tue, 31 Mar 2009 22:44:17 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n315iH1M002163; Wed, 1 Apr 2009 05:44:17 GMT
Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 31 Mar 2009 22:44:17 -0700
Received: from [10.21.67.213] ([10.21.67.213]) by xmb-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 31 Mar 2009 22:44:16 -0700
Message-ID: <[e-mail]>
Date: Tue, 31 Mar 2009 22:44:16 -0700
From: Atri Indiresan <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: BOCCI Matthew <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Apr 2009 05:44:16.0573 (UTC) FILETIME=[E51BA6D0:01C9B28C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=583; t=1238564657; x=1239428657; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Atri=20Indiresan=20<[e-mail]> |Subject:=20Re=3A=20[PWE3]=20draft-bryant-pwe3-packet-pw-00 .txt=20to=20WG=20draft? |Sender:=20; bh=15pqDorf3v+pXmv2Q1TMWzzzFcQh9ypAAg0TVBPmhHk=; b=aMVF6DgBr9dRXdWRVeF99E2r4sqDGlIRO8P0bK+qvgix96wo9JIioPJRsC EzWZjIX7Zcz/KXe7LCYEfnyAD0qKhHYml/TPID/x205+wACDo+BDhAmQssMn 4w/UX9ZezFg7kohIfkzkXrxIcbSIQcT/1vYqSkmA8KpxG0P5XLBH0=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Cc: [e-mail], [e-mail]
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2009 05:43:20 -0000

support

Atri

BOCCI Matthew wrote:
>
> This is the start of a two week poll to judge the consensus to move 
> draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.
>
> Please can you respond, *to the PWE3 list only*, with your approval 
> (or otherwise).
>
> This poll will close on 14th April 2009.
>
> Regards
>
> Matthew
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>   

From [e-mail]  Tue Mar 31 22:46:35 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A133A6823 for <[e-mail]>; Tue, 31 Mar 2009 22:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 oemhq20Rs5H2 for <[e-mail]>; Tue, 31 Mar 2009 22:46:34 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A2A023A672F for <[e-mail]>; Tue, 31 Mar 2009 22:46:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="164749034"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2009 05:47:34 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n315lYBl013672;  Tue, 31 Mar 2009 22:47:34 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n315lYvw004520; Wed, 1 Apr 2009 05:47:34 GMT
Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 31 Mar 2009 22:47:34 -0700
Received: from [10.21.67.213] ([10.21.67.213]) by xmb-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 31 Mar 2009 22:47:34 -0700
Message-ID: <[e-mail]>
Date: Tue, 31 Mar 2009 22:47:33 -0700
From: Atri Indiresan <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: BOCCI Matthew <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Apr 2009 05:47:34.0040 (UTC) FILETIME=[5ACEB980:01C9B28D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=573; t=1238564854; x=1239428854; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Atri=20Indiresan=20<[e-mail]> |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=FW9Za5f2PBpCiDF4Uz5ykS65sALVIA9fQxEpZFwRSck=; b=Kt1NzoaxXBUZkuXMHR0TyCAu6RUksc8AbKBxBlADdmofOrX5Andqtolf1h 1t4IRVDj/jxKzuNytWO6WZHXjCFAln+ElGOYJ/fzEkY5WXwV6T6i43whu2mI 1LczWxJYR6;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: [e-mail]
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2009 05:46:35 -0000

Support.

Atri

BOCCI Matthew wrote:
>
> This is the start of a two week poll to judge the consensus to move 
> draft-bryant-filsfils-fat-pw-03
>  to a PWE3 Working Group draft.
>
> Please can you respond to the PWE3 list with your approval (or 
> otherwise).
>
> This poll will close on 14th April 2009.
>
> Regards
>
> Matthew
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>   

From [e-mail]  Tue Mar 31 23:53:28 2009
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8406828C122 for <[e-mail]>; Tue, 31 Mar 2009 23:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.443
X-Spam-Level: 
X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 uPmsUoKOVLQe for <[e-mail]>; Tue, 31 Mar 2009 23:53:27 -0700 (PDT)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 4846128C0FC for <[e-mail]>; Tue, 31 Mar 2009 23:53:27 -0700 (PDT)
Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 1 Apr 2009 07:54:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B296.B1B66202"
Date: Wed, 1 Apr 2009 07:54:22 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgAnmw6g
From: <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 01 Apr 2009 06:54:26.0603 (UTC) FILETIME=[B27B3FB0:01C9B296]
Cc: [e-mail]
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2009 06:53:28 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B296.B1B66202
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stewart, can I please ask if this draft would be applicable to MPLS-TP?
=20
I ask this because a transport network should satisfy the requirements
of transparency....which in brief means:
=20
-    all client bits treated equally
-    client bit ordering preserved
-    no attempt made to try understand semantics of client symbols (ie
client message/traffic-unit formed from N client bits) and never change
client bits
-    server ensures client X traffic behaviour cannot impact performance
experienced by client Y
=20
...and I cannot reconcile this with this draft.  So perhaps this draft
is only intended to apply to 'classical' MPLS?
=20
regards, Neil


________________________________

	From: [e-mail] [mailto:[e-mail]] On
Behalf Of BOCCI Matthew
	Sent: 31 March 2009 12:51
	To: [e-mail]
	Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
=09
=09

	This is the start of a two week poll to judge the consensus to
move draft-bryant-filsfils-fat-pw-03=20
	 to a PWE3 Working Group draft.=20

	Please can you respond to the PWE3 list with your approval (or
otherwise).=20

	This poll will close on 14th April 2009.=20

	Regards=20

	Matthew=20



------_=_NextPart_001_01C9B296.B1B66202
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>draft-bryant-filsfils-fat-pw-03 to WG draft?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>Stewart, can I please ask if this draft would =
be=20
applicable to MPLS-TP?</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>I ask this because a transport network should =
satisfy=20
the requirements of transparency....which in brief =
means:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>-&nbsp;&nbsp;&nbsp; all client bits treated=20
equally</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>-&nbsp;&nbsp;&nbsp; client bit ordering=20
preserved</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>-&nbsp;&nbsp;&nbsp; no attempt made to try =
understand=20
semantics of client symbols (ie client message/traffic-unit&nbsp;formed =
from N=20
client bits) and never change client bits</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>-&nbsp;&nbsp;&nbsp; server ensures client X =
traffic=20
behaviour cannot impact performance experienced by client =
Y</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>...and I cannot reconcile this with this =
draft.&nbsp;=20
So perhaps this draft is only intended to apply to 'classical'=20
MPLS?</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
class=3D218364406-01042009>regards, Neil</SPAN></FONT></DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>BOCCI=20
  Matthew<BR><B>Sent:</B> 31 March 2009 12:51<BR><B>To:</B>=20
  [e-mail]<BR><B>Subject:</B> [PWE3] =
draft-bryant-filsfils-fat-pw-03 to WG=20
  draft?<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/rtf format -->
  <P><FONT face=3DArial size=3D2>This is the start of a two week poll to =
judge the=20
  consensus to move draft-bryant-filsfils-fat-pw-03</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>&nbsp;to a PWE3 Working Group draft.</FONT> </P>
  <P><FONT face=3DArial size=3D2>Please can you respond to the PWE3 list =
with your=20
  approval (or otherwise).</FONT> </P>
  <P><FONT face=3DArial size=3D2>This poll will close on 14th April =
2009.</FONT>=20
</P>
  <P><FONT face=3DArial size=3D2>Regards</FONT> </P>
  <P><FONT face=3DArial size=3D2>Matthew</FONT> =
</P><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C9B296.B1B66202--