[lisp] Fwd: [sfc] routing area design team on dataplane encapsulation considerations

Dino Farinacci <farinacci@gmail.com> Wed, 10 December 2014 01:03 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F364C1A0399 for <lisp@ietfa.amsl.com>; Tue, 9 Dec 2014 17:03:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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=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 haz5b0Dh2vMl for <lisp@ietfa.amsl.com>; Tue, 9 Dec 2014 17:03:27 -0800 (PST)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578411A0162 for <lisp@ietf.org>; Tue, 9 Dec 2014 17:03:27 -0800 (PST)
Received: by mail-pa0-f42.google.com with SMTP id et14so1668857pad.29 for <lisp@ietf.org>; Tue, 09 Dec 2014 17:03:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=oMiUjvYPxhDh6KsEMK3VpSjEWwPWxMgSW6alIk6AylA=; b=bS0RLlJopEPEL50bTJdny1ly3NfjB9O8ajbbVHfkpYLv8K7NWe36JuLIdZU7IXbQsV XJEOmx3syZUSmUxcTupIqykAwHX2cmK3V3/MgFa2vPx4IVG+PXA6u77xK13hbs7XclSN 34VK7m9+y/EaTcp6x6VKh5Wz/YUfh6ST3Szz5cYZN8eo4iv9Euyf+vEWi2P5C/7OsPtd kHe/Yk789h7UHSXs16S7uzNS/eynflhYQ/tMsGn4CUS7mizpTjaBmWGsFkUbVVH96qim w1CiZ5OKzYiu2OE9g3JVHfkdkSGjVGW929aqzrSQl5eDdg3BOx32gTMTbFrwST+KaOM2 BeMA==
X-Received: by 10.70.101.161 with SMTP id fh1mr2386275pdb.62.1418173405999; Tue, 09 Dec 2014 17:03:25 -0800 (PST)
Received: from berlin-vl2010.sjc.aristanetworks.com (mobile-166-171-250-186.mycingular.net. [166.171.250.186]) by mx.google.com with ESMTPSA id ta9sm1391554pbc.50.2014.12.09.17.03.24 for <lisp@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 17:03:25 -0800 (PST)
From: Dino Farinacci <farinacci@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_92879204-B70E-4553-B6D6-A20203C6B082"
Date: Tue, 09 Dec 2014 17:03:24 -0800
References: <CAG4d1rd60hK8=WtYw-nid_Z7Z8+TvdzA52fNx3pFjND+eDWAfA@mail.gmail.com>
To: LISP mailing list list <lisp@ietf.org>
Message-Id: <55568C81-14FF-4804-B649-49093BA8D908@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/-KF0WA9gKS7S4xkHpyuSxyzaX0U
Subject: [lisp] Fwd: [sfc] routing area design team on dataplane encapsulation considerations
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 01:03:32 -0000

FYI.

Dino

> Begin forwarded message:
> 
> Date: December 9, 2014 at 2:46:30 PM PST
> From: Alia Atlas <akatlas@gmail.com>
> To: "routing-discussion@ietf.org" <routing-discussion@ietf.org>
> Subject: [sfc] 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 <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
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc