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

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.