Subject: Re: [nsc] Node or not //RE: Charter text updated

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 01 Dec 2013 18:18:46 +0000

Agreed. I support keeping "node".

Be goode,

On 1 Dec 2013, at 04:32 , Surendra Kumar (smkumar) wrote:

> +1, "node" makes perfect sense.
>
> Surendra.
>
> On 11/30/13 6:18 AM, "Thomas Nadeau" <[email-masked]> wrote:
>
>>
>> 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:
>>
>> 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
>>
>>
>>>
>>> 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
>>>
>>>> -----Original Message-----
>>>> 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
>>>>
>>>> Would entities be better than nodes?
>>>>
>>>> S
>>>>
>>>>
>>>>
>>>>> On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" <[email-masked]>
>>>>> wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> _______________________________________________
>>>>> nsc mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/nsc
>>>>> _______________________________________________
>>>>> nsc mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/nsc
>>>
>>> _______________________________________________
>>> nsc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nsc
>>>
>>
>
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Mon, 2 Dec 2013 01:39:21 +0000

Hi Adrian,

The case I expect the charter to cover is the example I made in the first email of this thread. Now that node can be interpreted as logical ones, I am OK with current text.

Thanks,
Hongyu

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Saturday, November 30, 2013 9:07 PM
To: Hongyu Li (Julio)
Cc: [email-masked]
Subject: RE: [nsc] Node or not //RE: Charter text updated

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

> > On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" <[email-masked]> wrote:
> >
> > Hi all,
> >
> > There are several virtual Service Functions running in a same 
> > server, and
each
an
support
to VMs?
text a
don't
> 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
did
> >   of specific service function instances on specific network nodes to form
> > This is the version that will go to the IESG on Thursday 5th. You 
> > can (of
the