Liaison statement
Response to the IEEE 802.1 Liaison Letter

Mr. Jeffree,

Thank you for your liaison letter dated 3/19/2012. We share your desire for the
IETF and the IEEE 802 (and the IEEE 802.1 in particular) to work together in
order to avoid the creation and proliferation of multiple solutions to the same
problems. We agree on the need for concerted efforts that will ensure that the
technologies developed by the two organizations interoperate with each other
and are operated and controlled in a consistent manner.

We appreciate your sharing the list of projects completed in the last two
years, the ones in progress, and the new proposals in IEEE 802.1.

In response to your request to list the work items in the IETF that are
proposed or underway that relate to MAC networks together with a brief
description of the problems these are addressing, please find below the list of
relevant Working Groups and work items organized per Area:

INTERNET AREA

6LOWPAN
The WG developped specifications for transport (RFC 4944) and compression (RFC
6282) of IPv6 packets over IEEE 802.15.4 and is now working on a document that
defines IPv6 transport over BT-LE.

TRILL
draft-ietf-trill-fine-labeling uses EtherType 0x893B after an 802.1q VLAN tag
to extend the TRILL VLAN label to 24 bits and provide an additional 3-bit
priority field. The TRILL WG has expressed interest in collaborating with IEEE
802.11 to write a specification to use components of TRILL for path selection
in IEEE 802.11s.

POTENTIAL NEW WORK IN THE INTERNET AREA
The Area has also hold some preliminary discussion on a potential WG to look at
IPv6 over a variety of new link types (802.15.4e, 802.15.4k). As yet, no new
WGs or WG work items have been created.

OPERATIONS AND MANAGEMENT AREA

ADSLMIB
Four documents defining MIB modules (a common MIB module and three specific MIB
modules will be developed to handle the three separate layer-2 technologies to
handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1
(ATM), G.998.2 (Ethernet) and G.998.3 (TDIM).

IPFIX
There are a few MAC/VLAN related Information Elements in
http://www.iana.org/assignments/ipfix/ipfix.xml based on previous work. The WG
is also chartered to define several new information elements for data link
monitoring covering frame size, type, sections of frames, and VLAN information.

RADEXT
This WG chartered to work on extensions for RADIUS has one work item for RADIUS
Attributes for IEEE 802 Networks (draft-ietf-radext-ieee802ext)

ROUTING AREA

BFD
The BFD working group is in communication with 802.1 about using BFD to detect
failures in LAG members and coordinate this with the LAG control and load
sharing functions. There is no proposal to make any modifications to LACP.

CCAMP
The CCAMP working group has developed a number of RFCs for the control of
Ethernet networks and services (5828, 6003, 6004, 6005, 6060). The working
group currently has one I-D in hand for the control of Ethernet OAM in Ethernet
networks already under the control of a control plane protocol
(draft-ietf-ccamp-rsvp-te-eth-oam-ext). This I-D builds on a generic OAM
control mechanism for GMPLS to provide configuration/control of 802.1ag and
802.1Qay OAM.

ISIS
The ISIS working group is responsible for the maintenance and extension of the
IS-IS protocol. It performs review and updates to IS-IS on behalf of the TRILL
working group (quod vide) which is working on routing in Ethernet networks.

KARP
The KARP working group is tasked to work with the routing protocol working
groups in order to improve the communication security of the packets on the
wire used by the routing protocols. This working group is concerned with
message authentication, packet integrity, and denial of service (DoS)
protection. At present, the KARP work explicitly excludes confidentiality and
non-repudiation concerns. KARP will make recommendations concerning enhancement
to the security of the ISIS routing protocol which will be implicit
recommendations for layer 2 protocols such as TRILL which are based on ISIS.

L2VPN
The L2VPN working group is chartered to work on VPLS and VPWS (both including
Ethernet), EVPNs, and E-Trees emulating native services operated over
pseudowires as defined by the PWE3 WG or over IP or MPLS PSN tunnels. There are
a number of RFCs and active I-Ds relating to the provision of emulated Ethernet
services.

MPLS
The working group has developed a number of extensions to MPLS use in MPLS-TP
networks where one of the key use cases is the transport of Ethernet
pseudowires over MPLS. The MPLS working group has one active I-D related to
Ethernet. draft-ietf-mpls-tp-ethernet-addressing presents considerations for
determining link-layer addressing of Ethernet frames carrying MPLS-TP packets
where IP-based address learning mechanisms might not be present.

NVO3
The NVO3 working group may offer support to Ethernet connectivity services
within data centers through VPN-type solutions. This topic is still for
discussion within the working group, but seems likely. There are no working
group drafts in hand at the moment.

PWE3
The PWE3 working group has specified encapsulation methods for the transport of
Ethernet over MPLS networks (RFC 4448) (Ethernet pseudowires) and an applicable
MIB module (RFC 5603). A number of RFCs from the working group are applicable
to all pseudowires and hence to Ethernet pseudowires. RFC 5994 discusses how
Ethernet pseudowires may be used to satisfy the requirements of MPLS-TP
networks. The working group has one active I-D related to Ethernet:
draft-ietf-pwe3-mpls-eth-oam-iwk describes interworking of OAM between Ethernet
Attachment Circuits (ACs) and the MPLS-based Ethernet pseudowires that provide
connectivity over the MPLS network.

ROLL
The ROLL working group has developed RPL (RFC 6550) which we understand may
have led to an Annex in IEEE P1901.2

SECURITY AREA

EMU
Part of the work in IEEE 802.1X as well as security features developed in IEEE
802.11 and 802.16 rely on EAP. Currently the development of EAP methods
continues in the EMU WG.

HOKEY
The WG (soon to conclude) develops procedures for key reuse and delivery that
accommodate inter-technology heterogeneous handover and roaming. One of the
tasks in the charter is providing assistance to the IEEE 802.21 WG in
specifying the integration of EAP pre-authentication with IEEE 802.21a.

IPSECME
The individual submission draft-nir-ipsecme-erx describes an extension to the
IKEv2 protocol that allows an IKE Security Association (SA) to be created and
authenticated using the EAP Re-authentication Protocol extension (ERP). One of
the two use cases is smooth transition between a WLAN that uses IEEE 802.1X to
grant access and a VPN connection to a cellular network.

As you may have noticed we listed above some activities that relate to MAC
technologies developed in the IEEE 802, but not in IEEE 802.1. We did this as
we are aware that the IEEE 802.1 WG is also responsible on the overall
architecture of IEEE 802. Please feel free to forward this liaison letter to
other Working Groups in IEEE 802.

We expect some of the items above to be part of the discussions concerning
areas of shared interest during the meeting between the IEEE 802 and IETF
leadership teams scheduled for July 25, 2012.

On behalf of the IESG,

Russ Housley
IETF Chair