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

Gert Manhoudt <gmanhoudt@aimvalley.nl> Thu, 19 July 2012 09:56 UTC

Return-Path: <gmanhoudt@aimvalley.nl>
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 D6D1721F87A4 for <pwe3@ietfa.amsl.com>; Thu, 19 Jul 2012 02:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 ABzShtGLL7Sl for <pwe3@ietfa.amsl.com>; Thu, 19 Jul 2012 02:56:57 -0700 (PDT)
Received: from mika.eatserver.nl (mika.eatserver.nl [195.20.9.75]) by ietfa.amsl.com (Postfix) with ESMTP id BBFE021F8783 for <pwe3@ietf.org>; Thu, 19 Jul 2012 02:56:56 -0700 (PDT)
Received: from [195.242.97.150] (qore.networks.above.net [195.242.97.150] (may be forged)) (authenticated bits=0) by mika.eatserver.nl (8.13.8/8.13.8) with ESMTP id q6J9vVfO023387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2012 11:57:31 +0200
Received: from localhost (localhost.localhost [127.0.0.1]) by router38.aimvalley.nl (Postfix) with ESMTP id 9BA79818303; Thu, 19 Jul 2012 11:57:31 +0200 (CEST)
X-Virus-Scanned: by Endian Firewall
X-Spam-CTCH-RefID:
Received: from mail3.aimsys.nl (mail.aimsys.nl [10.10.0.114]) by router38.aimvalley.nl (Postfix) with ESMTP id BE493818302; Thu, 19 Jul 2012 11:57:30 +0200 (CEST)
Received: from [10.10.7.15] (pc315.aimsys.nl [10.10.7.15]) (authenticated bits=0) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id q6J9vSo6012111; Thu, 19 Jul 2012 11:57:28 +0200
Message-ID: <5007DA08.1020108@aimvalley.nl>
Date: Thu, 19 Jul 2012 11:57:28 +0200
From: Gert Manhoudt <gmanhoudt@aimvalley.nl>
Organization: AimValley B.V.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Yaakov Stein <yaakov_s@rad.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <F9336571731ADE42A5397FC831CEAA020997FF@FRIDWPPMB001.ecitele.com> <500674D8.1040601@aimvalley.nl> <07F7D7DED63154409F13298786A2ADC9044E9468@EXRAD5.ad.rad.co.il>
In-Reply-To: <07F7D7DED63154409F13298786A2ADC9044E9468@EXRAD5.ad.rad.co.il>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010604030202060701010703"
Cc: "peter.roberts@alcatel-lucent.com" <peter.roberts@alcatel-lucent.com>, pwe3 <pwe3@ietf.org>, "stephan.roullot@alcatel-lucent.com" <stephan.roullot@alcatel-lucent.com>, "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
Reply-To: gmanhoudt@aimvalley.nl
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: Thu, 19 Jul 2012 09:56:58 -0000

Yaakov, Alexander,

I understand that the key issue that you raise is whether the continuity 
of the "physical layer" when an STM-N signal traverses a TSoP Pseudowire 
is sufficiently guaranteed.

First of all, I assume that "continuity of the physical layer"(during 
normal operation)means that all bits that ingress the Pseudowire also 
egress the Pseudowire in the same order and that there is a certain 
timing relation between these ingress en egress signals. The example of 
an optical amplifier was mentioned as a system that does not break the 
physical layer. That is indeed a clear example. But also more complex 
systems that do process the binary content of the client signals, like 
OTN networks, can be said to leave the physical layer intact. Actually, 
the whole point of Pseudowires is to deliver services that emulate a 
wire as well as possible, but that does not mean that the client signals 
are not "adapted" during transport.

Anyway, I agree that to transport STM-N signals over a Pseudowire in the 
way as proposed in the TSoP draft, requires that not only the STM-N bits 
should remain unaffected, but also a certain timing relation between 
input and output must be satisfied in order not to "lie about the S1 
content".

The way that this is currently specified in the TSoP draft is written in 
section 6.2.2, where it stated for the TSoP decapsulation function, that:
- A reconstructed SDH-type STM-N signal delivered to an Attachment 
Circuit MUST meet [G.825] jitter and wander requirements, or,
- A reconstructed SONET-type OC-M signal delivered to an Attachment 
Circuit MUST meet [GR-253] jitter and wander requirements.

I believe this covers Yaakov's comment that "The MTIE slope has to obey 
the constraint at some finite time", since G.825 and GR-253 exactly 
define all phase noise tolerances in different observation intervals.

The current draft indeed does not specify how this should be achieved. 
This is done on purpose to avoid prescribing a certain implementation: 
The draft allows in principle both adaptive and differential approaches, 
and who knows what other schemes that clever people may dream up in the 
future. As long as the recovered SDH/SONET signal meets all applicable 
G.825/GR-253 jitter and wander specifications, it should be fine from a 
network perspective.

Clearly, meeting the G.825/GR-253 requirements is a lot easier 
whensynchronized clocks are available in the PE ingress and egress 
nodesand differential timing can be used. I agree that it may be useful 
(necessary?) to add some text to the draft in the Applicability 
Statements section that explains these things, referring to the 
different network timing situations described in RFC-4197.

Answering some of the other questions:
- TSoP carries STM-N in scrambled format
- TSoP can not insert MS-AIS, since it does not know where the STM-N 
frame starts. Instead it substitutes G-AIS, just as an OTN network will 
do when it carries an STM-N client and something goes wrong.
- The quality level of the clock at the PE that reconstructs the STM-N 
signal at the PW egress is not prescribed. It depends on the design of 
this circuit and the network synchronization. Again, as long as you meet 
G.825/GR-253 jitter and wander requirements at the egress it should be 
fine. The only other requirement is a +/-20 ppm accuracy when the STM-N 
signal is replaced by G-AIS. Note that in this condition no S1 is 
present any longer, so the downstream SDH/SONET NE can not draw any 
wrong conclusions. In fact it will immediately detect LOF and select 
another reference or fall back into hold-over mode.

Regards,
Gert.





On 18 jul 2012 11:25, Yaakov Stein wrote:
> Gert and all,
>
> I would like to partially retract what I previously said about the S1 byte and traceability.
> I hit the send too quickly, and should have thought over the issue first.
>
> It is true that the SSM message relates information about traceability,
> i.e., that after N SDH network elements a certain amount of phase noise has accumulated,
> so that the bit stream does not obey the G.81x masks.
> However, this is not applicable here.
> Here the physical layer traceability is truly broken,
> and you are relying on unexplained magic to restore it.
>
> All that your statement about not dropping or adding bits guarantees is
> lim_tau->infinity  MTIE(tau) / tau = 0, which is not enough.
> The MTIE slope has to obey the constraint at some finite time.
>
> Put in another way, stating that you don't drop or add bits is equivalent
> to stating that you are somehow traceable to the original clock,
> but since you broke the physical layer, and do not describe any mechanism
> for recovery of that physical layer clock, in fact you WILL be forced
> to have bit slips at the egress IWF.
>
> So, simply saying that the SSM is correct by definition,
> and relying on magic to restore the proper clock,
> is not meaningful.
>
> Sorry for my previous incorrect statements.
>
> Y(J)S
>