Skip to main content

2012-10: Potential Areas for IETF/IEEE802 Coordination v02

Meeting Slides IETF-IEEE (ietfieee) IAB ASG
Date and time 2021-12-31 17:00
Title 2012-10: Potential Areas for IETF/IEEE802 Coordination v02
State Active
Other versions plain text
Last updated 2022-06-10

Potential Areas for IETF/IEEE802 Coordination

0. Revision History
0.0 Initial Revision - 9/4/2012
0.1 revised for the period between 9/5 and 10/29
0.2 revised according to input received on 01, still reflects the 
9/5-10/29 time interval

1. IETF TRILL Fine-grained labeling and IEEE 802.1 tags
1.1 Description
In the 7/25 f2f meeting Paul Unbehagen presented a brief summary of the 
IETF TRILL WG work on Fine-Grained Labeling which raises concerns about 
the use of the existing 0x8100 Ethertype.  IEEE 802 suggested that new 
protocols should require new Ethertypes.
Further discussions - the TRILL contributors agreed to get different 
Ethertypes. This needs to be confirmed in the revised I-Ds.

1.2 Relevant Documents

1.3 Owners - Ralph Droms

1.4 Action Items

2. IETF BFD and IEEE 802.1AX
2.1 Description
In the 7/25 f2f meeting Norman Finn noted that drafts have been written 
(but not adopted in IETF WGs) for using BFD to detect Link Aggregation 
failures.  Norman suggested that BFD is at the wrong layer for this, and 
suggested the following ways to avoid layer violations:
- Invent and use a Layer 3 equivalent of LACP that fits routing and BFD
- Use Ether OAM; work with 802.1 to invent a way to avoid needless 
- Encapsulate BFD below LinkAgg thus giving the world two ways to do 
exactly the same job

The routing AD (Adrian Farrel) clarified by email that the IETF has no 
intention of working on modifications to or a replacement for LACP. The 
only work being undertaken in this area is the ability to run BFD on LAG 
members and report failures of individual members as a degradation of 
the link constructed from the LAG.

Liaison statements were changed between the IEEE 802.1 and IETF BFD WGs.
The BFD WG sent to the 802.1 WG a liaison on 9/25 https:// setting out the progress and 
continuing the communication.
The authors of the BFD for LAGs work have posted several updates, the 
latest at
Note that this work is still currently not official BFD working group 
work. However, a re-charter of the BFD working group was considered by 
the IESG, reviewed by the IETF community, and advertised on the New Work 
mailing list on 10/16. This change in the charter was approved by the 
IESG on 10/25 and includes the following text:

> 5. Provide one or more mechanisms to run BFD over Link Aggregation
> Group Interfaces.


> The working group will maintain a relationship with the KARP and MPLS
> working groups, and will communicate with the IEEE with respect to BFD
> over LAGs. it is expected that the BFD working group will adopt a draft to 
work on soon, and that they will be in touch with 802.1 again in due 

2.2 Relevant Documents

2.3 Owners - Adrian Farrel, Norm Finn

2.4 Action Items

3. IETF NVO3 and IEEE 802.1 DCB
3.1. Description
IEEE 802.1Qbg VDP might be used as the basis for the communication that 
NVO may need between an end system and an external box (e.g. bridge or 
router) doing the NVO encapsulation. Coordination will help determine if 
VDP is a suitable candidate and possibly to make any amendment needed in 
VDP for NVO usage.

Status 10/26 ? not much progress. The NVO3 working group continues to 
work on architecture and requirements. It remains unclear whether a 
"new" encapsulation will be required. Many people consider that there 
are enough encapsulations in the world already.

3.2. Relevant Documents

3.3. Owners - Adrian Farrel, Pat Thaler

3.4. Action Items
- Adrian to ensure that architecture and requirements are liaised to the 
appropriate part of IEEE.

4. IETF awareness of IEEE 802.1Q-2011
4.1. Description

