Return-Path: 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 ; 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 ; 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 ; Tue, 9 Dec 2014 17:03:27 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so1668857pad.29 for ; 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 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 17:03:25 -0800 (PST) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_92879204-B70E-4553-B6D6-A20203C6B082" Date: Tue, 9 Dec 2014 17:03:24 -0800 References: To: LISP mailing list list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 01:03:32 -0000 --Apple-Mail=_92879204-B70E-4553-B6D6-A20203C6B082 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI. Dino > Begin forwarded message: >=20 > Date: December 9, 2014 at 2:46:30 PM PST > From: Alia Atlas > To: "routing-discussion@ietf.org" > Subject: [sfc] routing area design team on dataplane encapsulation = considerations >=20 > I have chartered a Routing Area Design Team to work on data-plane = encapsulation considerations. >=20 > I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant. = Please keep any conversation in one place on routing-discussion. >=20 > Erik Nordmark has kindly agreed to lead this design team. The members = of the design > team are: >=20 > Albert Tian > > Erik Nordmark > > Jesse Gross > > Jon Hudson > > Larry Kreeger (kreeger) > > Pankaj Garg > > Pat Thaler > > Tom Herbert > >=20 > The mailing list, 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/m= aillist.html = >=20 > The Design Team is chartered as follows: >=20 > 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. >=20 > 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. >=20 > Data plane encapsulations face a set of common issues such as: >=20 > * 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 >=20 > 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=E2=80=99t have to = reinvent the wheel for the above common issues. >=20 > 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. >=20 > Regards, > Alia > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_92879204-B70E-4553-B6D6-A20203C6B082 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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>
  Erik Nordmark <nordmark@sonic.net>
  Jesse Gross = <jgross@vmware.com>
  Jon Hudson = <jon.hudson@gmail.com>
  Larry = Kreeger (kreeger) <kreeger@cisco.com>
  Pankaj Garg <Garg.Pankaj@microsoft.com>
  Pat = Thaler <pthaler@broadcom.com>
  Tom Herbert = <therbert@google.com>

The mailing list, 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-consideration= s/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=E2=80=99t 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

= --Apple-Mail=_92879204-B70E-4553-B6D6-A20203C6B082--