Subject: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 10 Jun 2003 18:12:37 +0200

Stewart, Danny and all,
As (some of) you have probably noticed I have posted an 
updated (-06) revision of the CESoPSN draft.

I would like to ask the WG to adopt this draft as a WG item, 
and this message is intended to initiate a TECHNICAL discussion
on this subject.

Allow me to present my major points wrt the -06 revision:

Compatibility with the Requirements and Architecture Documents
==============================================================

The -06 revision of the draft explicitly answers the following requirements:

1. The requirements stated in the WG Charter
2. Common PWE3 requirements as stated in draft-ietf-pwe3-requirements-05.txt
3. Specific requirements for emulation of TDM services as stated in
   draft-ietf-pwe3-tdm-requirements-00.txt
4. The PWE3 architectural principles as presented in
draft-ietf-pwe3-arch-03.txt.
5. Additional requirements that have been identified during discussions
   in the WG and in the (unpublished) disucssions of the TDM design team,
   including ability to preserve packetization latency regardless of
   the bit rate of the emulated Nx64 kbit/s service

Formerly Raised Technical Issues
================================

The -06 revision of the draft addresses all the technical isssue 
that have ever been raised with the previous revisions. In particular:

1. It allows BW-saving suppression of RTP headers when the
   information carried in these headers cannot contribute
   to the truthfulness of the emulation
2. It defines a new mode for carrying trunk-specific Nx64 
   kbit/s services with CAS which:
   a) Does not mandate usage of RTP for synchronization between
      TDM data and telephony application signaling
   b) Does not break the principle of fixed packetization time 
      for emulation of TDM services
3. It defines, as mandatory, raw encapsulation of unstructured T1 
   without any intermediate adaptation.
  
Independent Interoperable Implementations
=========================================

A series of successful interoperability tests between 
independent CESoPSN implementations has been completed lately. 
The following ones have been publicly announced:

1.  http://www.rad.com/Article/0,6583,13305,00.html
2.  http://www.axerra.com/pr15.html
3.  http://www.axerra.com/pr16.html
4.  http://www.reduxcom.com/News/Issues/030527_WiMark/index.html

I would like to ask the WG participants to break their silence and
to provide the input that is required to advance the subject of 
TDM emulation over PSN in the WG.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 09, 2003 1:45 PM
> Cc: [email-masked]
> Subject: I-D ACTION:draft-vainshtein-cesopsn-06.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: TDM Circuit Emulation Service over 
> Packet Switched 
>                           Network (CESoPSN)
> 	Author(s)	: S. Vainshtein et al.
> 	Filename	: draft-vainshtein-cesopsn-06.txt
> 	Pages		: 38
> 	Date		: 2003-6-6
> 	
> This document describes a method for encapsulating unstructured  (T1, 
> E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over 
> packet-switching networks (PSN). In this regard, it 
> complements similar 
> work for SONET/SDH. 
>  
> Proposed PW encapsulation uses RTP for clock recovery and leverages 
> RTP-based mixing capabilities for application state signaling between 
> Customer Edge (CE) devices.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> 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-vainshtein-cesopsn-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:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-vainshtein-cesopsn-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: Shahram Davari <[email-masked]>
Date: Wed, 11 Jun 2003 08:32:02 -0700

Sasha,

Could you please explain the setup used fo the first interop bullet. Did you interoperate with TDMoIP?

-Shahram

>From: Sasha Vainshtein [mailto:[email-masked]]
>Sent: Tuesday, June 10, 2003 12:13 PM
>To: Stewart Bryant (E-mail); Danny McPherson (E-mail); PWE3 WG (E-mail)
>Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim 
>Frost (E-mail); Prayson Pate (E-mail)
>Subject: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt
>
>
>Stewart, Danny and all,
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 12 Jun 2003 11:22:33 +0200

Shahram and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> From: Shahram Davari [mailto:[email-masked]]
... snipped ...
> Did you interoperate with TDMoIP?
NO.

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 12 Jun 2003 12:58:42 +0300

> > Did you interoperate with TDMoIP?

I was afraid that Sasha's email
this would lead to this type of misunderstanding.

As a favor to our friends at Axerra, RAD implemented CESoIP
on a version of our low-end (software only) box 
by a software modification
(i.e. removing the adaptation and changing the control word).

This was a one-time effort on our part, 
and is not part of our standard product line.

This cooperation between our two companies
does NOT imply any that RAD has accepted CESoIP, 
nor that Axerra has adopted TDMoIP.

Y(J)S

---

From: Michel Khouderchah <[email-masked]>
Date: Thu, 12 Jun 2003 03:38:57 -0700

Sasha,

Correction to my previous comments.

Please ignore the first comment. Your formula is correct.
The second comment is still valid.

Regards,

Michel

>Date: Thu, 12 Jun 2003 03:06:12 -0700
>To: Sasha Vainshtein <[email-masked]>
>From: Michel Khouderchah <[email-masked]>
>Subject: Re: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt
>Cc: [email-masked], [email-masked]
>
>Saha,
>
>I have the following minor corrections/comments on your latest draft
>  (BTW, the new additions are very useful!):
>
>1. Section      6.2.3:
>         “ 2. The packet payload size is:
>          a) 16*n + floor((n+1)/2) for E1-Nx64 kbit/s
>          b) 24*n + floor((n+1)/2) for T1/ESF-Nx64 kbit/s and T1/SF-Nx64
>             kbit/s”
>
>The above is Correct if n is odd, but when n is even floor((n+1)/2)
>  should be changed to floor (n/2).
>
>
>
>2. The following sentences in section 6.2.3 and 4.1.2 are inconsistent:
>
>Section      6.2.3
>“CESoPSN implementations supporting trunk-specific Nx64 kbit/s services
>with CAS MUST NOT carry more TDM data per packet than is contained in a
>single trunk multiframe”  … “All CESoPSN implementations supporting
>trunk-specific Nx64 kbit/s with CAS MUST support the default mode where
>  a single CESoPSN packet carries exactly one trunk multiframe aligned
>with the packet payload. “
>
>
>Section  4.1.2.
>“Note: For T1 trunks using SF format (12 frames per multiframe),
>CESoPSN preserves the structure comprising two consecutive trunk
>multiframes. This consideration is aligned with [ATM-CES].”
>
>The description in section 6.2.3  is true in the case of T1/ESF
>( multiframe = 24 frames); However, in the case of T1/SF
>(multiframe = 12 frames) a single packet is actually carrying
>exactly two multiframes not one. The proposed structure
>is certainly aligned with [ATM-CES], but the phrases “exactly
>one trunk multiframe” or “single trunk multiframe” are a bit
>misleading in the case of T1/SF.  I would suggest rewording
>of the statements in section 6.2.3.
>
>Regards,
>
>Michel
>
>
>
>
>At 09:12 AM 6/10/2003, Sasha Vainshtein wrote:
>>Stewart, Danny and all,

