Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt

From: <[email-masked]>
Date: Wed, 29 Jan 2014 16:18:32 +0100

Dear all,

An updated version of this draft is available online. A diff to track the changes is provided below.

Comments and contributions are more than welcome.

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 29 janvier 2014 15:31
À : [email-masked]
Objet : I-D Action: draft-boucadair-sfc-requirements-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Requirements for Service Function Chaining
        Authors         : Mohamed Boucadair
                          Christian Jacquenet
                          Yuanlong Jiang
                          Ron Parker
                          Carlos Pignataro
	Filename        : draft-boucadair-sfc-requirements-01.txt
	Pages           : 13
	Date            : 2014-01-29

Abstract:
   This document identifies the requirements for the Service Function
   Chaining (SFC).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-sfc-requirements-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-requirements-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Jan 2014 10:53:19 -0500

My apologies if I am misreading the document.
Many of the requirements are couched in terms of SF-Maps and specific 
kinds of IDs.  Both of those are aspects of solutions, not requirements. 
  I found it very hard to separate the actual requirements from the 
presumption of solution in the draft.

Also, have you checked that the requirements are aligned with the agreed 
architecture?

Yours,
Joel M. Halpern

On 1/29/14, 10:18 AM, [email-masked] wrote:
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 30 Jan 2014 06:33:02 +0000

Hi Med,

I reviewed your draft and before more detailed comments I have a general
question.

When you say "The solution MUST², what do mean by ³solution²?

Do you mean the IETF must standardize a method for meeting that
requirement?  Or is this targeted to the service provider, the vendor,
etc? 

Some of the ³the solution MUST² seems to me more RFP material and outside
the scope of IETF and therefore the document...or not. And therefore would
like clarification.

Thanks,

Reinaldo

---

From: <[email-masked]>
Date: Thu, 30 Jan 2014 07:50:47 +0100

Hi Joel,

The requirements are drawn from a functional perspective with a constraint to avoid binding them specific to a solution. If there are some that you think are solution-specific, then it would be helpful to point those and discuss them. 

The document uses the reference architecture defined in the "architecture and framework" document cited in the draft. That architecture defines a set of functional elements. 

Does the "agreed architecture" you are referring define an architecture distinct than the one cited in the requirements draft?

Cheers,
Med

>De : Joel M. Halpern [mailto:[email-masked]]
>Envoyé : mercredi 29 janvier 2014 16:53
>À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
>Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-01.txt
>

---

From: <[email-masked]>
Date: Thu, 30 Jan 2014 08:21:14 +0100

Hi Reinaldo,

Please see inline.

Cheers,
Med

>De : Reinaldo Penno (repenno) [mailto:[email-masked]]
>Envoyé : jeudi 30 janvier 2014 07:33
[Med] What is actually meant by "The solution" is called out in each section:

* Section 3: indicates "   The following set of functional requirements should be considered for
   the design of the Service Function Chaining solution:"
* Section 4: says "   This section lists the set of requirements for the Service Function
   Discovery procedure (denoted hereafter as "the solution")."
* Section 5: says "   This section lists the set of requirements for the SFC Diagnosis &
   Troubleshooting procedure (denoted hereafter as "the solution")."

Ideally, the requirements in Section 3 should be grouped, for instance per Functional Element. But, we didn't done that yet. 

>requirement? 
[Med] Those are functional requirements for the IETF work. Detailed requirements can be added but it will be hard to be keep a document solution-independent.  

 Or is this targeted to the service provider, the vendor,
>the scope of IETF and therefore the document...or not. And therefore would
[Med] Let's discuss those requirements that you think should be out of scope. The list is not frozen, it is here to be alive. 

>Thanks,
[Med] Thank for this input.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Jan 2014 10:00:48 -0500

My apologies about the architecture reference.  There is no WG agreed 
architecture.  My talking abou tthat is both wrong and confusing.

The larger point however remains.  The requirements as written treat 
elements like the SF-Map and the SF-ID as if they are information that 
will appear in the data packet.  That would be part of a solution.  I 
found that to be quite confusing, and it made it hard to determine what 
the solution-independent requirements are.  We really need such 
requirements, particularly from folks like you on the operator side.

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 30 Jan 2014 16:35:32 +0100

Hi Joel,

Please see inline.

Cheers,
Med

>Envoyé : jeudi 30 janvier 2014 16:01
[Med] No problem ;-)

>will appear in the data packet. 
[Med] No. There is no assumption in the requirements I-D that the "Service Function Identifier" and the "SF Map" will appear in the packet. These terms are defined as part of the "architecture & framework" draft cited on the draft. I'm reproducing what is meant by these terms here: 

   o  SF Identifier: is a unique identifier that unambiguously
      identifies a SF within a SFC-enabled domain.  SF Identifiers are
      assigned, configured and managed by the administrative entity that
      operates the SFC-enabled domain.  SF identifiers can be structured
      as strings; other formats can be used.  SF Identifiers are not
      required to be globally unique nor be exposed to or used by
      another SF-enabled domain.

   o  SF Map: refers to an ordered list of SF identifiers.  Each SF Map
      is identified with a unique identifier called SF Map Index.

As you can see in the requirements I-D, there is no mention of the "SF Map Index".

 That would be part of a solution.
[Med] It depends where you position the solution vs architecture frontier. IMHO, it makes sense to use those terms as they can be seen as part of the reference functional architecture.

  I
>requirements, particularly from folks like you on the operator side.
[Med] That was our motivation when editing this draft. We are very open to update the document (including removing text that the wg thinks it is not solution-independent). BTW, I would really like to see more operators joining us in this effort. 

>> The requirements are drawn from a functional perspective with a
>constraint to avoid binding them specific to a solution. If there are some
>that you think are solution-specific, then it would be helpful to point
>those and discuss them.
>>
>> The document uses the reference architecture defined in the "architecture
>and framework" document cited in the draft. That architecture defines a set
>of functional elements.
>>
>> Does the "agreed architecture" you are referring define an architecture
>distinct than the one cited in the requirements draft?
>>
>> Cheers,
>> Med
>>
>>>> An updated version of this draft is available online. A diff to track
>the
>>> changes is provided below.
>>>>