Andy, Christian,
Thank you for the updates. I’ve reviewed the changes and will mark this as Ready.
Several of your responses below are extremely helpful and material and I would like to encourage you to include these in the document. However, that’s wholly optional at this point.
Regards, Tony On Nov 19, 2024, at 2:27 PM, Andrew G. Malis <agmalis@xxxxxxxxx> wrote:
Tony,
Are you OK with Christian's reply and the updates in -10? I noticed that you haven't updated the "Has issues" tag in the Datatracker and the draft is on the 12/5 telechat agenda.
Thanks, Andy
Hi Tony,
Thank you for your very detailed review. I am trying to address your comments inline via [cs]. Mentioned changes are incorporated in the -10 revision I just published
Christian
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.
[cs] good point. I tried to be brief so far - maybe too much so. I changed the first paragraph as follows to be more explicit. More details are in following paragraphs, see also subsequent comments
OLD
This document describes a method called Private Line Emulation (PLE) for encapsulating high-speed bit-streams as Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN). This emulation suits applications where signal transparency is required
and data or framing structure interpretation of the PE would be counter productive.
NEW
This document describes a method called Private Line Emulation (PLE) for encapsulating high-speed bit-streams as Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN).
This emulation suits applications where carrying Protocol Data Units (PDUs) as defined in [RFC4906] or [RFC4448] is not enough, physical layer signal transparency is required and data or framing structure interpretation of the PE would be counter productive.
[cs] the comparison to I tried to cover with this sentence
Also SONET/SDH add/drop multiplexers or cross-connects can be interconnected without interfering with the multiplexing structures and networks mechanisms. This is a key distinction to Circuit Emulation over Packet (CEP) defined in [RFC4842] where demultiplexing
and multiplexing is desired in order to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual Container (VC). Said in another way, PLE does provide an independent layer network underneath the SONET/SDH layer network,
whereas CEP does operate at the same level and peer with the SONET/SDH layer network.
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?
[cs] I totally agree that for the most part frame level transport is enough. but L2 control protocol tunnelling has been proven to be a challenge over the years and still is with the most recent example of EAPOL (IEEE802.1x) for MACSEC not being passed.
I tried to cover this in a more generic way with the following sentence
One example of such case is two Ethernet connected Customer Edge (CE) devices and the need for Synchronous Ethernet operation between them without the intermediate Provider Edge (PE) devices interfering or addressing concerns about Ethernet control protocol
transparency for PDU based carrier Ethernet services, beyond the behaviour definitions of Metro Ethernet Forum (MEF) specifications.
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.
[cs] done
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.
[cs] You are absolutely right, no-one is deploying new SONET/SDH networks. However while lots of SDH networks got dismantled already, the rate of SONET network decommissioning is slower than someone would expect.
I have had numerous customer discussions on this aspect and one common scenario I see is that people try to modernise their DWDM networks by moving from non-coherent (direct detect) optical transmission which is generally limited to 10Gbps per wavelength,
to coherent transmission which allows 100s of Gbps (even Tbps) per wavelength. However these new DWDM platforms are often not designed to pickup 2.5G OC48 or even 10G SONET connections. PLE is giving you an option to “aggregate” those 2.5G or 10G TDM connections
onto a bigger packet pipe carried over coherent DWDM without the need to daisy-chaining legacy muxponders with a state of the art coherent DWDM system.
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.
[cs] good point, however I wonder from a practical perspective, how much of use would this temporary extra capacity be? Wouldn’t operators in their capacity planning process always consider the worst case, i.e. that those high capacity / high value constant
bitstream elephant flows are always present?
Other bitstream RFCs did include text that implementations MAY omit the payload for packets with L-bit set. If the WG thinks this has value, we can add it
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.
[cs] done
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.
[cs] done
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, ...
[cs] done
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)
[cs] I have enhanced this part of the document to now have two sections “PLE performance monitoring” and “PLE Fault Management”. Can you please have a look at the new -10 revision and let me know if that provides enough detail?
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.
[cs] we are following the lead of other bitstream PWs already defined. In particular RFC4842 (CEP) which also only defines far-end fault indication (R bit).
I guess your point is “can we do better?". OTN (G.709) which is somewhat supposed to be mimicking by PLE does provide Backward Error Indication (BEI). But OTN has the luxury of lots of overhead bytes that can be used for doing that but also it is a TDM
technology where you deal with bit errors in frames/timeslots.
To do the same in PLE we would need some piece of overhead that allows the far-end to Indicate lost packets. Using some unused parts of the control word? Or something else? … I wonder if this is worth the effort? I tend to think, no.
Maybe a good reference point to judge this is that ITU also didn't specify “Errored Seconds (ES)” for ethernet (i.e. a 1 second interval with only a few packets being lost), just "Severely Errored Seconds (SES)” which is inline with PLE communication far-end
packet loss state (PLOS) via 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.
[cs] as with other bitstream PW specs before, the signalling protocol details are defined as out of scope in section 7.1 and are covered in dedicated documents … so I assume that would also mean we can leave this to be covered in the respect documents,
right?
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.
[cs] I made some change to this section in my response to Tommy Pauly’s review. What do you think about this text?
The PSN providing connectivity between PE devices of a PLE VPWS has to ensure low jitter and low loss. The exact mechanisms used are beyond the scope of this document and may evolve over time. Possible options, but not exhaustively, are a Diffserv-enabled
[RFC2475] PSN with a per domain behavior [RFC3086] supporting Expedited Forwarding [RFC3246]. Traffic-engineered paths through the PSN with bandwidth reservation and admission control applied. Or capacity over-provisioning.
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.
[cs] With regards to authentication. We are following the lead of other PW RFCs that use the same / a similar sentence as below and some pointers to security considerations for the relevant PSNs. Isn’t that enough?
PLE does not enhance or detract from the security performance of the underlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.
[cs] On the point of “valid interfaces” I also replied to Christian H. My bad I was taking a MPLS specific text from RFC7432 and made it generic. I changed the section to now have the relevant data plane text in one place as follows
NEW
The PSN is assumed to be trusted and secure. Considerations about the MPLS core network outlined in [RFC4381] are applicable.
For MPLS based PSNs, one of the requirements for protecting the data plane is that the MPLS packets be accepted only from valid interfaces. For a PE, valid interfaces comprise links from other routers in the PE's own AS. For an ASBR, valid interfaces comprise
links from other routers in the ASBR's own AS, and links from other ASBRs in ASes that have instances of a given PLE PWs. It is especially important in the case of multi-AS PLE PWs that one accepts PLE packets only from valid interfaces.
When a Segment Routing (SR) based PSN is used (MPLS or SRv6) the considerations in Section 8 of [RFC8402] and Section 9.3 of [RFC9252] are applicable.
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.
[cs] changed to informative, also went through the references and made changes where applicable
|
