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

["Roberta Maglione (robmgl)" <[e-mail]>]

Hi Med,
We posted a new version of this draft to address your comments. 
Best Regards
Roberta

 


Roberta Maglione
TECHNICAL SOLUTIONS ARCHITECT
GSP Architecture
[e-mail]
Tel: [phone]
Cisco Systems, Inc.
Via Torri Bianche 8
VIMERCATE
20871
Italy
cisco.com


Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here for Company Registration Information.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, October 24, 2016 9:38 AM
To: Roberta Maglione (robmgl) <[e-mail]>; [e-mail]
Subject: RE: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-radius-00.txt

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:[e-mail]] De la part de Roberta Maglione
> (robmgl)
> Envoyé : samedi 22 octobre 2016 11:52
> À : [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, October 15, 2016 9:08 AM
> To: Guillermo Trueba (gtrueba) <[e-mail]>; Roberta Maglione
> (robmgl) <[e-mail]>; Carlos Pignataro (cpignata) 
> <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc