2013-05-02: Potential Areas for IETF/IEEE802 Coordination v07
slides-interim-2021-ietfieee-02-sessa-2013-05-02-potential-areas-for-ietfieee802-coordination-v07-00

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
0.3 revised after the 10/29/12 meeting
0.4 revised for the period between 10/29 and 12/12
0.5 revised after the 12/17/12 meeting
0.6 revised for the period between 12/17/12 and 2/5/13
0.7 revised for the period between 2/5/13 and 4/30/13



1. IETF TRILL Fine-grained labeling and IEEE 802.1 tags
1.1 Description - CLOSED


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

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://
datatracker.ietf.org/liaison/1192/ setting out the progress and 
continuing the communication.
The authors of the BFD for LAGs work have posted several updates, the 
latest at http://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags/
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.

...and...

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

...so 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 
course.

Status 12/17 (Adrian): we're progressing as expected and trying to 
communicate as much as possible with 802.1 as we go along.  The BFD WG 
is not the fastest WG in the world, but I know the people involved are 
working on an interop event now, so there should be more to report in 
the new year.

Status 12/30/13 (Adrian, Dan): Revision -07 of draft-mmm-bfd-on-lags was 
posted on April 12th. It reflects the recent activity in interop testing 
and work with the IANA to make early allocation of codepoints. It was 
sent for comments to the IEEE 802.1 reflector on 4/29

2.2 Relevant Documents
https://datatracker.ietf.org/liaison/1192/
http://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags/

2.3 Owners - Adrian Farrel, Norm Finn

2.4 Action Items
- follow-up the evolution of the doc, as it is adopted as a WG item


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.

In the 10/29 meeting - concerns from the IEEE that some of the NVO 
requirement drafts say things about 802.1 and its capabilities that 
don't take all the capabilities into account.  There are some above 
layer 2 reasons to do NVO, and we think the requirements doc would 
portray that more accurately going forward.  Concerns with the way 
802.1Q capabilities are being portrayed.  Also there's an 802.1 protocol 
called DCB that may be useful and we want it to get fair consideration 
if it's a fit.

Status 12/17 (Pat, Adrian): Things are going fine, but we'll need to 
keep this open as things go along.

Status 4/30: draft-ietf-nvo3-overlay-problem-statement-02 is in WGLC, 
several comments from participants in both IEEE 802.1 and IETF

3.2. Relevant Documents
https://datatracker.ietf.org/liaison/1219/
http://datatracker.ietf.org/doc/draft-ietf-nvo3-overlay-problem-statement

3.3. Owners - Adrian Farrel, Pat Thaler

3.4. Action Items
- Adrian to ensure that architecture and requirements are liaised to the 
appropriate parties of IEEE. Done. Liaison sent by NVO3
- follow-up and send documents for review as they are adopted as WG 
items.


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


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.

Status 4/30 - Glenn Parsons submitted an I-D and gave presentations at 
IETF-86 in the Technical Plenary, OPS and INT area meetings. The IEEE 
RAC will finalize and approve the proposal by June.

5.2. Relevant Documents
http://www.iab.org/2012/12/13/proposed-ieee-registration-authority-committee-oui-tier-restructuring/
http://www.ietf.org/proceedings/86/slides/slides-86-iab-techplenary-5.pdf
https://datatracker.ietf.org/doc/draft-ieee-rac-oui-restructuring/

5.3. Owners - Glenn Parsons

5.4. Action Items
- Bernard (as IAB chair) sent on 12/12/12 a message to ietf-announce 
asking for feedback on the Proposed IEEE Registration Authority 
Committee OUI Tier Restructuring
- Glenn to prepare the presentation for the technical plenary, and to 
submit companion I-D by end of January/early February - Done
- Follow approval in IEEE 802, then close the item



6. IETF EMU and IEEE 802.1X, 802.11 and 802.16 security based on EAP
6.1. Description - CLOSED


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
- Status 4/30/13: draft-ietf-opsawg-rfc5066bis received a number of 
substantial comments in the OPSAWG review which resulted in the need for 
substantial edits, revised version is still in progress. The second I-D 
was not submitted yet. The IEEE 802.3.1 completes Recirculation Sponsor 
Ballot on 4/30. Dan submitted an Approve ballot, the document is 
expected to be released in June, probably with reference to the 
Internet-Draft.

