2012-09: Potential Areas for IETF/IEEE802 Coordination v00
slides-interim-2021-ietfieee-01-sessa-2012-09-potential-areas-for-ietfieee802-coordination-v00-00

Potential Areas for IETF/IEEE802 Coordination

0. Revision History
0.1 Initial Revision - 9/4/2012

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.
1.2 Relevant Documents
1.3 Owners
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  
configuration.
- Encapsulate BFD below LinkAgg thus giving the world two ways to do  
exactly the same job
2.2 Relevant Documents
2.3 Owners
2.4 Action Items

3. IETF NVO 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.

3.2. Relevant Documents
3.3. Owners
3.4. Action Items

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

Many IETF drafts reflect a 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
4.4. Action Items


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.

5.2. Relevant Documents
5.3. Owners
5.4. Action Items

6. IETF EMU and IEEE 802.1X, 802.11 and 802.16 security based on EAP
6.1. Description
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

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, 
reviews
d) Clarifications on the intellectual property considerations
-

-

8. IETF 6LOWPAN and IEEE 802.15
8.1. Description
8.2. Relevant Documents
8.3. Owners
8.4. Action Items


9. IETF PAWS WG and IEEE 802.1, 802.11, 802.15, 802.16, 802.22
9.1 Description
9.2 Relevant Documents
9.3 Owners
9.4 Action Items

10. IETF IPPM and IEEE 802.16 Metrology Study Group
10.1 Description
10.2 Relevant Documents
10.3 Owners
10.4 Action Items

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 
standards
- IEEE 802 and IETF should?
    * leverage each other's expertise
    * plan communications
    * identify commonalities
    * link solutions
    * organize a team to coordinate milestones and progress
11.2. Relevant Documents
11.3. Owners
11.4. Action Items

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.

12.2. Relevant Documents
12.3. Owners
12.4. Action Items


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

13.2. Relevant Documents
13.3. Owners
13.4. Action Items

14. IETF IPFIX Information Elements for Data Link monitoring
14.1. Description
14.2. Relevant Documents
14.3. Owners
14.4. Action Items

15. IETF RADIUS attributes for IEEE 802 networks
15.1. Description
15.2. Relevant Documents
15.3. Owners
15.4. Action Items

16. IEEE802.1Q SRP (and Gen2 updates) and RSVP/SIP
16.1. Description
16.2. Relevant Documents
16.3. Owners
16.4. Action Items


17. IEEE 802.1AS/1588 and NTP
17.1 Description
17.2 Relevant Documents
17.3 Owners
17.4 Action Items

18. 802.1AS/1588, 802.1Q time aware shaper(s) and RTP
18.1. Description
18.2. Relevant Documents
18.3. Owners
18.4. Action Items

19. Area Name
19.1. Description
19.2. Relevant Documents
19.3. Owners
19.4. Action Items

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