Subject: Re: [nsc] nsc Digest, Vol 4, Issue 85

From: Sanjay Chalikar <[email-masked]>
Date: Tue, 17 Sep 2013 13:35:48 +0530

Hello All,

Sorry, out the box discussion. Can we add a sub-layer into the OSI model as
session initiated and session terminated binary calculation. As this would
give us the time to include time calculating bit, for me transaction. Do
you all really get my concerns.

cheers,
Sanjay Chalikar
Skype id: sanjay.chalikare

+91 - 9637 436287/ [email-masked], [email-masked]
http://lnkd.in/sJm_yE
http://www.linkedin.com/pub/sanjay-chalikar/2b/7a3/13a

On Sat, Sep 14, 2013 at 12:59 AM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/nsc
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send nsc mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/nsc
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nsc digest..."
>
> Today's Topics:
>
>    1. Re: New NSC WG Charter (Adrian Farrel)
>    2. Re: New NSC WG Charter (Lucy yong)
>
>
> ---------- Forwarded message ----------
> From: "Adrian Farrel" <[email-masked]>
> To: "'Lucy yong'" <[email-masked]>, "'Linda Dunbar'" <
> [email-masked]>, <[email-masked]>
> Cc:
> Date: Fri, 13 Sep 2013 20:18:07 +0100
> Subject: Re: [nsc] New NSC WG Charter
> Hi Lucy
>
> > Clarify that your reply is to Linda, not me.
>
> Sorry. Too many equally nice ladies working in the same company with two
> syllable names beginning with L.
>
> As to the rest, I think we are close enough to converged.
>
> Adrian
>
>
>
>
> ---------- Forwarded message ----------
> From: Lucy yong <[email-masked]>
> To: Ken Gray <[email-masked]>, "[email-masked]" <
> [email-masked]>, Linda Dunbar <[email-masked]>, "
> [email-masked]" <[email-masked]>
> Cc:
> Date: Fri, 13 Sep 2013 19:28:57 +0000
> Subject: Re: [nsc] New NSC WG Charter
>
> ** **
>
> *From:* Ken Gray [mailto:[email-masked]]
> *Sent:* Friday, September 13, 2013 2:17 PM
> *To:* Lucy yong; [email-masked]; Linda Dunbar; [email-masked]
> *Subject:* Re: [nsc] New NSC WG Charter****
>
> ** **
>
> It doesn't appear to me as if any of this has to do with the charter, per
> se … but once again attempts to explore/define how SFC will be
> achieved/embodied/communicated … which would be in other documents that are
> yet to be developed.  Cart -> Horse****
>
> *[Lucy] that is not my attempt.*
>
> *Lucy  *
>
> ** **
>
> ** **
>
> *From: *Lucy yong <[email-masked]>
> *Date: *Fri, 13 Sep 2013 17:40:38 +0000
> *To: *"[email-masked]" <[email-masked]>, Linda Dunbar <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [nsc] New NSC WG Charter****
>
> ** **
>
> Adrian,****
>
> Clarify that your reply is to Linda, not me.****
>
> My understand is that the SFC addresses the environment that service
> functions may be only available on the nodes that are not the path and some
> packet flows on the path need to be treated by some of service functions.
>  The SFC results these packet flows (need service functions) traverse a new
> path called service function path in order to be served. This is a clear
> problem and need to be solved.****
>
> To me, term “service delivery” in the charter means the ability to
> redirect the packet flows to the nodes where they can be served by the
> service functions.  ****
>
> Thanks,****
>
> Lucy****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Adrian Farrel
> *Sent:* Friday, September 13, 2013 11:11 AM
> *To:* Linda Dunbar; [email-masked]
> *Subject:* Re: [nsc] New NSC WG Charter****
>
>  ****
>
> Lucy,****
>
> I think that is circular. Why would one apply service functions to a data
> flow except to provide a service.****
>
> Lucy asked to whom the service is provided, and I answer "Why, to the
> service consumer, of course."****
>
> I don't know what you mean by "applications" in your mail. A service
> function is instantiated by a combination of hardware and software. In some
> cases, the service function will be instantiated purely by an "application"
> (i.e. by a piece of software running on a processor). In other cases it
> won't. Let's not complicate things by trying to give examples of everything.
> ****
>
>  ****
>
> A****
>
> *From:* Linda Dunbar [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* 13 September 2013 16:44
> *To:* [email-masked]; 'Jim Guichard (jguichar)'; [email-masked]
> *Subject:* RE: [nsc] New NSC WG Charter****
>
>  ****
>
>  ****
>
> Adrian, ****
>
> My interpretation of “Service function Chaining” is about network services
> that require a sequence of service functions to be applied to a selective
> data flows. So it is less about “service delivery”, but more about “the
> mechanism of applying service functions to data flows”. ****
>
> So I would suggest the sentence “The process of service delivery is..”  in
> the first paragraph to
>     “The process of applying service functions to selective data flows is
> changing from the physical insertion of equipment on the path into a
> mechanism for causing the path or ...”****
>
>  ****
>
> The wording of the charter: “Services are typically implemented by the
> ordered combination of a number of service functions that may be
> implemented at different points within the network”,  gives me the
> impression that the charter is about chaining a sequence of applications,
> like chaining WebServer <->AppServer<->DBserver.  If that is the intent of
> the charter, it is fine with me. ****
>
> Linda****
>
> *From:* Adrian Farrel [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, September 13, 2013 10:00 AM
> *To:* Linda Dunbar; 'Jim Guichard (jguichar)'; [email-masked]
> *Subject:* RE: [nsc] New NSC WG Charter****
>
>  ****
>
> Hi Linda,****
>
> I think it is important to be very clear when we mean service and when we
> mean service function.****
>
> IMHO, service functions are not delivered. Service functions are executed
> to deliver services.****
>
> Perhaps rather than a global search and replace, you could suggest
> specific instances to be replaced?****
>
> Thanks,****
>
> Adrian****
>
>  ****
>
> *From:[email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Linda Dunbar
> *Sent:* 13 September 2013 15:42
> *To:* Jim Guichard (jguichar); [email-masked]
> *Subject:* Re: [nsc] New NSC WG Charter****
>
>  ****
>
> I like the new name! ****
>
> “Service Function Chaining” is much more clear in describing the intent of
> the proposed work. ****
>
> IMHO, it would be even more clear to replace the “Services” across the
> charter with “Service Functions”, like “..Service functions delivery...”,
> to differentiate from the today’s connectivity/VPN “services”. ****
>
>  ****
>
> Linda****
>
>  ****
>
> *From:[email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Jim Guichard (jguichar)
> *Sent:* Friday, September 13, 2013 9:08 AM
> *To:* [email-masked]
> *Subject:* [nsc] New NSC WG Charter
> *Importance:* High****
>
>  ****
>
> Greetings,****
>
>  ****
>
> We have been working with the routing area AD's and our IAB shepherd Joel
> Halpern over the last few days to refine the NSC WG charter. The following
> is our proposal to the community for review and comment. Please note that
> as an outcome of the various discussions on the list we are proposing that
> the WG name change from "Network Service Chaining (NSC)" to "Service
> Function Chaining (SFC)". ****
>
>  ****
>
> *Proposed Service Function Chaining (SFC) WG Charter*****
>
>  ****
>
> Networks, servers, storage technologies, and applications, have all
> undergone significant change in recent years with the introduction of
> virtualization, network overlays, and orchestration. The process of service
> delivery is changing from the physical insertion of equipment on the path
> into a mechanism for causing the path or data to transit specific physical
> or virtual nodes on which the service functions are performed. Services are
> typically implemented by the ordered combination of a number of service
> functions that may be implemented at different points within the
> network.Service delivery is currently both a technical and organisational
> challenge that involves significant modification to the network
> configuration.****
>
> For a given service, the abstracted view of the required service functions
> and the order in which they are to be invoked is called a Service Function
> Chain (SFC). Since a given service function may be available on more than
> one node within a network, a ServiceFunction Chain is instantiated via the
> selection of specific service function instances and the network nodes on
> which they are provided, thereby forming a servicetopology: this is called
> a Service Function Path. The service functions may be applied at a specific
> layer within the network protocol stack (network layer, application layer,
> etc.).****
>
> The Service Function Chaining (SFC) working group will develop new
> approaches to service delivery and deployment, by providing a framework for
> service function chaining and the necessary protocols or protocol
> extensions to convey the service path and for communication between nodes
> that implement service functions.  The working group will also examine what
> information needs to be gathered from the network and service functions in
> support of service function chaining and how that information may be made
> available to nodes that implement the service functions.****
>
> Specifically, the SFC WG is chartered to deliver the following: ****
>
> 1) Problem Statement: This document will provide a summary of the problem
> space to be addressed by the WG including example high-level use cases.
>  Additionally, the WG will normalize nomenclature and definitions for
> service function chaining.****
>
> 2) Architecture: This document will provide a description of the
> architectural building blocks and their relationships including
> interconnection, placement of capabilities, management, diagnostics, and
> security models, as well as requirements on the protocol mechanisms.****
>
> 3) Generic Service Function Chaining Encapsulation: A document will
> describe the single service-level encapsulation protocol for conveying the
> service function chain and the service function path, and for communicating
> information between nodes that implement service functions. It is intended
> that the encapsulation be agnostic to thenetwork layer at which it is
> applied and the service that is being constructed. That is, the same
> encapsulation may be used on a service function path realised at the
> network layer or at any other layer, and the same encapsulation willapply
> for the construction of service function paths regardless of the actual
> service.****
>
> 4) Control Plane Mechanisms: A set of documents will be developed to
> describe requirements and protocols necessary to convey information to
> service function implementation points. Where possible, existing IETF
> protocols will be used and extended. All protocol extensions work should
> be carried out in the working groups responsible for the protocols being
> modified in coordination with this working group, but may be done in this
> working group after agreement with all the relevant WG chairs and
> responsible ADs.****
>
> 5) Manageability: This document will address the management of service
> function chaining includingrelevant MIBs and YANG data modules, and service
> function chaining diagnostics.****
>
> Proposed Milestones (all dates TBD):****
>
> Request the IESG for publication of an Informational document defining the
> problem statement and core use cases for Service Function Chaining****
>
> Request the IESG for publication of Informational documents defining the
> architecture for SFC and describing the framework and requirements for a
> generic service function chaining encapsulation protocol.****
>
> Request the IESG for publication of a Standards Track document specifying
> the generic service function chaining encapsulation protocol.****
>
> Request the IESG for publication of Informational documents specifying
> control plane requirements in support of specific SFC use cases.****
>
> Request the IESG for publication of an Informational document defining SFC
> manageability including diagnostics, and MIB and YANG data models to IESG
> ****
>
> Request the IESG for publication of Informational applicability documents
> defining how the protocol elements developed by the WG may be combined with
> other IETF protocols to satisfy the use cases.****
>
>  ****
>
>  ****
>
> _______________________________________________ nsc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/nsc ****
>
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc
>
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Sep 2013 04:38:46 -0800

On 9/17/13 12:05 AM, Sanjay Chalikar wrote:
> Sorry, out the box discussion. Can we add a sub-layer into the OSI
> model as session initiated and session terminated binary calculation.
> As this would give us the time to include time calculating bit, for
> me transaction. Do you all really get my concerns.

I'm afraid I don't.  Could you explain the problem in more detail?

Melinda

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 17 Sep 2013 17:51:13 +0000

+1