---

From: Shahram Davari <[email-masked]>
Date: Thu, 12 Jun 2003 06:46:52 -0700

Sasha,

Did RAD's box implement CESoPSN?

-Shahram

>From: Sasha Vainshtein [mailto:[email-masked]]
>Sent: Thursday, June 12, 2003 5:23 AM
>To: Shahram Davari; Stewart Bryant (E-mail); Danny McPherson 
>(E-mail); PWE3 WG (E-mail)
>Subject: RE: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt
>
>
>Shahram and all,
>Please see inline.
>
>With best regards,
>                                   Sasha Vainshtein

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 12 Jun 2003 19:40:03 +0200

Shahram,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> Did RAD's box implement CESoPSN?
YES.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 12 Jun 2003 11:12:54 -0700

Danny,

I think my view is known. I prefer the Anavi draft (aka TDMoIP), due to its usage
of a known and proven technology (i.e, AAL1) and its ease of interworking with
ATM CES. 

Yours,
-Shahram

>From: Danny McPherson [mailto:[email-masked]]
>Sent: Thursday, June 12, 2003 12:57 PM
>To: Sasha Vainshtein; Stewart Bryant (E-mail); PWE3 WG (E-mail)
>Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim Frost
>(E-mail); Prayson Pate (E-mail)
>Subject: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt
>
>
>If there are other folks that would like to see this document 
>become a WG
>item please speak up now.
>
>-danny
>
>On 6/10/03 10:12 AM, "Sasha Vainshtein" <[email-masked]> wrote:
>
>> Stewart, Danny and all,

---

From: "Yaakov Stein" <[email-masked]>
Date: Fri, 13 Jun 2003 09:00:24 +0300

> become a WG item please speak up now.

Other than Sasha finally making RTP optional,
I don't see anything new in this revision
that could influence our decision.

Hence, I am very much AGAINST adopting
this draft in any form.

If, however, we go back to draft-johnson and make the 
pointer mechanism mandatory
(so that the structured mode is not an "unstructured structured" mode)
and fix up a few other minor errors,
then I would be willing to support that becoming
a WG draft.

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Sun, 15 Jun 2003 10:19:02 +0200

Danny,

I support adopting this draft as a WG item. 

Regards
Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Danny McPherson
> Sent: Thursday, June 12, 2003 6:57 PM
> > I would like to ask the WG to adopt this draft as a WG 
> item, and this 
> > message is intended to initiate a TECHNICAL discussion on this 
> > subject.
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 15 Jun 2003 09:17:46 +0300

> I would like to see this draft become a WG item. The latest 
> enhancements offer a good compromise to achieve convergence of Anavi and
> Johnson drafts.

Michel, 

Can you elaborate on this convergence that you see?

I hope you are not being fooled by the new draft's
frequent references to ATM-CES --- these references
are either to general descriptive material in that standard,
or to CAS functions, and in no way imply that this new
draft has become any closer to draft-anavi.

Indded, the only major updates to CESoPSN that I see 
actually make it LESS like TDMoIP.

1) There is a new default mode for CAS 
wherein the packet MUST contain a full multiframe.

This is a major DIVERGENCE from draft-anavi,
the entire philosophy of which is to break the locking
between TDM structures and packets
in order to enable flexible selection of packet size and latency.

2) The partial awakening of the CESoPSN authors to the 
fact that they were the only strong promoters of RTP.
So they decided top promote RTP header compression
as well.

This is also a divergence from draft-anavi
which for political reasons has a vague reference to RTP,
but certainly does not promote investing in complex
(and expensive from the IPR viewpoint) header compression
schemes in order to ameliorate its ill effects.

3) The elevation of the following statement to "requirement" level:
   Fixed end-to-end delay: CESoPSN implementations SHOULD provide 
   the same end-to-end delay between any given pair of PEs 
   regardless of the bit-rate of the emulated service. 

I have commented in the past at great length about the total artificiality
of requiring two different links to have the same delay,
only in order to force a given implementation which happens
to have this "feature".
This un-natural requirement is of course entirely alien to draft-anavi.

4) Optional "ECMP Prevention" Word 
This is of course not needed in draft-anavi, as it uses
the standard PWE control word.

Y(J)S

---

From: "Amnon Ilan" <[email-masked]>
Date: Mon, 16 Jun 2003 10:30:42 +0200

Danny,

I'm against adopting the CESoPSN draft. I also prefer the TDMoIP draft.
Mainly because it is based on VoATM standards:
1. proven technology.
2. easier market acceptance.
3. easier acceptance by other bodies (ITU, MPLS-Forum) and higher
   chance for compatible standards.
To add on Shahram's view: I think the support for AAL2 is also very
important for future acceptence and interworking with VoATM, 3G etc.

Regards,
Amnon.

>---------------------------------------------------------------------------
-----

---

From: "Amnon Ilan" <[email-masked]>
Date: Mon, 16 Jun 2003 18:08:40 +0200

Danny,

I'm against adopting the CESoPSN draft. I support the TDMoIP draft
Mainly because it is based on VoATM standards:
1. proven technology (AAL1, AAl2 and TDMoIP itself).
2. easier market acceptance.
3. easier acceptance by other bodies (ITU, MPLS-Forum) and higher
   chance for compatible standards.
To add on Shahram's view: I think the support for AAL2 is also very
important for future acceptence and interworking with VoATM, 3G etc.

Regards,
Amnon.

-----

---

From: [email-masked]
Date: Mon, 16 Jun 2003 18:57:22 +0100

