Review results: having a standard for sending 100 of Gigabits over pseudo-wires
is awesome, but the security section may need a bit of work. 

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

The draft defines two "pseudo-wires" encapsulations for "private line emulation":

1) An MPLS encapsulation in which a frame starts by an MPLS header, possibly including a stack of labels per
   segment routing, followed by a PLE header and a bit stream payload;

2) An IPv6 packet, in which the IPv6 header includes the segment routing option. The header that follows the
   SRv6 headers will have the type "BIT-EMU" (to be assigned by IANA per this draft), contains
   the PLE header, and is followed by the bit stream payload.

The bit stream payloads are composed by the sender, and replayed as a bit stream at the receiver.
This obviously requires that there is enough bandwidth on the selected path, and that the receiver manages
a sufficient jitter buffer. The draft assumes that the paths are carefully engineered, enough bandwidth
is reserved, etc.

The draft specifies how to "fill the holes" and signal errors when a packet
does not arrive in time, and a performance monitoring system.

The draft specifies how to use the PLE service to carry specific "physical" services like
multiple variants of Ethernet, SONET/SDH, Fiber Channel, OTN. I did not review that part.
But I am rather impressed that we can now carry 10 or 100 Gbps links over pseudo-wires. Wow.

Security considerations:

The security considerations state that PLE "relies upon the Packet Switched Network mechanisms
for encryption, integrity, and authentication whenever required." I am not sure what that implies
exactly. Is it possible for example to combine "PLE/BIT-EMU" and IPSEC? This is hinted to in RFC3985,
but does it require a specific support in PLE?

The draft inherits the security issues with pseudo wire services detailed in the security considerations of
RFC3985. What are the recommended deployment scenarios and security postures to prevent or mitigate the
attacks described in RFC3985? I assume that the draft is intended for use in places where all the
internal nodes are under a common ownership, or at least a common management. Could the draft
state that "single managed domain" requirement explicitly?

Regarding the "single managed domain" hypothesis, there are obvious exposures if the attackers
do manage to get some access to the domain -- or if parts of the service are exposed outside
of the managed domain. Attackers could for example send spoofed IPv6 packets to
internal routers and try to get these inserted in the SR path, and then in the pseudo wire.
What happens if an attack like that succeeds? How does the service recover?

The security section mentions RFC 7432, which includes some mitigations. I am not sure that all these
mitigations apply -- for example, the discussion of MAC addresses in 7432 is probably not relevant here.
If some do, should they be cited explicitly? What about the recommendations in section 8 of RFC 8402?

Typos:

in section 8, QoS and Congestion Control: you write that the data should "be carried over
traffic-engineering paths". Do you mean "traffic-engineered paths"?

in section 9, security considerations: you write that clock synchronization is sensitive
"to various threads and attacked vectors". Do you mean "to various threats and attack vectors"?