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

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

Hello Med,
Thanks for your comments.
Please see answers inline [RM]
Regards
Roberta


-----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. 

[RM] Thanks for the pointer, I can modify the format of the attributes adding "description" and "Type" fields in order to follow the guidelines defined there. 

* 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. 

[RM] let me take another  closer look at the control plane draft and I come back to you on this point.

* 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?

[RM] SPI and SI are the minimal set of parameters required to identify a service chain. Regarding your question about demuxing multiple services, the idea here is that each subscriber will subscribe/pay for a different offer/service. A service may require to go across different SF's thus a service chain is required. A classification rule can be used to specific which type of traffic should go through the service chain
The classification rule can be sent by RADIUS, as written at the end of 
Section 3, " A classification rule, to be associated with the SPI, can also be sent by the AAA Server as part of the list of attribute-value pairs."
Or it can be specified by other means, for example pre-configured on the NAS. In most of the case that could be all the traffic coming from that subscriber line.

* Because NSH-SI may be bound to a given path, the presence of NSH-SPI attribute may be required.
[RM] You are correct and this is taken in care by the text in section 4.1

"  If the NAS does not receive the NSH-SPI attribute in the Access-
   Accept message, it MAY fall back to a pre-configured default NSH SPI,
   if any.  If the NAS does not have any pre-configured NSH SPI, the
   traffic generated by that specific subscriber does not have to be
   sent across any service chain."

 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.).

[RM] I don't think such complexity would be required to address most of the common broadband use cases.



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