答复: Solicit feedback on draft -schmutzer-bess-ple and draft-schmutzer-bess-ple-vpws-signallin g

Hi Christian,

I have read the two drafts, and believe such mechanism comes from a solid need. However, based on the previous work in Pals, I still have some doubts and hope you can help me clarify them.

Firstly, I have an overall confusion about the boundary between PWE3 and PLE. PWE3 architecture [RFC3985] and a series of RFCs e.g. [RFC4448][RFC4842] provide the mechanisms of carrying different types of payload over packet switched networks, including Ethernet, SONET/SDH services.
And both of them define 4 byte length control word and make use of RTP protocol. My question is whether the intention of PLE is to solve the problems that PWE3 doesn't cover e.g. encapsulate ODUk, or create an generic header used for types of PSN?
I also noticed PLE reference model is different from PWE3, it seems that NSP doesn’t belong to PLE architecture.

Secondly, some minor questions:

1.       RTP is optional in PWE3, whereas it is a MUST in PLE and defined in following of control word. If PSN is IP/UDP based, RTP wouldn't comply with the usual usage mentioned in RFC4553 and RFC5086.

2.       In RFC8986，End.DX2 only covers the processing of upper layer header is Ethernet, not for the other payload types.

3.       In section 5.1,  for PCS based CE interface types supporting FEC or virtual lanes, I wonder if it means that NSP function is also performed at layer 1?

Regards,
Fan


发件人: Pals [mailto:[email protected]] 代表 Christian Schmutzer (cschmutz)
发送时间: 2021年3月23日 22:46
收件人: [email protected]
抄送: Christian Schmutzer (cschmutz) <[email protected]>; [email protected]
主题: [Pals] Solicit feedback on draft-schmutzer-bess-ple and draft-schmutzer-bess-ple-vpws-signalling

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

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals