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

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

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,
>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.
> >
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Danny McPherson <[email-masked]>
Date: Thu, 12 Jun 2003 10:57:08 -0600

If there are other folks that would like to see this document become a WG
item please speak up now.

-danny

---

From: Michel Khouderchah <[email-masked]>
Date: Fri, 13 Jun 2003 09:05:44 -0700

Danny,

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.

Regards,

Michel

---

From: Max Riegel <[email-masked]>
Date: Mon, 16 Jun 2003 11:06:59 +0200

Danny,

I would support that the WG is adopting this document as a base for 
further discussions in the working group towards a WG solution.

Bye
Max

---

From: Alex Conta <[email-masked]>
Date: Mon, 16 Jun 2003 11:20:40 -0400

No. At this point, I am against. 

Is there a newer version of the "anavi" draft as well? (Yaakov?) Is that
addressing the issues raised earlier?

Thanks,
Alex