email: sasha@axerra.com

tel: +972-3-7659993=20 (office)

=20 +972-8-9254948 (res.)

=20 +972-58-674833 (cell.)

-----Original Message-----
From: Torben Rasmussen=20 [mailto:tra@tpack.net]
Sent: Wednesday, June 02, 2004 2:49=20 PM
To: pwe3@ietf.org
Subject: [PWE3] References = in=20 draft-ietf-pwe3-cesopsn-01.txt and=20 draft-ietf-pwe3-satop-01.txt

draft-ietf-pwe3-cesopsn-01.txt and=20 draft-ietf-pwe3-satop-01.txt.

Both papers is referring to a sub clause = 5.4.4 with=20 the reference [PWE3-ARCH] there is something wrong the see figure 3 = in both=20 documents.

In draft-ietf-pwe3-cesopsn-01.txt it makes = reference=20 to draft-ietf-pwe3-arch-06.txt there is no sub clause 5.4.4 in the = new=20 draft-ietf-pwe3-arch-07.txt version.

For draft-ietf-pwe3-satop-01.txt it refers = to=20 draft-ietf-pwe3-framework-06.txt here the document do not exist, in = the old=20 version of satop-00.txt it makes reference to = draft-ietf-pwe3-arch-06.txt and=20 ones again the new document do not contain this sub = clause.

Anyone that is able to explain this and = give a hint=20 where to find the information about the first four bits of the = control=20 word?

Thanks

Torben Rasmussen

------_=_NextPart_001_01C44944.77D5A370-- ------=_NextPartTM-000-875d4bcd-c84c-42ea-9631-345815b4995c Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------=_NextPartTM-000-875d4bcd-c84c-42ea-9631-345815b4995c-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-sonet-07.txt Date: Thu, 03 Jun 2004 15:57:56 -0400 Lines: 96 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Jun 03 23:39:37 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation over Packet (CEP) Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-sonet-07.txt Pages : 48 Date : 2004-6-3 This draft provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over a packet-switched network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-sonet-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-sonet-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: RE: I-D ACTION:draft-ietf-pwe3-sonet-07.txt Date: Thu, 3 Jun 2004 14:59:38 -0700 Lines: 93 Sender: pwe3-bounces@ietf.org References: <200406031957.PAA09103@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Fri Jun 04 01:05:36 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <200406031957.PAA09103@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Oy vay, The only changes I made were: 1. Section 9.1 last paragraph CEP-NE failures should be limited to Type-2 defects. It should read: "CEP-NE failure is declared after 2.5 +/- 0.5 seconds of CEP-NE Type-2 defect, and cleared after 10 seconds free of CEP-NE defect state. Sending notification to the OS for CEP-NE failure is local policy." 2. Remove references from abstract section to comply with ID nits For some unknown reason the draft on the web has text and page alignment problems. I don't have these problems on the draft I have (the one that was sent to the ietf submission email). I'm trying to find out what went wrong and fix it. Apologies Ron > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Thursday, June 03, 2004 12:58 PM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-sonet-07.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Pseudo Wire Emulation Edge > to Edge Working Group of the IETF. > > Title : SONET/SDH Circuit Emulation over Packet (CEP) > Author(s) : A. Malis, et al. > Filename : draft-ietf-pwe3-sonet-07.txt > Pages : 48 > Date : 2004-6-3 > > This draft provides encapsulation formats and semantics for > emulating SONET/SDH circuits and services over a packet-switched > network (PSN). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-07.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to > change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pwe3-sonet-07.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pwe3-sonet-07.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Vach Kompella" Subject: Interface parameters Date: Fri, 4 Jun 2004 09:30:57 -0700 Organization: Alcatel USA Lines: 41 Sender: pwe3-bounces@ietf.org Reply-To: vach.kompella@alcatel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Fri Jun 04 18:54:16 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 04 Jun 2004 16:30:55.0924 (UTC) FILETIME=[4F774740:01C44A51] Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org We need some text around the interface parameters that defines the behavior when an unknown interface parameter is seen. E.g., some vendors have implemented FCS retention, and there is apparently no way to turn it off. Any code that pre-dates FCS retention may or may not work with this up-level code because: - there are mandatory interface parameters - there are optional interface parameters - there is no way to tell if, for a PW, an interface parameter is optional or mandatory - any new interface parameter may also be mandatory or optional So it is fine for the FCS retention draft to say that it is backwards compatible with any pre-FCS retention implementation. However, that is true only if the behavior of the older implementations is to ignore any unknown interface parameters. This is what draft-ietf-pwe3-control says: 5.4. Interface Parameters Field This field specifies interface specific parameters. When applicable, ^^^^^^^^^^^^^^^ it MUST be used to validate that the PEs, and the ingress and egress ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ports at the edges of the circuit, have the necessary capabilities to interoperate with each other. The field structure is defined as follows: This is not an implementable statement: pre-existing implementations cannot tell if a new interface parameter MUST be used to validate the PW. Have I missed some other place which describes it better? The behavior, say, when unknown LDP messages or TLVs are received is better defined. Those U/F bits don't exist for interface parameters. Vach Kompella IP Division, Alcatel vach.kompella@alcatel.com +1 650 237-5152=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: Interface parameters Date: Fri, 04 Jun 2004 14:01:43 -0400 Lines: 4 Sender: pwe3-bounces@ietf.org References: <014701c44a51$51d58290$0101010a@eng.timetra.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Jun 04 20:22:08 2004 Return-path: X-BrightmailFiltered: true To: vach.kompella@alcatel.com In-reply-to: Your message of Fri, 04 Jun 2004 09:30:57 -0700. <014701c44a51$51d58290$0101010a@eng.timetra.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Perhaps it is a mistake to try to use the Interface Parameters as a generalized capabilities negotiation mechanism. Has consideration been given to an alternative, such as using a new LDP TLV? From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Shah, Himanshu" Subject: RE: Interface parameters Date: Fri, 4 Jun 2004 14:34:15 -0400 Lines: 30 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Jun 04 20:51:06 2004 Return-path: To: "'erosen@cisco.com'" , vach.kompella@alcatel.com X-Mailer: Internet Mail Service (5.5.2657.72) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is exactly what we propose in draft-shah-pwe3-control-protocol-extension-01.txt. A mechanism to dynamically exchange/negotiate capabilities/parameters in a backward compatible fashion. /himanshu > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, June 04, 2004 2:02 PM > To: vach.kompella@alcatel.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Interface parameters > > > > Perhaps it is a mistake to try to use the Interface > Parameters as a > generalized capabilities negotiation mechanism. Has > consideration been > given to an alternative, such as using a new LDP TLV? > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: Re: References in draft-ietf-pwe3-cesopsn-01.txt and draft -ietf-pwe3-satop-01.txt Date: Fri, 04 Jun 2004 22:34:36 +0100 Organization: Cisco Systems, Inc. Lines: 84 Sender: pwe3-bounces@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Torben Rasmussen' , "Yaakov Stein $E-mail$" , pwe3@ietf.org X-From: pwe3-bounces@ietf.org Sat Jun 05 00:02:52 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Sasha Vainshtein In-Reply-To: Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha Vainshtein wrote: > Torben and all, > > draft-ietf-pwe3-satop-01.txt and draft-ietf-pwe3-cesopsn-00.txt have > been posted in December 2003 and January 2004 respectively, while > draft-ietf-pwe3-arch-07.txt has has been only posted in March 2004. > Sub-clause 5.4.4 existed in the -06 revision of the PWE3 > Architecture but has been dropped in the -07 revision. The latter only > states the requirement to allow usage of the first nibble of the > control word for discrimination between PW and IP packets carried over > MPLS PSN without going into details (in the sub-clause 5.4.3) by making > its value different from any current IP version. > > Both drafts require the first nibble of the control word to be set to 0 > and hence satisfy this requirement. > The references will be updated in the next revisions of the drafts. > We are working on a new draft that contains similar text to that which removed from 5.4.3 and 5.4.4. It should be posted shortly. - Stewart > Hopefully this answers your questions. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > -----Original Message----- > From: Torben Rasmussen [mailto:tra@tpack.net] > Sent: Wednesday, June 02, 2004 2:49 PM > To: pwe3@ietf.org > Subject: [PWE3] References in draft-ietf-pwe3-cesopsn-01.txt and > draft-ietf-pwe3-satop-01.txt > > draft-ietf-pwe3-cesopsn-01.txt and draft-ietf-pwe3-satop-01.txt. > > > > Both papers is referring to a sub clause 5.4.4 with the reference > [PWE3-ARCH] there is something wrong the see figure 3 in both > documents. > > > > In draft-ietf-pwe3-cesopsn-01.txt it makes reference to > draft-ietf-pwe3-arch-06.txt there is no sub clause 5.4.4 in the new > draft-ietf-pwe3-arch-07.txt version. > > > > For draft-ietf-pwe3-satop-01.txt it refers to > draft-ietf-pwe3-framework-06.txt here the document do not exist, in > the old version of satop-00.txt it makes reference to > draft-ietf-pwe3-arch-06.txt and ones again the new document do not > contain this sub clause. > > > > Anyone that is able to explain this and give a hint where to find > the information about the first four bits of the control word? > > > > Thanks > > Torben Rasmussen > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Andrew G. Malis" Subject: Fwd: I-D ACTION:draft-malis-pwe3-cell-transport-01.txt Date: Fri, 04 Jun 2004 18:07:33 -0400 Lines: 93 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-bounces@ietf.org Sat Jun 05 00:45:23 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 To: "PWE3 (IETF)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The authors request that this become a working group document. It fills a hole in the ATM encapsulation document that is already adequately covered in the other encapsulation specs. Thanks, Andy ------- Begin of Forwarded Message ------- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 04 Jun 2004 16:14:17 -0400 Subject: I-D ACTION:draft-malis-pwe3-cell-transport-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 04 Jun 2004 20:52:06.0384 (UTC) FILETIME=[CBC9B700:01C44A75] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PWE3 ATM Transparent Cell Transport Service Author(s) : A. Malis, et al. Filename : draft-malis-pwe3-cell-transport-01.txt Pages : 3 Date : 2004-6-4 The document describes a transparent cell transport service that makes use of the 'N-to-one' cell relay mode for PWE3 ATM cell encapsulation described in [ATM-ENCAPS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malis-pwe3-cell-transport-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-malis-pwe3-cell-transport-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-malis-pwe3-cell-transport-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-6-4145616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-malis-pwe3-cell-transport-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce ------- End of Forwarded Message ------- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cep-mib-05.txt Date: Mon, 07 Jun 2004 15:43:39 -0400 Lines: 99 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Mon Jun 07 22:47:50 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2 Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-cep-mib-05.txt Pages : 57 Date : 2004-6-7 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Native Service Processing of SONET/SDH circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cep-mib-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-cep-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-cep-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Orly Nicklass" Subject: RE: I-D ACTION:draft-ietf-pwe3-cep-mib-05.txt Date: Tue, 8 Jun 2004 09:15:16 +0300 Lines: 76 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Tue Jun 08 08:25:45 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-cep-mib-05.txt Thread-Index: AcRM0cfEuCHixvjaTzS+BG1iOfROOgAS1PQg To: Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 Following a brief review of the new MIB version and scanning through the other PWE3 MIB modules it seems like all are having the same reference problem with respect to IANA allocation root. pwStdMIB is a value that should be assigned by IANA, and requested as such in the TC-MIB, but at the same time any of the subtrees should be assigned by IANA as well. For any of the MIB modules below, the proper syntax should be: ::=3D { pwStdMIB x } -- To be assigned by IANA=20 -- the value y is requested for this specific Module. Where y will be replaced in each of the modules below by the required number. For example: For ..pwe3-pw-mib...it will be=20 ::=3D { pwStdMIB x } -- To be assigned by IANA=20 -- The value 2 is requested for this specific Module. Below is the list of modules to arrange, enet and tdm are already conflicting in values. draft-ietf-pwe3-pw-tc-mib-04.txt ::=3D { pwStdMIB 1 } draft-ietf-pwe3-pw-mib-04.txt ::=3D { pwStdMIB 2 } -- To be assigned by IANA=20 =20 draft-ietf-pwe3-pw-mpls-mib-05.txt ::=3D { pwStdMIB 3 } -- To be assigned by IANA=20 draft-ietf-pwe3-cep-mib-05.txt ::=3D { pwStdMIB 4 } --To be assigned by IANA=20 draft-ietf-pwe3-enet-mib-04.txt ::=3D { pwStdMIB 5 } -- To be assigned by IANA=20 draft-ietf-pwe3-tdm-mib-00.txt ::=3D { pwStdMIB 5 } --To be assigned by IANA draft-ietf-pwe3-satop-mib-00.txt ::=3D { pwStdMIB 6 } --To be assigned by IANA Orly -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 07, 2004 22:44 To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cep-mib-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation Service Over Packet (CEP)=20 Management Information Base Using SMIv2 Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-cep-mib-05.txt Pages : 57 Date : 2004-6-7 =09 ...... From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Interface parameters Date: Tue, 08 Jun 2004 01:11:28 -0600 Lines: 80 Sender: pwe3-bounces@ietf.org References: <014701c44a51$51d58290$0101010a@eng.timetra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Jun 08 10:55:33 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029 X-Accept-Language: Italian [it], French/Canada [fr-CA], French/France [fr-FR], English/United States [en-US] To: vach.kompella@alcatel.com In-Reply-To: <014701c44a51$51d58290$0101010a@eng.timetra.com> X-PMX-Version: 4.6.0.99824 X-from-outside-Cisco: [144.254.124.215] Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Vach, The text you are asking for is one paragraph below at : "The Length field is defined as the length of the interface parameter including the parameter id and length field itself. Processing of the interface parameters should continue when encountering unknown interface parameters and they MUST be silently ignored." The point here is that there is an assumption that all REQUIRED parameters for existing PW types have been defined. Any new interface parameters will fall into two categories : 1) A new PW type is defined , and it requires new "REQUIRED" interface parameters. 2) A new option on an existing PW is created , and this will be by definition optional to maintain backward compatibility. In either case the control document is fine, and both cases will require new separate drafts. As far as the text below, maybe I can make it a little clearer and change the "When applicable" to "When REQUIRED by the definitions below" Or something of the sort. Luca Vach Kompella wrote: >We need some text around the interface parameters that defines the >behavior when an unknown interface parameter is seen. E.g., some >vendors have implemented FCS retention, and there is apparently no way >to turn it off. Any code that pre-dates FCS retention may or may not >work with this up-level code because: > - there are mandatory interface parameters > - there are optional interface parameters > - there is no way to tell if, for a PW, an interface parameter is >optional or mandatory > - any new interface parameter may also be mandatory or optional > >So it is fine for the FCS retention draft to say that it is backwards >compatible with any pre-FCS retention implementation. However, that is >true only if the behavior of the older implementations is to ignore any >unknown interface parameters. This is what draft-ietf-pwe3-control >says: > > 5.4. Interface Parameters Field > > > This field specifies interface specific parameters. When >applicable, > ^^^^^^^^^^^^^^^ > it MUST be used to validate that the PEs, and the ingress and >egress > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ports at the edges of the circuit, have the necessary capabilities >to > interoperate with each other. The field structure is defined as > follows: > >This is not an implementable statement: pre-existing implementations >cannot tell if a new interface parameter MUST be used to validate the >PW. Have I missed some other place which describes it better? The >behavior, say, when unknown LDP messages or TLVs are received is better >defined. Those U/F bits don't exist for interface parameters. > >Vach Kompella >IP Division, Alcatel >vach.kompella@alcatel.com >+1 650 237-5152 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Danny McPherson Subject: IETF 60 PWE3 Slot Requests Date: Mon, 7 Jun 2004 20:41:02 -0600 Lines: 7 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Tue Jun 08 18:55:14 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org If you'd like some time on the agenda in San Diego please let me know (sooner, rather than later). Thanks! -danny From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: RE: I-D ACTION:draft-ietf-pwe3-sonet-07.txt Date: Tue, 8 Jun 2004 10:43:51 -0700 Lines: 124 Sender: pwe3-bounces@ietf.org References: <000001c449b6$11719b30$79db4dd1@lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Tue Jun 08 20:09:45 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <000001c449b6$11719b30$79db4dd1@lycium.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org PWE3ers, Problem solved. The current draft in the IETF repository includes all last call remarks and there are no alignment problems. It turns out there was a technical problem that was solved thanks to the IETF team. I'd like to thank this team for their prompt help. Regards Ron > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Ron Cohen > Sent: Thursday, June 03, 2004 3:00 PM > To: pwe3@ietf.org > Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-sonet-07.txt > > > Oy vay, > > The only changes I made were: > > 1. Section 9.1 last paragraph CEP-NE failures should be limited to > Type-2 defects. It should read: > > "CEP-NE failure is declared after 2.5 +/- 0.5 seconds of CEP-NE Type-2 > defect, and cleared after 10 seconds free of CEP-NE defect state. > Sending notification to the OS for CEP-NE failure is local policy." > > 2. Remove references from abstract section to comply with ID nits > > For some unknown reason the draft on the web has text and > page alignment > problems. I don't have these problems on the draft I have > (the one that > was sent to the ietf submission email). I'm trying to find > out what went > wrong and fix it. > > Apologies > Ron > > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Thursday, June 03, 2004 12:58 PM > > To: i-d-announce@ietf.org > > Cc: pwe3@ietf.org > > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-sonet-07.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Pseudo Wire Emulation Edge > > to Edge Working Group of the IETF. > > > > Title : SONET/SDH Circuit Emulation over Packet (CEP) > > Author(s) : A. Malis, et al. > > Filename : draft-ietf-pwe3-sonet-07.txt > > Pages : 48 > > Date : 2004-6-3 > > > > This draft provides encapsulation formats and semantics for > > emulating SONET/SDH circuits and services over a packet-switched > > network (PSN). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-07.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to > > change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-pwe3-sonet-07.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-pwe3-sonet-07.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Andrew G. Malis" Subject: Re: WG last call requested for draft-ietf-pwe3-fcs-retention-01.txt Date: Wed, 09 Jun 2004 08:22:53 -0400 Lines: 72 Sender: pwe3-bounces@ietf.org References: <6.1.0.6.2.20040520172011.072d2c90@po1.vivacenetworks.com> <40C6F74C.5060906@cisco.com> <40C6F99C.6080201@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis" , "W. Mark Townsley" , "PWE3 $IETF$" , l2tpext@ietf.org X-From: pwe3-bounces@ietf.org Wed Jun 09 17:44:29 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 To: "W. Mark Townsley" In-Reply-To: <40C6F99C.6080201@cisco.com> References: <6.1.0.6.2.20040520172011.072d2c90@po1.vivacenetworks.com> <40C6F74C.5060906@cisco.com> <40C6F99C.6080201@cisco.com> X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Mark, Thanks! We'll consider this a last call comment :-) and edit it in following the close of last call (which I believe was this past Monday, actually). Cheers, Andy --------- At 6/9/2004 01:50 PM +0200, W. Mark Townsley wrote: >OK, let me try again, I made the same mistake as you did regarding the FCS >length. Andy, I stole the text describing the FCS Length parameter from >you directly. > >4. Signaling FCS Retention With L2TPv3-based Pseudowires > >When using the signaling procedures in [7], the FCS Retention AVP, >Attribute Type L2TP-TBA-1, is used. > > The Attribute Value field for this AVP has the following format: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FCS Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The FCS Length is a 2-octet unsigned integer. > >The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE >(PE) requests its peer to retain FCS for the L2TP session being >established. If the receiving LCCE recognizes the AVP and complies with >the FCS retention request, it MUST include an FCS Retention AVP as an >acknowledgement in a corresponding ICRP or ICCN message. FCS Retention is >always bidirectional, thus FCS is only retained if both LCCEs send an FCS >Rentention AVP during session establishment. > >The Attribute Value is a 16-bit FCS length field, which indicates the >length of the original FCS being retained. For Ethernet and ATM AAL5 >pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame >Relay pseudowires, this length will be set to either 2 or 4. Since the FCS >length on these interfaces is a local setting, retaining the FCS only >makes sense if the FCS length is identical on both ends of the >pseudowire. Including the FCS length in this AVP allows the PEs to ensure >that the FCS is only retained when it makes sense. > >The Length of this AVP is 8. The M bit for this AVP MUST be set to 0 >(zero). This AVP MAY be hidden (the H bit MAY be 1 or 0). > >For the IANA Considerations Section: > >This specification requires one value within the L2TP "Control Message >Attribute Value Pairs" section to be assigned by IANA as per [8]. The new >AVP is encoded as L2TP-TBA-1 in this document, and should be referred to >in the IANA L2TP parameters registry as "FCS Retention." > >For the References Section: > > [7] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling > Protocol (Version 3)", work in progress, > draft-ietf-l2tpext-l2tp-base-14.txt, June 2004. > > [8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet > Assigned Numbers Authority (IANA) Considerations Update", > RFC 3438, December 2002. > >Thanks, > >- Mark From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "W. Mark Townsley" Subject: Re: WG last call requested for draft-ietf-pwe3-fcs-retention-01.txt Date: Wed, 09 Jun 2004 13:50:52 +0200 Lines: 58 Sender: pwe3-bounces@ietf.org References: <6.1.0.6.2.20040520172011.072d2c90@po1.vivacenetworks.com> <40C6F74C.5060906@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "W. Mark Townsley" , "PWE3 $IETF$" , l2tpext@ietf.org X-From: pwe3-bounces@ietf.org Wed Jun 09 17:50:07 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: "Andrew G. Malis" In-Reply-To: <40C6F74C.5060906@cisco.com> Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org OK, let me try again, I made the same mistake as you did regarding the FCS length. Andy, I stole the text describing the FCS Length parameter from you directly. 4. Signaling FCS Retention With L2TPv3-based Pseudowires When using the signaling procedures in [7], the FCS Retention AVP, Attribute Type L2TP-TBA-1, is used. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The FCS Length is a 2-octet unsigned integer. The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE (PE) requests its peer to retain FCS for the L2TP session being established. If the receiving LCCE recognizes the AVP and complies with the FCS retention request, it MUST include an FCS Retention AVP as an acknowledgement in a corresponding ICRP or ICCN message. FCS Retention is always bidirectional, thus FCS is only retained if both LCCEs send an FCS Rentention AVP during session establishment. The Attribute Value is a 16-bit FCS length field, which indicates the length of the original FCS being retained. For Ethernet and ATM AAL5 pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame Relay pseudowires, this length will be set to either 2 or 4. Since the FCS length on these interfaces is a local setting, retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this AVP allows the PEs to ensure that the FCS is only retained when it makes sense. The Length of this AVP is 8. The M bit for this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0). For the IANA Considerations Section: This specification requires one value within the L2TP "Control Message Attribute Value Pairs" section to be assigned by IANA as per [8]. The new AVP is encoded as L2TP-TBA-1 in this document, and should be referred to in the IANA L2TP parameters registry as "FCS Retention." For the References Section: [7] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol (Version 3)", work in progress, draft-ietf-l2tpext-l2tp-base-14.txt, June 2004. [8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", RFC 3438, December 2002. Thanks, - Mark From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "W. Mark Townsley" Subject: Re: WG last call requested for draft-ietf-pwe3-fcs-retention-01.txt Date: Wed, 09 Jun 2004 13:41:00 +0200 Lines: 127 Sender: pwe3-bounces@ietf.org References: <6.1.0.6.2.20040520172011.072d2c90@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "PWE3 $IETF$" , l2tpext@ietf.org X-From: pwe3-bounces@ietf.org Wed Jun 09 17:50:45 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: "Andrew G. Malis" In-Reply-To: <6.1.0.6.2.20040520172011.072d2c90@po1.vivacenetworks.com> Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Andrew G. Malis wrote: > The authors feel that this draft is ready to enter WG last call. Looks like section 4 needs some attention first. It's pretty simple, here is some text: 4. Signaling FCS Retention With L2TPv3-based Pseudowires When using the signaling procedures in [7], the FCS Retention AVP, Attribute Type L2TP-TBA-1, is used. The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE (PE) requests its peer to retain FCS for the L2TP session being established. If the receiving LCCE recognizes the AVP and complies with the FCS retention request, it MUST include an FCS Retention Indicator AVP as an acknowledgement in an ICRP or ICCN message. FCS Retention is always bidirectional, thus FCS is only retained if both LCCEs send an FCS Rentention AVP during session establishment. The Length of this AVP is 6 (there is no Attribute Value field). The M bit for this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0). For the IANA Considerations Section: This specification requires one value within the L2TP "Control Message Attribute Value Pairs" section to be assigned by IANA as per [8]. The new AVP is encoded as L2TP-TBA-1 in this document, and should be referred to in the IANA L2TP parameters registry as "FCS Retention." For the References Section: [7] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol (Version 3)", work in progress, draft-ietf-l2tpext-l2tp-base-14.txt, June 2004. [8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", RFC 3438, December 2002. Thanks, - Mark > > Thanks, > Andy > > ------- Begin of Forwarded Message ------- > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > From: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-pwe3-fcs-retention-01.txt > Date: Thu, 20 May 2004 16:02:00 -0400 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Pseudo Wire Emulation Edge to Edge > Working Group of the IETF. > > Title : PWE3 Frame Check Sequence Retention > Author(s) : A. Malis, et al. > Filename : draft-ietf-pwe3-fcs-retention-01.txt > Pages : 6 > Date : 2004-5-20 > > This document defines a mechanism for preserving frame FCS through > Ethernet, Frame Relay, and HDLC pseudowires. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pwe3-fcs-retention-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-5-20152730.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt > > > > ------- End of Forwarded Message ------- > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "W. Mark Townsley" Subject: Re: VCCV ? Date: Wed, 09 Jun 2004 12:56:06 +0200 Lines: 48 Sender: pwe3-bounces@ietf.org References: <200405141940.i4EJeYYu025331@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "PWE3 $IETF$" , tnadeau@cisco.com, "Monique \"Morrow \"$mmorrow$" , Yaakov Stein , Luca Martini X-From: pwe3-bounces@ietf.org Wed Jun 09 18:51:04 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: George Swallow In-Reply-To: <200405141940.i4EJeYYu025331@rtp-core-1.cisco.com> Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org George Swallow wrote: >>I already asked this question a while back ... I think that Tom has a >>good point. But I also believe that we will not be allowed to >>keep this name. There main reason is that we talk about PWs , not VCs >>, so at some time in the future is somebody looks up this draft there >>will be more confusion. > > > If we have to change the name for the VC part then we should change the > CV as well. What is being defined is a channel (and means of > signalling) for general operations and management tools. It's not > limited to Connectivity Verification. Obvious, but not very catchy: POAM or PWOAM: Pseudowire OAM Borrowing from BFD: PFD or PWFD: Pseudowire Fault Detection But I like PWWP too ;-) - Mark > > ...George > > ps. It really a channel to ensure the psuedowires are working > properly. Would you believe PWWP? ;-) > > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-control-protocol-07.txt Date: Wed, 09 Jun 2004 15:34:44 -0400 Lines: 102 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Jun 09 22:46:57 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire Setup and Maintenance using LDP Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-control-protocol-07.txt Pages : 35 Date : 2004-6-9 Layer 2 services (such as Frame Relay, ATM, ethernet) can be 'emulated' over an IP and/or MPLS backbone by encapsulating the layer 2 PDUs and then transmitting them over 'pseudowires'. It is also possible to use pseudowires to provide SONET circuit emulation over an IP and/or MPLS network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to LDP. Procedures for encapsulating layer 2 PDUs are specified in a set of companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-control-protocol-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-control-protocol-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: Re: VCCV ? Date: Thu, 10 Jun 2004 11:33:17 +0100 Organization: Cisco Systems, Inc. Lines: 65 Sender: pwe3-bounces@ietf.org References: <200405141940.i4EJeYYu025331@rtp-core-1.cisco.com> <40C6ECC6.9030301@cisco.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: George Swallow , tnadeau@cisco.com, "Monique \"Morrow \"$mmorrow$" , Yaakov Stein , "PWE3 $IETF$" , Luca Martini X-From: pwe3-bounces@ietf.org Thu Jun 10 12:48:12 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "W. Mark Townsley" In-Reply-To: <40C6ECC6.9030301@cisco.com> Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Do we seriously want to change this? For better or worse it is widely known in the industry as VCCV. - Stewart W. Mark Townsley wrote: > > > George Swallow wrote: > >>> I already asked this question a while back ... I think that Tom has a >>> good point. But I also believe that we will not be allowed to >>> keep this name. There main reason is that we talk about PWs , not VCs >>> , so at some time in the future is somebody looks up this draft there >>> will be more confusion. >> >> >> >> If we have to change the name for the VC part then we should change the >> CV as well. What is being defined is a channel (and means of >> signalling) for general operations and management tools. It's not >> limited to Connectivity Verification. > > > Obvious, but not very catchy: > > POAM or PWOAM: Pseudowire OAM > > Borrowing from BFD: > > PFD or PWFD: Pseudowire Fault Detection > > But I like PWWP too ;-) > > - Mark > > >> >> ...George >> >> ps. It really a channel to ensure the psuedowires are working >> properly. Would you believe PWWP? ;-) > > > > >> >> ======================================================================== >> George Swallow Cisco Systems (978) 936-1398 >> 1414 Massachusetts Avenue >> Boxborough, MA 01719 >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Thomas D. Nadeau" Subject: Re: VCCV ? Date: Thu, 10 Jun 2004 08:16:53 -0400 Lines: 62 Sender: pwe3-bounces@ietf.org References: <200405141940.i4EJeYYu025331@rtp-core-1.cisco.com> <40C6ECC6.9030301@cisco.com> <40C838ED.3060306@cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: George Swallow , "Monique \"Morrow \"$mmorrow$" , Yaakov Stein , "PWE3 $IETF$" , "W. Mark Townsley" , Luca Martini X-From: pwe3-bounces@ietf.org Thu Jun 10 14:34:46 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: <40C838ED.3060306@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I personally do not want to change the name for that very reason. --Tom On Jun 10, 2004, at 6:33 AM, Stewart Bryant wrote: > Do we seriously want to change this? For better or worse it is > widely known in the industry as VCCV. > > - Stewart > > W. Mark Townsley wrote: >> George Swallow wrote: >>>> I already asked this question a while back ... I think that Tom has >>>> a >>>> good point. But I also believe that we will not be allowed to >>>> keep this name. There main reason is that we talk about PWs , not >>>> VCs >>>> , so at some time in the future is somebody looks up this draft >>>> there >>>> will be more confusion. >>> >>> >>> >>> If we have to change the name for the VC part then we should change >>> the >>> CV as well. What is being defined is a channel (and means of >>> signalling) for general operations and management tools. It's not >>> limited to Connectivity Verification. >> Obvious, but not very catchy: >> POAM or PWOAM: Pseudowire OAM >> Borrowing from BFD: >> PFD or PWFD: Pseudowire Fault Detection >> But I like PWWP too ;-) >> - Mark >>> >>> ...George >>> >>> ps. It really a channel to ensure the psuedowires are working >>> properly. Would you believe PWWP? ;-) >>> >>> ===================================================================== >>> === >>> George Swallow Cisco Systems (978) >>> 936-1398 >>> 1414 Massachusetts Avenue >>> Boxborough, MA 01719 >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Monique Morrow $mmorrow$" Subject: RE: VCCV ? Date: Thu, 10 Jun 2004 14:23:19 +0200 Lines: 78 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "George Swallow $swallow$" , "Mark Townsley $townsley$" , "PWE3 $IETF$" , Yaakov Stein , "Luca Martini $lmartini$" X-From: pwe3-bounces@ietf.org Thu Jun 10 14:41:17 2004 Return-path: X-BrightmailFiltered: true X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] VCCV ? Thread-Index: AcRO5QwG58Lb8snHQxSlhxNssqEEIQAADLGA To: "Tom Nadeau $tnadeau$" , "Stewart Bryant $stbryant$" X-OriginalArrivalTime: 10 Jun 2004 12:23:20.0592 (UTC) FILETIME=[B77A0100:01C44EE5] Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Ditto here --- -----Original Message----- From: Tom Nadeau (tnadeau)=20 Sent: 10 June 2004 14:17 To: Stewart Bryant (stbryant) Cc: Monique Morrow (mmorrow); George Swallow (swallow); Yaakov Stein; Mark Townsley (townsley); Luca Martini (lmartini); PWE3 (IETF) Subject: Re: [PWE3] VCCV ? I personally do not want to change the name for that very reason. --Tom On Jun 10, 2004, at 6:33 AM, Stewart Bryant wrote: > Do we seriously want to change this? For better or worse it is > widely known in the industry as VCCV. > > - Stewart > > W. Mark Townsley wrote: >> George Swallow wrote: >>>> I already asked this question a while back ... I think that Tom has >>>> a >>>> good point. But I also believe that we will not be allowed to >>>> keep this name. There main reason is that we talk about PWs , not =20 >>>> VCs >>>> , so at some time in the future is somebody looks up this draft =20 >>>> there >>>> will be more confusion. >>> >>> >>> >>> If we have to change the name for the VC part then we should change >>> the >>> CV as well. What is being defined is a channel (and means of >>> signalling) for general operations and management tools. It's not >>> limited to Connectivity Verification. >> Obvious, but not very catchy: >> POAM or PWOAM: Pseudowire OAM >> Borrowing from BFD: >> PFD or PWFD: Pseudowire Fault Detection >> But I like PWWP too ;-) >> - Mark >>> >>> ...George >>> >>> ps. It really a channel to ensure the psuedowires are working >>> properly. Would you believe PWWP? ;-) >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >>> =3D=3D=3D >>> George Swallow Cisco Systems (978) =20 >>> 936-1398 >>> 1414 Massachusetts Avenue >>> Boxborough, MA 01719 >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: David Meyer Subject: Re: VCCV ? Date: Thu, 10 Jun 2004 07:21:42 -0700 Lines: 74 Sender: pwe3-bounces@ietf.org References: <200405141940.i4EJeYYu025331@rtp-core-1.cisco.com> <40C6ECC6.9030301@cisco.com> <40C838ED.3060306@cisco.com> <0F4B1C46-BAD8-11D8-BBEC-000D93AD480A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: George Swallow , "Monique Morrow $mmorrow$" , Yaakov Stein , "PWE3 $IETF$" , "W. Mark Townsley" , Luca Martini , stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Jun 10 18:17:14 2004 Return-path: X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f To: "Thomas D. Nadeau" Content-Disposition: inline In-Reply-To: <0F4B1C46-BAD8-11D8-BBEC-000D93AD480A@cisco.com> User-Agent: Mutt/1.4.1i X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Thu, Jun 10, 2004 at 08:16:53AM -0400, Thomas D. Nadeau wrote: >> >> I personally do not want to change the name for that >> very reason. Agree. Dave >> >> --Tom >> >> >> On Jun 10, 2004, at 6:33 AM, Stewart Bryant wrote: >> >> >Do we seriously want to change this? For better or worse it is >> >widely known in the industry as VCCV. >> > >> >- Stewart >> > >> >W. Mark Townsley wrote: >> >>George Swallow wrote: >> >>>>I already asked this question a while back ... I think that Tom has >> >>>>a >> >>>>good point. But I also believe that we will not be allowed to >> >>>>keep this name. There main reason is that we talk about PWs , not >> >>>>VCs >> >>>>, so at some time in the future is somebody looks up this draft >> >>>>there >> >>>>will be more confusion. >> >>> >> >>> >> >>> >> >>>If we have to change the name for the VC part then we should change >> >>>the >> >>>CV as well. What is being defined is a channel (and means of >> >>>signalling) for general operations and management tools. It's not >> >>>limited to Connectivity Verification. >> >>Obvious, but not very catchy: >> >> POAM or PWOAM: Pseudowire OAM >> >>Borrowing from BFD: >> >> PFD or PWFD: Pseudowire Fault Detection >> >>But I like PWWP too ;-) >> >>- Mark >> >>> >> >>>...George >> >>> >> >>>ps. It really a channel to ensure the psuedowires are working >> >>>properly. Would you believe PWWP? ;-) >> >>> >> >>>===================================================================== >> >>>=== >> >>>George Swallow Cisco Systems (978) >> >>>936-1398 >> >>> 1414 Massachusetts Avenue >> >>> Boxborough, MA 01719 >> >>> >> >>> >> >>>_______________________________________________ >> >>>pwe3 mailing list >> >>>pwe3@ietf.org >> >>>https://www1.ietf.org/mailman/listinfo/pwe3 >> >>> >> >>_______________________________________________ >> >>pwe3 mailing list >> >>pwe3@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: VCCV ? Date: Thu, 10 Jun 2004 17:33:32 +0300 Lines: 17 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: George Swallow , tnadeau@cisco.com, "Monique \"Morrow \"$mmorrow$" , "PWE3 $IETF$" , Luca Martini X-From: pwe3-bounces@ietf.org Fri Jun 11 13:55:49 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] VCCV ? Thread-Index: AcRO1gFIefDKcDH/QVGpa9JmZk42jQAIU/Pg To: , "W. Mark Townsley" Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 > Subject: Re: [PWE3] VCCV ? >=20 > Do we seriously want to change this? For better or worse it=20 > is widely known in the industry as VCCV. >=20 > - Stewart Although I don't want to contradict all the previous emailers (most of which seem to be from a single company :> ) I still think we need to remove all references to VCs. I can go along with leaving the CV, but I thought that long ago we standardized on the term PW.=20 Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: VCCV ? Date: Thu, 10 Jun 2004 12:06:37 -0600 Lines: 70 Sender: pwe3-bounces@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5202A1EECE@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0917098430==" Cc: George Swallow , tnadeau@cisco.com, "Monique \"Morrow \"$mmorrow$" , "PWE3 $IETF$" , "W. Mark Townsley" , stbryant@cisco.com X-From: pwe3-bounces@ietf.org Fri Jun 11 14:29:00 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029 X-Accept-Language: Italian [it], French/Canada [fr-CA], French/France [fr-FR], English/United States [en-US] To: Yaakov Stein In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5202A1EECE@exrad2.ad.rad.co.il> X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --===============0917098430== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hey , I do want to change the name ....
Actually I do not care much what it is called , but I do *care* for this to progress is a timely manner.
I believe that right now we have a serious terminology issue with the frame-relay encapsulation draft , and the VCCV name.
I cannot see how the IESG can just miss the Virtual Circuit part ... ( especially, Allison who was quite keen on the PW name )

