* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Timeframe IETF 85 (Atlanta)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 17:00 PT Monday, September 24 (01:00 UTC Tuesday, September 24). The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconferece, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before September ?.



RFC Format (rfcform) Status: Approved for IETF 85


Fixed Mobile Convergence (fmc) Status: Approved (if room) for IETF 85

  • Description:

More and more operators today are globally active and offer fixed and mobile services, i.e. ubiquitous access to universal services both from fixed wireless access http://trac.tools.ietf.org/bof/trac/wiki/WiFi and via mobile cellular networks to terminals or User Equipment (UE) that can connect to both networks. Especially with upcoming cloud services users request for continuous broadband access to their data stored on servers worldwide. Since best available access networks may not be operated by the same provider at the users location an interoperation between different fixed and mobile networks is required - independent of the used technology and the operator in charge.

Some issues have been identified in a joint workshop of Third Generation Partnership Project (3GPP) and Broadband Forum (BBF) which was held in November 2011 and joint work with IETF has been called for.

Fixed Mobile Convergence (fmc) deals with the issues surrounding the interactions of fixed and mobile networks. Of specific interest are issues with serving access to the UEs that requires the sharing of subscribers' policies between the fixed and mobile networks. Existing different http://trac.tools.ietf.org/bof/trac/wiki/WiFi deployment scenarios range from WLAN access points directly connected to a mobile operators core (tight coupling) via mobile operator owned WLAN access points to one or more APs controlled by a fixed network operator or single APs at residential premises. Whereas the first scenario is out of scope here (WLAN acting just as another Radio Access Technology beside GERAN, UTRAN or LTE) the second scenario includes policy convergence whereas the latter ones describe pure interworking between fixed and mobile networks.

The scope of Fixed Mobile Convergence here covers both a pure interworking and a policy convergence scenario. In the interworking scenario, the mobile network passes on the mobile subscribers policies to an IP network which happens to be fixed, in order to maintain the end-to-end service level agreement and to support remote terminal and access network management. Explicitly, the fixed IP network must have partnership with the mobile network in Fixed Mobile Convergence interworking scenario. Fixed Mobile Convergence policy convergence scenario refers to using the mobile network policy framework also when UE access WLAN network and many technical issues are common with the interworking scenario.

Fixed Mobile Convergence has many use cases that require protocol work in IETF. The use case commonly called UE Identification use case refers to the following problem: Whereas in mobile networks the end user terminal is directly addressed and identified (e.g. by a SIM card) in fixed networks an access (e.g. Residential Gateway, RG) at users home is object of subscription. Here one or more end user terminals acess the RG and are addressed e.g. via a Network Address Translation (NAT) box placed at the RG to allow sharing IPv4/IPv6 public addresses by more than one UEs. In this case the edge router, called Broadband Network Gateway (BNG) would be unable to identify the traffic originated by the individual UEs. This problem has been identified and IETF work on required mechanisms to enable UE Identification in case of an RG with NATs have been encouraged in the joint 3GPP/BBF workshop in November 2011. An outcome of this workshop was the Chairmen's Summary slides at: http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip which is publicly available.

Another use case is UE Mobility use case. UE Mobility use case is based on the fact that in broadband network, the devices are assumed to be fixed and mobility status is not tracked. Especially in case of a user session to be continued across change from a point of attachment to the mobile network to the fixed network and vice versa a mobility mechanism for fixed networks is required. Since fmc is about the mobile devices accessing a network that is not originally designed for handling mobility, it is especially important by the network, i.e. the edge router to know if the UE is in the network or has disconnected. Protocol solution is needed to provide some signalling to the edge router when UE enters the network and more importantly when UE leaves the network.

Another use case is transporting link characteristics use case. Within mobile networks different service classes are defined and mapped to link quality characteristics such as CQI (Channel Quality Indicator) as defined by 3GPP. For maintaining a specific service quality agreed between user and operator across fixed and mobile networks the characteristics of the underlying access link have to be exchanged. Transportation of UE http://trac.tools.ietf.org/bof/trac/wiki/WiFi Link Characteristics use case is to enable UE to first detect the link characteristics of a newly connected WLAN network, possibly using an existing Application Programming Interface (API) and then to transport the link characteristics to the edge router. The edge router may then use this information to determine the best quality of service for the UE considering the quality of service information the edge router receives from the mobile network as well.