I support this view.  However, I do draw a distinction between a cnls server
layer of IP and co pkt-sw server layer of MPLS.  I see no point in
elaborating on this further, save to point out the rather obvious fact that
if they had not the potential to provide different capabilities then one
would not need both would one?

regards, Neil

> From: Amnon Ilan [mailto:[email-masked]]
> Sent: 16 June 2003 09:31
> To: [email-masked]; [email-masked]
> Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt
> 
> 
> Danny,
> 
> >I think my view is known. I prefer the Anavi draft (aka 
> TDMoIP), due to its
> usage
> >of a known and proven technology (i.e, AAL1) and its ease of 
> interworking
> with
> >ATM CES.
> >
> >Yours,
> >-Shahram
> >

---

From: "Uri Rotshtein" <[email-masked]>
Date: Mon, 16 Jun 2003 18:15:53 +0300

I would also recommend adopting this draft as WG item. For all this CES market we should close the standard ASAP.

Uri.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Sunday, June 15, 2003 9:18 AM
To: Michel Khouderchah
Cc: Alexander Vainshtein; PWE3 WG (E-mail)
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Michel, 

Y(J)S

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Jun 2003 09:29:20 +0300

I am in favor this draft becoming a WG item. This standard is needed, and this approach seems to be the one that comes closer to catching significant support. The number of participants in the process supporting the standard seems to exceed by far the threshold that would ensure interoperable implementations and further advancement of the standard. Further work as WG item, and the quality review that standards track I-Ds go through will only help in refining the details and clearing up possible problems.

Dan

> Sent: Thursday, June 12, 2003 7:57 PM

---

From: Danny McPherson <[email-masked]>
Date: Tue, 17 Jun 2003 07:52:47 -0600

On 6/17/03 12:29 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

> I am in favor this draft becoming a WG item. This standard is needed, and this
> approach seems to be the one that comes closer to catching significant
> support. The number of participants in the process supporting the standard
> seems to exceed by far the threshold that would ensure interoperable
> implementations and further advancement of the standard.

Really?  Can you elaborate on this (i.e., how many other folks have/are
implementing this)?

Thanks!

-danny

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Jun 2003 17:17:00 +0300

Danny,

I am seeing the messages that you are seeing - maybe less :-)

Assuming that people who declared their support are doing it on a responsible manner, it looks that there are more than two independent implementations on the way.  

Dan

> Sent: Tuesday, June 17, 2003 4:53 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 17 Jun 2003 21:33:07 +0300

> Really?  Can you elaborate on this (i.e., how many other 
> folks have/are implementing this)?

Sasha quotes 4 interoperable implementations,
RAD, Redux,  Ericsson, and Engage.

As I have said in previous emails RAD does NOT
support CESoPSN in our standard product line.
This "interop" was a one-time effort to supply small
remote boxes to interoperate with CESoPSN central site
for a given sales opportunity.

>From their latest spec sheets, Redux only supports unframed
raw bit transport, and thus could only possibly support draft-vainshtein
in unstructured E1 mode. Unless they have something new
and unpublished, they can't possibly support draft-vainshtein
for T1 or in structured modes.

I don't know what modes Engage and Ericsson support,
but it would be interesting to hear. I am guessing that
the Engage implementation (being software on a small
processor) is also unstructured,
but perhaps Sasha could enlighten us.

Incidentally, draft-anavi presently has several interoperable
implementations that support unstructured and structured  modes,
and at least two commercial chip-sets are coming out in the near future. 

Perhaps Dan is refering to verbal support,
rather than actual implementations.
So far I see 6:5 in favor of CESoPSN:

FOR CESoPSN:
    1. Sasha - Axerra
    2. Ron Cohen - Lycium
    3. Michel Khouderchah - Cisco
    4. Uri Rotshtein - Redux
    5. Max Riegel - Siemens
    6. Dan Romascanu - Avaya

AGAINST (i.e. for TDMoIP)
    1. Yaakov - RAD
    2. Shahram - PMC
    3. Alex Conta - TranSwitch
    4. Amnon Ilan - Nbase
    5. Neil Harrison - BT

which is pretty close to 50-50.
Since I am going to be issuing an update
of draft-anavi, we can go through this
again and see what support draft-anavi has - 
the answer will probably be about the same.

Finally, perhaps Dan is refering to deployments.
draft-anavi has well over 10,000 deployed ports,
many of which have been functioning for several
years already.  Can we get some figures on
active deployments (not betas) from the CESoPSN
implementations ?  
I know that this sounds terribly crass, 
but don't we deserve to hear if this stuff 
has really been tested in the field? 

Y(J)S

---

From: Alik Shimelmits <[email-masked]>
Date: Wed, 18 Jun 2003 09:08:57 +0200

Yaakov,
just for being accurate you should not forget that draft-vainshtein has the
following co-authors:

Tim Frost (Zarlink) - the company provides CESoPSN chip demonstrated at the
last Supercomm,
Prayson Pate (Overture) - the company has working system (also demonstrated
at the last Supercomm),
Edward Metz (Thrupoint)

With best regards
	Alik

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Tuesday, June 17, 2003 8:33 PM
To: Danny McPherson; Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

FOR CESoPSN:
    1. Sasha - Axerra
    2. Ron Cohen - Lycium

Y(J)S

---

From: Michel Khouderchah <[email-masked]>
Date: Tue, 17 Jun 2003 23:59:47 -0700

Yaakov,

No I'm not fooled by the references to ATM-CES, nor am I fooled
by draft-Anavi as the only way to salvation! The fact is that the authors
of draft-Vainshtein have adopted most of Johnson's formats with
the exception of the structure pointer, which remains to be a steamy issue
with this WG . IMO, this is a step in the right direction and similar
compromise is required from draft-Anavi camp to reach convergence on the
basic format.  Let us face it, unless comprises are made from both sides
(Vainshtein and Anavi authors) this WG will most likely end up with more
than one draft. Even the  interworking between these two drafts is
unlikely if there is no agreement on a basic format. That
is not going to serve anyone on this WG!

Thus, the first step toward convergence is to reach an agreement on
the basic format knowing that it is a compromise (i.e. does solve all the
problems, but the limitations it introduces are acceptable). The next step
is to introduce other optional formats, which can be adopted from both
Vainshtein and Anavi drafts, that are more efficient and appropriate for 
certain
deployment scenarios.  The basic format must be supported by all
implementations, but not all the optional formats need to be supported by all.

