OPSDIR Last Call Review of draft-ietf-pals-ple Reviewer: Tony Li Status: Overall: Details: Section 1: Please expand the acronyms PE and CE on first use. Some discussion comparing and contrasting this to other pseudowire standards would be most helpful to those who are not subject matter experts. What is the relationship of this work to RFC 4906? RFC 4842? RFC4448, etc.? Why would an operator choose one or another? This is part of your marketing, so I would think that you would very much want to expound on this. As an example: if the payload is Ethernet, then frame level transport is adequate for most applications. In fact, the only thing that I can think of where it would not be adequate is if it were transporting PTP. I have some concerns about transporting PTP based on clocking that is itself derived from PTP, but I assume someone who knows PTP well has thought about that already. Wouldn't it be easier just to provide PTP directly as a service? Section 3.2: OLD After the NSP the IWF is generating the payload of the VPWS which is carried via a PSN tunnel. NEW After the NSP, the IWF is generating the payload of the VPWS which is carried via a PSN tunnel. Section 4.3: Is there actually a market for this service? AFAIK, SONET/SDH is a legacy service with little to no new deployment. While SONET/SDH transport across a packet network seems like a possible migration strategy, will SONET/SDH customers actually be willing to explore new technology for supporting legacy services? I would hate to see us going to the effort of creating standards that don't have an impact on the market. Section 5.1: Using BIT-EMU in the SRH next-header field seems unusual. Why not request a code point for PLE itself? Section 5.1.2: If the L bit is set, the payload of the packet would seem to be wholly irrelevant. Must the payload be attached? If so, that would seem like a waste of bandwidth. Section 6.2: OLD The PLE payload size MUST be a integer number of bytes. NEW The PLE payload size MUST be an integer number of bytes. Section 7.2.2: OLD The CE-bound NSP function will continue to inject the appropriate native downstream fault indication signal until a pre-configured amount of payloads is stored in the jitter buffer. NEW The CE-bound NSP function will continue to inject the appropriate native downstream fault indication signal until a pre-configured amount of payload is stored in the jitter buffer. Section 7.3: OLD UAS-PLE SHALL be counted after configurable number of consecutive SES-PLE have been observed, ... NEW UAS-PLE SHALL be counted after a configurable number of consecutive SES-PLE have been observed, ... You write that "PLE SHOULD provide the following functions to monitor the network performance to be inline with expectations of transport network operators." All well and good. However, more consideration for the expectations of packet switched network operators would very much be in order. How this is done is up to you, but more information is definitely needed from an operational perspective. From the near-end, I would like to see something like: - Current fault status and explanation - Time of last fault - Time of last good data - Media specific link details (e.g., loss of signal but no loss of light; signal but errors; FEC statistics) For the far-end, I would also like to see similar data. I was expecting a similar far-end requirement for transport network operators, beyond just a comment about the R bit. This data MUST be provided by management interface and SHOULD be provided by a YANG model, which can be out of scope for this document. If a signaling protocol is involved, it should provide its own operational indications. You should call this out. Section 8: I believe that your point here is that you require low jitter and low loss. That much I agree with. There are, however, many ways of accomplishing this, so I think that Diffserv is not a 'MUST' and would better off being a 'SHOULD'. Providers may achieve low jitter and low loss by over-provisioning, for example, or through traffic engineering mechanisms. Section 9: If a signaling protocol is used, then it is responsible for its own security. You should call this out. Please discuss SRv6 security. You make a point of only accepting data from 'valid interfaces'. However, this is somewhat challenging as you have no authentication mechanisms in this proposal. The receiver is wholly dependent on data plane security. If you want to provide a more secure proposal, I would suggest adding a cryptographic authentication mechanism. Preferably one that provides protection against replay attacks. Section 12: I'm not understanding the distinction that you're making between informative and normative. Why is SONET normative, but Fibre Channel informative? Why is PWE3 normative? Please review all of your references.