Many IETF drafts reflect knowledge of IEEE 802.1Q-2005 and ignore the 
evolution to IEEE 802.1Q-2011. There are two aspects of this. First, it 
leads to statements in IETF drafts about the capabilities of IEEE 802.1 
bridging that are incorrect, often as part of the justification for new 
work.  Many NVO drafts are an example of this.  E.g. frequent references 
to the 12-bit VLAN ID not scaling without mention that the I-tag carries 
a 24-bit I-SID (backbone Service Instance Identifier) for networks 
needing a bigger scale. Secondly, it can lead to incompatibility between 
bridging using more recent capabilities of IEEE 802.1Q-2011 and 
protocols written based on IEEE 802.1Q-2005.

4.2. Relevant Documents

4.3. Owners - Dan Romascanu, Pat Thaler

4.4. Action Items
- define a process to check whether references to IEEE 802 documents are 
being made to the latest document versions, unless justified differently 
in specific cases ? possibly at GenART review stage

5. Effect of virtualization on IEEE 802 architecture
5.1. Description

At the 7/25 f2f meeting Glenn Parsons presented a brief overview of the 
IEEE Registration Authority Committee (RAC) mission, highlighting the 
current RAC policy on virtualization and asking what virtualization 
policy would reduce the consumption of EUI-48 addresses.  Norman Finn 
suggested this could be an area of collaboration between the IETF and 
the IEEE 802.

At the 9/5 virtual meeting Glenn Parsons reported that the action item 
from the last meeting on updating the IETF on virtualization at the 
Vancouver IETF Meeting (July/August, 2012) was completed.

5.2. Relevant Documents
5.3. Owners - Glen Parsons
5.4. Action Items - Ross Callon and Spencer Dawkins to discuss the 
relation and effects of virtualization on the IEEE 802 architecture with 
the IAB.

6. IETF EMU and IEEE 802.1X, 802.11 and 802.16 security based on EAP
6.1. Description - CLOSED (as discussed at the 9/5 virtual meeting)
6.2. Relevant Documents
6.3. Owners
6.4. Action Items

7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3
7.1. Description
In the transition process between the IETF and the IEEE the following 
documents were taken over by IEEE 802.3:
RFC 2108 - Ethernet Repeater Devices
RFC 3621 - Power Ethernet MIB
RFC 3635 - Ethernet-like Interface Types
RFC 3637 - Ethernet WAN Interface Sublayer
RFC 4836 - Ethernet Medium Attachment Units (MAUs)
RFC 4837 - Ethernet Passive Optical Networks (EPON)
RFC 4878 - Operations, Administration, and Maintenance (OAM) Functions 
on Ethernet-Like Interfaces
RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF proposed to 
continue to be maintained by the IETF in a separate new document
The IEEE 802.3 proposed to create an RFC that documents the issues 
related to the transition of the Ethernet MIB work to IEEE 802.3 similar 
to RFC 4663 which documents the transition of the Bridge MIB work to 
IEEE 802.1
- The OPSAWG was rechartered in October 2012 to include the two relevant 

7.2. Relevant Documents
- IEEE 802.3.1 Draft

7.3. Owners
- Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE 802.3)

7.4. Action Items
- Dan Romascanu will enter the Sponsor Ballot pool and enter a comment 
suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB 
from their document and refer the IF-CAP-STACK-MIB instead.
- Ed Beili will write an I-D targeting standards track that obsoletes 
RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording 
emphasizing the generic nature of this module
- Ed Beili will write an I-D targeting informational RFC, similar to RFC 
4663, with:
a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011
b) A table mapping the old IETF MIB names with the corresponding new 
IEEE ones
c) Clarifications/rules on the IETF-IEEE interactions, mailing lists, 
d) Clarifications on the intellectual property considerations
The first version will be posted by Ed. Then Dan Romascanu and Howard 
Frazier will add IETF-IEEE interactions chapter.
- Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB 
document, to explain the situation

8. IETF 6LOWPAN and IEEE 802.15
8.1. Description
At the 9/5 virtual meeting Ralph Droms reported the new 802.15 Study 
Group should be aware of the work already taken place in the IETF 
6LOWPAN Working Group.  Ralph indicated he would take ownership of this 
item and ask Clint Powell to share the responsibility.  He also 
indicated this would likely be an ongoing coordination effort.

8.2. Relevant Documents

8.3. Owners: Ralph Droms, Clint Powell

8.4. Action Items

