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

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Sat, 22 Oct 2016 09:51:59 +0000

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: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, October 15, 2016 9:08 AM
To: Guillermo Trueba (gtrueba) <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; Carlos Pignataro (cpignata) <[email-masked]>
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

---

From: <[email-masked]>
Date: Mon, 24 Oct 2016 07:38:17 +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:[email-masked]] De la part de Roberta Maglione
> (robmgl)
> Envoyé : samedi 22 octobre 2016 11:52
> À : [email-masked]
> Objet : [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-
> radius-00.txt
> 
> Hello,
> To: Guillermo Trueba (gtrueba) <[email-masked]>; Roberta Maglione
> (robmgl) <[email-masked]>; Carlos Pignataro (cpignata)
> <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Mon, 24 Oct 2016 11:12:47 +0000

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

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

Hi Roberta, 

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

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

[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