[Stackevo-discuss] When provider networks don't t trust the stack set by the end points ....
Linda Dunbar <firstname.lastname@example.org> Mon, 07 December 2015 22:30 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732521B29FF for <email@example.com>; Mon, 7 Dec 2015 14:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([22.214.171.124]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnOHUECVNwSD for <firstname.lastname@example.org>; Mon, 7 Dec 2015 14:30:46 -0800 (PST)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [126.96.36.199]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FC71B29F5 for <email@example.com>; Mon, 7 Dec 2015 14:30:46 -0800 (PST)
Received: from 172.18.9.243 (EHLO dfweml706-chm.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTQ77120; Mon, 07 Dec 2015 16:30:44 -0600 (CST)
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 7 Dec 2015 14:30:40 -0800
From: Linda Dunbar <firstname.lastname@example.org>
To: "email@example.com" <firstname.lastname@example.org>
Thread-Topic: When provider networks don't t trust the stack set by the end points ....
Date: Mon, 7 Dec 2015 22:30:40 +0000
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DADD4Adfweml701chm_"
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.56660895.006E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
Subject: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points ....
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 22:30:49 -0000
I find the use cases for SPUD are very real and definitely need a good approach to make it happen. However, a lot of discussions have been centered around the SPUD layer being encoded by End Points, and expect the network to apply certain rules for those traffic. Having an In-band standard signaling among end points and network has its advantages: allowing network to treat packets without getting into the encrypted payload, and not requiring any extra components across the networks between the end points. However, Virtually all traffic today go through provider networks (most likely multiple). Provider network usually don't (can't) trust the signaling or requests from end points because any end points can set their own traffic as "requiring the least latency" or "passing through the network". Provider network set traffic based on the SLA clients pay. For example all the DiffServ set by the endpoints are ignored by the provider network, instead Provider Network set its own DiffServ based on the SLA from the customers. The Network Service Header (NSH) introduced by SFC (http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ ) is effectively another layer of stack added to the packets (added by the ingress node). My question is: Should SPUD allow multiple types of layer added to data packets? Or only focusing on the layer end points can add? My two cents. Linda Dunbar
- [Stackevo-discuss] When provider networks don't t… Linda Dunbar
- Re: [Stackevo-discuss] When provider networks don… Szilveszter Nadas
- Re: [Stackevo-discuss] When provider networks don… Brian Trammell