It is a goal of the BoF to identify ways how to develop protocol solutions for fixed mobile convergence within IETF and Int Area. Existing or being developed protocol solutions such as flow mobility which solves WLAN offloading of the UE's data traffic from the mobile network to WLAN network and network or host based mobility protocols and their extensions are out of scope. Roaming agreements between operators and all related issues needed to ensure fixed mobile convergence are out of scope.

The protocol work may involve extending Control And Provisioning of Wireless Access Points (CAPWAP) protocol, especially its Binding for IEEE 802.11. In doing the protocol work, the goal will be to identify gaps in existing protocols such as ICMP, IPv4/v6, CAPWAP, etc. and work on the extensions rather than developing completely new protocols. In doing the protocol work, multi-hop multi domain signalling mechanisms will be considered and the protocol will be secured. Any management and operations issues arising from the protocol solutions to the fmc use cases are in scope. Privacy issues related, e.g. to UE Identification use case are in scope.

In doing its work, a close work together with all interested and related working groups is foreseen, especially with intarea, dmm, mif, and 6man working groups and a coordination with radext and dime working groups shall take place.

Proposed Agenda:

  • Agenda Bashing (5)
  • Fmc Motivation (5)
  • Fmc Problem Statement (10)
  • Fmc Requirements (20)
  • Protocols (20
  • Discussion (30)

Links to the draft charter, relevant Internet-Drafts

  • Draft Charter Items:


Extensions to the Bonjour protocol suite (mdnsext) Status: Approved for IETF 85

  • Description:

The Bonjour protocols suite, comprising mDNS (draft-cheshire-dnsext-multicastdns / RFC 6762 in AUTH48) and DNS-SD (draft-cheshire-dnsext-dns-sd / RFC 6763 in AUTH48), are widely used for discovery and resolution of services and names on a single link. In principle DNS-SD can be used with conventional unicast DNS for wide-area service discovery but in practice this capability is not widely used.

Aerohive, Aruba, Xirrus, and Cisco have recently announced "Bonjour gateway" products which allow service discovery beyond the local link. These products were brought to market rapidly in reponse to evidence of market demand such as the Educause petition and it's unclear whether they represent a good long-term direction for service discovery protocol development.

It would benefit the Internet to pool the creative energy of these four companies and others to develop better, more scaleable long-term solutions for wide-area service discovery. Individuals from these companies have indicated their interest in collaborating to develop an IETF-standard solution which would lead to open specifications and interoperable products from multiple vendors.

The ZigBee Smart Energy Profile 2.0 commercial standard currently under development has specified mDNS as its method of zero configuration discovery. However, its use of multi-link wireless mesh subnets (LLNs) and disparate physical layers will require extensions to mDNS to allow it to operate across multiple links. The homenet architecture also raises the question of whether to extend or proxy zero configuration naming and discovery services.

Because of the interest in solving the zero configuration service and name resolution for routed networks, and the diversity of solutions already under consideration, it is timely for the IETF to consider the development and specification of extensions to Bonjour. This BoF will gauge interest in addressing this topic in the IETF and determine if formation of a Working Group should be pursued.

  • The responsible Area Director (AD) - Ralph Droms
  • BoF Chairs (or the ADs as placeholders) - Tim Chown, Thomas Narten
  • Number of people expected to attend - 50
  • Length of session (1, 1.5, 2, or 2.5 hours) - 1.5 hours
  • Conflicts to avoid (whole Areas and/or WGs) - homenet, 6man, dnsext, dnsop, v6ops
  • Does it require WebEX? If so, why? - no
  • Does it require Meetecho? If so, why? - no
  • Mailing list: mdnsext@ietf.org
  • Mailing list archive: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html

Tentative agenda:

  • Note Well, agenda bashing and other preliminaries (10 minutes)
  • Introduction and ground rules for the BoF (10 minutes)
  • Goals for the BoF (10 minutes)
  • Summary of Bonjour (10 minutes)
  • Use cases for Bonjour in routed networks (15 minutes)
  • Requirements and other considerations (15 minutes)
  • Discussion (20 minutes)

Draft Charter/Scope:


mdnsext draft charter

Currently, zeroconf networking protocols are generally used to discover services within the scope of a single link. In particular, the Bonjour protocols suite, comprising mDNS (draft-cheshire-dnsext-multicastdns / RFC 6762 in AUTH48) and DNS-SD (draft-cheshire-dnsext-dns-sd / RFC 6763 in AUTH48), are widely used for discovery and resolution of services and names on a single link.

Such discovery is commonly used in many scenarios, including home networks, commercial and campus enterprise networks, and can be used in certain mesh networks. However, the multicast zeroconf protocols are constrained to link-local scope, so can only be used to discover services on the same link. In a typical current home network, which is a single link, users should experience the desired discovery behaviour. However, in future multi-link home networks (as envisaged by the homenet WG) and in routed campus or enterprise networks, devices and thus users can only discover services on the same link, which is a significant limitation. Such limitations have led to calls, such as those by the Educause petition, to develop an appropriate solution to span multiple links.

In addition, the Zigbee Smart Energy Profile 2.0 commercial standard currently under development has specified mDNS as its method of zero configuration discovery. However, its use of multi-link wireless mesh subnets (LLNs) and disparate physical layers will require extensions to mDNS to allow it to operate across multiple links.

In principle DNS-SD can be used with conventional unicast DNS for wide area service discovery spanning multiple links, but in practice this capability is not widely used. As a result, as demand for service discovery across routed networks grows, some vendors are beginning to ship their own early solutions. It is thus both timely and important that efforts to develop improved, scalable service discovery solutions for routed networks are coordinated towards producing a single, standards-based solution.


To that end, the primary goals of the mdnsext WG are as follows:

  1. To document a set of requirements for service discovery across routed, multi-link networks in the following four scenarios:

a) Commercial enterprise networks b) Academic/educational/university campus networks c) Multi-link home networks, such as those envisgaed by the HOMENET WG d) Multi-link/single subnet (mesh) networks, such as ROLL/6LOWPAN subnets

  1. To develop an improved, scalable solution for wide-area service discovery spanning multiple links, applicable to the scenarios above.
  1. To develop a solution to seamlessly integrate zeroconf (mDNS) and unicast (global DNS) name services, which should include consideration of both the name resolution mechanism and the namespace.