Luca
P.S. maybe we should ask her ?

Yaakov Stein wrote:

Subject: Re: [PWE3] VCCV ?

Do we seriously want to change this? For better or worse it 
is widely known in the industry as VCCV.

- Stewart


Although I don't want to contradict all the previous emailers
(most of which seem to be from a single company :> )
I still think we need to remove all references to VCs.

I can go along with leaving the CV,
but I thought that long ago we standardized on the term PW. 

Y(J)S

--===============0917098430== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0917098430==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Richard Sugarman Subject: Section 5.6.2 of pwe3-control-protocol-07 not required? Date: Fri, 11 Jun 2004 16:24:44 +0100 Lines: 59 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-bounces@ietf.org Fri Jun 11 18:01:16 2004 Return-path: To: "'pwe3@ietf.org'" Deferred-Delivery: Fri, 11 Jun 2004 16:25:00 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I have some concerns about section 5.6.2 of draft-ietf-pwe3-control-protocol-07. I suspect that this section of the draft has not been widely implemented, but am open to being proved wrong. It describes the situation where a router wishes restart forwarding of packets with sequence number 1. It suggests - sending an LDP Label Release for the PW in question - sending a corresponding LDP Label Request. This seems non-ideal for a couple of reasons. 1) For plain LDP signalling in DU/Liberal mode, most (all?) existing implementations do not send Label Requests at all. This has lead to an undesirable situation where - some implementations do not respond to Label Requests - some implementations just do not cope with receipt of a Label Request (in a service impacting way). Whilst broken implementations should of course be fixed, this situation does suggest that sending Label Requests can lead to severe interop problems that will not go away in a hurry. I suspect that these problems will exist for PW LSPs as much as for normal LDP LSPs. 2) In the absence of Label Request support, sending a Label Release in Liberal mode should be avoided as far as possible. The downstream node that receives the Label Release will never retry sending the Label Mapping without operator intervention. Without a Label Request, the LSP will stay broken. [The other places in pwe3-control-protocol that specify sending Label Release messages, sections 5.2.3 and 5.4.1, do so for specific reasons reflected in the Label Release status code - these are unexpected misconfigurations that I believe will _always_ require operator intervention to resolve]. 3) At the Seoul IETF meeting, Luca Martini described an alternative way to re-set the sequence number that does not involve LDP signalling at all, but instead utilizes standard sequence number algorithms (see http://www.ietf.org/proceedings/04mar/index.html, section 2.8.10, under "Luca - PWE3 sequencing"). This seems like a better way to go forward. So unless anyone knows of an implementation of section 5.6.2 of pwe3-control-protocol-07, I would suggest either removing the section entirely, or instead changing it to comment that re-setting the sequence number is outside of the scope of the signalling protocol. Thoughts welcome! Rich Richard Sugarman Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: mailto:richard.sugarman@dataconnection.com Web: http://www.dataconnection.com From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: CEP: RTP not mandatory Date: Sat, 12 Jun 2004 05:09:23 -0700 Lines: 43 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Stewart Bryant , Danny McPherson X-From: pwe3-bounces@ietf.org Sat Jun 12 14:24:13 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org X-Spam-Report: 9.6 points; * -8.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 2.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.6 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy * [67.126.115.197 listed in dnsbl.njabl.org] * 15 GERMAN_SPAM_O_RAMA_01 German Political Spam Hi, There is one more change I propose before sending the SONET/SDH CEP emulation draft to IESG. I would like to change RTP encapsulation to optional. CEP control word is mandatory and carries both a sequence number and pointer adjustment indications (N,P bits). All information required for delivery of timing (synchronization) information is therefore contained with the control word and RTP is not required as mandatory encapsulation. If there is no common clock between Pes the RTP time stamp advance together with the sequence number and adds no information. If common clock is available to both Pes the native service method for conveying the difference between service clock and the common clock should be used (N,P). If there are no objections within a week I will prepare another version of the draft with RTP as optional encapsulation. Thanks Ron Ron Cohen CTO Lycium Networks Mobile: 650.823.7672 Mobile: +972.55.245.104 Tel: 650.234.4010 Fax: 650.854.8183 ===================================================== This email message and any files transmitted with it contain confidential information intended only for its addressee(s). If you are not the addressee of this message, any reading, disclosure, copying, printing, distribution or forwarding by you of this message or its content or attachments is strictly forbidden. In such case, please notify us immediately by replying to this message or by calling 650.234.4010 and delete the message from your computer. Thank you. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: CEP: RTP not mandatory Date: Sun, 13 Jun 2004 08:15:24 +0300 Lines: 24 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Danny McPherson , Stewart Bryant X-From: pwe3-bounces@ietf.org Sun Jun 13 07:28:48 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] CEP: RTP not mandatory Thread-Index: AcRQeAuh3enGr+AwRtuRrbXAzWmIBAAjBmiw To: "Ron Cohen" , Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =20 > I would like to change RTP encapsulation to optional.=20 I fully support this. We have done the same in SAToP, TDMoIP and Y.1413. The only portion of the RTP overhead that can potentially add anything is the timestamp, and it only helps in the common clock case.=20 Even in the common clock case one needs to choose the common clock rate=20 wisely; and even then there are much better methods of clocking (as you note). In addition, there are complications in placement of the RTP header, with IP and MPLS cases being treated differently. So I believe that we should leave the RTP header only in those places where it has already been implemented (e.g. CESoPSN) and remove it entirely everywhere else. As a compromise we can leave it as an option that no-one will ever implement. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Section 5.6.2 of pwe3-control-protocol-07 not required? Date: Tue, 15 Jun 2004 11:57:34 -0600 Lines: 110 Sender: pwe3-bounces@ietf.org References: <37701240971DD31193970000F6CCB9F7059287F3@duke.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" X-From: pwe3-bounces@ietf.org Tue Jun 15 19:44:33 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029 X-Accept-Language: Italian [it], French/Canada [fr-CA], French/France [fr-FR], English/United States [en-US] To: Richard Sugarman In-Reply-To: <37701240971DD31193970000F6CCB9F7059287F3@duke.datcon.co.uk> Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard Sugarman wrote: >I have some concerns about section 5.6.2 of >draft-ietf-pwe3-control-protocol-07. I suspect that this section of the >draft has not been widely implemented, but am open to being proved wrong. > >It describes the situation where a router wishes restart forwarding of >packets with sequence number 1. It suggests > > - sending an LDP Label Release for the PW in question > - sending a corresponding LDP Label Request. > >This seems non-ideal for a couple of reasons. > >1) For plain LDP signalling in DU/Liberal mode, most (all?) existing >implementations do not send Label Requests at all. This has lead to an >undesirable situation where > > - some implementations do not respond to Label Requests > > that violates rfc3036 , those implementations need to be fixed. > - some implementations just do not cope with receipt of a Label Request (in >a service impacting way). > > > again that is not behavior that agrees with rfc3036. >Whilst broken implementations should of course be fixed, this situation does >suggest that sending Label Requests can lead to severe interop problems that >will not go away in a hurry. I suspect that these problems will exist for >PW LSPs as much as for normal LDP LSPs. > >2) In the absence of Label Request support, sending a Label Release in >Liberal mode should be avoided as far as possible. The downstream node that >receives the Label Release will never retry sending the Label Mapping >without operator intervention. Without a Label Request, the LSP will stay >broken. > > > correct. >[The other places in pwe3-control-protocol that specify sending Label >Release messages, sections 5.2.3 and 5.4.1, do so for specific reasons >reflected in the Label Release status code - these are unexpected >misconfigurations that I believe will _always_ require operator intervention >to resolve]. > >3) At the Seoul IETF meeting, Luca Martini described an alternative way to >re-set the sequence number that does not involve LDP signalling at all, but >instead utilizes standard sequence number algorithms (see >http://www.ietf.org/proceedings/04mar/index.html, section 2.8.10, under >"Luca - PWE3 sequencing"). This seems like a better way to go forward. > > > I agree , it works much better, but we cannot prevent the label release/request method as it is part of the rfc3036 already. >So unless anyone knows of an implementation of section 5.6.2 of >pwe3-control-protocol-07, I would suggest either removing the section >entirely, or instead changing it to comment that re-setting the sequence >number is outside of the scope of the signalling protocol. > > > Actually as far as I can remember most of the implementations of the draft-martini version did answer the label request messages. Since we are almost ready to LC this draft ( I am missing the security section which will be posted shortly ) I think that we cannot introduce the methodology that I presented at the last PWE3 meeting. But I still have an item on my list of to do things to write a draft about that CW synchronization methodology. I do not think that removing this section will make things easier, as the LDP specification still requires that label request response be implemented. So we can still have implementations attempting to use this methodology. What is the issue here ? Do you not want to implement answering label request messages ? Luca >Thoughts welcome! > >Rich > >Richard Sugarman >Network Protocols Group >Data Connection Ltd (DCL) >Tel: +44 20 8366 1177 >Fax: +44 20 8363 1039 >Email: mailto:richard.sugarman@dataconnection.com >Web: http://www.dataconnection.com > > > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From ietf-announce-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: The IESG Subject: Document Action: 'Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)' to Informational RFC Date: Wed, 16 Jun 2004 18:19:09 -0400 Lines: 18 Sender: ietf-announce-bounces@ietf.org Cc: pwe3 chair , pwe3 chair , Internet Architecture Board , pwe3 mailing list , RFC Editor X-From: ietf-announce-bounces@ietf.org Thu Jun 17 01:11:48 2004 Return-path: X-test-idtracker: no To: IETF-Announce X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org The IESG has approved the following document: - 'Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) ' as an Informational RFC This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: ITU-T Q5/13 Liason re PW over UDP Date: Mon, 21 Jun 2004 09:25:40 +0100 Organization: Cisco Systems, Inc. Lines: 48 Sender: pwe3-bounces@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Danny McPherson , "Peterson, Jon" X-From: pwe3-bounces@ietf.org Mon Jun 21 10:35:13 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@ietf.org" , Scott Bradner Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org It has not yet appeared on the IETF Liaison web page, but the following Liaison statement is in the process of being sent from ITU-T Q5/13 to IETF-PWE3 As you can see we been asked recommend the correct method of multiplexing a PW over UDP. - Stewart Q5/13 is extending ITU-T Recommendations specifying interworking LSPs (PWs) over MPLS networks, to networks based on UDP/IP. We understand that your charter also defines UDP/IP as a possible packet switched network infrastructure. Due to the lack of an interworking LSP label, a connection de-multiplexing mechanism must be devised for this case. Our analysis has uncovered five possibilities for using UDP port numbers as connection de-multiplexers, namely: 1. Use of destination port as application de-multiplexers, and source + destination socket as connection de-multiplexers. This method (used by HTTP) restricts a pair of end-points to a single simultaneous connection, and hence is not relevant for interworking LSPs (PWs). 2. Use of destination port number to identify a protocol setup message, and implicit allocation of port numbers by originator. This method (used by telnet) is limited to asymmetric applications, and so is not relevant for interworking LSPs (PWs). 3. Use of destination port number to identify a control protocol, and explicit allocation of port numbers (either downstream or upstream). This method (used by FTP) could be applicable to interworking LSPs (PWs), but would require the development of a new control protocol. Such a protocol could be based on a subset of targeted LDP. 4. Use of destination port number as application de-multiplexer, and source port number as connection de-multiplexer. This method (used by the draft-ietf-pwe3-tdmoip-01.txt) is possibly the simplest to implement, but non-standard. 5. Use of destination port number as connection de-multiplexer, and optionally source port number as application de-multiplexer. This method (the first part of which is used by RTP) seems to violate both conventional usage of destination port numbers as application de-multiplexers, and common sense by differentiation between different sources based on destination port. Since we have to complete our draft Recommendation shortly, we would appreciate that you inform us of your preferred method. From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Mon, 21 Jun 2004 13:19:37 +0200 Lines: 146 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Thomas Narten , pwe3@ietf.org, Danny McPherson , Scott Bradner , "Peterson, Jon" X-From: pwe3-bounces@ietf.org Mon Jun 21 12:31:35 2004 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart and all, Please see some personal comments on the assumed liaison text inline below (marked [Sasha]). With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, June 21, 2004 10:26 AM > To: pwe3@ietf.org; Scott Bradner > Cc: Thomas Narten; Danny McPherson; Peterson, Jon > Subject: [PWE3] ITU-T Q5/13 Liason re PW over UDP > > > It has not yet appeared on the IETF Liaison web page, but the > following > Liaison statement is in the process of being sent from ITU-T > Q5/13 to IETF-PWE3 > > As you can see we been asked recommend the correct method of > multiplexing > a PW over UDP. > > - Stewart > > > > Q5/13 is extending ITU-T Recommendations specifying > interworking LSPs (PWs) over > MPLS networks, to networks based on UDP/IP. > We understand that your charter also defines UDP/IP as a > possible packet switched network infrastructure. > Due to the lack of an interworking LSP label, a connection > de-multiplexing mechanism must be devised for this case. > [Sasha] As a general comment, I'd say that the method used for demultiplexing PWs over UDP/IP should not be architecturally different from the other demultiplexing methods used in PWE3, e.g. MPLS or L2TPv3. In particular: 1. The demultiplexers exist in the PWE3 data plane, and are distributed using manual configuration or some control protocol. 2. The demultiplexer value for each direction of the PW is allocated by the corresponding egress PW 3. If a control protocol is used, the demultiplexer value is distributed from the egress to the ingress PE for each direction of the PW. In addition, one should avoid using architectural elements that have not been specified in the PWE3 Architecture. > > Our analysis has uncovered five possibilities for using UDP > port numbers as > connection de-multiplexers, namely: > > 1. Use of destination port as application de-multiplexers, > and source + > destination socket as connection de-multiplexers. This method > (used by HTTP) > restricts a pair of end-points to a single simultaneous > connection, and hence is > not relevant for interworking LSPs (PWs). > [Sasha] IMO the PWE3 architecture does not define any "applications" and/or "application de-multiplexers". > > 2. Use of destination port number to identify a protocol > setup message, and > implicit allocation of port numbers by originator. This > method (used by telnet) > is limited to asymmetric applications, and so is not relevant > for interworking > LSPs (PWs). > [Sasha] AFAIK, Telnet uses a well-know port on the server side and a dynamically (for the duration of the connection) allocated port on the client side. Since PWs are not client-server applications, I agree that this method is inappropriate. > > 3. Use of destination port number to identify a control > protocol, and explicit > allocation of port numbers (either downstream or upstream). > This method (used by > FTP) could be applicable to interworking LSPs (PWs), but > would require the > development of a new control protocol. Such a protocol could > be based on a > subset of targeted LDP. > [Sasha] I'd say that a more relevant example is establishment over a L2TPv2/v3 over UDP Tunnel/Control Connection. This technique (described in RFC 2661) results in: - each peer allocating a locally free UDP port as the de-multiplexer value for the direction of the connection for which it is the receiver - using the allocated value as the Source UDP port in all the messages it sends save from the SCCRQ message (which is sent to the well-known port) - using the similar value allocated by the peer as the Destination UDP port in all the messages it sends save from the SCCRQ message which is sent to the well-known port because the peer allocation is not known yet. > > 4. Use of destination port number as application > de-multiplexer, and source port > number as connection de-multiplexer. This method (used by the > draft-ietf-pwe3-tdmoip-01.txt) is possibly the simplest to > implement, but non-standard. > [Sasha] In addition top referring to a non-existent "PWE3 application", this method does not specify which side ALLOCATES the demultiplexer. > > 5. Use of destination port number as connection > de-multiplexer, and optionally > source port number as application de-multiplexer. This method > (the first part of > which is used by RTP) seems to violate both conventional > usage of destination > port numbers as application de-multiplexers, and common sense > by differentiation > between different sources based on destination port. > [Sasha] Leaving aside the emotional side, I'd like to point out that in the PWE3 architecture de-multipexers are commonly used to identify the DESTINATION PW endpoints in the egress PEs in the data plane, so that this method fully complies with my common sense (for whatever it is worth). In addition it can be easily combined with a suitable control protocol (see my comment to method #3). Hence I would say that this is definitely the preferable method. > > Since we have to complete our draft Recommendation shortly, > we would appreciate > that you inform us of your preferred method. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Yaakov Stein" Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Mon, 21 Jun 2004 16:25:43 +0300 Lines: 137 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , Danny McPherson , pwe3@ietf.org, Scott Bradner , "Peterson, Jon" X-From: pwe3-bounces@ietf.org Mon Jun 21 17:21:38 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] ITU-T Q5/13 Liason re PW over UDP Thread-Index: AcRXevxDYu3TnS7lQr29SPensr/ydQADE2Hg To: "Sasha Vainshtein" , Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha and all,=20 > > Q5/13 is extending ITU-T Recommendations specifying interworking LSPs=20 > > (PWs) over MPLS networks, to networks based on UDP/IP. > > We understand that your charter also defines UDP/IP as a possible=20 > > packet switched network infrastructure. > > Due to the lack of an interworking LSP label, a connection=20 > > de-multiplexing mechanism must be devised for this case. > > > [Sasha] As a general comment, I'd say that the method used=20 > for demultiplexing PWs over UDP/IP should not be=20 > architecturally different from the other demultiplexing=20 > methods used in PWE3, e.g. MPLS or L2TPv3. In particular: > 1. The demultiplexers exist in the PWE3 data plane, and > are distributed using manual configuration or some control > protocol. > 2. The demultiplexer value for each direction of the PW is > allocated by the corresponding egress PW 3. If a control=20 > protocol is used, the demultiplexer value is=20 > distributed from the egress to the ingress PE for each=20 > direction of the PW. > In addition, one should avoid using architectural elements=20 > that have not been specified in the PWE3 Architecture. Mostly agree. However, please note that the usage in PWE has followed that of MPLS=20 in downstream allocation of PW labels. This does not necessarily carry over to the UDP case, but may. > > > > Our analysis has uncovered five possibilities for using UDP port=20 > > numbers as connection de-multiplexers, namely: > >=20 > > 1. Use of destination port as application de-multiplexers,=20 > > and source + > > destination socket as connection de-multiplexers. This=20 > method (used by=20 > > HTTP) restricts a pair of end-points to a single simultaneous=20 > > connection, and hence is not relevant for interworking LSPs (PWs). > > > [Sasha] IMO the PWE3 architecture does not define any "applications" > and/or "application de-multiplexers".=20 PWE3 doesn't define the application demux - this is a feature of UDP/IP and TCP/IP. A UDP/IP PWE IWF may have to handle FTP or HTTP or whatever in addition to the PWs. > > 2. Use of destination port number to identify a protocol setup message, and > > implicit allocation of port numbers by originator. This method (used > > by telnet) is limited to asymmetric applications, and so is not=20 > > relevant for interworking LSPs (PWs). > > > [Sasha] AFAIK, Telnet uses a well-know port on the server=20 > side and a dynamically (for the duration of the connection)=20 > allocated port on the client side. Since PWs are not=20 > client-server applications, I agree that this method is inappropriate. You are correct (the various cases are analyzed in the original ITU contribution). > > 3. Use of destination port number to identify a control protocol, and explicit > > allocation of port numbers (either downstream or upstream).=20 > > This method (used by FTP) could be applicable to interworking LSPs (PWs), but would require=20 > > the development of a new control protocol. Such a protocol could be=20 > > based on a subset of targeted LDP. > > > [Sasha] I'd say that a more relevant example is establishment=20 > over a L2TPv2/v3 over UDP Tunnel/Control Connection. This=20 > technique (described in RFC 2661) results in: > - each peer allocating a locally free UDP port as the de-multiplexer > value for the direction of the connection for which it is the receiver > - using the allocated value as the Source UDP port in all the messages > it sends save from the SCCRQ message (which is sent to the well-known port) > - using the similar value allocated by the peer as the Destination UDP port > in all the messages it sends save from the SCCRQ message which is sent > to the well-known port because the peer allocation is not known yet. OK - this is a valid analogy too. The use of FTP is perhaps somewhat better known, and interesting in that you can have upstream allocation (port command) or downstream allocation (pasv command). > > 4. Use of destination port number as application=20 > > de-multiplexer, and source port > > number as connection de-multiplexer. This method (used by the > > draft-ietf-pwe3-tdmoip-01.txt) is possibly the simplest to implement,=20 > > but non-standard. > > > [Sasha] In addition top referring to a non-existent "PWE3=20 > application", this method does not specify which side=20 > ALLOCATES the demultiplexer. As above, the application demux is not a PWE function, it is a UDP/IP function. In this case the upstream side allocates. > > 5. Use of destination port number as connection=20 > > de-multiplexer, and optionally > > source port number as application de-multiplexer. This method (the=20 > > first part of which is used by RTP) seems to violate both conventional=20 > > usage of destination port numbers as application de-multiplexers, and=20 > > common sense by differentiation between different sources based on=20 > > destination port. > > > [Sasha] Leaving aside the emotional side, I'd like to point=20 > out that in the PWE3 architecture de-multipexers are commonly=20 > used to identify the DESTINATION PW endpoints in the egress=20 > PEs in the data plane, so that this method fully complies=20 > with my common sense (for whatever it is worth). In addition=20 > it can be easily combined with a suitable control protocol=20 > (see my comment to method #3). Hence I would say that this is=20 > definitely the preferable method. I note that you don't disagree that conventional (i.e. except RTP) usage is for destination UDP ports to identifiy applications, of which PWE is one. Also, downstream allocation could be used but the label still placed in the SOURCE port. Y(J)S From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: ITU-T Q5/13 Liason re PW over UDP Date: Mon, 21 Jun 2004 17:47:08 +0200 Lines: 204 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Thomas Narten , Danny McPherson , pwe3@ietf.org, Scott Bradner , "Peterson, Jon" X-From: pwe3-bounces@ietf.org Mon Jun 21 20:30:46 2004 Return-path: To: "'Yaakov Stein'" , stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yaakov and all, Thank you for a prompt response. Please see some answers imline below. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Monday, June 21, 2004 3:26 PM > To: Sasha Vainshtein; stbryant@cisco.com > Cc: Thomas Narten; pwe3@ietf.org; Danny McPherson; Scott > Bradner; Peterson, Jon > Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP > > > Sasha and all, > > > > Q5/13 is extending ITU-T Recommendations specifying interworking > LSPs > > > (PWs) over MPLS networks, to networks based on UDP/IP. > > > We understand that your charter also defines UDP/IP as a possible > > > packet switched network infrastructure. > > > Due to the lack of an interworking LSP label, a connection > > > de-multiplexing mechanism must be devised for this case. > > > > > [Sasha] As a general comment, I'd say that the method used > > for demultiplexing PWs over UDP/IP should not be > > architecturally different from the other demultiplexing > > methods used in PWE3, e.g. MPLS or L2TPv3. In particular: > > 1. The demultiplexers exist in the PWE3 data plane, and > > are distributed using manual configuration or some control > > protocol. > > 2. The demultiplexer value for each direction of the PW is > > allocated by the corresponding egress PW 3. If a control > > protocol is used, the demultiplexer value is > > distributed from the egress to the ingress PE for each > > direction of the PW. > > In addition, one should avoid using architectural elements > > that have not been specified in the PWE3 Architecture. > > Mostly agree. > However, please note that the usage in PWE has followed that of MPLS > in downstream allocation of PW labels. > This does not necessarily carry over to the UDP case, but may. > [Sasha] Since we allocate the PW demultiplexers downstream in MPLS and L2TPv3, a very strong justification is, IMO, required to do things differently over UDP. > > > > > > > Our analysis has uncovered five possibilities for using UDP port > > > numbers as connection de-multiplexers, namely: > > > > > > 1. Use of destination port as application de-multiplexers, > > > and source + > > > destination socket as connection de-multiplexers. This > > method (used by > > > HTTP) restricts a pair of end-points to a single simultaneous > > > connection, and hence is not relevant for interworking LSPs (PWs). > > > > > [Sasha] IMO the PWE3 architecture does not define any "applications" > > and/or "application de-multiplexers". > > PWE3 doesn't define the application demux - this is a feature > of UDP/IP > and TCP/IP. > A UDP/IP PWE IWF may have to handle FTP or HTTP or whatever > in addition to the PWs. > [Sasha] I have probably missed something. Until now I have been under impression that a PW IWF hanldes only PW traffic and nothing else? > > ... snipped ... (we seem to agree on this one0! > > > > 3. Use of destination port number to identify a > control protocol, > and explicit > > > allocation of port numbers (either downstream or upstream). > > > This method (used by FTP) could be applicable to interworking LSPs > (PWs), but would require > > > the development of a new control protocol. Such a > protocol could be > > > based on a subset of targeted LDP. > > > > > [Sasha] I'd say that a more relevant example is establishment > > over a L2TPv2/v3 over UDP Tunnel/Control Connection. This > > technique (described in RFC 2661) results in: > > - each peer allocating a locally free UDP port as the de-multiplexer > > value for the direction of the connection for which it is the > receiver > > - using the allocated value as the Source UDP port in all > the messages > > it sends save from the SCCRQ message (which is sent to the > well-known port) > > - using the similar value allocated by the peer as the > Destination UDP > port > > in all the messages it sends save from the SCCRQ message which is > sent > > to the well-known port because the peer allocation is not > known yet. > > OK - this is a valid analogy too. > > The use of FTP is perhaps somewhat better known, > and interesting in that you can have upstream allocation > (port command) > or downstream allocation (pasv command). > [Sasha], Well, I can add that TFTP (that presumably is no less known than FTP) uses exactly the same scheme AND downstream Transfer Identification (TID) allocation; each side places its local TID as the Source UDP port and the peer TID - as the Destination UDP port in all the packets it generates excluding the request for intiation of transfer (WRQ or RRQ) which are sent to the TFTP well-known port - see RFC 783 for details. > > > > 4. Use of destination port number as application > > > de-multiplexer, and source port > > > number as connection de-multiplexer. This method (used by the > > > draft-ietf-pwe3-tdmoip-01.txt) is possibly the simplest to > implement, > > > but non-standard. > > > > > [Sasha] In addition top referring to a non-existent "PWE3 > > application", this method does not specify which side > > ALLOCATES the demultiplexer. > > As above, the application demux is not a PWE function, > it is a UDP/IP function. > [Sasha] But who needs this function? PWE3 can do without (as it does in the L2TPv3 and MPLS use cases), so why make life more complicated? > > In this case the upstream side allocates. > > > > 5. Use of destination port number as connection > > > de-multiplexer, and optionally > > > source port number as application de-multiplexer. This > method (the > > > first part of which is used by RTP) seems to violate both > conventional > > > usage of destination port numbers as application de-multiplexers, > and > > > common sense by differentiation between different sources > based on > > > destination port. > > > > > [Sasha] Leaving aside the emotional side, I'd like to point > > out that in the PWE3 architecture de-multipexers are commonly > > used to identify the DESTINATION PW endpoints in the egress > > PEs in the data plane, so that this method fully complies > > with my common sense (for whatever it is worth). In addition > > it can be easily combined with a suitable control protocol > > (see my comment to method #3). Hence I would say that this is > > definitely the preferable method. > > I note that you don't disagree that conventional (i.e. except RTP) > usage is for destination UDP ports to identifiy applications, > of which PWE is one. > > Also, downstream allocation could be used but the label > still placed in the SOURCE port. > [Sasha] I DO disagree and on several counts. 1. RTP, TFTP and L2TPv2 are quite conventional, IMO. What's more, they are among the most widely deployed UDP protocols AFAIK. 2. All the UDP-based protocols that deal with bi-directional traffic SWAP the source and destination UDP ports for the two directions of traffic (some UDP protocols, e.g., SYSLOG, are unidirectional by nature so this does not apply). And this is done in a perfect match with the following spec (quoted from RFC 768): Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. 3. As I have said already, since the demultiplexer (as a data plane enity) is used to identify the DESTINATION (e.g., the PE-to-CE direction of an attachment circuit of a PW end point), placing it in the SOURCE port contradicts the common sense (at least, mine). 4. While upstream allocation of the demultiplexer is probably possible, it is both more complicated and only rarely justified (the only example so far has been the FTP "passive" mode). In the PWE3 case I do not see any justification for it. > > Y(J)S > From pwe3-bounces@ietf.org Wed Dec 27 15:58:26 2006 From: "Fabio Poggi" Subject: CLP bit to QoS mapping Date: Mon, 21 Jun 2004 16:52:19 +0200 Lines: 13 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Mon Jun 21 20:31:01 2004 Return-path: To: pwe3@ietf.org X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 21/06/2004 15:53:03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge