Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP

Yaakov Stein <yaakov_s@rad.com> Wed, 11 July 2012 16:55 UTC

Return-Path: <yaakov_s@rad.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73411E810C for <pwe3@ietfa.amsl.com>; Wed, 11 Jul 2012 09:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level:
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHSP7GxfxBLw for <pwe3@ietfa.amsl.com>; Wed, 11 Jul 2012 09:55:18 -0700 (PDT)
Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85911E8106 for <pwe3@ietf.org>; Wed, 11 Jul 2012 09:55:15 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 11 Jul 2012 19:21:09 +0300
Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 19:55:42 +0300
From: Yaakov Stein <yaakov_s@rad.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "gmanhoudt@aimvalley.nl" <gmanhoudt@aimvalley.nl>, "stephan.roullot@alcatel-lucent.com" <stephan.roullot@alcatel-lucent.com>, "peter.roberts@alcatel-lucent.com" <peter.roberts@alcatel-lucent.com>
Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP
Thread-Index: AQHNXnGiS690goHnm0iu3kV86wpwkZciBfkAgAI6eNA=
Date: Wed, 11 Jul 2012 16:55:42 +0000
Message-ID: <07F7D7DED63154409F13298786A2ADC9044E3B7C@EXRAD5.ad.rad.co.il>
References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <F9336571731ADE42A5397FC831CEAA020997FF@FRIDWPPMB001.ecitele.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA020997FF@FRIDWPPMB001.ecitele.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.17.141.36]
Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9044E3B7CEXRAD5adradcoil_"
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A090204.4FFDB00F.0076,ss=1,fgs=0
Cc: pwe3 <pwe3@ietf.org>, "stbryant@cisco.com" <stbryant@cisco.com>
Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 16:55:23 -0000

Authors of draft-manhoudt-pwe3-tsop and the rest of PWE3,



This approach was considered a long time ago,

but was not accepted due to a major architectural flaws.



First, as Sasha said, it does not find the S1 byte

and thus lies about the SSM message.

This is not acceptable behavior.

In terms that non-TDM people would understand,

this would be similar to discovering an incorrect header checksum.

but then recalculating it to cover up the loss.



Second, this function is at least a section (in SDH terminology a regenerator section) termination

(since it does not divide up STM-Ns, it is not a line termination).

Section terminations MUST terminate and regenerate the section overhead

(A1, A2, J0, B1, etc.) and optionally SHOULD enable insertion and dropping of

E1, F1, and D1/2/3 Data Communcations Channels.

Once again, by transparently passing these bytes rather than regenerating them,

the emulation "lies" about their values.



Finally, as Sasha already stated, the scrambling mechanism

recovery after a single packet loss is problematic.

This in itself pretty much kills the service usefulness if there is any packet loss.



In addition the clocking is not sufficiently described.

I understand that RTP usage is mandated,

and for some reason that 25 MHz is the nominal frequency.

However, it is not clear what that 25 MHz is locked to.

Is this always "common clock" (differential mode) ?



Also, why is G.709 AIS generated instead of SDH MS-AIS or MSF-AIS ?

I have a funny feeling that someone is trying to trick the SDH end devices

NOT to recognize the fault condition.

G.826 specifies that detecting AIS causes the declaration of a severely errored second (SES)

and that there can be no more than 1/5 of a percent of SESes,

i.e., about 1 AIS event in 500 seconds.

At the default payload size of 810 Bytes, a single STM-1 takes 3 packets,

so that there are 24,000 packets per second,

so we are talking about an packet loss ratio of 1 in 500*24,000 = 12 million,

i.e., about 8E-8.



Nits:

   As with all PWs, TSoP PWs may be manually configured or set up using

   the PWE3 control protocol [RFC4447<http://tools.ietf.org/html/rfc4447>].

well, it will require extensions to 4447.



   The key difference between the CEP approach and the TSoP

   approach is that within CEP an incoming STM-N is terminated and

   demultiplexed to its constituent VCs (Virtual Containers).

I don't agree. While transport of VTs/VCs is allowed,

an STM-1 can be transported directly using CEP without demuxing.

However, the framing is discovered and the CW structure pointer points to the beginning of the SPE.

This is the correct behavior for a regenerator.



Why is G.709 an informative reference, if one needs to generate its AIS pattern ?



Y(J)S