Subject: [nsc] Charter text updated

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Nov 2013 19:16:44 -0000

Hi,

I've been reading through the mailing list and have polished the charter text a
little further.

I picked up Kevin's suggestions as follows:

Added the word "format" describing the layer independence of the encapsulation
in point 3.

In point 3, I did not delete... 
  "That is, the same 
   encapsulation may be used on a service function path realized at the 
   network layer or at any other layer, and the same encapsulation will
   apply for the construction of service function paths regardless of
   the actual service."
...but I did insert "format" in that text as well.

Still in the same point 3, I took Jim's s/path realized/function applied/

I did not make any change after Hongyu's discussion of "network node". I don't
think that is a synonym for "Network Element (NE)", but does represent an
addressable node on the graph. It *is* an interesting debate about whether a
specific service function instance can move around, but if it changes identity
and address when it does so then perhaps it is hard to know what to call it. But
I did take Thomas's proposal for that paragraph and rework it to lead to..

   An SFC is instantiated through selection
   of specific service function instances on specific network nodes to form
   a service graph: this is called a Service Function Path (SFP). 

This is the version that will go to the IESG on Thursday 5th. You can (of
course) continue to discuss the text, but it feels like we are now tweaking the
tweaks.

Cheers,
Adrian

PS. If you could all try to remember to change the subject line when your
conversation wanders on to new topics it would be nice.

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Sat, 30 Nov 2013 08:03:24 +0000

Hi all,

I am still struggling with the word "node" in updated charter.

" 3. Generic SFC Encapsulation: This document will describe a single 
   service-level data plane encapsulation format for conveying the
   service function chain and the service function path, and for 
   communicating context information between nodes that implement 
   service functions and service function chains."

I am not sure where are "nodes that implement" in above test fitting into following case:

There are several virtual Service Functions running in a same server, and each Service Function is running in a standalone Virtual Machine. These SFs forms an SFC in the server. This is a typical NFV case, which I believe we agreed to support according mailing list discussion. So, where is the node fitting into? Equal to VMs?

Cheers,
Hongyu

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, November 30, 2013 3:17 AM
To: [email-masked]
Subject: [nsc] Charter text updated

Hi,

I've been reading through the mailing list and have polished the charter text a little further.

Added the word "format" describing the layer independence of the encapsulation in point 3.

I did not make any change after Hongyu's discussion of "network node". I don't think that is a synonym for "Network Element (NE)", but does represent an addressable node on the graph. It *is* an interesting debate about whether a specific service function instance can move around, but if it changes identity and address when it does so then perhaps it is hard to know what to call it. But I did take Thomas's proposal for that paragraph and rework it to lead to..

This is the version that will go to the IESG on Thursday 5th. You can (of
course) continue to discuss the text, but it feels like we are now tweaking the tweaks.

Cheers,
Adrian

PS. If you could all try to remember to change the subject line when your conversation wanders on to new topics it would be nice.

_______________________________________________
nsc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsc

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sat, 30 Nov 2013 08:26:34 +0000

Would entities be better than nodes?

S

> On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 30 Nov 2013 13:07:08 -0000

I don't like to use "entity" because it is commonly shorthand for "Network
Entity (NE)" which has a long association with a physical box.

"Node" (for me) is a concept of graph theory equating to "vertex" and is a
"point on the graph". That, I think, mans that it is uniquely addressable and
identifiable, but may be logical or physical (indeed, when we want to make the
distinction we say "logical node" or "physical node").

Hongyu, I appreciate you asking questions to find out what is and is not in
scope for this text. But since we are having trouble reaching convergence, I
wonder whether you could make a clear statement of what it is that you want to
make sure is in scope for the WG. If you can say "I want the WG to be able to
work on..." then we can pick an appropriate answer:
- Ah, no, it is our intention that that is out of scope
- Yes, and that is already in scope
- Oh, we see what you mean - here is a text change.

Thanks,
Adrian

> From: Stewart Bryant (stbryant) [mailto:[email-masked]]
> Sent: 30 November 2013 08:27
> To: Hongyu Li (Julio)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nsc] Node or not //RE: Charter text updated
> 
> > There are several virtual Service Functions running in a same server, and
each
> Service Function is running in a standalone Virtual Machine. These SFs forms
an
> SFC in the server. This is a typical NFV case, which I believe we agreed to
support
> according mailing list discussion. So, where is the node fitting into? Equal
to VMs?
> specific service function instance can move around, but if it changes identity
and
> address when it does so then perhaps it is hard to know what to call it. But I
did
> take Thomas's proposal for that paragraph and rework it to lead to..
> >

---

From: Thomas Nadeau <[email-masked]>
Date: Sat, 30 Nov 2013 09:18:47 -0500

> distinction we say "logical node" or "physical node").

	I agree. In fact, we refined that a little more in draft-quinn-sfc-arch 
by using this definition:

  Service Node (SN):  Physical or virtual element that hosts one or
      more service functions and has one or more network locators
      associated with it for reachability and service delivery.

	--Tom

---

From: Ron Parker <[email-masked]>
Date: Sat, 30 Nov 2013 16:24:21 +0000

Tom,

That definition covers all the necessary aspects, IMO.

   Ron

-----Original Message-----
From: nsc [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Saturday, November 30, 2013 9:19 AM
To: Farrel Adrian
Cc: [email-masked]; Hongyu Li (Julio)
Subject: Re: [nsc] Node or not //RE: Charter text updated

On Nov 30, 2013:8:07 AM, at 8:07 AM, Adrian Farrel <[email-masked]> wrote:

> I don't like to use "entity" because it is commonly shorthand for 
> "Network Entity (NE)" which has a long association with a physical box.
> 
> "Node" (for me) is a concept of graph theory equating to "vertex" and 
> is a "point on the graph". That, I think, mans that it is uniquely 
> addressable and identifiable, but may be logical or physical (indeed, 
> when we want to make the distinction we say "logical node" or "physical node").

	I agree. In fact, we refined that a little more in draft-quinn-sfc-arch by using this definition:

	--Tom

> 
> Hongyu, I appreciate you asking questions to find out what is and is 
> not in scope for this text. But since we are having trouble reaching 
> convergence, I wonder whether you could make a clear statement of what 
> it is that you want to make sure is in scope for the WG. If you can 
> say "I want the WG to be able to work on..." then we can pick an appropriate answer:
>>> I am not sure where are "nodes that implement" in above test fitting 
>>> into
>> following case:
>>> 
>>> I've been reading through the mailing list and have polished the 
>>> charter
> text a
>> little further.
>>> 
>>>  encapsulation may be used on a service function path realized at 
>>> the  network layer or at any other layer, and the same encapsulation 
>>> will  apply for the construction of service function paths 
>>> regardless of  the actual service."
>>> I did not make any change after Hongyu's discussion of "network 
>>> node". I
> don't
>> think that is a synonym for "Network Element (NE)", but does 
>> represent an addressable node on the graph. It *is* an interesting 
>> debate about whether a specific service function instance can move 
>> around, but if it changes identity
> and
>>>  An SFC is instantiated through selection  of specific service 
>>> function instances on specific network nodes to form  a service 
>>> graph: this is called a Service Function Path (SFP).
>>> 
>>> course) continue to discuss the text, but it feels like we are now 
>>> tweaking
> the
>> tweaks.
>>> 
>>> Cheers,
>>> Adrian
>>>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sun, 1 Dec 2013 03:32:37 +0000

+1, "node" makes perfect sense.

Surendra.

On 11/30/13 6:18 AM, "Thomas Nadeau" <[email-masked]> wrote:

>>"Network
>>is a
>>not in