RE: routing area design team on dataplane encapsulation considerations

"Fedyk, Don" <don.fedyk@hp.com> Wed, 10 December 2014 20:11 UTC

Return-Path: <don.fedyk@hp.com>
X-Original-To: routing-discussion@ietfa.amsl.com
Delivered-To: routing-discussion@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ECF1A8A0C for <routing-discussion@ietfa.amsl.com>; Wed, 10 Dec 2014 12:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 lYKd3xogqSqU for <routing-discussion@ietfa.amsl.com>; Wed, 10 Dec 2014 12:11:46 -0800 (PST)
Received: from g6t1526.atlanta.hp.com (g6t1526.atlanta.hp.com [15.193.200.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD391A8AC5 for <routing-discussion@ietf.org>; Wed, 10 Dec 2014 12:11:45 -0800 (PST)
Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t1526.atlanta.hp.com (Postfix) with ESMTPS id D290F14B; Wed, 10 Dec 2014 20:11:44 +0000 (UTC)
Received: from G5W5500.americas.hpqcorp.net (16.201.144.180) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 10 Dec 2014 20:10:35 +0000
Received: from G6W2492.americas.hpqcorp.net ([169.254.8.160]) by G5W5500.americas.hpqcorp.net ([16.201.144.180]) with mapi id 14.03.0169.001; Wed, 10 Dec 2014 20:10:35 +0000
From: "Fedyk, Don" <don.fedyk@hp.com>
To: Alia Atlas <akatlas@gmail.com>, "Andrew G. Malis" <agmalis@gmail.com>
Subject: RE: routing area design team on dataplane encapsulation considerations
Thread-Topic: routing area design team on dataplane encapsulation considerations
Thread-Index: AQHQFAIBof6l1w2lzkaDttVw5IYW85yI4q2AgAADRYCAAFYvUA==
Date: Wed, 10 Dec 2014 20:10:35 +0000
Message-ID: <A46D9C092EA46F489F135060986AD9FF0F8BD5B6@G6W2492.americas.hpqcorp.net>
References: <CAG4d1rd60hK8=WtYw-nid_Z7Z8+TvdzA52fNx3pFjND+eDWAfA@mail.gmail.com> <CAA=duU3boijLYXFKW4E-RU1fGhxH_xyAk7NJWqXTFL+896woBA@mail.gmail.com> <CAG4d1rfi=51fxsasu9qfz4=CQQuRSazW-6xoc-8gH5918j2Sxw@mail.gmail.com>
In-Reply-To: <CAG4d1rfi=51fxsasu9qfz4=CQQuRSazW-6xoc-8gH5918j2Sxw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [16.201.12.28]
Content-Type: multipart/alternative; boundary="_000_A46D9C092EA46F489F135060986AD9FF0F8BD5B6G6W2492americas_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/ITSZ4Da1rzSr1sal8469hLCS8BQ
Cc: "routing-discussion@ietf.org" <routing-discussion@ietf.org>
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/routing-discussion/>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 20:11:52 -0000

Hi Alia

I think it would be good for the design team to  also include for reference comparisons of the L2 encapsulations from IEEE 802.1 such as Provider backbone Bridging(PBB) aka Mac-in-MAC and IEEE 802.1Qbp – Equal Cost Multipath (ECMP)  (also a Mac-in-MAC encaps) which have some common properties with data plane encapsulations in general.  As with PWE the designers of these encapsulations have grappled with a lot of the same issues.

One  addition to your list these L2 encapsulations  have specific support for multicast that can be utilized in the in the underlay data plane.

Cheers,
Don

From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, December 10, 2014 9:39 AM
To: Andrew G. Malis
Cc: routing-discussion@ietf.org
Subject: Re: routing area design team on dataplane encapsulation considerations


Hi Andy,

Absolutely true.   I apologize for the oversight.   Psuedo-wires are another encapsulation that we can learn from.

I expect the design team to be reaching out to get more insight on these different issues.

Regards
Alia
On Dec 10, 2014 9:27 AM, "Andrew G. Malis" <agmalis@gmail.com<mailto:agmalis@gmail.com>> wrote:
Alia,

To hijack this discussion back to your original post, I'm very surprised to see no mention of PALS anywhere. We in PALS (and PWE3 before that) have plenty of experience with data plane encapsulations, and we already have solutions for a number of the issues in your list, including ECMP (RFC 6391), packet size and fragmentation (4623), OAM (5085 and others), and a draft on congestion considerations just in the process of finishing up. PWs have been extremely successful in the marketplace. So I hope the design team keeps us in mind as well.

Cheers,
Andy

On Tue, Dec 9, 2014 at 5:46 PM, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> wrote:
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

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<mailto:routing-discussion@ietf.org>
https://www.ietf.org/mailman/listinfo/routing-discussion