Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

Brian Haberman <brian@innovationslab.net> Wed, 10 December 2014 17:26 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: ieee-ietf-coord@ietfa.amsl.com
Delivered-To: ieee-ietf-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7271A1B2A for <ieee-ietf-coord@ietfa.amsl.com>; Wed, 10 Dec 2014 09:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws5hfTIDStV4 for <ieee-ietf-coord@ietfa.amsl.com>; Wed, 10 Dec 2014 09:26:25 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840CD1A8760 for <ieee-ietf-coord@ietf.org>; Wed, 10 Dec 2014 09:26:25 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AF465880E2 for <ieee-ietf-coord@ietf.org>; Wed, 10 Dec 2014 09:26:23 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6AF4371C0002 for <ieee-ietf-coord@ietf.org>; Wed, 10 Dec 2014 09:26:23 -0800 (PST)
Message-ID: <54888238.1030401@innovationslab.net>
Date: Wed, 10 Dec 2014 12:26:16 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ieee-ietf-coord@ietf.org
References: <48E1A67CB9CA044EADFEAB87D814BFF632C0E823@eusaamb107.ericsson.se>
In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632C0E823@eusaamb107.ericsson.se>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="b04Tbv9rN12eu9I6fAHP7Bu1F1VXEsLPm"
Archived-At: http://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/UdVpU2Db0YRDKpFeyUqS8Hpuass
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations
X-BeenThere: ieee-ietf-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Management-level discussions between IEEE and IETF on topics of interest to both SDOs <ieee-ietf-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ieee-ietf-coord/>
List-Post: <mailto:ieee-ietf-coord@ietf.org>
List-Help: <mailto:ieee-ietf-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 17:26:28 -0000

Hi Eric,

On 12/10/14 11:53 AM, Eric Gray wrote:
> Folks,
> 
> Raising this issue in case it has not been raised already on this list.
> 
> The issue is with an announcement made by one of the Routing ADs
> of the appointment of a design team with intention to provide DLL
> encapsulation and protocol designers with advice on common ways
> to interact with IP encapsulation on a number of issues.

I think the above is a mis-characterization of what Alia announced.  The
design team is looking at data-plane, not data link layer, encapsulation
within IETF protocols.  Think of protocols like MPLS and LISP or for
that matter IP over UDP-based tunnels.

Regards,
Brian

> 
> As I understand this, this is an effort that may have started with a draft
> written in March of this year.  Pat Thaler is one of the 3 co-authors (with
> Bob Briscoe from BT and John Kaippallimalil from Huawei) on that draft.
> 
> The current (-04) version of the above draft expired in September,
> most likely because people wanted to figure out what to do about it
> (and related work).
> 
> That draft is:
>     “Guidelines for Adding Congestion Notification to Protocols that
>       Encasulate IP”
>     http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines
> 
> There is also the Deterministic Networking (DetNet) WG, which sits
> somewhat squarely in the middle of the “QoS” aspect of IP transport
> protocols).
> 
> And there is the recent BIER work that may possibly have an impact on
> IP transport over a few data link technologies.
> 
> I assume there is also related work on ECMP entropy, packet size and
> fragmentation, OAM, security/privacy, extensibility and IPv6 header
> protection as indicated in Alia’s mail (see below).
> 
> Alia sets what is in my opinion the right tone (consistent with the draft
> mentioned above) in saying that the intention is to provide advice on
> possible common ways to deal with these issues at the data-link layer
> and how they may interact with IP.
> 
> As long as the design team stays with the spirit of that tone, it is likely
> there will be issues for IEEE 802.
> 
> I believe this needs to be on our issues list for IEEE/IETF cooperation,
> and folks should keep an eye on it.
> 
> In particular, some folks have expressed concerns that this might be
> view as implying that the IETF is expanding its charter to include DLL
> design.  I do not see that, but that best way to deal with this as a
> perception issue is to track the activity.
> 
> --
> Eric
> 
> 
> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Alia Atlas
> Sent: Tuesday, December 09, 2014 5:47 PM
> To: routing-discussion@ietf.org<mailto:routing-discussion@ietf.org>
> Subject: routing area design team on dataplane encapsulation considerations
> 
> 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 <albert.tian@ericsson.com<mailto:albert.tian@ericsson.com>>
>   Erik Nordmark <nordmark@sonic.net<mailto:nordmark@sonic.net>>
>   Jesse Gross <jgross@vmware.com<mailto:jgross@vmware.com>>
>   Jon Hudson <jon.hudson@gmail.com<mailto:jon.hudson@gmail.com>>
>   Larry Kreeger (kreeger) <kreeger@cisco.com<mailto:kreeger@cisco.com>>
>   Pankaj Garg <Garg.Pankaj@microsoft.com<mailto:Garg.Pankaj@microsoft.com>>
>   Pat Thaler <pthaler@broadcom.com<mailto:pthaler@broadcom.com>>
>   Tom Herbert <therbert@google.com<mailto:therbert@google.com>>
> 
> The mailing list, rgt-dt-encap-considerations@ietf.org<mailto:rgt-dt-encap-considerations@ietf.org>, is closed but the archives are
> publicly available at:
>    http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/current/maillist.html
> 
> 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 control
>   * 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.
> 
> Regards,
> Alia
> 
> 
> 
> _______________________________________________
> ieee-ietf-coord mailing list
> ieee-ietf-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>