I think that all the drafts have pros and cons depending on the  assumed
deployment scenarios, and that the never-ending disagreements on the
convergence to a single format is unlikely to bear fruit any time soon. This
is due to the following basic premises, from which all the disagreement
seem to stem from.

1.      In camp Anavi the main thrust is based on adapting  existing
   ATM-CES structures and the associated advantages (using existing AAL1 SARs,
proven technology, ease of  interworking with ATM-CES,..). The disadvantage
of this approach is that CES over IP/MPLS will be limited by the existing
ATM-CES structures and AAL1 SARs. Therefore, any future feature or service
must be artificially made to fit into ATM-CES structures. BTW, if interworking
with existing ATM-CES is to be addressed fully, then SRTS clock recovery
should be addressed in draft-Anavi.  SRTS is the recommend approach by ITU,
for obvious reasons, and constitute the majority of deployed  unstructured 
ATM-CES .
2.      In camp Vainshtein the main thrust is based on supporting flexible 
and native CES
  over IP/MPLS without restriction to existing ATM-CES structures. The 
basic argument
  here is why carry the baggage and restrictions of ATM-CES in all CES over 
IP/MPLS
  deployments even when interworking with ATM is not required?

We can keep on arguing the issues till the cows come home, but sooner or
later we need to work on convergence and make compromises. Are you ready
to make a compromise?

Regards,
Michel

---

From: [email-masked]
Date: Wed, 18 Jun 2003 09:48:18 +0100

Alik took the words out of my mouth!

Yes we do have a CESoPSN implementation that we demonstrated at Supercomm 
this year, running across the MEF core network. This implementation is 
completely separate to any of the implementations mentioned so far in this 
thread. So there are many separate implementations of this standard. We 
have not run interoperability trials yet, but these are being planned to 
happen soon.

Just for the record, I support this draft going through as a WG standard. 
As I understand it , independent co-authors should be counted separately.

Regards,
Tim

Alik Shimelmits <[email-masked]>
Sent by: [email-masked]
18-Jun-2003 08:08 AM

        To:     Yaakov Stein <[email-masked]>, Danny McPherson <[email-masked]>, 
"Romascanu, Dan (Dan)" <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Yaakov,
just for being accurate you should not forget that draft-vainshtein has 
the
following co-authors:

Tim Frost (Zarlink) - the company provides CESoPSN chip demonstrated at 
the
last Supercomm,
Prayson Pate (Overture) - the company has working system (also 
demonstrated
at the last Supercomm),
Edward Metz (Thrupoint)

With best regards
                 Alik

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Tuesday, June 17, 2003 8:33 PM
To: Danny McPherson; Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

FOR CESoPSN:
    1. Sasha - Axerra
    2. Ron Cohen - Lycium

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 18 Jun 2003 12:15:10 +0300

> Yes we do have a CESoPSN implementation that we demonstrated 
> at Supercomm this year, running across the MEF core network. This 
> implementation is completely separate to any of the implementations mentioned 
> so far in this thread. 

Great news. Actually I heard from some people
who saw your demo that it looked impressive.

> So there are many separate implementations of this 
> standard. We have not run interoperability trials yet, but these are being 
> planned to happen soon.
> 
> Just for the record, I support this draft going through as a 
> WG standard. As I understand it , independent co-authors should be counted 
> separately.

As far as I understand, support means non-authors.
(One would assume that draft authors support their own draft)

Y(J)S

---

From: [email-masked]
Date: Wed, 18 Jun 2003 10:53:35 +0100

So if I were to take my name off the draft, I could then support it, while 
with my name on the draft I'm not counted?
OK, but you'd better take Sasha off your list of supporters, since he is 
an author - makes it 5-5.
Whatever, you all know I support the draft...

By the way, thanks for the compliment, we were pleased with the demo. And 
to return the favour, I understand you had a implementation of draft-anavi 
there too, running on the MPLS Forum stand.

We both have technologies that work. That doesn't make it any easier to 
choose between them :-)

Tim

"Yaakov Stein" <[email-masked]>
Sent by: [email-masked]
18-Jun-2003 10:15 AM

        To:     <[email-masked]>
        cc:     "Danny McPherson" <[email-masked]>, <[email-masked]>
        Subject:        RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 18 Jun 2003 14:15:50 +0300

>  I'm not fooled by the references to ATM-CES, nor am I fooled
> with this WG.

I see that you are new to this subject.
It wasn't that draft-vainshtein adopted most of draft-johnson,
it was simply that Johnson adopted almost all of CESoPSN.

If you see anything in the newer versions that were taken
from draft-johnson that didn't exist in earlier versions
of draft-vainshtein, I am interested in hearing about it.

> IMO, this is a step in the right direction and similar
> than one draft. 

The compromise was PRECISELY the structure pointer.
I WAS willing to give up everything, throwing out all of 
draft-anavi, except the requirement for a structure pointer 
(which is an absolute necessity for my applications).  
draft-johnson started off as exactly draft-vainshtein 
EXCEPT for the structure pointer,
and I reluctantly WAS willing to accept that.
But then the CESoPSN camp insisited that the structure pointer 
be removed (or become an unused option),
leaving me without functionality that I required.

In other words, first I compromised by throwing out all
of draft-anavi and accepting draft-vainshtein,
except for one small improvement that would allow
me to function, and NOW you say that I should
compromise and forget about that as well.

To come to me now and say that CESoPSN supporters compromised 
but I am intransigent demonstrates total ignorance of what transpired.
I would suggest going back and reading the drafts before
making baseless statements to the list.

> Even the  interworking between these two drafts is 
> unlikely if there is no agreement on a basic format. 
> That is not going to serve anyone on this WG! 

What do you mean by interworking between the two drafts?
In earlier versions of draft-anavi I put in a CESoPSN mode
for the unstructured case - as a suggested compromise.
I also co-authored with Sasha a draft (uCESoPSN)
that suggested precisely that mode as the commonality.
We then reached a full compromise in Atlanta,
but the other camp backed down after 2 weeks.

> problems, but the limitations it introduces are acceptable). 

Why should I make compromises that leave problems unsolved
when I have a method that solves all my problems?

