Re: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.txt

<mohamed.boucadair@orange.com> Mon, 24 October 2016 07:38 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB3C129471 for <sfc@ietfa.amsl.com>; Mon, 24 Oct 2016 00:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level:
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_DUL=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 dAR18I11v8FJ for <sfc@ietfa.amsl.com>; Mon, 24 Oct 2016 00:38:20 -0700 (PDT)
Received: from relais-inet.orange.com (relais-aub41.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3863E129434 for <sfc@ietf.org>; Mon, 24 Oct 2016 00:38:20 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 572D51000C7; Mon, 24 Oct 2016 09:38:18 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 577F84004C; Mon, 24 Oct 2016 09:38:18 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 24 Oct 2016 09:38:18 +0200
From: mohamed.boucadair@orange.com
To: "Roberta Maglione (robmgl)" <robmgl@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.txt
Thread-Index: AQHSJrLV16ldISbcrUyPtZGudOBmTqC0NMHQgALy6QA=
Date: Mon, 24 Oct 2016 07:38:17 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009D96F6E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <147651526420.14954.691320262825038260.idtracker@ietfa.amsl.com> <7b056fd8879c42a0ad63417586dff2a4@XCH-RCD-009.cisco.com>
In-Reply-To: <7b056fd8879c42a0ad63417586dff2a4@XCH-RCD-009.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/h8LXgwX4S_T5v_uGy5L3MiI4gHc>
Subject: Re: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2016 07:38:22 -0000

Hi Roberta, 

Thank you for sharing this draft. Some comments below:

* You may consider the template in https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section-2.1.3 for defining the RADIUS attributes. 

* This draft is an implementation of the "C1: Interface between SFC Control Plane & SFC Classifier" interface: https://tools.ietf.org/html/draft-ietf-sfc-control-plane-08#section-3.3.1. Having a reference to the CP architecture would be helpful. If you can indicate which requirements from the CP document you are targeting, this would be even appreciated. 

* The draft focuses on two pieces of information that can be instructed via the CP. I do agree those two are important ones, but I wonder whether those are sufficient to cover SFC needs in the broadband case. For example, how to demux among multiple services to be delivered to the same subscriber? Do you assume that other control protocols are used to instruct the classification rules or this is done by RADIUS?

* Because NSH-SI may be bound to a given path, the presence of NSH-SPI attribute may be required. BTW, I wonder whether you can define a "SFC Rule" RADIUS attribute that can convey one or many SFC-related TLVs (e.g., NSH-SPI, NSH-SI, etc.).

Thank you.

Cheers,
Med 

> -----Message d'origine-----
> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Roberta Maglione
> (robmgl)
> Envoyé : samedi 22 octobre 2016 11:52
> À : sfc@ietf.org
> Objet : [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-
> radius-00.txt
> 
> Hello,
> We submitted this document about Radius attributes for NSH.
> The draft is targeted at addressing Broadband access use cases.
> Your comments are welcome.
> Best Regards
> Roberta
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Saturday, October 15, 2016 9:08 AM
> To: Guillermo Trueba (gtrueba) <gtrueba@cisco.com>; Roberta Maglione
> (robmgl) <robmgl@cisco.com>; Carlos Pignataro (cpignata)
> <cpignata@cisco.com>
> Subject: New Version Notification for draft-maglione-sfc-nsh-radius-00.txt
> 
> 
> A new version of I-D, draft-maglione-sfc-nsh-radius-00.txt
> has been successfully submitted by Roberta Maglione and posted to the IETF
> repository.
> 
> Name:		draft-maglione-sfc-nsh-radius
> Revision:	00
> Title:		RADIUS Attributes for NSH
> Document date:	2016-10-14
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-maglione-sfc-
> nsh-radius-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-maglione-sfc-nsh-
> radius/
> Htmlized:       https://tools.ietf.org/html/draft-maglione-sfc-nsh-radius-
> 00
> 
> 
> Abstract:
>    Network Service Header (NSH) protocol defines the Service Function
>    Chaining (SFC) encapsulation required to support the Service Function
>    Chaining (SFC) Architecture.  One of the components of the Network
>    Service Header (NSH) protocol is the Service Path Identifier (SPI),
>    which identifies a service path, another important element of the NSH
>    protocol is the Service Index (SI), which provides location within
>    the Service Path.
> 
>    When Service Providers would like to deliver customized services
>    offers requiring Service Functions Chains, a different service chain
>    may be required for each subscriber or group of subscribers.  In
>    order to simplify the service provisioning in this scenario, it would
>    be useful to be able to associate the Service Path Identifier (SPI),
>    identifying the service chain, and the appropriate Service Index
>    (SI), identifying the location in the service path, with the customer
>    profile.
> 
>    In some Broadband networks, the customer profile information may be
>    stored in Authentication, Authorization, and Accounting (AAA)
>    servers.  This document specifies two new Remote Authentication Dial-
>    In User Service (RADIUS) attributes to carry the Service Path
>    Identifier (SPI) and the Service Index (SI).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc