routing area design team on dataplane encapsulation considerations

Alia Atlas <> Tue, 09 December 2014 22:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C11D31A6EED for <>; Tue, 9 Dec 2014 14:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JA5WHEzCjkEv for <>; Tue, 9 Dec 2014 14:46:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E86591A6F3D for <>; Tue, 9 Dec 2014 14:46:30 -0800 (PST)
Received: by with SMTP id f10so738444yha.8 for <>; Tue, 09 Dec 2014 14:46:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EkX7xIn5A5fSVVo2TU5F/ZsOCqZuRIMXxh0NLFxK24k=; b=kmvrw4pvlhPyfktJbJeX/Tm+Euj2zzvVkNmmLfnTWF8QBUNC0Dh1VnWruyD9TE7uKU X1X91/zIApyVNeGgxxHlUJL0paGC8apVthCcnW3bsZcWelMwQdHqU0uP55pEi7zH5LeU OTxWXYuaPQSg+35wXnjj7ynBtJZ6z+JB1PFjOPZb+VLbwLH35Kac0n8GuBSLyR/smPGd EGdyeWxeZOkwdnz6TqM6EP8ipgrtzvZmnEcNB7m7eOfUAZZ+8mpnIU9x2bwA+1U82D3T /l7Xs1gd7Z2STOmFbtOwSckiuJdE5lgRvB1gzID4n32sUs4u6iPNaAzRZc9yGnm+aFBy NFkg==
MIME-Version: 1.0
X-Received: by with SMTP id g184mr643304ykd.72.1418165190135; Tue, 09 Dec 2014 14:46:30 -0800 (PST)
Received: by with HTTP; Tue, 9 Dec 2014 14:46:30 -0800 (PST)
Date: Tue, 9 Dec 2014 17:46:30 -0500
Message-ID: <>
Subject: routing area design team on dataplane encapsulation considerations
From: Alia Atlas <>
To: "" <>
Content-Type: multipart/alternative; boundary=001a113936b46414e80509d05081
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area General mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Dec 2014 22:46:34 -0000

I have chartered a Routing Area Design Team to work on data-plane
encapsulation considerations.

I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant.
Please keep any conversation in one place on routing-discussion.

Erik Nordmark has kindly agreed to lead this design team.  The members of
the design
team are:

  Albert Tian <>
  Erik Nordmark <>
  Jesse Gross <>
  Jon Hudson <>
  Larry Kreeger (kreeger) <>
  Pankaj Garg <>
  Pat Thaler <>
  Tom Herbert <>

The mailing list,, is closed but the
archives are
publicly available at:

The Design Team is chartered as follows:

There have been multiple efforts over the years that have resulted in new
or modified data plane behaviors involving encapsulations. That includes
IETF efforts like MPLS, LISP, and TRILL but also industry efforts like
Vxlan and NVGRE.  These collectively can be seen as a source of insight
into the properties that data planes need to meet.  The IETF is currently
working on potentially new encapsulations in NVO3 and SFC and considering
working on BIER. In addition there is work on tunneling in the INT area.

This is a short term design team chartered to collect and construct useful
advice to parties working on new or modified data plane behaviors that
include additional encapsulations.  The goal is for the group to document
useful advice gathered from interacting with ongoing efforts.  An Internet
Draft will be produced for IETF92 to capture that advice, which will be
discussed in RTGWG.

Data plane encapsulations face a set of common issues such as:

  * How to provide entropy for ECMP
  * Issues around packet size and fragmentation/reassembly
  * OAM - what support is needed in an encapsulation format?
  * Security and privacy.
  * QoS
  * Congestion Considerations
  * IPv6 header protection (non-zero UDP checksum over IPv6 issue)
  * Extensibility - e.g., for evolving OAM, security, and/or congestion
  * Layering of multiple encapsulations e.g., SFC over NVO3 over BIER

The design team will provide advice on those issues. The intention is that
even where we have different encapsulations for different purposes carrying
different data, each such encapsulation doesn’t have to reinvent the wheel
for the above common issues.

The design team will look across the routing area in particular at SFC,
NVO3 and BIER. It will not be involved in comparing or analyzing any
particular encapsulation formats proposed in those WGs and BoFs but instead
focus on common advice.