From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Tue, 11 May 2004 14:42:09 +0300 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "PWE3 \(IETF\)" X-From: pwe3-admin@ietf.org Tue May 11 14:00:05 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call Thread-Index: AcQ3KIXL8jsPtA5YRAepEbkOjU9gawAI+ahg To: "David Zelig" , "Ron Cohen" , "Andrew G. Malis" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , David,=20 > The difference between SONET and the pure TDM case is that a=20 > SONET signal may contain significant portion of unequipped=20 > payloads, so network wide with large number of connections=20 > you can take advantage of the statistical saving. For AIS, I=20 > agree that the saving is non-significant but once the=20 > mechanism is there why not use it? Yes, I know that you do "DBA" for the unequipped case as well. This case obviously doesn't occur for the low-rate emulation, which is the context I was refering to. However, for the SONET case, do you envision the unequipped payload to be a transient state, or a particular SONET PW will run this way all the time? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: David Zelig Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Tue, 11 May 2004 16:16:26 +0200 Lines: 18 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: "PWE3 (IETF)" X-From: pwe3-admin@ietf.org Tue May 11 15:27:09 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , > > > However, for the SONET case, do you envision the unequipped > payload to be a transient state, or a particular SONET PW > will run this > way > all the time? Not all the time, but for significant portion of the time - on a large enough network (or more precisely large enough number of connections) you may gain some BW for other type of services. David > > Y(J)S > > From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Yaakov Stein" Subject: VCCV ? Date: Thu, 13 May 2004 11:41:19 +0300 Lines: 81 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C438C6.10AF83D7" Cc: "PWE3 \(IETF\)" X-From: pwe3-admin@ietf.org Thu May 13 11:02:51 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: VCCV ? Thread-Index: AcQ4xhARGPZRQdBFQWmL5YJeTEt3xA== To: , "Monique \"Morrow \(mmorrow\)" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C438C6.10AF83D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom / Monique Is there a good reason to continue using the term "VC" in VCCV rather than PW? We are now consistently using the term PW, e.g. "VC labels" has become "PW labels", etc. So I believe it would be easier and more compliant with present PWE terminology to say "PWCV" rather than "VCCV" . And while we are at it, I prefer "connectivity verification" to "connection verification". Y(J)S ------_=_NextPart_001_01C438C6.10AF83D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable VCCV ?

Tom / = Monique

Is there = a good reason to continue using the term "VC" in = VCCV

rather = than PW?

We are = now consistently using the term PW,

e.g. = "VC labels" has become "PW labels", = etc.

So I = believe it would be easier and more compliant with present PWE = terminology

to say = "PWCV" rather than "VCCV" .

And = while we are at it, I prefer "connectivity = verification"

to = "connection verification".

Y(J)S

------_=_NextPart_001_01C438C6.10AF83D7-- From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Thomas D. Nadeau" Subject: Re: VCCV ? Date: 13 May 2004 09:09:58 -0400 Organization: Cisco Systems, Inc. Lines: 37 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A520281C73D@exrad2.ad.rad.co.il> Reply-To: tnadeau@cisco.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "Monique \"Morrow ""(mmorrow)" , "PWE3 (IETF)" X-From: pwe3-admin@ietf.org Thu May 13 15:17:39 2004 Return-path: To: Yaakov Stein In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520281C73D@exrad2.ad.rad.co.il> X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , > Tom / Monique > > Is there a good reason to continue using the term "VC" in VCCV > > rather than PW? > > We are now consistently using the term PW, > > e.g. "VC labels" has become "PW labels", etc. It is up to the WG to change the name of the document, but my personal feeling is to leave it as-is given that its been out for so long and actually deployed by many vendors. Changing the name now could cause industry confusion IMHO in an area that needs no more confusion. *) > So I believe it would be easier and more compliant with present PWE > terminology > > to say "PWCV" rather than "VCCV" . or just pcv. :P > And while we are at it, I prefer "connectivity verification" > > to "connection verification". Agreed. We will fix this in the next revision of the draft. --Tom > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Luca Martini Subject: Re: VCCV ? Date: Fri, 14 May 2004 13:07:29 -0600 Organization: Cisco Systems Lines: 72 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A520281C73D@exrad2.ad.rad.co.il> <1084453797.7678.19.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Yaakov Stein , "Monique \"Morrow \"(mmorrow)" , "PWE3 (IETF)" X-From: pwe3-admin@ietf.org Fri May 14 21:19:32 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: tnadeau@cisco.com In-Reply-To: <1084453797.7678.19.camel@localhost.localdomain> X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov, 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. Luca Thomas D. Nadeau wrote: >>Tom / Monique >> >>Is there a good reason to continue using the term "VC" in VCCV >> >>rather than PW? >> >>We are now consistently using the term PW, >> >>e.g. "VC labels" has become "PW labels", etc. >> >> > > It is up to the WG to change the name of >the document, but my personal feeling is to leave it >as-is given that its been out for so long and >actually deployed by many vendors. Changing the name >now could cause industry confusion IMHO in an area >that needs no more confusion. *) > > > >>So I believe it would be easier and more compliant with present PWE >>terminology >> >>to say "PWCV" rather than "VCCV" . >> >> > > or just pcv. :P > > > >>And while we are at it, I prefer "connectivity verification" >> >>to "connection verification". >> >> > > Agreed. We will fix this in the next revision of the draft. > > --Tom > > > > >>Y(J)S >> >> >> > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: George Swallow Subject: Re: VCCV ? Date: Fri, 14 May 2004 15:40:34 -0400 Lines: 20 Sender: pwe3-admin@ietf.org References: <40A518F1.7060602@cisco.com> Cc: tnadeau@cisco.com, Yaakov Stein , "Monique \"Morrow \"(mmorrow)" , "PWE3 (IETF)" X-From: pwe3-admin@ietf.org Fri May 14 22:47:03 2004 Return-path: X-BrightmailFiltered: true To: Luca Martini cc: swallow@cisco.com In-reply-to: Your message of "Fri, 14 May 2004 13:07:29 MDT." <40A518F1.7060602@cisco.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.1.1 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , > 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. ...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 From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Yaakov Stein" Subject: RE: VCCV ? Date: Sun, 16 May 2004 14:00:09 +0300 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: , "Monique \"Morrow \"\(mmorrow\)" , "PWE3 \(IETF\)" X-From: pwe3-admin@ietf.org Sun May 16 13:11:09 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: AcQ56xbj5bmqQDoIT9ig33C3OX4SKwBSXWSw To: "George Swallow" , "Luca Martini" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , =20 > If we have to change the name for the VC part then we should=20 > change the CV as well. What is being defined is a channel=20 > (and means of signalling) for general operations and management tools. > It's not limited to Connectivity Verification. I think that connectivity verification is its main function. > ps. It really a channel to ensure the psuedowires are=20 > working properly. Would you believe PWWP? ;-) What about PW-ping?=20 Since ICMP packets are only one option, more generally could we say PW-probe ? Y(J)S From i-d-announce-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-satop-mib-00.txt Date: Thu, 20 May 2004 16:01:50 -0400 Lines: 93 Sender: i-d-announce-admin@ietf.org Reply-To: internet-drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: i-d-announce-admin@ietf.org Thu May 20 22:53:02 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Managed Objects for Structure-Agnostic TDM over Packet Network Author(s) : O. Nicklass Filename : draft-ietf-pwe3-satop-mib-00.txt Pages : 20 Date : 2004-5-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for TDM (T1, E1, T3, E3) bit-streams circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-mib-00.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-satop-mib-00.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-satop-mib-00.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 i-d-announce-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdm-mib-00.txt Date: Thu, 20 May 2004 16:01:54 -0400 Lines: 93 Sender: i-d-announce-admin@ietf.org Reply-To: internet-drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: i-d-announce-admin@ietf.org Thu May 20 22:54:50 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Managed Objects for TDM over Packet Switched Network (PSN) Author(s) : O. Nicklass Filename : draft-ietf-pwe3-tdm-mib-00.txt Pages : 37 Date : 2004-5-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-00.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-tdm-mib-00.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-tdm-mib-00.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 i-d-announce-admin@ietf.org Wed Dec 27 15:58:25 2006 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 Lines: 90 Sender: i-d-announce-admin@ietf.org Reply-To: internet-drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: i-d-announce-admin@ietf.org Thu May 20 22:57:41 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : 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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Andrew G. Malis" Subject: WG last call requested for draft-ietf-pwe3-fcs-retention-01.txt Date: Thu, 20 May 2004 17:21:17 -0400 Lines: 75 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Thu May 20 23:50:06 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: "PWE3 (IETF)" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , The authors feel that this draft is ready to enter WG last call. 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 ------- From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: zinin@psg.com Subject: Mail Delivery (failure pwe3@ietf.org) Date: Fri, 21 May 2004 13:13:03 +0800 Lines: 42 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-From: pwe3-admin@ietf.org Fri May 21 07:25:38 2004 Return-path: To: pwe3@ietf.org X-Priority: 3 X-MSMail-Priority: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 13.2 points; * 0.2 NO_REAL_NAME From: does not include a real name * 0.0 EXTRA_MPART_TYPE Header has extraneous Content-type:...type= entry * 1.0 ADDRESS_IN_SUBJECT To: address listed at front of Subject * 0.3 J_CHICKENPOX_73 BODY: {7}Letter - dot - {3}Letter * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 1.7 HTML_RELAYING_FRAME BODY: Frame wanted to load outside URL * 3.0 MPART_ALT_DIFF BODY: HTML and text parts are different * 0.0 BAYES_50 BODY: Bayesian spam probability is 50 to 56% * [score: 0.5000] * 0.1 HTML_MESSAGE BODY: HTML included in message * 4.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [218.193.191.176 listed in sbl-xbl.spamhaus.org] * 1.6 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.2 PRIORITY_NO_NAME Message has priority, but no X-Mailer/User-Agent This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C0CA80.6B015D10" ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the message will not displayed automatically,
follow the link to read the delivered message.

Received message is available at:
www.ietf.org/inbox/pwe3/read.php?sessionid-14872
 
------=_NextPart_001_001C_01C0CA80.6B015D10-- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Filename: message.scr, Content-Type: audio/x-wav] The attachment file in the message has been removed by eManager. ------=_NextPart_000_001B_01C0CA80.6B015D10-- From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt Date: Fri, 21 May 2004 10:53:09 +0100 Organization: Cisco Systems, Inc. Lines: 7 Sender: pwe3-admin@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: Danny McPherson X-From: pwe3-admin@ietf.org Fri May 21 12:09:04 2004 Return-path: 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" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , This the two week Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt Last Call will end Monday 7th June 2004 - Stewart From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: [Fwd: draft-ietf-pwe3-satop-01.txt - Last Call] Date: Fri, 21 May 2004 11:01:36 +0100 Organization: Cisco Systems, Inc. Lines: 29 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 21 12:27:35 2004 Return-path: 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" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Last call has completed on this with no comments. We will sent it to the IESG. - Stewart -------- Original Message -------- Subject: [PWE3] draft-ietf-pwe3-satop-01.txt - Last Call Date: Mon, 19 Apr 2004 13:25:44 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. To: pwe3@ietf.org CC: Danny McPherson This the two week Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-01.txt Last Call will end Tuesday 4th May 2004 - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-fcs-retention-01.txt Last Call Date: Fri, 21 May 2004 11:46:01 +0100 Organization: Cisco Systems, Inc. Lines: 7 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 21 13:09:43 2004 Return-path: 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 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , This is the start of two week last call on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-01.txt Last call will end on Monday June 7th 2004 Stewart From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: MIB status request Date: Fri, 21 May 2004 12:05:24 +0100 Organization: Cisco Systems, Inc. Lines: 18 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 21 13:15:41 2004 Return-path: 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" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Please could the MIB authors give a status update to the WG chairs. We are close to sending protocol and encap drafts to the IESG, and need to start getting the MIBs ready for LC. Thanks - Stewart draft-ietf-pwe3-pw-mib-04.txt - STD draft-ietf-pwe3-pw-mpls-mib-05.txt - STD draft-ietf-pwe3-pw-tc-mib-04.txt - STD draft-ietf-pwe3-cep-mib-04.txt - STD draft-pwe3-enet-mib-04.txt (needs a name change) - STD draft-ietf-pwe3-pw-atm-mib-00.txt - STD draft-ietf-pwe3-satop-mib-00.txt - STD draft-ietf-pwe3-tdm-mib-00.txt - STD From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: [Fwd: Re: Latest status] Date: Fri, 21 May 2004 22:32:38 +0100 Organization: Cisco Systems, Inc. Lines: 73 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 21 23:56:55 2004 Return-path: 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" , Danny McPherson Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Here is the current status of the PWE3 WG drafts - Stewart RFC Editor ---------- draft-ietf-pwe3-arch-07.txt - INFO IESG Review ----------- draft-ietf-pwe3-requirements-08.txt - INFO (We do not know why this is still in this state. We have asked) Sent to IESG for Review --------------------- draft-ietf-pwe3-tdm-requirements-05.txt - INFO draft-ietf-pwe3-atm-encap-05.txt - STD draft-ietf-pwe3-satop-01.txt - STD draft-ietf-pwe3-ethernet-encap-06.txt - STD Completed Last Call ------------------- draft-ietf-pwe3-fragmentation-05.txt - STD ------------------------------------------ Waiting for two updates from the authors draft-ietf-pwe3-control-protocol-06.txt - STD ------------------------------------------- Needs an edit and then has to go back into LC Ready for Last Call ------------------- draft-ietf-pwe3-frame-relay-02.txt (needs a refresh first) - STD ---------------------------------------------------------------- Needs a final edit and the ready for LC. draft-ietf-pwe3-sonet-05.txt - STD ---------------------------------- There were comments on -05, we now need -06 draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt - STD ------------------------------------------------ 21/5/4 LC sent to list draft-ietf-pwe3-cesopsn-00.txt - INFO ------------------------------------- Sent LC but considerable comment. Needs an update and a new LC draft-ietf-pwe3-fcs-retention-00.txt - STD ------------------------------------------ 21/5/4 sent LC to list Work in Progress ---------------- draft-ietf-pwe3-iana-allocation-03.txt - INFO?? draft-ietf-pwe3-pw-mib-04.txt - STD draft-ietf-pwe3-pw-mpls-mib-05.txt - STD draft-ietf-pwe3-pw-tc-mib-04.txt - STD draft-ietf-pwe3-cep-mib-04.txt - STD draft-pwe3-enet-mib-04.txt (needs a name change) - STD draft-ietf-pwe3-pw-atm-mib-00.txt - STD draft-ietf-pwe3-satop-mib-00.txt - STD draft-ietf-pwe3-tdm-mib-00.txt - STD MIB authors have been asked to provide a status update. draft-ietf-pwe3-vccv-02.txt - STD draft-ietf-pwe3-tdmoip-00.txt - INFO From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: David Zelig Subject: RE: MIB status request Date: Sat, 22 May 2004 09:56:24 +0200 Lines: 46 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Sat May 22 09:21:55 2004 Return-path: To: stbryant@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Stewart, please see inline David > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, May 21, 2004 1:05 PM > To: pwe3@ietf.org > Subject: [PWE3] MIB status request > > > Please could the MIB authors give a status update to the > WG chairs. > > We are close to sending protocol and encap drafts to the > IESG, and need to start getting the MIBs ready for LC. > > Thanks > > - Stewart > > draft-ietf-pwe3-pw-mib-04.txt - STD > draft-ietf-pwe3-pw-mpls-mib-05.txt - STD > draft-ietf-pwe3-pw-tc-mib-04.txt - STD > draft-ietf-pwe3-cep-mib-04.txt - STD All the above need one more round for updating new PW types and some cleaning, no changes expected in structure, etc. > draft-pwe3-enet-mib-04.txt (needs a name change) - STD Need one more round of deeper changes. After the next round, our intention is that all 5 drafts will be ready for last call. > draft-ietf-pwe3-pw-atm-mib-00.txt - STD > draft-ietf-pwe3-satop-mib-00.txt - STD > draft-ietf-pwe3-tdm-mib-00.txt - STD > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Sasha Vainshtein Subject: RE: WG last call requested for draft-ietf-pwe3-fcs-retenti on-01.txt Date: Sat, 22 May 2004 18:22:47 +0200 Lines: 111 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Sat May 22 17:41:01 2004 Return-path: To: "'Andrew G. Malis '" , "'PWE3 (IETF) '" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Andy and all, A brief pre-LC comment on the draft in question: In its present form the draft only indicates whether the FCS is retained or not as the corresponding Interface Parameter does not carry any value,just ID. This is OK when dealing with Ethernet and ATM AAL5 PWs. However, if you want to retain FCS in HDLC or FR PWs, FCS retention only makes sense if the two ACs use the same FCS size (2 or 4 bytes). If the sizes are different, FCS retenation cannot function. However, the draft does not allow signaling of the expected FCS size and hence does not prevent successful setup of non-operational PWs. Hopefully this comment will be helpful. -----Original Message----- From: Andrew G. Malis To: PWE3 (IETF) Sent: 5/20/2004 11:21 PM Subject: [PWE3] WG last call requested for draft-ietf-pwe3-fcs-retention-01.txt The authors feel that this draft is ready to enter WG last call. 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-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Andrew G. Malis" Subject: RE: WG last call requested for draft-ietf-pwe3-fcs-retenti on-01.txt Date: Sat, 22 May 2004 15:33:37 -0400 Lines: 64 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'PWE3 (IETF) '" X-From: pwe3-admin@ietf.org Sat May 22 21:43:44 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: Sasha Vainshtein In-Reply-To: References: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha, >Andy and all, >A brief pre-LC comment on the draft in question: > >In its present form the draft only indicates whether the FCS is >retained or not as the corresponding Interface Parameter does >not carry any value,just ID. > >This is OK when dealing with Ethernet and ATM AAL5 PWs. > >However, if you want to retain FCS in HDLC or FR PWs, FCS retention >only makes sense if the two ACs use the same FCS size (2 or 4 bytes). >If the sizes are different, FCS retenation cannot function. >However, the draft does not allow signaling of the expected FCS >size and hence does not prevent successful setup of non-operational PWs. Thanks - you're absolutely correct. For the post-LC revision, I'll replace section 3 with the following: 3. Signaling FCS Retention With MPLS-based Pseudowires When using the signaling procedures in [4], there is a Virtual Circuit FEC element parameter ID used to signal the desire to retain the FCS when advertising a VC label: Parameter ID Length Description 0x0A 4 FCS Retention Indicator The presence of this parameter ID in the VC FEC element indicates that the egress PE requests the ingress PE to retain the FCS for the VC label being advertised. It does not obligate the ingress PE to retain the FCS; it is simply an indication that the ingress PE MAY retain the FCS. The sender MUST NOT retain the FCS if this parameter ID is not present in the VC FEC element. The parameter includes 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 parameter allows the PEs to ensure that the FCS is only retained when it makes sense. Since unknown parameter IDs are silently ignored [4], backwards compatibility with systems that do not implement this document is provided by requiring that the FCS is retained ONLY if the FCS Retention Indicator with an identical setting for the FCS length has been included in the advertisements for both directions on a pseudowire. If the ingress PE recognizes the FCS Retention Indicator parameter ID, but does not wish to retain the FCS with the indicated length, it need only issue its own label mapping message for the opposite direction without including the FCS Retention Indicator. This will prevent FCS retention in either direction. If PWE3 signaling [4] is not in use for a pseudowire, then whether or not the FCS is to be retained MUST be identically provisioned in both PEs at the pseudowire endpoints. If there is no provisioning support for this option, the default behavior is to remove the FCS. Cheers, Andy From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: sob@harvard.edu Subject: Mail Delivery (failure pwe3@ietf.org) Date: Sun, 23 May 2004 19:24:35 +0800 Lines: 42 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-From: pwe3-admin@ietf.org Sun May 23 13:35:12 2004 Return-path: To: pwe3@ietf.org X-Priority: 3 X-MSMail-Priority: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 13.2 points; * 0.2 NO_REAL_NAME From: does not include a real name * 0.0 EXTRA_MPART_TYPE Header has extraneous Content-type:...type= entry * 1.0 ADDRESS_IN_SUBJECT To: address listed at front of Subject * 0.3 J_CHICKENPOX_73 BODY: {7}Letter - dot - {3}Letter * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 1.7 HTML_RELAYING_FRAME BODY: Frame wanted to load outside URL * 3.0 MPART_ALT_DIFF BODY: HTML and text parts are different * 0.0 BAYES_50 BODY: Bayesian spam probability is 50 to 56% * [score: 0.5000] * 0.1 HTML_MESSAGE BODY: HTML included in message * 4.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [218.193.191.176 listed in sbl-xbl.spamhaus.org] * 1.6 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.2 PRIORITY_NO_NAME Message has priority, but no X-Mailer/User-Agent This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C0CA80.6B015D10" ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the message will not displayed automatically,
follow the link to read the delivered message.

Received message is available at:
www.ietf.org/inbox/pwe3/read.php?sessionid-30710
 