Purely political compromises that produce deficient standards
are not in anyone's interest. 

> The next step is to introduce other optional formats, 
> which can be adopted from both Vainshtein and Anavi drafts, 
> that are more efficient and appropriate for certain

This is just what was agreed in Atlanta,
and I am still willing to go back to that agreement.

> must be artificially made to fit into ATM-CES structures. 

Can you give an example of what future feature
in your opinion can not be handled by TDMoIP?

> BTW, if interworking
> for obvious reasons, and constitute the majority of deployed  unstructured ATM-CES . 

SRTS can certainly be used in any draft-anavi implementations
that have a physical layer clock to reference.
Unfortunately, few IP or MPLS networks have end-to-end
physical clock integrity.
If there is no consistent physical layer clock,
then SRTS (which encodes the difference between the source 
clock and the physical layer clock) can not work,
no matter what I write in a draft.
But if it makes you happy I will let you use SRTS.

> 2.  In camp Vainshtein the main thrust is based on supporting flexible and native CES > over IP/MPLS without restriction to existing ATM-CES structures. The basic argument 
> here is why carry the baggage and restrictions of ATM-CES in all CES over IP/MPLS 

What baggage do you think TDMoIP has?
If you read the draft you will see that we do NOT have ATM baggage
(e.g. we do NOT carry the ATM header).
Also I suggest comparing the two drafts to see which
has more "baggage" - you will find that TDMoIP has less baggage.
For example, why does CESoPSN use the CEP header rather than
the standard PWE control word, when it doesn't use the structure
pointer? Just baggage.

> later we need to work on convergence and make compromises. Are you ready 

draft-anavi supporters made the compromises sooner - 
too bad you came into the picture later. 

I am still willing to return to the previously agreed 
upon compromises - in all of which I gave up practically 
everything in my draft and adopted essentially CESoPSN
but with the required additions to solve practical problems.

I am also more than willing to hear about new compromises,
but in order not to fall into the same trap as last time
I want first to hear what compromise the other side is willing 
to make. 

Y(J)S

---

From: Rina Nathaniel <[email-masked]>
Date: Wed, 18 Jun 2003 08:50:06 +0300

Rina Nathaniel

This mail was sent via mail.alvarion.com
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 18 Jun 2003 16:54:51 +0200

Yaakov,
In case you have missed this item while reading CESoPSN-06:

CESoPSN-06 now supports trunk-specific Nx64 kbit/s with CAS and 
that the default payload format for these services coinsides with the 
default payload format for these services in draft-johnson. 

As far as I remember, you have strongly emphasized the need to support
trunk-specific Nx64 kbit/s services with CAS in the past.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, June 18, 2003 1:16 PM
> To: Michel Khouderchah
> Cc: PWE3 WG (E-mail)
> > 2.  In camp Vainshtein the main thrust is based on 
> supporting flexible and native CES > over IP/MPLS without 
> restriction to existing ATM-CES structures. The basic argument

---

From: Shahram Davari <[email-masked]>
Date: Wed, 18 Jun 2003 07:09:23 -0700

Hi,

As I recall the first compromise reached was in Atlanta, where the design team agreed that the unstructured mode be done according to CESoPSN and the structured mode be done according to TDMoIP. Later on the CESoPSN camp backed off from their compromise.

The second compromise was initiated by Johnson, which was essentially CESoPSN with 
a structure pointer, which was accepted by TDMoIP camp (although it didn't preserve anything from TDMoIP), but was soon rejected by CESoPSN camp, because they didn't like the structure pointer.

So As far as I can see, it is the CESoPSN camp that is unwilling to compromise not the TDMoIP camp.

Yours,
-Shahram

>Sent: Wednesday, June 18, 2003 7:16 AM
>To: Michel Khouderchah
>Cc: PWE3 WG (E-mail)

---

From: [email-masked]
Date: Wed, 18 Jun 2003 22:40:33 +0100

Tim,

Can you please clarify *who* this draft aimed at?  Is it's usage in:
Internet?  ISPs?  Enterprises?  Carriers?  I must admit I find it really
hard to understand just who lots of CCAMPs stuff is aimed at in the general
case.  I just re-read it and IMO its awful from a large carriers perspective
(but then we have many problems with much of the PWE stuff from a functional
architecture perspective.....hopefully I don't have to explain why!).
However, I would not want to stop anyone using this, just so long as its
target audience is clear and its not being sold as the solution for
everyone.

regards, Neil

> From: [email-masked] [mailto:[email-masked]]
> Sent: 18 June 2003 09:48
> To: Alik Shimelmits
> Cc: Danny McPherson; Romascanu, Dan (Dan); [email-masked];
> [email-masked]; Yaakov Stein
> at Supercomm 
> WG standard.

---

From: "Rotshtein" <[email-masked]>
Date: Wed, 18 Jun 2003 19:12:44 +0300

Yaakov,

Regarding your claims:

a) Cisco, Avaya and Siemens support CESoPSN - that's a big industry
statement
b) Deployment of 5k links is miniscule compared to what the market will be -
the OEMs cannot bind themselves to a messy technical solution and a
monopolistic silicon source because of 5k links.
c) The interop of Axerra, Redux, Engage, Ericsson shows that this is a
working technology
d) Just to set thing straight, Redux supports structured and unstructured
E1/T1 in working silicon (not as you stated)

Uri.

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Tuesday, June 17, 2003 9:33 PM
To: Danny McPherson; Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

FOR CESoPSN:
    1. Sasha - Axerra
    2. Ron Cohen - Lycium

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 19 Jun 2003 08:23:21 +0300

Uri, 

> a) Cisco, Avaya and Siemens support CESoPSN - that's a big industry

As Max has said to the list several times,
Siemens also uses TDMoIP.

Regarding Cisco, their business units are independent,
and so while one may chose CESoPSN,
another may chose TDMoIP.
In fact, we too have units being evaluated at Cisco.
 
> monopolistic silicon source because of 5k links.

I just checked my calendar, and the year is no longer 2000.
We have been hearing about this fantastically large market
potential for several years now, I think the time has come for
you to prove it. In the meantime, only TDMoIP seems to be
selling.

> c) The interop of Axerra, Redux, Engage, Ericsson shows that this is a

