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

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

Hi Yangfan,

Thank you very much for going through the drafts and I am happy to see that WG members are acknowledging the need for PLE

Please see my comments inline

Regards
Christian

On 06.04.2021, at 13:03, Yangfan (IP Standard) <[e-mail]<mailto:[e-mail]>> wrote:

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?

[cs] You are correct the intention of PLE is to define structure agnostic transport of more than just E1/T1 or E3/T3 (RFC4553). The list of expected services is covered in sections 3.1, 3.2, 3.3 and 3.5 of https://tools.ietf.org/html/draft-schmutzer-bess-ple-vpws-signalling-01

I also noticed PLE reference model is different from PWE3, it seems that NSP doesn’t belong to PLE architecture.

[cs] We did not intend to introduce a different architecture for PLE. Is your concern coming from the fact that in figure 1 of the PLE draft we show a “p2p L2VPN service” between PE1 and PE2, whereas in RFC3985 figure 2 there is a “pseudo wire" shown between PE1 and PE2 and a “emulated service” between CE1 and CE2?

From a NSP standpoint I think both the PLE draft and RFC3985 / RFC4553 state the same things.

We surely can adjust the diagram and wording to make it more clear that there isn’t a difference.


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.

[cs] We defined RTP as MUST because the clock recovery performance targets won’t be achievable with ACR and only with DCR which requires the RTP header.

With regards to the position of the RTP header, putting it behind the control word has the benefit of using the control word to identify the “upper-layer header” type when carrying PLE over a SRv6 network.

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

[cs] yes right now the End.DX2 definition is focused around ethernet and EVPN-VPWS. But conceptional I think End.DX2 is a match for PLE, would you agree/disagree?

I would even contemplate that the current text in section 4.1.1 of RFC8986 is generic enough to not preclude End.DX2 to be applied to PLE. i.e. a “control word” could be considered as a locally configured allowed upper-layer header type?

… but you are right input from SPRING experts is needed here

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?

[cs] Yes NSP functions at layer 1 because PLE is defining a bit transparent transport mechanism over packet also for ethernet.


Regards,
Fan


发件人: Pals [mailto:[e-mail]] 代表 Christian Schmutzer (cschmutz)
发送时间: 2021年3月23日 22:46
收件人: [e-mail]<mailto:[e-mail]>
抄送: Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: [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>)4>). 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>-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>53>, RFC5086<https://tools.ietf.org/html/rfc5086> and RFC4842<https://tools.ietf.org/html/rfc4842>42>.

Looking forward to your suggestions and discussion

Thank you,
Christian