Re: [PWE3] Fwd: New Version Notification for draft-manhoudt-pwe3-tsop-01.txt

[Alexander Vainshtein <[e-mail]>]

Gert,
Please see inline below.

Regards,
     Sasha

From: Gert Manhoudt [mailto:[e-mail]]
Sent: Wednesday, August 15, 2012 10:59 AM
To: Alexander Vainshtein
Cc: Andrew G. Malis; pwe3
Subject: Re: [PWE3] Fwd: New Version Notification for draft-manhoudt-pwe3-tsop-01.txt

Hi Sasha,

I don't think we have any fundamental disagreement. Let me give you my take on this:

The TSoP draft specifies in section 6.2.2 that the STM-N signal that is recovered at the PW egress in PE2, MUST meet SONET/SDH jitter and wander requirements. This is the key requirement.
[[[Sasha]]] This is not what I have been speaking about.


My argument is that as long as you meet this requirement, there are no issues regarding S1 and nodes CE1 and CE2 can use it exactly as they would when the TSoP PW would not be there.
[[[Sasha]]] I disagree and, what is more important, the text in the draft says differently: If TSoP were not there:

*         CE1 could set the S1 value it transmits towards CE2 in accordance with the quality of its current system clock  source (whatever it happens to be). With TSoP you suggest to set it to SSU or even to DNU in certain scenarios

*         CE2 could believe whatever it receives from CE1. With TSoP, if the operator of CE1 did not follow the recommendations of the draft, CE2 would make wrong decisions regarding selection of its system clock source
Based on this I think the current TSoP draft is internally consistent (including the applicability statements).

I understand your argument to be that you can't guarantee that you can meet this requirement generically in all PSNs; it depends very much on the synchronization situation and the design of the STM-N clock recovery in PE2 and the quality of Clk3. The synchronization situation can be such that a practical design that meets the key requirement is virtually impossible.
[[[Sasha]]]  This is not the point IMO. The point is that usage of TSoP prevents the customer from operating SONET or SDH CE devices in the normal way when it comes to the system clock selection/clock quality distribution.


I believe that both arguments are correct and non-contradictory. It simply means that TSoP is not a solution that is generically applicable in all situations.

To address the applicability restrictions of TSoP, I've added appendix C to explain in which situations you should be able, with reasonable design requirements, to meet the key spec of 6.2.2. To summarize this appendix: In situations C.1, C.2 and C.3 you can apply TSoP both for data and sync transport without restrictions. In situation C.4 you can transport STM-N data over the TSoP PW, but the use of the STM-N signal as a synchronization source is not generically possible and requires special measures involving CE1 and/or CE2. In situation C.5 even STM-N data transport must be judged on a case-by-case basis and sync transport is practically impossible.

The point you raise in your e-mail is that the limitations of TSoP should be mentioned in the Applicability Statements (section 10) of the draft. Strictly speaking I don't think that is necessary, because, as I said, if you meet the requirement in 6.2.2, there are no further restrictions.
[[[Sasha]]] I believe that you refer to the following test from 6.2.2:

   Subsequently, the STM-N stream towards the CE is reconstructed by
   playing out the buffer content with a clock that is reconstructed to
   have the same average frequency as the STM-N clock at the PW ingress.
   In addition, this clock signal must have such properties that the
   following requirements can be met:

      o  A reconstructed SDH-type STM-N signal delivered to an
         Attachment Circuit MUST meet [G.825] and [G.823] jitter and
         wander requirements (for synchronization interfaces), or,

      o  A reconstructed SONET-type OC-M signal delivered to an
         Attachment Circuit MUST meet [GR-253] jitter and wander
         requirements.

I did not look up GR-253, but your reference to G.823 looks misleading to me, because it - unsurprisingly -defines specific jitter and wander limits depending on the clock quality level. And G.825 does not, per se,  define any requirements, it just provides pointers to G.812 and G.813 with multiple options.  So I am not sure these reference are very helpful.

But I agree that this approach may be a bit too formal, so we could include a statement in section 10 that warns the reader that meeting the requirement in 6.2.2 is not always practically possible and that a forward reference is made to appendix C for further details on this.
[[[Sasha]]] Please see above.


Would such an addition address your concerns?
[[[Sasha]]] Unfortunately, no.


Regards,
Gert.
On 14 aug 2012 16:11, Alexander Vainshtein wrote:
Andy and Gert,
I have looked up the draft in order to understand how the problem of the SSM (carried in the S1 overhead byte) is resolved.

