Agenda IETF105: hotrfc
Hot RFC Lightning Talks
(hotrfc) Ad Hoc
||Agenda IETF105: hotrfc
HotRFC @ IETF-105, Montreal
Sunday, July 21, 2019, 1800-2000
1. Service Oriented IP
Brian E Carpenter (email@example.com)
Service Oriented Internet Protocol (SOIP) proposes a new,
backwards-compatible, approach to packet forwarding, where the service
required rather than the IP address required acts as the vector for
routing packets at the edge of the network. There's a draft
(draft-jiang-service-oriented-ip) and there's even some toy code, at
2. Asymmetric IPv6
Brian E Carpenter (firstname.lastname@example.org>
Asymmetric IPv6 is a new approach to IPv6 header compression for use
in IoT scenarios where minimizing packet size is crucial but routing
performance must be maximized. There's a draft
(draft-jiang-asymmetric-ipv6). The idea is to make packets shorter
without needing a decompression step.
3. iCAN Do It
Liubing (Leo) (email@example.com)
iCAN (instant Congestion Assessment Network) is a mechanism running
directly on network nodes:
o To adjust the flows paths based on real-time measurement of the
o The measurement is to reflect the congestion situation of each path,
so that the ingress nodes could decide which flows need to be
switched from a path to another. This is something that current SDN
and TE technologies can hardly achieve:
o Controller is slow and far from the data plane, it is neither able
to assess the real-time congestion situation of each path, nor able
to assure the data plane always go as expected (especially in SRv6
scenarios). However, iCAN can work with SDN perfectly: controller
planning multi-path transmission, and iCAN does the flow
o Traditional TE is not able to adjust the flow paths in real-time.
Aim: call for attention and partners
Relevance to IETF: This work might be related to TEAS/SPRING/IPPM WGs.
4. Trustworthy Multipurpose RemoteID (TM-RID)
Bob Moskowitz (firstname.lastname@example.org)
Stuart Card (email@example.com)
To mitigate the risks presented by Unmanned Aircraft Systems (UAS),
the US FAA and other government agencies internationally soon will
require, and various bodies are drafting standards for, remote
identification. ASTM's proposed Broadcast Remote ID specifies how
Unmanned Aircraft (UA) within Line Of Sight (LOS) of an observer can
use a one-way RF broadcast to identify themselves and provide other
latency-sensitive safety-critical information. ASTM's proposed Network
Remote ID specifies how this same information can be obtained,
starting from an observed UA's location, via the Internet. All such
proposals hinge on a unique ID for each UA, a method whereby this ID
(along with operator contact information etc.) can be registered, and
a method by which a subsequent ID assertion can be authenticated by
Network RemoteID uses the Internet to map current aircraft locations
to identities. To avoid being deceived by malicious spoofing of these
critical mappings, we need strong authentication. To maintain privacy
(from unauthorized eavesdroppers, not from legitimate authorities), we
need strong encryption. HIP provides both of these. Thus, we propose
to consolidate the 4-tuple of (UA ID, UA physical location, UA onboard
host ID, UA onboard host logical location [IP address list]) to a
3-tuple by standardizing the HIP Host Identity Tag (HIT) as a 4th
RemoteID type. Depending upon the level of adoption by a given UAS
operator, this can provide 3 levels of benefit:
1. Use of the Internet Domain Name System (DNS, the world’s largest
distributed database, with well-established update procedures) as
a RemoteID registry
2. Strong authentication of not only Network RemoteID but also
Broadcast RemoteID messages
3. Rapid establishment of authenticated and encrypted communications
with any observed UA that is suitably equipped.
We call this “Trustworthy Multipurpose RemoteID (TM-RID)” and have
begun preparations for prototyping and experimentation at the New York
UAS Test Site.
A sidebof will be held Monday at 6pm in room C2.
5. Mobility Networking
Sharon Barkai (firstname.lastname@example.org)
Would like to introduce a new draft-rfc we have been working on in the
area of mobility, v2v, v2x, networking within the LISP working
group. LISP is a set of RFCs dealing with virtual IP and
Over the past decade mobility networks progress was slow and quite
stuck for multiple reasons. Many of these reason primarily stem from
questionable pre-assumed peer-to-peer model for mobility, and
redundant protocol wars that follow - DSRC/c-v2x.
Vehicles in most road situations are not really peers, they briefly
happen to be in the same place at the same time. An enforced peer to
peer model to communicate situations introduces privacy,
interoperability, security, timing, and convergence problems which are
hard to impossible to solve.
As an example, a vehicle reaching a junction and about to turn into an
invisible problem (to him) such as construction, jaywalker, double
park, school-bus. The problem is clearly visible to cross traffic, but
that vehicle may receive multiple, conflicting, or no indications at
all from cross cars it doesn't know or trust.
To solve this problem we focused strictly on layer3-4 or
connectionless brokered mobility sessions. We use the
shared-road-location, or geo-state, as the brokering anchor of v2v v2x
communications. Nexar, having some of the largest v2v fleets, 10Ks in
every major US city, 100Ms miles of ride logs, together with Cisco and
academia propose the nexagon draft.
Nexagons tiles every road, lane, junction, shoulder, sidewalk with
1sqm H3 hexagons giving each an aggregated unicast and multicast
virtual IP (LISP EID) address. These are the in-network geo-state
network hexagons enable brokered, verified, private, resilient, LISP
based pub-sub exchange of road information. H3 Hexagons offer clear
bit operations to track impacted neighboring tiles, clear bitwise
geo-spatial hierarchy, approximation of lan-lat-rad that tiles, and
algorithmic 64bit HID to 128bit IP EID mapping.
We will describe the draft briefly in hotRFC, and few v2v v2x examples
including red-light-breach brokered-relayed in under 2msec in lab
conditions the largest 5G carrier, as well as real life footage
examples from US cities happening daily as time permits. The draft
will be discussed at more length in the routing area LISP-WG meeting
on July 22. Any questions can be forwarded to email@example.com or to
myself firstname.lastname@example.org, or to any of the co-authors listed in the
Hope this is clear, attaching a couple links to short video and the
6. An open congestion control architecture with network cooperation
for RDMA fabric
Roni Even (A) (email@example.com)
The requirement document discusses major problems of current Remote
Direct Memory Access (RDMA) fabric technologies and the requirements
for better performance. Based on that, the architecture document
proposes an open control architecture of hosts and networks for the
high performance RDMA fabric to provide better congestion handling for
High Performance Computing (HPC) and distributed storage accessing
applications which requires low latency and high throughput.
We will also have a side meeting to continue the discussion from
7. Strategies to drastically improve congestion control in high
performance data centers: next steps for RDMA"
Paul Congdon (firstname.lastname@example.org)
In current high-speed Datacenter Networks (DCNs), Remote Direct Memory
Access (RDMA) has become the dominant network technology. Congestion
control strategies are required to reduce the negative effects of
congestion, such as Head-of-Line (HoL) blocking. Among the proposed
solutions to mitigate congestion, Explicit Congestion Notification
(ECN) and some solutions based on it, are the most popular
ones. Unfortunately, the ECN closed-loop mechanism is not able to
react in a smooth way under most congestion scenarios. In this talk,
we describe the effects that lead the ECN closed-loop mechanism to
generate oscillations when congestion is notified to the NICs. We also
propose several ideas to improve ECN based on some research we have
conducted in the past years. We also invite interested parties to
continue the discussion at a scheduled side meeting, Monday 8:30AM -
9:45AM in the Notre Dame room this week, and a proposed non-wg mailing
list to be set-up after IETF-105.
8. Using Service Function Chaining for In-Network Computation
Adrien Wion (email@example.com)
We present how to augment the routing layer by introducing the notion
of service. Our solution leverages on existing distributed routing
protocols where, in addition, autonomous nodes announce information
about the virtual services they provide. This augmented network view
allows NFV-Routers to steer flows through a set of services to propose
complex functions in the network. Longer version of this talk will be
given @ COINRG Thursday Afternoon.
9. Networking and Theory
Hejianfei (Jeffrey) (firstname.lastname@example.org)
IETF has active participants from both academic and industrial
communities, but the observation is that networking mainly looks an
engineering domain, and a good design of protocol depends more on
experience from best practice rather than on a systematic knowledge
body. Building a good knowledge body(or “theory”) can make it easy for
the new generation/new comers not only to inherit but also to make
their incremental contribution. Meanwhile , nowadays the industry
shows interest in “deterministic” or "bounded delay" services beyond
"best effort". This may be a challenge which may require theoretical
analysis when exploring the optimal network solutions. Folks, who
find this interesting, please email to me to discuss the technical
visions and what we can do in IETF potentially.
10. YANG/RESTCONF for all?
Douglas Hubler (email@example.com)
YANG and RESTCONF is associated with just networking but software
industry as a whole needs a standard for management plane. Existing
management tools require DevOps teams to build integration with
existing software services creating fragile, expensive, limited
management solutions often with many security vulnerabilities. With
"micro services" on the scene, the demands on the management plane
gets exponentially higher.
I'd like to share my experiences using YANG and RESTCONF for last 4
years for IoT sensors, malware detection systems, public school
software, and even a robotic bartender.
What can IETF do to extend the scope of these management standards
For more information, see freeconf.org. To provide feedback, however
small, please reach out to Douglas Hubler (firstname.lastname@example.org). Love
to connect at IETF 105 !
11. Democratic Improvement Proposals for decentralization projects
Shayan Eskandari (email@example.com)
Blockchain and DLT* based systems are waiting in the wings to join the
potpourri of core technology that makes up our future digital
lives. Both core internet infrastructure technology and many DLT
solutions have one thing in common: They are developed with a diverse
open source developer community and carry significant security
risk. To manage software change related risks both Bitcoin and
Ethereum - the second ranked cryptocurrency market - have derived
their own process of managing change proposals. For Ethereum changes
are discussed and agreed upon in the Ethereum Improvement Proposal
(EIP) process. However given the non-hierarchy management model, there
have been many approaches and obstacles to make this process as close
to a democratic procedure as possible. It is working, but far from
perfect and there are many good approaches and lessons learnt. EIP
requires input from experts at IETF to shape up and standardize.
This proposal is to introduce the EIP process to IETF participants and
possibly spring up a BarBof session. For now please feel free to email
us to discuss this further, we will create a mailing list when the
scope is more defined.
Shayan Eskandari: firstname.lastname@example.org
Martin Ortner: email@example.com
Previous discussions regarding Security in EIP process:
* Distributed Ledger Technology
12. What is the Next Step of YANG models in the IETF?
Qin Wu (firstname.lastname@example.org)
Thanks for Routing area YANG model coordination group, IETF YANG
architecture design team, YANG Doctors Team, YANG design team in
various protocol WGs and IETF YANG coordination group across OPS area
and RTG area, considerable huge number of YANG data models are
specified springing up like mushroom at high speed since 2014 and used
to model devices, e.g., configuration data and operation state and
services (for example, the L3VPN Service Model produced by the L3SM
working group) They cover many of the networking protocols and
techniques. However many such design teams (e.g.,IETF YANG
coordination group ,IETF YANG architecture design team) have been
closedown around the middle of 2018. There are many YANG models still
being specified but move to normal IETF process for standardization.
However many operators are not engaged YANG model standardization
enough in the IETF. The operators expected to deploy these
technologies often don't even know that the standards are being
developed. Other operators expected to deploy these technologies may
not know how these models work together to configure a device, manage
a set of devices involved in a service and which models are fitted
into their use case and meet their requirements. This lead to critical
new technologies currently being developed without sufficient direct
We want to discuss the next steps for YANG models in the IETF. For
people who are interested in YANG data model interconnection
framework, please participant in opsawg session on Wednesday 10:00,
for people who are interested in the gap between IETF YANG and
operator's requirements, please join our side meeting at 8:30PM on
Tuesday. We want to understand how operators are looking to use YANG
models to provide an integrated top-to-bottom management system based
on YANG models, and how the existing models should be integrated. We
would especially like to hear from implementers. Feel free to contact
me if you are interested or want to engage the discussion.
13. The Mathematical Mesh
Phillip Hallam-Baker (email@example.com)
Providing usable end-to-end security presents three major problems
that are solved by the Mesh
1) Alice wants to read her email, access her web pages from six
different devices, how does she manage them
2) Alice needs a means of exchanging contacts with Bob, Carol,
etc. How does she do this in person or remotely and how does she
call Bob from her phone when she added him on her laptop
3) Managing private keys. If we want Alice to encrypt her stored data
we must provide an absolute assurance that there is not the
slightest chance of losing it as a result. Otherwise she will keep
her encrypted data in the cloud and the unencrypted copy just in
case the key is lost.
Today we use 1980s cryptography to solve 21st century information
security challenges. The Mesh moves the dial forward to the 1990s
adding metacryptographic techniques.
There are currently 8 drafts and an MIT License reference library.
14. Topic: Packet Loss Signaling for Encrypted Protocols
Lubashev, Igor (firstname.lastname@example.org)
Packet loss is a pervasive problem of day-to-day network operation,
and proactively detecting, measuring, and locating it is crucial to
maintaining high QoS. In a TCP-dominated world, network operators
have been heavily relying on information present in the clear in TCP
headers: seq and ack numbers, and SACK when enabled. With encrypted
protocols, the equivalent transport headers are encrypted and passive
packet loss observation is not possible.
Since encrypted protocols could be routed by the network differently,
and the fraction of Internet traffic delivered using encrypted
protocols is increasing every year, it is imperative to measure packet
loss experienced by encrypted protocol users directly instead of
relying on measuring TCP loss between similar endpoints.
We propose adding two explicit loss bits to the clear portion of the
protocol headers to restore network operators' ability to maintain
high QoS for users of encrypted protocols. These bits can be added to
an unencrypted portion of a header belonging to any protocol layer.
There will be a side meeting in Sainte-Catherine 8:30am-9:30am on
16. RESERVED is NOT MUST be zero.
Rodney W. Grimes (email@example.com)
When trying to deploy new or modifications to existing Internet
standard protocols frequently the issue comes up that implementations
are treating things labeled as reserved by standards as MUST be zero.
I would like to propose that we ad RESERVED to the format RFC
terminology documents and expand upon the fact that this does not mean
that they should be treated as MUST be zero.
This also expands into things further than being treated as must be
zero in that often things labeled as reserved end up in implmentations
as "permanetly forbidden" requiring a revision to the implementation
before the reserved items can be used.
This is self defeating to the purpose of reservation for future use.
Basically reserved has often come to mean immutably forbidden.
I can suggest some language that should soften this burden for the
future develops of Internet Drafts and standards iff we can actually
promote reserved to RESERVED.
17. DNSSD Discovery Proxy
Stuart Cheshire (firstname.lastname@example.org)
DNSSD Discovery Proxy
Multicast DNS [RFC6762] is appropriate for small Ethernet networks,
but for larger networks, and Wi-Fi networks, IP Multicast can be
unreliable, slow, and wasteful of precious wireless spectrum. A DNSSD
Discovery Proxy (https://tools.ietf.org/html/draft-ietf-dnssd-hybrid)
acts as an intermediary to allow clients to use efficient, reliable,
unicast queries to discover existing devices that offer their services
using Multicast DNS. Particularly for client devices on Wi-Fi,
discovering services on wired Ethernet, this allows the discovery to
take place while keeping the IP Multicast traffic isolated to the
wired Ethernet, which can handle this traffic much better than
Wi-Fi. To engage with this work join us at the DNSSD Working Group
meeting on Thursday afternoon, join the DNSSD mailing list, or
participate by contributing code and suggestions at our GitHub
18. Application-aware IPv6 networking (APN6)
Zhenbin Li (email@example.com)
Shuping Peng (firstname.lastname@example.org)
As the Internet is progressing, the decoupling of applications and
network transport causes the service provider network pipelined which
becomes the bottleneck of the network service development. Moreover a
multitude of applications are being carried over the IP network which
have varying needs for network bandwidth, latency, jitter, and packet
loss, etc. However the network is hard to learn the applications'
service requirements which cause it is difficult to provide truly
fine-granular traffic operations for the applications and guarantee
their SLA requirements.
The Application-aware IPv6 Networking (APN6) is to make use of IPv6
extensions header to convey the application related information
including its requirements along with the packet to the network so to
facilitate the service deployment and network resources
adjustment. [I-D.li-6man-app-aware-ipv6-network] proposes the possible
work on the application-aware IPv6 networking.
We would like to invite the interested parties to continue the
discussion at a scheduled side meeting, Thursday 8:30AM - 9:45AM in
the Notre Dame room this week, and a proposed a non-wg mailing list to
be set-up after IETF-105.
19. An 'Internet of Rules'
Joseph Potvin (email@example.com)
An 'Internet of Rules' (IoR) is created when computational algorithms
which implement rules can be readily transmitted from any independent
source repositories within which they are maintained, to any
applications that would use them. A 'rule' is a normative precept by
which repeated behaviour is guided through authority, agreement or
preference. An 'algorithm' is a posited reusable operational method
invoked by a specified data input condition to generate a specified
data output result, and then to terminate. However computationally
active data probably merits some different treatment than
computationally passive data when being transmitted on the Internet.
I will step through a 3-minute graphical overview of our 100%
free/libre/open specifications, components and system design for a
general-purpose request-response IoR service to solve this general
class of problem:
Agent A, interacting with agent B, would obtain algorithms for one or
more externally-managed computational rules from agents C..n, where: *
A and B may or may not know about C..n’s rules, or about any updates
to them, but either or both would prefer to be notified about relevant
rules when interacting. * C…n may or may not know about A and B in
particular, nor about their particular medium of interaction, but can
expect A or B or their medium of interaction to be capable of
exchanging data with a generic medium common to A..n. * A and B would
tolerate the risk of exposing limited data through the generic medium
in order to learn of applicable rules from C..n.
The community is now alpha-testing a working system and invites your
constructive criticism and collaboration. Joseph Potvin, the lead for
IoR system concepts, looks forward to discussions at IETF 105. All
elements are at https://github.com/Xalgorithms (Apache 2.0
license). Slack #ior & Twitter @Xalgorithms In 3-minutes I'll
introduce just a few key points from this deck, and will be happy to
discuss any elements and ideas throughout the week.
20. Use Cases for Provisioning Domains
Ted Lemon (firstname.lastname@example.org)
Provisioning Domains (RFC 7556) defined how clients manage different
sets of interface information for routing, DNS, and more. This
enables multi-path transports, fail-over between different interfaces,
and stronger guarantees for how clients separate traffic with
different security and privacy needs (VPNs versus unprotected local
networks, say). However, RFC 7556 was just the first step.
Ongoing work in INTAREA (draft-ietf-intarea-provisioning-domains) is
defining how a local router can advertise multiple explicit
Provisioning Domains: if your home has multiple uplink providers, this
now enables devices to take advantage of the different provider
networks as if they are indeed different physical interfaces.
Beyond this, we're looking at how we can use Provisioning Domains
(PvDs) to help manage tunnels, captive portals, server protocol
support, DNS privacy configurations, and more.
Please join us in INTAREA and take a look at
draft-ietf-intarea-provisioning-domains if you're interested!
21. Performance Implications of Path Characteristics
Spencer Dawkins at IETF
The PILC ("Performance Implications of Link Characteristics") working
group produced a number of BCPs providing guidance for protocol
designers working with links that were slow, error-prone, and
asymmetric, for subnetwork designers, and for Performance Enhancing
Proxies (PEPs), between 1999 and 2004.
Networks and protocols have changed significantly since 2004.
I believe it's time to revisit this topic, and to focus on PATH
characteristics, rather than first-hop link characteristics.
We had a side meeting about this at IETF 104, and there was
significant interest, so we are ready to move forward.
I'm hosting two opportunities for participate, here at IETF 105.
I'll be hosting a side meeting in the IETF Code Lounge at 8:30-9:30 on
TUESDAY, to talk about next steps.
I have a time slot at PANRG to talk about the RGs views on what is
research and what is engineering in this space - the IETF would
produce any BCPs, but I want to propose the right topics for IETF
work, and the RG's thoughts will be valuable input.
PANRG is scheduled in Laurier room, at 13:30-15:30 on THURSDAY.
22. LOOPS(Local Optimizations on Path Segments) BoF Announcement
- BoF Time: 10:00-12:00 Monday Morning session I
- Room: Laurier
- Co-chairs: Ole Troan and Spencer Dawkins
- Description: Path over long haul network can be partitioned into
multiple path segments that some of them are using network overlay
tunnels. LOOPS aims to provide local in-network loss recovery over
specific segment to achieve better data delivery.
Use case (draft-li-tsvwg-loops-problem-opportunities-03)
Solution sketch (draft-welzl-loops-gen-info-00)
23. DNS Transparency
We are creating a system that will allow domain owners to protect
their domain name resources by making record changes available for the
domain owners and other interested parties to verify. We are calling
this service "DNS Transparency" and we want to work with all companies
and stakeholders to enable a more transparent naming infrastructure
for the future!
If you want to learn more or see how you can help, please fill out
[this form](https://dnstransparency.org/stayinformed) to let us know!
24. Let's Have Some Fun
As some of you may know, I occasionally organize a social event around
satirical short talks. (Sometimes there is beer.) In the past, it’s been
required to fit the PechaKucha format but the PechaKucha format is rather
strict (20 slides, each on screen for 20 seconds, minimal text). So, I’d like
to try an experiment. This time, any talk format will be allowed (including PK)
with a maximum length of 7 minutes. As before, the topics are encouraged to be
a IETF-related and satirical or controversial in some way, although not
mean-spirited. Anyone can participate in this unofficial social event.
The date will be Thursday evening (July 25) starting at 9:30pm in Duluth.
* Presentation slots are open to all, assigned first come, first served.
* To reserve a presentation slot, send a name and title to
email@example.com and receive confirmation.
* Presenters must agree to limit their talks to less than 7 minutes
(strictly enforced using the Lars Eggert Approach).
* Slides are due Thursday 6pm in Powerpoint or PDF.