As I asked before, what modes were tested?
If you are talking about simple unstructured, then they will
interop with TDMoIP in raw mode as well.

> d) Just to set thing straight, Redux supports structured and 
> unstructured E1/T1 in working silicon (not as you stated).

In that case I suggest that you update your marketing literature.
Can you send me a new spec sheet?

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 19 Jun 2003 09:18:58 +0300

Hi everyone, 

Redux has asked to me to clarify
that my information about their chip's capabilities
was derived from a "product announcement"
and not from a "spec sheet".

They have further informed me that the information 
that I gleaned from their web site, 
and in their news flashes sent by email,
is partial, and therefore potentially misleading.

In plain English - I don't have any inside information
about their chip. All I know is what they publish.

Y(J)S

---

From: Shahram Davari <[email-masked]>
Date: Thu, 19 Jun 2003 06:52:39 -0700

Uri,

>unstructured

Redux website says:

http://www.metroethernetforum.net/apps/org/workgroup/technical

"The StelaGate RS-160 is a single chip solution for point-to-point
tunneling of unstructured E1/T1/J1 over Ethernet-based and HDLCbased
packet links."

So obviously this needs correction.

BTW is the structured T1/E1 transported in structured mode or unstructured mode?
If the former have you tested it in the Interop?

Thanks,
-Shahram

---

From: Nurit Sprecher <[email-masked]>
Date: Sun, 22 Jun 2003 10:18:51 +0200

Hi,
I have been passively following the debate over draft-vainshtein vs.
draft-anavi for some time, and still don't understand one thing.
draft-anavi uses techniques borrowed from ATM, in order to maintain
compatibility to existing CES systems. It thus a pointer to maintains frame
alignment.
draft-vainshtein maintains TDM frame alignment by always sending an integral
number of frames in a packet.
Why do we need to maintain frame alignment at all?
>From the TDM reconstruction point of view, all we need is to play out the
bits that are in the receive buffer, and the TDM switch will take care of
all the rest.
If a packet is lost, all we need to know is how many bits it contained - so
all we need is to have a constant size packet!1
I vote against accepting draft-vainshtein.
For the unstructured case we need a simpler method - just constant size
packets!
For those complex cases where we need structured (especially with CAS) we
might as well use draft-anavi.
Nurit.

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Jun 2003 14:59:02 +0200

Nurit and all,
... snipped ...
> Why do we need to maintain frame alignment at all?
draft-vainshtein DOES NOT maintain "frame alignment for 
UNSTRUCTURED services - pease see Section 6.3.1.
"Frame alignment" across the PW MUST be provided for STRUCTURED
(Nx64 kbit/s with and without CAS) services. The reason: 
once the PW has been terminated at the egress PE, separate
64 kbit/s channels in the bundle may go to different destinations 
in the access TDM network. This happens even if the "access TDM network" 
is represented by a single P2P CE<-->PE TDM trunk. 
... snipped ...
>
> If a packet is lost, all we need to know is how many bits it 
> contained - so all we need is to have a constant size packet!
>
This is EXACTLY what draft-vainshtein (Section 3.2.3) specifies
as an explicit requirement. And this requirement is satisfied 
by the solution proposed in the draft.
... snipped ...
> 
> For the unstructured case we need a simpler method - just 
> constant size packets!
>
This is EXACTLY what draft-vainsthein says (please read Section 6.3.1).

I suggest you re-read draft-vainshtein. I will be happy to 
answer your specific questions/suggestions after that.
... snipped ...

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 23 Jun 2003 15:33:22 +0300

Sasha, 

I think that Nurit has a point.

Can you explain in simple terms why 
you need to have packet payload's of 
multiples of 125 microseconds?

If there is no packet loss any number of bytes
per packet is properly reproduced.

If there is packet loss, as long as I know 
how many bytes are sent in each packet
I can send the proper amount of interpolation data,
and the TDM interface is happy.

Y(J)S

> From: Alexander Vainshtein 
> Sent: Monday, June 23, 2003 3:59 PM
> To: 'Nurit Sprecher'
> Cc: [email-masked]'

---

From: "Amnon Ilan" <[email-masked]>
Date: Mon, 23 Jun 2003 17:23:57 +0200

Hi,

I agree with Nurit that there is no need for the CESoPSN draft.
We can have only two basic solutions:
1. The simple (simplistic) one: unstructured bitstream.
2. The more sophisticated one: TDMoIP.

The simple approach is limited since it requires a very good PSN
(very low packet loss and PDV): small frame loss may cause the loss
of frame alignment (and many E1\T1 applications are not robust
enough to minimize the effect of such a problem). This approach
is also very sensitive to loss of timing synchronization.
However, it is simple, easy to implement, and may be used on cases
where the PSN is good enough, or when the E1\T1 line itself is
unstructured.
The more sophisticated approach is much more robust: having framers
at the edge prevents loss of frame alignment (the effect of corrupted
data inside some of the time-slots is much less severe then the one
caused by loss of frame alignment). The structured modes of both
TDMoIP and CESoPSN address these issues.
However, IMO, TDMoIP is much more comprehensive: for example
see the issue of silence suppression. Most of E1\T1 lines are voice
trunks and for such trunks silence suppression may save more then
50% of network traffic. The only way to support silence suppression
is by using the AAL2 mode of TDMoIP. That is to add on the issues
of market acceptance and chances for compatible standards (ITU,
MPLS-Forum) mentioned in my previous email.

Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Nurit
Sprecher
Sent: Sun 22 June 2003 10:19
To: [email-masked]'
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Hi,

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Jun 2003 19:30:35 +0200

Yaakov,
... snipped ... 
> multiples of 125 microseconds?
For UNSTRUCTURED services, the draft explicitly allows 
ANY(!) packet latency. 

Since the WG has decided that a mandatory default 
MUST be defined, the draft specifies such a default
on a per service basis. 

The default chosen in the draft carries, IMO, some added 
value. As YOU have taught the WG some time ago, 
the egress IWF of an unstructured TDM PW must 
preserve correct FAS to avoid the TDM CE interface to declare
an OOF (or AIS) condition due to loss of a single PW packet. 
(Low-end E1 framers are more sensitive in this regard).
Since FAS is periodic, packet latency that is a multiple of 
the FAS period, makes this task TRIVIAL while using other 
packet latencies makes this task DIFFICULT. 