It is important that the mdnsext WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the mdsnext WG, and thus coordination between the WGs is desirable.


The WG will produce three documents: an Informational RFC on the requirements for wide-area service discovery protocols; a Standards Track RFC documenting a wide-area service discovery solution that is applicable to those scenarios; and a Standards Track document describing a solution to seamlessly integrate mDNS and global DNS name services.


  • Jan 2013 Formation of the WG
  • Apr 2013 Adopt requirements draft as WG document
  • Aug 2013 Submit requirements draft to the IESG as an Informational RFC
  • Aug 2013 Adopt wide-area service discovery solution draft as WG document
  • Aug 2013 Adopt mDNS and global DNS integration solution draft as WG document
  • Dec 2013 Submit wide-area service discovery solution draft to the IESG as Standards Track RFC
  • Dec 2013 Submit mDNS and global DNS integration solution draft to the IESG as Standards Track RFC


Relevant Internet-Drafts:

Low power/Lossy Networks Futures (LLN-Futures) Status: Not approved for IETF 85

Description: Lowpower/Lossy? Networks are characterized by nodes that communicate using RF (mostly) or other media that have the tendency to "lose" packets, ie. provide less than an ethernet quality packet delivery. The 6lowpan WG worked on an adaptation layer for one such PHY/MAC - IEEE 802.15.4 2006. Since that time new LLN PHY/MACs have and are being developed that provide similar, but slightly different characteristics. While the IETF could continue to develop many "IP over Foo" RFCs for each of these, a better solution might be to take a look at RFC4944 and RFC6282 with respect to the new 15.4 developments and the new work on Layer 2 Forwarding services. Additionally the 6lowpan group did not address network or device management or end to end security over a multihop network. Both of these are crucial for the future success of IP based LLNs.