7.2. Relevant Documents
- IEEE 802.3.1 Draft
- http://datatracker.ietf.org/wg/opsawg/charter/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/

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 - in 
progress, Sponsor Ballot started, comments need to be submitted until 
1/13 - Done
- 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 - now on the OPSAWG 
charter, CRITICAL TIMING issue initial I-D to be submitted by 12/28, to 
become an OPSAWG document before 1/25 - done
- 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. - Now on OPSAWG charter
- Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB 
document, to explain the situation - Done
- Dan Romascanu will submit an Approve Ballot in the Recirculation 
Sponsor Ballot (if all related issues are addressed) - Done


8. IETF 6LOWPAN and IEEE 802.15
8.1. Description - CLOSED


9. IETF PAWS WG and 802.11, 802.19, 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 
coordination.
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.
- At the 10/29 meeting we confirmed the decision to take out IEEE 802.15 
and IEEE 802.16 from the list. Coordination continues by now via 
participation of Gabor Bajko in both SDOs. Need confirmation this is OK 
with IEEE 802
- Status 4/30/13: draft-ietf-paws-problem-stmt-usecases-rqmts-15 was 
last-called and approved by the IESG, draft-ietf-paws-protocol is still 
in pre-WGLC state

9.2 Relevant Documents
- http://datatracker.ietf.org/wg/paws/charter/
- https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/
- https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

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 - Done
- Bruce to confirm the list and clarify at the IEEE plenary whether the 
current level of coordination is sufficient - Done
- PAWS WG chairs to notify the IEEE 802 WGs when documents reach Last 
Call


10. IETF IPPM and LMAP, and IEEE 802.16 Metrology Study Group
10.1 Description
- IEEE 802.16 Metrology Study Group => IEEE P802.16.3 ("Mobile Broadband 
Network Performance Measurements")
- Coordinate future work in the IEEE 802.16 with existing work in the IETF
- Status 4/30/13: LMAP BOF held at IETF-86, IEEE 802.16.3 met at the 
IEEE 802 Plenary, sent liaison statement requesting LMAP perspective of 
IEEE Project P802.16.3 Architecture and Privacy - 
https://datatracker.ietf.org/liaison/1244/

10.2 Relevant Documents
http://datatracker.ietf.org/wg/ippm/
http://www.ieee802.org/16/mbnpm/
https://datatracker.ietf.org/liaison/1195/
http://www.ietf.org/mail-archive/web/lmap/current/msg00132.html
http://www.ietf.org/mail-archive/web/lmap/current/msg00200.html


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) - Done
- email response sent by IPPM chairs and AD to IEEE 802.16 chair on 
11/28 - Done
- Report on P802.16.3 sent to LMAP list on 2012-11-19 
<http://www.ietf.org/mail-archive/web/lmap/current/msg00132.html>
- Report on P802.16.3 sent to LMAP list on 2013-01-24 
<http://www.ietf.org/mail-archive/web/lmap/current/msg00200.html>.



11. IETF Mobile IP and EC OmniRAN 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
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.
Roger reported in the 10/29 meeting that discussions are expected to be 
hold at the plenary meeting and he expects to have information to report 
after the plenary
Roger reported in a mail sent on 11/26 that the IEEE 802 Executive 
Committee (EC) initiated the EC OmniRAN Study Group. It is chartered 
through the March 802 Plenary, with an expectation of extension through 
July. Max Riegel is the chair.
Max Riegel sent a mail to the IESG on 12/11 including information on the 
Study Group
12/17 Status (Roger): Next Study Group meeting in January, will discuss 
requesting time in the INT Area meeting for a presentation and 
discussion
Status 4/30/13: OmniRAN presentation was given at the 3/6/13 face2face 
meeting followed by Q&A and discussions

11.2. Relevant Documents
http://www.ieee802.org/OmniRANsg/
http://www.iab.org/wp-content/IAB-uploads/2013/01/omniran-13-0011-01-ecsg-omniran-introduction-and-way-forward.pptx

11.3. Owners - Max Riegel

11.4. Action Items
- Discuss communication and coordination level in the 12/17 meeting - 
Done
- IEEE will communicate after the January Interim whether to request 
presentation and discussion time in the INT Area meeting in Orlando. 
Done
- planning for a 30 min presentation on the OmniRAN SG at the face-to-
face leadership meeting by Max Riegel - Done


