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

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Wed, 2 Nov 2016 10:02:01 +0000

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

Roberta Maglione
TECHNICAL SOLUTIONS ARCHITECT
GSP Architecture
[email-masked]
Tel: +39 039 629 5758
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: [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, 

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,
> 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
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Thu, 3 Nov 2016 13:05:36 +0000

Hi Roberta, 

Thank you for taking care of my comments. Much Appreciated!

I still have the following points that I want to discuss: 

* Identify the control interface targeted by this solution in reference to the SFC CP architecture defined in draft-ietf-sfc-control-plane
* Call out explicitly (in a dedicated section, preferably) the control requirements that are not covered by this specification
* Consider defining one "SFC Classification Control" RADIUS attribute. This attribute may carry one or multiple SFC TLVs (SPI, SI, Metadata IDs, ...). BTW, some of these TLVs may be used if someone wanted to define dedicated RADIUS attributes used to control SFFs or SFC-aware SFs.

Cheers,
Med

> De : Roberta Maglione (robmgl) [mailto:[email-masked]]
> Envoyé : mercredi 2 novembre 2016 11:02
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Objet : RE: [sfc] FW: New Version Notification for draft-maglione-sfc-nsh-
> radius-00.txt
> 
> Hi Med,
> 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.
> * 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
>