[Pals] Solicit feedback on draft-schmutzer-bess-ple and draft-schmutzer-bess-ple-vpws-signalling

["Christian Schmutzer (cschmutz)" <[e-mail]>]

Dear PALS experts,

The authors would like to introduce you to the concept of Private Line Emulation Emulation (PLE) and the two related drafts draft-schmutzer-bess-ple<https://tools.ietf.org/html/draft-schmutzer-bess-ple-02> and draft-schmutzer-bess-ple-vpws-signalling.<https://tools.ietf.org/html/draft-schmutzer-bess-ple-vpws-signalling-01>

Even though ethernet became the de facto WAN interface technology and pretty much all traffic has converged to IP, service providers are still required to provide “transparent circuits” to their customers which can not be addressed by frame/packet based approaches such as ethernet PWs (RFC4448<https://tools.ietf.org/html/rfc4448>) or EVPN-VPWS (RFC8214<https://tools.ietf.org/html/rfc8214>). While in the past those were mostly DS1s/E1s or DS3/E3s or 10/100Mbps ethernet over PDH/SONET/SDH (GFP/VCAT) “leased lines” nowadays customers are requesting larger pipes (private lines) and a wider variety of interfaces types. Examples are 1GE, 10GE, OC48/STM16, OC192/STM64, various rates of Fibre-channel and even 100GE.

Optical transport technology has evolved to 200-800Gbps capacity per wavelength. In order to stay efficient at the optical transport layer, service providers require a multiplexing/switching layer to carry 10Gbps or 100Gbps private lines over those large capacity wavelengths. Advances in packet switching ASIC/NPU technology make IP/MPLS technology a very efficient choice for that layer. This is where PLE being an “emulation concept” does come into picture. It allows for delivering 100% (bit) transparent “circuits” over a packet switching (transport) layer that is completely independent from the client layer signal/traffic it is carrying. PLE is also inline with the considerations of RFC3916 section 1<https://tools.ietf.org/html/rfc3916#section-1>.

Granted this idea is not entirely new, you somewhat can see PLE as the expanded scope of SAToP (RFC4553<https://tools.ietf.org/html/rfc4553>) that defined the transparent transport of low rate DS1/E1/DS3/E3 TDM signals in the past.

While we already had some discussion (in PALS) on rev -00 and -01 of draft-schmutzer-bess-ple<https://tools.ietf.org/html/draft-schmutzer-bess-ple-02> we kindly request your review and feedback also on the latest rev -02. Changes that went in so far:
* explicitly specify payload fill order
* increased default payload size
* change “ODUk aligned” mode to “byte aligned” mode
* correct use of FRG in control word
* increased timestamp frequency
* clarify use of common clock and differential clock recovery (including quality targets)
* improve defect and performance monitoring section

Furthermore we would also appreciate your feedback on draft-schmutzer-bess-ple-vpws-signalling<https://tools.ietf.org/html/draft-schmutzer-bess-ple-vpws-signalling-01> which right now is in rev -01. During recent deployments of SATOP/CESOP/CEP, service providers indicated interest in adopting EVPN-VPWS as a signalling mechanism. Hence we propose to use EVPN-VPWS for signalling PLE VPWS and consider a broader scope to also define how EVPN-VPWS can be used for signalling TDM pseudo wires defined in RFC4553<https://tools.ietf.org/html/rfc4553>, RFC5086<https://tools.ietf.org/html/rfc5086> and RFC4842<https://tools.ietf.org/html/rfc4842>.

Looking forward to your suggestions and discussion

Thank you,
Christian