12. IETF HOKEY and IEEE 802.21
12.1. Description CLOSED


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
At the 10/29 virtual meeting Subir reported about the discussion with 
MIF in Vancouver, and there presentations in .21.  There's a joint draft 
from both groups that will be presented at Atlanta IETF.  Hoping for 
more discussion. Ralph confirmed that the draft's been posted, did not 
review it yet.
12/17 Status (Ralph): There was a discussion at the MIF WG regarding a 
draft describing the relationship of the work in MIF and in 802.21.  
Agree that there is some overlap, but not clear to what degree yet.  A 
couple of different potential architectures proposed and discussed.
Status 4/30: An 802.21 overview I-D was submitted draft-zuniga-
mif-802-21-overview. The MIF architecture team has met twice since 
Orlando.   Discussion at this point is at a high level, and doesn't 
really touch directly on 802.21.   Juan-Carlos Zuniga volunteered to 
work on this team. It's unlikely that the team is going to reach the 
point of directly discussing 802.21-related work between now and Berlin; 
at this point the strategy is to document use cases and identify changes 
to IP-layer protocols and protocol use patterns as they relate to 
various Multiple Provisioning Domain (MPD) scenarios the team has 
identified. The team does intend to address the behavior of the host, 
and at that point we will probably start thinking about how what we are 
talking about relates to 802.21, but the current strategy is to address 
that aspect of the MPD work only after having thoroughly explored use 
cases and trying to come up with a strategy for addressing gaps in 
existing IP protocols.


13.2. Relevant Documents
http://www.ieee802.org/21/
http://datatracker.ietf.org/wg/mif/
https://datatracker.ietf.org/doc/draft-seite-mif-cm/
https://datatracker.ietf.org/doc/draft-zuniga-mif-802-21-overview/

13.3. Owners - Subir Das, Ted Lemon

13.4. Action Items
- Subir Das to report back from discussions at the November IETF meeting 
and IEEE Plenary - Done, reported by Ralph
- continue follow-up until issues related to architecture and solutions 
clarify - Done
- Subir and Ralph to discuss the status in the second half of 2/12 - 
Done
- Meet after IETF-87 and discuss the impacts/dependencies.



14. IETF IPFIX Information Elements for Data Link monitoring
The IPFIX WG specifies a couple of data link Information Elements, to be 
added to http://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.

Status 12/17 (Benoit): I-D was sent via liaison for review to IEEE 
802.1, missed deadline for a formal answer (during IEEE 802 Plenary 
week), was later forwarded to the IEEE 802.1 reflector for comments from 
individuals, but did not get any feedback
Status 4/30/13: WGLC was announced on the coordination list. Comments 
made by Pat on draft-02 were discussed; they need to be addressed by the 
editors in draft-03

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 
<Quittek@neclab.eu>, Nevil Brownlee <n.brownlee@auckland.ac.nz>)

14.4. Action Items
- IETF needs to receive feedback from the IEEE - Done
- Action (Benoit): Proceed to IESG review, send again to IEEE 802.1 for 
review during IETF Last Call
- Feedback (by Pat Thaler) received on the IPFIX list, authors will 
address it on the list and on revised I-D


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.

Status 12/17: comments received from 802.11, but not from 802.1. I-D 
forwarded for comments to participants in the Security TF
Status 1/31: message from Mick Seaman - no comments from the Security TF
Status 4/30/13: second WGLC was distributed, comments received from Max 
Riegel need to be addressed

15.2. Relevant Documents:
http://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext/

15.3. Owners
Bernard Adoba, the RADEXT chairs (Jouni Korhonen 
<jouni.korhonen@nsn.com> and Mauricio Sanchez 
<mauricio.sanchez@hp.com>), and Benoit Claise

15.4. Action Items
- address issues raised by Max Riegel in draft-03
- send again document for comments when it reaches IETF Last Call


16. IEEE802.1Q SRP (and Gen2 updates) and RSVP/SIP
16.1. Description
IEEE 802.1Q currently includes a procedure for reserving bandwidth for 
particular streams and learning the worst case delays for those streams. 
Streams are identified using a stream ID that is the concatenation of 
the source MAC address and an arbitrary 16-bit number (for IP streams, 
it was expected to be the port #, but the only requirement is that it be 
unique for a particular source MAC address). The reservation is made 
using the 802.1Q MRP scheme, where the registration parameters are the 
StreamID, a destination MAC, a QoS class, a bandwidth requirement, and a 
stream ranking. Currently, the destination MAC address *must* be a group 
address, even if there is only a single listener since so many of the 
use cases need multicast, and handling both unicast and multicast was 
originally viewed as needless complication. The QoS class is called an 
"SR Class" and currently corresponds to expected delay requirements, 
where class A is for highly interactive applications such as live 
musical performance, while class B is for less stringent uses. Bandwidth 
is measured as worst-case bytes per second as measured over a class-
specific interval (125us for class A, 250us for class B). Rank currently 
only has two values, "emergency" and "normal".