------=_NextPart_001_001C_01C0CA80.6B015D10-- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Filename: message.scr, Content-Type: audio/x-wav] The attachment file in the message has been removed by eManager. ------=_NextPart_000_001B_01C0CA80.6B015D10-- From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: Stewart Bryant Subject: Re: WG last call requested for draft-ietf-pwe3-fcs-retenti on-01.txt Date: Mon, 24 May 2004 10:44:51 +0100 Organization: Cisco Systems, Inc. Lines: 126 Sender: pwe3-admin@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: "'Andrew G. Malis '" , "'PWE3 (IETF) '" X-From: pwe3-admin@ietf.org Mon May 24 12:01:16 2004 Return-path: 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 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha Good point. Stewart Sasha Vainshtein wrote: > Andy and all, > A brief pre-LC comment on the draft in question: > > In its present form the draft only indicates whether the FCS is > retained or not as the corresponding Interface Parameter does > not carry any value,just ID. > > This is OK when dealing with Ethernet and ATM AAL5 PWs. > > However, if you want to retain FCS in HDLC or FR PWs, FCS retention > only makes sense if the two ACs use the same FCS size (2 or 4 bytes). > If the sizes are different, FCS retenation cannot function. > However, the draft does not allow signaling of the expected FCS > size and hence does not prevent successful setup of non-operational PWs. > > Hopefully this comment will be helpful. > > -----Original Message----- > From: Andrew G. Malis > To: PWE3 (IETF) > Sent: 5/20/2004 11:21 PM > Subject: [PWE3] WG last call requested for > draft-ietf-pwe3-fcs-retention-01.txt > > The authors feel that this draft is ready to enter WG last call. > > 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 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Andrew G. Malis" Subject: Re: WG last call requested for draft-ietf-pwe3-fcs-retenti on-01.txt Date: Mon, 24 May 2004 06:45:12 -0400 Lines: 28 Sender: pwe3-admin@ietf.org References: <40B1C413.4040502@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Sasha Vainshtein , "'PWE3 (IETF) '" X-From: pwe3-admin@ietf.org Mon May 24 13:03:54 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: stbryant@cisco.com In-Reply-To: <40B1C413.4040502@cisco.com> References: <40B1C413.4040502@cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Stewart, Did you see the reply I sent on the list about this on Saturday? Cheers, Andy At 5/24/2004 10:44 AM +0100, Stewart Bryant wrote: >Sasha > >Good point. > >Stewart > >Sasha Vainshtein wrote: > >>Andy and all, >>A brief pre-LC comment on the draft in question: >>In its present form the draft only indicates whether the FCS is retained >>or not as the corresponding Interface Parameter does not carry any >>value,just ID. >>This is OK when dealing with Ethernet and ATM AAL5 PWs. >>However, if you want to retain FCS in HDLC or FR PWs, FCS retention only >>makes sense if the two ACs use the same FCS size (2 or 4 bytes). If the >>sizes are different, FCS retenation cannot function. However, the draft >>does not allow signaling of the expected FCS size and hence does not >>prevent successful setup of non-operational PWs. >>Hopefully this comment will be helpful. From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: Re: WG last call requested for draft-ietf-pwe3-fcs-retenti on-01.txt Date: Mon, 24 May 2004 12:17:46 +0100 Organization: Cisco Systems, Inc. Lines: 41 Sender: pwe3-admin@ietf.org References: <40B1C413.4040502@cisco.com> <6.1.0.6.2.20040524064417.06dedec0@mail.comcast.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Sasha Vainshtein , "'PWE3 (IETF) '" X-From: pwe3-admin@ietf.org Mon May 24 13:42:18 2004 Return-path: 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: "Andrew G. Malis" In-Reply-To: <6.1.0.6.2.20040524064417.06dedec0@mail.comcast.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Andrew G. Malis wrote: > Stewart, > > Did you see the reply I sent on the list about this on Saturday? > > Cheers, > Andy > Just found it. - Stewart > At 5/24/2004 10:44 AM +0100, Stewart Bryant wrote: > >> Sasha >> >> Good point. >> >> Stewart >> >> Sasha Vainshtein wrote: >> >>> Andy and all, >>> A brief pre-LC comment on the draft in question: >>> In its present form the draft only indicates whether the FCS is >>> retained or not as the corresponding Interface Parameter does not >>> carry any value,just ID. >>> This is OK when dealing with Ethernet and ATM AAL5 PWs. >>> However, if you want to retain FCS in HDLC or FR PWs, FCS retention >>> only makes sense if the two ACs use the same FCS size (2 or 4 bytes). >>> If the sizes are different, FCS retenation cannot function. However, >>> the draft does not allow signaling of the expected FCS size and hence >>> does not prevent successful setup of non-operational PWs. >>> Hopefully this comment will be helpful. > > > > 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-06.txt Date: Tue, 25 May 2004 15:51:57 -0400 Lines: 100 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 Tue May 25 23:22:14 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-06.txt Pages : 48 Date : 2004-5-25 The generic requirements and architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3- ARCH]. Additional requirements for emulation of SONET/SDH and lower-rate TDM circuits has been defined in [PWE3-TDM-REQ]. 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-06.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-06.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-06.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-06.txt Date: Wed, 26 May 2004 11:34:49 -0700 Lines: 93 Sender: pwe3-bounces@ietf.org References: <200405251951.PAA13020@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Wed May 26 20:50:44 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200405251951.PAA13020@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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 Hi, This draft incorporates the last call comments provided by Deborah and Juergen. There are two issues that I missed during this edit: 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 Regards Ron > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, May 25, 2004 12:52 PM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-sonet-06.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-06.txt > Pages : 48 > Date : 2004-5-25 > > The generic requirements and architecture for Pseudo Wire Emulation > Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3- > ARCH]. Additional requirements for emulation of SONET/SDH and > lower-rate TDM circuits has been defined in [PWE3-TDM-REQ]. > 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-06.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-06.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-06.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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Ron Cohen" Subject: Default payload size of NxDS0 (CESoPSN Last Call) Date: Sat, 1 May 2004 22:26:34 -0700 Lines: 32 Sender: pwe3-admin@ietf.org References: <4091761E.3000703@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Sun May 02 07:40:24 2004 Return-path: To: , "Sasha Vainshtein" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <4091761E.3000703@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha, In IETF Korea I asked for change in the default payload size of NxDS0 service for small N to be changed from 5 to 4ms. Is this going to be changed? Thanks Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Stewart Bryant > Sent: Thursday, April 29, 2004 2:40 PM > To: pwe3@ietf.org > Subject: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > This the start of the two week Last Call for comments on > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-00.txt > > Last Call will end Monday 17th May 2004 > > - Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Tue, 4 May 2004 15:51:43 +0300 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Tue May 04 15:02:36 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQuNMM8sGiHXnhASxq/hEroS/wYvgDoIHDg To: "Sasha Vainshtein" , , Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha,=20 In CESoPSN "A special combination of flags in the CESoPSN control word is used to=20 distinguish between data and signaling packets", namely L=3D0, M=3D11 (a combination marked as reserved in Y.1413). When signalling is carried in separate packets, what processing has to be performed when a lost packet is detected (as it is not immediately clear whether the lost packet is signaling or data) ? Is the optional RTP timestamp REQUIRED for this case? Do you allow signalling packets to be sent in a separate PW? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Tue, 4 May 2004 15:59:41 +0200 Lines: 45 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 04 15:16:39 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov and all, Annex A of the draft states that signaling packets use a separate numbering sequence (independent from that of the data packets). Hence the mechanism for detection of lost data packets used with the basic NxDS0 services (or with SAToP) will not be affected by presence of signaling packets and vice versa. It probably makes sense to move the caveat on the separate numbering sequence of signaling packets to the body of the draft to avoid misunderstaning. Would this be OK with you? 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: Tuesday, May 04, 2004 2:52 PM > To: Sasha Vainshtein; stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > In CESoPSN "A special combination of flags in the CESoPSN control word > is used to > distinguish between data and signaling packets", namely L=0, M=11 > (a combination marked as reserved in Y.1413). > > When signalling is carried in separate packets, > what processing has to be performed when a lost > packet is detected (as it is not immediately clear whether > the lost packet is signaling or data) ? > > Is the optional RTP timestamp REQUIRED for this case? > > Do you allow signalling packets to be sent in a separate PW? > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 08:55:38 +0300 Lines: 93 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Wed May 05 08:07:17 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQx19rVY84khI6GQ3mppLFWb1aJ2QAjKZcQ To: "Sasha Vainshtein" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha,=20 I thought that this is what you intended, but didn't see it in the text. This is indeed somewhat better, but opens a new can of worms. First, sequencing is a feature covered in the architecture draft, and the TDM case already deviates somewhat from the norm in requiring the sequencing (not leaving it optional) and hence not assigning a special meaning to zero. However, having a single PW maintain two separate sequencing streams seems a much more major deviation from the PWE architecture as I understand it. Basically you are running two independent PWs under a single label, and I think this requires some consideration. I realize that you are reticent to require assignment of two separate PW labels, as this would require more messaging or provisioning, but I am not sure that this extra work is in vain. Second, since the sequences are independent, but run at different rates, nothing prevents them from becoming close. Hence the sequence number processing can not rely on the sequence number alone, but MUST check the L+M fields. In fact, the L+M fields must be checked FIRST, and only then the sequence processing performed. Finally, how do I know to expect this "double PW with a single label"? Is it signalled at setup ? Y(J)S > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 > Sent: Tuesday, May 04, 2004 17:00 > To: Yaakov Stein > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL >=20 > Yaakov and all, > Annex A of the draft states that signaling packets use a=20 > separate numbering sequence (independent from that of the=20 > data packets). > Hence the mechanism for detection of lost data packets used=20 > with the basic NxDS0 services (or with SAToP) will not be=20 > affected by presence of signaling packets and vice versa. >=20 > It probably makes sense to move the caveat on the separate=20 > numbering sequence of signaling packets to the body of the=20 > draft to avoid misunderstaning. Would this be OK with you? >=20 > With best regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > =20 >=20 >=20 > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Tuesday, May 04, 2004 2:52 PM > > To: Sasha Vainshtein; stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > >=20 > >=20 > > Sasha, > >=20 > > In CESoPSN "A special combination of flags in the CESoPSN=20 > control word=20 > > is used to distinguish between data and signaling packets", namely=20 > > L=3D0, M=3D11 (a combination marked as reserved in Y.1413). > >=20 > > When signalling is carried in separate packets, what=20 > processing has to=20 > > be performed when a lost packet is detected (as it is not=20 > immediately=20 > > clear whether the lost packet is signaling or data) ? > >=20 > > Is the optional RTP timestamp REQUIRED for this case? > >=20 > > Do you allow signalling packets to be sent in a separate PW? > >=20 > > Y(J)S > >=20 >=20 >=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 10:46:56 +0200 Lines: 138 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 05 10:06:44 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov and all, Please see some answers inline. Hopefylly they will be helpful. 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: Wednesday, May 05, 2004 7:56 AM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > I thought that this is what you intended, > but didn't see it in the text. > > This is indeed somewhat better, but opens > a new can of worms. > > First, sequencing is a feature covered in the > architecture draft, and the TDM case already > deviates somewhat from the norm in requiring > the sequencing (not leaving it optional) and > hence not assigning a special meaning to zero. > [Sasha] Sorry, I've checked the latest architecture draft (-07) and it DOES NOT say anything about "assigning special meaning to zero". It is true that the TDM case differs from the convention used by various L2 encapsulations over MPLS, but this is not related to signaling packets. > > However, having a single PW maintain two separate > sequencing streams seems a much more major deviation > from the PWE architecture as I understand it. > [Sasha] IMHO this is fully compliant with the notion of PWE3 Channel types discussed in Section 5.1.2 of the said draft. The applicable channel type is explicitly listed in item 2 of this Section (A high-priority, unreliable, sequenced channel)and, according to the draft, is typically used for CE-CE signaling. > > Basically you are running two independent PWs > under a single label, and I think this requires > some consideration. I realize that you are reticent > to require assignment of two separate PW labels, > as this would require more messaging or provisioning, > but I am not sure that this extra work is in vain. > > Second, since the sequences are independent, > but run at different rates, nothing prevents them > from becoming close. Hence the sequence number processing > can not rely on the sequence number alone, but MUST > check the L+M fields. In fact, the L+M fields must be checked > FIRST, and only then the sequence processing performed. > [Sasha] This is probably correct and deserves explicit mentioning in the draft. > > Finally, how do I know to expect this "double PW with a single label"? > Is it signalled at setup ? > [Sasha] Yes, of course - but signaling is not discussed in the draft in question. > > Y(J)S > > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Tuesday, May 04, 2004 17:00 > > To: Yaakov Stein > > Cc: stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > Yaakov and all, > > Annex A of the draft states that signaling packets use a > > separate numbering sequence (independent from that of the > > data packets). > > Hence the mechanism for detection of lost data packets used > > with the basic NxDS0 services (or with SAToP) will not be > > affected by presence of signaling packets and vice versa. > > > > It probably makes sense to move the caveat on the separate > > numbering sequence of signaling packets to the body of the > > draft to avoid misunderstaning. Would this be OK with you? > > > > 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: Tuesday, May 04, 2004 2:52 PM > > > To: Sasha Vainshtein; stbryant@cisco.com; pwe3@ietf.org > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Sasha, > > > > > > In CESoPSN "A special combination of flags in the CESoPSN > > control word > > > is used to distinguish between data and signaling > packets", namely > > > L=0, M=11 (a combination marked as reserved in Y.1413). > > > > > > When signalling is carried in separate packets, what > > processing has to > > > be performed when a lost packet is detected (as it is not > > immediately > > > clear whether the lost packet is signaling or data) ? > > > > > > Is the optional RTP timestamp REQUIRED for this case? > > > > > > Do you allow signalling packets to be sent in a separate PW? > > > > > > Y(J)S > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 12:01:52 +0300 Lines: 63 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Wed May 05 11:25:21 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQydVm5l8ePgx8iTMui1PLpM/opgQACEnsg To: "Sasha Vainshtein" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha, Your answers are intriguing, as usual. Further comments interleaved to snippets below. Y(J)S > Sorry, I've checked the latest architecture draft=20 > (-07) and it DOES NOT say anything about "assigning special=20 > meaning to zero". =20 I didn't mean to imply that this behavior contradicted the architecture draft (if it would I would have asked for the architecture draft to be changed). All I meant was that only SAToP, CESoPSN and TDMoIP do not skip the zero value. > IMHO this is fully compliant with the notion of > PWE3 Channel types discussed in Section 5.1.2 of the said=20 > draft. The applicable channel type is explicitly listed in=20 > item 2 of this Section (A high-priority, unreliable,=20 > sequenced channel)and, according to the draft, is typically=20 > used for CE-CE signaling.=20 ... and I assume that you are also invoking the succeedin statement from the architecture draft=20 "The data channels (2, 3 and 4 above) should be carried "in band" with one another to as much of a degree as is reasonably possible on a PSN." But did this really imply SEPARATE sequencing for the various channels in a single PW ? I would certainly like to hear Stewart's view on this (as author of the aforementioned draft) as well as the WG at large. I had interpreted "in-band" to mean "over the same PSN", or even "over thee same tunnel", not "over the same PW". The architecture draft does not mention any method of demuxing these channels (which you DO provide in your draft) and thus if we adopt your interpretation we could have multiple un-marked streams with separate sequencing running together in a single PW. This would be indeed be mystifying. > > Finally, how do I know to expect this "double PW with a single label"? > > Is it signalled at setup ? > > > [Sasha] Yes, of course - but signaling is not discussed in=20 > the draft in question.=20 If we do go this way I would suggest adding the appropriate parameter specifying 1) signaling substructure appended to data packet 2) signaling substructure in separate packets with independent sequencing 3) signaling substructure in separate PW to your control protocol extensions draft. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 12:27:17 +0200 Lines: 103 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 05 11:49:45 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov and all, Please see some more inline 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: Wednesday, May 05, 2004 11:02 AM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > Your answers are intriguing, as usual. > > Further comments interleaved to snippets below. > > Y(J)S > > > Sorry, I've checked the latest architecture draft > > (-07) and it DOES NOT say anything about "assigning special > > meaning to zero". > > I didn't mean to imply that this behavior contradicted > the architecture draft (if it would I would have asked for > the architecture draft to be changed). All I meant was > that only SAToP, CESoPSN and TDMoIP do not skip the zero value. > [Sasha] Note also that the L2TPv3 L2-specific sublayer also does not skip zero (in addition to providing a 24-bit sequence number). > > > IMHO this is fully compliant with the notion of > > PWE3 Channel types discussed in Section 5.1.2 of the said > > draft. The applicable channel type is explicitly listed in > > item 2 of this Section (A high-priority, unreliable, > > sequenced channel)and, according to the draft, is typically > > used for CE-CE signaling. > > ... and I assume that you are also invoking the succeedin statement > from the architecture draft > "The data channels (2, 3 and 4 above) should be carried "in band" > with > one another to as much of a degree as is reasonably possible on a > PSN." > > But did this really imply SEPARATE sequencing for the various > channels in a single PW ? > > I would certainly like to hear Stewart's view on this > (as author of the aforementioned draft) > as well as the WG at large. > [Sasha] I do not see it as a major architectural issue beyond the TDM. The difference between the TDM PWs and the rest of them wrt packet loss is essential: TDM PWs MUST compensate each lost packet, while non-TDM can, by default, simply drop mis-ordered packets. I would also glad to hear from Stewart and from the WG at large on this subject. > > I had interpreted "in-band" to mean "over the same PSN", > or even "over thee same tunnel", not "over the same PW". > [Sasha] Unless things have changed drastically from the last time I looked at the TDMoIP draft, you use two types of packets - data and signaling - in the AAL2-based mode - over the same PW. Or did I miss something? > > The architecture draft does not mention any method of > demuxing these channels (which you DO provide in your draft) > and thus if we adopt your interpretation we could have multiple > un-marked streams with separate sequencing running together > in a single PW. This would be indeed be mystifying. > > > > Finally, how do I know to expect this "double PW with a single > label"? > > > Is it signalled at setup ? > > > > > [Sasha] Yes, of course - but signaling is not discussed in > > the draft in question. > > If we do go this way I would suggest adding the appropriate > parameter specifying > 1) signaling substructure appended to data packet > 2) signaling substructure in separate packets with independent > sequencing > 3) signaling substructure in separate PW > to your control protocol extensions draft. > I will consider this option when I update the signaling draft; more comments on it are really welcome. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 13:58:29 +0300 Lines: 59 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Wed May 05 13:09:22 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQyg1mHbsY/GeULRnq9fCPjjGmYNgACcdPg To: "Sasha Vainshtein" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , ... the plot thickens ... =20 > [Sasha] Note also that the L2TPv3 L2-specific sublayer also=20 > does not skip zero (in addition to providing a 24-bit=20 > sequence number). =20 as does RTP and just about every other sequencing method. > [Sasha] I do not see it as a major architectural issue beyond=20 > the TDM. The difference between the TDM PWs and the rest of=20 > them wrt packet loss is essential: TDM PWs MUST compensate=20 > each lost packet, while non-TDM can, by default, simply drop=20 > mis-ordered packets. I would also glad to hear from Stewart=20 > and from the WG at large on this subject. The use of the zero sequence number is not the question. The use of multiple sequencing streams in a single PW is. > >=20 > > I had interpreted "in-band" to mean "over the same PSN", or=20 > > even "over thee same tunnel", not "over the same PW". > > > [Sasha] Unless things have changed drastically from the last=20 > time I looked at the TDMoIP draft, you use two types of=20 > packets - data and signaling - in the AAL2-based mode - over=20 > the same PW. Or did I miss something? No, you haven't missed anything.=20 The AAL2 method definitely has separate signaling subframes,=20 which can be (depending on implementation) placed into separate packets. Separate signaling packets share the SAME sequence number series. However, this is not critical as in your case as the subframes have their own sequencing (in the UUI field). A long time I had considered the option of using a separate sequencing method, but rejected it due to its not conforming with what I considered a general architectural principle (you will see in a moment why I consider this a fundamental question). That principle is that a PW carries a single flow. In particular: 1) a PW is either sequenced or not 2) when it is sequenced there is a single sequence per PW You are proposing multiple sequenced and unsequenced streams per PW. In other words, you are proposing a third level of flow: 1) A tunnel 2) PWs in the tunnel 3) flows in a PW Do we really want/need this third level? Are there separate set-up and maintenance entities for this third level? Do I need VCCV, performance parameters, etc for this new level? We have already basically turned the PW into a full-blown layer network. Taking over the job of a friend of ours :) I would like to ask whether we need to define yet another layer network inside this one? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 14:14:43 +0200 Lines: 113 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 05 13:25:15 2004 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov and all, Please see some more 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: Wednesday, May 05, 2004 12:58 PM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > ... the plot thickens ... > > > [Sasha] Note also that the L2TPv3 L2-specific sublayer also > > does not skip zero (in addition to providing a 24-bit > > sequence number). > > as does RTP and just about every other sequencing method. > [Sasha] L2TPv3 is used to carry, say FR over an IP PSN. This means that forthe same type of AC (FR), you have two different numbering methods: one for an MPLS PSN and another fo an IP PSN. So I agree with you that the plot thickens - but it leads further and further from the initial scope. > > > [Sasha] I do not see it as a major architectural issue beyond > > the TDM. The difference between the TDM PWs and the rest of > > them wrt packet loss is essential: TDM PWs MUST compensate > > each lost packet, while non-TDM can, by default, simply drop > > mis-ordered packets. I would also glad to hear from Stewart > > and from the WG at large on this subject. > > The use of the zero sequence number is not the question. > The use of multiple sequencing streams in a single PW is. > > > > > > > I had interpreted "in-band" to mean "over the same PSN", or > > > even "over thee same tunnel", not "over the same PW". > > > > > [Sasha] Unless things have changed drastically from the last > > time I looked at the TDMoIP draft, you use two types of > > packets - data and signaling - in the AAL2-based mode - over > > the same PW. Or did I miss something? > > No, you haven't missed anything. > The AAL2 method definitely has separate signaling subframes, > which can be (depending on implementation) placed into > separate packets. Separate signaling packets share the > SAME sequence number series. However, this is not critical > as in your case as the subframes have their own sequencing (in the UUI > field). > > A long time I had considered the option of using > a separate sequencing method, but rejected it due to its not > conforming > with what I considered a general architectural principle > (you will see in a moment why I consider this a fundamental question). > That principle is that a PW carries a single flow. > [Sasha] This very much depends on what you define as a flow. E.g., the "port mode" of FR PWs carries multiple DLCIs which could be called "flows" as well. The current architecture does not refer to any such notion, so, IMHO, everybody can presume what suits him/her best. > > In particular: > 1) a PW is either sequenced or not > 2) when it is sequenced there is a single sequence per PW > > You are proposing multiple sequenced and unsequenced streams per PW. > [Sasha] I agree with you that a PW can be either sequenced or not and I have tried to convince the FR draft editor to impose some such limitation. The current draft does not preclude a mix of sequences (i.e., with non-zero SN) and unsequenced (with zero SN) PW packets on the same FR PW which, IMHO, should be fixed. And, to the best of my understanding, I do NOT propose any UNSEQUENCED flows within a CESoPSN PW. > > In other words, you are proposing a third level of flow: > 1) A tunnel > 2) PWs in the tunnel > 3) flows in a PW > [Sasha] IMHO, this is goes far beyond my modest and very specific proposal. I am not sure that such a generalization is justified and definitely was not intended. Hence I find it difficult to answer your very generic questions below, BUT I believe I have answered some of them already (wrt setup) in the previous message. > > Do we really want/need this third level? > Are there separate set-up and maintenance entities for this > third level? > Do I need VCCV, performance parameters, etc for this new level? > > We have already basically turned the PW into a full-blown > layer network. > Taking over the job of a friend of ours :) I would like to ask > whether we need to define yet another layer network inside this one? > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 05 May 2004 09:48:47 -0600 Organization: Cisco Systems Lines: 174 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 05 18:23:14 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: Sasha Vainshtein In-Reply-To: X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha, Indeed there are differences in the drafts , regarding sequence numbers handling , and control words. This does not mean that it will be accepted by the IESG, and it does not mean we have free run of deigning even more different schemes. Definely we never meant to have different sequenced flows in the same PW. This is not part of the architecture. Please do not mistake merged flows within a PW with separate flows within the PW. For example when many ATM VCs are transported as one VP in a PW, they are one flow, as they separate VCs have been merged into a single flow in a PW. The point here is to create a standard that can re-use maybe part of the same hardware to transport different types of PWs. It seems to me that even the sequencing in the tdm drafts should conform to the rest of PWE3 designs. Note that I'm on vacation until monday , and desperately attempting to stay away from this computer ... ;-) Bye Luca Sasha Vainshtein wrote: >Yaakov and all, >Please see some more 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: Wednesday, May 05, 2004 12:58 PM >>To: Sasha Vainshtein >>Cc: stbryant@cisco.com; pwe3@ietf.org >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL >> >> >>... the plot thickens ... >> >> >> >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also >>>does not skip zero (in addition to providing a 24-bit >>>sequence number). >>> >>> >>as does RTP and just about every other sequencing method. >> >> >> >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. >This means that forthe same type of AC (FR), you have >two different numbering methods: one for an MPLS PSN and >another fo an IP PSN. So I agree with you that the plot >thickens - but it leads further and further from the >initial scope. > > >>>[Sasha] I do not see it as a major architectural issue beyond >>>the TDM. The difference between the TDM PWs and the rest of >>>them wrt packet loss is essential: TDM PWs MUST compensate >>>each lost packet, while non-TDM can, by default, simply drop >>>mis-ordered packets. I would also glad to hear from Stewart >>>and from the WG at large on this subject. >>> >>> >>The use of the zero sequence number is not the question. >>The use of multiple sequencing streams in a single PW is. >> >> >> >>>>I had interpreted "in-band" to mean "over the same PSN", or >>>>even "over thee same tunnel", not "over the same PW". >>>> >>>> >>>> >>>[Sasha] Unless things have changed drastically from the last >>>time I looked at the TDMoIP draft, you use two types of >>>packets - data and signaling - in the AAL2-based mode - over >>>the same PW. Or did I miss something? >>> >>> >>No, you haven't missed anything. >>The AAL2 method definitely has separate signaling subframes, >>which can be (depending on implementation) placed into >>separate packets. Separate signaling packets share the >>SAME sequence number series. However, this is not critical >>as in your case as the subframes have their own sequencing (in the UUI >>field). >> >>A long time I had considered the option of using >>a separate sequencing method, but rejected it due to its not >>conforming >>with what I considered a general architectural principle >>(you will see in a moment why I consider this a fundamental question). >>That principle is that a PW carries a single flow. >> >> >> >[Sasha] This very much depends on what you define as a flow. >E.g., the "port mode" of FR PWs carries multiple DLCIs which >could be called "flows" as well. >The current architecture does not refer to any such notion, >so, IMHO, everybody can presume what suits him/her best. > > >>In particular: >> 1) a PW is either sequenced or not >> 2) when it is sequenced there is a single sequence per PW >> >>You are proposing multiple sequenced and unsequenced streams per PW. >> >> >> >[Sasha] I agree with you that a PW can be either sequenced or not >and I have tried to convince the FR draft editor to impose >some such limitation. The current draft does not preclude a mix of >sequences (i.e., with non-zero SN) and unsequenced (with zero SN) >PW packets on the same FR PW which, IMHO, should be fixed. >And, to the best of my understanding, I do NOT propose any >UNSEQUENCED flows within a CESoPSN PW. > > >>In other words, you are proposing a third level of flow: >> 1) A tunnel >> 2) PWs in the tunnel >> 3) flows in a PW >> >> >> >[Sasha] IMHO, this is goes far beyond my modest and >very specific proposal. I am not sure that such a >generalization is justified and definitely was not >intended. Hence I find it difficult to answer your very >generic questions below, BUT I believe I have answered >some of them already (wrt setup) in the previous message. > > >>Do we really want/need this third level? >>Are there separate set-up and maintenance entities for this >>third level? >>Do I need VCCV, performance parameters, etc for this new level? >> >>We have already basically turned the PW into a full-blown >>layer network. >>Taking over the job of a friend of ours :) I would like to ask >>whether we need to define yet another layer network inside this one? >> >>Y(J)S >> >> >> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 19:09:52 +0200 Lines: 213 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 05 18:38:35 2004 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Luca and all, Please see a few words inline (do not want to keep you bound to the computer:-). 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: Luca Martini [mailto:lmartini@cisco.com] > Sent: Wednesday, May 05, 2004 5:49 PM > To: Sasha Vainshtein > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > Indeed there are differences in the drafts , regarding > sequence numbers > handling , and control words. > This does not mean that it will be accepted by the IESG, and > it does not > mean we have free run of deigning even more different schemes. > There is a reason for such a difference between TDM and non-TDM PWs: in case of TDM, you MUST compensate for each paylod byte that has been lost, while in case of non-TDM it is enough to discard mis-ordered packets (and sometimes you can skip even that). > > Definely we never meant to have different sequenced flows in the same > PW. This is not part of the architecture. > Please do not mistake merged flows within a PW with separate flows > within the PW. > For example when many ATM VCs are transported as one VP in a PW, they > are one flow, as they separate VCs have been merged into a > single flow > in a PW. > > The point here is to create a standard that can re-use maybe > part of the > same hardware to transport different types of PWs. It seems > to me that > even the sequencing in the tdm drafts should conform to the > rest of PWE3 > designs. > > Note that I'm on vacation until monday , and desperately > attempting to > stay away from this computer ... ;-) > > > Bye > Luca > > Sasha Vainshtein wrote: > > >Yaakov and all, > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > >>To: Sasha Vainshtein > >>Cc: stbryant@cisco.com; pwe3@ietf.org > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > >> > >> > >>... the plot thickens ... > >> > >> > >> > >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also > >>>does not skip zero (in addition to providing a 24-bit > >>>sequence number). > >>> > >>> > >>as does RTP and just about every other sequencing method. > >> > >> > >> > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > >This means that forthe same type of AC (FR), you have > >two different numbering methods: one for an MPLS PSN and > >another fo an IP PSN. So I agree with you that the plot > >thickens - but it leads further and further from the > >initial scope. > > > > > >>>[Sasha] I do not see it as a major architectural issue beyond > >>>the TDM. The difference between the TDM PWs and the rest of > >>>them wrt packet loss is essential: TDM PWs MUST compensate > >>>each lost packet, while non-TDM can, by default, simply drop > >>>mis-ordered packets. I would also glad to hear from Stewart > >>>and from the WG at large on this subject. > >>> > >>> > >>The use of the zero sequence number is not the question. > >>The use of multiple sequencing streams in a single PW is. > >> > >> > >> > >>>>I had interpreted "in-band" to mean "over the same PSN", or > >>>>even "over thee same tunnel", not "over the same PW". > >>>> > >>>> > >>>> > >>>[Sasha] Unless things have changed drastically from the last > >>>time I looked at the TDMoIP draft, you use two types of > >>>packets - data and signaling - in the AAL2-based mode - over > >>>the same PW. Or did I miss something? > >>> > >>> > >>No, you haven't missed anything. > >>The AAL2 method definitely has separate signaling subframes, > >>which can be (depending on implementation) placed into > >>separate packets. Separate signaling packets share the > >>SAME sequence number series. However, this is not critical > >>as in your case as the subframes have their own sequencing > (in the UUI > >>field). > >> > >>A long time I had considered the option of using > >>a separate sequencing method, but rejected it due to its not > >>conforming > >>with what I considered a general architectural principle > >>(you will see in a moment why I consider this a fundamental > question). > >>That principle is that a PW carries a single flow. > >> > >> > >> > >[Sasha] This very much depends on what you define as a flow. > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > >could be called "flows" as well. > >The current architecture does not refer to any such notion, > >so, IMHO, everybody can presume what suits him/her best. > > > > > >>In particular: > >> 1) a PW is either sequenced or not > >> 2) when it is sequenced there is a single sequence per PW > >> > >>You are proposing multiple sequenced and unsequenced streams per PW. > >> > >> > >> > >[Sasha] I agree with you that a PW can be either sequenced or not > >and I have tried to convince the FR draft editor to impose > >some such limitation. The current draft does not preclude a mix of > >sequences (i.e., with non-zero SN) and unsequenced (with zero SN) > >PW packets on the same FR PW which, IMHO, should be fixed. > >And, to the best of my understanding, I do NOT propose any > >UNSEQUENCED flows within a CESoPSN PW. > > > > > >>In other words, you are proposing a third level of flow: > >> 1) A tunnel > >> 2) PWs in the tunnel > >> 3) flows in a PW > >> > >> > >> > >[Sasha] IMHO, this is goes far beyond my modest and > >very specific proposal. I am not sure that such a > >generalization is justified and definitely was not > >intended. Hence I find it difficult to answer your very > >generic questions below, BUT I believe I have answered > >some of them already (wrt setup) in the previous message. > > > > > >>Do we really want/need this third level? > >>Are there separate set-up and maintenance entities for this > >>third level? > >>Do I need VCCV, performance parameters, etc for this new level? > >> > >>We have already basically turned the PW into a full-blown > >>layer network. > >>Taking over the job of a friend of ours :) I would like to ask > >>whether we need to define yet another layer network inside this one? > >> > >>Y(J)S > >> > >> > >> > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Thomas D. Nadeau" Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: 05 May 2004 09:32:09 -0400 Organization: Cisco Systems, Inc. Lines: 228 Sender: pwe3-admin@ietf.org References: Reply-To: tnadeau@cisco.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "'Luca Martini'" , "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 05 19:49:22 2004 Return-path: To: Sasha Vainshtein In-Reply-To: X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , On Wed, 2004-05-05 at 13:09, Sasha Vainshtein wrote: > Luca and all, > Please see a few words inline (do not want to > keep you bound to the computer:-). > > > > > 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: Luca Martini [mailto:lmartini@cisco.com] > > Sent: Wednesday, May 05, 2004 5:49 PM > > To: Sasha Vainshtein > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Sasha, > > > > Indeed there are differences in the drafts , regarding > > sequence numbers > > handling , and control words. > > This does not mean that it will be accepted by the IESG, and > > it does not > > mean we have free run of deigning even more different schemes. > > > There is a reason for such a difference between TDM and non-TDM PWs: > in case of TDM, you MUST compensate for each paylod byte that has been > lost, while in case of non-TDM it is enough to discard mis-ordered > packets (and sometimes you can skip even that). This still doesn't seem to justify the departure in methods. I agree with Luca in that we should try to have as few different ways of doing the same thing as possible. --Tom > > > > Definely we never meant to have different sequenced flows in the same > > PW. This is not part of the architecture. > > Please do not mistake merged flows within a PW with separate flows > > within the PW. > > For example when many ATM VCs are transported as one VP in a PW, they > > are one flow, as they separate VCs have been merged into a > > single flow > > in a PW. > > > > The point here is to create a standard that can re-use maybe > > part of the > > same hardware to transport different types of PWs. It seems > > to me that > > even the sequencing in the tdm drafts should conform to the > > rest of PWE3 > > designs. > > > > Note that I'm on vacation until monday , and desperately > > attempting to > > stay away from this computer ... ;-) > > > > > > Bye > > Luca > > > > Sasha Vainshtein wrote: > > > > >Yaakov and all, > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > >>To: Sasha Vainshtein > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > >> > > >> > > >>... the plot thickens ... > > >> > > >> > > >> > > >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also > > >>>does not skip zero (in addition to providing a 24-bit > > >>>sequence number). > > >>> > > >>> > > >>as does RTP and just about every other sequencing method. > > >> > > >> > > >> > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > >This means that forthe same type of AC (FR), you have > > >two different numbering methods: one for an MPLS PSN and > > >another fo an IP PSN. So I agree with you that the plot > > >thickens - but it leads further and further from the > > >initial scope. > > > > > > > > >>>[Sasha] I do not see it as a major architectural issue beyond > > >>>the TDM. The difference between the TDM PWs and the rest of > > >>>them wrt packet loss is essential: TDM PWs MUST compensate > > >>>each lost packet, while non-TDM can, by default, simply drop > > >>>mis-ordered packets. I would also glad to hear from Stewart > > >>>and from the WG at large on this subject. > > >>> > > >>> > > >>The use of the zero sequence number is not the question. > > >>The use of multiple sequencing streams in a single PW is. > > >> > > >> > > >> > > >>>>I had interpreted "in-band" to mean "over the same PSN", or > > >>>>even "over thee same tunnel", not "over the same PW". > > >>>> > > >>>> > > >>>> > > >>>[Sasha] Unless things have changed drastically from the last > > >>>time I looked at the TDMoIP draft, you use two types of > > >>>packets - data and signaling - in the AAL2-based mode - over > > >>>the same PW. Or did I miss something? > > >>> > > >>> > > >>No, you haven't missed anything. > > >>The AAL2 method definitely has separate signaling subframes, > > >>which can be (depending on implementation) placed into > > >>separate packets. Separate signaling packets share the > > >>SAME sequence number series. However, this is not critical > > >>as in your case as the subframes have their own sequencing > > (in the UUI > > >>field). > > >> > > >>A long time I had considered the option of using > > >>a separate sequencing method, but rejected it due to its not > > >>conforming > > >>with what I considered a general architectural principle > > >>(you will see in a moment why I consider this a fundamental > > question). > > >>That principle is that a PW carries a single flow. > > >> > > >> > > >> > > >[Sasha] This very much depends on what you define as a flow. > > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > > >could be called "flows" as well. > > >The current architecture does not refer to any such notion, > > >so, IMHO, everybody can presume what suits him/her best. > > > > > > > > >>In particular: > > >> 1) a PW is either sequenced or not > > >> 2) when it is sequenced there is a single sequence per PW > > >> > > >>You are proposing multiple sequenced and unsequenced streams per PW. > > >> > > >> > > >> > > >[Sasha] I agree with you that a PW can be either sequenced or not > > >and I have tried to convince the FR draft editor to impose > > >some such limitation. The current draft does not preclude a mix of > > >sequences (i.e., with non-zero SN) and unsequenced (with zero SN) > > >PW packets on the same FR PW which, IMHO, should be fixed. > > >And, to the best of my understanding, I do NOT propose any > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > >>In other words, you are proposing a third level of flow: > > >> 1) A tunnel > > >> 2) PWs in the tunnel > > >> 3) flows in a PW > > >> > > >> > > >> > > >[Sasha] IMHO, this is goes far beyond my modest and > > >very specific proposal. I am not sure that such a > > >generalization is justified and definitely was not > > >intended. Hence I find it difficult to answer your very > > >generic questions below, BUT I believe I have answered > > >some of them already (wrt setup) in the previous message. > > > > > > > > >>Do we really want/need this third level? > > >>Are there separate set-up and maintenance entities for this > > >>third level? > > >>Do I need VCCV, performance parameters, etc for this new level? > > >> > > >>We have already basically turned the PW into a full-blown > > >>layer network. > > >>Taking over the job of a friend of ours :) I would like to ask > > >>whether we need to define yet another layer network inside this one? > > >> > > >>Y(J)S > > >> > > >> > > >> > > > > > >_______________________________________________ > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Nick Weeds Subject: RE: Generalized PWID FEC and the question of the Group ID Date: Wed, 5 May 2004 19:09:17 +0100 Lines: 312 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Wed May 05 20:31:19 2004 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Thanks Luca. My main concern is to ensure that the AGI, SAII and TAII can be identified clearly and distinguished from interface parameters. The GR ID might complicate that, especially if it is optional. If the GR ID isn't at the start of the FEC then describing the general case is awkward, but we have two cases (full FEC or wildcard) that are easily described separately. I guess they appear as follows (possibly with 32 bit GR ID values instead of 16 bit values): Full FEC: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 |C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI ID | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII ID | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII ID | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID=0 | Length=4 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Interface Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here the AGI, SAII and TAII are required, MUST be the first three elements, and MUST be in the order shown above. The IDs of the AGI, SAII and TAII are assigned from a distinct space separate from interface parameters. They MUST NOT be assigned ID=0. Either the GR ID is mandatory and MUST be the 4th element or it is distinguished from interface parameters by ID=0. Wildcard: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 |C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID=0 | Length=4 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here the AGI, SAII and TAII MUST be omitted. Also the interface parameters SHOULD be omitted. Ideally PW Info Length = 4 so that FEC element length = (4 + PW Info Length) as before. Using PW Info Length = 0 would make FEC element length determination more complicated so it would be worth careful explanation. Nick. > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: 03 May 2004 20:35 > To: Nick Weeds > Subject: Re: [PWE3] Generalized PWID FEC and the question of the Group > ID > > > > > Nick Weeds wrote: > > >Luca, > > > >A few thoughts... > > > >(1) Is the GR ID implementing essentially the same function > as the Group ID > >in the PWid FEC? If so then it would be helpful to make the > definitions as > >close as possible. > > > > > > > yes. > > >(2) You suggest a 16-bit value, perhaps so that the entire > 00 04 XX XX > >encoding fits into 32 bits. A 32-bit value might be > preferred to match the > >Group ID. Either way, best use a fixed-length value not > exceeding 32 bits. > >I hope that's consistent with your observation that "we can > make [it]bigger > >if needed". > > > > > > > yes , I can make it 32 bits , the only issues I see is the word > alignment , but that is not much of an issue. > > >(3) It would be simpler to make the GR ID mandatory in all > messages (like > >the Group ID). > >- Mandatory GR ID, AGI, SAII and TAII make it easy to > identify these 4 > >fields. Making them optional makes it harder to distinguish > them from > >interface parameters. > >- Mandatory GR ID avoids the need for special procedures in > case the GR ID > >is omitted or not supported. > > > > > > > ok, you are the second person to suggest this. I am not opposed to > making it mandatory. > > >(4) If the GR ID is mandatory, could we use the same format > as the PWid FEC > >for the first 8 bytes, followed by the AGI, SAII, TAII etc. ? > > > > > > > that , Eric has a problem with. He does not want the Gr ID in > the FEC. > To accommodate this the GR ID needs to be last, and only used in the > wild card withdraw status messages. > > >(5) Does the PW Info Length include the GR ID? If so it > might be helpful to > >require this in all cases, rather than use PW Info Length = > 0 to indicate > >"Only GR ID present". Or do you intend the PW Info Length > to exclude the GR > >ID (like the Group ID in the PWid FEC)? > > > > > > > no. Here the GR ID is identified by a type == 0, SO in theory > we don't > even need to set the length to 0. > I'm open to suggestions on this point. > > >(6) Is the Label Release "GR ID not supported" needed? Or could the > >receiver just ignore the GR ID? Obviously the receiver wouldn't use > >wildcard label withdraw or wildcard PW status notifications, but that > >wouldn't matter to the downstream node. Am I missing something? > > > > > > > yes, the transmitter is the PE that will issue a wild card PW status > notification, hence if the receiver of the gr ID ingnores it > , it will > not be able to process the wild card status/withdraw > messages correctly. > > >Thanks, > > > > Nick. > > > > > > > Please CC the PWE3 list if you don't mind with the next > response. This > way we show some interest and support for this. > > Thanks. > Luca > > >>-----Original Message----- > >>From: Luca Martini [mailto:lmartini@cisco.com] > >>Sent: 27 April 2004 23:04 > >>To: pwe3@ietf.org > >>Subject: [PWE3] Generalized PWID FEC and the question of > the Group ID > >> > >> > >>Hello! > >> > >>It has been pointed out that the GPW FEC design was somewhat > >>inconsistent with the other PWId design in the control draft. > >>I have fixed several issues related to length fields, and > >>clarified the > >>label with draw procedures. The only thing that remains is > the GR ID > >>functionality. > >>This was initially suggested at a diner/meeting at the San > >>Diego IETF. > >>The idea is that if there are large amounts of PWs > originating on a > >>port , with a few dozen different destinations it would be > >>much faster > >>to send a few dozen withdraw ( or status messages ) instead > >>of thousands > >>individual PW withdraw , or PW status messages. > >>We left the association of GR IDs open to implementors, as > it is not > >>relevant for protocol compatibility. > >> > >>This time around, I would like to keep the same functionality, but > >>remove the GR ID from the FEC if possible. > >> > >>So I propose the following: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>| 129 |C| PW Type |PW info Length | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>| Group ID=0 | Length=4 | Value | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>| AGI | Length | Value | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>~ Value (contd.) ~ > >>| | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>| SAII | Length | Value | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>~ Value (contd.) ~ > >>| | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>| TAII | Length | Value | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>~ Value (contd.) ~ > >>| | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>| | > >>| Interface Parameters | > >>| | > >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >>To identify the GR ID we set the type to the reserved type of 0 ... > >>the length is set to 4 to specify a 16 bit value , but we can > >>make that > >>bigger if needed. ( however I cannot think of an application > >>requiring > >>more then 16 bit of locally defined groups ) > >> > >>the semantics would remain similar with the following exception: > >> > >>The GR ID is not part of the FEC, is OPTIONAL, and will not be > >>advertised except in the initial PW FEC advertisement. > >>If the GR ID is advertised , then the advertising PE can > use the wild > >>card withdraw semantics, and the if the remote PEs accepts > the FEC it > >>MUST implement this. > >>If a PE chooses not to implement the GR ID, and it receives an > >>advertisement containing one, a Label Release MUST be sent, > >>with an "GR > >>ID not Supported" status code. In this case, the PW will not be > >>enabled. ( the PE is free to advertise a new PW FEC without > >>the GR ID, > >>but that is a matter of local configuration policy ) > >> > >>0x00000029 "GR ID not Supported" > >> > >>To issue a wild card command ( status/or withdraw ): > >>Set the PW Info Length to 0 , and send only the GR ID in the > >>FEC. ( we > >>could also make this be the correct length, since we can > >>recognize the > >>GR ID , by the code point = 0 ) > >> > >>One other option is to make this mandatory, in a similar way > >>as with FEC > >>128. > >> > >>Of course we will need to reissue a last call for this > >>section as well > >>as the status TLV section. > >> > >>Comments ? > >> > >>Thanks. > >>Luca > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> > >> > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Shahram Davari Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 11:21:48 -0700 Lines: 218 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 05 20:48:02 2004 Return-path: To: "'Luca Martini'" , Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi Sasha, I also share the concern that Yaakov and Luca expressed regarding the CAS packets multiplexed in the same PW. This would require 2 seq number tracking per PW. I also have another concern, but before I elaborate on that I would like to mention that in structured emulation, the network MUST generate Trunk conditioning as specified in Bellcore TR-NWT-000170, rather than AIS/RDI. Now my concern: Based on Table 1: The Interpretation of bits L and M in the CESoPSN CW, it appears that L=1& M=00 may or may not generate AIS/Truck conditioning at the far end, depending on the configuration. In order to reduce the amount of configuration, I suggest using L=1& M=00, only when your payload is omitted and you want AIS/Truck Conditioning generated at the far end. And use another code point such as L=1 & M=01 to indicate a valid payload, which doesn't need AIS/Trunk conditioning to be generated at the far-end. Similarly for L=0 & M=10, you may want to have another codepoint such as L=0 & M=01 if you want RDI/Trunk conditioning be generated, while using L=0 &M=10 for the case that you don't want to generate RDI/Trunk conditioning. In any case we have to make sure that the interpretation of these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413. Yours, -Shahram > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Wednesday, May 05, 2004 11:49 AM > To: Sasha Vainshtein > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > Indeed there are differences in the drafts , regarding > sequence numbers > handling , and control words. > This does not mean that it will be accepted by the IESG, and > it does not > mean we have free run of deigning even more different schemes. > > Definely we never meant to have different sequenced flows in the same > PW. This is not part of the architecture. > Please do not mistake merged flows within a PW with separate flows > within the PW. > For example when many ATM VCs are transported as one VP in a PW, they > are one flow, as they separate VCs have been merged into a > single flow > in a PW. > > The point here is to create a standard that can re-use maybe > part of the > same hardware to transport different types of PWs. It seems > to me that > even the sequencing in the tdm drafts should conform to the > rest of PWE3 > designs. > > Note that I'm on vacation until monday , and desperately > attempting to > stay away from this computer ... ;-) > > > Bye > Luca > > Sasha Vainshtein wrote: > > >Yaakov and all, > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > >>To: Sasha Vainshtein > >>Cc: stbryant@cisco.com; pwe3@ietf.org > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > >> > >> > >>... the plot thickens ... > >> > >> > >> > >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also > >>>does not skip zero (in addition to providing a 24-bit > >>>sequence number). > >>> > >>> > >>as does RTP and just about every other sequencing method. > >> > >> > >> > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > >This means that forthe same type of AC (FR), you have > >two different numbering methods: one for an MPLS PSN and > >another fo an IP PSN. So I agree with you that the plot > >thickens - but it leads further and further from the > >initial scope. > > > > > >>>[Sasha] I do not see it as a major architectural issue beyond > >>>the TDM. The difference between the TDM PWs and the rest of > >>>them wrt packet loss is essential: TDM PWs MUST compensate > >>>each lost packet, while non-TDM can, by default, simply drop > >>>mis-ordered packets. I would also glad to hear from Stewart > >>>and from the WG at large on this subject. > >>> > >>> > >>The use of the zero sequence number is not the question. > >>The use of multiple sequencing streams in a single PW is. > >> > >> > >> > >>>>I had interpreted "in-band" to mean "over the same PSN", or > >>>>even "over thee same tunnel", not "over the same PW". > >>>> > >>>> > >>>> > >>>[Sasha] Unless things have changed drastically from the last > >>>time I looked at the TDMoIP draft, you use two types of > >>>packets - data and signaling - in the AAL2-based mode - over > >>>the same PW. Or did I miss something? > >>> > >>> > >>No, you haven't missed anything. > >>The AAL2 method definitely has separate signaling subframes, > >>which can be (depending on implementation) placed into > >>separate packets. Separate signaling packets share the > >>SAME sequence number series. However, this is not critical > >>as in your case as the subframes have their own sequencing > (in the UUI > >>field). > >> > >>A long time I had considered the option of using > >>a separate sequencing method, but rejected it due to its not > >>conforming > >>with what I considered a general architectural principle > >>(you will see in a moment why I consider this a fundamental > question). > >>That principle is that a PW carries a single flow. > >> > >> > >> > >[Sasha] This very much depends on what you define as a flow. > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > >could be called "flows" as well. > >The current architecture does not refer to any such notion, > >so, IMHO, everybody can presume what suits him/her best. > > > > > >>In particular: > >> 1) a PW is either sequenced or not > >> 2) when it is sequenced there is a single sequence per PW > >> > >>You are proposing multiple sequenced and unsequenced streams per PW. > >> > >> > >> > >[Sasha] I agree with you that a PW can be either sequenced or not > >and I have tried to convince the FR draft editor to impose > >some such limitation. The current draft does not preclude a mix of > >sequences (i.e., with non-zero SN) and unsequenced (with zero SN) > >PW packets on the same FR PW which, IMHO, should be fixed. > >And, to the best of my understanding, I do NOT propose any > >UNSEQUENCED flows within a CESoPSN PW. > > > > > >>In other words, you are proposing a third level of flow: > >> 1) A tunnel > >> 2) PWs in the tunnel > >> 3) flows in a PW > >> > >> > >> > >[Sasha] IMHO, this is goes far beyond my modest and > >very specific proposal. I am not sure that such a > >generalization is justified and definitely was not > >intended. Hence I find it difficult to answer your very > >generic questions below, BUT I believe I have answered > >some of them already (wrt setup) in the previous message. > > > > > >>Do we really want/need this third level? > >>Are there separate set-up and maintenance entities for this > >>third level? > >>Do I need VCCV, performance parameters, etc for this new level? > >> > >>We have already basically turned the PW into a full-blown > >>layer network. > >>Taking over the job of a friend of ours :) I would like to ask > >>whether we need to define yet another layer network inside this one? > >> > >>Y(J)S > >> > >> > >> > > > >_______________________________________________ > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Wed, 5 May 2004 20:50:55 +0100 Lines: 261 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , , X-From: pwe3-admin@ietf.org Wed May 05 22:04:24 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQy0Ycv6T+fOo/yT9K43JNgQL344wAB9KWw To: , , X-OriginalArrivalTime: 05 May 2004 19:50:56.0263 (UTC) FILETIME=[47D53170:01C432DA] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Further point... If there are 2 independent Seq No streams then it seems to me you will = require 2 independent Seq No aberration tests (which essentially means = that defect entry/exit criteria need defining for these). The = consequent actions however might not be independent. regards, Neil=20 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Shahram Davari > Sent: 05 May 2004 19:22 > To: 'Luca Martini'; Sasha Vainshtein > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL >=20 >=20 > Hi Sasha, >=20 > I also share the concern that Yaakov and Luca expressed regarding > the CAS packets multiplexed in the same PW. This would require 2 seq > number tracking per PW. >=20 > I also have another concern, but before I elaborate on that I=20 > would like to mention that in structured emulation, the=20 > network MUST generate Trunk conditioning as specified in=20 > Bellcore TR-NWT-000170, rather than AIS/RDI.=20 >=20 > Now my concern: Based on Table 1: The Interpretation of bits=20 > L and M in the CESoPSN CW, it appears that L=3D1& M=3D00 may or=20 > may not generate AIS/Truck conditioning at the far end,=20 > depending on the configuration. In order to reduce the amount=20 > of configuration, I suggest using L=3D1& M=3D00, only when your=20 > payload is omitted and you want AIS/Truck Conditioning=20 > generated at the far end. And use another code point such as=20 > L=3D1 & M=3D01 to indicate a valid payload, which doesn't need=20 > AIS/Trunk conditioning to be generated at the far-end. >=20 > Similarly for L=3D0 & M=3D10, you may want to have another=20 > codepoint such as L=3D0 & M=3D01 if > you want RDI/Trunk conditioning be generated, while using L=3D0=20 > &M=3D10 for the case that you don't want to generate RDI/Trunk=20 > conditioning. >=20 > In any case we have to make sure that the interpretation of=20 > these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413. >=20 > Yours, > -Shahram >=20 > =20 >=20 > > -----Original Message----- > > From: Luca Martini [mailto:lmartini@cisco.com] > > Sent: Wednesday, May 05, 2004 11:49 AM > > To: Sasha Vainshtein > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > >=20 > >=20 > > Sasha, > >=20 > > Indeed there are differences in the drafts , regarding=20 > > sequence numbers=20 > > handling , and control words. > > This does not mean that it will be accepted by the IESG, and=20 > > it does not=20 > > mean we have free run of deigning even more different schemes. > >=20 > > Definely we never meant to have different sequenced flows=20 > in the same=20 > > PW. This is not part of the architecture. > > Please do not mistake merged flows within a PW with separate flows=20 > > within the PW. > > For example when many ATM VCs are transported as one VP in=20 > a PW, they=20 > > are one flow, as they separate VCs have been merged into a=20 > > single flow=20 > > in a PW. > >=20 > > The point here is to create a standard that can re-use maybe=20 > > part of the=20 > > same hardware to transport different types of PWs. It seems=20 > > to me that=20 > > even the sequencing in the tdm drafts should conform to the=20 > > rest of PWE3=20 > > designs. > >=20 > > Note that I'm on vacation until monday , and desperately=20 > > attempting to=20 > > stay away from this computer ... ;-) > >=20 > >=20 > > Bye > > Luca > >=20 > > Sasha Vainshtein wrote: > >=20 > > >Yaakov and all, > > >Please see some more below. > > > > > >With best regards, > > > Sasha Vainshtein > > >email: sasha@axerra.com =20 > > >tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > > >=20 > > > > > > > > > =20 > > > > > >>-----Original Message----- > > >>From: Yaakov Stein [mailto:yaakov_s@rad.com] > > >>Sent: Wednesday, May 05, 2004 12:58 PM > > >>To: Sasha Vainshtein > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > >> > > >> > > >>... the plot thickens ... > > >>=20 > > >> =20 > > >> > > >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also=20 > > >>>does not skip zero (in addition to providing a 24-bit=20 > > >>>sequence number). =20 > > >>> =20 > > >>> > > >>as does RTP and just about every other sequencing method. > > >> > > >> =20 > > >> > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > >This means that forthe same type of AC (FR), you have > > >two different numbering methods: one for an MPLS PSN and=20 > > >another fo an IP PSN. So I agree with you that the plot > > >thickens - but it leads further and further from the > > >initial scope. > > > =20 > > > > > >>>[Sasha] I do not see it as a major architectural issue beyond=20 > > >>>the TDM. The difference between the TDM PWs and the rest of=20 > > >>>them wrt packet loss is essential: TDM PWs MUST compensate=20 > > >>>each lost packet, while non-TDM can, by default, simply drop=20 > > >>>mis-ordered packets. I would also glad to hear from Stewart=20 > > >>>and from the WG at large on this subject. > > >>> =20 > > >>> > > >>The use of the zero sequence number is not the question. > > >>The use of multiple sequencing streams in a single PW is. > > >> > > >> =20 > > >> > > >>>>I had interpreted "in-band" to mean "over the same PSN", or=20 > > >>>>even "over thee same tunnel", not "over the same PW". > > >>>> > > >>>> =20 > > >>>> > > >>>[Sasha] Unless things have changed drastically from the last=20 > > >>>time I looked at the TDMoIP draft, you use two types of=20 > > >>>packets - data and signaling - in the AAL2-based mode - over=20 > > >>>the same PW. Or did I miss something? > > >>> =20 > > >>> > > >>No, you haven't missed anything.=20 > > >>The AAL2 method definitely has separate signaling subframes,=20 > > >>which can be (depending on implementation) placed into > > >>separate packets. Separate signaling packets share the > > >>SAME sequence number series. However, this is not critical > > >>as in your case as the subframes have their own sequencing=20 > > (in the UUI > > >>field). > > >> > > >>A long time I had considered the option of using > > >>a separate sequencing method, but rejected it due to its not=20 > > >>conforming > > >>with what I considered a general architectural principle > > >>(you will see in a moment why I consider this a fundamental=20 > > question). > > >>That principle is that a PW carries a single flow. > > >> > > >> =20 > > >> > > >[Sasha] This very much depends on what you define as a flow. > > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > > >could be called "flows" as well. > > >The current architecture does not refer to any such notion, > > >so, IMHO, everybody can presume what suits him/her best. > > > =20 > > > > > >>In particular: > > >> 1) a PW is either sequenced or not > > >> 2) when it is sequenced there is a single sequence per PW > > >> > > >>You are proposing multiple sequenced and unsequenced=20 > streams per PW. > > >> > > >> =20 > > >> > > >[Sasha] I agree with you that a PW can be either sequenced or not > > >and I have tried to convince the FR draft editor to impose=20 > > >some such limitation. The current draft does not preclude a mix of > > >sequences (i.e., with non-zero SN) and unsequenced (with zero SN) > > >PW packets on the same FR PW which, IMHO, should be fixed. > > >And, to the best of my understanding, I do NOT propose any=20 > > >UNSEQUENCED flows within a CESoPSN PW. > > > =20 > > > > > >>In other words, you are proposing a third level of flow: > > >> 1) A tunnel > > >> 2) PWs in the tunnel > > >> 3) flows in a PW > > >> > > >> =20 > > >> > > >[Sasha] IMHO, this is goes far beyond my modest and > > >very specific proposal. I am not sure that such a > > >generalization is justified and definitely was not > > >intended. Hence I find it difficult to answer your very > > >generic questions below, BUT I believe I have answered > > >some of them already (wrt setup) in the previous message. > > > =20 > > > > > >>Do we really want/need this third level? > > >>Are there separate set-up and maintenance entities for this=20 > > >>third level? > > >>Do I need VCCV, performance parameters, etc for this new level? > > >> > > >>We have already basically turned the PW into a full-blown=20 > > >>layer network. > > >>Taking over the job of a friend of ours :) I would like to ask > > >>whether we need to define yet another layer network=20 > inside this one? > > >> > > >>Y(J)S > > >> > > >> =20 > > >> > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > =20 > > > > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 11:37:17 +0200 Lines: 279 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Thu May 06 10:53:50 2004 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Shahram and all, I'd like to point out that the draft explicitly states the need for an appropriate NSP in order to provide structured TDM services. IMO, the Trunk Conditioning functionality you have mentioned is a "native TDM" function and hence should be performed by the NSP which would then act not just as a Framer but as a Digital Cross-Connect (DXC) system. I also do not think that using additional codepoints can reduce the need of configuration (which seems to be one of your concerns). E.g., the decision to generate or not to generate AIS towards the local CE cannot, IMO, be based solely on indications received by the CE-bound IWF instance. E.g., please consider the case where several groups of timeslots on the same TDM trunk act as ACs for different IWF instances while "far ends" of the corresponding CESoPSN PWs use ACs that originate in different trunks. Killing the entire "near end" trunk with AIS just because AIS has been observed on one of the "far end" trunks would hardly be the best possible solution. On the other hand, making each "far end IWF" aware of the fatc that its peer shares (or does not share) the trunk with other IWF instances does not look a good solution either. 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 05, 2004 8:22 PM > To: 'Luca Martini'; Sasha Vainshtein > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Hi Sasha, > > I also share the concern that Yaakov and Luca expressed regarding > the CAS packets multiplexed in the same PW. This would require 2 seq > number tracking per PW. > > I also have another concern, but before I elaborate on that I > would like to mention that in structured emulation, the > network MUST generate Trunk conditioning as specified in > Bellcore TR-NWT-000170, rather than AIS/RDI. > > Now my concern: Based on Table 1: The Interpretation of bits > L and M in the CESoPSN CW, it appears that L=1& M=00 may or > may not generate AIS/Truck conditioning at the far end, > depending on the configuration. In order to reduce the amount > of configuration, I suggest using L=1& M=00, only when your > payload is omitted and you want AIS/Truck Conditioning > generated at the far end. And use another code point such as > L=1 & M=01 to indicate a valid payload, which doesn't need > AIS/Trunk conditioning to be generated at the far-end. > > Similarly for L=0 & M=10, you may want to have another > codepoint such as L=0 & M=01 if > you want RDI/Trunk conditioning be generated, while using L=0 > &M=10 for the case that you don't want to generate RDI/Trunk > conditioning. > > In any case we have to make sure that the interpretation of > these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413. > > Yours, > -Shahram > > > > > -----Original Message----- > > From: Luca Martini [mailto:lmartini@cisco.com] > > Sent: Wednesday, May 05, 2004 11:49 AM > > To: Sasha Vainshtein > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Sasha, > > > > Indeed there are differences in the drafts , regarding > > sequence numbers > > handling , and control words. > > This does not mean that it will be accepted by the IESG, and > > it does not > > mean we have free run of deigning even more different schemes. > > > > Definely we never meant to have different sequenced flows > in the same > > PW. This is not part of the architecture. > > Please do not mistake merged flows within a PW with separate flows > > within the PW. > > For example when many ATM VCs are transported as one VP in > a PW, they > > are one flow, as they separate VCs have been merged into a > > single flow > > in a PW. > > > > The point here is to create a standard that can re-use maybe > > part of the > > same hardware to transport different types of PWs. It seems > > to me that > > even the sequencing in the tdm drafts should conform to the > > rest of PWE3 > > designs. > > > > Note that I'm on vacation until monday , and desperately > > attempting to > > stay away from this computer ... ;-) > > > > > > Bye > > Luca > > > > Sasha Vainshtein wrote: > > > > >Yaakov and all, > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > >>To: Sasha Vainshtein > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > >> > > >> > > >>... the plot thickens ... > > >> > > >> > > >> > > >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also > > >>>does not skip zero (in addition to providing a 24-bit > > >>>sequence number). > > >>> > > >>> > > >>as does RTP and just about every other sequencing method. > > >> > > >> > > >> > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > >This means that forthe same type of AC (FR), you have > > >two different numbering methods: one for an MPLS PSN and > > >another fo an IP PSN. So I agree with you that the plot > > >thickens - but it leads further and further from the > > >initial scope. > > > > > > > > >>>[Sasha] I do not see it as a major architectural issue beyond > > >>>the TDM. The difference between the TDM PWs and the rest of > > >>>them wrt packet loss is essential: TDM PWs MUST compensate > > >>>each lost packet, while non-TDM can, by default, simply drop > > >>>mis-ordered packets. I would also glad to hear from Stewart > > >>>and from the WG at large on this subject. > > >>> > > >>> > > >>The use of the zero sequence number is not the question. > > >>The use of multiple sequencing streams in a single PW is. > > >> > > >> > > >> > > >>>>I had interpreted "in-band" to mean "over the same PSN", or > > >>>>even "over thee same tunnel", not "over the same PW". > > >>>> > > >>>> > > >>>> > > >>>[Sasha] Unless things have changed drastically from the last > > >>>time I looked at the TDMoIP draft, you use two types of > > >>>packets - data and signaling - in the AAL2-based mode - over > > >>>the same PW. Or did I miss something? > > >>> > > >>> > > >>No, you haven't missed anything. > > >>The AAL2 method definitely has separate signaling subframes, > > >>which can be (depending on implementation) placed into > > >>separate packets. Separate signaling packets share the > > >>SAME sequence number series. However, this is not critical > > >>as in your case as the subframes have their own sequencing > > (in the UUI > > >>field). > > >> > > >>A long time I had considered the option of using > > >>a separate sequencing method, but rejected it due to its not > > >>conforming > > >>with what I considered a general architectural principle > > >>(you will see in a moment why I consider this a fundamental > > question). > > >>That principle is that a PW carries a single flow. > > >> > > >> > > >> > > >[Sasha] This very much depends on what you define as a flow. > > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > > >could be called "flows" as well. > > >The current architecture does not refer to any such notion, > > >so, IMHO, everybody can presume what suits him/her best. > > > > > > > > >>In particular: > > >> 1) a PW is either sequenced or not > > >> 2) when it is sequenced there is a single sequence per PW > > >> > > >>You are proposing multiple sequenced and unsequenced > streams per PW. > > >> > > >> > > >> > > >[Sasha] I agree with you that a PW can be either sequenced or not > > >and I have tried to convince the FR draft editor to impose > > >some such limitation. The current draft does not preclude a mix of > > >sequences (i.e., with non-zero SN) and unsequenced (with zero SN) > > >PW packets on the same FR PW which, IMHO, should be fixed. > > >And, to the best of my understanding, I do NOT propose any > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > >>In other words, you are proposing a third level of flow: > > >> 1) A tunnel > > >> 2) PWs in the tunnel > > >> 3) flows in a PW > > >> > > >> > > >> > > >[Sasha] IMHO, this is goes far beyond my modest and > > >very specific proposal. I am not sure that such a > > >generalization is justified and definitely was not > > >intended. Hence I find it difficult to answer your very > > >generic questions below, BUT I believe I have answered > > >some of them already (wrt setup) in the previous message. > > > > > > > > >>Do we really want/need this third level? > > >>Are there separate set-up and maintenance entities for this > > >>third level? > > >>Do I need VCCV, performance parameters, etc for this new level? > > >> > > >>We have already basically turned the PW into a full-blown > > >>layer network. > > >>Taking over the job of a friend of ours :) I would like to ask > > >>whether we need to define yet another layer network > inside this one? > > >> > > >>Y(J)S > > >> > > >> > > >> > > > > > >_______________________________________________ > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 11:58:49 +0300 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Thu May 06 11:08:26 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQyu8o7W4mRwn06Q8uxlUKOtMYE6AAi+VdQ To: "Sasha Vainshtein" , "Luca Martini" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , =20 Luca/Sasha,=20 My feeling is that we need as much similarlity as possible between the difference service emulations. The sequence number skipping zero issue seems to me to be "mostly harmless", as we don't need to indication that a TDM packet is not carrying a sequence number, as all packets are sequenced. I am more concerned with the concept of multiple sequenced flows inside a PW. This seems to me to verge on the dangerous, and I would like to avoid it if possible. As far as I see there ARE other alternatives to handle the signaling substructure, including the original technique of appending it to a data packet. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 12:12:21 +0200 Lines: 67 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 06 11:24:38 2004 Return-path: To: "'Yaakov Stein'" , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov and Luca, Carrying of singnaling info in separate packets has, IMO, a certain advantage since it allows to use the same data plane mechanisms for services with and without signaling. Another advantage is trunk independence (i.e., ability to pass signaling between bundles of timeslots originating, say in E1 and T1/ESF trunks). This functionality CANNOT be achieved by appending signaling structures to the data. Please note also that the draft treats transport of signaling information in separate packets as OPTIONAL (indeed, the word must be capitalized in accordance with 2119 - will fix after the LC). Hence the implementors that think that this behavior is dangerous, are free not to implement it and to use other available methods. Carrying signaling info in a separate PW solves the problem of two sequencing flows in the same PW BUT introduces some new ones stemming from interdependency of the two PWs. E.g., the setup mechanism must provide for ability to associate the data PW with its paired signaling PW, both must be torn down together etc. So I'd say that this proposal fully complies with RFC 1925 (item 6). 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: Thursday, May 06, 2004 10:59 AM > To: Sasha Vainshtein; Luca Martini > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > Luca/Sasha, > > My feeling is that we need as much similarlity as possible > between the difference service emulations. > > The sequence number skipping zero issue seems to me > to be "mostly harmless", as we don't need to indication > that a TDM packet is not carrying a sequence number, > as all packets are sequenced. > > I am more concerned with the concept of multiple sequenced flows > inside a PW. This seems to me to verge on the dangerous, > and I would like to avoid it if possible. > > As far as I see there ARE other alternatives to handle > the signaling substructure, including the original technique > of appending it to a data packet. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 12:32:17 +0300 Lines: 108 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Thu May 06 11:55:08 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQzSnCA3Z42c1RHT/uUfOCzTmGmtwAAT3VA To: "Sasha Vainshtein" , "Luca Martini" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha,=20 I find your quoting of 1925 apt -=20 you are moving the problem to a different part of the network,=20 in fact you are creating a new network layer! Regarding the optionality, I am not sure that even optional features should be allowed to create new network layers. I don't understand your explanation of trunk independence. In the unlikely case of having E1 and T1 trunks converging on one IWF (apparently situated on the border between North America and Europe), the are two consistent options: 1) add a NSF that multiplexes them taking timing into account (we don't want to recreate PDH functionality in the PW), 2) open two PWs, one for the E1 and one for the T1. These E1 and T1 trunks will have different timing sources and MUST NOT be mixed into a single PW. In addition, as you mention, they have different (multiframe) structure sizes, and thus SHOULD NOT be placed into a single PW. Due to the last point, if you indeed intend to use separate signaling packets, I guess you would use one for the E1 and one for the T1, resulting in three separately sequenced flows in the PW.=20 Y(J)S > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 > Sent: Thursday, May 06, 2004 13:12 > To: Yaakov Stein; Luca Martini > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL >=20 > Yaakov and Luca, > Carrying of singnaling info in separate packets has, IMO, a=20 > certain advantage since it allows to use the same data plane=20 > mechanisms for services with and without signaling. >=20 >=20 > Another advantage is trunk independence (i.e., ability to=20 > pass signaling between bundles of timeslots originating, say=20 > in E1 and T1/ESF trunks). This functionality CANNOT be=20 > achieved by appending signaling structures to the data.=20 >=20 > Please note also that the draft treats transport of signaling=20 > information in separate packets as OPTIONAL (indeed, the word=20 > must be capitalized in accordance with 2119 - will fix after=20 > the LC). Hence the implementors that think that this behavior=20 > is dangerous, are free not to implement it and to use other=20 > available methods. >=20 > Carrying signaling info in a separate PW solves the problem=20 > of two sequencing flows in the same PW BUT introduces some=20 > new ones stemming from interdependency of the two PWs. > E.g., the setup mechanism must provide for ability to=20 > associate the data PW with its paired signaling PW, both must=20 > be torn down together etc. So I'd say that this proposal=20 > fully complies with RFC 1925 (item 6). >=20 >=20 >=20 > With best regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > =20 >=20 >=20 > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Thursday, May 06, 2004 10:59 AM > > To: Sasha Vainshtein; Luca Martini > > Cc: stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > >=20 > >=20 > > =20 > > Luca/Sasha, > >=20 > > My feeling is that we need as much similarlity as possible=20 > between the=20 > > difference service emulations. > >=20 > > The sequence number skipping zero issue seems to me to be "mostly=20 > > harmless", as we don't need to indication that a TDM packet is not=20 > > carrying a sequence number, as all packets are sequenced. > >=20 > > I am more concerned with the concept of multiple sequenced flows=20 > > inside a PW. This seems to me to verge on the dangerous,=20 > and I would=20 > > like to avoid it if possible. > >=20 > > As far as I see there ARE other alternatives to handle the=20 > signaling=20 > > substructure, including the original technique of appending it to a=20 > > data packet. > >=20 > > Y(J)S > >=20 >=20 >=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 12:51:39 +0200 Lines: 150 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 06 12:09:34 2004 Return-path: To: "'Yaakov Stein'" , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov and all, Please see inline. 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: Thursday, May 06, 2004 11:32 AM > To: Sasha Vainshtein; Luca Martini > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > I find your quoting of 1925 apt - > you are moving the problem to a different part of the network, > in fact you are creating a new network layer! > [Sasha] I am not sure what exactly does and what does not make TDM PWs a "new network layer". If you see any EXPLICIT conradiction between usage of two separate sequencing schemes with a single PW and the protocol layering scheme as presented in the PWE3 architecture, please spell it out in order to make THIS discussion more specific. > > Regarding the optionality, I am not sure that even optional > features should be allowed to create new network layers. > > I don't understand your explanation of trunk independence. > [Sasha] I have not probably explained weel. The intention has been to, say, a trans-atlatic PW with timeslots at one end originating in a T1 trunkl and timeslots at the other end originating in an E1 trunk. (Of course this would also require A-law to mu-loaw transplation, but this is purely NSP and hence out of the PWE3 scope). > > In the unlikely case of having E1 and T1 trunks converging > on one IWF (apparently situated on the border between North America > and Europe), the are two consistent options: > [Sasha] As I have said above, this was NOT teh case I have had in mind. > > > 1) add a NSF that multiplexes them taking timing into account > (we don't want to recreate PDH functionality in the PW), > 2) open two PWs, one for the E1 and one for the T1. > > These E1 and T1 trunks will have different timing sources > and MUST NOT be mixed into a single PW. > In addition, as you mention, they have different (multiframe) > structure sizes, and thus SHOULD NOT be placed into a single PW. > > Due to the last point, if you indeed intend to use separate > signaling packets, I guess you would use one for the E1 and > one for the T1, resulting in three separately sequenced flows > in the PW. > > Y(J)S > > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Thursday, May 06, 2004 13:12 > > To: Yaakov Stein; Luca Martini > > Cc: stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > Yaakov and Luca, > > Carrying of singnaling info in separate packets has, IMO, a > > certain advantage since it allows to use the same data plane > > mechanisms for services with and without signaling. > > > > > > Another advantage is trunk independence (i.e., ability to > > pass signaling between bundles of timeslots originating, say > > in E1 and T1/ESF trunks). This functionality CANNOT be > > achieved by appending signaling structures to the data. > > > > Please note also that the draft treats transport of signaling > > information in separate packets as OPTIONAL (indeed, the word > > must be capitalized in accordance with 2119 - will fix after > > the LC). Hence the implementors that think that this behavior > > is dangerous, are free not to implement it and to use other > > available methods. > > > > Carrying signaling info in a separate PW solves the problem > > of two sequencing flows in the same PW BUT introduces some > > new ones stemming from interdependency of the two PWs. > > E.g., the setup mechanism must provide for ability to > > associate the data PW with its paired signaling PW, both must > > be torn down together etc. So I'd say that this proposal > > fully complies with RFC 1925 (item 6). > > > > > > > > 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: Thursday, May 06, 2004 10:59 AM > > > To: Sasha Vainshtein; Luca Martini > > > Cc: stbryant@cisco.com; pwe3@ietf.org > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > Luca/Sasha, > > > > > > My feeling is that we need as much similarlity as possible > > between the > > > difference service emulations. > > > > > > The sequence number skipping zero issue seems to me to be "mostly > > > harmless", as we don't need to indication that a TDM > packet is not > > > carrying a sequence number, as all packets are sequenced. > > > > > > I am more concerned with the concept of multiple sequenced flows > > > inside a PW. This seems to me to verge on the dangerous, > > and I would > > > like to avoid it if possible. > > > > > > As far as I see there ARE other alternatives to handle the > > signaling > > > substructure, including the original technique of > appending it to a > > > data packet. > > > > > > Y(J)S > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 13:25:33 +0100 Lines: 51 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Content-Transfer-Encoding: quoted-printable Cc: , , , X-From: pwe3-admin@ietf.org Thu May 06 14:41:12 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQzR0/niEA+HbAHRYu5szfsmCbL0QAFMiCg To: , X-OriginalArrivalTime: 06 May 2004 12:25:33.0605 (UTC) FILETIME=[3A4CED50:01C43365] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha, Sasha Vainshtein wrote 06 May 2004 10:37 > I also do not think that using additional codepoints can > reduce the need of configuration (which seems to be one of > your concerns). E.g., the decision to generate or not to > generate AIS towards the local CE cannot, IMO, be based > solely on indications received by the CE-bound IWF instance. > E.g., please consider the case where several groups of timeslots > on the same TDM trunk act as ACs for different IWF instances while > "far ends" of the corresponding CESoPSN PWs use ACs that originate > in different trunks. Killing the entire "near end" trunk with AIS > just because AIS has been observed on one of the "far end" trunks > would hardly be the best possible solution. On the other hand, making > each "far end IWF" aware of the fatc that its peer shares (or does=20 > not share) the trunk with other IWF instances does not look a > good solution either. NH=3D> May I make a plea for folks to try and get au fait with the = descriptions of layer networks as defined in G.805 and respect these. = If this was understood here then there is no problem. That is (for = example): If the failures are in 64k trails then these exist above (ie are clients = to) a server E1 or T1 (say) layer trail. The only defect = detection/handling that is relevant here is at the 64k layer = level....specifically, there *must* be no defect detection/handling at = the server E1/T1 level (or indeed any further lower server layer = networks below these). If there is a failure between the trail = termination points of the E1 or T1 server layer however, then at the = E1/T1 trail sink point a FDI (ie AIS here) must be mapped to *all* the = affected 64k client layer trails. And of course, as for the previous = case there must be no defect detection/handling ine any layer networks = below the affected E1/T1 trail. So in fact, both the proposals for handling the case you gave are = incorrect.....the required behaviour is as I outlined above. This is a fundamental behaviour requirement in any client/server = relationship between 2 layer networks. Now if one does not have = client/server layer independence (eg because one is compressing the = client say) you are going to create problems. Specifically, one will be = creating proxy client layer trail termination functions in the wrong = (server) layer network (or, perhaps more accurately, at the = client<=3D>server adaptation function) at the i/w point. And as a = further observation here, the BW savings acrrued from doing this are not = warranted IMO in terms of the problems it creates. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 13:25:36 +0100 Lines: 99 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Thu May 06 14:42:01 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQzTKkQp7i95ncYRqaULV5jRoT2iAAEqFew To: , , X-OriginalArrivalTime: 06 May 2004 12:25:37.0324 (UTC) FILETIME=[3C8466C0:01C43365] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Please think about the functional architecture you are discussing here. = For exmaple: The traffic data-plane and the control data-plane trail = entities can have various levels of disjointedness. In some networks = they might be physically disjoint (eg OTNs), in others they might be = only virtually disjoint (CCS7 for the PSTN say) and in some other cases = might be carried within a common lower layer network trail, eg CAS in an = E1....the 64k client CAS channel/trail here is for the control of (and = only the control of) the client 64k traffic channels/trails that are in = the same parent lower layer E1 trail......so althought both the 64k CAS = channel/trail and each of the 64k traffic clients are independent at the = 64k layer, they are all carried by the same server layer E1 trail. So the required functional model is quite different in all these cases. = So please be very careful to which case you are referring, and use the = appropriate functional model. regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On=20 > Behalf Of Sasha Vainshtein > Sent: 06 May 2004 11:12 > To: 'Yaakov Stein'; Luca Martini > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL >=20 >=20 > Yaakov and Luca, > Carrying of singnaling info in separate packets has, IMO, > a certain advantage since it allows to use the same > data plane mechanisms for services with and without signaling. >=20 >=20 > Another advantage is trunk independence (i.e., ability to > pass signaling between bundles of timeslots originating, > say in E1 and T1/ESF trunks). This functionality > CANNOT be achieved by appending signaling structures to > the data.=20 >=20 > Please note also that the draft treats transport of signaling > information in separate packets as OPTIONAL (indeed, the > word must be capitalized in accordance with 2119 - will fix > after the LC). Hence the implementors that think that=20 > this behavior is dangerous, are free not to implement it=20 > and to use other available methods. >=20 > Carrying signaling info in a separate PW solves the problem > of two sequencing flows in the same PW BUT introduces some > new ones stemming from interdependency of the two PWs. > E.g., the setup mechanism must provide for ability to associate > the data PW with its paired signaling PW, both must be=20 > torn down together etc. So I'd say that this proposal fully=20 > complies with RFC 1925 (item 6). >=20 >=20 >=20 > With best regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > =20 >=20 >=20 > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Thursday, May 06, 2004 10:59 AM > > To: Sasha Vainshtein; Luca Martini > > Cc: stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > >=20 > >=20 > > =20 > > Luca/Sasha,=20 > >=20 > > My feeling is that we need as much similarlity as possible > > between the difference service emulations. > >=20 > > The sequence number skipping zero issue seems to me > > to be "mostly harmless", as we don't need to indication > > that a TDM packet is not carrying a sequence number, > > as all packets are sequenced. > >=20 > > I am more concerned with the concept of multiple sequenced flows > > inside a PW. This seems to me to verge on the dangerous, > > and I would like to avoid it if possible. > >=20 > > As far as I see there ARE other alternatives to handle > > the signaling substructure, including the original technique > > of appending it to a data packet. > >=20 > > Y(J)S > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 13:25:41 +0100 Lines: 146 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Thu May 06 14:44:00 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQzSnCA3Z42c1RHT/uUfOCzTmGmtwAAT3VAAAWNZOA= To: , , X-OriginalArrivalTime: 06 May 2004 12:25:41.0722 (UTC) FILETIME=[3F237BA0:01C43365] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov, please see in-line. regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Yaakov Stein > Sent: 06 May 2004 10:32 > To: Sasha Vainshtein; Luca Martini > Cc: stbryant@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL >=20 >=20 > Sasha,=20 >=20 > I find your quoting of 1925 apt -=20 > you are moving the problem to a different part of the network,=20 > in fact you are creating a new network layer! NH=3D> Precisely.....see my other related mail for further examples. I = wish for more folks would try and grok this layer network stuff better = as they might then produce solutions that don't have latent downstream = problems from (probably unintended) architectural violations.=20 >=20 > Regarding the optionality, I am not sure that even optional > features should be allowed to create new network layers. NH=3D> I would not be prescriptive here, but what I would say is that if = folks properly defined/understood their proposals in func arch terms = then we would better understand all the consequences of the proposal and = make a better informed judgement. >=20 > I don't understand your explanation of trunk independence. > In the unlikely case of having E1 and T1 trunks converging > on one IWF (apparently situated on the border between North America > and Europe), the are two consistent options: >=20 > 1) add a NSF that multiplexes them taking timing into account > (we don't want to recreate PDH functionality in the PW), > 2) open two PWs, one for the E1 and one for the T1. >=20 > These E1 and T1 trunks will have different timing sources > and MUST NOT be mixed into a single PW. > In addition, as you mention, they have different (multiframe) > structure sizes, and thus SHOULD NOT be placed into a single PW. NH=3D> Arrghhh! The E1 and T1 trails belong to different layer networks = anyway....*all* their functions (ie their complete Characteristic = Information in G.805 speak) *must* be terminated at any i/w point. The = only thing that is common is the higher layer 64k layer network traffic = channels (but even these might be diferent at a higher level still, eg A = vs u law encoding say). And of course, although the signalling channels = use the same 64k layer network as the traffic channels for ransport, = these can be quite different in terms of the higher level signalling = protocol used. Further, if the 64k clients are *not* part of a common = 64k layer network then as Yaakov also says their timing behaviour will = be different. >=20 > Due to the last point, if you indeed intend to use separate > signaling packets, I guess you would use one for the E1 and > one for the T1, resulting in three separately sequenced flows > in the PW.=20 >=20 > Y(J)S >=20 >=20 > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 > > Sent: Thursday, May 06, 2004 13:12 > > To: Yaakov Stein; Luca Martini > > Cc: stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > >=20 > > Yaakov and Luca, > > Carrying of singnaling info in separate packets has, IMO, a=20 > > certain advantage since it allows to use the same data plane=20 > > mechanisms for services with and without signaling. > >=20 > >=20 > > Another advantage is trunk independence (i.e., ability to=20 > > pass signaling between bundles of timeslots originating, say=20 > > in E1 and T1/ESF trunks). This functionality CANNOT be=20 > > achieved by appending signaling structures to the data.=20 > >=20 > > Please note also that the draft treats transport of signaling=20 > > information in separate packets as OPTIONAL (indeed, the word=20 > > must be capitalized in accordance with 2119 - will fix after=20 > > the LC). Hence the implementors that think that this behavior=20 > > is dangerous, are free not to implement it and to use other=20 > > available methods. > >=20 > > Carrying signaling info in a separate PW solves the problem=20 > > of two sequencing flows in the same PW BUT introduces some=20 > > new ones stemming from interdependency of the two PWs. > > E.g., the setup mechanism must provide for ability to=20 > > associate the data PW with its paired signaling PW, both must=20 > > be torn down together etc. So I'd say that this proposal=20 > > fully complies with RFC 1925 (item 6). > >=20 > >=20 > >=20 > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com =20 > > tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > =20 > >=20 > >=20 > > > -----Original Message----- > > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > > Sent: Thursday, May 06, 2004 10:59 AM > > > To: Sasha Vainshtein; Luca Martini > > > Cc: stbryant@cisco.com; pwe3@ietf.org > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > >=20 > > >=20 > > > =20 > > > Luca/Sasha, > > >=20 > > > My feeling is that we need as much similarlity as possible=20 > > between the=20 > > > difference service emulations. > > >=20 > > > The sequence number skipping zero issue seems to me to be "mostly=20 > > > harmless", as we don't need to indication that a TDM=20 > packet is not=20 > > > carrying a sequence number, as all packets are sequenced. > > >=20 > > > I am more concerned with the concept of multiple sequenced flows=20 > > > inside a PW. This seems to me to verge on the dangerous,=20 > > and I would=20 > > > like to avoid it if possible. > > >=20 > > > As far as I see there ARE other alternatives to handle the=20 > > signaling=20 > > > substructure, including the original technique of=20 > appending it to a=20 > > > data packet. > > >=20 > > > Y(J)S > > >=20 > >=20 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 13:25:45 +0100 Lines: 146 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Thu May 06 14:44:46 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQzUkOxen1kINWlQQW+DkN+qj0lXwAEfCuw To: , , X-OriginalArrivalTime: 06 May 2004 12:25:46.0098 (UTC) FILETIME=[41BF3520:01C43365] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha.... > > I find your quoting of 1925 apt -=20 > > you are moving the problem to a different part of the network,=20 > > in fact you are creating a new network layer! > > > [Sasha] I am not sure what exactly does and what does not > make TDM PWs a "new network layer".=20 NH=3D> I can see that. Please look at G.805/809. Better, read chapter = 3 (and if time chapter 4) of my colleague Andy Reid's book on 'Broadband = Networking' {ISBN 0-89006-578-0}. > If you see any EXPLICIT > conradiction between usage of two separate sequencing schemes > with a single PW and the protocol layering scheme as > presented in the PWE3 architecture, please spell it out > in order to make THIS discussion more specific. > >=20 > > Regarding the optionality, I am not sure that even optional > > features should be allowed to create new network layers. > >=20 > > I don't understand your explanation of trunk independence. > > > [Sasha] I have not probably explained weel. The intention has > been to, say, a trans-atlatic PW with timeslots at one end > originating in a T1 trunkl and timeslots at the other end > originating in an E1 trunk. (Of course this would also > require A-law to mu-loaw transplation, but this is purely > NSP and hence out of the PWE3 scope).=20 NH=3D> See the comments I made earlier about this case to Yaakov. regards, Neil > > > > In the unlikely case of having E1 and T1 trunks converging > > on one IWF (apparently situated on the border between North America > > and Europe), the are two consistent options: > > > [Sasha] As I have said above, this was NOT teh case I have had > in mind. > > > >=20 > > 1) add a NSF that multiplexes them taking timing into account > > (we don't want to recreate PDH functionality in the PW), > > 2) open two PWs, one for the E1 and one for the T1. > >=20 > > These E1 and T1 trunks will have different timing sources > > and MUST NOT be mixed into a single PW. > > In addition, as you mention, they have different (multiframe) > > structure sizes, and thus SHOULD NOT be placed into a single PW. > >=20 > > Due to the last point, if you indeed intend to use separate > > signaling packets, I guess you would use one for the E1 and > > one for the T1, resulting in three separately sequenced flows > > in the PW.=20 > >=20 > > Y(J)S > >=20 > >=20 > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 > > > Sent: Thursday, May 06, 2004 13:12 > > > To: Yaakov Stein; Luca Martini > > > Cc: stbryant@cisco.com; pwe3@ietf.org > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > >=20 > > > Yaakov and Luca, > > > Carrying of singnaling info in separate packets has, IMO, a=20 > > > certain advantage since it allows to use the same data plane=20 > > > mechanisms for services with and without signaling. > > >=20 > > >=20 > > > Another advantage is trunk independence (i.e., ability to=20 > > > pass signaling between bundles of timeslots originating, say=20 > > > in E1 and T1/ESF trunks). This functionality CANNOT be=20 > > > achieved by appending signaling structures to the data.=20 > > >=20 > > > Please note also that the draft treats transport of signaling=20 > > > information in separate packets as OPTIONAL (indeed, the word=20 > > > must be capitalized in accordance with 2119 - will fix after=20 > > > the LC). Hence the implementors that think that this behavior=20 > > > is dangerous, are free not to implement it and to use other=20 > > > available methods. > > >=20 > > > Carrying signaling info in a separate PW solves the problem=20 > > > of two sequencing flows in the same PW BUT introduces some=20 > > > new ones stemming from interdependency of the two PWs. > > > E.g., the setup mechanism must provide for ability to=20 > > > associate the data PW with its paired signaling PW, both must=20 > > > be torn down together etc. So I'd say that this proposal=20 > > > fully complies with RFC 1925 (item 6). > > >=20 > > >=20 > > >=20 > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com =20 > > > tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > > > =20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > > > Sent: Thursday, May 06, 2004 10:59 AM > > > > To: Sasha Vainshtein; Luca Martini > > > > Cc: stbryant@cisco.com; pwe3@ietf.org > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > >=20 > > > >=20 > > > > =20 > > > > Luca/Sasha, > > > >=20 > > > > My feeling is that we need as much similarlity as possible=20 > > > between the=20 > > > > difference service emulations. > > > >=20 > > > > The sequence number skipping zero issue seems to me to=20 > be "mostly=20 > > > > harmless", as we don't need to indication that a TDM=20 > > packet is not=20 > > > > carrying a sequence number, as all packets are sequenced. > > > >=20 > > > > I am more concerned with the concept of multiple=20 > sequenced flows=20 > > > > inside a PW. This seems to me to verge on the dangerous,=20 > > > and I would=20 > > > > like to avoid it if possible. > > > >=20 > > > > As far as I see there ARE other alternatives to handle the=20 > > > signaling=20 > > > > substructure, including the original technique of=20 > > appending it to a=20 > > > > data packet. > > > >=20 > > > > Y(J)S > > > >=20 > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 15:48:26 +0200 Lines: 104 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: yaakov_s@rad.com, stbryant@cisco.com, pwe3@ietf.org, lmartini@cisco.com, Shahram_Davari@pmc-sierra.com X-From: pwe3-admin@ietf.org Thu May 06 15:03:47 2004 Return-path: To: "'neil.2.harrison@bt.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Neil and all, Please see some comments/answers inline 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, May 06, 2004 2:26 PM > To: Sasha Vainshtein; Shahram_Davari@pmc-sierra.com > Cc: yaakov_s@rad.com; stbryant@cisco.com; pwe3@ietf.org; > lmartini@cisco.com > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > Sasha Vainshtein wrote 06 May 2004 10:37 > > > > I also do not think that using additional codepoints can > > reduce the need of configuration (which seems to be one of > > your concerns). E.g., the decision to generate or not to > > generate AIS towards the local CE cannot, IMO, be based > > solely on indications received by the CE-bound IWF instance. > > E.g., please consider the case where several groups of timeslots > > on the same TDM trunk act as ACs for different IWF instances while > > "far ends" of the corresponding CESoPSN PWs use ACs that originate > > in different trunks. Killing the entire "near end" trunk with AIS > > just because AIS has been observed on one of the "far end" trunks > > would hardly be the best possible solution. On the other > hand, making > > each "far end IWF" aware of the fatc that its peer shares (or does > > not share) the trunk with other IWF instances does not look a > > good solution either. > > NH=> May I make a plea for folks to try and get au fait with > the descriptions of layer networks as defined in G.805 and > respect these. If this was understood here then there is no > problem. That is (for example): > > If the failures are in 64k trails then these exist above (ie > are clients to) a server E1 or T1 (say) layer trail. > [Sasha] AFAIK, no failures/defects have been defined for 64K trails. This may be very bad from the generic leyer networks view as described in G.805 etc., but this is THE ONLY SPECIFIC kind of trails this draft deals with. One way to deal with this problem has been already proposed (in a different forum), namely to forbit emulation of NxDS0 services because they do not fit the correct architecture anyway. This draft clearly pursues a different option. > > The > only defect detection/handling that is relevant here is at > the 64k layer level....specifically, there *must* be no > defect detection/handling at the server E1/T1 level (or > indeed any further lower server layer networks below these). > If there is a failure between the trail termination points of > the E1 or T1 server layer however, then at the E1/T1 trail > sink point a FDI (ie AIS here) must be mapped to *all* the > affected 64k client layer trails. And of course, as for the > previous case there must be no defect detection/handling ine > any layer networks below the affected E1/T1 trail. > The behavior you've described is one that is implemented in the draft. However, the draft allows additional functionality for the case when your NxDS0 service is used to emulate a partially populated E1 or T1 trunk. Once more, the architecturally correct way would be to carry the entire trunk, say 24 timeslots instead of only 4 or 8 actually used and to ignore the BW price tag that goes with it as well as to prevent ability to provide Voice and Data services on a single trunk (quite a business in some places, e.g., in the US). Another option would be to propagate the trunk AIS and RDI indications across the PW and to use them as needed. > > So in fact, both the proposals for handling the case you gave > are incorrect.....the required behaviour is as I outlined above. > > This is a fundamental behaviour requirement in any > client/server relationship between 2 layer networks. Now if > one does not have client/server layer independence (eg > because one is compressing the client say) you are going to > create problems. Specifically, one will be creating proxy > client layer trail termination functions in the wrong > (server) layer network (or, perhaps more accurately, at the > client<=>server adaptation function) at the i/w point. And > as a further observation here, the BW savings acrrued from > doing this are not warranted IMO in terms of the problems it creates. > [Sasha] You clearly prefer BW-inefficient but architecturally correct solutions. I do not have any problems with that, but some people have different opinion and the draft provides for their needs as well as it can be restricted to suit your position. > > regards, Neil > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 16:14:30 +0100 Lines: 50 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Content-Transfer-Encoding: quoted-printable Cc: , , , , X-From: pwe3-admin@ietf.org Thu May 06 17:30:09 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL Thread-Index: AcQzaN6mxFcMzWKlRomQwhrOX9jTQwAEPPsQ To: X-OriginalArrivalTime: 06 May 2004 15:14:30.0950 (UTC) FILETIME=[D4A10460:01C4337C] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Thanks Sasha....please see below. > >=20 > > If the failures are in 64k trails then these exist above (ie=20 > > are clients to) a server E1 or T1 (say) layer trail.=20 > > > [Sasha] AFAIK, no failures/defects have been defined for 64K > trails. NH=3D> I agree. This is historical.=20 > This may be very bad from the generic leyer networks > view as described in G.805 etc., NH=3D> Correct....this is the key point. That is, the fact we have = historical errors/deficiencies means we should learn from them. For = example, SDH had strong OAM built-in to it from day 1 due to the lessons = learned from not having this in PDH. A key (and unintentional) spin-off = of this was that SDH was pretty-well bug-free from the box, ie the = vendors could use the OAM to de-bug their kit during its = development/testing before we operators took large-scale delivery. For = the *general* case what I am saying is corect....so if one deviates from = this, then we need to understand the consequences of doing so before = agreeing to it. > > This is a fundamental behaviour requirement in any=20 > > client/server relationship between 2 layer networks. Now if=20 > > one does not have client/server layer independence (eg=20 > > because one is compressing the client say) you are going to=20 > > create problems. Specifically, one will be creating proxy=20 > > client layer trail termination functions in the wrong=20 > > (server) layer network (or, perhaps more accurately, at the=20 > > client<=3D>server adaptation function) at the i/w point. And=20 > > as a further observation here, the BW savings acrrued from=20 > > doing this are not warranted IMO in terms of the problems=20 > it creates. > > > [Sasha] You clearly prefer BW-inefficient but architecturally=20 > correct solutions. I do not have any problems with that, > but some people have different opinion and the draft provides > for their needs as well as it can be restricted to suit > your position. NH=3D> Understood. I too have no problem with this either providing we = understand the consequences either way and are quite open/honest about = this. What I do have problems with however is when folks try and tell = me that some (usually quite obvious) architectural violation is = 'correct/normal' behaviour and (for whatever reason) refuse to see = things any other way. I am sure you know the stuff I mean here. regards, Neil=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 6 May 2004 18:42:06 +0200 Lines: 46 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: yaakov_s@rad.com, stbryant@cisco.com, pwe3@ietf.org, lmartini@cisco.com, Shahram_Davari@pmc-sierra.com X-From: pwe3-admin@ietf.org Thu May 06 19:16:18 2004 Return-path: To: "'neil.2.harrison@bt.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Neil, Thankk you, and please see a very short response inline below (I have skipped some text for clarity). 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, May 06, 2004 5:15 PM > To: Sasha Vainshtein > Cc: yaakov_s@rad.com; stbryant@cisco.com; pwe3@ietf.org; > lmartini@cisco.com; Shahram_Davari@pmc-sierra.com > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Thanks Sasha....please see below. ... snipped ,,, > > > > > [Sasha] You clearly prefer BW-inefficient but architecturally > > correct solutions. I do not have any problems with that, > > but some people have different opinion and the draft provides > > for their needs as well as it can be restricted to suit > > your position. > NH=> Understood. I too have no problem with this either > providing we understand the consequences either way and are > quite open/honest about this. What I do have problems with > however is when folks try and tell me that some (usually > quite obvious) architectural violation is 'correct/normal' > behaviour and (for whatever reason) refuse to see things any > other way. I am sure you know the stuff I mean here. > [Sasha] I definetely agree with you on the need to be quite open and honest about everything you do. The same goes for making at least a honest attempt to understand the position presented by the others (to the best of one's ability:-). > > regards, Neil > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: Generalized PWID FEC and the question of the Group ID Date: Fri, 07 May 2004 10:28:54 -0400 Lines: 4 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "'Luca Martini'" , "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Fri May 07 17:12:23 2004 Return-path: X-BrightmailFiltered: true To: Nick Weeds In-reply-to: Your message of Wed, 05 May 2004 19:09:17 +0100. 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) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , I'd like to see both the group id and the interface parameters removed from the FEC element entirely, and carried in separate LDP TLVs. I know Luca doesn't like that idea :-); I'd be interested in what others think. From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Shahram Davari Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Mon, 10 May 2004 06:36:13 -0700 Lines: 300 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Mon May 10 15:54:13 2004 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Sasha, AIS of a few time slots should not generate AIS for the whole T1/E1. This is a principle of client/server AIS relationship. Therefore your example is moot. Yours, Shahram > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Thursday, May 06, 2004 5:37 AM > To: Shahram Davari > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; 'Luca Martini' > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Shahram and all, > I'd like to point out that the draft explicitly states the > need for an appropriate NSP in order to provide structured > TDM services. IMO, the Trunk Conditioning functionality you > have mentioned is a "native TDM" function and hence should > be performed by the NSP which would then act not just as > a Framer but as a Digital Cross-Connect (DXC) system. > > I also do not think that using additional codepoints can > reduce the need of configuration (which seems to be one of > your concerns). E.g., the decision to generate or not to > generate AIS towards the local CE cannot, IMO, be based > solely on indications received by the CE-bound IWF instance. > E.g., please consider the case where several groups of timeslots > on the same TDM trunk act as ACs for different IWF instances while > "far ends" of the corresponding CESoPSN PWs use ACs that originate > in different trunks. Killing the entire "near end" trunk with AIS > just because AIS has been observed on one of the "far end" trunks > would hardly be the best possible solution. On the other hand, making > each "far end IWF" aware of the fatc that its peer shares (or does > not share) the trunk with other IWF instances does not look a > good solution either. > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, May 05, 2004 8:22 PM > > To: 'Luca Martini'; Sasha Vainshtein > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Hi Sasha, > > > > I also share the concern that Yaakov and Luca expressed regarding > > the CAS packets multiplexed in the same PW. This would require 2 seq > > number tracking per PW. > > > > I also have another concern, but before I elaborate on that I > > would like to mention that in structured emulation, the > > network MUST generate Trunk conditioning as specified in > > Bellcore TR-NWT-000170, rather than AIS/RDI. > > > > Now my concern: Based on Table 1: The Interpretation of bits > > L and M in the CESoPSN CW, it appears that L=1& M=00 may or > > may not generate AIS/Truck conditioning at the far end, > > depending on the configuration. In order to reduce the amount > > of configuration, I suggest using L=1& M=00, only when your > > payload is omitted and you want AIS/Truck Conditioning > > generated at the far end. And use another code point such as > > L=1 & M=01 to indicate a valid payload, which doesn't need > > AIS/Trunk conditioning to be generated at the far-end. > > > > Similarly for L=0 & M=10, you may want to have another > > codepoint such as L=0 & M=01 if > > you want RDI/Trunk conditioning be generated, while using L=0 > > &M=10 for the case that you don't want to generate RDI/Trunk > > conditioning. > > > > In any case we have to make sure that the interpretation of > > these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413. > > > > Yours, > > -Shahram > > > > > > > > > -----Original Message----- > > > From: Luca Martini [mailto:lmartini@cisco.com] > > > Sent: Wednesday, May 05, 2004 11:49 AM > > > To: Sasha Vainshtein > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Sasha, > > > > > > Indeed there are differences in the drafts , regarding > > > sequence numbers > > > handling , and control words. > > > This does not mean that it will be accepted by the IESG, and > > > it does not > > > mean we have free run of deigning even more different schemes. > > > > > > Definely we never meant to have different sequenced flows > > in the same > > > PW. This is not part of the architecture. > > > Please do not mistake merged flows within a PW with > separate flows > > > within the PW. > > > For example when many ATM VCs are transported as one VP in > > a PW, they > > > are one flow, as they separate VCs have been merged into a > > > single flow > > > in a PW. > > > > > > The point here is to create a standard that can re-use maybe > > > part of the > > > same hardware to transport different types of PWs. It seems > > > to me that > > > even the sequencing in the tdm drafts should conform to the > > > rest of PWE3 > > > designs. > > > > > > Note that I'm on vacation until monday , and desperately > > > attempting to > > > stay away from this computer ... ;-) > > > > > > > > > Bye > > > Luca > > > > > > Sasha Vainshtein wrote: > > > > > > >Yaakov and all, > > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > > >>To: Sasha Vainshtein > > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > >> > > > >> > > > >>... the plot thickens ... > > > >> > > > >> > > > >> > > > >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also > > > >>>does not skip zero (in addition to providing a 24-bit > > > >>>sequence number). > > > >>> > > > >>> > > > >>as does RTP and just about every other sequencing method. > > > >> > > > >> > > > >> > > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > > >This means that forthe same type of AC (FR), you have > > > >two different numbering methods: one for an MPLS PSN and > > > >another fo an IP PSN. So I agree with you that the plot > > > >thickens - but it leads further and further from the > > > >initial scope. > > > > > > > > > > > >>>[Sasha] I do not see it as a major architectural issue beyond > > > >>>the TDM. The difference between the TDM PWs and the rest of > > > >>>them wrt packet loss is essential: TDM PWs MUST compensate > > > >>>each lost packet, while non-TDM can, by default, simply drop > > > >>>mis-ordered packets. I would also glad to hear from Stewart > > > >>>and from the WG at large on this subject. > > > >>> > > > >>> > > > >>The use of the zero sequence number is not the question. > > > >>The use of multiple sequencing streams in a single PW is. > > > >> > > > >> > > > >> > > > >>>>I had interpreted "in-band" to mean "over the same PSN", or > > > >>>>even "over thee same tunnel", not "over the same PW". > > > >>>> > > > >>>> > > > >>>> > > > >>>[Sasha] Unless things have changed drastically from the last > > > >>>time I looked at the TDMoIP draft, you use two types of > > > >>>packets - data and signaling - in the AAL2-based mode - over > > > >>>the same PW. Or did I miss something? > > > >>> > > > >>> > > > >>No, you haven't missed anything. > > > >>The AAL2 method definitely has separate signaling subframes, > > > >>which can be (depending on implementation) placed into > > > >>separate packets. Separate signaling packets share the > > > >>SAME sequence number series. However, this is not critical > > > >>as in your case as the subframes have their own sequencing > > > (in the UUI > > > >>field). > > > >> > > > >>A long time I had considered the option of using > > > >>a separate sequencing method, but rejected it due to its not > > > >>conforming > > > >>with what I considered a general architectural principle > > > >>(you will see in a moment why I consider this a fundamental > > > question). > > > >>That principle is that a PW carries a single flow. > > > >> > > > >> > > > >> > > > >[Sasha] This very much depends on what you define as a flow. > > > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > > > >could be called "flows" as well. > > > >The current architecture does not refer to any such notion, > > > >so, IMHO, everybody can presume what suits him/her best. > > > > > > > > > > > >>In particular: > > > >> 1) a PW is either sequenced or not > > > >> 2) when it is sequenced there is a single sequence per PW > > > >> > > > >>You are proposing multiple sequenced and unsequenced > > streams per PW. > > > >> > > > >> > > > >> > > > >[Sasha] I agree with you that a PW can be either sequenced or not > > > >and I have tried to convince the FR draft editor to impose > > > >some such limitation. The current draft does not > preclude a mix of > > > >sequences (i.e., with non-zero SN) and unsequenced (with zero SN) > > > >PW packets on the same FR PW which, IMHO, should be fixed. > > > >And, to the best of my understanding, I do NOT propose any > > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > > > > >>In other words, you are proposing a third level of flow: > > > >> 1) A tunnel > > > >> 2) PWs in the tunnel > > > >> 3) flows in a PW > > > >> > > > >> > > > >> > > > >[Sasha] IMHO, this is goes far beyond my modest and > > > >very specific proposal. I am not sure that such a > > > >generalization is justified and definitely was not > > > >intended. Hence I find it difficult to answer your very > > > >generic questions below, BUT I believe I have answered > > > >some of them already (wrt setup) in the previous message. > > > > > > > > > > > >>Do we really want/need this third level? > > > >>Are there separate set-up and maintenance entities for this > > > >>third level? > > > >>Do I need VCCV, performance parameters, etc for this new level? > > > >> > > > >>We have already basically turned the PW into a full-blown > > > >>layer network. > > > >>Taking over the job of a friend of ours :) I would > like to ask > > > >>whether we need to define yet another layer network > > inside this one? > > > >> > > > >>Y(J)S > > > >> > > > >> > > > >> > > > > > > > >_______________________________________________ > > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Mon, 10 May 2004 16:40:28 +0200 Lines: 335 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Mon May 10 15:58:45 2004 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Shaharam and all, Please consider the case when you want to emulate behavior of a regular E1/T1 trunk over a PW, but, since only a few timeslots are actually used on this trunk, you use structure-aware emulation. In this case - an this is the example I've tried to present for your consideration before,- AIS of an E1/T1 trunk observed at one end of the PW must be translated to AIS at the other end of the PW. One of the reasons for that requirement can be the need to trigger trunk conditioning in the corresponding CE (if this CE is a DXC). 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 10, 2004 3:36 PM > To: Sasha Vainshtein > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; 'Luca Martini' > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Sasha, > > AIS of a few time slots should not generate AIS for the whole T1/E1. > This is a principle of client/server AIS relationship. Therefore > your example is moot. > > Yours, > Shahram > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Thursday, May 06, 2004 5:37 AM > > To: Shahram Davari > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > 'Luca Martini' > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Shahram and all, > > I'd like to point out that the draft explicitly states the > > need for an appropriate NSP in order to provide structured > > TDM services. IMO, the Trunk Conditioning functionality you > > have mentioned is a "native TDM" function and hence should > > be performed by the NSP which would then act not just as > > a Framer but as a Digital Cross-Connect (DXC) system. > > > > I also do not think that using additional codepoints can > > reduce the need of configuration (which seems to be one of > > your concerns). E.g., the decision to generate or not to > > generate AIS towards the local CE cannot, IMO, be based > > solely on indications received by the CE-bound IWF instance. > > E.g., please consider the case where several groups of timeslots > > on the same TDM trunk act as ACs for different IWF instances while > > "far ends" of the corresponding CESoPSN PWs use ACs that originate > > in different trunks. Killing the entire "near end" trunk with AIS > > just because AIS has been observed on one of the "far end" trunks > > would hardly be the best possible solution. On the other > hand, making > > each "far end IWF" aware of the fatc that its peer shares (or does > > not share) the trunk with other IWF instances does not look a > > good solution either. > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Wednesday, May 05, 2004 8:22 PM > > > To: 'Luca Martini'; Sasha Vainshtein > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Hi Sasha, > > > > > > I also share the concern that Yaakov and Luca expressed regarding > > > the CAS packets multiplexed in the same PW. This would > require 2 seq > > > number tracking per PW. > > > > > > I also have another concern, but before I elaborate on that I > > > would like to mention that in structured emulation, the > > > network MUST generate Trunk conditioning as specified in > > > Bellcore TR-NWT-000170, rather than AIS/RDI. > > > > > > Now my concern: Based on Table 1: The Interpretation of bits > > > L and M in the CESoPSN CW, it appears that L=1& M=00 may or > > > may not generate AIS/Truck conditioning at the far end, > > > depending on the configuration. In order to reduce the amount > > > of configuration, I suggest using L=1& M=00, only when your > > > payload is omitted and you want AIS/Truck Conditioning > > > generated at the far end. And use another code point such as > > > L=1 & M=01 to indicate a valid payload, which doesn't need > > > AIS/Trunk conditioning to be generated at the far-end. > > > > > > Similarly for L=0 & M=10, you may want to have another > > > codepoint such as L=0 & M=01 if > > > you want RDI/Trunk conditioning be generated, while using L=0 > > > &M=10 for the case that you don't want to generate RDI/Trunk > > > conditioning. > > > > > > In any case we have to make sure that the interpretation of > > > these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413. > > > > > > Yours, > > > -Shahram > > > > > > > > > > > > > -----Original Message----- > > > > From: Luca Martini [mailto:lmartini@cisco.com] > > > > Sent: Wednesday, May 05, 2004 11:49 AM > > > > To: Sasha Vainshtein > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > Sasha, > > > > > > > > Indeed there are differences in the drafts , regarding > > > > sequence numbers > > > > handling , and control words. > > > > This does not mean that it will be accepted by the IESG, and > > > > it does not > > > > mean we have free run of deigning even more different schemes. > > > > > > > > Definely we never meant to have different sequenced flows > > > in the same > > > > PW. This is not part of the architecture. > > > > Please do not mistake merged flows within a PW with > > separate flows > > > > within the PW. > > > > For example when many ATM VCs are transported as one VP in > > > a PW, they > > > > are one flow, as they separate VCs have been merged into a > > > > single flow > > > > in a PW. > > > > > > > > The point here is to create a standard that can re-use maybe > > > > part of the > > > > same hardware to transport different types of PWs. It seems > > > > to me that > > > > even the sequencing in the tdm drafts should conform to the > > > > rest of PWE3 > > > > designs. > > > > > > > > Note that I'm on vacation until monday , and desperately > > > > attempting to > > > > stay away from this computer ... ;-) > > > > > > > > > > > > Bye > > > > Luca > > > > > > > > Sasha Vainshtein wrote: > > > > > > > > >Yaakov and all, > > > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > > > >>To: Sasha Vainshtein > > > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > > > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > >> > > > > >> > > > > >>... the plot thickens ... > > > > >> > > > > >> > > > > >> > > > > >>>[Sasha] Note also that the L2TPv3 L2-specific sublayer also > > > > >>>does not skip zero (in addition to providing a 24-bit > > > > >>>sequence number). > > > > >>> > > > > >>> > > > > >>as does RTP and just about every other sequencing method. > > > > >> > > > > >> > > > > >> > > > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > > > >This means that forthe same type of AC (FR), you have > > > > >two different numbering methods: one for an MPLS PSN and > > > > >another fo an IP PSN. So I agree with you that the plot > > > > >thickens - but it leads further and further from the > > > > >initial scope. > > > > > > > > > > > > > > >>>[Sasha] I do not see it as a major architectural > issue beyond > > > > >>>the TDM. The difference between the TDM PWs and the rest of > > > > >>>them wrt packet loss is essential: TDM PWs MUST compensate > > > > >>>each lost packet, while non-TDM can, by default, simply drop > > > > >>>mis-ordered packets. I would also glad to hear from Stewart > > > > >>>and from the WG at large on this subject. > > > > >>> > > > > >>> > > > > >>The use of the zero sequence number is not the question. > > > > >>The use of multiple sequencing streams in a single PW is. > > > > >> > > > > >> > > > > >> > > > > >>>>I had interpreted "in-band" to mean "over the same PSN", or > > > > >>>>even "over thee same tunnel", not "over the same PW". > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>[Sasha] Unless things have changed drastically from the last > > > > >>>time I looked at the TDMoIP draft, you use two types of > > > > >>>packets - data and signaling - in the AAL2-based mode - over > > > > >>>the same PW. Or did I miss something? > > > > >>> > > > > >>> > > > > >>No, you haven't missed anything. > > > > >>The AAL2 method definitely has separate signaling subframes, > > > > >>which can be (depending on implementation) placed into > > > > >>separate packets. Separate signaling packets share the > > > > >>SAME sequence number series. However, this is not critical > > > > >>as in your case as the subframes have their own sequencing > > > > (in the UUI > > > > >>field). > > > > >> > > > > >>A long time I had considered the option of using > > > > >>a separate sequencing method, but rejected it due to its not > > > > >>conforming > > > > >>with what I considered a general architectural principle > > > > >>(you will see in a moment why I consider this a fundamental > > > > question). > > > > >>That principle is that a PW carries a single flow. > > > > >> > > > > >> > > > > >> > > > > >[Sasha] This very much depends on what you define as a flow. > > > > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > > > > >could be called "flows" as well. > > > > >The current architecture does not refer to any such notion, > > > > >so, IMHO, everybody can presume what suits him/her best. > > > > > > > > > > > > > > >>In particular: > > > > >> 1) a PW is either sequenced or not > > > > >> 2) when it is sequenced there is a single sequence per PW > > > > >> > > > > >>You are proposing multiple sequenced and unsequenced > > > streams per PW. > > > > >> > > > > >> > > > > >> > > > > >[Sasha] I agree with you that a PW can be either > sequenced or not > > > > >and I have tried to convince the FR draft editor to impose > > > > >some such limitation. The current draft does not > > preclude a mix of > > > > >sequences (i.e., with non-zero SN) and unsequenced > (with zero SN) > > > > >PW packets on the same FR PW which, IMHO, should be fixed. > > > > >And, to the best of my understanding, I do NOT propose any > > > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > > > > > > > >>In other words, you are proposing a third level of flow: > > > > >> 1) A tunnel > > > > >> 2) PWs in the tunnel > > > > >> 3) flows in a PW > > > > >> > > > > >> > > > > >> > > > > >[Sasha] IMHO, this is goes far beyond my modest and > > > > >very specific proposal. I am not sure that such a > > > > >generalization is justified and definitely was not > > > > >intended. Hence I find it difficult to answer your very > > > > >generic questions below, BUT I believe I have answered > > > > >some of them already (wrt setup) in the previous message. > > > > > > > > > > > > > > >>Do we really want/need this third level? > > > > >>Are there separate set-up and maintenance entities for this > > > > >>third level? > > > > >>Do I need VCCV, performance parameters, etc for this > new level? > > > > >> > > > > >>We have already basically turned the PW into a full-blown > > > > >>layer network. > > > > >>Taking over the job of a friend of ours :) I would > > like to ask > > > > >>whether we need to define yet another layer network > > > inside this one? > > > > >> > > > > >>Y(J)S > > > > >> > > > > >> > > > > >> > > > > > > > > > >_______________________________________________ > > > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Shahram Davari Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Mon, 10 May 2004 07:03:05 -0700 Lines: 367 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Mon May 10 16:19:51 2004 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi Sasha, Mapping AIS from server to client is fine. So in you new example if the fractional T1/E1 indicates AIS, then again you must generated trunk conditioning toward downstream. You may want to generate trunk conditioning at the PE that first detects TDM failure (ingress PE), or at the egress PE. If you generate trunk conditioning at the ingress PE , then you must tell the other end not to generate trunk conditioning, but only send whatever it receives to the customer. While if the ingress PE can't generate trunk conditioning, it should tell the egress PE to generate it. So there are only 2 cases, either the egress PE should or should not generate trunk conditioning, depending on ingress PE capabilities. That is why I asked for 2 L/M code points. Yours, -Shahram > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Monday, May 10, 2004 10:40 AM > To: Shahram Davari > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; 'Luca Martini' > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Shaharam and all, > Please consider the case when you want to emulate behavior of > a regular E1/T1 trunk over a PW, but, since only a few timeslots > are actually used on this trunk, you use structure-aware emulation. > In this case - an this is the example I've tried to present for your > consideration before,- AIS of an E1/T1 trunk observed at one end > of the PW must be translated to AIS at the other end of the PW. > One of the reasons for that requirement can be the need to trigger > trunk conditioning in the corresponding CE (if this CE is a DXC). > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, May 10, 2004 3:36 PM > > To: Sasha Vainshtein > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > 'Luca Martini' > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Sasha, > > > > AIS of a few time slots should not generate AIS for the whole T1/E1. > > This is a principle of client/server AIS relationship. Therefore > > your example is moot. > > > > Yours, > > Shahram > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > Sent: Thursday, May 06, 2004 5:37 AM > > > To: Shahram Davari > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > 'Luca Martini' > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Shahram and all, > > > I'd like to point out that the draft explicitly states the > > > need for an appropriate NSP in order to provide structured > > > TDM services. IMO, the Trunk Conditioning functionality you > > > have mentioned is a "native TDM" function and hence should > > > be performed by the NSP which would then act not just as > > > a Framer but as a Digital Cross-Connect (DXC) system. > > > > > > I also do not think that using additional codepoints can > > > reduce the need of configuration (which seems to be one of > > > your concerns). E.g., the decision to generate or not to > > > generate AIS towards the local CE cannot, IMO, be based > > > solely on indications received by the CE-bound IWF instance. > > > E.g., please consider the case where several groups of timeslots > > > on the same TDM trunk act as ACs for different IWF instances while > > > "far ends" of the corresponding CESoPSN PWs use ACs that originate > > > in different trunks. Killing the entire "near end" trunk with AIS > > > just because AIS has been observed on one of the "far end" trunks > > > would hardly be the best possible solution. On the other > > hand, making > > > each "far end IWF" aware of the fatc that its peer shares > (or does > > > not share) the trunk with other IWF instances does not look a > > > good solution either. > > > > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Wednesday, May 05, 2004 8:22 PM > > > > To: 'Luca Martini'; Sasha Vainshtein > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > Hi Sasha, > > > > > > > > I also share the concern that Yaakov and Luca expressed > regarding > > > > the CAS packets multiplexed in the same PW. This would > > require 2 seq > > > > number tracking per PW. > > > > > > > > I also have another concern, but before I elaborate on that I > > > > would like to mention that in structured emulation, the > > > > network MUST generate Trunk conditioning as specified in > > > > Bellcore TR-NWT-000170, rather than AIS/RDI. > > > > > > > > Now my concern: Based on Table 1: The Interpretation of bits > > > > L and M in the CESoPSN CW, it appears that L=1& M=00 may or > > > > may not generate AIS/Truck conditioning at the far end, > > > > depending on the configuration. In order to reduce the amount > > > > of configuration, I suggest using L=1& M=00, only when your > > > > payload is omitted and you want AIS/Truck Conditioning > > > > generated at the far end. And use another code point such as > > > > L=1 & M=01 to indicate a valid payload, which doesn't need > > > > AIS/Trunk conditioning to be generated at the far-end. > > > > > > > > Similarly for L=0 & M=10, you may want to have another > > > > codepoint such as L=0 & M=01 if > > > > you want RDI/Trunk conditioning be generated, while using L=0 > > > > &M=10 for the case that you don't want to generate RDI/Trunk > > > > conditioning. > > > > > > > > In any case we have to make sure that the interpretation of > > > > these fields is the same for SAToP, CESoPSN, TDMoIP and Y.1413. > > > > > > > > Yours, > > > > -Shahram > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Luca Martini [mailto:lmartini@cisco.com] > > > > > Sent: Wednesday, May 05, 2004 11:49 AM > > > > > To: Sasha Vainshtein > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > Sasha, > > > > > > > > > > Indeed there are differences in the drafts , regarding > > > > > sequence numbers > > > > > handling , and control words. > > > > > This does not mean that it will be accepted by the IESG, and > > > > > it does not > > > > > mean we have free run of deigning even more different schemes. > > > > > > > > > > Definely we never meant to have different sequenced flows > > > > in the same > > > > > PW. This is not part of the architecture. > > > > > Please do not mistake merged flows within a PW with > > > separate flows > > > > > within the PW. > > > > > For example when many ATM VCs are transported as one VP in > > > > a PW, they > > > > > are one flow, as they separate VCs have been merged into a > > > > > single flow > > > > > in a PW. > > > > > > > > > > The point here is to create a standard that can re-use maybe > > > > > part of the > > > > > same hardware to transport different types of PWs. It seems > > > > > to me that > > > > > even the sequencing in the tdm drafts should conform to the > > > > > rest of PWE3 > > > > > designs. > > > > > > > > > > Note that I'm on vacation until monday , and desperately > > > > > attempting to > > > > > stay away from this computer ... ;-) > > > > > > > > > > > > > > > Bye > > > > > Luca > > > > > > > > > > Sasha Vainshtein wrote: > > > > > > > > > > >Yaakov and all, > > > > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > > > > >>To: Sasha Vainshtein > > > > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > > > > >>Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > >> > > > > > >> > > > > > >>... the plot thickens ... > > > > > >> > > > > > >> > > > > > >> > > > > > >>>[Sasha] Note also that the L2TPv3 L2-specific > sublayer also > > > > > >>>does not skip zero (in addition to providing a 24-bit > > > > > >>>sequence number). > > > > > >>> > > > > > >>> > > > > > >>as does RTP and just about every other sequencing method. > > > > > >> > > > > > >> > > > > > >> > > > > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > > > > >This means that forthe same type of AC (FR), you have > > > > > >two different numbering methods: one for an MPLS PSN and > > > > > >another fo an IP PSN. So I agree with you that the plot > > > > > >thickens - but it leads further and further from the > > > > > >initial scope. > > > > > > > > > > > > > > > > > >>>[Sasha] I do not see it as a major architectural > > issue beyond > > > > > >>>the TDM. The difference between the TDM PWs and > the rest of > > > > > >>>them wrt packet loss is essential: TDM PWs MUST compensate > > > > > >>>each lost packet, while non-TDM can, by default, > simply drop > > > > > >>>mis-ordered packets. I would also glad to hear > from Stewart > > > > > >>>and from the WG at large on this subject. > > > > > >>> > > > > > >>> > > > > > >>The use of the zero sequence number is not the question. > > > > > >>The use of multiple sequencing streams in a single PW is. > > > > > >> > > > > > >> > > > > > >> > > > > > >>>>I had interpreted "in-band" to mean "over the > same PSN", or > > > > > >>>>even "over thee same tunnel", not "over the same PW". > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>[Sasha] Unless things have changed drastically > from the last > > > > > >>>time I looked at the TDMoIP draft, you use two types of > > > > > >>>packets - data and signaling - in the AAL2-based > mode - over > > > > > >>>the same PW. Or did I miss something? > > > > > >>> > > > > > >>> > > > > > >>No, you haven't missed anything. > > > > > >>The AAL2 method definitely has separate signaling > subframes, > > > > > >>which can be (depending on implementation) placed into > > > > > >>separate packets. Separate signaling packets share the > > > > > >>SAME sequence number series. However, this is not critical > > > > > >>as in your case as the subframes have their own sequencing > > > > > (in the UUI > > > > > >>field). > > > > > >> > > > > > >>A long time I had considered the option of using > > > > > >>a separate sequencing method, but rejected it due > to its not > > > > > >>conforming > > > > > >>with what I considered a general architectural principle > > > > > >>(you will see in a moment why I consider this a fundamental > > > > > question). > > > > > >>That principle is that a PW carries a single flow. > > > > > >> > > > > > >> > > > > > >> > > > > > >[Sasha] This very much depends on what you define as a flow. > > > > > >E.g., the "port mode" of FR PWs carries multiple DLCIs which > > > > > >could be called "flows" as well. > > > > > >The current architecture does not refer to any such notion, > > > > > >so, IMHO, everybody can presume what suits him/her best. > > > > > > > > > > > > > > > > > >>In particular: > > > > > >> 1) a PW is either sequenced or not > > > > > >> 2) when it is sequenced there is a single sequence per PW > > > > > >> > > > > > >>You are proposing multiple sequenced and unsequenced > > > > streams per PW. > > > > > >> > > > > > >> > > > > > >> > > > > > >[Sasha] I agree with you that a PW can be either > > sequenced or not > > > > > >and I have tried to convince the FR draft editor to impose > > > > > >some such limitation. The current draft does not > > > preclude a mix of > > > > > >sequences (i.e., with non-zero SN) and unsequenced > > (with zero SN) > > > > > >PW packets on the same FR PW which, IMHO, should be fixed. > > > > > >And, to the best of my understanding, I do NOT propose any > > > > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > > > > > > > > > > >>In other words, you are proposing a third level of flow: > > > > > >> 1) A tunnel > > > > > >> 2) PWs in the tunnel > > > > > >> 3) flows in a PW > > > > > >> > > > > > >> > > > > > >> > > > > > >[Sasha] IMHO, this is goes far beyond my modest and > > > > > >very specific proposal. I am not sure that such a > > > > > >generalization is justified and definitely was not > > > > > >intended. Hence I find it difficult to answer your very > > > > > >generic questions below, BUT I believe I have answered > > > > > >some of them already (wrt setup) in the previous message. > > > > > > > > > > > > > > > > > >>Do we really want/need this third level? > > > > > >>Are there separate set-up and maintenance entities for this > > > > > >>third level? > > > > > >>Do I need VCCV, performance parameters, etc for this > > new level? > > > > > >> > > > > > >>We have already basically turned the PW into a full-blown > > > > > >>layer network. > > > > > >>Taking over the job of a friend of ours :) I would > > > like to ask > > > > > >>whether we need to define yet another layer network > > > > inside this one? > > > > > >> > > > > > >>Y(J)S > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > >_______________________________________________ > > > > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Mon, 10 May 2004 17:25:18 +0200 Lines: 444 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Mon May 10 16:54:12 2004 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Shahram and all, Please see some comments inline. 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 10, 2004 4:03 PM > To: Sasha Vainshtein > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; 'Luca Martini' > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Hi Sasha, > > Mapping AIS from server to client is fine. So in you new [Sasha] Sorry to say, but is one and the same example all the way. Presumably I have not explained it well enough. > example if the fractional T1/E1 > indicates AIS, then again you must generated trunk > conditioning toward downstream. [Sasha] Bellcore TR-NWT-170 to which you refer defines requirements to digital cross-connect (DXC) systems. These systems, indeed, must generate trunk conditioning (namely, release telephony calls) on the downsream channels (timeslots) that have been affected by an upstream local ("red") or remote ("yelow") alarm. Now, structure-aware TDM PWs are NOT DXCs, nor are their IWFs. The PWEe reference model has defines a dedicated element for handling this kind of functionality, namely the NSP. The draft under consideration postulates the need for an NSP for structure-aware TDM PWs. Such an NSP can be a plain E1/T1 framer, or it can support DXC functions as well. In the latter case, this DXC would implement traffic conditioning, and the only thing needed for this purpose is conveyance of the appropriate signals by the structure-aware TDM PW. > > You may want to generate > trunk conditioning at the PE that first detects TDM failure > (ingress PE), or at the egress PE. If you generate trunk > conditioning at the ingress PE , then you must tell the other > end not to generate trunk conditioning, but only send > whatever it receives to the customer. While if the ingress PE > can't generate trunk conditioning, it should tell the egress > PE to generate it. > > So there are only 2 cases, either the egress PE should or > should not generate trunk conditioning, depending on ingress > PE capabilities. That is why I asked for 2 L/M code points. > [Sasha] Please note that the two cases you describe are hardly dynamic. So, instead of carrying some indications in the data it is enough to configure the IWF to pass or not to pass signals received over the TDM PW to the local NSP. Please note that this does not increase the amount of local configuration, when compared with your proposal, just move some configuration from one end of the PW to the other. Note also that there is no need to exchange the NSP capabilities and desired behavior during the PW setup. > > Yours, > -Shahram > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Monday, May 10, 2004 10:40 AM > > To: Shahram Davari > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > 'Luca Martini' > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Shaharam and all, > > Please consider the case when you want to emulate behavior of > > a regular E1/T1 trunk over a PW, but, since only a few timeslots > > are actually used on this trunk, you use structure-aware emulation. > > In this case - an this is the example I've tried to present for your > > consideration before,- AIS of an E1/T1 trunk observed at one end > > of the PW must be translated to AIS at the other end of the PW. > > One of the reasons for that requirement can be the need to trigger > > trunk conditioning in the corresponding CE (if this CE is a DXC). > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Monday, May 10, 2004 3:36 PM > > > To: Sasha Vainshtein > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > 'Luca Martini' > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Sasha, > > > > > > AIS of a few time slots should not generate AIS for the > whole T1/E1. > > > This is a principle of client/server AIS relationship. Therefore > > > your example is moot. > > > > > > Yours, > > > Shahram > > > > > > > -----Original Message----- > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > Sent: Thursday, May 06, 2004 5:37 AM > > > > To: Shahram Davari > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > 'Luca Martini' > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > Shahram and all, > > > > I'd like to point out that the draft explicitly states the > > > > need for an appropriate NSP in order to provide structured > > > > TDM services. IMO, the Trunk Conditioning functionality you > > > > have mentioned is a "native TDM" function and hence should > > > > be performed by the NSP which would then act not just as > > > > a Framer but as a Digital Cross-Connect (DXC) system. > > > > > > > > I also do not think that using additional codepoints can > > > > reduce the need of configuration (which seems to be one of > > > > your concerns). E.g., the decision to generate or not to > > > > generate AIS towards the local CE cannot, IMO, be based > > > > solely on indications received by the CE-bound IWF instance. > > > > E.g., please consider the case where several groups of timeslots > > > > on the same TDM trunk act as ACs for different IWF > instances while > > > > "far ends" of the corresponding CESoPSN PWs use ACs > that originate > > > > in different trunks. Killing the entire "near end" > trunk with AIS > > > > just because AIS has been observed on one of the "far > end" trunks > > > > would hardly be the best possible solution. On the other > > > hand, making > > > > each "far end IWF" aware of the fatc that its peer shares > > (or does > > > > not share) the trunk with other IWF instances does not look a > > > > good solution either. > > > > > > > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Wednesday, May 05, 2004 8:22 PM > > > > > To: 'Luca Martini'; Sasha Vainshtein > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > I also share the concern that Yaakov and Luca expressed > > regarding > > > > > the CAS packets multiplexed in the same PW. This would > > > require 2 seq > > > > > number tracking per PW. > > > > > > > > > > I also have another concern, but before I elaborate on that I > > > > > would like to mention that in structured emulation, the > > > > > network MUST generate Trunk conditioning as specified in > > > > > Bellcore TR-NWT-000170, rather than AIS/RDI. > > > > > > > > > > Now my concern: Based on Table 1: The Interpretation of bits > > > > > L and M in the CESoPSN CW, it appears that L=1& M=00 may or > > > > > may not generate AIS/Truck conditioning at the far end, > > > > > depending on the configuration. In order to reduce the amount > > > > > of configuration, I suggest using L=1& M=00, only when your > > > > > payload is omitted and you want AIS/Truck Conditioning > > > > > generated at the far end. And use another code point such as > > > > > L=1 & M=01 to indicate a valid payload, which doesn't need > > > > > AIS/Trunk conditioning to be generated at the far-end. > > > > > > > > > > Similarly for L=0 & M=10, you may want to have another > > > > > codepoint such as L=0 & M=01 if > > > > > you want RDI/Trunk conditioning be generated, while using L=0 > > > > > &M=10 for the case that you don't want to generate RDI/Trunk > > > > > conditioning. > > > > > > > > > > In any case we have to make sure that the interpretation of > > > > > these fields is the same for SAToP, CESoPSN, TDMoIP > and Y.1413. > > > > > > > > > > Yours, > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Luca Martini [mailto:lmartini@cisco.com] > > > > > > Sent: Wednesday, May 05, 2004 11:49 AM > > > > > > To: Sasha Vainshtein > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > > Subject: Re: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > Sasha, > > > > > > > > > > > > Indeed there are differences in the drafts , regarding > > > > > > sequence numbers > > > > > > handling , and control words. > > > > > > This does not mean that it will be accepted by the > IESG, and > > > > > > it does not > > > > > > mean we have free run of deigning even more > different schemes. > > > > > > > > > > > > Definely we never meant to have different sequenced flows > > > > > in the same > > > > > > PW. This is not part of the architecture. > > > > > > Please do not mistake merged flows within a PW with > > > > separate flows > > > > > > within the PW. > > > > > > For example when many ATM VCs are transported as one VP in > > > > > a PW, they > > > > > > are one flow, as they separate VCs have been merged into a > > > > > > single flow > > > > > > in a PW. > > > > > > > > > > > > The point here is to create a standard that can > re-use maybe > > > > > > part of the > > > > > > same hardware to transport different types of PWs. It seems > > > > > > to me that > > > > > > even the sequencing in the tdm drafts should conform to the > > > > > > rest of PWE3 > > > > > > designs. > > > > > > > > > > > > Note that I'm on vacation until monday , and desperately > > > > > > attempting to > > > > > > stay away from this computer ... ;-) > > > > > > > > > > > > > > > > > > Bye > > > > > > Luca > > > > > > > > > > > > Sasha Vainshtein wrote: > > > > > > > > > > > > >Yaakov and all, > > > > > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > > > > > >>To: Sasha Vainshtein > > > > > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > > > > > >>Subject: RE: [PWE3] > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > >> > > > > > > >> > > > > > > >>... the plot thickens ... > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>>[Sasha] Note also that the L2TPv3 L2-specific > > sublayer also > > > > > > >>>does not skip zero (in addition to providing a 24-bit > > > > > > >>>sequence number). > > > > > > >>> > > > > > > >>> > > > > > > >>as does RTP and just about every other sequencing method. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > > > > > >This means that forthe same type of AC (FR), you have > > > > > > >two different numbering methods: one for an MPLS PSN and > > > > > > >another fo an IP PSN. So I agree with you that the plot > > > > > > >thickens - but it leads further and further from the > > > > > > >initial scope. > > > > > > > > > > > > > > > > > > > > >>>[Sasha] I do not see it as a major architectural > > > issue beyond > > > > > > >>>the TDM. The difference between the TDM PWs and > > the rest of > > > > > > >>>them wrt packet loss is essential: TDM PWs MUST > compensate > > > > > > >>>each lost packet, while non-TDM can, by default, > > simply drop > > > > > > >>>mis-ordered packets. I would also glad to hear > > from Stewart > > > > > > >>>and from the WG at large on this subject. > > > > > > >>> > > > > > > >>> > > > > > > >>The use of the zero sequence number is not the question. > > > > > > >>The use of multiple sequencing streams in a single PW is. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>>>I had interpreted "in-band" to mean "over the > > same PSN", or > > > > > > >>>>even "over thee same tunnel", not "over the same PW". > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>[Sasha] Unless things have changed drastically > > from the last > > > > > > >>>time I looked at the TDMoIP draft, you use two types of > > > > > > >>>packets - data and signaling - in the AAL2-based > > mode - over > > > > > > >>>the same PW. Or did I miss something? > > > > > > >>> > > > > > > >>> > > > > > > >>No, you haven't missed anything. > > > > > > >>The AAL2 method definitely has separate signaling > > subframes, > > > > > > >>which can be (depending on implementation) placed into > > > > > > >>separate packets. Separate signaling packets share the > > > > > > >>SAME sequence number series. However, this is not critical > > > > > > >>as in your case as the subframes have their own > sequencing > > > > > > (in the UUI > > > > > > >>field). > > > > > > >> > > > > > > >>A long time I had considered the option of using > > > > > > >>a separate sequencing method, but rejected it due > > to its not > > > > > > >>conforming > > > > > > >>with what I considered a general architectural principle > > > > > > >>(you will see in a moment why I consider this a > fundamental > > > > > > question). > > > > > > >>That principle is that a PW carries a single flow. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >[Sasha] This very much depends on what you define > as a flow. > > > > > > >E.g., the "port mode" of FR PWs carries multiple > DLCIs which > > > > > > >could be called "flows" as well. > > > > > > >The current architecture does not refer to any such notion, > > > > > > >so, IMHO, everybody can presume what suits him/her best. > > > > > > > > > > > > > > > > > > > > >>In particular: > > > > > > >> 1) a PW is either sequenced or not > > > > > > >> 2) when it is sequenced there is a single > sequence per PW > > > > > > >> > > > > > > >>You are proposing multiple sequenced and unsequenced > > > > > streams per PW. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >[Sasha] I agree with you that a PW can be either > > > sequenced or not > > > > > > >and I have tried to convince the FR draft editor to impose > > > > > > >some such limitation. The current draft does not > > > > preclude a mix of > > > > > > >sequences (i.e., with non-zero SN) and unsequenced > > > (with zero SN) > > > > > > >PW packets on the same FR PW which, IMHO, should be fixed. > > > > > > >And, to the best of my understanding, I do NOT propose any > > > > > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > > > > > > > > > > > > > >>In other words, you are proposing a third level of flow: > > > > > > >> 1) A tunnel > > > > > > >> 2) PWs in the tunnel > > > > > > >> 3) flows in a PW > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >[Sasha] IMHO, this is goes far beyond my modest and > > > > > > >very specific proposal. I am not sure that such a > > > > > > >generalization is justified and definitely was not > > > > > > >intended. Hence I find it difficult to answer your very > > > > > > >generic questions below, BUT I believe I have answered > > > > > > >some of them already (wrt setup) in the previous message. > > > > > > > > > > > > > > > > > > > > >>Do we really want/need this third level? > > > > > > >>Are there separate set-up and maintenance > entities for this > > > > > > >>third level? > > > > > > >>Do I need VCCV, performance parameters, etc for this > > > new level? > > > > > > >> > > > > > > >>We have already basically turned the PW into a full-blown > > > > > > >>layer network. > > > > > > >>Taking over the job of a friend of ours :) I would > > > > like to ask > > > > > > >>whether we need to define yet another layer network > > > > > inside this one? > > > > > > >> > > > > > > >>Y(J)S > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > >_______________________________________________ > > > > > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Shahram Davari Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Mon, 10 May 2004 07:41:40 -0700 Lines: 500 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Mon May 10 17:00:20 2004 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi Sasha, > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Monday, May 10, 2004 11:25 AM > To: Shahram Davari > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; 'Luca Martini' > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Shahram and all, > Please see some comments inline. > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, May 10, 2004 4:03 PM > > To: Sasha Vainshtein > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > 'Luca Martini' > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Hi Sasha, > > > > Mapping AIS from server to client is fine. So in you new > [Sasha] Sorry to say, but is one and the same example > all the way. Presumably I have not explained it well enough. > > example if the fractional T1/E1 > > indicates AIS, then again you must generated trunk > > conditioning toward downstream. > [Sasha] Bellcore TR-NWT-170 to which you refer defines requirements > to digital cross-connect (DXC) systems. These systems, indeed, > must generate trunk conditioning (namely, release telephony calls) > on the downsream channels (timeslots) that have been affected > by an upstream local ("red") or remote ("yelow") alarm. > Now, structure-aware TDM PWs are NOT DXCs, nor are their IWFs. SD-> Have a look at ATM Forum's af-vtoa-0078.000. It requires generating trunk conditioning by the ATM network. So it is not restricted to DXCs. > The PWEe reference model has defines a dedicated element for > handling this kind of functionality, namely the NSP. > The draft under consideration postulates the need for an NSP > for structure-aware TDM PWs. Such an NSP can be a plain E1/T1 > framer, or it can support DXC functions as well. In the latter > case, this DXC would implement traffic conditioning, and the > only thing needed for this purpose is conveyance of the > appropriate signals by the structure-aware TDM PW. OK, but a single flag can't tell the folowing to the PE: 1)A defect is detected at the other end, however you don't need to generate any RDI/trunk conditioning 2) A defect is detected at the other end, and you need to generate RDI/trunk conditioning 3)There is no problem at the other end. > > > You may want to generate > > trunk conditioning at the PE that first detects TDM failure > > (ingress PE), or at the egress PE. If you generate trunk > > conditioning at the ingress PE , then you must tell the other > > end not to generate trunk conditioning, but only send > > whatever it receives to the customer. While if the ingress PE > > can't generate trunk conditioning, it should tell the egress > > PE to generate it. > > > > So there are only 2 cases, either the egress PE should or > > should not generate trunk conditioning, depending on ingress > > PE capabilities. That is why I asked for 2 L/M code points. > > > [Sasha] Please note that the two cases you describe are > hardly dynamic. So, instead of carrying some indications in the > data it is enough to configure the IWF to pass or not to pass > signals received over the TDM PW to the local NSP. Please > note that this does not increase the amount of local configuration, > when compared with your proposal, just move some configuration > from one end of the PW to the other. Note also that there is no need > to exchange the NSP capabilities and desired behavior during the > PW setup. This is avalid argument. Yours, -Shahram > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > Sent: Monday, May 10, 2004 10:40 AM > > > To: Shahram Davari > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > 'Luca Martini' > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Shaharam and all, > > > Please consider the case when you want to emulate behavior of > > > a regular E1/T1 trunk over a PW, but, since only a few timeslots > > > are actually used on this trunk, you use structure-aware > emulation. > > > In this case - an this is the example I've tried to > present for your > > > consideration before,- AIS of an E1/T1 trunk observed at one end > > > of the PW must be translated to AIS at the other end of the PW. > > > One of the reasons for that requirement can be the need to trigger > > > trunk conditioning in the corresponding CE (if this CE is a DXC). > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Monday, May 10, 2004 3:36 PM > > > > To: Sasha Vainshtein > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > 'Luca Martini' > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > Sasha, > > > > > > > > AIS of a few time slots should not generate AIS for the > > whole T1/E1. > > > > This is a principle of client/server AIS relationship. Therefore > > > > your example is moot. > > > > > > > > Yours, > > > > Shahram > > > > > > > > > -----Original Message----- > > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > > Sent: Thursday, May 06, 2004 5:37 AM > > > > > To: Shahram Davari > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > > 'Luca Martini' > > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > Shahram and all, > > > > > I'd like to point out that the draft explicitly states the > > > > > need for an appropriate NSP in order to provide structured > > > > > TDM services. IMO, the Trunk Conditioning functionality you > > > > > have mentioned is a "native TDM" function and hence should > > > > > be performed by the NSP which would then act not just as > > > > > a Framer but as a Digital Cross-Connect (DXC) system. > > > > > > > > > > I also do not think that using additional codepoints can > > > > > reduce the need of configuration (which seems to be one of > > > > > your concerns). E.g., the decision to generate or not to > > > > > generate AIS towards the local CE cannot, IMO, be based > > > > > solely on indications received by the CE-bound IWF instance. > > > > > E.g., please consider the case where several groups > of timeslots > > > > > on the same TDM trunk act as ACs for different IWF > > instances while > > > > > "far ends" of the corresponding CESoPSN PWs use ACs > > that originate > > > > > in different trunks. Killing the entire "near end" > > trunk with AIS > > > > > just because AIS has been observed on one of the "far > > end" trunks > > > > > would hardly be the best possible solution. On the other > > > > hand, making > > > > > each "far end IWF" aware of the fatc that its peer shares > > > (or does > > > > > not share) the trunk with other IWF instances does not look a > > > > > good solution either. > > > > > > > > > > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > Sent: Wednesday, May 05, 2004 8:22 PM > > > > > > To: 'Luca Martini'; Sasha Vainshtein > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > I also share the concern that Yaakov and Luca expressed > > > regarding > > > > > > the CAS packets multiplexed in the same PW. This would > > > > require 2 seq > > > > > > number tracking per PW. > > > > > > > > > > > > I also have another concern, but before I elaborate > on that I > > > > > > would like to mention that in structured emulation, the > > > > > > network MUST generate Trunk conditioning as specified in > > > > > > Bellcore TR-NWT-000170, rather than AIS/RDI. > > > > > > > > > > > > Now my concern: Based on Table 1: The > Interpretation of bits > > > > > > L and M in the CESoPSN CW, it appears that L=1& M=00 may or > > > > > > may not generate AIS/Truck conditioning at the far end, > > > > > > depending on the configuration. In order to reduce > the amount > > > > > > of configuration, I suggest using L=1& M=00, only when your > > > > > > payload is omitted and you want AIS/Truck Conditioning > > > > > > generated at the far end. And use another code > point such as > > > > > > L=1 & M=01 to indicate a valid payload, which doesn't need > > > > > > AIS/Trunk conditioning to be generated at the far-end. > > > > > > > > > > > > Similarly for L=0 & M=10, you may want to have another > > > > > > codepoint such as L=0 & M=01 if > > > > > > you want RDI/Trunk conditioning be generated, while > using L=0 > > > > > > &M=10 for the case that you don't want to generate > RDI/Trunk > > > > > > conditioning. > > > > > > > > > > > > In any case we have to make sure that the interpretation of > > > > > > these fields is the same for SAToP, CESoPSN, TDMoIP > > and Y.1413. > > > > > > > > > > > > Yours, > > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Luca Martini [mailto:lmartini@cisco.com] > > > > > > > Sent: Wednesday, May 05, 2004 11:49 AM > > > > > > > To: Sasha Vainshtein > > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > > > Subject: Re: [PWE3] > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > > > > Sasha, > > > > > > > > > > > > > > Indeed there are differences in the drafts , regarding > > > > > > > sequence numbers > > > > > > > handling , and control words. > > > > > > > This does not mean that it will be accepted by the > > IESG, and > > > > > > > it does not > > > > > > > mean we have free run of deigning even more > > different schemes. > > > > > > > > > > > > > > Definely we never meant to have different sequenced flows > > > > > > in the same > > > > > > > PW. This is not part of the architecture. > > > > > > > Please do not mistake merged flows within a PW with > > > > > separate flows > > > > > > > within the PW. > > > > > > > For example when many ATM VCs are transported as > one VP in > > > > > > a PW, they > > > > > > > are one flow, as they separate VCs have been > merged into a > > > > > > > single flow > > > > > > > in a PW. > > > > > > > > > > > > > > The point here is to create a standard that can > > re-use maybe > > > > > > > part of the > > > > > > > same hardware to transport different types of > PWs. It seems > > > > > > > to me that > > > > > > > even the sequencing in the tdm drafts should > conform to the > > > > > > > rest of PWE3 > > > > > > > designs. > > > > > > > > > > > > > > Note that I'm on vacation until monday , and desperately > > > > > > > attempting to > > > > > > > stay away from this computer ... ;-) > > > > > > > > > > > > > > > > > > > > > Bye > > > > > > > Luca > > > > > > > > > > > > > > Sasha Vainshtein wrote: > > > > > > > > > > > > > > >Yaakov and all, > > > > > > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > > > > > > >>To: Sasha Vainshtein > > > > > > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > > > > > > >>Subject: RE: [PWE3] > > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > >> > > > > > > > >> > > > > > > > >>... the plot thickens ... > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >>>[Sasha] Note also that the L2TPv3 L2-specific > > > sublayer also > > > > > > > >>>does not skip zero (in addition to providing a 24-bit > > > > > > > >>>sequence number). > > > > > > > >>> > > > > > > > >>> > > > > > > > >>as does RTP and just about every other > sequencing method. > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > > > > > > >This means that forthe same type of AC (FR), you have > > > > > > > >two different numbering methods: one for an MPLS PSN and > > > > > > > >another fo an IP PSN. So I agree with you that the plot > > > > > > > >thickens - but it leads further and further from the > > > > > > > >initial scope. > > > > > > > > > > > > > > > > > > > > > > > >>>[Sasha] I do not see it as a major architectural > > > > issue beyond > > > > > > > >>>the TDM. The difference between the TDM PWs and > > > the rest of > > > > > > > >>>them wrt packet loss is essential: TDM PWs MUST > > compensate > > > > > > > >>>each lost packet, while non-TDM can, by default, > > > simply drop > > > > > > > >>>mis-ordered packets. I would also glad to hear > > > from Stewart > > > > > > > >>>and from the WG at large on this subject. > > > > > > > >>> > > > > > > > >>> > > > > > > > >>The use of the zero sequence number is not the question. > > > > > > > >>The use of multiple sequencing streams in a > single PW is. > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >>>>I had interpreted "in-band" to mean "over the > > > same PSN", or > > > > > > > >>>>even "over thee same tunnel", not "over the same PW". > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>[Sasha] Unless things have changed drastically > > > from the last > > > > > > > >>>time I looked at the TDMoIP draft, you use two > types of > > > > > > > >>>packets - data and signaling - in the AAL2-based > > > mode - over > > > > > > > >>>the same PW. Or did I miss something? > > > > > > > >>> > > > > > > > >>> > > > > > > > >>No, you haven't missed anything. > > > > > > > >>The AAL2 method definitely has separate signaling > > > subframes, > > > > > > > >>which can be (depending on implementation) placed into > > > > > > > >>separate packets. Separate signaling packets share the > > > > > > > >>SAME sequence number series. However, this is > not critical > > > > > > > >>as in your case as the subframes have their own > > sequencing > > > > > > > (in the UUI > > > > > > > >>field). > > > > > > > >> > > > > > > > >>A long time I had considered the option of using > > > > > > > >>a separate sequencing method, but rejected it due > > > to its not > > > > > > > >>conforming > > > > > > > >>with what I considered a general architectural principle > > > > > > > >>(you will see in a moment why I consider this a > > fundamental > > > > > > > question). > > > > > > > >>That principle is that a PW carries a single flow. > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >[Sasha] This very much depends on what you define > > as a flow. > > > > > > > >E.g., the "port mode" of FR PWs carries multiple > > DLCIs which > > > > > > > >could be called "flows" as well. > > > > > > > >The current architecture does not refer to any > such notion, > > > > > > > >so, IMHO, everybody can presume what suits him/her best. > > > > > > > > > > > > > > > > > > > > > > > >>In particular: > > > > > > > >> 1) a PW is either sequenced or not > > > > > > > >> 2) when it is sequenced there is a single > > sequence per PW > > > > > > > >> > > > > > > > >>You are proposing multiple sequenced and unsequenced > > > > > > streams per PW. > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >[Sasha] I agree with you that a PW can be either > > > > sequenced or not > > > > > > > >and I have tried to convince the FR draft editor > to impose > > > > > > > >some such limitation. The current draft does not > > > > > preclude a mix of > > > > > > > >sequences (i.e., with non-zero SN) and unsequenced > > > > (with zero SN) > > > > > > > >PW packets on the same FR PW which, IMHO, should > be fixed. > > > > > > > >And, to the best of my understanding, I do NOT > propose any > > > > > > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > > > > > > > > > > > > > > > > >>In other words, you are proposing a third level of flow: > > > > > > > >> 1) A tunnel > > > > > > > >> 2) PWs in the tunnel > > > > > > > >> 3) flows in a PW > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >[Sasha] IMHO, this is goes far beyond my modest and > > > > > > > >very specific proposal. I am not sure that such a > > > > > > > >generalization is justified and definitely was not > > > > > > > >intended. Hence I find it difficult to answer your very > > > > > > > >generic questions below, BUT I believe I have answered > > > > > > > >some of them already (wrt setup) in the previous message. > > > > > > > > > > > > > > > > > > > > > > > >>Do we really want/need this third level? > > > > > > > >>Are there separate set-up and maintenance > > entities for this > > > > > > > >>third level? > > > > > > > >>Do I need VCCV, performance parameters, etc for this > > > > new level? > > > > > > > >> > > > > > > > >>We have already basically turned the PW into a > full-blown > > > > > > > >>layer network. > > > > > > > >>Taking over the job of a friend of ours :) I would > > > > > like to ask > > > > > > > >>whether we need to define yet another layer network > > > > > > inside this one? > > > > > > > >> > > > > > > > >>Y(J)S > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Mon, 10 May 2004 17:47:25 +0200 Lines: 552 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Mon May 10 17:08:30 2004 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Shaharm and all, Please see inline (marked SV-> to distinguish from my earlier ones). 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 10, 2004 4:42 PM > To: Sasha Vainshtein > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; 'Luca Martini' > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Hi Sasha, > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Monday, May 10, 2004 11:25 AM > > To: Shahram Davari > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > 'Luca Martini' > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Shahram and all, > > Please see some comments inline. > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Monday, May 10, 2004 4:03 PM > > > To: Sasha Vainshtein > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > 'Luca Martini' > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Hi Sasha, > > > > > > Mapping AIS from server to client is fine. So in you new > > [Sasha] Sorry to say, but is one and the same example > > all the way. Presumably I have not explained it well enough. > > > example if the fractional T1/E1 > > > indicates AIS, then again you must generated trunk > > > conditioning toward downstream. > > [Sasha] Bellcore TR-NWT-170 to which you refer defines requirements > > to digital cross-connect (DXC) systems. These systems, indeed, > > must generate trunk conditioning (namely, release telephony calls) > > on the downsream channels (timeslots) that have been affected > > by an upstream local ("red") or remote ("yelow") alarm. > > Now, structure-aware TDM PWs are NOT DXCs, nor are their IWFs. > > SD-> Have a look at ATM Forum's af-vtoa-0078.000. It requires > generating trunk conditioning > by the ATM network. So it is not restricted to DXCs. > SV->I am aware of that and also of the fact that af-vtoa-0078.000 includes the TDM NSP in the ATM CES IWF. Personally I prefer the IETF reference model. > > > The PWEe reference model has defines a dedicated element for > > handling this kind of functionality, namely the NSP. > > The draft under consideration postulates the need for an NSP > > for structure-aware TDM PWs. Such an NSP can be a plain E1/T1 > > framer, or it can support DXC functions as well. In the latter > > case, this DXC would implement traffic conditioning, and the > > only thing needed for this purpose is conveyance of the > > appropriate signals by the structure-aware TDM PW. > > OK, but a single flag can't tell the folowing to the PE: > > 1)A defect is detected at the other end, however you don't > need to generate > any RDI/trunk conditioning > 2) A defect is detected at the other end, and you need to generate > RDI/trunk conditioning > 3)There is no problem at the other end. > > > > > > > > You may want to generate > > > trunk conditioning at the PE that first detects TDM failure > > > (ingress PE), or at the egress PE. If you generate trunk > > > conditioning at the ingress PE , then you must tell the other > > > end not to generate trunk conditioning, but only send > > > whatever it receives to the customer. While if the ingress PE > > > can't generate trunk conditioning, it should tell the egress > > > PE to generate it. > > > > > > So there are only 2 cases, either the egress PE should or > > > should not generate trunk conditioning, depending on ingress > > > PE capabilities. That is why I asked for 2 L/M code points. > > > > > [Sasha] Please note that the two cases you describe are > > hardly dynamic. So, instead of carrying some indications in the > > data it is enough to configure the IWF to pass or not to pass > > signals received over the TDM PW to the local NSP. Please > > note that this does not increase the amount of local configuration, > > when compared with your proposal, just move some configuration > > from one end of the PW to the other. Note also that there is no need > > to exchange the NSP capabilities and desired behavior during the > > PW setup. > > This is avalid argument. SV-> I am glad we have reached some understanding. > > Yours, > -Shahram > > > > > > > Yours, > > > -Shahram > > > > > > > -----Original Message----- > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > Sent: Monday, May 10, 2004 10:40 AM > > > > To: Shahram Davari > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > 'Luca Martini' > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > Shaharam and all, > > > > Please consider the case when you want to emulate behavior of > > > > a regular E1/T1 trunk over a PW, but, since only a few timeslots > > > > are actually used on this trunk, you use structure-aware > > emulation. > > > > In this case - an this is the example I've tried to > > present for your > > > > consideration before,- AIS of an E1/T1 trunk observed > at one end > > > > of the PW must be translated to AIS at the other end of the PW. > > > > One of the reasons for that requirement can be the need > to trigger > > > > trunk conditioning in the corresponding CE (if this CE > is a DXC). > > > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Monday, May 10, 2004 3:36 PM > > > > > To: Sasha Vainshtein > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > > 'Luca Martini' > > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > Sasha, > > > > > > > > > > AIS of a few time slots should not generate AIS for the > > > whole T1/E1. > > > > > This is a principle of client/server AIS > relationship. Therefore > > > > > your example is moot. > > > > > > > > > > Yours, > > > > > Shahram > > > > > > > > > > > -----Original Message----- > > > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > > > Sent: Thursday, May 06, 2004 5:37 AM > > > > > > To: Shahram Davari > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > > > 'Luca Martini' > > > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > Shahram and all, > > > > > > I'd like to point out that the draft explicitly states the > > > > > > need for an appropriate NSP in order to provide structured > > > > > > TDM services. IMO, the Trunk Conditioning functionality you > > > > > > have mentioned is a "native TDM" function and hence should > > > > > > be performed by the NSP which would then act not just as > > > > > > a Framer but as a Digital Cross-Connect (DXC) system. > > > > > > > > > > > > I also do not think that using additional codepoints can > > > > > > reduce the need of configuration (which seems to be one of > > > > > > your concerns). E.g., the decision to generate or not to > > > > > > generate AIS towards the local CE cannot, IMO, be based > > > > > > solely on indications received by the CE-bound IWF instance. > > > > > > E.g., please consider the case where several groups > > of timeslots > > > > > > on the same TDM trunk act as ACs for different IWF > > > instances while > > > > > > "far ends" of the corresponding CESoPSN PWs use ACs > > > that originate > > > > > > in different trunks. Killing the entire "near end" > > > trunk with AIS > > > > > > just because AIS has been observed on one of the "far > > > end" trunks > > > > > > would hardly be the best possible solution. On the other > > > > > hand, making > > > > > > each "far end IWF" aware of the fatc that its peer shares > > > > (or does > > > > > > not share) the trunk with other IWF instances does > not look a > > > > > > good solution either. > > > > > > > > > > > > > > > > > > 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: Shahram Davari > [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > > Sent: Wednesday, May 05, 2004 8:22 PM > > > > > > > To: 'Luca Martini'; Sasha Vainshtein > > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > > > Subject: RE: [PWE3] > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > I also share the concern that Yaakov and Luca expressed > > > > regarding > > > > > > > the CAS packets multiplexed in the same PW. This would > > > > > require 2 seq > > > > > > > number tracking per PW. > > > > > > > > > > > > > > I also have another concern, but before I elaborate > > on that I > > > > > > > would like to mention that in structured emulation, the > > > > > > > network MUST generate Trunk conditioning as specified in > > > > > > > Bellcore TR-NWT-000170, rather than AIS/RDI. > > > > > > > > > > > > > > Now my concern: Based on Table 1: The > > Interpretation of bits > > > > > > > L and M in the CESoPSN CW, it appears that L=1& > M=00 may or > > > > > > > may not generate AIS/Truck conditioning at the far end, > > > > > > > depending on the configuration. In order to reduce > > the amount > > > > > > > of configuration, I suggest using L=1& M=00, only > when your > > > > > > > payload is omitted and you want AIS/Truck Conditioning > > > > > > > generated at the far end. And use another code > > point such as > > > > > > > L=1 & M=01 to indicate a valid payload, which > doesn't need > > > > > > > AIS/Trunk conditioning to be generated at the far-end. > > > > > > > > > > > > > > Similarly for L=0 & M=10, you may want to have another > > > > > > > codepoint such as L=0 & M=01 if > > > > > > > you want RDI/Trunk conditioning be generated, while > > using L=0 > > > > > > > &M=10 for the case that you don't want to generate > > RDI/Trunk > > > > > > > conditioning. > > > > > > > > > > > > > > In any case we have to make sure that the > interpretation of > > > > > > > these fields is the same for SAToP, CESoPSN, TDMoIP > > > and Y.1413. > > > > > > > > > > > > > > Yours, > > > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Luca Martini [mailto:lmartini@cisco.com] > > > > > > > > Sent: Wednesday, May 05, 2004 11:49 AM > > > > > > > > To: Sasha Vainshtein > > > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > > > > Subject: Re: [PWE3] > > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > > > > > > > Sasha, > > > > > > > > > > > > > > > > Indeed there are differences in the drafts , regarding > > > > > > > > sequence numbers > > > > > > > > handling , and control words. > > > > > > > > This does not mean that it will be accepted by the > > > IESG, and > > > > > > > > it does not > > > > > > > > mean we have free run of deigning even more > > > different schemes. > > > > > > > > > > > > > > > > Definely we never meant to have different > sequenced flows > > > > > > > in the same > > > > > > > > PW. This is not part of the architecture. > > > > > > > > Please do not mistake merged flows within a PW with > > > > > > separate flows > > > > > > > > within the PW. > > > > > > > > For example when many ATM VCs are transported as > > one VP in > > > > > > > a PW, they > > > > > > > > are one flow, as they separate VCs have been > > merged into a > > > > > > > > single flow > > > > > > > > in a PW. > > > > > > > > > > > > > > > > The point here is to create a standard that can > > > re-use maybe > > > > > > > > part of the > > > > > > > > same hardware to transport different types of > > PWs. It seems > > > > > > > > to me that > > > > > > > > even the sequencing in the tdm drafts should > > conform to the > > > > > > > > rest of PWE3 > > > > > > > > designs. > > > > > > > > > > > > > > > > Note that I'm on vacation until monday , and > desperately > > > > > > > > attempting to > > > > > > > > stay away from this computer ... ;-) > > > > > > > > > > > > > > > > > > > > > > > > Bye > > > > > > > > Luca > > > > > > > > > > > > > > > > Sasha Vainshtein wrote: > > > > > > > > > > > > > > > > >Yaakov and all, > > > > > > > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > > > > > > > >>To: Sasha Vainshtein > > > > > > > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > > > > > > > >>Subject: RE: [PWE3] > > > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>... the plot thickens ... > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>[Sasha] Note also that the L2TPv3 L2-specific > > > > sublayer also > > > > > > > > >>>does not skip zero (in addition to providing > a 24-bit > > > > > > > > >>>sequence number). > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>as does RTP and just about every other > > sequencing method. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >[Sasha] L2TPv3 is used to carry, say FR over an IP PSN. > > > > > > > > >This means that forthe same type of AC (FR), you have > > > > > > > > >two different numbering methods: one for an > MPLS PSN and > > > > > > > > >another fo an IP PSN. So I agree with you that the plot > > > > > > > > >thickens - but it leads further and further from the > > > > > > > > >initial scope. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>[Sasha] I do not see it as a major architectural > > > > > issue beyond > > > > > > > > >>>the TDM. The difference between the TDM PWs and > > > > the rest of > > > > > > > > >>>them wrt packet loss is essential: TDM PWs MUST > > > compensate > > > > > > > > >>>each lost packet, while non-TDM can, by default, > > > > simply drop > > > > > > > > >>>mis-ordered packets. I would also glad to hear > > > > from Stewart > > > > > > > > >>>and from the WG at large on this subject. > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>The use of the zero sequence number is not > the question. > > > > > > > > >>The use of multiple sequencing streams in a > > single PW is. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>>I had interpreted "in-band" to mean "over the > > > > same PSN", or > > > > > > > > >>>>even "over thee same tunnel", not "over the > same PW". > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>[Sasha] Unless things have changed drastically > > > > from the last > > > > > > > > >>>time I looked at the TDMoIP draft, you use two > > types of > > > > > > > > >>>packets - data and signaling - in the AAL2-based > > > > mode - over > > > > > > > > >>>the same PW. Or did I miss something? > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>No, you haven't missed anything. > > > > > > > > >>The AAL2 method definitely has separate signaling > > > > subframes, > > > > > > > > >>which can be (depending on implementation) placed into > > > > > > > > >>separate packets. Separate signaling packets share the > > > > > > > > >>SAME sequence number series. However, this is > > not critical > > > > > > > > >>as in your case as the subframes have their own > > > sequencing > > > > > > > > (in the UUI > > > > > > > > >>field). > > > > > > > > >> > > > > > > > > >>A long time I had considered the option of using > > > > > > > > >>a separate sequencing method, but rejected it due > > > > to its not > > > > > > > > >>conforming > > > > > > > > >>with what I considered a general > architectural principle > > > > > > > > >>(you will see in a moment why I consider this a > > > fundamental > > > > > > > > question). > > > > > > > > >>That principle is that a PW carries a single flow. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >[Sasha] This very much depends on what you define > > > as a flow. > > > > > > > > >E.g., the "port mode" of FR PWs carries multiple > > > DLCIs which > > > > > > > > >could be called "flows" as well. > > > > > > > > >The current architecture does not refer to any > > such notion, > > > > > > > > >so, IMHO, everybody can presume what suits > him/her best. > > > > > > > > > > > > > > > > > > > > > > > > > > >>In particular: > > > > > > > > >> 1) a PW is either sequenced or not > > > > > > > > >> 2) when it is sequenced there is a single > > > sequence per PW > > > > > > > > >> > > > > > > > > >>You are proposing multiple sequenced and unsequenced > > > > > > > streams per PW. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >[Sasha] I agree with you that a PW can be either > > > > > sequenced or not > > > > > > > > >and I have tried to convince the FR draft editor > > to impose > > > > > > > > >some such limitation. The current draft does not > > > > > > preclude a mix of > > > > > > > > >sequences (i.e., with non-zero SN) and unsequenced > > > > > (with zero SN) > > > > > > > > >PW packets on the same FR PW which, IMHO, should > > be fixed. > > > > > > > > >And, to the best of my understanding, I do NOT > > propose any > > > > > > > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > > > > > > > > > > > > > > > > > > > >>In other words, you are proposing a third > level of flow: > > > > > > > > >> 1) A tunnel > > > > > > > > >> 2) PWs in the tunnel > > > > > > > > >> 3) flows in a PW > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >[Sasha] IMHO, this is goes far beyond my modest and > > > > > > > > >very specific proposal. I am not sure that such a > > > > > > > > >generalization is justified and definitely was not > > > > > > > > >intended. Hence I find it difficult to answer your very > > > > > > > > >generic questions below, BUT I believe I have answered > > > > > > > > >some of them already (wrt setup) in the > previous message. > > > > > > > > > > > > > > > > > > > > > > > > > > >>Do we really want/need this third level? > > > > > > > > >>Are there separate set-up and maintenance > > > entities for this > > > > > > > > >>third level? > > > > > > > > >>Do I need VCCV, performance parameters, etc for this > > > > > new level? > > > > > > > > >> > > > > > > > > >>We have already basically turned the PW into a > > full-blown > > > > > > > > >>layer network. > > > > > > > > >>Taking over the job of a friend of ours :) I would > > > > > > like to ask > > > > > > > > >>whether we need to define yet another layer network > > > > > > > inside this one? > > > > > > > > >> > > > > > > > > >>Y(J)S > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Shahram Davari Subject: RE: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Mon, 10 May 2004 08:02:31 -0700 Lines: 594 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: "'Yaakov Stein'" , stbryant@cisco.com, pwe3@ietf.org, "'Luca Martini'" X-From: pwe3-admin@ietf.org Mon May 10 17:23:48 2004 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi Sasha, > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Monday, May 10, 2004 11:47 AM > To: Shahram Davari > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; 'Luca Martini' > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > Shaharm and all, > Please see inline (marked SV-> to distinguish > from my earlier ones). > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, May 10, 2004 4:42 PM > > To: Sasha Vainshtein > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > 'Luca Martini' > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > Hi Sasha, > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > Sent: Monday, May 10, 2004 11:25 AM > > > To: Shahram Davari > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > 'Luca Martini' > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > Shahram and all, > > > Please see some comments inline. > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Monday, May 10, 2004 4:03 PM > > > > To: Sasha Vainshtein > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > 'Luca Martini' > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > Hi Sasha, > > > > > > > > Mapping AIS from server to client is fine. So in you new > > > [Sasha] Sorry to say, but is one and the same example > > > all the way. Presumably I have not explained it well enough. > > > > example if the fractional T1/E1 > > > > indicates AIS, then again you must generated trunk > > > > conditioning toward downstream. > > > [Sasha] Bellcore TR-NWT-170 to which you refer defines > requirements > > > to digital cross-connect (DXC) systems. These systems, indeed, > > > must generate trunk conditioning (namely, release telephony calls) > > > on the downsream channels (timeslots) that have been affected > > > by an upstream local ("red") or remote ("yelow") alarm. > > > Now, structure-aware TDM PWs are NOT DXCs, nor are their IWFs. > > > > SD-> Have a look at ATM Forum's af-vtoa-0078.000. It requires > > generating trunk conditioning > > by the ATM network. So it is not restricted to DXCs. > > > SV->I am aware of that and also of the fact that af-vtoa-0078.000 > includes the TDM NSP in the ATM CES IWF. Personally I prefer > the IETF reference model. SD-> No matter how you slice it, the PE MUST generate trunk conditioning and not AIS/RDI for the structured mode. > > > > > The PWEe reference model has defines a dedicated element for > > > handling this kind of functionality, namely the NSP. > > > The draft under consideration postulates the need for an NSP > > > for structure-aware TDM PWs. Such an NSP can be a plain E1/T1 > > > framer, or it can support DXC functions as well. In the latter > > > case, this DXC would implement traffic conditioning, and the > > > only thing needed for this purpose is conveyance of the > > > appropriate signals by the structure-aware TDM PW. > > > > OK, but a single flag can't tell the folowing to the PE: > > > > 1)A defect is detected at the other end, however you don't > > need to generate > > any RDI/trunk conditioning > > 2) A defect is detected at the other end, and you need to generate > > RDI/trunk conditioning > > 3)There is no problem at the other end. > > > > > > > > > > > > > You may want to generate > > > > trunk conditioning at the PE that first detects TDM failure > > > > (ingress PE), or at the egress PE. If you generate trunk > > > > conditioning at the ingress PE , then you must tell the other > > > > end not to generate trunk conditioning, but only send > > > > whatever it receives to the customer. While if the ingress PE > > > > can't generate trunk conditioning, it should tell the egress > > > > PE to generate it. > > > > > > > > So there are only 2 cases, either the egress PE should or > > > > should not generate trunk conditioning, depending on ingress > > > > PE capabilities. That is why I asked for 2 L/M code points. > > > > > > > [Sasha] Please note that the two cases you describe are > > > hardly dynamic. So, instead of carrying some indications in the > > > data it is enough to configure the IWF to pass or not to pass > > > signals received over the TDM PW to the local NSP. Please > > > note that this does not increase the amount of local > configuration, > > > when compared with your proposal, just move some configuration > > > from one end of the PW to the other. Note also that there > is no need > > > to exchange the NSP capabilities and desired behavior during the > > > PW setup. > > > > This is avalid argument. > SV-> I am glad we have reached some understanding. OK. -Shahram > > > > Yours, > > -Shahram > > > > > > > > > > Yours, > > > > -Shahram > > > > > > > > > -----Original Message----- > > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > > Sent: Monday, May 10, 2004 10:40 AM > > > > > To: Shahram Davari > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > > 'Luca Martini' > > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > Shaharam and all, > > > > > Please consider the case when you want to emulate behavior of > > > > > a regular E1/T1 trunk over a PW, but, since only a > few timeslots > > > > > are actually used on this trunk, you use structure-aware > > > emulation. > > > > > In this case - an this is the example I've tried to > > > present for your > > > > > consideration before,- AIS of an E1/T1 trunk observed > > at one end > > > > > of the PW must be translated to AIS at the other end > of the PW. > > > > > One of the reasons for that requirement can be the need > > to trigger > > > > > trunk conditioning in the corresponding CE (if this CE > > is a DXC). > > > > > > > > > > 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: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > Sent: Monday, May 10, 2004 3:36 PM > > > > > > To: Sasha Vainshtein > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > > > 'Luca Martini' > > > > > > Subject: RE: [PWE3] draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > Sasha, > > > > > > > > > > > > AIS of a few time slots should not generate AIS for the > > > > whole T1/E1. > > > > > > This is a principle of client/server AIS > > relationship. Therefore > > > > > > your example is moot. > > > > > > > > > > > > Yours, > > > > > > Shahram > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > > > > Sent: Thursday, May 06, 2004 5:37 AM > > > > > > > To: Shahram Davari > > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org; > > > > > > 'Luca Martini' > > > > > > > Subject: RE: [PWE3] > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > > > > Shahram and all, > > > > > > > I'd like to point out that the draft explicitly states the > > > > > > > need for an appropriate NSP in order to provide structured > > > > > > > TDM services. IMO, the Trunk Conditioning > functionality you > > > > > > > have mentioned is a "native TDM" function and > hence should > > > > > > > be performed by the NSP which would then act not just as > > > > > > > a Framer but as a Digital Cross-Connect (DXC) system. > > > > > > > > > > > > > > I also do not think that using additional codepoints can > > > > > > > reduce the need of configuration (which seems to be one of > > > > > > > your concerns). E.g., the decision to generate or not to > > > > > > > generate AIS towards the local CE cannot, IMO, be based > > > > > > > solely on indications received by the CE-bound > IWF instance. > > > > > > > E.g., please consider the case where several groups > > > of timeslots > > > > > > > on the same TDM trunk act as ACs for different IWF > > > > instances while > > > > > > > "far ends" of the corresponding CESoPSN PWs use ACs > > > > that originate > > > > > > > in different trunks. Killing the entire "near end" > > > > trunk with AIS > > > > > > > just because AIS has been observed on one of the "far > > > > end" trunks > > > > > > > would hardly be the best possible solution. On the other > > > > > > hand, making > > > > > > > each "far end IWF" aware of the fatc that its peer shares > > > > > (or does > > > > > > > not share) the trunk with other IWF instances does > > not look a > > > > > > > good solution either. > > > > > > > > > > > > > > > > > > > > > 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: Shahram Davari > > [mailto:Shahram_Davari@pmc-sierra.com] > > > > > > > > Sent: Wednesday, May 05, 2004 8:22 PM > > > > > > > > To: 'Luca Martini'; Sasha Vainshtein > > > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > > > > Subject: RE: [PWE3] > > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > > > I also share the concern that Yaakov and Luca expressed > > > > > regarding > > > > > > > > the CAS packets multiplexed in the same PW. This would > > > > > > require 2 seq > > > > > > > > number tracking per PW. > > > > > > > > > > > > > > > > I also have another concern, but before I elaborate > > > on that I > > > > > > > > would like to mention that in structured emulation, the > > > > > > > > network MUST generate Trunk conditioning as > specified in > > > > > > > > Bellcore TR-NWT-000170, rather than AIS/RDI. > > > > > > > > > > > > > > > > Now my concern: Based on Table 1: The > > > Interpretation of bits > > > > > > > > L and M in the CESoPSN CW, it appears that L=1& > > M=00 may or > > > > > > > > may not generate AIS/Truck conditioning at the far end, > > > > > > > > depending on the configuration. In order to reduce > > > the amount > > > > > > > > of configuration, I suggest using L=1& M=00, only > > when your > > > > > > > > payload is omitted and you want AIS/Truck Conditioning > > > > > > > > generated at the far end. And use another code > > > point such as > > > > > > > > L=1 & M=01 to indicate a valid payload, which > > doesn't need > > > > > > > > AIS/Trunk conditioning to be generated at the far-end. > > > > > > > > > > > > > > > > Similarly for L=0 & M=10, you may want to have another > > > > > > > > codepoint such as L=0 & M=01 if > > > > > > > > you want RDI/Trunk conditioning be generated, while > > > using L=0 > > > > > > > > &M=10 for the case that you don't want to generate > > > RDI/Trunk > > > > > > > > conditioning. > > > > > > > > > > > > > > > > In any case we have to make sure that the > > interpretation of > > > > > > > > these fields is the same for SAToP, CESoPSN, TDMoIP > > > > and Y.1413. > > > > > > > > > > > > > > > > Yours, > > > > > > > > -Shahram > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Luca Martini [mailto:lmartini@cisco.com] > > > > > > > > > Sent: Wednesday, May 05, 2004 11:49 AM > > > > > > > > > To: Sasha Vainshtein > > > > > > > > > Cc: 'Yaakov Stein'; stbryant@cisco.com; pwe3@ietf.org > > > > > > > > > Subject: Re: [PWE3] > > > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > > > > > > > > > > > > > > > > > > > Sasha, > > > > > > > > > > > > > > > > > > Indeed there are differences in the drafts , > regarding > > > > > > > > > sequence numbers > > > > > > > > > handling , and control words. > > > > > > > > > This does not mean that it will be accepted by the > > > > IESG, and > > > > > > > > > it does not > > > > > > > > > mean we have free run of deigning even more > > > > different schemes. > > > > > > > > > > > > > > > > > > Definely we never meant to have different > > sequenced flows > > > > > > > > in the same > > > > > > > > > PW. This is not part of the architecture. > > > > > > > > > Please do not mistake merged flows within a PW with > > > > > > > separate flows > > > > > > > > > within the PW. > > > > > > > > > For example when many ATM VCs are transported as > > > one VP in > > > > > > > > a PW, they > > > > > > > > > are one flow, as they separate VCs have been > > > merged into a > > > > > > > > > single flow > > > > > > > > > in a PW. > > > > > > > > > > > > > > > > > > The point here is to create a standard that can > > > > re-use maybe > > > > > > > > > part of the > > > > > > > > > same hardware to transport different types of > > > PWs. It seems > > > > > > > > > to me that > > > > > > > > > even the sequencing in the tdm drafts should > > > conform to the > > > > > > > > > rest of PWE3 > > > > > > > > > designs. > > > > > > > > > > > > > > > > > > Note that I'm on vacation until monday , and > > desperately > > > > > > > > > attempting to > > > > > > > > > stay away from this computer ... ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > Bye > > > > > > > > > Luca > > > > > > > > > > > > > > > > > > Sasha Vainshtein wrote: > > > > > > > > > > > > > > > > > > >Yaakov and all, > > > > > > > > > >Please see some more 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: Wednesday, May 05, 2004 12:58 PM > > > > > > > > > >>To: Sasha Vainshtein > > > > > > > > > >>Cc: stbryant@cisco.com; pwe3@ietf.org > > > > > > > > > >>Subject: RE: [PWE3] > > > > draft-ietf-pwe3-cesopsn-00.txt LAST CALL > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>... the plot thickens ... > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>>[Sasha] Note also that the L2TPv3 L2-specific > > > > > sublayer also > > > > > > > > > >>>does not skip zero (in addition to providing > > a 24-bit > > > > > > > > > >>>sequence number). > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>as does RTP and just about every other > > > sequencing method. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >[Sasha] L2TPv3 is used to carry, say FR over > an IP PSN. > > > > > > > > > >This means that forthe same type of AC (FR), you have > > > > > > > > > >two different numbering methods: one for an > > MPLS PSN and > > > > > > > > > >another fo an IP PSN. So I agree with you > that the plot > > > > > > > > > >thickens - but it leads further and further from the > > > > > > > > > >initial scope. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>[Sasha] I do not see it as a major architectural > > > > > > issue beyond > > > > > > > > > >>>the TDM. The difference between the TDM PWs and > > > > > the rest of > > > > > > > > > >>>them wrt packet loss is essential: TDM PWs MUST > > > > compensate > > > > > > > > > >>>each lost packet, while non-TDM can, by default, > > > > > simply drop > > > > > > > > > >>>mis-ordered packets. I would also glad to hear > > > > > from Stewart > > > > > > > > > >>>and from the WG at large on this subject. > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>The use of the zero sequence number is not > > the question. > > > > > > > > > >>The use of multiple sequencing streams in a > > > single PW is. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>>>I had interpreted "in-band" to mean "over the > > > > > same PSN", or > > > > > > > > > >>>>even "over thee same tunnel", not "over the > > same PW". > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>[Sasha] Unless things have changed drastically > > > > > from the last > > > > > > > > > >>>time I looked at the TDMoIP draft, you use two > > > types of > > > > > > > > > >>>packets - data and signaling - in the AAL2-based > > > > > mode - over > > > > > > > > > >>>the same PW. Or did I miss something? > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>No, you haven't missed anything. > > > > > > > > > >>The AAL2 method definitely has separate signaling > > > > > subframes, > > > > > > > > > >>which can be (depending on implementation) > placed into > > > > > > > > > >>separate packets. Separate signaling > packets share the > > > > > > > > > >>SAME sequence number series. However, this is > > > not critical > > > > > > > > > >>as in your case as the subframes have their own > > > > sequencing > > > > > > > > > (in the UUI > > > > > > > > > >>field). > > > > > > > > > >> > > > > > > > > > >>A long time I had considered the option of using > > > > > > > > > >>a separate sequencing method, but rejected it due > > > > > to its not > > > > > > > > > >>conforming > > > > > > > > > >>with what I considered a general > > architectural principle > > > > > > > > > >>(you will see in a moment why I consider this a > > > > fundamental > > > > > > > > > question). > > > > > > > > > >>That principle is that a PW carries a single flow. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >[Sasha] This very much depends on what you define > > > > as a flow. > > > > > > > > > >E.g., the "port mode" of FR PWs carries multiple > > > > DLCIs which > > > > > > > > > >could be called "flows" as well. > > > > > > > > > >The current architecture does not refer to any > > > such notion, > > > > > > > > > >so, IMHO, everybody can presume what suits > > him/her best. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>In particular: > > > > > > > > > >> 1) a PW is either sequenced or not > > > > > > > > > >> 2) when it is sequenced there is a single > > > > sequence per PW > > > > > > > > > >> > > > > > > > > > >>You are proposing multiple sequenced and > unsequenced > > > > > > > > streams per PW. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >[Sasha] I agree with you that a PW can be either > > > > > > sequenced or not > > > > > > > > > >and I have tried to convince the FR draft editor > > > to impose > > > > > > > > > >some such limitation. The current draft does not > > > > > > > preclude a mix of > > > > > > > > > >sequences (i.e., with non-zero SN) and unsequenced > > > > > > (with zero SN) > > > > > > > > > >PW packets on the same FR PW which, IMHO, should > > > be fixed. > > > > > > > > > >And, to the best of my understanding, I do NOT > > > propose any > > > > > > > > > >UNSEQUENCED flows within a CESoPSN PW. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>In other words, you are proposing a third > > level of flow: > > > > > > > > > >> 1) A tunnel > > > > > > > > > >> 2) PWs in the tunnel > > > > > > > > > >> 3) flows in a PW > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >[Sasha] IMHO, this is goes far beyond my modest and > > > > > > > > > >very specific proposal. I am not sure that such a > > > > > > > > > >generalization is justified and definitely was not > > > > > > > > > >intended. Hence I find it difficult to > answer your very > > > > > > > > > >generic questions below, BUT I believe I > have answered > > > > > > > > > >some of them already (wrt setup) in the > > previous message. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>Do we really want/need this third level? > > > > > > > > > >>Are there separate set-up and maintenance > > > > entities for this > > > > > > > > > >>third level? > > > > > > > > > >>Do I need VCCV, performance parameters, etc > for this > > > > > > new level? > > > > > > > > > >> > > > > > > > > > >>We have already basically turned the PW into a > > > full-blown > > > > > > > > > >>layer network. > > > > > > > > > >>Taking over the job of a friend of ours :) > I would > > > > > > > like to ask > > > > > > > > > >>whether we need to define yet another layer network > > > > > > > > inside this one? > > > > > > > > > >> > > > > > > > > > >>Y(J)S > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > > > >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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Brungard, Deborah A, ALABS" Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Mon, 10 May 2004 11:24:05 -0500 Lines: 143 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "PWE3 \(IETF\)" X-From: pwe3-admin@ietf.org Mon May 10 19:10:01 2004 Return-path: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0 Thread-Topic: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call Thread-Index: AcQsVpJKDRTCICw6RFywT5VGN/r+jgKRrR+w To: , "Ron Cohen" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Stewart, Ron, all, Here's some minor edits to align with T1X1.5 updates to T1.105 (aligning = with 2001 version) and ITU-T updates: 6 SONET/SDH Maintenance Signals - as multiple functionalities (LTE, PTE, etc) may be supported at a NSP, = it may help clarify to add, "Failure detection capabilities and performance monitoring capabilities = will be dependent on the NSP functionality e.g. LTE, PTE, Tandem = Connection Monitoring (refer to [G.707]), or Non-intrusive Monitoring = (intermediate connection monitoring)." 6.1.1 AIS-P/V Indication - minor edits on included defects, and suggest to say "for example" as = SDH and SONET differ on AIS insertion: "The mapping of SONET/SDH failures into the PATH/VT layer is considered = part of the NSP function, and is based on the principles specified in = [GR253], [SONET], [G.707], [G.806], and [G.783]. Should for example the = Section Layer detect a Loss of Signal (LOS) or Loss of Frame (LOF) or = Section Trace Mismatch (TIM) conditions, it sends AIS-L up to the Line = Layer. If the Line Layer detects AIS-L or Loss of Pointer (LOP), it = sends AIS-P to the Path Layer. If the Path Layer detects AIS-P or UNEQ-P = or TIM-P or PLM-P and is terminated at the NSP (i.e. PTE), it sends = AIS-V to the VT Layer. Note, a non-intrusive monitor only detects = failures, it must not do AIS insertion." 6.1.2 Unequipped Indication - minor edit to add test signal differentiation: "The declaration of SPE/VT unequipped MUST conform to [GR253], [SONET], = or [G806] and [G783]. [GR253] detection is based on the presence of an = unequipped Signal Label. [SONET]/SDH detection is based on the presence = of an unequipped Signal Label and an all zeros Trail Trace Identifier = (TTI) to distinguish the presence of an unequipped signal or a [SONET] = test signal (Supervisory-Unequipped [G707])." - suggest to remove the next paragraph "STS PTE shall detect an STS Path = Unequipped (UNEQ-P) defect..". The detection/clearing definition used = for the UNEQ defect is based on GR253, G783 has a different defect = detection. As AIS defect detection is also not included in the draft, = the first paragraph referring to the appropriate standards is = sufficient. 9.1 Near-end Performance Monitors - suggest adding a CEP-NE failure similar to the CEP-FE failure (section = 9.2), "CEP Near-end (CEP-NE) failure is declared after 2.5 +/- 0.5 seconds of = Type 2 CEP defect, and cleared after 10 seconds free of CEP defect = state. Sending notification to the OS for CEP failure is local policy." 10 Payload Compression Options - suggest adding a sentence on use of DBA (at end of 2nd paragraph) to = clarify: "The use of DBA will be dependent on network architectures e.g. support = of Tandem Connection Monitoring, test signals." Regards, Deborah -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Stewart Bryant Sent: Tuesday, April 27, 2004 8:25 AM To: Ron Cohen Cc: PWE3 (IETF) Subject: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call This formally starts the two week Last Call process. Last Call will end Wednesday 12th May - Stewart Ron Cohen wrote: > Dear PWE3ers >=20 > The updated CEP draft is now available at > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-05.txt >=20 > Below please find the list of modification made since the 04 version. > The authors believe the draft is now ready for last call.=20 >=20 > 1. Section 11: Signaling of CEP pseudo-wires: Added mandatory/optional > attribute for each parameter. Clarified which error codes are returned > when signaling fails and referenced the IANA draft for actual values. > Added a table of values for the CEP/TDM bit rate parameter. Fixed > language. >=20 > 2. Draft 04 appendix B discussing actual payload sizes of fractional > payload compression modes was folded into section 10. This removed > duplication of data and clarified in-context the actual payload sizes. > Verify that the draft body (without appendixes) includes all = information > required for implementation and interoperability. >=20 > 3. Removed non-ASCII characters. Aligned formats and language (DS-3, = DS3 > and T3 to T3). Removed empty open issues section. Added VT payload = size > table. Updated authors contact addresses.=20 >=20 > 4. Security section rewritten >=20 > Thanks > Ron & Co-authors >=20 > Ron Cohen > CTO > Lycium Networks=20 > Mobile: 650.823.7672 > Mobile: +972.55.245.104 > Tel: 650.234.4010 > Fax: 650.854.8183 >=20 > = =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 > 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. >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Ron Cohen" Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Mon, 10 May 2004 09:52:37 -0700 Lines: 167 Sender: pwe3-admin@ietf.org References: <449B2580D802A443A923DABF3EAB82AF06A300C6@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'PWE3 \(IETF\)'" X-From: pwe3-admin@ietf.org Mon May 10 19:10:33 2004 Return-path: To: "'Brungard, Deborah A, ALABS'" , 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 In-Reply-To: <449B2580D802A443A923DABF3EAB82AF06A300C6@OCCLUST04EVS1.ugd.att.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Deborah, Thanks for the review. I went over all the comments below and intend to incorporate them in the draft unless there are objections from the mailing list. Thanks a lot! Ron > -----Original Message----- > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > Sent: Monday, May 10, 2004 9:24 AM > To: stbryant@cisco.com; Ron Cohen > Cc: PWE3 (IETF) > Subject: RE: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call > > > Stewart, Ron, all, > > Here's some minor edits to align with T1X1.5 updates to > T1.105 (aligning with 2001 version) and ITU-T updates: > > 6 SONET/SDH Maintenance Signals > - as multiple functionalities (LTE, PTE, etc) may be > supported at a NSP, it may help clarify to add, > "Failure detection capabilities and performance monitoring > capabilities will be dependent on the NSP functionality e.g. > LTE, PTE, Tandem Connection Monitoring (refer to [G.707]), or > Non-intrusive Monitoring (intermediate connection monitoring)." > > 6.1.1 AIS-P/V Indication > - minor edits on included defects, and suggest to say "for > example" as SDH and SONET differ on AIS insertion: > "The mapping of SONET/SDH failures into the PATH/VT layer is > considered part of the NSP function, and is based on the > principles specified in [GR253], [SONET], [G.707], [G.806], > and [G.783]. Should for example the Section Layer detect a > Loss of Signal (LOS) or Loss of Frame (LOF) or Section Trace > Mismatch (TIM) conditions, it sends AIS-L up to the Line > Layer. If the Line Layer detects AIS-L or Loss of Pointer > (LOP), it sends AIS-P to the Path Layer. If the Path Layer > detects AIS-P or UNEQ-P or TIM-P or PLM-P and is terminated > at the NSP (i.e. PTE), it sends AIS-V to the VT Layer. Note, > a non-intrusive monitor only detects failures, it must not do > AIS insertion." > > 6.1.2 Unequipped Indication > - minor edit to add test signal differentiation: > "The declaration of SPE/VT unequipped MUST conform to > [GR253], [SONET], or [G806] and [G783]. [GR253] detection is > based on the presence of an unequipped Signal Label. > [SONET]/SDH detection is based on the presence of an > unequipped Signal Label and an all zeros Trail Trace > Identifier (TTI) to distinguish the presence of an unequipped > signal or a [SONET] test signal (Supervisory-Unequipped [G707])." > > - suggest to remove the next paragraph "STS PTE shall detect > an STS Path Unequipped (UNEQ-P) defect..". The > detection/clearing definition used for the UNEQ defect is > based on GR253, G783 has a different defect detection. As AIS > defect detection is also not included in the draft, the first > paragraph referring to the appropriate standards is sufficient. > > 9.1 Near-end Performance Monitors > - suggest adding a CEP-NE failure similar to the CEP-FE > failure (section 9.2), > "CEP Near-end (CEP-NE) failure is declared after 2.5 +/- 0.5 > seconds of Type 2 CEP defect, and cleared after 10 seconds > free of CEP defect state. Sending notification to the OS for > CEP failure is local policy." > > 10 Payload Compression Options > - suggest adding a sentence on use of DBA (at end of 2nd > paragraph) to clarify: > "The use of DBA will be dependent on network architectures > e.g. support of Tandem Connection Monitoring, test signals." > > Regards, > Deborah > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Stewart Bryant > Sent: Tuesday, April 27, 2004 8:25 AM > To: Ron Cohen > Cc: PWE3 (IETF) > Subject: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call > > > This formally starts the two week Last Call process. > > Last Call will end Wednesday 12th May > > - Stewart > > > Ron Cohen wrote: > > Dear PWE3ers > > > > The updated CEP draft is now available at > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-05.txt > > > > Below please find the list of modification made since the > 04 version. > > The authors believe the draft is now ready for last call. > > > > 1. Section 11: Signaling of CEP pseudo-wires: Added > mandatory/optional > > attribute for each parameter. Clarified which error codes > are returned > > when signaling fails and referenced the IANA draft for > actual values. > > Added a table of values for the CEP/TDM bit rate parameter. Fixed > > language. > > > > 2. Draft 04 appendix B discussing actual payload sizes of fractional > > payload compression modes was folded into section 10. This removed > > duplication of data and clarified in-context the actual > payload sizes. > > Verify that the draft body (without appendixes) includes > all information > > required for implementation and interoperability. > > > > 3. Removed non-ASCII characters. Aligned formats and > language (DS-3, DS3 > > and T3 to T3). Removed empty open issues section. Added VT > payload size > > table. Updated authors contact addresses. > > > > 4. Security section rewritten > > > > Thanks > > Ron & Co-authors > > > > 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. > > > > > > > > _______________________________________________ > > 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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Andrew G. Malis" Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Mon, 10 May 2004 20:54:00 -0400 Lines: 181 Sender: pwe3-admin@ietf.org References: <449B2580D802A443A923DABF3EAB82AF06A300C6@OCCLUST04EVS1.ugd.att.com> <002b01c436af$34162620$230110ac@lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Brungard, Deborah A, ALABS'" , , "'PWE3 \(IETF\)'" X-From: pwe3-admin@ietf.org Tue May 11 03:08:30 2004 Return-path: X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: "Ron Cohen" In-Reply-To: <002b01c436af$34162620$230110ac@lycium.net> References: <449B2580D802A443A923DABF3EAB82AF06A300C6@OCCLUST04EVS1.ugd.att.com> <002b01c436af$34162620$230110ac@lycium.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , I would also like to publicly thank Deborah for her very detailed review. Cheers, Andy --------- At 5/10/2004 09:52 AM -0700, Ron Cohen wrote: >Deborah, > >Thanks for the review. I went over all the comments below and intend to >incorporate them in the draft unless there are objections from the >mailing list. > >Thanks a lot! >Ron > > > -----Original Message----- > > From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > Sent: Monday, May 10, 2004 9:24 AM > > To: stbryant@cisco.com; Ron Cohen > > Cc: PWE3 (IETF) > > Subject: RE: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call > > > > > > Stewart, Ron, all, > > > > Here's some minor edits to align with T1X1.5 updates to > > T1.105 (aligning with 2001 version) and ITU-T updates: > > > > 6 SONET/SDH Maintenance Signals > > - as multiple functionalities (LTE, PTE, etc) may be > > supported at a NSP, it may help clarify to add, > > "Failure detection capabilities and performance monitoring > > capabilities will be dependent on the NSP functionality e.g. > > LTE, PTE, Tandem Connection Monitoring (refer to [G.707]), or > > Non-intrusive Monitoring (intermediate connection monitoring)." > > > > 6.1.1 AIS-P/V Indication > > - minor edits on included defects, and suggest to say "for > > example" as SDH and SONET differ on AIS insertion: > > "The mapping of SONET/SDH failures into the PATH/VT layer is > > considered part of the NSP function, and is based on the > > principles specified in [GR253], [SONET], [G.707], [G.806], > > and [G.783]. Should for example the Section Layer detect a > > Loss of Signal (LOS) or Loss of Frame (LOF) or Section Trace > > Mismatch (TIM) conditions, it sends AIS-L up to the Line > > Layer. If the Line Layer detects AIS-L or Loss of Pointer > > (LOP), it sends AIS-P to the Path Layer. If the Path Layer > > detects AIS-P or UNEQ-P or TIM-P or PLM-P and is terminated > > at the NSP (i.e. PTE), it sends AIS-V to the VT Layer. Note, > > a non-intrusive monitor only detects failures, it must not do > > AIS insertion." > > > > 6.1.2 Unequipped Indication > > - minor edit to add test signal differentiation: > > "The declaration of SPE/VT unequipped MUST conform to > > [GR253], [SONET], or [G806] and [G783]. [GR253] detection is > > based on the presence of an unequipped Signal Label. > > [SONET]/SDH detection is based on the presence of an > > unequipped Signal Label and an all zeros Trail Trace > > Identifier (TTI) to distinguish the presence of an unequipped > > signal or a [SONET] test signal (Supervisory-Unequipped [G707])." > > > > - suggest to remove the next paragraph "STS PTE shall detect > > an STS Path Unequipped (UNEQ-P) defect..". The > > detection/clearing definition used for the UNEQ defect is > > based on GR253, G783 has a different defect detection. As AIS > > defect detection is also not included in the draft, the first > > paragraph referring to the appropriate standards is sufficient. > > > > 9.1 Near-end Performance Monitors > > - suggest adding a CEP-NE failure similar to the CEP-FE > > failure (section 9.2), > > "CEP Near-end (CEP-NE) failure is declared after 2.5 +/- 0.5 > > seconds of Type 2 CEP defect, and cleared after 10 seconds > > free of CEP defect state. Sending notification to the OS for > > CEP failure is local policy." > > > > 10 Payload Compression Options > > - suggest adding a sentence on use of DBA (at end of 2nd > > paragraph) to clarify: > > "The use of DBA will be dependent on network architectures > > e.g. support of Tandem Connection Monitoring, test signals." > > > > Regards, > > Deborah > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > > Stewart Bryant > > Sent: Tuesday, April 27, 2004 8:25 AM > > To: Ron Cohen > > Cc: PWE3 (IETF) > > Subject: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call > > > > > > This formally starts the two week Last Call process. > > > > Last Call will end Wednesday 12th May > > > > - Stewart > > > > > > Ron Cohen wrote: > > > Dear PWE3ers > > > > > > The updated CEP draft is now available at > > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-05.txt > > > > > > Below please find the list of modification made since the > > 04 version. > > > The authors believe the draft is now ready for last call. > > > > > > 1. Section 11: Signaling of CEP pseudo-wires: Added > > mandatory/optional > > > attribute for each parameter. Clarified which error codes > > are returned > > > when signaling fails and referenced the IANA draft for > > actual values. > > > Added a table of values for the CEP/TDM bit rate parameter. Fixed > > > language. > > > > > > 2. Draft 04 appendix B discussing actual payload sizes of fractional > > > payload compression modes was folded into section 10. This removed > > > duplication of data and clarified in-context the actual > > payload sizes. > > > Verify that the draft body (without appendixes) includes > > all information > > > required for implementation and interoperability. > > > > > > 3. Removed non-ASCII characters. Aligned formats and > > language (DS-3, DS3 > > > and T3 to T3). Removed empty open issues section. Added VT > > payload size > > > table. Updated authors contact addresses. > > > > > > 4. Security section rewritten > > > > > > Thanks > > > Ron & Co-authors > > > > > > 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. > > > > > > > > > > > > _______________________________________________ > > > 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-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Yaakov Stein" Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Tue, 11 May 2004 09:44:21 +0300 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "PWE3 \(IETF\)" X-From: pwe3-admin@ietf.org Tue May 11 09:10:40 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call Thread-Index: AcQ2sXaZ3Fpmy5R4SpKeSWSFnhrOTgAbw8fw To: "Ron Cohen" , "Andrew G. Malis" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Ron/Andy,=20 I have a question about the original of the term "DBA" you use in the draft. Earlier versions had a reference after the first use of the term ([CEP-SPE]), but unfortunately this reference didn't resolve. It has since been removed altogether. Was this term previously used in a similar context or was is sui generis ? The reason I ask is that to me "Dynamic Bandwidth Allocation" sounds much more like LCAS=20 than a mechanism that simply suppresses transmission=20 of a payload known to be meaningless. =20 In SAToP, CESoPSN and TDMoIP we have a similar optional mechanism whereby bandwidth=20 can be conserved when the TDM input is meaningless, but we avoid such an impressive nomenclature. Actually, I believe that the entire concept of conserving bandwidth=20 by suppressing defective TDM payloads is a bit suspect. Carrier class TDM has "five nines" reliability,=20 so the amount of BW conserved will certainly be below=20 one tenth of one percent. This can hardly be called significant bandwidth conservation, let alone dynamic bandwidth allocation. For enterprise TDM the "network" is often a single link, so its chance of failure is equally small. So why do we bother? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: David Zelig Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Tue, 11 May 2004 10:21:55 +0200 Lines: 62 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: "PWE3 (IETF)" X-From: pwe3-admin@ietf.org Tue May 11 09:47:31 2004 Return-path: To: "'Yaakov Stein'" , Ron Cohen , "Andrew G. Malis" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Yaakov, The difference between SONET and the pure TDM case is that a SONET signal may contain significant portion of unequipped payloads, so network wide with large number of connections you can take advantage of the statistical saving. For AIS, I agree that the saving is non-significant but once the mechanism is there why not use it? David > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, May 11, 2004 8:44 AM > To: Ron Cohen; Andrew G. Malis > Cc: PWE3 (IETF) > Subject: RE: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call > > > Ron/Andy, > > I have a question about the original of the term "DBA" you use in the > draft. > > Earlier versions had a reference after the first use of the term > ([CEP-SPE]), > but unfortunately this reference didn't resolve. > It has since been removed altogether. > > Was this term previously used in a similar context > or was is sui generis ? > > The reason I ask is that to me "Dynamic Bandwidth Allocation" > sounds much more like LCAS > than a mechanism that simply suppresses transmission > of a payload known to be meaningless. > > In SAToP, CESoPSN and TDMoIP > we have a similar optional mechanism whereby bandwidth > can be conserved when the TDM input is meaningless, > but we avoid such an impressive nomenclature. > > Actually, I believe that the entire concept of conserving bandwidth > by suppressing defective TDM payloads is a bit suspect. > > Carrier class TDM has "five nines" reliability, > so the amount of BW conserved will certainly be below > one tenth of one percent. This can hardly be called > significant bandwidth conservation, > let alone dynamic bandwidth allocation. > > For enterprise TDM the "network" > is often a single link, so its chance of failure is equally small. > > So why do we bother? > > Y(J)S > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Tue, 11 May 2004 11:30:04 +0100 Lines: 78 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , X-From: pwe3-admin@ietf.org Tue May 11 12:51:50 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call Thread-Index: AcQ2sXaZ3Fpmy5R4SpKeSWSFnhrOTgAbw8fwAAc/t6A= To: , , X-OriginalArrivalTime: 11 May 2004 10:30:05.0078 (UTC) FILETIME=[ECA45B60:01C43742] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi Yaakov....small remark (in support) below. regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Yaakov Stein > Sent: 11 May 2004 07:44 > To: Ron Cohen; Andrew G. Malis > Cc: PWE3 (IETF) > Subject: RE: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call >=20 >=20 > Ron/Andy,=20 >=20 > I have a question about the original of the term "DBA" you use in the > draft. >=20 > Earlier versions had a reference after the first use of the term > ([CEP-SPE]), > but unfortunately this reference didn't resolve. > It has since been removed altogether. >=20 > Was this term previously used in a similar context > or was is sui generis ? >=20 > The reason I ask is that to me "Dynamic Bandwidth Allocation" > sounds much more like LCAS=20 > than a mechanism that simply suppresses transmission=20 > of a payload known to be meaningless. =20 >=20 > In SAToP, CESoPSN and TDMoIP > we have a similar optional mechanism whereby bandwidth=20 > can be conserved when the TDM input is meaningless, > but we avoid such an impressive nomenclature. >=20 > Actually, I believe that the entire concept of conserving bandwidth=20 > by suppressing defective TDM payloads is a bit suspect. NH=3D> I agree. I think you would find others (eg Maarten) who would = also agree....probably even more strongly than I do. The rationale you = give in the para below is compelling IMO. Aside - I also think that the compression of clients is something to be = avoided in general because I do not believe the benefits (BW savings) = outweigh the (management) consequences of violating the architectural = requirement for client/server independence. Real networks don't run = near their congestion-knee over the vast majority of their life, ie = planning cycles are relatively long (and these increase as we move = towards the duct), and one can't in general exceed ~70% load at the end = of the current planning cycle for resilience reasons, noting that this = must include the effects of daily peak/mean variation too. And if you = start stacking layer networks (which one invariably does) the efficiency = fill of the top layer can be quite low, eg 4 nested layer networks each = at 70% load (ie remarkably high) =3D 24% max fill. As a general = observation, we should be looking to use BW wisely to remove = complexity.....we should not be seeking to add complexity (read = 'opex/capex' costs) to save small amounts of BW. This also has = implications wrt the real benefit of having lots of QoS classses too and = ensuring consistent/meaningful service differentiation over a large = range of load points....but that is another story. >=20 > Carrier class TDM has "five nines" reliability,=20 > so the amount of BW conserved will certainly be below=20 > one tenth of one percent. This can hardly be called > significant bandwidth conservation, > let alone dynamic bandwidth allocation. >=20 > For enterprise TDM the "network" > is often a single link, so its chance of failure is equally small. >=20 > So why do we bother? >=20 > Y(J)S >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20