2013-09-30: Potential areas for IETF/IEEE802 Coordination v09
slides-interim-2021-ietfieee-02-sessa-2013-09-30-potential-areas-for-ietfieee802-coordination-v09-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 0.8 revised after the 5/2/13 meeting 0.9 revised for the
period between 5/2/13 and 9/22/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.

5/22/13 - following mail exchange between Tony, Adrian and Dan  information
and request for comments from individuals about
https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/ was sent to the IEEE
802.1 WG reflector.

Status 5/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

Status 6/17/13 (Adrian): BFD on LAGs - The document has been adopted as a
working group draft See it at
http://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/. The problem statement
document is in IETF last call until 19th June. This was announced on the
appropriate IEEE exploders. Progress seems to be smooth and an RFC is likely to
result relatively soon. The BFD working group is not meeting at IETF-87 in
Berlin.

2.2 Relevant Documents
https://datatracker.ietf.org/liaison/1192/
http://datatracker.ietf.org/doc/draft-mmm-bfd-on-lags/
https://datatracker.ietf.org/doc/draft-ietf-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

6/5/13: draft-ietf-nvo3-overlay-problem-statement-03.txt in IETF LC,
announcement shared on list

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, WGLC and IETF LC.

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. 9/9/13:
draft-ieee-rac-oui-restructuring-01.txt submitted

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, and 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. - Status 5/6/13: revised I-D
draft-ietf-opsawg-rfc5066bis-02 was submitted, second Recirculation Ballot in
IEEE 802.3.1 completed - Status 6/19/13: IEEE standard approved - Status
6/25/13: revised I-D draft-ietf-opsawg-rfc5066bis-03.txt submitted - Status
8/13/13: IEEE standard published as IEEE 802.3.1-2013

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 - Status 5/2/13:
reasonable progress with draft-ietf-paws-protocol, no worries about progress -
6/20/13: Last Call issued on
http://tools.ietf.org/html/draft-ietf-paws-protocol-06, sent to the
coordination list

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/
- http://www.ietf.org/mail-archive/web/paws/current/msg01535.html

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/ - Status 5/2/13: LMAP is still in
pre-charter mode, official communication will be possible only after chartering
- Status 9/13: the LMAP WG was chartered and hold its first meeting at IETF-87.
Status of the IEEE 802.16 Metrology activity unclear. Do we need to keep this
AI open?

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
http://datatracker.ietf.org/wg/lmap/charter/

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 Status 5/2: There is concern
in 802 about what part of the problem belongs in 802 and if so in an existing
group like .1 or .21, or a new group.  Not expecting the group to settle on
this until we're approaching the November meeting.  Still working on the
problem statement. 5/13: OmniRAN report presented at IEEE interim meeting 
presentation pointer sent to the list

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
https://mentor.ieee.org/omniran/dcn/13/omniran-13-0030-04-ecsg-may-2013-waikoloa-agenda.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 - IEEE 802 will update about outcome of
the SG work - probably after the November Plenary meeting

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. Status 2/5/13
(Ted): The MIF WG currently has an action to develop an architecture doc and
that's the main thing they're dong right now.  The architecture doc is focusing
on layer 3 and above.  The doc doesn't talk much about layer 2.  Right now I
don't think it will have a direct impact on anything in 802.21, but it's early
days yet.  Juan-Carlos did volunteer to participate and keep us apprised of any
conflicts.  Should have more output on the process either by the next
coordination call or the July IETF meeting. Status 9/19/13 (Ted): The work was
presented in Berlin and was well received.   Work continues.  There's nothing
particularly new to report on that front, although Juan Carlos seems to be
doing a good job of keeping the team informed of related work in the IEEE.  
We're expecting a fairly mature version of the document to be presented to the
working group for adoption prior to Vancouver.

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 - Inform team when
architecture I-D 00 is submitted - 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 Status 2/5/13 (Benoit): Should be ready to
progress to IETF LC soon.  Waiting on a revision from the author first.

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 Status
5/2/13 (Benoit): One new revision of this was posted today.  Not sure if this
is final, a third WGLC until May 9th. Status 7/13:
draft-ietf-radext-ieee802ext-08.txt submitted and discussed at IETF-87 with
remote participation from Mick Seaman 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. - 2/5/13: missing status from Michael - 5/21/13: The PAR and
5Criteria for P802.1Qcc Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements distributed to the mail list - Status 6/17 (Michael):
The TSN (time-sensitive networking)) task group has agreed that the cooperation
with the IETF is vital, but we haven't got ourselves properly organized to make
real progress. It is on the agenda for the July meetings in Geneva, however.
Since there is no real overlap in working group membership between TSN and
DISPATCH or TSVWG (and everyone has day jobs), it's hard to recruit people to
do this  nonetheless, the chair (me) will find someone(s) willing to start the
coordination by the end of the summer. - 7/13: P802.1Qcc approved QUESTION:
should we keep this item open?

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 IEEE 802.1Qcc project
- http://www.ieee802.org/1/pages/802.1cc.html