For STRUCTURED services the answer is different - please see
Section 6.2 of the draft.

Let's try not to mix these two cases (structured vs unstructured).
They are different.
... snipped to the end ...

Regards,
                      Sasha

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Jun 2003 19:37:10 +0200

Ilan,
... snipped ...
> 1. The simple (simplistic) one: unstructured bitstream.
The CESoPSN draft does exactly that for unstructured services. 
In addition it solves the problem of packet loss and facilitates
high-quality clock recovery when necessary. 
> 2. The more sophisticated one: TDMoIP.
The idea to have two absolutely different approaches for structured
and unstructured services has been discussed by the WG and rejected 
in the past. 
With best regards,
                                   Sasha Vainshtein

---

From: [email-masked]
Date: Tue, 24 Jun 2003 10:44:51 +0100

Nurit,

Thank you for your email. I will try and address some of the points you 
raise.

Firstly you point out that for unstructured emulation, we simply need 
constant size packets. Thank you for your vote of confidence, this is 
exactly what CESoPSN does in the unstructured case.

Secondly, you have posed the question "why do we need frame aligment?". 
This is only maintained in the structured (N x 64kbit/s) case, and these 
are some of the reasons why.

In AAL1, the cell size is fixed, therefore a pointer system is required to 
indicate the start of any structure within the cell stream. The pointer 
here is a necessary element to get around the fixed cell size.

In an IP or MPLS network, the packet size is free to vary. This can be 
exploited to simplify the encapsulation method. The basic structure in a 
TDM trunk is the 125us frame. Therefore the approach in CESoPSN is to 
carry a whole number of such structures in the packet. Hence it is 
exploting the nature of an IP or MPLS network to carry the stuctures 
already present in the data

Frame alignment is not required for its own sake, but it does convey a 
number of advantages:
- eliminates the need for a pointer, since the pointer is implicit (always 
0)
- operators can set up PWs with different values of N to the same latency, 
simplifying network management and QoS
- using a fixed cell size, the granularity of packetization delay may be 
very high for small values of N - with CESoPSN it can always be adjusted 
in 125 us units

One more point - you mention the advantages of a constant size packet. We 
should not confuse a constant size packet for a given PW with the use of 
the same size packet across all PWs (e.g. the fixed cell size of ATM). 
CESoPSN does maintain a constant size packet for a given pseudo-wire. Once 
the PW has been set up with a given latency, the packet size does not 
vary. So as you state below, when a packet is lost, we know exactly how 
many bits have been lost and need reconstructing. The reconstruction 
itself can use any of the techniques suggested in Yaakov's draft on the 
effects of packet loss, should it be desired - these are not restricted to 
AAL1.

In fact AAL1 actually makes this issue harder than CESoPSN. The cells in 
AAL1, while of fixed size, contain varying amounts of _timeslot_ data, 
depending on the position of the CAS sub-structure. CESoPSN always 
contains the same amount of timeslot data, regardless of whether the CAS 
sub-structure is present or not. Therefore the amount of data to replay is 
known directly, without having to compute from the position of the pointer 
the amount of CAS data that may be present in the packet. This simplifies 
reconstruction of the timeslot data. It also makes it much easier to 
identify and process the CAS data, since it is always in the same, regular 
location.

Therefore I contend that the frame alignment system in CESoPSN, and 
especially the use of a constant amount of timeslot data in each packet 
regardless of the presence of CAS is an important property of the method. 
You are right to say it is not necessary for its own sake, but its use 
conveys significant advantages, and exploits the nature of an IP or MPLS 
network in a way that a method based on a fixed cell size cannot.

Tim

Nurit Sprecher <[email-masked]>
Sent by: [email-masked]
22-Jun-2003 09:18 AM

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Hi,
I have been passively following the debate over draft-vainshtein vs.
draft-anavi for some time, and still don't understand one thing.
draft-anavi uses techniques borrowed from ATM, in order to maintain
compatibility to existing CES systems. It thus a pointer to maintains 
frame
alignment.
draft-vainshtein maintains TDM frame alignment by always sending an 
integral
number of frames in a packet.
Why do we need to maintain frame alignment at all?
If a packet is lost, all we need to know is how many bits it contained - 
so

---

From: [email-masked]
Date: Tue, 24 Jun 2003 10:59:11 +0100

Neil,

Apologies for the late reply.

Who is the draft aimed at? We are seeing adoption in a number of 
applications. Clearly for an incumbent carrier with a pre-existing and 
comprehensive TDM network such as yourselves, this is not going to be 
appropriate. Where we are seeing more traction is:

- for use across packet access networks (e.g. metro ethernet networks), 
allowing an operator with a packet network to service TDM-based customers
- the competitive play, allowing data operators to "steal" voice customers 
from the incumbents
- use in greenfield areas, where packet networks are being installed, but 
still need to support voice applications (e.g. PBXs)
- enterprise use in a "toll bypass" scenario (something RAD have been very 
successfully exploiting recently)

I'm sure we could debate the relative merits or demerits of these 
applications, but it gives a flavour. You are right that it is not the 
panacea for everyone, but then what is?

Cheers,
Tim

[email-masked]
18-Jun-2003 10:40 PM

        To:     [email-masked], [email-masked]
        cc:     [email-masked], [email-masked], [email-masked], [email-masked], 
[email-masked]
        Subject:        RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Tim,

