[Pals] New Liaison Statement, "IETF PALS Working Group on the Control Word for Ethernet Pseudowires"
Liaison Statement Management Tool <[email protected]>
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <[email protected]> |
Title: IETF PALS Working Group on the Control Word for Ethernet Pseudowires Submission Date: 2018-04-05 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1571/ From: Andrew Malis <[email protected]> To: Paul Nikolich <[email protected]>,Glen Parsons <[email protected]>,John Messenger <[email protected]>,[email protected] Cc: John Drake <[email protected]>,Deborah Brungard <[email protected]>,Stewart Bryant <[email protected]>,David Sinicrope <[email protected]>,Pseudowire And LDP-enabled Services Discussion List <[email protected]>,Martin Vigoureux <[email protected]>,Alvaro Retana <[email protected]>,Andrew Malis <[email protected]>,Scott Mansfield <[email protected]>,Eric Gray <[email protected]>,[email protected],Raghu Ranganathan <[email protected]> Response Contacts: Andrew Malis <[email protected]>,Stewart Bryant <[email protected]> Technical Contacts: Purpose: For information Body: The pseudowire (PW) encapsulation of Ethernet, as defined in IETF RFC 4448, specifies that the use of the Control Word (CW) is optional. When the CW is not used in an Ethernet PW, it has been found to be operationally common for deployed MPLS label switching routers (LSRs) to search past the end of the label stack to determine whether the payload is an IP packet, and if it thinks that the payload is an IP packet based on the first four bits of the payload being equal to 0x4 or 0x6, to use equal-cost-multi-path (ECMP) algorithms to select the next hop based of the so called IP "five-tuple" (IP source address, IP destination address, protocol/next-header, transport layer source port and transport layer destination port). In the absence of a PW CW, an Ethernet pseudowire packet can be misidentified as an IP packet by a LSR selecting the ECMP path based on the presumed (but incorrect) IP five-tuple. This in turn may lead to the selection of the wrong equal-cost-multi-path (ECMP) path for the packet, leading in turn to the misordering of payload Ethernet frames. Further discussion of this topic is published in IETF RFC 4928. Frame misordering can also happen in a single path scenario when traffic classification and differential forwarding treatment mechanisms are in use. This occurs when a forwarder incorrectly assumes that the packet is IP and applies forwarding policy based on fields in the PW payload. This problem has recently become more serious in operational networks for several reasons. The first is due to the more common deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6 as assigned by the IEEE Registration Authority (RA). Secondly, concerns over privacy have led to the use of MAC address randomization which assigns local MAC addresses randomly for privacy. Random assignment produces addresses starting with one of the two values about 1/8 of the time. The use of the Ethernet PW CW addresses this problem. The IETF PALS Working Group has written a draft RFC that recommends the use of the Ethernet pseudowire Control Word in all but exceptional circumstances. This draft is close to completion in the PALS Working Group, and may be found online at https://tools.ietf.org/html/draft-ietf-pals-ethernet-cw . Organizations that write specifications that include the use of Ethernet PW technology are recommended to be familiar with this draft and take any actions with their respective specifications they think are needed to address the draft. We anticipate its publication as an IETF RFC in the coming months. Interested individuals are invited to provide comments to the PALS email list, [email protected] . Regards, Andrew G. Malis and Stewart Bryant Attachments: Control Word for Ethernet Pseudowires https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-05-pals-itu-t-sg-15-ieee-802-1-broadband-forum-mef-ietf-pals-working-group-on-the-control-word-for-ethernet-pseudowires-attachment-1.pdf