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

[Gert Manhoudt <[e-mail]>]

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.

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. 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.

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. 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.

Would such an addition address your concerns?

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]] *On Behalf 
> Of *Andrew G. Malis
> *Sent:* Tuesday, August 14, 2012 2:34 PM
> *To:* [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.
>