At this BoF we will review presentations on a few possible work items: multi-hop security, IPv6 over alternative phy/mac, a MIB for LLNs, efficient LLN multicasting, and using 6lowpan with Layer 2 Forwarding. To be clear and remove any confusion, this BoF and the intended working group would not be looking to develop a layer 2 forwarding mechanism. The work item would be to develop any necessary updates to the 6lowpan RFC to support layer 2 forwarding protocols being developed in the IEEE and other areas. Other potential work items might be brought up during the BoF.

One possible very focused scope would be to: Update RFCs 4944 and 6282 as related to that breadth of 802.15.4 MAC/PHYs and complete the work necessary for multi-hop security and device management of these same network.

The goal of the BoF is to generate a charter with deliverables and milestones for the formation of a Working Group.

Responsible AD: Ralph Droms - Internet Area

BoF Chairs: Geoff Mulligan and ????

Number of Attendees: 20 to 30

Length of Session: 1.5 hours

Conflicts to avoid: ROLL, Manet, COAP, Homenet, LWIG

Does it require a WEBEX? NO

Does it require Meetecho? NO

Proposed Agenda:

  • Agenda Bashing (10 min)
  • Presentations (45 min)
    • Multi-hop security (15 min)
    • IPv6 over 15.4[e,g,k,l] (15 min)
    • LLN MIB (10 min)
    • LLN Multicasting (15 min)
    • 6lowpan using IEEE Layer 2 Forwarding (15 min)
    • Charter and milestone discussion (20 min)

Link to mailing list: http://www.ietf.org/mail-archive/web/lln-futures/current/maillist.html

Operations and Management

Web PKI operations (wpkops) Status: Approved for IETF 85

  • Description: There are hundreds of variations on the Web PKI in regular use, and this can be a source of problems for certificate users, certificate holders, and certificate issuers. More consistency in Web security behavior is desirable, and a natural first step is to document current behavior. A working group is proposed for the purpose of documenting the operation of the Web PKI. The BoF is intended to gauge support for the proposal and confirm the availability of sufficient resources to complete the work.


Internet Video Codec (videocodec) Status: Approved for IETF 85


There are efforts underway by several groups to produce a next-generation, royalty-free (RF) video codec, including VPnext by Google [1,2] and Daala by Mozilla/Xiph?.Org [3]. While far from complete, we hope that these can become the backbone of a truly universally deployable, interactive video codec standard that is competitive with royalty-bearing offerings. These projects are just the start. Recent efforts within the MPEG LA to create an RF license for the Restricted Baseline profile of H.264, while ultimately unsuccessful, showed that there are many consumer device manufacturers that would support RF licensing for a video codec. Not all will participate in development, but even providing review, as some have agreed to do, is useful. In the CODEC WG, it was the input and feature requests from a wide range of IETF participants that led to a codec that excelled at an extremely broad range of applications. This kind of review is much easier for codecs, where there are easily-understood, measurable objectives ("everyone has two eyes"). The IETF is typically used to dealing with much thornier questions, such as, "Will this interoperate with legacy, possibly-broken implementations?" or "Is this protocol sufficiently extensible?"

The success of Opus from the CODEC WG has also shown that collaboration, based on the IETF's principals of open participation, can produce better results than competition between patented technologies. The IPR rules in BCP 78 and 79 are also critical for success. They impose a duty to disclose, and require exact patent or patent application numbers, in addition to basic licensing terms. This allows participants to evaluate the risk of infringement and, if appropriate, design work arounds, in any technology adopted, and assess the cost of adopting such technology. Because it does not force participants to agree to license their patents under RF terms, it helps to encourage participation even by those opposed to such terms (instead of guaranteeing they stay away). In addition to an environment which encourages third-party disclosures, this provides much better chances of success than SDOs which have a "patent-blind" process [4] or which require blanket RF grants.

  [1] http://downloads.webmproject.org/ngov2012/pdf/04-ngov-project-update.pdf
  [2] http://downloads.webmproject.org/ngov2012/wilkins/vpnext-results.html
  [3] http://xiph.org/daala/
  [4] http://lists.xiph.org/pipermail/theora/2010-April/003769.html

BOF agenda

Chair(s): Peter Saint-Andre (plus a possible TBD co-chair)

Area: RAI

Area directors: Gonzalo Camarillo and Robert J. Sparks

Draft agenda (subject to modifications):
- Note Well, logistics, agenda bash (Chairs, 5 min)
- Introduction and scoping of BoF (AD, 10 min)
- Goals (Chairs, 10 min)
- Engineering progress to date (Google, Mozilla 20 min)
- Is it reasonable to do this work at the IETF? (All, 45 min)
- Charter discussion (All, 25 min)
- Conclusions and next steps (Chairs/AD, 5 min)

Total timeslot: 2 hours

WG charter (proposed)

Internet Video Codec (video-codec)

Status: Proposed Working Group
Last Updated: 2012-09-24

Chair(s): TBD

RAI Area Director(s):
 Robert J. Sparks (rjsparks@nostrum.com)
 Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com)

RAI Area Advisor:
 Robert J. Sparks (rjsparks@nostrum.com)

Mailing Lists: video-codec@ietf.org

Description of Working Group

Problem Statement

According to reports from developers of Internet video applications and
operators of Internet video services, there is no standardized, high-quality
video codec that meets all of the following three conditions:

1. Is optimized for use in interactive Internet applications.

2. Is published by a recognized standards development organization (SDO) and
therefore subject to clear change control and IPR disclosure rules.

3. Can be widely implemented and easily distributed among application
developers, service operators, and end users.

There exist codecs that provide high quality encoding of video information, but
that are not optimized for the actual conditions of the Internet; according to
reports, this mismatch between design and deployment has hindered
interoperability of such codecs in interactive Internet applications.

There exist codecs that can be widely implemented, but were not developed under
the IPR rules of any SDO; according to reports, the lack of clarity in their
IPR status has hindered adoption of such codecs in Internet applications.

There exist codecs that are standardized, but that cannot be widely implemented
and easily distributed; according to reports, the presence of various usage
restrictions (e.g., in the form of requirements to pay royalty fees, obtain a
license, enter into a business agreement, or meet other special conditions
imposed by a patent holder) has hindered adoption of such codecs in Internet

According to application developers and service operators, a video codec that
meets all three of these conditions would: (1) enable protocol designers to
more easily specify a mandatory-to-implement codec in their protocols and thus
improve interoperability; (2) enable developers to more easily build innovative
applications for the Internet; (3) enable service operators to more easily
deploy affordable, high-quality video services on the Internet; and (4) enable
end users of Internet applications and services to enjoy an improved user


The goal of this working group is to ensure the existence of a single
high-quality video codec that can be widely implemented and easily distributed
among application developers, service operators, and end users. At present it
appears that ensuring the existence of such a codec will require a development
effort within the working group.  The core technical considerations for such a
codec include, but are not necessarily limited to, the following:

1. Designing for use in interactive applications (examples include, but are not
limited to, point-to-point video calls, multi-party video conferencing,
telepresence, teleoperation, and in-game video chat).

2. Addressing the real transport conditions of the Internet, such as the
flexibility to rapidly respond to changing bandwidth availability and loss
rates, or as otherwise identified and prioritized by the working group.

3. Ensuring interoperability and clean integration with the Real-time Transport
Protocol (RTP), including secure transport via SRTP.

4. Ensuring interoperability with Internet signaling technologies such as
Session Initiation Protocol (SIP), Session Description Protocol (SDP), and
Extensible Messaging and Presence Protocol (XMPP); however, the result should
not depend on the details of any particular signaling technology.

Optimizing for very low bit rates (typically below 64 kbps) is out of scope
because such work might necessitate specialized optimizations.

In addition to the technical objectives, there is one process goal, which is

5. Ensuring the work is done under the IPR rules of the IETF.

Although a codec produced by this working group or another standards
organization might be used as a mandatory-to-implement technology by designers
of particular Internet protocols, it is explicitly not a goal of the working
group to produce or select a codec that will be mandated for use across the
entire IETF or Internet community nor would their be any expectation that this
would be the only mandatory-to-implement codec.