The intention always was to allow RSVP and/or SIP to use SRP procedures 
to gain true L2 guarantees on bandwidth and latency, but not much has 
been done up to this point. There is an industry-specific effort 
underway by the AVnu Alliance (www.avnu.org) to specify a way to use 
SIP/SDP as a way for applications to access SRP services across multiple 
subnets.
SRP is under revision right now, with various improvements in the queue:
1) Two-way and unicast reservations (for VOIP-type applications)
2) Multiple path establishment using IS-IS topology discovery.
3) Reduced "chattiness" due to the current MRP procedures.
4) Expanded QoS classes to support new scheduled (802.1Qbv) and 
preempting (802.1Qbu) traffic.
5) (others)

12/20: Response from RAI AD Gonzalo Camarillo - with respect to point 
16, I assume your intention is to work on extending SIP and SDP and not 
so much on extending RSVP, is that correct? If so, a good starting point 
would be to get your technical people to discuss those issues on the 
DISPACTH mailing list:

https://www.ietf.org/mailman/listinfo/dispatch

The DISPATCH community may direct you to other working groups (e.g., 
SIPCORE or MMUSIC) if needed.



16.2. Relevant Documents
IEEE Std 802.1Q-2011
"AVB Gen2 assumptions" <http://www.ieee802.org/1/files/public/docs2012/
avb-pannell-gen2-assumptions-1112-v12.pdf>
RSVP - Resource Reservation Protocol (a gaggle of RFCs)
SIP - "SIP: Session Initiation Protocol" <http://tools.ietf.org/html/
rfc3261>
SDP - "SDP: Session Description Protocol" <http://tools.ietf.org/html/
rfc4566>

16.3. Owners - Michael Johas Teener, Brian Haberman

16.4. Action Items
- Michael to confirm response from Gonzalo and to propose ways to 
proceed


17. IEEE 802.1AS/1588 and NTP
17.1 Description
IEEE 1588 and its primary L2-only profile, IEEE 802.1AS, define 
protocols and procedures for very precise and fast-responding 
synchronization. These procedures require some hardware-level time 
stamping services, and, in some cases, on-the-fly modification of 
packets as they are transmitted. 1588 is heavily used within the telecom 
and test/measurement community, and has been proposed for various smart 
grid applications as well. The L2-only 802.1AS is used in professional 
A/V networks, and is also in other environments where multiple L2 
technologies are needed (the other 1588 profiles are Ethernet-only, even 
though they use IPv4 or IPv6 packet formats).

The time format chosen by 1588 is a 64-bit seconds/nanoseconds composite 
instead of a seconds/fractions of a second composite as used by NTP. 
(Hey, don't blame me! I wanted the NTP format, myself.)

Right now there are no specified procedures for NTP to use 1588/802.1AS 
when available, nor is there a router spec to define how 1588 can be 
used in the wider internet. There *are* a few papers that show that a 
"universal" time router/bridge could be built, and that if it were 
properly specified, the performance would be equivalent to any 
particularly 1588 profile.
IEEE 1588 is about to be opened for revision, and the IEEE 802.1AS 
revision has already started as project 802.1ASbt.

Status (4/30/13 - Brian): The action item to form a small design team is 
on hold from the IETF perspective.  After some discussion, it was 
decided to hold off on the formation of any design team until the IEEE 
1588 PAR is approved and the 1558/TICTOC liaison is in place.  Once 
those actions happen, we can revisit the topic.

17.2 Relevant Documents
IEEE Std 1588-2008 - "Precision Clock Synchronization Protocol?for 
Networked Measurement and Control Systems",<http://standards.ieee.org/
findstds/standard/1588-2008.html>

IEEE Std 802.1AS-2011 - "Timing and Synchronization for Time-Sensitive 
Applications in Bridged Local Area Networks", <http://
standards.ieee.org/findstds/standard/802.1AS-2011.html>

NTP -"Network Time Protocol Version 4: Protocol and Algorithms 
Specification",RFC 5905, June 2010

http://ieee802.org/1/files/public/docs2013/as-mjt-ISPCS-39-11-next-gen-
PTP-0113.pdf

17.3 Owners - Michael Johas Teener

17.4 Action Items
- need one or more IETF experts to work with the 1588 and 802 
communities, particularly since the relevant parts of those standards 
are (or soon will be) open for revision. Dan to approach the Transport 
and RAI ADs about how to proceed, copy Michael.

- no response from the IETF ADs, need more information, proposal for a 
presentation by Michael and discussion at the face-to-face meeting on a 
possible unification of 1588, 802.1AS, and any number of "protocol 
specific" time synch methods

-(at the f2f meeting): Brian Haberman will work with Michael Johas 
Teener to form a small design team to clarify the issues going on in the 
study group on Time Protocols Unification.



18. 802.1AS/1588, 802.1Q time aware shaper(s) and RTP
18.1. Description
RTP is viewed as the primary packet format for IP-based audio and video 
streams. The existing protocol uses various methods for labeling the 
time-significance of a particular chunk of data, and then uses yet 
another protocol (RTCP) to do the "cross timestamp" to associate the 
somewhat abstract timestamp used in the RTP packets to another time 
source that has more relevance to the application.

IEEE 1722 is a non-routable simple streaming format similar to RTP and 
the IEC 61883 formats used by Firewire: IEEE 1394). Although 1722 was 
originally only being used in the pro A/V community, it's also being 
used in automotive and industrial control networks.

