Hi Stewart, I just realised you provided a very detailed review of the PLE draft back in November. I am new to actively contributing to IETF and only now have updated my email filters so any future PLE draft related email without my email directly on to/cc will get directly into my inbox for proper attention.
Thank you very much for taking the time and providing very detailed feedback to this draft! My colleague Luca and I provided comments inline via [cs/ldc] We are looking forward to more discussion input from your and the IETF group Regards Christian On 12.11.2020, at 13:37, Stewart Bryant <[email protected]<mailto:[email protected]>> wrote: Hi Matthew I have taken a look at this draft and think that it needs close review in PALS and ought to have a review in TICTOC. [cs/ldc] agree, fyi we had already some initial review from / discussion with Alexander and Yakoov. Unfortunately not all emails made it into the BESS email archive. But they are accessible in the PALS archive https://mailarchive.ietf.org/arch/browse/pals/?q=ple Of course we are happy to get feedback from TICTOC experts. I see the tictoc mailer on TO/CC so we will wait for their input It needs a much clearer description of the scenario. For instance in Figure 3 are A and G the same clock domain or is one the master. I think that for this to work one has to be the master otherwise I cannot see how you can ship an arbitrary bit stream between them. [cs/ldc] The relationship of clocks A and G is out of scope of PLE. They may be synchronous or asynchronous. In https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-3.2 we are already pointing to https://tools.ietf.org/html/rfc4197#section-4.3.2 which described the relative network scenario for synchronisation. Even then it will not be easy and you need to give a lot of thought to the need for bit stuffing and bit slip since it is unlikely that you will generate perfect sync. In traditional wide area sync networks the protocols include features that support this action to cope with long term drift. [cs/ldc] Bit stuffing, bit slip or pointer adjustments don’t apply to PLE due to the packet based nature of the transport network. The client signal is carried across in a transparent manner and on egress differential clock recovery (DCR) provide the same clock on egress as received on ingress of the network. A PLE implementation must be accurate enough to comply with the respective clock targets referenced in https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-6.2.2. Those targets have been defined so that the respective network can deal with imperfect synchronisation. Also you talk about SyncE. That is specified to provide a 50bbp frequency accuracy, so this is going to need careful design and planning. [cs/ldc] are you referring to SyncE being used to implement the “common clock I”? Or are you concerned about transporting a SyncE client signal? If the former, we are not assuming SyncE to be the only option. There are other ways such as external timing (aka BITS) or IEEE1588/PTP. So far didn't explicitly mention any mechanisms in https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-3.2 as previous TDM PW IETF documents didn’t do either (i.e. RFC4197). Do you think we should add some more specifics here? If the later, this should be already covered by us pointing to relevant target performance for each technology in https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-6.2.2. Also since this is an arbitrary bit stream, you have to comment on what you do when a packet is dropped. [cs/ldc] Replacement data will be played out. This is covered in the 4th paragraph of https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-6.2.2 Since this is PW encapsulation, it probably belongs in PALS, but I do have some reservations about what is proposed. This is not a turf issue for me, I just want to make sure it gets the reviewed by the people that designed this type of technology in the past. [cs/ldc] As noted above we already had some email discussion and input from PALS experts. The question of which WG would be best to adopt the draft was already raised during IETF108 but this topic has yet to be closed with WG chairs. Best regards Stewart More comments inline. ======= Another example is addressing common ethernet control protocol transparency concerns for carrier ethernet services, beyond the behavior definitions of MEF specifications. SB> That is a possible application, and that might include some of the link layer fragmentation that TSN is doing, but I do have to wonder if the network would destroy the other properties. This is certainly something worth discussing in DetNet. [cs/ldc] What we are trying to say here is that PLE is bit transparent and hence should also be 100% transparent to any DetNet / TSN functions. Can you please let us know if you think otherwise. ======== To allow the clock of the transported signal to be carried across the PLE domain in a transparent way the network synchronization reference model and deployment scenario outlined in section 4.3.2 of [RFC4197] is applicable. Gringeri, et al. Expires May 6, 2021 [Page 5] Internet-Draft PLE November 2020 J | G v | +-----+ +-----+ v +-----+ |- - -|=================|- - -| +-----+ | |<---------|.............................|<---------| | | CE1 | | PE1 | VPWS | PE2 | | CE2 | | |--------->|.............................|--------->| | +-----+ |- - -|=================|- - -| +-----+ ^ +-----+<-------+------->+-----+ | | ^ A +-+ | |I| E +-+ Figure 2: Relative Network Scenario Timing The attachment circuit clock E is generated by PE2 in reference to a common clock I. For this to work the difference between clock I and A MUST be explicitly transferred between the PE1 and PE2 using the timestamp inside the RTP header. For the reverse direction PE1 does generate the clock J in reference to clock I and the clock difference between I and G. SB> OK, so you are assuming that I is fully distributed through the network and that I does not change as it might if the clock master in I changes. [cs/ldc] The PLE implementation is responsible to have a proper transient response to still satisfy the performance targets for the client clock referenced in https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-6.2.2. If for example SyncE is used for the common clock I, transient response of the SEC as defined in G.8262 section 11 will be applicable also. SB> That is not generally available in an MPLS network and we need to discuss the implications of providing it. [cs/ldc] The need for a common clock is not new. It also applied to previous TDM PWE concepts from the past. As there are multiple options to implement a common clock we don’t perceive this to be a concern nowadays. SB> This does not make sense to me and maybe I do not understand what you have in mind. CE would normally be a domain rather than a host, so the ingress and egress from CE1 and CE2 would need to be synchronous, but that is not what you are showing. However I think you have CE1 syncing CE2 and CE2 syncing CE1. I don’t think that will work. [cs/ldc] as mentioned before: The relationship of clocks A and G is out of scope of PLE. They may be synchronous or asynchronous. In https://tools.ietf.org/html/draft-schmutzer-bess-ple-01#section-3.2 we are already pointing to https://tools.ietf.org/html/rfc4197#section-4.3.2 which described the relative network scenario for synchronisation. =========== 4.2.1. PLE Control Word The format of the PLE control word is inline with the guidance in [RFC4385] and as shown in the below figure: SB> You know that you are not required to follow this exact format. SB> It would be worth losing at the SONET PW to see if that is more convenient. [cs/ldc] we looked at all control words (SAToP - rfc4553, CESoP - rfc5086 and CEP - rfc4842). As PLE doesn’t require any pointer adjustments to be communicated and is more similar to SAToP we defined the PLE control word similar to the CW for SATOP. ========= 4.2.2. RTP Header The RTP header MUST be included and is used for explicit transfer of timing information. The RTP header is purely a formal reuse and RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Transport Protocol (SRTP), etc., are not applicable to PLE VPWS. SB> RTP is clearly an option, but it is not clear whether it is better or not than creating custom CW as we did for the SONET PW. [cs/ldc] We thought it would be more easier / preferred to align with previous approaches. The format of the RTP header is as shown in the below figure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Synchronization Source (SSRC) Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: RTP Header ======== Sequence Number SB> I am not sure we need two sequence numbers in the protocol - on in the CW and one in the RTP header [cs/ldc] Same as before. We thought alignment with other concepts defined so far is preferred. Reducing these overhead structure would only have a very small impact on the overall efficiency due to the payload size selected. The packet sequence number MUST continuously cycle from 0 to 0xFFFF. It is generated and processed in accordance with the rules established in [RFC3550]. The PLE receiver MUST sequence packets according to the Sequence Number field of the PLE control SB> Also By using RTP you are of course tied to its S/N size. It is not clear to me that this is optimal. [cs/ldc] Good point. We had a related discussion with Alexander in the past (https://mailarchive.ietf.org/arch/msg/pals/QSUJuyque2yLfnP4RpBBK7U_XxA/). We are open to suggestions but don’t see any issues at this stage word and MAY verify correct sequencing using RTP Sequence Number field. Timestamp Timestamp values are used in accordance with the rules established in [RFC3550]. For bit-streams up to 200 Gbps the frequency of the clock used for generating timestamps MUST be 125 MHz based on a the common clock I. For bit-streams above 200 Gbps the frequency MUST be 250 MHz. SB> I am not sure how the TS is working her, because at a different point in the document I thought that you said that the TS was being used to convey the frequency difference between the clock domains. [cs/ldc] thanks for pointing out this aspect, looks like we only pointed to RFC3550 for the encoding but forgot to add text similar to what has been done in https://tools.ietf.org/html/rfc4553#section-4.3.2. Worth to note, for PLE the absolute mode does not apply and we propose to define just the differential mode and as mandatory We will take care of this in upcoming 02 revision SB> I think from this text you are only considering Ethernet bit streams. I am not sure you can describe arbitrary speeds with reference to a 200MHz clock. This needs a lot more thought. [cs/ldc] differential clock recovery doesn’t require the clock used for generating the RTP timestamp to be correlated (i.e. multiple) with the clock of the signal being transported over the PW. The only limits we see are timestamp rollover and resolution which per our calculations both can be addressed with a 125MHz and 250MHz reference clock. SB> If you are only supporting syncE you need to say so, and of course reference the ITU-T material on the subject. [cs/ldc] can you please clarify? Are you referring to the common reference clock or the clock of the transported signal? ======= 5. PLE Payload Layer 5.1. Constant Bit Rate Payload For CBR, I am not sure who is handling the clock slip. [cs/ldc] there won’t be any slips because the signal is played out to the CE based on the recovered clock which is identical to the clock of the signal on the ingress of PW. While doing so, any packet delay variation will be absorbed by the dejitter buffer. ======== 7. Security Considerations As PLE is leveraging VPWS as transport mechanism the security considerations described in [RFC7432] and [RFC3985] are applicable. SB> I think there is more to it that in this case. For example what about disruption to the clock service? [cs/ldc] agree we did not spend much time yet to fine tune this particular section. We will try to provide some more details in the next revision of the draft (taking example from other TDM PWs for example also). Input and suggestions what attack vectors we should focus on are welcome. =========== 10.1. Normative References SB> I am surprised there are not G.8262 and G.8264 references since these are part of the SyncE specification. [cs/ldc] We are pointing to G.8261 as a normative reference for the clock recovery performance target. As we are following the approach of RFC4197 which is not defining any explicit techniques for achieving a common clock we don’t see any need yet to point to G.8262 or G.8264 SB> A lot of the difficulty in designing synchronisation architectures is in the management of the clock master and the actions to take when access to a clock fails. [cs/ldc] as this was out of scope for other / similar PW documents so far we assumed we can take the same approach. _______________________________________________ Pals mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pals
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