9. IETF PAWS WG and IEEE 802.1, 802.11, 802.15, 802.16, 802.22
9.1 Description
At the 9/5 virtual meeting Bruce Kraemer volunteered that one of the 
IETF PAWS WG Chairs (Gabor Bajko) is active in 802.11.  Dan Romascanu 
took an action item to clarify with Gabor Bajko and Pete Resnick if 
there are any action items that need to be taken immediately regarding 
Gabors answer was that the coordination between IETF PAWS and IEEE 
802.11af, 802.19 and 802.22 was so far handled by him; Gabor presented 
periodic updates of PAWS to these IEEE 802 groups, and took their input 
back to PAWS. So far this type of coordination did the job, although in 
the future some of this interaction may need to be handled via the 
official channels.

9.2 Relevant Documents

9.3 Owners: Bruce Kraemer, Gabor Bajko

9.4 Action Items - clarify whether IEEE 802.11af, 802.19 and 802.22 are 
all the relevant groups within IEEE 802 that need coordination with 
PAWS, modify item title accordingly.

10. IETF IPPM and IEEE 802.16 Metrology Study Group
10.1 Description
Coordinate future work in the IEEE 802.16 with existing work in the IETF

10.2 Relevant Documents

10.3 Owners - Roger Marks

10.4 Action Items - IEEE 802.16 to send a statement to IETF IPPM WG 
informing them of the status of the activities of 802.16, and possibly 
asking for input  Done (sent to IPPM with CC to LMAP list)

11. IETF Mobile IP and IEEE 802.16 HetNet Study Group
11.1. Description
  At the 7/25 f2f meeting Roger Marks presented a proposal for a new 
IEEE 802 WG to specify access network abstraction layer above IEEE 802 
access technologies, noting that the work is related to some IETF WGs 
(e.g. DMM, MIF, NETEXT), and made the following recommendations:  - IEEE 
802 OmniRAN can close the gap and tie 802 devices into a family of 
standards within a heterogeneous IP network supporting evolving IETF 
- IEEE 802 and IETF should:
    * leverage each other's expertise
    * plan communications
    * identify commonalities
    * link solutions
    * organize a team to coordinate milestones and progress
At the 9/5 virtual meeting Roger Marks indicated he would be the owner 
of this item.  An action item was identified: Roger Marks to form a team 
to discuss coordination with possible input from Brian Haberman and 
Charlie Perkins.

11.2. Relevant Documents

11.3. Owners - Roger Marks

11.4. Action Items - Roger Marks to form a team to discuss coordination
with possible input from Brian Haberman and Charlie Perkins.

12. IETF HOKEY and IEEE 802.21
12.1. Description

The HOKEY charter includes:  Assistance to the 802.21a group in 
specifying the integration of EAP pre-authentication with IEEE 802.21a. 
The HOKEY Working Group shall perform tasks that are complementary to 
and do not duplicate work being done in IEEE 802.21a.

Note: since July the HOKEY WG concluded. If there are any pending tasks 
they should be transferred to some other place in the IETF.

At the 9/5 virtual meeting Dan Romascanu confirmed that the IETF HOKEY 
WG was concluded since the leadership meeting in July 2012.  An action 
item was identified: Dan Romascanu to ask Subir Das to clarify whether 
IEEE 802.21 has any impending actions that might require the input from 
the concluded IETF HOKEY WG. The former chairs of HOKEY are still active 
IETF participants and would be able to help if needed.

Subir responded that no further actions are required from the concluded 

Proposal: Close the item

12.2. Relevant Documents
12.3. Owners
12.4. Action Items
- Dan Romascanu to ask Subir Das to clarify whether IEEE 802.21 has any 
impending actions that might require the input from the concluded IETF 

13. IETF MIF and IEEE 802.21
13.1. Description

- IETF MIF should not re-do the work that 802.21 has already done

    * 802.21 defines a Media Independent Services SAP (API) that
      provides most of the functionalities that MIF is looking for

    * 802.21 also defines low level Media Specific SAPs for the
      underlying access technologies

  - IETF MIF should identify requirements and make references to 802.21
    SAPs where appropriate

    * If non-existing functionalities are identified both MIF and 802.21
      should work together

At the 5/9 virtual meeting Dan Romascanu took the action item to ask 
Subir Das to clarify what is required. Subir answered that the relevant 
discussions will take place at the November IEEE 802 plenary