Can you please clarify *who* this draft aimed at?  Is it's usage in:
Internet?  ISPs?  Enterprises?  Carriers?  I must admit I find it really
hard to understand just who lots of CCAMPs stuff is aimed at in the 
general
case.  I just re-read it and IMO its awful from a large carriers 
perspective
(but then we have many problems with much of the PWE stuff from a 
functional
architecture perspective.....hopefully I don't have to explain why!).
However, I would not want to stop anyone using this, just so long as its
target audience is clear and its not being sold as the solution for
everyone.

regards, Neil

---

From: [email-masked]
Date: Tue, 24 Jun 2003 11:55:34 +0100

Amnon,
I'm curious about your assertion here "The only way to support silence suppression
is by using the AAL2 mode of TDMoIP". That is a very bold statement!

There are several ways to support silence suppression, of which AAL2 is 
one. What about VoIP, for example? AAL2 may be a good method, however, it 
is not the _only_ way.

Clearly CESoPSN does not have a mode for silence suppression. However, it 
does not compete with the AAL2 mode from TDMoIP. There may be an argument 
why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both 
do basically the same thing, but AAL2 has a clear differentiating reason 
for its existence, as you have pointed out. 

Therefore the presence of an AAL2 mode in TDMoIP is not an argument 
against adopting CESoPSN.

Regards,
Tim

"Amnon Ilan" <[email-masked]>
Sent by: [email-masked]
23-Jun-2003 04:23 PM
Please respond to ailan

        To:     "'Nurit Sprecher'" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Hi,

Amnon.

-----Original Message-----

Hi,

---

From: [email-masked]
Date: Tue, 24 Jun 2003 13:59:54 +0100

So what you are actually saying is that we shouldn't use either CESoPSN or 
TDMoIP's AAL1 mode.
The logical conclusion from your argument appears to be that the only mode 
worth having is the AAL2 mode of TDMoIP.

Perhaps you could also explain the "market acceptance" argument. There may 
be acceptance of AAL1 and AAL2 in the ATM market. Why do you think that 
this will be maintained when translated into the IP/MPLS market?

I've heard the opposite view put forward by several vendors along the 
lines of "the network is starting to migrate away from ATM, so why on 
earth should I go and stick it back in there again". 

Regards,
Tim

24-Jun-2003 01:37 PM
Please respond to ailan

        To:     <[email-masked]>
        cc:     "'Nurit Sprecher'" <[email-masked]>, 
<[email-masked]>, <[email-masked]>
        Subject:        RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Tim,

Please see my comments inline.

Regards,
Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tue 24 June 2003 12:56
To: [email-masked]
Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Amnon,
I'm curious about your assertion here "The only way to support silence
suppression
is by using the AAL2 mode of TDMoIP". That is a very bold statement!

[Amnon Ilan] My wording was not so good. By the word 'only' I meant within
   the scope of E1/T1 over PSN current suggestions (i.e. CESoPSN and
TDMoIP).

[Amnon Ilan] IMHO it is an argument, and even a good one. If you go with 
the
   concept of adopting VoATM to PSNs why break it in the middle? (the 
basic
   reason for adopting VoATM was that VoIP is not designed for trunking 
and
   CES). There should be some very clear and dramatic technical advantage 
in
   favor of CESoPSN in order to do it (and by doing it loose the market
   acceptance advantages of VoATM which I've mentioned before). IMHO there
is
   no such an advantage for CESoPSN (TDMoIP and CESoPSN are more or less 
the
   same on the AAL1 level).

Regards,
Tim

        To:     "'Nurit Sprecher'" <[email-masked]>,
<[email-masked]>
        cc:
        Subject:        RE: [PWE3] Re: I-D
ACTION:draft-vainshtein-cesopsn-06.txt

Hi,

Amnon.

-----Original Message-----

Hi,

---

From: "Amnon Ilan" <[email-masked]>
Date: Tue, 24 Jun 2003 16:32:04 +0200

Tim,

I do not recall writing we should use only AAL2.
My point is: since TDMoIP has both AAL1 and AAL2, we have all
the options inside. There are cases where AAL1 should be used.
AAL2 is mainly for voice trunks while AAL1 is better for
N*64k data applications.
Regarding the "market acceptance" issue:
1. If we can have the ATM market on our side then why
  shouldn't we? (and, IMO, it includes many ILECs, ITU etc.).
2. Even the "religious" guys wouldn't mind borrowing some good
  technologies from ATM in order to push IP\MPLS forward.

Regards,
Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tue 24 June 2003 15:00
To: [email-masked]
Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Regards,
Tim

Tim,

Regards,
Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tue 24 June 2003 12:56
To: [email-masked]
Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Amnon,

Regards,
Tim

Hi,

Amnon.

-----Original Message-----

Hi,

---

From: Alik Shimelmits <[email-masked]>
Date: Tue, 24 Jun 2003 16:46:10 +0200

Ilan and all,

I propose to keep discussion in the scope of 
draft-ietf-pwe3-tdm-requirements-00.txt that specifies 
requirements for emulation of tdm services over PSN.

Regards
	Alik

-----Original Message-----
From: Amnon Ilan [mailto:[email-masked]]
Sent: Tuesday, June 24, 2003 4:32 PM
To: [email-masked]
Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Tim,

Regards,
Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tue 24 June 2003 15:00
To: [email-masked]
Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Regards,
Tim

Tim,

Regards,
Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tue 24 June 2003 12:56
To: [email-masked]
Cc: 'Nurit Sprecher'; [email-masked]; [email-masked]
Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Amnon,

Regards,
Tim

Hi,

Amnon.

-----Original Message-----

Hi,

---

From: Nurit Sprecher <[email-masked]>
Date: Thu, 26 Jun 2003 09:39:49 +0200

Hi,

In discussions we had at Seabridge following my previous letter regarding
the CESoPSN debate, we decided that Seabridge shall not take a stand in this
matter. Consequently, please disregard my earlier position expressed in my
previous letter (below).
Sincerely, Nurit.

-----Original Message-----
From:	Nurit Sprecher [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
Sent:	Sunday, June 22, 2003 10:19 AM
To:	‘[email-masked]’
Subject:	RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt

Hi,
I have been passively following the debate over draft-vainshtein vs.
draft-anavi for some time, and still don’t understand one thing.
draft-anavi uses techniques borrowed from ATM, in order to maintain
compatibility to existing CES systems. It thus a pointer to maintains frame
alignment.  draft-vainshtein maintains TDM frame alignment by always sending
an integral number of frames in a packet.
Why do we need to maintain frame alignment at all?  From the TDM
reconstruction point of view, all we need is to play out the bits that are
in the receive buffer, and the TDM switch will take care of all the rest.
If a packet is lost, all we need to know is how many bits it contained - so
all we need is to have a constant size packet!1 I vote against accepting
draft-vainshtein.
For the unstructured case we need a simpler method - just constant size
packets!
For those complex cases where we need structured (especially with CAS) we
might as well use draft-anavi.
Nurit.

_______________________________________________
pwe3 mailing list
[email-masked] <mailto:[email-masked]> 
https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3>