Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP
Yaakov Stein <yaakov_s@rad.com> Wed, 18 July 2012 08:58 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 ACE0321F8690 for <pwe3@ietfa.amsl.com>; Wed, 18 Jul 2012 01:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Level:
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, 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 AYHOm3LvMxLZ for <pwe3@ietfa.amsl.com>; Wed, 18 Jul 2012 01:58:43 -0700 (PDT)
Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5721F8686 for <pwe3@ietf.org>; Wed, 18 Jul 2012 01:58:40 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 18 Jul 2012 11:23:13 +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, 18 Jul 2012 11:59:26 +0300
From: Yaakov Stein <yaakov_s@rad.com>
To: "gmanhoudt@aimvalley.nl" <gmanhoudt@aimvalley.nl>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "stbryant@cisco.com" <stbryant@cisco.com>
Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP
Thread-Index: AQHNXnGiS690goHnm0iu3kV86wpwkZciBfkAgAyK2wCAADQsEA==
Date: Wed, 18 Jul 2012 08:59:26 +0000
Message-ID: <07F7D7DED63154409F13298786A2ADC9044E9429@EXRAD5.ad.rad.co.il>
References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <F9336571731ADE42A5397FC831CEAA020997FF@FRIDWPPMB001.ecitele.com> <500674D8.1040601@aimvalley.nl>
In-Reply-To: <500674D8.1040601@aimvalley.nl>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A0B0207.50067AEF.00FA,ss=1,fgs=0
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>
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, 18 Jul 2012 08:58:44 -0000
see comments below. -----Original Message----- From: Gert Manhoudt [mailto:gmanhoudt@aimvalley.nl] Sent: Wednesday, July 18, 2012 11:33 To: Alexander Vainshtein; stbryant@cisco.com; Yaakov Stein Cc: stephan.roullot@alcatel-lucent.com; peter.roberts@alcatel-lucent.com; pwe3; Ron Cohen Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Stewart, Yaacov and Alexander, Thanks for your comments on draft-manhoudt-pwe3-tsop-00. It is our intent to request the PWE3 WG to accept this document as a working group draft. [YJS] I think that since this draft redefines basic SDH functionality, at very least we need to liaise with ITU-T before accepting this document. At this stage I want to address those points that could be interpreted to imply that the TSoP approach as such is not acceptable. The other comments are of a less principal nature and can be addressed later (and can probably be fixed by adapting the text). 1. TSoP does not require the termination of any STM-N overhead: Yaakov's e-mail contains the statement: "this function is at least a section (in SDH terminology a regenerator section) termination". I believe that this statement is not true: There is no reason why STM-N signals can not be carried transparently over some server layer with minimal interaction between client and server (as should always be the goal). [YJS] Anything that breaks the physical layer continuity, is at least a regenerator from the SDH layering point of view. A simple optical amplifier is less than a regenerator, since it indeed passes the SDH transparently. The proposal here is VERY non-transparent, as I pointed out. In particular, it breaks the timing chain, which is absolutely fundamental to SDH operation. The correct architectural analogue would be to compare a TSoP PW section to an OTN network that transports an STM-N client signal. [YJS] Do you realize that PSNs are not synchronous networks ? The mapping of an STM-16/OC-48 in an ODU1 does not require any processing of STM-N overhead or even framing for alignment purposes: All STM-16 bits are directly written into the OPU1 payload area. This is described in G.709 section 17.2.1. In terms of functional blocks this is described in G.798 section 14.3.1. Note that Appendix I.1 of this same Recommendation describes the mapping of STM-N in OPU-k using OPTIONAL RS-monitoring, just like TSoP. Because a TSoP PW section (STM-N over PSN) is modeled to behave itself in the same way as an STM-N over OTN section, the TSoP decapsulation function inserts Generic AIS as defined in G.709, rather than SDH multiplex section AIS as defined in G.707, in case the client signal is interrupted. As a side remark: Yaakov's mail also contains the statement: "(since it does not divide up STM-Ns, it is not a line termination)". Note that this directly contradicts the remark that the S1-byte must be processed. If that were really necessary, it would not be sufficient to limit the required SDH functionality to a regenerator section termination, but rather a full multiplex section termination (SONET: line termination) would be necessary, since the S1-byte is located in the MS part of the STM-N overhead and not in the RS part: SDH regenerators pass the S1-byte transparently. [YJS] The whole purpose of my remark was to point out that this draft proposes a network element that does not exist in SDH as presently defined, and thus, as I proposed, needs to be liaised to the SDO holding the pen on SDH. 2. TSoP passes the S1-byte transparently: The S1-byte in the STM-N multiplex section overhead carries the "traceability information" of the STM-N signal, i.e. the quality level of the master clock at the beginning of a chain of slaved STM-N systems. Normally this quality level is PRC/PRS, but during fault situations, it may lower to SSU/ST2 or even SEC/ST3. Downstream STM-N systems can use this information to select another reference signal or to go in hold-over mode. The question is now whether the passage of an STM-N signal over a TSoP/PSN section should affect the value of the S1-byte. We believe that this is not the case: The nature of a passage of an STM-N signal through a TSoP Pseudowire is such that the traceability does not change, since the (long term average of the) frequency of the STM-N signals before entering the TSoP PW and after leaving the TSoP PW is the same: No bits are created or deleted from the STM-N client signal. This means that if the long term frequency accuracy of an STM-N signal is 1E-11 (i.e. it is traceable to PRC/PRS), that this will not change by passing the TSoP PW, i.e. the traceability is invariant. [YJS] This statement is blatantly incorrectly. The S1 byte specifically indicates that the bit stream obeys the appropriate ITU-T timing Recommendation, such as G.811, G.812, or G.813. This is not limited to very long term FFO constraints, but also jitter and wander limits. Were this statement to be true, the entire SDH timing chain would fail (which is precisely what worries me about the draft). In particular, were this statement to be true, we would not have needed to work so hard over the past 10 years on algorithms and standards for TDM PW synchronization. We could just send everything using a local 100 ppm crystal and claim that long term the FFO is will be correct. Of course, during a failure, the TSoP decapsulation function substitutes the G-AIS signal which is no longer frequency synchronous with the input STM-N. In this case the downstream STM-N node will immediately detect Loss of Frame and will no longer be able to read the S1-byte. According to standard SDH reference selection procedures (see G.781), this node will no longer consider such a signal to be an acceptable synchronization reference. [YJS] I am not talking about failures. I am talking about normal operation. You will be carrying an SSM that states that you are SEC or SSU, and the downstream network elements will believe this. Their G.781 will cause this clock to be selected, rejecting better clocks, and leading to system failures. 3. A TSoP PWE3 can be carried over UDP/IP: This option has been included in the TSoP draft purely because it is present in the SAToP standard and to keep the encapsulation options aligned. If experience has shown that transport over an UDP/IP PSN of higher bitrate circuit emulation PW's is not recommendable, the authors have no problem to remove this option. [YJS] While this was not my remark, I think that there is a big difference between an individual E1 and an STM signal. Regards, Gert Manhoudt. On 10 jul 2012 11:01, Alexander Vainshtein wrote: > Hi all, > Several comments on the draft in question: > > 1. The draft seems to follow closely RFC 4553, including support of IPv4/IPv6 as the PSN, congestion handling etc. I echo Stewart's question regarding usage of IPv4/IPv6 PSN (with limited TE capabilities) for carrying such high-rate CBR flows as STM-1/OC-3 and higher. > > 2. The draft correctly mentions RFC 4842 as an alternative (and approved by the IETF) method for emulating SONET/SDH over PSN. However, it is worth noting that one of the reasons this method has been preferred to transparent passing of the entire SONET/SDDH bit stream (e.g., as proposed in one of the early precursors of RFC 4553 - see http://www.watersprings.org/pub/id/draft-vainshtein-cesopsn-01.txt, Annex B) to was elimination of the need to manipulate the S1 byte in the SONET/SDH overhead. The lower nibble of this byte contains encoded quality of the system clock of the SONET/SDH mux that has been used to drive the outgoing SONET/SDH bit stream. Simply passing tits value transparently thru the PSN does not make any sense (and, indeed, potentially violates integrity of clock distribution). The IWF proposed in the draft cannot access this byte because it is unaware of the SONET/SDH boundaries, and neither can this be done by the OSn_TT_So & OSn/RSn_A_So/ OSn_TT_Sk & OSn/RSn_A_Sk functional blocks to which the IWF is connected. IMHO the draft should explain in some detail how this issue is resolved. Alternatively, it should state that the SONET/SDH bit stream that has passed thru the TSoP PW MUST NOT be used as the clock source by the CE device. > > 3. The draft defines only LOS as the mandatory SONET/SDH AC fault to affect setting of the L bit in the PW control word. However, if Loss of Frame defect is encountered (dLOF), de-scrambling of the incoming SONET/SDH stream cannot be completed, and the payload of the TSoP would become junk; hence IMO LOF must be added as a mandatory trigger for asserting the SF condition in Section 3.1. (And, while the reference to the ITU-T G.783 functional blocks implies that, it would be nice to explain that the incoming SONET/SDH bit stream is segmented and encapsulated after de-scrambling - for the sake of the readers that do not parse the ITU-T-ish easily:-) > > 4. The draft seems to imply that TSoP requires, as a pre-requisite, availability of common high-quality clock for the pair of PEs terminating a TSoP PW by both mandating the use of the minimal RTP header in the encapsulation and not recommending usage of adaptive clock recovery for these PWs. However, this important restriction is not reflected in the Applicability Statement section of the draft. > > 5. The draft mentions the need not to exceed the path MTU between the pair of PEs in the case of IPv4/IPv6 PSN but not in the case of the MPLS PSN (where it obviously applies). > > Hopefully these notes will be useful. > > Regards, > Sasha > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf >> Of Stewart Bryant >> Sent: Tuesday, July 10, 2012 10:57 AM >> To: pwe3 >> Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP >> >> Do the authors think that running transparent >> SONET emulation over IP is likely in practice, or is >> this included because SAToP included it? >> >> Stewart >> (Speaking as an individual) >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. >
- [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Stewart Bryant
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Alexander Vainshtein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Alexander Vainshtein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Gert Manhoudt
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Alexander Vainshtein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Yaakov Stein
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Gert Manhoudt
- Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Stewart Bryant