Reviewer: Tony Li
Review result: Has Issues
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.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
