|
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
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.
[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.
[cs] done
[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.
[cs] the idea was to have a generic/common next-header that can also be used for SRv6 PSN scenarios for other bitstreams PWs such SAToP (RFC4553), CESoP (RFC5086) and CEP (RFC4842) that were previously defined. The common EVPN-VPWS control plane aspects
for example are covered in https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-bitstream-vpws-signalling
[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
[cs] done
[cs] done
[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?
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
[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?
[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.
[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.
[cs] changed to informative, also went through the references and made changes where applicable
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
