Re: [Pals] Mail regarding draft-schmutzer-bess-ple-01

[Stewart Bryant <[e-mail]>]

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.
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. 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.
Also you talk about SyncE. That is specified to provide a 50bbp frequency accuracy, so this is going to need careful design and planning.
Also since this is an arbitrary bit stream, you have to comment on what you do when a packet is dropped.
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.
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.

========


   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.
SB> That is not generally available in an MPLS network and we need to discuss the implications of providing it.
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.
===========
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.
=========

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.


   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

      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.

      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.
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.
SB> If you are only supporting syncE you need to say so, and of course reference the ITU-T material on the subject.
=======

5.  PLE Payload Layer

5.1.  Constant Bit Rate Payload

For CBR, I am not sure who is handling the clock slip.


========


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?

===========

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