Subject: [ieee-ietf-coord] updated version of the 'Potential Areas for IETF/IEEE802 Coordination' document

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 26 Oct 2012 13:52:43 +0200

Hi, 

In preparation for the 10/29 virtual meeting of the team involved in the
coordination between the IEEE 802 and the IETF please find attached an
updated version of the area coordination document. Please review the
document and send comments to the list or be prepared to make comments
and report progress status in the Monday call. 

Thanks and Regards,

Dan

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Oct 2012 13:52:29 +0100

Thanks,

Item 2
See my previous email on the progress on BFD for LAG.
AFAIK, 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.

Item 3
No progress is currently appropriate.
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.
Happy to be assigned an action item to ensure that architecture and requirements
are liaised to the appropriate part of IEEE if that would be helpful.

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:ieee-ietf-coord-
> [email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: 26 October 2012 12:53
> To: [email-masked]
> Subject: [ieee-ietf-coord] updated version of the 'Potential Areas for
> IETF/IEEE802 Coordination' document
> 
> Hi,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 27 Oct 2012 12:03:59 +0200

Here is an updated version based on input received by now on the status
of the Action Items. 

Note that I will be travelling during the weekend, so I do not expect to
do another update before the Monday call. 

Cindy, please upload the attached document and the agenda at
http://www.ietf.org/iesg/ieee/.

Thanks and Regards,

Dan

> Sent: Friday, October 26, 2012 1:53 PM
> Subject: [ieee-ietf-coord] updated version of the 'Potential Areas
> forIETF/IEEE802 Coordination' document
> 
> Hi,
>

---

From: Ralph Droms <[email-masked]>
Date: Sun, 28 Oct 2012 08:20:37 -0400

Follow up on a couple of items:

1. IETF TRILL Fine-grained labeling and IEEE 802.1 tags: The trill WG has agreed to use Ethertype 0x893B for fine-grained labeling, avoiding any conflict with IEEE 802 Ethertypes.  See draft-ietf-trill-fine-labeling-02.

8. IETF 6LOWPAN and IEEE 802.1: Tom Herbst has volunteered within the IEEE 802.15 L2R IG to act as liaison to IETF.  Ralph will stay in touch with Tom to monitor possible interactions with the IETF.

13. IETF MIF and IEEE 802.21: Subir Das to report back from discussions at the November IEEE Plenary.

19. TRILL-IEEE 802.1 Common OAM proposal: A design to use 802.1 OAM in TRILL was presented and discussed at the 802.1 interim meeting in Santa Cruz.  THe discussion at the interim meeting had some contentious moments.  Several interested parties from both IEEE and IETF [*] got together for a teleconf to discuss the situation.  We concluded that the use of 802.1 OAM in TRILL is reasonably sound technically and we should develop a plan to facilitate the development of a design by the trill WG.  The trill WG will first publish a requirements document and a framework document as background for the specific 802.1-based OAM for trill.

[*] Participants: Pat Thaler, Norm Finn, Ben Mack-Crane, Dan Romascanu, Thomas Narten, Ralph Droms

---

From: Benoit Claise <[email-masked]>
Date: Mon, 29 Oct 2012 03:51:48 +0100

Hi Dan,

I'll have to skip this call. Sorry for the short notice.
However, here is the update for my AIs

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 documents

7.2. Relevant Documents
- IEEE 802.3.1 Draft
-http://datatracker.ietf.org/wg/opsawg/charter/  
- TBD OPSAWG I-Ds

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
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

LATEST INFO:
Waiting for Ed to produce the drafts. I've been hoping that the two drafts initial versions would be posted for this IETF, but it's not the case. Waiting for some news from Ed Beili.

=============================================

14. IETF IPFIX Information Elements for Data Link monitoring
The IPFIX WG specifies a couple of data link Information Elements, to be added tohttp://www.iana.org/assignments/ipfix/ipfix.xml. Feedback from the IEEE on the Information Element specifications would be appreciated.
       
Information Elements for Data Link Layer Traffic Measurement
              draft-ietf-ipfix-data-link-layer-monitoring-00

Abstract

    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
-http://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/

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

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 schedules

LATEST NEWS:
The WG Last Call started October 15th, and will end just after IETF-85, i.e. on Sunday, 11 November.
An email has been sent to Eric Gray.
The next step is the official liaision

===========================================================

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 appreciated.
                 RADIUS Attributes for IEEE 802 Networks
                   draft-ietf-radext-ieee802ext-02.txt
Abstract

    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:
http://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext/

15.3. Owners
Bernard Adoba, the RADEXT chairs? (Jouni Korhonen<[email-masked]>  and Mauricio Sanchez<[email-masked]>), 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.

LATEST NEWS
- A new draft version was posted on October 21st
- Bernard, who should be on the call, will give the latest information.

Regards, Benoit
> _______________________________________________
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Mon, 29 Oct 2012 16:56:23 +0000

I interpreted the results of the TRILL OAM discussions as, "We'll look
again at the problem and see whether Ether OAM has anything to offer
TRILL."  After working with Tissa Senevirathne and Samer Salam, I think
that that it would be useful to proceed.  The new requirements document is
encouraging.

-- Norm

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Sunday, October 28, 2012 05:20 AM
To: Dan Romascanu <[email-masked]>
Cc: Cindy Morgan <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [ieee-ietf-coord] updated version of the 'Potential
Areas	forIETF/IEEE802 Coordination' document

>1. IETF TRILL Fine-grained labeling and IEEE 802.1 tags: The trill WG has
>agreed to use Ethertype 0x893B for fine-grained labeling, avoiding any
>conflict with IEEE 802 Ethertypes.  See draft-ietf-trill-fine-labeling-02.
>
>8. IETF 6LOWPAN and IEEE 802.1: Tom Herbst has volunteered within the
>IEEE 802.15 L2R IG to act as liaison to IETF.  Ralph will stay in touch
>with Tom to monitor possible interactions with the IETF.
>
>19. TRILL-IEEE 802.1 Common OAM proposal: A design to use 802.1 OAM in
>TRILL was presented and discussed at the 802.1 interim meeting in Santa
>Cruz.  THe discussion at the interim meeting had some contentious
>moments.  Several interested parties from both IEEE and IETF [*] got
>together for a teleconf to discuss the situation.  We concluded that the
>use of 802.1 OAM in TRILL is reasonably sound technically and we should
>develop a plan to facilitate the development of a design by the trill WG.
> The trill WG will first publish a requirements document and a framework
>document as background for the specific 802.1-based OAM for trill.
>

---

From: "Pat Thaler" <[email-masked]>
Date: Mon, 29 Oct 2012 16:58:24 +0000

On 19, I'd state the conclusion as: use of 802.1 OAM in TRILL may be possible but there are technical challenges because IEEE 802.1 OAM model assumes that Bridge ports are addressable and TRILL Nicknames identify the Rbridge, not the Rbridge port. How to solve this depends on the requirements and model needed for TRILL OAM so that information is needed before a solution to the technical challenge can be developed.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Oct 2012 13:05:48 -0400

Pat - for the record in the document, how about this text:

On Oct 29, 2012, at 12:58 PM 10/29/12, Pat Thaler wrote:

19. TRILL-IEEE 802.1 Common OAM proposal: A design to use 802.1 OAM in TRILL was presented and discussed at the 802.1 interim meeting in Santa Cruz.  The discussion at the interim meeting had some contentious moments.  Several interested parties from both IEEE and IETF [*] got together for a teleconf to discuss the situation.  We concluded that the use of 802.1 OAM in TRILL may be possible but there are technical challenges because IEEE 802.1 OAM model assumes that Bridge ports are addressable and TRILL Nicknames identify the Rbridge, not the Rbridge port.  How to solve this (and potentially other) technical challenge depends on the requirements and model for TRILL OAM.  The trill WG will first publish a requirements document and a framework document as background for developing a specific 802.1-based OAM for TRILL.

---

From: "Pat Thaler" <[email-masked]>
Date: Mon, 29 Oct 2012 17:28:46 +0000

That's good. Thanks, Pat