Based on the working group's analysis of the design space, the working group
might determine that it needs to produce more than one codec, or a codec with
multiple modes; however, it is not the goal of working group to produce more
than one codec, and to reduce confusion in the marketplace the working group
shall endeavor to produce as few codecs as possible.

In completing its work, the working group should collaborate with other IETF
working groups to complete particular tasks. These might include, but would not
be limited to, the following:

- Within the AVT WG, define the codec's payload format for use with the
  Real-time Transport Protocol (RTP).

- Collaborate with RMCAT and any other appropriate working groups in the
  Transport Area to identify important aspects of packet transmission over the

- Collaborate with RMCAT to understand the degree of rate adaptation desirable,
  and to reflect that understanding in the design of a codec that can adjust
  its transmission in a way that minimizes disruption to the video.

- Collaborate with working groups in the RAI Area to ensure that information
  about and negotiation of the codec can be easily represented at the signaling

- Collaborate with working groups in the RAI Area such as CLUE and RTCWEB to
  ensure the codec can satisfy all of their video-related use cases.

The working group will coordinate with the ITU-T (Study group 16) and ISO/IEC
(JTC1/SC29 WG11), with the intent of submitting the completed codec RFC for
co-publication if they find that appropriate. The working group will
communicate a detailed description of the requirements and goals to other SDOs
including the ITU-T and MPEG to help determine if existing codecs meet the
requirements and goals. Information about codecs being standardized will be
available to other SDOs in the form of Internet-Drafts and the working group
welcomes technical feedback from other SDOs and experts from other

The Guidelines for Development of an Audio Codec within the IETF (RFC 6569)
will form the starting point for guidelines and requirements for achieving the
forgoing objectives for video. The working group will modify them as necessary
with lessons learned during that process, refining them into a new document in
accordance with the usual IETF procedures once consensus has been achieved.

A codec that can be widely implemented and easily distributed among application
developers, service operators, and end users is preferred. Many existing codecs
that might fulfill some or most of the technical attributes listed above are
encumbered in various ways. For example, patent holders might require that
those wishing to implement the codec in software, deploy the codec in a
service, or distribute the codec in software or hardware need to request a
license, enter into a business agreement, pay licensing fees or royalties, or
attempt to adhere to other special conditions or restrictions.

Because such encumbrances have made it difficult to widely implement and easily
distribute high-quality video codecs across the entire Internet community, the
working group prefers unencumbered technologies in a way that is consistent
with BCP 78 and BCP 79. In particular, the working group shall heed the
preference stated in BCP 79: "In general, IETF working groups prefer
technologies with no known IPR claims or, for technologies with claims against
them, an offer of royalty-free licensing." Although this preference cannot
guarantee that the working group will produce an unencumbered codec, the
working group shall follow BCP 79, and adhere to the spirit of BCP 79. The
working group cannot explicitly rule out the possibility of adopting encumbered
technologies; however, the working group will try to avoid encumbered
technologies that require royalties or other encumbrances that would prevent
such technologies from being easy to redistribute and use.


1. A set of Codec Standardization Guidelines that define the work processes of
the working group. This document shall be Informational.

2. A set of technical Requirements. This document shall be Informational.

3. Specification of a codec that meets the agreed-upon requirements, in the
form of an Internet-Draft that defines the codec algorithm along with source
code for a reference implementation. The text description of the codec shall
describe the mandatory, recommended, and optional portions of the encoder and
decoder. It is envisioned that this document shall be a Proposed Standard

4. Specification of a storage format for non-interactive (HTTP) streaming or
file transfer of the codec. It is envisioned that this document shall be a
Proposed Standard document.

Goals and Milestones
TBD  WGLC on codec standardization guidelines
TBD  WGLC on requirements, liaise to other SDOs
TBD  Requirements to IESG (Informational)
TBD  Liaise requirements RFC to other SDOs
TBD  Codec standardization guidelines to IESG (Informational)
TBD  WGLC on codec specification, liaise to other SDOs
TBD  Submit codec specification to IESG (Standards Track)
TBD  WGLC on storage format specification
TBD  Submit storage format specification to IESG (Standards Track)
TBD  WGLC on Testing document
TBD  Testing document to IESG