13.2. Relevant Documents

13.3. Owners - Subir Das, Ralph Droms
13.4. Action Items - Subir Das to report back from discussions at the 
November IEEE Plenary

14. IETF IPFIX Information Elements for Data Link monitoring
The IPFIX WG specifies a couple of data link Information Elements, to be 
added to Feedback from 
the IEEE on the Information Element specifications would be appreciated.

Information Elements for Data Link Layer Traffic Measurement


   This document describes Information Elements related to data link
   layer.  They are used by the IP Flow Information Export (IPFIX)
   protocol for encoding measured data link layer traffic information.

14.2. Relevant Documents

14.3. Owners
- Benoit Claise and the IPFIX chairs (Juergen Quittek 
<>, Nevil Brownlee <>)

14.4. Action Items
- IETF needs to receive feedback from the IEEE (3 meetings a year, 
almost at the same time as the IETF)
- Send a liaison letter send it the liaison letter to 802.1 and/or 
802.11 as soon as the WG Last Call starts
 Note: the process works better if the liaison is informally discussed 
before it's sent (contact: Eric Gray)
- Benoit and Dan to determine: 802.1 and/or 802.11? looks like 802.1 
only by now
- Benoit and IPFIX chairs to synchronize the WGLC with the IEEE 

15. IETF RADIUS attributes for IEEE 802 networks
The RADEXT WG specifies RADIUS attributes related to IEEE 802 network. 
Feedback from the IEEE on the attributes specifications would be 
                RADIUS Attributes for IEEE 802 Networks

   RFC 3580 provides guidelines for the use of the Remote Authentication
   Dialin User Service (RADIUS) within IEEE 802 local area networks
   (LANs).  This document proposes additional attributes for use within
   IEEE 802 networks, as well as clarifications on the usage of the EAP-
   Key-Name attribute, updating RFC 4072.  The attributes defined in
   this document are usable both within RADIUS and Diameter.

15.2. Relevant Documents:

15.3. Owners
Bernard Adoba, the RADEXT chairs? (Jouni Korhonen 
<> and Mauricio Sanchez 
<>), and Benoit Claise

15.4. Action Items
- Bernard Adoba sent the document to IEEE 802.1 and 802.11, and no 
feedback was received
- This document will be revised by IETF85, and another WG Last Call will 
be performed
- The RADEXT chairs to send a reminder about this document to IEEE 802.1 
and IEEE 802.11, copy Eric Gay, and Dorothy.

16. IEEE802.1Q SRP (and Gen2 updates) and RSVP/SIP
16.1. Description
16.2. Relevant Documents
16.3. Owners - Path Thaler
16.4. Action Items
- Pat to clarify scope with Michael Johas Teener

17. IEEE 802.1AS/1588 and NTP
17.1 Description
17.2 Relevant Documents
17.3 Owners - Pat Thaler
17.4 Action Items
- Pat to clarify scope with Michael Johas Teener

18. 802.1AS/1588, 802.1Q time aware shaper(s) and RTP
18.1. Description
18.2. Relevant Documents
18.3. Owners - Pat Thaler
18.4. Action Items
- Pat to clarify scope with Michael Johas Teener

19. Common OAM proposal
19.1. Description - proposal made by Tissa Senevirathne and a group of 
TRILL contributors at the IEEE 802.1 meetings in July and September to 
reuse the IEEE 802.1ag frame format for TRILL OAM. Needs coordination 
and architectural consistency with the IEEE 802.1 architecture and OAM 
19.2. Relevant Documents

19.3. Owners - Ralph Droms, Norm Finn, Ben Mack-Crane

19.4. Action Items
Follow-up on update of the TRILL OAM requirements document

20. Area Name
20.1. Description
20.2. Relevant Documents
20.3. Owners
20.4. Action Items

21. Area Name
21.1. Description
21.2. Relevant Documents
21.3. Owners
21.4. Action Items

22. Area Name
22.1. Description
22.2. Relevant Documents
22.3. Owners
22.4. Action Items

23. Area Name
23.1. Description
23.2. Relevant Documents
23.3. Owners
23.4. Action Items

24. Area Name
24.1. Description
24.2. Relevant Documents
24.3. Owners
24.4. Action Items