16.3. Owners - Michael Johas Teener, Brian Haberman

16.4. Action Items
- Michael to confirm response from Gonzalo and to propose ways to proceed
- Pat to send message to Michael asking for status
- Consider closing this item, unless scope is clarified

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. Status (2/5/13 - Jon): Waiting for formality of 10-day letter ballot to
close Status (6/17/13 - Brian): Waiting for decision in the IEEE before
coordinating with the IETF (TICTOC & NTP)

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, Brian Haberman

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. - (2/5/13 meeting):
The coordination team will follow up with the design team that will be formed
to work on this item.

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. 2/5/13: missing status from Michael

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
- Pat to send message to Michael asking for status
- QUESTION: should we keep this item open? Consider closing this item, unless
scope is clarified

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 - Status 2/5/13
(Donald): Framework draft had a lot of comments, expecting to be WGLC soon. 
Fault management doc needs to be reviewed, and then there will be an effort to
move that to WG doc.  The performance management doc is not as far along. -
8/20/13: The TRILL WG re-chartered, new charter includes OAM. Rechartering was
communicated on the mail list.

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/
http://datatracker.ietf.org/wg/trill/charter/

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

21.1. Description:

BOF activity in the IETF which may lead to the formation of a WG which would
focus one enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard. If
formed, the working group will define an open standard-based architecture that
covers the formation and the operation of a wireless mesh based on the TSCH
technology, and the aggregation of multiple meshes over a high speed backbone,
including security, link management for the IPv6 network layer consumption,
peer management and routing. The group will document best practices, and
standardize the missing components to achieve industrial-grade criteria for
jitter, latency, scalability and reliability.

In particular the group will define how packets that belong to a deterministic
IPv6 flow are marked and routed or forwarded over the mesh within jitter and
latency budgets.  When possible, the group will reuse existing protocols such
as IPv6 ND, RPL and 6LoWPAN with the minimum adaptation required to meet
criteria for reliability and determinism within the mesh, and scalability over
the backbone. The WG will focus on three scheduling models: - a centralized
route computation that builds and maintains the communication schedule, and
distributes it to the nodes. This schedule includes forwarding information
associated to time slots;  RPL operations only apply to emergency repair
actions when the reference topology becomes unusable. - a distributed resource
reservation and signaling protocol that establishes tracks between source and
destination nodes along  multi-hop routes identified by RPL. - a best effort
resource allocation that is used to transport data frames on a per hop basis in
the absence of a reservation protocol. In IEEE 802.15: (Bob): Go to the 802.15
website and look for L2R under public docs.  The group formed in March with a
goal to spend 6 months to end up at a project point. Status 9/22  6tisch
charter in external review, on IESG agenda for 9/26, external review message
distributed

21.2. Relevant Documents
- Mail list https://www.ietf.org/mailman/listinfo/6tsch
- drafts and other documents are centralized at https://bitbucket.org/6tsch
- http://datatracker.ietf.org/doc/charter-ietf-6tisch/

21.3. Owners: Ted Lemon, Bob Heile

21.4. Action Items
- follow the activities in the IETF and IEEE 802.15, share information
informally until activities are chartered

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