Interface to the Routing System (IRS) Status: Approved for IETF 85

Routers that form the Internet's routing infrastructure maintain state at various layers of detail and function. For example, each router has a Routing Information Base (RIB), and the routing protocols (OSPF, ISIS, BGP, etc.) each maintain protocol state and information about the state of the network.
A router also has information that may be required for applications to understand the network, verify that programmed state is installed in the forwarding plane, measure the behavior of various flows, and understand the existing configuration and state of the router.
Furthermore, routers are configured or implemented with procedural or policy-based instructions for how to convert all of this information into the forwarding operations that are installed in the forwarding plane, and this is also state information that describes the behaviour of the router.
The Interface to the Routing System (IRS) provides a common, standard, read / write interface to allow access to the information and state that enable the routing components of routing elements.
This BoF is to determine focus and support for work within the IETF to specify abstract data information models, specific data models, and protocols to operate the IRS. The BoF does not assume that new data modeling languages or protocols will be required - that decision is expected to form part of the analysis carried out by a working group if one is formed.
Responsible AD: Adrian Farrel
BoF Chairs: Ross Callon <rcallon@juniper.net> and Dave Ward <wardd@cisco.com>

  • Agenda-bashing and administrivia (chairs) [5:5]
  • Scope and purpose of BoF (AD) [5:10]
  • Problem statement and framework (TBD) [15:25]
  • Routing system use cases (TBD) [15:40]
  • Topology use cases (TBD) [15:55]
  • BGP use cases (TBD) [15:70]
  • Scope, limitations, and phasing of IRS (TBD) [10:80]
  • Potential charter (chairs) [10:90]
  • Discussion [20:110]
  • Summary and closure (chairs and AD) [10:120]

Expected Attendance: 200
Number of sessions 1
Length of sessions: 2 hours
Scheduled session: Monday November 5th, 17.40
Conflicts to avoid

  • Level 2: CCAMP, L2VPN, L3VPN, NVO3, GROW
  • Level 3: KARP, SIDR

Does it require WebEX?: No
Does it require Meetecho?: No
Special requests: Monday or Tuesday _please_
Draft charter: TBD
Mailing list: http://www.ietf.org/mailman/listinfo/irs-discuss


Certificate Transparency (certrans) Status: Approved for IETF 85

HTTP Authentication Mechanisms (httpauth) Status: Approved for IETF 85

Security Automation and Continuous Monitoring (sacm) Status: Approved for IETF 85


State Migration (sami) Status: Not approved for IETF 85

  • Description:

An end-to-end network flow typically traverses one or more "middlebox," which may retain state about the flow. These include, for example, firewalls, NATs, traffic optimizers, and similar. The flow-associated state is usually instantiated through a combination of traffic inspection and broad policies, but may also be created by the use of an explicit request or signaling mechanism. The problem of how to handle transfering flow-associated middlebox state when one flow endpoint moves is not a new one, but with some exceptions it remains largely unaddressed. For example, situations in which one endpoint or another "move" include mobile IP failover in a high-availability deployment, and VM (virtual machine) migration. Related problems include multihomed endpoints in SCTP and load balancing. Finding a standardized, interoperable solution to this problem is becoming more pressing with the increased reliance on virtualized servers in large datacenters, and with the inclusion of support for VM migration as a requirement in the nvo3 charter. While there has been considerable work done on instantiating middlebox state (midcom, nsis, pcp) and an existing framework and protocol for transferring device-associated state as it changes its point of attachment to the network, none of the existing technologies address the problems of identifying participating middleboxes (particularly the "migrated-to" middlebox), "triggering" the state transfer, and more general problems related to topology discovery. The goals of this BoF are to:

  • Determine whether or not there's consensus on the problem definition and scope,
  • Discuss whether there's an existing home for this work in the IETF, and if not whether there is interest and resources to support a new working group


LMAP / Large Scale Performance Measurement Status: Not approved for IETF 85