My reading of Appendix C (that deals with synchronization issues) is that the "solution" is moved outside the PW domain.
E.g., in Section C.4 "Layer 2 Synchronized PEs" the draft suggests that in a certain  scenario   "the S1-byte should be configured to "SSU-A" (SDH) or "ST2" (SONET) on the corresponding egress port of CE1" while in a different scenario "the S1-byte should be configured to "Don't Use for Synchronization" on the corresponding egress port of CE1".  The difference between these scenarios is the quality of the reference clock available to PE2, i.e., something that is not really known to the operator that configures CE1. (The reference model for synchronization is shown in the copied diagram below).

              ----- direction of transmission ----->

                        Ref2                   Ref3
                          |                     |
     Ref1                 |                     |                 Ref4
      |                   V                     V                   |
      |              +--------+             +--------+              |
      V              |  Clk2  |             |  Clk3  |              V
   +------+          |--------|             |--------|          +------+
   | Clk1 |          | STM-N /|             | TSoP  /|          | Clk4 |
   |------|          |      / |             | -PW  / |          |------|
   |      |          |     /  |             |     /  |          |      |
   | SDH1 |--------->|    /   |============>|    /   |--------->| SDH2 |
   |      |  STM-N   |   /    |    TSoP     |   /    |   STM-N  |      |
   |      |          |  /     |   Packets   |  /     |          |      |
   +------+          | / TSoP |             | /      |          +------+
     CE1             |/   -PW |             |/ STM-N |             CE2
          |          +--------+             +--------+          |
          |             PE1                     PE2             |
          |          |        |             |        |          |
          |-- AC1 -->|        |==== PSN ===>|        |-- AC2 -->|
          |          |                               |          |
          |          |--------- Pseudowire --------->|          |
   Up-    |                                                     |  Down-
   stream |------------- STM-N (multiplex) section ------------>| stream

           +---------------------------------------------------+
           |  Clk1 is the system clock of CE1, locked to Ref1  |
           |  Clk2 is the system clock of PE1, locked to Ref2  |
           |  Clk3 is the system clock of PE2, locked to Ref3  |
           |  Clk4 is the system clock of CE2, locked to Ref4  |
           +---------------------------------------------------+

           Figure 9.  Reference network for analysis of TSoP
                      synchronization requirements


IMHO and FWIW it would be much more appropriate to explain (in the "Applicability Statement" section) that while TSoP passes the S1 value transparently, it does not guarantee that it correctly reflects the actual timing quality of the recovered STM-N stream. Accordingly, the customer SHOULD by configuration exclude the recovered STM-N streams from the lists of potential clock sources of the CE devices.

My 2c,
     Sasha

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Andrew G. Malis
Sent: Tuesday, August 14, 2012 2:34 PM
To: [e-mail]<mailto:[e-mail]>
Cc: pwe3
Subject: Re: [PWE3] Fwd: New Version Notification for draft-manhoudt-pwe3-tsop-01.txt

Gert,

Thanks!

All,

As was discussed in Vancouver, the chairs will work with Gert to draft a liaison to ITU-T SG15 for their September meeting to get comments on this draft. We will circulate the draft liaison to the WG for comments before sending it to SG15.

Cheers,
Andy
On Tue, Aug 14, 2012 at 7:18 AM, Gert Manhoudt <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

As agreed during the IETF-84 meeting in Vancouver, I've updated draft-manhoudt-pwe3-tsop (to version -01). This document proposes a structure agnostic encapsulation and Pseudowire transport method for SDH/SONET client signals.

The following changes have been made to the document:
1. The use of IP as a possible PSN layer for this type of Pseudowires has been removed
2. Appendices B, C and D have been added to address the points that were raised on the mailing list after the issue of version -00
3. Quite a number of textual improvements (at least in my opinion) have been made and nits have been addressed

Regards,
Gert.


-------- Original Message --------
Subject:

New Version Notification for draft-manhoudt-pwe3-tsop-01.txt

Date:

Tue, 14 Aug 2012 03:59:53 -0700

From:

[e-mail]<mailto:[e-mail]>

To:

[e-mail]<mailto:[e-mail]>

CC:

[e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>



A new version of I-D, draft-manhoudt-pwe3-tsop-01.txt

has been successfully submitted by Gert Manhoudt and posted to the

IETF repository.



Filename:      draft-manhoudt-pwe3-tsop

Revision:      01

Title:         Transparent SDH/SONET over Packet

Creation date:  2012-08-14

WG ID:         Individual Submission

Number of pages: 40

URL:             http://www.ietf.org/internet-drafts/draft-manhoudt-pwe3-tsop-01.txt

Status:          http://datatracker.ietf.org/doc/draft-manhoudt-pwe3-tsop

Htmlized:        http://tools.ietf.org/html/draft-manhoudt-pwe3-tsop-01

Diff:            http://www.ietf.org/rfcdiff?url2=draft-manhoudt-pwe3-tsop-01



Abstract:

   This document describes the Transparent SDH/SONET over Packet (TSoP)

   mechanism to encapsulate Synchronous Digital Hierarchy (SDH) or

   Synchronous Optical NETwork (SONET) bit-streams in a packet format,

   suitable for Pseudowire (PW) transport over a packet switched network

   (PSN).  The key property of the TSoP  method is that it transports

   the SDH/SONET client signal in its entirety through the PW, i.e., no

   use is made of any specific characteristic of the SONET/SDH signal

   format, other than its bit rate.  The TSoP transparency includes

   transporting the timing properties of the SDH/SONET client signal.

   This ensures a maximum of transparency and a minimum of complexity,

   both in implementation and during operation.









The IETF Secretariat





_______________________________________________
pwe3 mailing list
[e-mail]<mailto:[e-mail]>
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.


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.