IETF Logo Mail Archive

Re: [Sdn] Poll for RG Adoption - draft-contreras-sdnrg-layered-sdn

Gert Grammel <ggrammel@juniper.net> Sun, 21 February 2016 17:43 UTC

Return-Path: <ggrammel@juniper.net>
X-Original-To: sdn@ietfa.amsl.com
Delivered-To: sdn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88BA1A8F45 for <sdn@ietfa.amsl.com>; Sun, 21 Feb 2016 09:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 2RNjIJHkKFod for <sdn@ietfa.amsl.com>; Sun, 21 Feb 2016 09:43:30 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043621A8F43 for <sdn@irtf.org>; Sun, 21 Feb 2016 09:43:28 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sun, 21 Feb 2016 17:43:05 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0409.023; Sun, 21 Feb 2016 17:43:05 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: "King, Daniel" <d.king@lancaster.ac.uk>, "'sdn@irtf.org'" <sdn@irtf.org>
Thread-Topic: [Sdn] Poll for RG Adoption - draft-contreras-sdnrg-layered-sdn
Thread-Index: AQHRbM9RNhYZhgSrpUK7OsJKEbmk4Q==
Date: Sun, 21 Feb 2016 17:43:05 +0000
Message-ID: <D2EF747E.12546%ggrammel@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.0.151221
authentication-results: lancaster.ac.uk; dkim=none (message not signed) header.d=none;lancaster.ac.uk; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.13]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 5:D+cPMDGPjGNrDQWWw5DWyBuj0qcgSqWlJpbYgCGcnFirXXUIFVW7YHNTVgpAyWRkXWrlAG14OmKgcvn/sLVPTuK9P0L4B4htiJ8BI1UASueBRc3oQuXBk6g3ROULbUcrx9SKg8twZCWTCopG9H3R8A==; 24:8uQkVdXksCDyvbypweHshKf+wUxEsXyygee4az3YGFZs9hx8hiyvRC9WYoJfhP1IQXoByhhrELFscQP+I+fhByuk+cTheg8/Ud87Mfu37bw=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1612;
x-ms-office365-filtering-correlation-id: b31d6642-d353-43c2-64e1-08d33ae67446
x-microsoft-antispam-prvs: <CY1PR0501MB16125F1B61ED54B1F6B886D4CEA20@CY1PR0501MB1612.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612;
x-forefront-prvs: 085956473E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(71364002)(38284003)(24454002)(4326007)(5890100001)(2906002)(36756003)(2900100001)(87936001)(40100003)(10400500002)(122556002)(99286002)(5002640100001)(92566002)(5001960100002)(5001770100001)(4001350100001)(1220700001)(11100500001)(1096002)(54356999)(50986999)(66066001)(83506001)(19580405001)(189998001)(77096005)(15975445007)(586003)(3846002)(6116002)(102836003)(5008740100001)(86362001)(230783001)(19580395003)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <799ADEF4D4AFBC4081DA1EE030F557EF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2016 17:43:05.3437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612
Archived-At: <http://mailarchive.ietf.org/arch/msg/sdn/4en6G2xbn1k8lLioS_21QP3l6gM>
Cc: "shiomoto.kohei@lab.ntt.co.jp" <shiomoto.kohei@lab.ntt.co.jp>
Subject: Re: [Sdn] Poll for RG Adoption - draft-contreras-sdnrg-layered-sdn
X-BeenThere: sdn@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List to Discuss SDN Research Group in the IRTF <sdn.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/sdn>, <mailto:sdn-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sdn/>
List-Post: <mailto:sdn@irtf.org>
List-Help: <mailto:sdn-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/sdn>, <mailto:sdn-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Feb 2016 17:43:32 -0000

Dan,

Support

It contributes to abstraction in the context of SDN. In IETF
https://datatracker.ietf.org/doc/draft-ietf-ccamp-interconnected-te-info-ex
change/ discusses such abstraction for the purpose of Traffic Engineering
but doesn¹t deal with the service. Also aspects like QoS have not been
tackled there.

Going forward, the aspect of transport attached services would need to be
worked out more explicitly to harden the abstraction.
1) A DSL service is attached to a particular copper cable that cannot be
virtualised. Moving a home Gateway to another DSL Line wouldn¹t provide a
service. So the transport is an essential part of the service.
2) For a Mobile service, one can move a SIM card between devices (even if
not owned by the same person) and get a service. Whether this service is
the same between devices however depends on the Mobile phone capabilities.
Here the SIM-HW is part of the service, but the transport (Mobile) is not.
3) A VoIP service can be made available on practically any device
connected by any transport to the internet, but access to that service may
be limited by firewall policies and alike. Here no HW is part of the
service but transport influences the quality.

So linking transport related information with service related information
in an efficient and abstracted manner is indeed an issue and worth to look
at. A collaborative architecture seems to be a good sarting point.


Gert




On 2016-15-02 14:26, "sdn on behalf of King, Daniel" <sdn-bounces@irtf.org
on behalf of d.king@lancaster.ac.uk> wrote:

>Greetings SDN Researchers,
>
>At IETF 94 we had a request from the authors of "Cooperating Layered
>Architecture for SDN" to poll the Research Group for adoption of their
>document:
>
>o If you missed their presentation at IETF 94 -
>https://www.ietf.org/proceedings/94/slides/slides-94-sdnrg-2.pdf
>o The current version of the document -
>https://tools.ietf.org/html/draft-contreras-sdnrg-layered-sdn-04
>
>We would like to open a two-week adoption call the document, but
>specifically ask that a "support" or "no support" response be
>substantiated with accompanying comments discussing why the document
>should be adopted, or indeed not.
>
>Kind Regards,
>Dan & Kohei

v2.8.7 | Report a Bug | By Email