Recent work in the IETF AVT-core group is building on new RTP extensions 
so that a precise timestamp based on 1588 or NTP can be directly used 
without the RTCP cross-timestamp. This simplification work opens up the 
possibility of using RTP as an IP carrier of IEEE 1722 streams in mixed 
IP/1722 environments.

12/20: Response from RAI AD: you probably want to start by discussing 
the issues on the AVT mailing list (AVTCORE working group). The actual 
work to be done may end up in a different working group (e.g., AVTEXT), 
but starting discussions on the AVT list is a good starting point.

https://www.ietf.org/mailman/listinfo/avt

If in addition to engaging with the right technical people at the IETF 
(to be found in the mailing lists above) you would like to get some type 
of support from us (i.e., the area directors), just let us know and we 
will be more than happy to help.


18.2. Relevant Documents
IEEE Std 1722-2011 - "Layer 2 Transport Protocol for Time Sensitive 
Applications in a Bridged Local Area Network", <http://
standards.ieee.org/findstds/standard/1722-2011.html>

RTP - "Standard 64, RTP: A Transport Protocol for Real-Time Applications 
<http://tools.ietf.org/html/rfc3550>

"RTP Clock Source Signalling", internet draft?draft-ietf-avtcore-
clksrc-01

18.3. Owners - Michael Johas Teener

18.4. Action Items
- Michael to confirm response from Gonzalo and to propose ways to 
proceed

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

- discussion at the 10/29 meeting: The requirements doc is going through 
WGLC so will come to IESG fairly soon. The framework doc being 
considered as a WG doc, so it has some time before it will be published 
by the WG.

- Status 12/17 (Ralph): Had a conversation with the TRILL WG, they're 
going to progress the work for OAM for TRILL by progressing a 
requirements doc then a framework doc.  If at that point they decided to 
go with an 802.1 base, they will go back to 802.1 and make sure that it 
doesn't infringe on the 802.1 OAM.  But have to get the requirements and 
framework done first.

- Status 4/20/13: https://datatracker.ietf.org/doc/draft-ietf-trill-oam-
req/ was published as RFC 6905, draft-ietf-trill-oam-framework is 
discussed by the WG (pre-LC), draft-tissa-trill-oam-fm was not yet 
adopted as WG item

19.2. Relevant Documents

https://datatracker.ietf.org/doc/draft-ietf-trill-oam-req
http://www.ieee802.org/1/files/public/docs2012/liaison-tissa-oam-ieee-trill-0912-v02.pptx
https://datatracker.ietf.org/doc/draft-ietf-trill-oam-framework/
https://datatracker.ietf.org/doc/draft-tissa-trill-oam-fm/

19.3. Owners  Ted Lemon, Norm Finn, Ben Mack-Crane

19.4. Action Items
Ralph will send the TRILL OAM requirements document to IEEE 802.1 expert 
review (Pat, Norm, possibly other) - Done

Follow the TRILL OAM documents progress in the WG and send them for 
review to IEEE 802.1 when they reach milestones (WGLC, IETF LC)


20. Area Name - use of TRILL as an alternative path selection protocol 
for use in 802.11 mesh networks

20.1. Description - CLOSED


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