From Ron_Parker@affirmednetworks.com  Tue Jul  2 06:35:07 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5030321F9D67 for <nsc@ietfa.amsl.com>; Tue,  2 Jul 2013 06:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXNQg5kVugyI for <nsc@ietfa.amsl.com>; Tue,  2 Jul 2013 06:35:02 -0700 (PDT)
Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9004B21F9D07 for <nsc@ietf.org>; Tue,  2 Jul 2013 06:35:02 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0123.003; Tue, 2 Jul 2013 06:35:01 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: Ac5w7gaFkR09Y/lqTveMLRqlAXe6pQBzw4MAAA54RDAAXUsmAACuz4Yg
Date: Tue, 2 Jul 2013 13:35:01 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A66DB52@MBX021-W3-CA-2.exch021.domain.local>
References: <CDF2F015F4429F458815ED2A6C2B6B0B1A669BFC@MBX021-W3-CA-2.exch021.domain.local> <8E86B6E7C6FB9F40A00B0E269045A7C91DDBB551@xmb-aln-x09.cisco.com>
In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C91DDBB551@xmb-aln-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2013 13:35:07 -0000

Surendra,

Thanks for continuing the discussion.   A few followups immediately below.

BR,
Ron
  =20

<snip>
SK> That is a fallacy! What is needed is a mechanism to steer the=20
SK> traffic
(frames/packets) to one or more service nodes while being able to identify =
the path used to steer the traffic. A simple overly network in the "data pl=
ane" with a service header like NSH satisfies this.

I'm assuming that the fallacy is the assumption of OpenFlow and not the ass=
umption that some assume OpenFlow :).   IP connectivity between all of the =
elements of the NSC should be both necessary and sufficient, IMO.


<snip>
SK> Precisely! The classification-capable nodes can provide such=20
SK> metadata
or ID to the service nodes to provide enhanced service delivery where the s=
ervice node is acting on a policy selected by the classifier-capable node. =
This ID may in turn lead to fine-grained classification at the service-node=
 based on any number attributes, including, flow, environment, network, ...=
 How to carry large metadata seems like a perfectly valid discussion to hav=
e as part of the WG and should be input to the WG when it is formed.

Conveyance of differentiated service profile can be communicated inband in =
the header, but there could be at least 3 approaches -- 1)  service require=
ments are conveyed concisely using AVP's or some other construct (i.e., lar=
ge metadata);  2) service requirements are conveyed with some sort of profi=
le ID whose meaning was communicated via an as-yet undefined control plane =
protocol;  3) service requirements are conveyed with some sort of profile I=
D whose meaning is provisioned via coordinated management actions at each o=
f the involved network elements.




-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=20
Sent: Friday, June 28, 2013 2:58 PM
To: Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Ron,

See my comments inline - SK>

Rgds,
Surendra.

On 6/26/13 5:50 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wrote:

>Hi, Paul.
>
>Thanks for the response.   My follow up embedded.
>
>BR,
>Ron
>
>-----Original Message-----
>From: Paul Quinn [mailto:paulq@cisco.com]
>Sent: Wednesday, June 26, 2013 11:33 AM
>To: Ron Parker
>Cc: nsc@ietf.org
>Subject: Re: [nsc] Comments on draft-quinn-nsh-00
>
>Hi Ron,
>
>Thanks for the thoughtful comments!  My apologies for not getting back=20
>to you sooner, I've been traveling.
>
>See my comments inline.
>
>Paul
>
>On Jun 24, 2013, at 8:19 AM, Ron Parker=20
><Ron_Parker@affirmednetworks.com>
>wrote:
>
>> I am new to this group and want to thank the authors and participants
>>for the good work you've done so far.   I feel that this work is very
>>complementary to the Network Function Virtualization Forum's nascent
>>network function chaining work.   Draft-quinn-nsh-00 and
>>draft-quinn-nsc-problem-statement-00 are, however, appropriately more=20
>>general in that mobile data services are not assumed to be the de=20
>>facto business problem and co-location of network functions are not=20
>>assumed to be within the data center.
>>=20
>
>PQ>  Yes. We make no assumption on applicability to particular market
>segments or location of service functions - all are within scope of=20
>this work.
>
>
>
>> My specific questions and comments on draft-quinn-nsh-00 follow...
>>=20
>> General - I agree with some previous comments on the thread that
>>"service" is an overloaded term.   I prefer the NFV's terms "network
>>function" and "network function chaining".   Let the business folks
>>determine what set of functions constitute a "service" that consumers=20
>>or businesses will pay for.
>
>PQ>  We tried use the term service function to describe the specific
>"services": e.g. firewall.  As Jim Guichard mentioned on the alias:
>services are what a customer buys and those services could be=20
>constructed using one or more "service functions". I don't want to use=20
>the term network function as that implies that the network somehow does=20
>something here which is not the case as the function applied is not=20
>necessarily at the network layer.
>Ron> Makes sense.
>
>
>>=20
>> 2.2 Problem Statement; 1. Topological Dependencies - This would be a=20
>>good place to clarify whether service chains are unidirectional or
>>bidirectional.   If bidirectional, is symmetry assumed (i.e. if from
>>client to server network functions A, B, C are invoked, then from=20
>>server to client, is it always C, B, A?  Must a classifier be at both end=
s of
>>the chain?   Must it be the same classifier at each end?
>>=20
>
>PQ>  Point well taken, we have two choices: do you have suggested text
>you think captures this, or I'm happy to send out a revision that=20
>incorporates comments to date early next week.  One thing to note:
>service chains could be unidirectional, bidirectional or something=20
>in-between and that symmetry may or may not be required. As part of the=20
>work we will have to define the "types" of service chains and this is=20
>something that the WG would be assigned to do.
>Ron> I don't have specific text at this point.   Agree that
>unidirectional, inversely-symmetrical bidirectional, and asymmetrical
>bidirectional are all valid.   Suggest that the flexible location of the
>classifier(s) be brought out, too.
>
>
>
>
>> 2.2 Problem Statement - It may be useful to discuss how standard IP
>>routing and NSC co-exist.   For example, a deployment based on this
>>technique may utilize IP routing to ensure packets arrive at the two=20
>>ends of a service chain, but the service overlay is used to steer=20
>>traffic between the two ends of the chain.
>>=20
>
>PQ>  Can you elaborate a bit more?  In general, routing carries the
>encapsulated packets from service to service.  The chaining function
>provides the service function destination for routing lookup.   IP
>routing is simply used for reachability of each service function within=20
>a service chain.
>Ron> I feel that many people thinking about this topic have somehow
>arrived at a conclusion that OpenFlow is automatically and exclusively=20
>the basis for achieving things like NSC.
SK> That is a fallacy! What is needed is a mechanism to steer the=20
SK> traffic
(frames/packets) to one or more service nodes while being able to identify =
the path used to steer the traffic. A simple overly network in the "data pl=
ane" with a service header like NSH satisfies this.
*Ron> I'm assuming that the fallacy is the assumption of OpenFlow and not t=
he assumption that some assume OpenFlow :).   IP connectivity between all o=
f the elements of the NSC should be both necessary and sufficient, IMO.

>
>
>> 3.1 NSH Actions; 1. Insert / Remove Service Header - this section=20
>>introduces the concept of control plane to indicate which node is "end
>>of the chain".   This could also be accomplished via the management
>>plane.   Perhaps a discussion of control plane and management plane
>>could be added to section 2.2?   From the balance of the draft, it seems
>>that control plane is deferred for a future proposal?
>>=20
>
>PQ>  Precisely.  We expect there to be several possible control plane
>options depending on environment and use case and this is something the=20
>WG would be assigned to work through.
>Ron>  My suggestion is that the concept be explicitly supportable with=20
>Ron> a
>control plane and without (i.e., solely via coordinated management of the
>affected Network Elements).   This may allow for earlier adoptions and
>thereby market validation of the concepts.
SK> By not requiring a specific model, NSH is generic to be=20
SK> implementable
in either model. As Paul said, further work in the WG can add to this.
>
>
>> 3.1 NSH Actions; 3. Update a Service Header - this section introduces
>>the concept of a service index.   From context, I assume that this
>>indicates the previous node was considered to be index N out of M total
>>nodes?   Is it 0-based or 1-based?
>
>PQ>  Correct, the index provides location with the path, and is
>decremented.  Service index=3D0 means the packet should be discarded.
>Ron> I suggest that the text be enhanced to bring out the semantic
>meaning more explicitly.
>
>
>>=20
>> 3.3 NSH Usage; 2. Service Chaining - this section introduces OAM
>>messages, but none are defined elsewhere in this document.   Does this
>>lend itself to a separate draft?   If so, should this document
>>acknowledge that it won't attempt to define OAM procedures?    Perhaps
>>it could acknowledge the possibility that the fields following the=20
>>Base Header would be different for OAM messages?
>>=20
>
>PQ>  Yes, the plan is to have a future OAM focused document.  I'll=20
>PQ> update
>the draft to reflect that.
>
>
>> 3.3 NSH Usage; 3. Metadata Sharing -It is mentioned that semantics of=20
>>the metadata require coordination via a control plane, but this seems=20
>>somewhat contrary to the previous statement that a fixed size and=20
>>format header is used for simplicity.
>
>
>PQ> The size is fixed, but the semantics of the data itself needs to be
>coordinated by the control plane.  For example, if the network shared=20
>context header is used to convey some form of classification, the value=20
>carried in the context but be meaningful to all participating nodes. =20
>The control plane assigns that meaning.
>Ron> Suggest that the concept include the option whereby the management
>plane assigns that meaning, too.
>
>
>>=20
>> 3.4 NSH Proxy Nodes - it is mentioned that the proxy may deliver the=20
>>packet to the service node via a local attachment circuit.  I suggest=20
>>that it should be specified that the service node is required to=20
>>deliver the packet back to the proxy (i.e., "bump-in-the-wire" forwarding
>>paradigm) via the same or different access circuit.   Also, this
>>mechanism could also be extended to non-NSH tunnels (i..e, IP-in-IP or=20
>>GRE).
>>=20
>
>PQ>  Good clarifications, and yes, the same of different circuits is
>viable, as are other encaps.  I'll update the doc.
>
>
>
>
>> 4. Header Format; C bit - the text states that when C bit is set, there
>>are one or more contexts present.   But then states that the format is
>>fixed to 4 32-bit contexts.
>
>PQ>  This is a parsing optimization: there are always 4 contexts but if
>non are used, then c=3D0 and they don't need to be checked.
>Ron> This was more of an editorial comment.   "When the C bit is set, all
>four contexts are present" would more accurately reflect the intention,=20
>if I have interpreted correctly.
>
>
>>=20
>> 4. Header Format - the distinction of network/service and
>>platform/shared is not clear to me.   Perhaps some usage examples could
>>be added to help clarify?
>>=20
>
>PQ>  Very valid comment, the next revision will include examples.
>
>
>
>> 4.  Header Format - for deployment topologies that  encompass access=20
>>networks (e.g., most), it is very common to wish to convey a=20
>>subscriber identity (e.g., IMSI or MSISDN in a mobile network) distinct f=
rom the IP
>>address used in the packet.   This may facilitate application of local
>>policy.   It can also facilitate application of local policy in network
>>functions chained after a NAT function.   Perhaps an optional 128-bit
>>generic subscriber identity can be considered in the NSH?    On the
>>other hand, I can see where keeping the NSH size minimal is extremely
>>beneficial.   One thought here would be a mechanism that could be
>>employed by stateful network functions using flag bits to acknowledge=20
>>that certain metadata has been received and is no longer necessary in
>>subsequent packets of the fully qualified flow.   With this approach,
>>the 128-bit generic subscriber identity could be conveyed in the first=20
>>N packets to the next node until a packet is received back from the=20
>>next nod
> e with the corresponding acknowledgement bit set.   This approach could
>be extended to other fields, including the 4 context fields already=20
>defined.
>>=20
>> =20
>
>PQ> The header is flexible enough to accommodate such a case but I need
>to understand the use case in more detail.  In theory, a control plane=20
>could indicate that the context headers are to be interpreted=20
>differently.  Again, I'd like to get a better sense of how you'd use this.
>Ron> Given this split notion of classification-capable nodes and
>non-classification-capable nodes, could the classification nodes add more
>value than simply choosing which SF's need to be invoked.   In
>particular, certain SF's would be capable of providing differentiated
>services for different groups of subscribers.   Can the classifier
>determine not only that some SF needs to be inserted but also which
>locally significant set of policy should be applied?   If so, how is this
>conveyed from the classifier to the SF?   Inband?   Out of band?
SK> Precisely! The classification-capable nodes can provide such=20
SK> metadata
or ID to the service nodes to provide enhanced service delivery where the s=
ervice node is acting on a policy selected by the classifier-capable node. =
This ID may in turn lead to fine-grained classification at the service-node=
 based on any number attributes, including, flow, environment, network, ...=
 How to carry large metadata seems like a perfectly valid discussion to hav=
e as part of the WG and should be input to the WG when it is formed.
>
>
>
>>=20
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From jguichar@cisco.com  Tue Jul  2 15:50:38 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96AD11E8122 for <nsc@ietfa.amsl.com>; Tue,  2 Jul 2013 15:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7CDhWH+dnUO for <nsc@ietfa.amsl.com>; Tue,  2 Jul 2013 15:50:33 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ACC8311E8121 for <nsc@ietf.org>; Tue,  2 Jul 2013 15:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14552; q=dns/txt; s=iport; t=1372805432; x=1374015032; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=asdbsLvzxIjXYL8qjdX4DVvGFkAZTzteDOMKcwoPBCw=; b=R9hg/z3Yl2Sd5Ia+xMYDH4WObUmMVi0Op9fYq+NbS9dvLkZmxMiQV+TR d//AdueZQyQzPG/ygZBO1cpqQwyljOq7YvIOtCm8evC9nzxIL4B5B2qmf knSqPQMyE77JCiKkhZFjlpc/T7SHKkq0IrX4CnzeatakgL0qAajdDVPC9 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAARY01GtJV2b/2dsb2JhbABQAQmDCTJJv3mBBxZ0giMBAQEEAQEBCywrAgcLDAYBCBEEAQEBChQJLgsUCQgBAQQBDQUIE4d0DLtGBI4pAYEKBisHBoJ+aQOpD4MRgWokGg
X-IronPort-AV: E=Sophos;i="4.87,983,1363132800"; d="scan'208";a="230281513"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 02 Jul 2013 22:50:31 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r62MoVnN016364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 22:50:31 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.9]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 17:50:30 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Surendra Kumar (smkumar)" <smkumar@cisco.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: Ac5w7gaFkR09Y/lqTveMLRqlAXe6pQBvkqEAAACgfYAAXHeJAADMitSAAAsEMoA=
Date: Tue, 2 Jul 2013 22:50:30 +0000
Message-ID: <68B171751455884590F8E38E96416F363F570491@xmb-rcd-x01.cisco.com>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A66DB52@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.212]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <794FC9213BF6B5499B2FA1F4BBDDDAF2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2013 22:50:38 -0000

Hi Ron,
Comments inline ..

On 7/2/13 9:35 AM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wrote:
> =20
>
><snip>
>SK> That is a fallacy! What is needed is a mechanism to steer the
>SK> traffic
>(frames/packets) to one or more service nodes while being able to
>identify the path used to steer the traffic. A simple overly network in
>the "data plane" with a service header like NSH satisfies this.
>
>I'm assuming that the fallacy is the assumption of OpenFlow and not the
>assumption that some assume OpenFlow :).   IP connectivity between all of
>the elements of the NSC should be both necessary and sufficient, IMO.

Jim> absolutely. Note that the overlay is simply a means to get packets
from point A to point B and then potentially to point C and so forth.

>
>
><snip>
>SK> Precisely! The classification-capable nodes can provide such
>SK> metadata
>or ID to the service nodes to provide enhanced service delivery where the
>service node is acting on a policy selected by the classifier-capable
>node. This ID may in turn lead to fine-grained classification at the
>service-node based on any number attributes, including, flow,
>environment, network, ... How to carry large metadata seems like a
>perfectly valid discussion to have as part of the WG and should be input
>to the WG when it is formed.
>
>Conveyance of differentiated service profile can be communicated inband
>in the header, but there could be at least 3 approaches -- 1)  service
>requirements are conveyed concisely using AVP's or some other construct
>(i.e., large metadata);  2) service requirements are conveyed with some
>sort of profile ID whose meaning was communicated via an as-yet undefined
>control plane protocol;  3) service requirements are conveyed with some
>sort of profile ID whose meaning is provisioned via coordinated
>management actions at each of the involved network elements.

Jim> yes and part of any WG charter would be to fully investigate and
provide solutions for one or more of these approaches.

>
>
>
>
>-----Original Message-----
>From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
>Sent: Friday, June 28, 2013 2:58 PM
>To: Ron Parker; Paul Quinn (paulq)
>Cc: nsc@ietf.org
>Subject: Re: [nsc] Comments on draft-quinn-nsh-00
>
>Ron,
>
>See my comments inline - SK>
>
>Rgds,
>Surendra.
>
>On 6/26/13 5:50 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wrote:
>
>>Hi, Paul.
>>
>>Thanks for the response.   My follow up embedded.
>>
>>BR,
>>Ron
>>
>>-----Original Message-----
>>From: Paul Quinn [mailto:paulq@cisco.com]
>>Sent: Wednesday, June 26, 2013 11:33 AM
>>To: Ron Parker
>>Cc: nsc@ietf.org
>>Subject: Re: [nsc] Comments on draft-quinn-nsh-00
>>
>>Hi Ron,
>>
>>Thanks for the thoughtful comments!  My apologies for not getting back
>>to you sooner, I've been traveling.
>>
>>See my comments inline.
>>
>>Paul
>>
>>On Jun 24, 2013, at 8:19 AM, Ron Parker
>><Ron_Parker@affirmednetworks.com>
>>wrote:
>>
>>> I am new to this group and want to thank the authors and participants
>>>for the good work you've done so far.   I feel that this work is very
>>>complementary to the Network Function Virtualization Forum's nascent
>>>network function chaining work.   Draft-quinn-nsh-00 and
>>>draft-quinn-nsc-problem-statement-00 are, however, appropriately more
>>>general in that mobile data services are not assumed to be the de
>>>facto business problem and co-location of network functions are not
>>>assumed to be within the data center.
>>>=20
>>
>>PQ>  Yes. We make no assumption on applicability to particular market
>>segments or location of service functions - all are within scope of
>>this work.
>>
>>
>>
>>> My specific questions and comments on draft-quinn-nsh-00 follow...
>>>=20
>>> General - I agree with some previous comments on the thread that
>>>"service" is an overloaded term.   I prefer the NFV's terms "network
>>>function" and "network function chaining".   Let the business folks
>>>determine what set of functions constitute a "service" that consumers
>>>or businesses will pay for.
>>
>>PQ>  We tried use the term service function to describe the specific
>>"services": e.g. firewall.  As Jim Guichard mentioned on the alias:
>>services are what a customer buys and those services could be
>>constructed using one or more "service functions". I don't want to use
>>the term network function as that implies that the network somehow does
>>something here which is not the case as the function applied is not
>>necessarily at the network layer.
>>Ron> Makes sense.
>>
>>
>>>=20
>>> 2.2 Problem Statement; 1. Topological Dependencies - This would be a
>>>good place to clarify whether service chains are unidirectional or
>>>bidirectional.   If bidirectional, is symmetry assumed (i.e. if from
>>>client to server network functions A, B, C are invoked, then from
>>>server to client, is it always C, B, A?  Must a classifier be at both
>>>ends of
>>>the chain?   Must it be the same classifier at each end?
>>>=20
>>
>>PQ>  Point well taken, we have two choices: do you have suggested text
>>you think captures this, or I'm happy to send out a revision that
>>incorporates comments to date early next week.  One thing to note:
>>service chains could be unidirectional, bidirectional or something
>>in-between and that symmetry may or may not be required. As part of the
>>work we will have to define the "types" of service chains and this is
>>something that the WG would be assigned to do.
>>Ron> I don't have specific text at this point.   Agree that
>>unidirectional, inversely-symmetrical bidirectional, and asymmetrical
>>bidirectional are all valid.   Suggest that the flexible location of the
>>classifier(s) be brought out, too.
>>
>>
>>
>>
>>> 2.2 Problem Statement - It may be useful to discuss how standard IP
>>>routing and NSC co-exist.   For example, a deployment based on this
>>>technique may utilize IP routing to ensure packets arrive at the two
>>>ends of a service chain, but the service overlay is used to steer
>>>traffic between the two ends of the chain.
>>>=20
>>
>>PQ>  Can you elaborate a bit more?  In general, routing carries the
>>encapsulated packets from service to service.  The chaining function
>>provides the service function destination for routing lookup.   IP
>>routing is simply used for reachability of each service function within
>>a service chain.
>>Ron> I feel that many people thinking about this topic have somehow
>>arrived at a conclusion that OpenFlow is automatically and exclusively
>>the basis for achieving things like NSC.
>SK> That is a fallacy! What is needed is a mechanism to steer the
>SK> traffic
>(frames/packets) to one or more service nodes while being able to
>identify the path used to steer the traffic. A simple overly network in
>the "data plane" with a service header like NSH satisfies this.
>*Ron> I'm assuming that the fallacy is the assumption of OpenFlow and not
>the assumption that some assume OpenFlow :).   IP connectivity between
>all of the elements of the NSC should be both necessary and sufficient,
>IMO.
>
>>
>>
>>> 3.1 NSH Actions; 1. Insert / Remove Service Header - this section
>>>introduces the concept of control plane to indicate which node is "end
>>>of the chain".   This could also be accomplished via the management
>>>plane.   Perhaps a discussion of control plane and management plane
>>>could be added to section 2.2?   From the balance of the draft, it seems
>>>that control plane is deferred for a future proposal?
>>>=20
>>
>>PQ>  Precisely.  We expect there to be several possible control plane
>>options depending on environment and use case and this is something the
>>WG would be assigned to work through.
>>Ron>  My suggestion is that the concept be explicitly supportable with
>>Ron> a
>>control plane and without (i.e., solely via coordinated management of the
>>affected Network Elements).   This may allow for earlier adoptions and
>>thereby market validation of the concepts.
>SK> By not requiring a specific model, NSH is generic to be
>SK> implementable
>in either model. As Paul said, further work in the WG can add to this.
>>
>>
>>> 3.1 NSH Actions; 3. Update a Service Header - this section introduces
>>>the concept of a service index.   From context, I assume that this
>>>indicates the previous node was considered to be index N out of M total
>>>nodes?   Is it 0-based or 1-based?
>>
>>PQ>  Correct, the index provides location with the path, and is
>>decremented.  Service index=3D0 means the packet should be discarded.
>>Ron> I suggest that the text be enhanced to bring out the semantic
>>meaning more explicitly.
>>
>>
>>>=20
>>> 3.3 NSH Usage; 2. Service Chaining - this section introduces OAM
>>>messages, but none are defined elsewhere in this document.   Does this
>>>lend itself to a separate draft?   If so, should this document
>>>acknowledge that it won't attempt to define OAM procedures?    Perhaps
>>>it could acknowledge the possibility that the fields following the
>>>Base Header would be different for OAM messages?
>>>=20
>>
>>PQ>  Yes, the plan is to have a future OAM focused document.  I'll
>>PQ> update
>>the draft to reflect that.
>>
>>
>>> 3.3 NSH Usage; 3. Metadata Sharing -It is mentioned that semantics of
>>>the metadata require coordination via a control plane, but this seems
>>>somewhat contrary to the previous statement that a fixed size and
>>>format header is used for simplicity.
>>
>>
>>PQ> The size is fixed, but the semantics of the data itself needs to be
>>coordinated by the control plane.  For example, if the network shared
>>context header is used to convey some form of classification, the value
>>carried in the context but be meaningful to all participating nodes.
>>The control plane assigns that meaning.
>>Ron> Suggest that the concept include the option whereby the management
>>plane assigns that meaning, too.
>>
>>
>>>=20
>>> 3.4 NSH Proxy Nodes - it is mentioned that the proxy may deliver the
>>>packet to the service node via a local attachment circuit.  I suggest
>>>that it should be specified that the service node is required to
>>>deliver the packet back to the proxy (i.e., "bump-in-the-wire"
>>>forwarding
>>>paradigm) via the same or different access circuit.   Also, this
>>>mechanism could also be extended to non-NSH tunnels (i..e, IP-in-IP or
>>>GRE).
>>>=20
>>
>>PQ>  Good clarifications, and yes, the same of different circuits is
>>viable, as are other encaps.  I'll update the doc.
>>
>>
>>
>>
>>> 4. Header Format; C bit - the text states that when C bit is set, there
>>>are one or more contexts present.   But then states that the format is
>>>fixed to 4 32-bit contexts.
>>
>>PQ>  This is a parsing optimization: there are always 4 contexts but if
>>non are used, then c=3D0 and they don't need to be checked.
>>Ron> This was more of an editorial comment.   "When the C bit is set, all
>>four contexts are present" would more accurately reflect the intention,
>>if I have interpreted correctly.
>>
>>
>>>=20
>>> 4. Header Format - the distinction of network/service and
>>>platform/shared is not clear to me.   Perhaps some usage examples could
>>>be added to help clarify?
>>>=20
>>
>>PQ>  Very valid comment, the next revision will include examples.
>>
>>
>>
>>> 4.  Header Format - for deployment topologies that  encompass access
>>>networks (e.g., most), it is very common to wish to convey a
>>>subscriber identity (e.g., IMSI or MSISDN in a mobile network) distinct
>>>from the IP
>>>address used in the packet.   This may facilitate application of local
>>>policy.   It can also facilitate application of local policy in network
>>>functions chained after a NAT function.   Perhaps an optional 128-bit
>>>generic subscriber identity can be considered in the NSH?    On the
>>>other hand, I can see where keeping the NSH size minimal is extremely
>>>beneficial.   One thought here would be a mechanism that could be
>>>employed by stateful network functions using flag bits to acknowledge
>>>that certain metadata has been received and is no longer necessary in
>>>subsequent packets of the fully qualified flow.   With this approach,
>>>the 128-bit generic subscriber identity could be conveyed in the first
>>>N packets to the next node until a packet is received back from the
>>>next nod
>> e with the corresponding acknowledgement bit set.   This approach could
>>be extended to other fields, including the 4 context fields already
>>defined.
>>>=20
>>> =20
>>
>>PQ> The header is flexible enough to accommodate such a case but I need
>>to understand the use case in more detail.  In theory, a control plane
>>could indicate that the context headers are to be interpreted
>>differently.  Again, I'd like to get a better sense of how you'd use
>>this.
>>Ron> Given this split notion of classification-capable nodes and
>>non-classification-capable nodes, could the classification nodes add more
>>value than simply choosing which SF's need to be invoked.   In
>>particular, certain SF's would be capable of providing differentiated
>>services for different groups of subscribers.   Can the classifier
>>determine not only that some SF needs to be inserted but also which
>>locally significant set of policy should be applied?   If so, how is this
>>conveyed from the classifier to the SF?   Inband?   Out of band?
>SK> Precisely! The classification-capable nodes can provide such
>SK> metadata
>or ID to the service nodes to provide enhanced service delivery where the
>service node is acting on a policy selected by the classifier-capable
>node. This ID may in turn lead to fine-grained classification at the
>service-node based on any number attributes, including, flow,
>environment, network, ... How to carry large metadata seems like a
>perfectly valid discussion to have as part of the WG and should be input
>to the WG when it is formed.
>>
>>
>>
>>>=20
>>> _______________________________________________
>>> nsc mailing list
>>> nsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nsc
>>
>>_______________________________________________
>>nsc mailing list
>>nsc@ietf.org
>>https://www.ietf.org/mailman/listinfo/nsc
>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From christian.jacquenet@orange.com  Wed Jul  3 01:44:34 2013
Return-Path: <christian.jacquenet@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D4921F96EB for <nsc@ietfa.amsl.com>; Wed,  3 Jul 2013 01:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.938
X-Spam-Level: 
X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRYnBk9tvz-w for <nsc@ietfa.amsl.com>; Wed,  3 Jul 2013 01:44:30 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7597021F91B7 for <nsc@ietf.org>; Wed,  3 Jul 2013 01:44:30 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E9B8F22CF8D for <nsc@ietf.org>; Wed,  3 Jul 2013 10:44:26 +0200 (CEST)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D102F35C065 for <nsc@ietf.org>; Wed,  3 Jul 2013 10:44:26 +0200 (CEST)
Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 3 Jul 2013 10:44:26 +0200
From: <christian.jacquenet@orange.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Date: Wed, 3 Jul 2013 10:44:25 +0200
Thread-Topic: New Version Notification for draft-boucadair-network-function-chaining-02.txt
Thread-Index: Ac53yUoL9MO1VzZYT6CYEfeEW5o3/AAAAhcA
Message-ID: <3138_1372841066_51D3E46A_3138_837_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15C46A8BFBA@PUEXCB1C.nanterre.francetelecom.fr>
References: <20130703084240.19055.59091.idtracker@ietfa.amsl.com>
In-Reply-To: <20130703084240.19055.59091.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.63327
Subject: [nsc] TR: New Version Notification for	draft-boucadair-network-function-chaining-02.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 08:44:34 -0000

RllJIC0gdGhpcyBuZXcgdmVyc2lvbiB3ZWxjb21lcyB0d28gYWRkaXRpb25hbCBjby1hdXRob3Jz
IGFuZCBhbHNvIGNsZWFucyB1cCBzb21lIHRleHQuDQoNCkNoZWVycywNCg0KQ2hyaXN0aWFuLg0K
DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRm
Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpFbnZvecOpwqA6IG1lcmNy
ZWRpIDMganVpbGxldCAyMDEzIDEwOjQzDQrDgMKgOiBKaW0gR3VpY2hhcmQ7IEJPVUNBREFJUiBN
b2hhbWVkIE9MTkMvT0xOOyBKQUNRVUVORVQgQ2hyaXN0aWFuIE9MTkMvT0xOOyBSb24gUGFya2Vy
OyBQYXJ2aXogWWVnYW5pOyBEaWVnbyBSLkxvcGV6OyBQYXVsIFF1aW5uDQpPYmpldMKgOiBOZXcg
VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvdWNhZGFpci1uZXR3b3JrLWZ1bmN0aW9u
LWNoYWluaW5nLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib3VjYWRh
aXItbmV0d29yay1mdW5jdGlvbi1jaGFpbmluZy0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs
eSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy
ZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWJvdWNhZGFpci1uZXR3b3JrLWZ1bmN0aW9u
LWNoYWluaW5nDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBEaWZmZXJlbnRpYXRlZCBOZXR3b3Jr
LUxvY2F0ZWQgRnVuY3Rpb24gQ2hhaW5pbmcgRnJhbWV3b3JrDQpDcmVhdGlvbiBkYXRlOgkgMjAx
My0wNy0wMw0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6
IDIwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWJvdWNhZGFpci1uZXR3b3JrLWZ1bmN0aW9uLWNoYWluaW5nLTAyLnR4dA0KU3RhdHVz
OiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFp
ci1uZXR3b3JrLWZ1bmN0aW9uLWNoYWluaW5nDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1uZXR3b3JrLWZ1bmN0aW9uLWNoYWluaW5n
LTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy
YWZ0LWJvdWNhZGFpci1uZXR3b3JrLWZ1bmN0aW9uLWNoYWluaW5nLTAyDQoNCkFic3RyYWN0Og0K
ICAgSVAgbmV0d29ya3MgcmVseSBtb3JlIGFuZCBtb3JlIG9uIHRoZSBjb21iaW5hdGlvbiBvZiBh
ZHZhbmNlZA0KICAgZnVuY3Rpb25zIChiZXNpZGVzIHRoZSBiYXNpYyByb3V0aW5nIGFuZCBmb3J3
YXJkaW5nIGZ1bmN0aW9ucykuICBUaGlzDQogICBkb2N1bWVudCBkZWZpbmVzIGEgc29sdXRpb24g
dG8gZW5mb3JjZSBOZXR3b3JrLUxvY2F0ZWQgRnVuY3Rpb24NCiAgIENoYWluaW5nIChOTEZDKSB3
aXRoIG1pbmltdW0gcmVxdWlyZW1lbnRzIG9uIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsuDQoNCiAg
IFRoZSBwcm9wb3NlZCBzb2x1dGlvbiBhbGxvd3MgZm9yIERpZmZlcmVudGlhdGVkIEZvcndhcmRp
bmcNCiAgIChEaWZmRm9yd2FyZCk6IHBhY2tldHMgYXJlIGNsYXNzaWZpZWQgYXQgdGhlIGVudHJ5
IHBvaW50IG9mIGFuIE5MRkMtDQogICBlbmFibGVkIG5ldHdvcmssIGFuZCBhcmUgdGhlbiBmb3J3
YXJkZWQgb24gYSBwZXIgTkxGQyBtYXAgYmFzaXMuDQoNCg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0
IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u
ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg
ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg
YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs
J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g
TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv
biwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0
ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBp
dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m
b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJl
IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlv
dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl
bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFp
bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0
IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==

From satoru.matsushima@gmail.com  Thu Jul 11 12:23:00 2013
Return-Path: <satoru.matsushima@gmail.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD2F21F9D28 for <nsc@ietfa.amsl.com>; Thu, 11 Jul 2013 12:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGLy+Xv7F4x9 for <nsc@ietfa.amsl.com>; Thu, 11 Jul 2013 12:23:00 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C18BD21F9B5C for <nsc@ietf.org>; Thu, 11 Jul 2013 12:22:58 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id fr10so7093627lab.32 for <nsc@ietf.org>; Thu, 11 Jul 2013 12:22:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aSV4hkii/Ui+jpyIBMiA6hnaObmR4WUsBqf+Efl6Izg=; b=LML0Te+joP9e1/4Jcav/CbjmFzkMRdbDKK4Hj9wQQ84j+Dxwy+MM+WXR48KyqBTaUz YomfsoWnT+98uTnRwJz86IIeAQ9R5dZVGto6hvG8nE3R9ouTMzfliFt3YomrQSdTwKbh jGSReT4okVgRduy9s4pKLXDR1aFMrz2WoT8AYfFx3HW+z/s22GRh73Wc268DVi30ywMb 5ivX/X31Ne+NrUXLMgfMhok+MqNciZ6Zs+k10IFVVnnKKjnyQn5/l4pnd3Pf35XZnH+Z iVdhvSXRVc7eP8eI3LVeOoSL6pz23ialD+YfJFnFfsOkwY7HALoRYzADQbl5IYDB9lHg KPGg==
MIME-Version: 1.0
X-Received: by 10.112.200.9 with SMTP id jo9mr17809895lbc.54.1373570574923; Thu, 11 Jul 2013 12:22:54 -0700 (PDT)
Received: by 10.112.167.169 with HTTP; Thu, 11 Jul 2013 12:22:54 -0700 (PDT)
Date: Fri, 12 Jul 2013 04:22:54 +0900
Message-ID: <CAFwJXX4yuRTj7BoUJG0iyA5JrnNv2yuELXRkLTMerc8CS-5fPA@mail.gmail.com>
From: Satoru Matsushima <satoru.matsushima@gmail.com>
To: nsc@ietf.org
Content-Type: multipart/alternative; boundary=001a11c371c2313fbb04e14152b9
Subject: [nsc] Fwd: I-D Action: draft-matsushima-stateless-uplane-vepc-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2013 19:23:01 -0000

--001a11c371c2313fbb04e14152b9
Content-Type: text/plain; charset=ISO-8859-1

Hi,

We have submitted an I-D for mobile core user-plane which adopts routing
basis architecture instead of tunnel centric one. This draft  hasn't been
mentioned the nsc stuff yet. But I think that the routing based
architecture for user-plane of mobile core fits to service chaining in
routing basis very much. Your comments, or advises to this architecture in
the nsc point of view are welcome.

Regards,
--satoru



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Jul 11, 2013 at 1:09 AM
Subject: I-D Action: draft-matsushima-stateless-uplane-vepc-00.txt
To: i-d-announce@ietf.org



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


        Title           : Stateless user-plane architecture for virtualized
EPC (vEPC)
        Author(s)       : Satoru Matsushima
                          Ryuji Wakikawa
        Filename        : draft-matsushima-stateless-uplane-vepc-00.txt
        Pages           : 19
        Date            : 2013-07-10

Abstract:
   We envision a new mobile architecture for the future Evolved Packet
   Core (EPC).  The new architecture is designed to support the
   virtualization scheme called NFV (Network Function Virtualization).
   In our architecture, the user plane of EPC is decoupled from the
   control-plane and uses routing information to forward packets of
   mobile nodes.  Although the EPC control plane will run on hypervisor,
   our proposal does not modify the signaling of the EPC control plane.
   The benefits of our architecture are 1) scalability, 2) flexibility
   and 3) Manageability.  How to run the EPC control plane on NFV is out
   of our focus in this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
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

--001a11c371c2313fbb04e14152b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-family:arial,sans-serif;font-size:13px"=
>Hi,</div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></=
div><div style=3D"font-family:arial,sans-serif;font-size:13px">We have subm=
itted an I-D for mobile core user-plane which adopts routing basis architec=
ture instead of tunnel centric one. This draft =A0hasn&#39;t been mentioned=
 the nsc stuff yet. But I think that the routing based architecture for use=
r-plane of mobile core fits to service chaining in routing basis very much.=
 Your comments, or advises to this architecture in the nsc point of view ar=
e welcome.</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">Regards,</div><div sty=
le=3D"font-family:arial,sans-serif;font-size:13px">--satoru</div><div style=
=3D"font-family:arial,sans-serif;font-size:13px">
<br></div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></=
div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div><d=
iv class=3D"gmail_quote" style=3D"font-family:arial,sans-serif;font-size:13=
px">
---------- Forwarded message ----------<br>From:=A0<b class=3D"gmail_sender=
name"></b><span dir=3D"ltr">&lt;<a href=3D"mailto:internet-drafts@ietf.org"=
 target=3D"_blank">internet-drafts@ietf.org</a>&gt;</span><br>Date: Thu, Ju=
l 11, 2013 at 1:09 AM<br>
Subject: I-D Action: draft-matsushima-stateless-uplane-vepc-00.txt<br>To:=
=A0<a href=3D"mailto:i-d-announce@ietf.org" target=3D"_blank">i-d-announce@=
ietf.org</a><br><br><br><br>A New Internet-Draft is available from the on-l=
ine Internet-Drafts directories.<br>
<br><br>=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Stateless user-plane ar=
chitecture for virtualized EPC (vEPC)<br>=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =
=A0 : Satoru Matsushima<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 Ryuji Wakikawa<br>=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-matsu=
shima-stateless-uplane-vepc-00.txt<br>
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19<br>=A0 =A0 =A0 =A0 Date =A0 =
=A0 =A0 =A0 =A0 =A0: 2013-07-10<br><br>Abstract:<br>=A0 =A0We envision a ne=
w mobile architecture for the future Evolved Packet<br>=A0 =A0Core (EPC). =
=A0The new architecture is designed to support the<br>
=A0 =A0virtualization scheme called NFV (Network Function Virtualization).<=
br>=A0 =A0In our architecture, the user plane of EPC is decoupled from the<=
br>=A0 =A0control-plane and uses routing information to forward packets of<=
br>=A0 =A0mobile nodes. =A0Although the EPC control plane will run on hyper=
visor,<br>
=A0 =A0our proposal does not modify the signaling of the EPC control plane.=
<br>=A0 =A0The benefits of our architecture are 1) scalability, 2) flexibil=
ity<br>=A0 =A0and 3) Manageability. =A0How to run the EPC control plane on =
NFV is out<br>
=A0 =A0of our focus in this document.<br><br><br>The IETF datatracker statu=
s page for this draft is:<br><a href=3D"https://datatracker.ietf.org/doc/dr=
aft-matsushima-stateless-uplane-vepc" target=3D"_blank">https://datatracker=
.ietf.org/doc/draft-matsushima-stateless-uplane-vepc</a><br>
<br>There&#39;s also a htmlized version available at:<br><a href=3D"http://=
tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00" target=3D"_b=
lank">http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00<=
/a><br>
<br><br>Internet-Drafts are also available by anonymous FTP at:<br><a href=
=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp://ftp.ietf.o=
rg/internet-drafts/</a><br><br>____________________________________________=
___<br>
I-D-Announce mailing list<br><a href=3D"mailto:I-D-Announce@ietf.org" targe=
t=3D"_blank">I-D-Announce@ietf.org</a><br><a href=3D"https://www.ietf.org/m=
ailman/listinfo/i-d-announceInternet-Draft" target=3D"_blank">https://www.i=
etf.org/mailman/listinfo/i-d-announce<br>
Internet-Draft</a>=A0directories:=A0<a href=3D"http://www.ietf.org/shadow.h=
tml" target=3D"_blank">http://www.ietf.org/shadow.html</a><br>or=A0<a href=
=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" target=3D"_blank">ftp://ftp.=
ietf.org/ietf/1shadow-sites.txt</a></div>
</div>

--001a11c371c2313fbb04e14152b9--

From linda.dunbar@huawei.com  Thu Jul 11 13:24:36 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B858521F9BDB for <nsc@ietfa.amsl.com>; Thu, 11 Jul 2013 13:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbFeAyCYKIFR for <nsc@ietfa.amsl.com>; Thu, 11 Jul 2013 13:24:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1BCC21F99F9 for <nsc@ietf.org>; Thu, 11 Jul 2013 13:24:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX90589; Thu, 11 Jul 2013 20:24:28 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 21:21:58 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 21:22:34 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 13:22:32 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: New Version draft-dunbar-l4-l7-sc-problem-statement-00.txt
Thread-Index: AQHOfnJPH+Rqk1nyG0a+fu0XQYQRCplf6AzQ
Date: Thu, 11 Jul 2013 20:22:32 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B47212@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.162]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Thomas Narten <narten@us.ibm.com>, Donald Eastlake <d3e3e3@gmail.com>
Subject: [nsc] FW: New Version draft-dunbar-l4-l7-sc-problem-statement-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2013 20:24:37 -0000

V2UgaGF2ZSBzdWJtaXR0ZWQgYW4gSS1EIHRvIGFkZHJlc3MgdW5pcXVlIGNoYWxsZW5nZXMgZmFj
aW5nIEw0LTcgc2VydmljZSBjaGFpbi4gWW91ciBjb21tZW50cy9zdWdnZXN0aW9ucyBmcm9tIHRo
ZSBuc2MgcG9pbnQgb2YgdmlldyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0KTGluZGEgJiBE
b25hbGQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVy
c2RheSwgSnVseSAxMSwgMjAxMyAzOjA4IFBNDQpUbzogTGluZGEgRHVuYmFyOyBEb25hbGQgRWFz
dGxha2U7IERvbmFsZCBFLiBFYXN0bGFrZSAzcmQNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm
aWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLWw0LWw3LXNjLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4
dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kdW5iYXItbDQtbDctc2MtcHJvYmxl
bS1zdGF0ZW1lbnQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExp
bmRhIER1bmJhciBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFt
ZToJIGRyYWZ0LWR1bmJhci1sNC1sNy1zYy1wcm9ibGVtLXN0YXRlbWVudA0KUmV2aXNpb246CSAw
MA0KVGl0bGU6CQkgTGF5ZXIgNC03IFNlcnZpY2UgQ2hhaW4gcHJvYmxlbSBzdGF0ZW1lbnQNCkNy
ZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTExDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N
Ck51bWJlciBvZiBwYWdlczogMTYNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHVuYmFyLWw0LWw3LXNjLXByb2JsZW0tc3RhdGVtZW50
LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWR1bmJhci1sNC1sNy1zYy1wcm9ibGVtLXN0YXRlbWVudA0KSHRtbGl6ZWQ6ICAgICAg
ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItbDQtbDctc2MtcHJvYmxl
bS1zdGF0ZW1lbnQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgYW5hbHl6ZXMgdGhl
IHRheG9ub215IG9mIExheWVyIDQtNyBTZXJ2aWNlcyBhbmQgZ2l2ZXMNCiAgIHR3byBleGFtcGxl
cyBvZiBMYXllciA0LTcgc2VydmljZSBjaGFpbiwgb25lIGZyb20gYSB0cmFmZmljDQogICBzdGVl
cmluZyBwZXJzcGVjdGl2ZSBhbmQgYW5vdGhlciBvbmUgZnJvbSBhIExheWVyIDcgcGVyc3BlY3Rp
dmUuDQogICBUaGUgaW50ZW50IGlzIHRvIGVtcGhhc2l6ZSB0aGVpciB1bmlxdWUgaXNzdWVzIGFu
ZCBjaGFsbGVuZ2VzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU
RiBTZWNyZXRhcmlhdA0KDQo=

From hadi@mojatatu.com  Mon Jul 15 05:27:56 2013
Return-Path: <hadi@mojatatu.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE02721F9021 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 05:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.943
X-Spam-Level: 
X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rKCuoBfXbso for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 05:27:52 -0700 (PDT)
Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id A340321F9048 for <nsc@ietf.org>; Mon, 15 Jul 2013 05:27:47 -0700 (PDT)
Received: by mail-ve0-f181.google.com with SMTP id db10so9869561veb.12 for <nsc@ietf.org>; Mon, 15 Jul 2013 05:27:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=cuCv88HgW3TENN7sTY6+Pc3dF7q6EXKWdpBqltaL6mc=; b=gxH9yOjMTl4YkBYzPYJHzKUEDbQetDbWXljrIMec5o02Z1AasS0HQ6fYd+XQY6a9YI V5vcrxzC2WFpwaTrmncvGaUwe1tg4v91h4eaO0g/6CdST8j4BfGBacinn0uU1b73N7Jx vaTHwfLcbv35ahkzdzbYmeqyo0VcC0ukw+G7fU6OzYvTwZMX/88N6eCm6z+TzdpXmhkD KLBOkXgGn/Cfu7iE3spAMT/QwC/v1lbcAkkesA2bcwZ9COWnFXV/zk00Ifo9SZJukxlg LN+BZen43tf+s968p3HTTEIu517x9mxlLB41YRVkxAsbC4uJER+qlExdu3dLbYNcqR9r 1JMA==
X-Received: by 10.52.94.45 with SMTP id cz13mr24422589vdb.9.1373891255426; Mon, 15 Jul 2013 05:27:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.247.197 with HTTP; Mon, 15 Jul 2013 05:27:15 -0700 (PDT)
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Mon, 15 Jul 2013 08:27:15 -0400
Message-ID: <CAAFAkD_vHveUeW6nN=qkypr+3v+u5ZdQ+0NpdMU+XqiJMNFY2w@mail.gmail.com>
To: nsc@ietf.org
Content-Type: multipart/alternative; boundary=bcaec50162d13d697104e18bfc6e
X-Gm-Message-State: ALoCoQkQmT5VJPUa5NlHhawaILMm7o3pUu7dS9tQTjoWHJljCwNo3O/Csy36A8w0wJduVqzRJQW6
Cc: Joel Halpern <jmh@joelhalpern.com>, dj@verizon.com
Subject: [nsc] comments on draft-quinn-nsc-problem-statement
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 12:27:56 -0000

--bcaec50162d13d697104e18bfc6e
Content-Type: text/plain; charset=ISO-8859-1

I apologize if this draft (seeing it is version 1)
was discussed on the list and i missed it.

Main comment:
You left out ForCES. ForCES charter talks about an inter-FE
connectivity which requires us to pass metadata along with packet
data which is very applicable.
Although it doesnt make the applicability case for your basic
requirements (that would need to be a different document), please
refer to this draft:
https://www.ietf.org/id/draft-joachimpillai-forces-interfelfb-02.txt

cheers,
jamal

--bcaec50162d13d697104e18bfc6e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>I apologize if this draft (seeing it is ver=
sion 1)<div>was discussed on the list and i missed it.<div><br><div>Main co=
mment:</div><div>You left out ForCES. ForCES charter talks about an inter-F=
E</div>

<div>connectivity which requires us to pass metadata along with packet</div=
></div><div>data which is very applicable.</div><div>Although it doesnt mak=
e the applicability case for your basic</div><div>requirements (that would =
need to be a different document), please</div>

<div>refer to this draft:</div><div><a href=3D"https://www.ietf.org/id/draf=
t-joachimpillai-forces-interfelfb-02.txt">https://www.ietf.org/id/draft-joa=
chimpillai-forces-interfelfb-02.txt</a><br></div><div><br></div><div>cheers=
,</div>

<div>jamal</div></div></div>

--bcaec50162d13d697104e18bfc6e--

From mn1921@att.com  Mon Jul 15 08:24:12 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA6421E80C0 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5tn22KfZCQj for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:24:07 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0359211E80FB for <nsc@ietf.org>; Mon, 15 Jul 2013 08:23:40 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id cf314e15.0.1944095.00-411.5361229.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 15:23:41 +0000 (UTC)
X-MXL-Hash: 51e413fd3af80cb0-83486e4389d3341145301113ea552c336f147a34
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FFNdVU012612; Mon, 15 Jul 2013 11:23:40 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FFNW1K012499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 11:23:37 -0400
Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 15 Jul 2013 15:23:20 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 11:23:20 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "'Thomas Narten'" <narten@us.ibm.com>
Thread-Topic: RE:  [nsc] Comments on draft-quinn-nsh-00 
Thread-Index: Ac6BbvX6D9IjzqAtTXmJbuDZa8Rd+Q==
Date: Mon, 15 Jul 2013 15:23:20 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.118.216]
Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01202B3BMISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=esxoOPVX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=kkgtkFppdtMA:10 a=Cf-jDbmM-UQA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HqxhTrMpf]
X-AnalysisOut: [q0A:10 a=VnNF1IyMAAAA:8 a=2clOPd4PAAAA:8 a=48vgC7mUAAAA:8 ]
X-AnalysisOut: [a=DR_9I_piAAAA:8 a=diqZG_NLcTF1tQojutsA:9 a=CjuIK1q_8ugA:1]
X-AnalysisOut: [0 a=ZF8ZrD0BOmYA:10 a=kkUMZHjH4KkA:10 a=_W_S_7VecoQA:10 a=]
X-AnalysisOut: [frz4AuCg-hUA:10 a=9xBua3jYNkdif-Zx:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 15:24:12 -0000

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01202B3BMISOUT7MSGUSR9I_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

-       Is it necessary to have a new header that identifies a service (cal=
led Base Header in the draft)? Base Header implies new forwarding paradigm =
on the edge. In my opinion using MPLS labels to identify a service chain an=
d a specific service will do the job.
-       Having a Global service chain identifier (called Service Path which=
 is a part of Base Header) might not be a good idea. It will make service c=
haining less flexible. MPLS labels, on the other hand, have only local sign=
ificance.
-       Having a fixed size Metadata might be too limiting. I believe we ne=
ed to structure it such that it is extensible.

Maria
[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_1D70D757A2C9D54D83B4CBD7625FA80E01202B3BMISOUT7MSGUSR9I_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">
<div>Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN"><u>narten at=
 us.ibm.com</u></a>&gt; writes:</div>
<div>&nbsp;</div>
<div>&gt; IMO, discussions about how best to encode stuff is a tad prematur=
e. We</div>
<div>&gt; should focus discussion on whether some item of information needs=
 to</div>
<div>&gt; be included in a packet or not, and the motivation/pros/cons of d=
oing that.</div>
<div>&nbsp;</div>
<div>I agree. I have three comments that fall in this category:</div>
<div>&nbsp;</div>
<ul style=3D"margin:0;padding-left:36pt;">
<li>Is it necessary to have a new header that identifies a service (called =
Base Header in the draft)? Base Header implies new forwarding paradigm on t=
he edge. In my opinion using MPLS labels to identify a service chain and a =
specific service will do the job.</li><li>Having a Global service chain ide=
ntifier (called Service Path which is a part of Base Header) might not be a=
 good idea. It will make service chaining less flexible. MPLS labels, on th=
e other hand, have only local significance.</li><li>Having a fixed size Met=
adata might be too limiting. I believe we need to structure it such that it=
 is extensible.</li></ul>
<div>&nbsp;</div>
<div>Maria</div>
<div><font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;"><img=
 width=3D"83" height=3D"41" src=3D"rtfimage://"></span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; -----Original =
Message-----</span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; From: Thomas N=
arten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN"><u>narten at us.ibm.com</=
u></a>&gt; </span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; To: Robert Ras=
zuk &lt;<a href=3D"mailto:robert@DOMAIN.HIDDEN"><u>robert at raszuk.net</u>=
</a>&gt; </span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; Cc: &lt;<a hre=
f=3D"mailto:nsc@DOMAIN.HIDDEN"><u>nsc at ietf.org</u></a>&gt; </span></font=
></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; Date: Thu, 27 =
Jun 2013 09:29:56 -0400 </span></font></div>
<div>&nbsp;</div>
<div>Robert Raszuk &lt;robert at raszuk.net&gt; writes:</div>
<div>&nbsp;</div>
<div>&gt; I have a basic question reg Network Service Header draft.</div>
<div>&nbsp;</div>
<div>&gt; Don't we already have sufficient room in v6 header (including it'=
s</div>
<div>&gt; extension header) to embed services in it ? Do we need to invent =
new</div>
<div>&gt; header each time someone proposes a new approach ;) ?</div>
<div>&nbsp;</div>
<div>IMO, discussions about how best to encode stuff is a tad premature. We=
</div>
<div>should focus discussion on whether some item of information needs to</=
div>
<div>be included in a packet or not, and the motivation/pros/cons of doing =
that.</div>
<div>&nbsp;</div>
<div>&gt; Just like we can get service discovery accomplished for free when=
 we</div>
<div>&gt; embed service in its reachability advertisement:</div>
<div>&gt; <a href=3D"http://telematics.tm.kit.edu/publications/Files/491/ip=
v6-app-contest-2011-paper.pdf"><font color=3D"blue"><u>http://telematics.tm=
.kit.edu/publications/Files/491/ipv6-app-contest-2011-paper.pdf</u></font><=
/a></div>
<div>&nbsp;</div>
<div>&quot;service discovery for free&quot; is an oxymoron. There are a ton=
 of</div>
<div>reasons why the above proposal is not a good idea. Encoding additional=
</div>
<div>semantics into IP addresses is fraught with difficulties, and except</=
div>
<div>in very limited situations, the IETF has not been willing to do so.</d=
iv>
<div>&nbsp;</div>
<div>Thomas</div>
<div>&nbsp;</div>
<div><font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">&nbs=
p;</span></font></div>
<div><font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">&nbs=
p;</span></font></div>
</span></font>
</body>
</html>

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01202B3BMISOUT7MSGUSR9I_--

From seungiklee@gmail.com  Mon Jul 15 08:29:44 2013
Return-Path: <seungiklee@gmail.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF1E11E811E for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level: 
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc0ADLmykUp6 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:29:44 -0700 (PDT)
Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5E11E80FB for <nsc@ietf.org>; Mon, 15 Jul 2013 08:29:43 -0700 (PDT)
Received: by mail-qe0-f45.google.com with SMTP id w7so6548037qeb.18 for <nsc@ietf.org>; Mon, 15 Jul 2013 08:29:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=Ik68vrPDD80Nb9QG6vYQNzx7JLvsAWHLgDBr+hfvOsU=; b=m95kEooJ8zspC8TsLcTZO7ekXD0XWFXqyADPlUTx9M1LLCLcPHNW9kSq1AnpCAm3JX EZc6jwAozY2wV1QUEzVjrg97efySelcMttlXvUCw1QK2C/l21T8zgbA3CpX49koD5+5P +ghz+KQdEOkvgmWg4jRSqIzG23lSMzOPo7Ai/sc6m+Y86/Ki3B58fnT0VWE3TRJZ4T0c 6d/r4/989Yq9smtLLNnLQ0OIn7U4AcWVv9hrvMSUdrpNp/CpLb1Mxgyu5bvBjVoQFFec cZ4pUxDVd0VCP85P8/BarD0kLmLA46nG9dlw4x2QxPV5yu+HeswGnQUaCA5waIpa1nHj ck2g==
X-Received: by 10.224.168.14 with SMTP id s14mr52061031qay.91.1373902183281; Mon, 15 Jul 2013 08:29:43 -0700 (PDT)
MIME-Version: 1.0
Sender: seungiklee@gmail.com
Received: by 10.49.26.106 with HTTP; Mon, 15 Jul 2013 08:29:23 -0700 (PDT)
In-Reply-To: <20130715152326.5661.78824.idtracker@ietfa.amsl.com>
References: <20130715152326.5661.78824.idtracker@ietfa.amsl.com>
From: Seung-Ik Lee <seungiklee@etri.re.kr>
Date: Tue, 16 Jul 2013 00:29:23 +0900
X-Google-Sender-Auth: KDbBZ6fBTcw8-DaIUYOzHJ7447M
Message-ID: <CAHMWmA8vNm3PB+jW02SE3ukC-RkOHqxWU1y-YM=aARegdqq5Ww@mail.gmail.com>
To: nsc@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [nsc] Fwd: New Version Notification for draft-lee-nsc-verification-problem-statement-01.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 15:29:44 -0000

FYI,

We have submitted an I-D to address the problem of service chain
conflicts with a verification method.
Your comments are appreciated.

Thanks.

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: 2013/7/16
Subject: New Version Notification for
draft-lee-nsc-verification-problem-statement-01.txt
To: Myung-Ki Shin <mkshin@etri.re.kr>, Yoon-Chul Choi
<cyc79@etri.re.kr>, Seung-Ik Lee <seungiklee@etri.re.kr>




A new version of I-D, draft-lee-nsc-verification-problem-statement-01.txt
has been successfully submitted by Seung-Ik Lee and posted to the
IETF repository.

Filename:        draft-lee-nsc-verification-problem-statement
Revision:        01
Title:           Problem statement for Verification of Network Service Chai=
ns
Creation date:   2013-07-15
Group:           Individual Submission
Number of pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-lee-nsc-verification-problem-stat=
ement-01.txt
Status:
http://datatracker.ietf.org/doc/draft-lee-nsc-verification-problem-statemen=
t
Htmlized:
http://tools.ietf.org/html/draft-lee-nsc-verification-problem-statement-01
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-lee-nsc-verification-problem-state=
ment-01

Abstract:
   This document addresses the possible conflicts between service
   overlays in the network service chaining.  These conflicts are due to
   overlapping in classification rules and resource sharing of service
   overlays.  The verification of service chains provides a method for
   network administrators to detect such conflicts and correct a
   problematic service chain before applying it on the real network.




The IETF Secretariat



--=20
Seung-Ik Lee (=EC=9D=B4=EC=8A=B9=EC=9D=B5)
Protocol Engineering Center, ETRI
Tel.    +82-42-860-1483
Fax.   +82-42-861-5404
Email. seungiklee@etri.re.kr; seungiklee@gmail.com

From Ron_Parker@affirmednetworks.com  Mon Jul 15 08:33:16 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B204E21E80B2 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkG8P-XZOJLM for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:33:12 -0700 (PDT)
Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 74FFC21E80AC for <nsc@ietf.org>; Mon, 15 Jul 2013 08:33:12 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 08:33:11 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, 'Thomas Narten' <narten@us.ibm.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: Ac6BbvX6D9IjzqAtTXmJbuDZa8Rd+QAAQI2w
Date: Mon, 15 Jul 2013 15:33:10 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.150.224]
Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674CEEMBX021W3CA2exch_"
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 15:33:16 -0000

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674CEEMBX021W3CA2exch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discu=
ssed ahead of the actual content.    One important input to that discussion=
 is whether MPLS is a requirement for Network Service Chaining, or if Netwo=
rk Service Chaining merely requires IP connectivity amongst the network fun=
ctions.   Another input to the discussion is whether the chain describes (e=
.g., via MPLS label(s) and/or IP-level encapsulation) merely the identity o=
f the sequence of network functions, or also suggests a per-network-functio=
n policy set to be applied (that is, additional value provided by the orche=
strator).

   Ron Parker
   Affirmed Networks


From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of NAPIE=
RALA, MARIA H
Sent: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten'
Cc: nsc@ietf.org; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

*         Is it necessary to have a new header that identifies a service (c=
alled Base Header in the draft)? Base Header implies new forwarding paradig=
m on the edge. In my opinion using MPLS labels to identify a service chain =
and a specific service will do the job.
*         Having a Global service chain identifier (called Service Path whi=
ch is a part of Base Header) might not be a good idea. It will make service=
 chaining less flexible. MPLS labels, on the other hand, have only local si=
gnificance.
*         Having a fixed size Metadata might be too limiting. I believe we =
need to structure it such that it is extensible.

Maria
[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674CEEMBX021W3CA2exch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1612932826;
	mso-list-template-ids:-404449142;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that the pros/con=
s of a new IP-level encapsulation need to be discussed ahead of the actual =
content.&nbsp;&nbsp;&nbsp; One important input to that discussion is whethe=
r
 MPLS is a requirement for Network Service Chaining, or if Network Service =
Chaining merely requires IP connectivity amongst the network functions.&nbs=
p;&nbsp; Another input to the discussion is whether the chain describes (e.=
g., via MPLS label(s) and/or IP-level encapsulation)
 merely the identity of the sequence of network functions, or also suggests=
 a per-network-function policy set to be applied (that is, additional value=
 provided by the orchestrator).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron Parker<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Affirmed Net=
works<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> nsc-bo=
unces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>NAPIERALA, MARIA H<br>
<b>Sent:</b> Monday, July 15, 2013 11:23 AM<br>
<b>To:</b> 'Thomas Narten'<br>
<b>Cc:</b> nsc@ietf.org; Robert Raszuk<br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN">=
narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; IMO, discussions about how best to encode stuff is a =
tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; should focus discussion on whether some item of infor=
mation needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; be included in a packet or not, and the motivation/pr=
os/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">I agree. I have three comments that fall in this category:=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol"><s=
pan style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times=
 New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:10.0pt;font-family:=
&quot;Courier New&quot;">Is it necessary to have a new header that identifi=
es a service (called Base Header in the draft)? Base Header implies new for=
warding paradigm on the edge. In my opinion
 using MPLS labels to identify a service chain and a specific service will =
do the job.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol"><s=
pan style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times=
 New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:10.0pt;font-family:=
&quot;Courier New&quot;">Having a Global service chain identifier (called S=
ervice Path which is a part of Base Header) might not be a good idea. It wi=
ll make service chaining less flexible. MPLS
 labels, on the other hand, have only local significance.<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol"><s=
pan style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times=
 New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:10.0pt;font-family:=
&quot;Courier New&quot;">Having a fixed size Metadata might be too limiting=
. I believe we need to structure it such that it is extensible.<o:p></o:p><=
/span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Maria<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><img border=3D"0" width=3D"83" height=
=3D"41" id=3D"_x0000_i1025" src=3D"rtfimage://"></span><span style=3D"font-=
size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; -----Original Message-----</span><span style=3D"font-=
size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; From: Thomas Narten &lt;<a href=3D"mailto:narten@DOMA=
IN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:robert@DOMAIN=
.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDDEN">nsc at i=
etf.org</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Robert Raszuk &lt;robert at raszuk.net&gt; writes:<o:p></o=
:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; I have a basic question reg Network Service Header dr=
aft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Don't we already have sufficient room in v6 header (i=
ncluding it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; extension header) to embed services in it ? Do we nee=
d to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; header each time someone proposes a new approach ;) ?=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">IMO, discussions about how best to encode stuff is a tad p=
remature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">should focus discussion on whether some item of informatio=
n needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">be included in a packet or not, and the motivation/pros/co=
ns of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Just like we can get service discovery accomplished f=
or free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; embed service in its reachability advertisement:<o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; <a href=3D"http://telematics.tm.kit.edu/publications/=
Files/491/ipv6-app-contest-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&quot;service discovery for free&quot; is an oxymoron. The=
re are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">reasons why the above proposal is not a good idea. Encodin=
g additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">semantics into IP addresses is fraught with difficulties, =
and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">in very limited situations, the IETF has not been willing =
to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674CEEMBX021W3CA2exch_--

From Ron_Parker@affirmednetworks.com  Mon Jul 15 08:47:43 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5705021E80AA for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3AH43eimQxt for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:47:32 -0700 (PDT)
Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id A822721F9E0A for <nsc@ietf.org>; Mon, 15 Jul 2013 08:47:31 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 08:47:31 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: Seung-Ik Lee <seungiklee@etri.re.kr>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Fwd: New Version Notification for draft-lee-nsc-verification-problem-statement-01.txt
Thread-Index: AQHOgXAmTsAQrTh1x0CaaQEO9HtCfZll4IAw
Date: Mon, 15 Jul 2013 15:47:31 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A674D1F@MBX021-W3-CA-2.exch021.domain.local>
References: <20130715152326.5661.78824.idtracker@ietfa.amsl.com> <CAHMWmA8vNm3PB+jW02SE3ukC-RkOHqxWU1y-YM=aARegdqq5Ww@mail.gmail.com>
In-Reply-To: <CAHMWmA8vNm3PB+jW02SE3ukC-RkOHqxWU1y-YM=aARegdqq5Ww@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.150.224]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [nsc] Fwd: New Version Notification for	draft-lee-nsc-verification-problem-statement-01.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 15:47:43 -0000

U2V1bmctSWssIGV0IGFsLCANCg0KVGhhbmtzIGZvciBjb250cmlidXRpbmcgb24gdGhpcyB0b3Bp
Yy4NCg0KSWYgSSByZWFkIHRoaXMgY29ycmVjdGx5LCB5b3UgYXJlIGludGVyZXN0ZWQgaW4gaWRl
bnRpZnlpbmcgdGhlIG51bWJlciBvZiBydWxlcyB0aGF0IHNwZWNpZnkgYSBwYXJ0aWN1bGFyIG5l
dHdvcmsgZnVuY3Rpb24gaW5zdGFuY2UuICAgT25lIHJlYXNvbiB0byB3aXNoIHRvIGRvIHRoaXMg
aXMgYmVjYXVzZSB0aGVyZSBtYXkgYmUgbWFueSBzZXJ2aWNlIG9yY2hlc3RyYXRvcnMgaW4gdGhl
IG5ldHdvcmsuICAgRG8gSSBoYXZlIHRoaXMgY29ycmVjdD8NCg0KV2hpbGUgaXQgaXMgaW5mb3Jt
YXRpdmUgdG8ga25vdyBob3cgbWFueSBydWxlcywgbmV0d29yayB3aWRlLCBzZWxlY3QgYSBwYXJ0
aWN1bGFyIG5ldHdvcmsgZnVuY3Rpb24gaW5zdGFuY2UsIGl0IHdvdWxkIGFsc28gYmUgaW5mb3Jt
YXRpdmUgdG8ga25vdyB0aGUgYWN0dWFsIHByb2Nlc3NpbmcgbG9hZCBvbiB0aGF0IG5ldHdvcmsg
ZnVuY3Rpb24gaW5zdGFuY2UuICAgVGhlIGV4aXN0ZW5jZSBvZiBhIHJ1bGUgZG9lc24ndCBpbXBs
eSB0aGF0IHRoZSBydWxlIGlzIGJlaW5nIGV4ZWN1dGVkIHdpdGggYW55IHBhcnRpY3VsYXIgZnJl
cXVlbmN5Lg0KDQpBbHNvLCBpbiB5b3VyIHByb3Bvc2FsLCBob3cgZG9lcyB0aGUgbmV0d29yayBm
dW5jdGlvbiBpbnN0YW5jZSBkaXNjb3ZlciB0aGF0IGl0IGlzIHJlZmVyZW5jZWQgYnkgYSBydWxl
PyAgIEFuZCBjb252ZXJzZWx5LCBob3cgZG9lcyBpdCBkaXNjb3ZlciB0aGF0IHRoZSByZWZlcmVu
Y2UgaXMgbm8gbG9uZ2VyIHZhbGlkPyAgIEFyZSB0aGVyZSBjb250cm9sIHBsYW5lIHJlcXVpcmVt
ZW50cyBoZXJlPw0KDQpUaGFua3MuDQoNCiAgIFJvbiBQYXJrZXINCiAgIEFmZmlybWVkIE5ldHdv
cmtzDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5zYy1ib3VuY2VzQGll
dGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTZXVuZy1J
ayBMZWUNClNlbnQ6IE1vbmRheSwgSnVseSAxNSwgMjAxMyAxMToyOSBBTQ0KVG86IG5zY0BpZXRm
Lm9yZw0KU3ViamVjdDogW25zY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy
YWZ0LWxlZS1uc2MtdmVyaWZpY2F0aW9uLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dA0KDQpGWUks
DQoNCldlIGhhdmUgc3VibWl0dGVkIGFuIEktRCB0byBhZGRyZXNzIHRoZSBwcm9ibGVtIG9mIHNl
cnZpY2UgY2hhaW4gY29uZmxpY3RzIHdpdGggYSB2ZXJpZmljYXRpb24gbWV0aG9kLg0KWW91ciBj
b21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcy4NCg0KLS0tLS0tLS0tLSBGb3J3YXJk
ZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiAgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4N
CkRhdGU6IDIwMTMvNy8xNg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0K
ZHJhZnQtbGVlLW5zYy12ZXJpZmljYXRpb24tcHJvYmxlbS1zdGF0ZW1lbnQtMDEudHh0DQpUbzog
TXl1bmctS2kgU2hpbiA8bWtzaGluQGV0cmkucmUua3I+LCBZb29uLUNodWwgQ2hvaSA8Y3ljNzlA
ZXRyaS5yZS5rcj4sIFNldW5nLUlrIExlZSA8c2V1bmdpa2xlZUBldHJpLnJlLmtyPg0KDQoNCg0K
DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGVlLW5zYy12ZXJpZmljYXRpb24tcHJvYmxl
bS1zdGF0ZW1lbnQtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNl
dW5nLUlrIExlZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1l
OiAgICAgICAgZHJhZnQtbGVlLW5zYy12ZXJpZmljYXRpb24tcHJvYmxlbS1zdGF0ZW1lbnQNClJl
dmlzaW9uOiAgICAgICAgMDENClRpdGxlOiAgICAgICAgICAgUHJvYmxlbSBzdGF0ZW1lbnQgZm9y
IFZlcmlmaWNhdGlvbiBvZiBOZXR3b3JrIFNlcnZpY2UgQ2hhaW5zDQpDcmVhdGlvbiBkYXRlOiAg
IDIwMTMtMDctMTUNCkdyb3VwOiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1i
ZXIgb2YgcGFnZXM6IDUNClVSTDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWxlZS1uc2MtdmVyaWZpY2F0aW9uLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dA0KU3Rh
dHVzOg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZWUtbnNjLXZlcmlm
aWNhdGlvbi1wcm9ibGVtLXN0YXRlbWVudA0KSHRtbGl6ZWQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1sZWUtbnNjLXZlcmlmaWNhdGlvbi1wcm9ibGVtLXN0YXRlbWVudC0wMQ0K
RGlmZjoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxlZS1uc2MtdmVy
aWZpY2F0aW9uLXByb2JsZW0tc3RhdGVtZW50LTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1
bWVudCBhZGRyZXNzZXMgdGhlIHBvc3NpYmxlIGNvbmZsaWN0cyBiZXR3ZWVuIHNlcnZpY2UNCiAg
IG92ZXJsYXlzIGluIHRoZSBuZXR3b3JrIHNlcnZpY2UgY2hhaW5pbmcuICBUaGVzZSBjb25mbGlj
dHMgYXJlIGR1ZSB0bw0KICAgb3ZlcmxhcHBpbmcgaW4gY2xhc3NpZmljYXRpb24gcnVsZXMgYW5k
IHJlc291cmNlIHNoYXJpbmcgb2Ygc2VydmljZQ0KICAgb3ZlcmxheXMuICBUaGUgdmVyaWZpY2F0
aW9uIG9mIHNlcnZpY2UgY2hhaW5zIHByb3ZpZGVzIGEgbWV0aG9kIGZvcg0KICAgbmV0d29yayBh
ZG1pbmlzdHJhdG9ycyB0byBkZXRlY3Qgc3VjaCBjb25mbGljdHMgYW5kIGNvcnJlY3QgYQ0KICAg
cHJvYmxlbWF0aWMgc2VydmljZSBjaGFpbiBiZWZvcmUgYXBwbHlpbmcgaXQgb24gdGhlIHJlYWwg
bmV0d29yay4NCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCi0tDQpTZXVuZy1J
ayBMZWUgKOydtOyKueydtSkNClByb3RvY29sIEVuZ2luZWVyaW5nIENlbnRlciwgRVRSSQ0KVGVs
LiAgICArODItNDItODYwLTE0ODMNCkZheC4gICArODItNDItODYxLTU0MDQNCkVtYWlsLiBzZXVu
Z2lrbGVlQGV0cmkucmUua3I7IHNldW5naWtsZWVAZ21haWwuY29tIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuc2MgbWFpbGluZyBsaXN0DQpuc2NAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo=

From paulq@cisco.com  Mon Jul 15 08:52:13 2013
Return-Path: <paulq@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295EB11E8105 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfywlV+KrWIz for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:52:08 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B131821E80BC for <nsc@ietf.org>; Mon, 15 Jul 2013 08:52:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1573; q=dns/txt; s=iport; t=1373903523; x=1375113123; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=7r0xXp7WJBas8WGMoNUfLedM1TbapbunH7/e26x6P2c=; b=dAe6zhZhARHQ7qyL1ERaPLZ2A1E0PGrRgljEoHZ6QNxPq+fekfIL/o4j 2XDocaK8UwdnEC5H72spFZVRHsjetCNjLTstfvm/NklujR9SKPzbNOh1B TvGgph/ezNjmRmADS5M9t9xMcA6GWrnh7skcczeUZArUoA5YsAFPGKPNC Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAL8Z5FGrRDoH/2dsb2JhbABagwY0ScJrFnSCIwEBAQMBOisSElFNCgYciAEFCAW1UZJ2bQOJJ441gSmQJIMyHA
X-IronPort-AV: E=Sophos;i="4.89,669,1367971200"; d="scan'208";a="83554151"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 15 Jul 2013 15:52:00 +0000
Received: from sjc-paquinn-8714.cisco.com (sjc-paquinn-8714.cisco.com [10.19.172.245]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6FFpwfX024291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <nsc@ietf.org>; Mon, 15 Jul 2013 15:51:58 GMT
From: Paul Quinn <paulq@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 15 Jul 2013 08:51:58 -0700
References: <20130713152129.4108.27453.idtracker@ietfa.amsl.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Message-Id: <A82DB6C5-92E0-4C14-87AC-CA0D30A95DA4@cisco.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [nsc] Fwd: New Version Notification for draft-quinn-nsc-problem-statement-01.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 15:52:13 -0000

Hello,

A new version of the draft was submitted:

- Incorporated comments from reviewers
- Updated author list

Thanks
Paul


>=20
> A new version of I-D, draft-quinn-nsc-problem-statement-01.txt
> has been successfully submitted by Paul Quinn and posted to the
> IETF repository.
>=20
> Filename:	 draft-quinn-nsc-problem-statement
> Revision:	 01
> Title:		 Network Service Chaining Problem Statement
> Creation date:	 2013-07-13
> Group:		 Individual Submission
> Number of pages: 16
> URL:             =
http://www.ietf.org/internet-drafts/draft-quinn-nsc-problem-statement-01.t=
xt
> Status:          =
http://datatracker.ietf.org/doc/draft-quinn-nsc-problem-statement
> Htmlized:        =
http://tools.ietf.org/html/draft-quinn-nsc-problem-statement-01
> Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-nsc-problem-statement-01
>=20
> Abstract:
>   This document provides an overview of the issues associated with the
>   deployment of network services functions (such as firewalls, load
>   balancers) in large-scale environments.  The term service chaining =
is
>   used to describe the deployment of such services, and the ability of
>   a network operator to specify an ordered list of services that =
should
>   be applied to a deterministic set of traffic flows.  Such service
>   chains require integration of service policy alongside the =
deployment
>   of applications, while allowing for the optimal utilization of
>   network resources.
>=20
>=20
>=20
>=20
> The IETF Secretariat
>=20


From paulq@cisco.com  Mon Jul 15 08:54:00 2013
Return-Path: <paulq@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E7C21E80BB for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krKUVNIGLnYd for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 08:53:55 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BE8C311E8173 for <nsc@ietf.org>; Mon, 15 Jul 2013 08:53:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1032; q=dns/txt; s=iport; t=1373903613; x=1375113213; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=i1eaV4n44Pw4qABhDXASgoVJZaYwkCVChA13x59TgMw=; b=Oa/+Wi1TqG0QesSFcM/Y13MSfDzqGfwptC4oiCQN0LzKdBfKKQeUJotB xMUtA8r1iMM21t7lZn3VtT0NDeJjBALcjWdu/pyk1jPUm1zoLe/PQqu+1 YDYBxEJfTEjMXfdkd7JN/tmUfmkPPZLecKZVbJ9pTZjlsAre/mGjJseYK 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAL8Z5FGrRDoJ/2dsb2JhbABagwY0SYJFwCYWdIIjAQEBAwE6LRASUU0KBhyIAQUIBbVRknZtA4knjjWBKZAkgzIc
X-IronPort-AV: E=Sophos;i="4.89,669,1367971200"; d="scan'208";a="83045577"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 15 Jul 2013 15:53:32 +0000
Received: from sjc-paquinn-8714.cisco.com (sjc-paquinn-8714.cisco.com [10.19.172.245]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6FFrVNQ026278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <nsc@ietf.org>; Mon, 15 Jul 2013 15:53:31 GMT
From: Paul Quinn <paulq@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 15 Jul 2013 08:53:31 -0700
References: <20130713024614.697.85926.idtracker@ietfa.amsl.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Message-Id: <05BCC23E-070F-4E2F-96B5-1F674EFE2617@cisco.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [nsc] Fwd: New Version Notification for draft-quinn-nsh-01.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 15:54:00 -0000

This new version has been updated with reviewer feedback and new co-authors.

Paul



> 
> A new version of I-D, draft-quinn-nsh-01.txt
> has been successfully submitted by Paul Quinn and posted to the
> IETF repository.
> 
> Filename:	 draft-quinn-nsh
> Revision:	 01
> Title:		 Network Service Header
> Creation date:	 2013-07-12
> Group:		 Individual Submission
> Number of pages: 21
> URL:             http://www.ietf.org/internet-drafts/draft-quinn-nsh-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-quinn-nsh
> Htmlized:        http://tools.ietf.org/html/draft-quinn-nsh-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-quinn-nsh-01
> 
> Abstract:
>   This draft describes a Network Service Header (NSH) that can be added
>   to encapsulated network packets or frames to create network service
>   paths.  In addition to path information, this header also carries
>   metadata used by network devices and/or network services.
> 
> 
> 
> 
> The IETF Secretariat
> 


From jguichar@cisco.com  Mon Jul 15 09:09:27 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44C21E80D4 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 09:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+TjjUrNcLMV for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 09:09:23 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0A11E8166 for <nsc@ietf.org>; Mon, 15 Jul 2013 09:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10946; q=dns/txt; s=iport; t=1373904563; x=1375114163; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ge6/vuJBPSmyggntyza2LLKlR8aOTrPAB6qAi35C5oU=; b=JNRleHleGa3oIiMs/aryHFdoc8PNDGMnUKfkNf7OfQc9M3OiYXlIJv/l DzZTV+j3CoUOwnvgiU/2JWFjKl4fBdzWJlg3BNWkC73qVvAEXrblY+Wax XEC/D0DZup39shvjSm0s4A7ygFW1h3Zumb3cVOs+x8I/bNpBr6vo+jlkD k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlIGAIgd5FGtJXHA/2dsb2JhbABQCoJCRDRPr2SJOIg2gRMWdIIjAQEBAgEBLUwFBwYBCBEDAQILHTkUCQgBAQQBDQUIiAIGDLVgjigEgQcGBxMRBwIEA4MCbQOZBZAkgxKBaEA
X-IronPort-AV: E=Sophos;i="4.89,669,1367971200";  d="scan'208,217";a="234974008"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 15 Jul 2013 16:09:22 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6FG9LPV031657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 16:09:21 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 11:09:21 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "'Thomas Narten'" <narten@us.ibm.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: Ac6BbvX6D9IjzqAtTXmJbuDZa8Rd+QADxRgA
Date: Mon, 15 Jul 2013 16:09:20 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5954D5@xmb-rcd-x01.cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.212]
Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F5954D5xmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 16:09:27 -0000

--_000_68B171751455884590F8E38E96416F363F5954D5xmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Maria,

Thank you for your comments on our draft. Please see inline for responses.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten' <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>=
, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:


  *   Is it necessary to have a new header that identifies a service (calle=
d Base Header in the draft)? Base Header implies new forwarding paradigm on=
 the edge. In my opinion using MPLS labels to identify a service chain and =
a specific service will do the job.

Jim>  it is certainly a true statement that an MPLS label could be used (as=
suming that the network environment supports/deploys MPLS; a large assumpti=
on), as could an IP tunnel, to get packets from point A to point B and at p=
oint B use said label value, or IP tunnel context, to indicate a given serv=
ice function to be applied to the traffic. However, service chaining will r=
equire more than simply a forwarding mechanism between service functions: a=
t a minimum service visibility and information exchange will be key.


  *   Having a Global service chain identifier (called Service Path which i=
s a part of Base Header) might not be a good idea. It will make service cha=
ining less flexible. MPLS labels, on the other hand, have only local signif=
icance.

Jim> could you provide a more detailed description of why service chaining =
would be less flexible if a global service chain identifier is adopted?


Maria
[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_68B171751455884590F8E38E96416F363F5954D5xmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <953D34FCEEB7F54AA8B756FE5F4ABDA9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; font-size: 14px; font-family: Calibri, sans-ser=
if; ">
<div style=3D"color: rgb(0, 0, 0); ">Hi Maria,</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">Thank you for your comments on our dra=
ft. Please see inline for responses.&nbsp;</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&lt;NAPIERALA&gt;, MARIA H &l=
t;<a href=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Monday, July 15, 2013 11:23 A=
M<br>
<span style=3D"font-weight:bold">To: </span>'Thomas Narten' &lt;<a href=3D"=
mailto:narten@us.ibm.com">narten@us.ibm.com</a>&gt;<br>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:nsc@iet=
f.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.=
org</a>&gt;, Robert Raszuk &lt;<a href=3D"mailto:robert@raszuk.net">robert@=
raszuk.net</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [nsc] Comments on draf=
t-quinn-nsh-00<br>
</div>
<div><br>
</div>
<div>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf --><style><!-- .EmailQuote { margin-left: 1pt; padd=
ing-left: 4pt; border-left: #800000 2px solid; } --></style>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">
<div>Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN"><u>narten at=
 us.ibm.com</u></a>&gt; writes:</div>
<div>&nbsp;</div>
<div>&gt; IMO, discussions about how best to encode stuff is a tad prematur=
e. We</div>
<div>&gt; should focus discussion on whether some item of information needs=
 to</div>
<div>&gt; be included in a packet or not, and the motivation/pros/cons of d=
oing that.</div>
<div>&nbsp;</div>
<div>I agree. I have three comments that fall in this category:</div>
<div>&nbsp;</div>
<ul style=3D"margin:0;padding-left:36pt;">
<li>Is it necessary to have a new header that identifies a service (called =
Base Header in the draft)? Base Header implies new forwarding paradigm on t=
he edge. In my opinion using MPLS labels to identify a service chain and a =
specific service will do the job.</li></ul>
</span></font></div>
</div>
</span>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div>Jim&gt; &nbsp;it is certainly a true statement that an MPLS label coul=
d be used (assuming that the network environment supports/deploys MPLS; a l=
arge assumption)<font>, as could an IP tunnel,</font>&nbsp;to get packets f=
rom point A to point B and at point B use said
 label value, or IP tunnel context, to indicate a given service function to=
 be applied to the traffic.&nbsp;However, service chaining&nbsp;will requir=
e&nbsp;more than simply a forwarding mechanism between service functions: a=
t a minimum service visibility and information
 exchange will be key.&nbsp;</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">
<ul style=3D"margin:0;padding-left:36pt;">
<li>Having a Global service chain identifier (called Service Path which is =
a part of Base Header) might not be a good idea. It will make service chain=
ing less flexible. MPLS labels, on the other hand, have only local signific=
ance.</li></ul>
</span></font></div>
</div>
</span>
<div><br>
</div>
<div>Jim&gt;&nbsp;could you provide a more detailed description of why serv=
ice chaining would be less flexible if a global service chain identifier is=
 adopted?&nbsp;</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">
<div><br>
</div>
<div>&nbsp;</div>
<div>Maria</div>
<div><font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;"><img=
 width=3D"83" height=3D"41" src=3D"rtfimage://"></span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; -----Original =
Message-----</span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; From: Thomas N=
arten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN"><u>narten at us.ibm.com</=
u></a>&gt;
</span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; To: Robert Ras=
zuk &lt;<a href=3D"mailto:robert@DOMAIN.HIDDEN"><u>robert at raszuk.net</u>=
</a>&gt;
</span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; Cc: &lt;<a hre=
f=3D"mailto:nsc@DOMAIN.HIDDEN"><u>nsc at ietf.org</u></a>&gt;
</span></font></div>
<div><font size=3D"2"><span style=3D"font-size:10.5pt;">&gt; Date: Thu, 27 =
Jun 2013 09:29:56 -0400
</span></font></div>
<div>&nbsp;</div>
<div>Robert Raszuk &lt;robert at raszuk.net&gt; writes:</div>
<div>&nbsp;</div>
<div>&gt; I have a basic question reg Network Service Header draft.</div>
<div>&nbsp;</div>
<div>&gt; Don't we already have sufficient room in v6 header (including it'=
s</div>
<div>&gt; extension header) to embed services in it ? Do we need to invent =
new</div>
<div>&gt; header each time someone proposes a new approach ;) ?</div>
<div>&nbsp;</div>
<div>IMO, discussions about how best to encode stuff is a tad premature. We=
</div>
<div>should focus discussion on whether some item of information needs to</=
div>
<div>be included in a packet or not, and the motivation/pros/cons of doing =
that.</div>
<div>&nbsp;</div>
<div>&gt; Just like we can get service discovery accomplished for free when=
 we</div>
<div>&gt; embed service in its reachability advertisement:</div>
<div>&gt; <a href=3D"http://telematics.tm.kit.edu/publications/Files/491/ip=
v6-app-contest-2011-paper.pdf">
<font color=3D"blue"><u>http://telematics.tm.kit.edu/publications/Files/491=
/ipv6-app-contest-2011-paper.pdf</u></font></a></div>
<div>&nbsp;</div>
<div>&quot;service discovery for free&quot; is an oxymoron. There are a ton=
 of</div>
<div>reasons why the above proposal is not a good idea. Encoding additional=
</div>
<div>semantics into IP addresses is fraught with difficulties, and except</=
div>
<div>in very limited situations, the IETF has not been willing to do so.</d=
iv>
<div>&nbsp;</div>
<div>Thomas</div>
<div>&nbsp;</div>
<div><font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">&nbs=
p;</span></font></div>
<div><font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">&nbs=
p;</span></font></div>
</span></font></div>
</div>
</span>
</body>
</html>

--_000_68B171751455884590F8E38E96416F363F5954D5xmbrcdx01ciscoc_--

From mn1921@att.com  Mon Jul 15 09:15:49 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4E211E818B for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 09:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTzToiiuS+Ts for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 09:15:43 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 28B3E21E80E2 for <nsc@ietf.org>; Mon, 15 Jul 2013 09:15:30 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 92024e15.2aaac9e02940.4508396.00-522.12505129.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 16:15:37 +0000 (UTC)
X-MXL-Hash: 51e420297ad310e4-c0f75556436a8dccd6faea886cc17a3bfe2dd8e6
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b1024e15.0.4508392.00-235.12504689.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 16:15:24 +0000 (UTC)
X-MXL-Hash: 51e4201c108b69da-c9224a2716e7ffb319df99a8252c9286c9c54227
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FGFN4R013472; Mon, 15 Jul 2013 12:15:23 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FGFCBw013170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 12:15:15 -0400
Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 15 Jul 2013 16:15:02 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 12:15:02 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "'Thomas Narten'" <narten@us.ibm.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: AQHOgXCjirru2EVnp0GQKr6sQClwy5ll4eFA
Date: Mon, 15 Jul 2013 16:15:02 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01202E02@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.118.216]
Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01202E02MISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=R5y076tX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=kkgtkFppdtMA:10 a=BUO9sMsmufgA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HqxhTrMpf]
X-AnalysisOut: [q0A:10 a=qN95wPeSAAAA:8 a=48vgC7mUAAAA:8 a=VnNF1IyMAAAA:8 ]
X-AnalysisOut: [a=2clOPd4PAAAA:8 a=DR_9I_piAAAA:8 a=eDKykiwTQEGebuUwZ78A:9]
X-AnalysisOut: [ a=CjuIK1q_8ugA:10 a=ZF8ZrD0BOmYA:10 a=kkUMZHjH4KkA:10 a=p]
X-AnalysisOut: [aC5pjApGzsA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFE]
X-AnalysisOut: [ACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0]
X-AnalysisOut: [A:10 a=frz4AuCg-hUA:10 a=rgw3e1S8ykOXBJgo:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 16:15:49 -0000

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01202E02MISOUT7MSGUSR9I_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ron,

Please see in-line.

Maria

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 15, 2013 11:33 AM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discu=
ssed ahead of the actual content.
One important input to that discussion is whether MPLS is a requirement for=
 Network Service Chaining, or if Network Service Chaining merely requires I=
P connectivity amongst the
<MN> IP-only connectivity (if I understand you correctly) will require IP f=
low classification at every service hop .

network functions.   Another input to the discussion is whether the chain d=
escribes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely the=
 identity of the sequence of network functions, or also suggests a per-netw=
ork-function policy set to be applied (that is, additional value provided b=
y the orchestrator).

<MN> In my opinion, both.


   Ron Parker
   Affirmed Networks


From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of NAPIERALA, MARIA H
Sent: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

*         Is it necessary to have a new header that identifies a service (c=
alled Base Header in the draft)? Base Header implies new forwarding paradig=
m on the edge. In my opinion using MPLS labels to identify a service chain =
and a specific service will do the job.
*         Having a Global service chain identifier (called Service Path whi=
ch is a part of Base Header) might not be a good idea. It will make service=
 chaining less flexible. MPLS labels, on the other hand, have only local si=
gnificance.
*         Having a fixed size Metadata might be too limiting. I believe we =
need to structure it such that it is extensible.

Maria
[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_1D70D757A2C9D54D83B4CBD7625FA80E01202E02MISOUT7MSGUSR9I_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Please see in-line.<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ron Park=
er [mailto:Ron_Parker@affirmednetworks.com]
<br>
<b>Sent:</b> Monday, July 15, 2013 11:33 AM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> nsc@ietf.org; Robert Raszuk<br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that the pros/con=
s of a new IP-level encapsulation need to be discussed ahead of the actual =
content.&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">One important input to th=
at discussion is whether MPLS is a requirement for Network Service Chaining=
, or if Network Service Chaining merely requires IP connectivity
 amongst the </span><span style=3D"font-size:11.0pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; IP-only connec=
tivity (if I understand you correctly) will require IP flow classification =
at every service hop .
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">network functions.&nbsp;&=
nbsp; Another input to the discussion is whether the chain describes (e.g.,=
 via MPLS label(s) and/or IP-level encapsulation) merely the identity
 of the sequence of network functions, or also suggests a per-network-funct=
ion policy set to be applied (that is, additional value provided by the orc=
hestrator).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; In my opinion,=
 both.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron Parker<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Affirmed Net=
works<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>NAPIERALA, MARIA H<br>
<b>Sent:</b> Monday, July 15, 2013 11:23 AM<br>
<b>To:</b> 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN">=
narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; IMO, discussions about how best to encode stuff is a =
tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; should focus discussion on whether some item of infor=
mation needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; be included in a packet or not, and the motivation/pr=
os/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">I agree. I have three comments that fall in this category:=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Is it necessary to have a new header that identifies a service (called Bas=
e Header in the draft)? Base Header implies new forwarding paradigm on the =
edge. In my opinion using MPLS labels to identify
 a service chain and a specific service will do the job.<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a Global service chain identifier (called Service Path which is a p=
art of Base Header) might not be a good idea. It will make service chaining=
 less flexible. MPLS labels, on the other hand,
 have only local significance.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a fixed size Metadata might be too limiting. I believe we need to s=
tructure it such that it is extensible.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Maria<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><img border=3D"0" width=3D"83" height=
=3D"41" id=3D"_x0000_i1025" src=3D"rtfimage://"></span><span style=3D"font-=
size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; -----Original Message-----</span><span style=3D"font-=
size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; From: Thomas Narten &lt;<a href=3D"mailto:narten@DOMA=
IN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:robert@DOMAIN=
.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDDEN">nsc at i=
etf.org</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Robert Raszuk &lt;robert at raszuk.net&gt; writes:<o:p></o=
:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; I have a basic question reg Network Service Header dr=
aft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Don't we already have sufficient room in v6 header (i=
ncluding it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; extension header) to embed services in it ? Do we nee=
d to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; header each time someone proposes a new approach ;) ?=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">IMO, discussions about how best to encode stuff is a tad p=
remature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">should focus discussion on whether some item of informatio=
n needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">be included in a packet or not, and the motivation/pros/co=
ns of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Just like we can get service discovery accomplished f=
or free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; embed service in its reachability advertisement:<o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; <a href=3D"http://telematics.tm.kit.edu/publications/=
Files/491/ipv6-app-contest-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&quot;service discovery for free&quot; is an oxymoron. The=
re are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">reasons why the above proposal is not a good idea. Encodin=
g additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">semantics into IP addresses is fraught with difficulties, =
and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">in very limited situations, the IETF has not been willing =
to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01202E02MISOUT7MSGUSR9I_--

From Ron_Parker@affirmednetworks.com  Mon Jul 15 09:29:52 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC7F21E8084 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 09:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpuILXL0eiqR for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 09:29:48 -0700 (PDT)
Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3EE21E80D4 for <nsc@ietf.org>; Mon, 15 Jul 2013 09:29:45 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 09:29:44 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, 'Thomas Narten' <narten@us.ibm.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: Ac6BbvX6D9IjzqAtTXmJbuDZa8Rd+QAAQI2wABBKdAAADo3YIA==
Date: Mon, 15 Jul 2013 16:29:43 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5@MBX021-W3-CA-2.exch021.domain.local>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01202E02@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01202E02@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.150.224]
Content-Type: multipart/related; boundary="_004_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 16:29:53 -0000

--_004_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_
Content-Type: multipart/alternative;
	boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_"

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks, Maria.

My followup, inline after yours.

   Ron


From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
Sent: Monday, July 15, 2013 12:15 PM
To: Ron Parker; 'Thomas Narten'
Cc: nsc@ietf.org; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Ron,

Please see in-line.

Maria

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 15, 2013 11:33 AM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discu=
ssed ahead of the actual content.
One important input to that discussion is whether MPLS is a requirement for=
 Network Service Chaining, or if Network Service Chaining merely requires I=
P connectivity amongst the
<MN> IP-only connectivity (if I understand you correctly) will require IP f=
low classification at every service hop .
<Ron> -- Without an encapsulation of some sort, then yes, each hop would ne=
ed to independently determine the next hop.   But I don't think this is the=
 approach envisioned by the NSC drafts, so far, including Quinn and Boucada=
ir.   There are 2 approaches that can be considered.   In the first, a glob=
al chain ID could be conveyed on the wire.   Either via a control plane or =
via coordinated management plane actions, each hop would fully understand t=
he semantics of the global chain ID.   In the second approach a stack of ho=
ps could be sent on the wire with an expectation that each hop pops its own=
 entry.    Both approaches could be achieved with MPLS (single label or sta=
ck of labels).   The first could also be achieved through existing IP layer=
 encapsulations (i.e., GRE, using its key as the chain ID), or new encapsul=
ations.   The latter could also be achieved with a new encapsulation.
<Ron>

network functions.   Another input to the discussion is whether the chain d=
escribes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely the=
 identity of the sequence of network functions, or also suggests a per-netw=
ork-function policy set to be applied (that is, additional value provided b=
y the orchestrator).

<MN> In my opinion, both.
<Ron> Mine, also.



   Ron Parker
   Affirmed Networks


From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of NAPIERALA, MARIA H
Sent: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

*         Is it necessary to have a new header that identifies a service (c=
alled Base Header in the draft)? Base Header implies new forwarding paradig=
m on the edge. In my opinion using MPLS labels to identify a service chain =
and a specific service will do the job.
*         Having a Global service chain identifier (called Service Path whi=
ch is a part of Base Header) might not be a good idea. It will make service=
 chaining less flexible. MPLS labels, on the other hand, have only local si=
gnificance.
*         Having a fixed size Metadata might be too limiting. I believe we =
need to structure it such that it is extensible.

Maria
[Image removed by sender.]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks, Maria.<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">My followup, inline after=
 yours.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> NAPIER=
ALA, MARIA H [mailto:mn1921@att.com]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:15 PM<br>
<b>To:</b> Ron Parker; 'Thomas Narten'<br>
<b>Cc:</b> nsc@ietf.org; Robert Raszuk<br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Please see in-line.<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ron Park=
er [mailto:Ron_Parker@affirmednetworks.com]
<br>
<b>Sent:</b> Monday, July 15, 2013 11:33 AM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> nsc@ietf.org; Robert Raszuk<br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that the pros/con=
s of a new IP-level encapsulation need to be discussed ahead of the actual =
content.&nbsp;&nbsp;&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">One important input to th=
at discussion is whether MPLS is a requirement for Network Service Chaining=
, or if Network Service Chaining merely requires IP connectivity
 amongst the <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; IP-only connec=
tivity (if I understand you correctly) will require IP flow classification =
at every service hop .
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt; -- Without an=
 encapsulation of some sort, then yes, each hop would need to independently=
 determine the next hop.&nbsp;&nbsp; But I don&#8217;t think this is the ap=
proach
 envisioned by the NSC drafts, so far, including Quinn and Boucadair.&nbsp;=
&nbsp; There are 2 approaches that can be considered.&nbsp;&nbsp; In the fi=
rst, a global chain ID could be conveyed on the wire.&nbsp;&nbsp; Either vi=
a a control plane or via coordinated management plane actions,
 each hop would fully understand the semantics of the global chain ID.&nbsp=
;&nbsp; In the second approach a stack of hops could be sent on the wire wi=
th an expectation that each hop pops its own entry.&nbsp;&nbsp;&nbsp; Both =
approaches could be achieved with MPLS (single label or stack
 of labels).&nbsp;&nbsp; The first could also be achieved through existing =
IP layer encapsulations (i.e., GRE, using its key as the chain ID), or new =
encapsulations.&nbsp;&nbsp; The latter could also be achieved with a new en=
capsulation.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt;<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">network functions.&nbsp;&=
nbsp; Another input to the discussion is whether the chain describes (e.g.,=
 via MPLS label(s) and/or IP-level encapsulation) merely the identity
 of the sequence of network functions, or also suggests a per-network-funct=
ion policy set to be applied (that is, additional value provided by the orc=
hestrator).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; In my opinion,=
 both.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt; Mine, also.<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron Parker<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Affirmed Net=
works<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>NAPIERALA, MARIA H<br>
<b>Sent:</b> Monday, July 15, 2013 11:23 AM<br>
<b>To:</b> 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN">=
narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; IMO, discussions about how best to encode stuff is a =
tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; should focus discussion on whether some item of infor=
mation needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; be included in a packet or not, and the motivation/pr=
os/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">I agree. I have three comments that fall in this category:=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Is it necessary to have a new header that identifies a service (called Bas=
e Header in the draft)? Base Header implies new forwarding paradigm on the =
edge. In my opinion using MPLS labels to identify
 a service chain and a specific service will do the job.<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a Global service chain identifier (called Service Path which is a p=
art of Base Header) might not be a good idea. It will make service chaining=
 less flexible. MPLS labels, on the other hand,
 have only local significance.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a fixed size Metadata might be too limiting. I believe we need to s=
tructure it such that it is extensible.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Maria<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;border:solid windowtext 1.0pt;padding:0i=
n"><img border=3D"0" width=3D"83" height=3D"41" id=3D"_x0000_i1025" src=3D"=
cid:image001.jpg@01CE8155.CEDAEBA0" alt=3D"Image removed by sender."></span=
><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; -----Original Message-----</span><span style=3D"font-=
size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; From: Thomas Narten &lt;<a href=3D"mailto:narten@DOMA=
IN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:robert@DOMAIN=
.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDDEN">nsc at i=
etf.org</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Robert Raszuk &lt;robert at raszuk.net&gt; writes:<o:p></o=
:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; I have a basic question reg Network Service Header dr=
aft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Don't we already have sufficient room in v6 header (i=
ncluding it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; extension header) to embed services in it ? Do we nee=
d to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; header each time someone proposes a new approach ;) ?=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">IMO, discussions about how best to encode stuff is a tad p=
remature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">should focus discussion on whether some item of informatio=
n needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">be included in a packet or not, and the motivation/pros/co=
ns of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Just like we can get service discovery accomplished f=
or free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; embed service in its reachability advertisement:<o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; <a href=3D"http://telematics.tm.kit.edu/publications/=
Files/491/ipv6-app-contest-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&quot;service discovery for free&quot; is an oxymoron. The=
re are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">reasons why the above proposal is not a good idea. Encodin=
g additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">semantics into IP addresses is fraught with difficulties, =
and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">in very limited situations, the IETF has not been willing =
to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_--

--_004_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=381;
	creation-date="Mon, 15 Jul 2013 16:29:43 GMT";
	modification-date="Mon, 15 Jul 2013 16:29:43 GMT"
Content-ID: <image001.jpg@01CE8155.CEDAEBA0>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg
IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAApAFMBAREA/8QAHwAAAQUBAQEB
AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh
ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ
WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK//Z

--_004_CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5MBX021W3CA2exch_--

From mn1921@att.com  Mon Jul 15 11:48:55 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8218B11E81B4 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 11:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbI9EFTq91Gg for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 11:48:44 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0087D11E81D1 for <nsc@ietf.org>; Mon, 15 Jul 2013 11:48:42 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b0444e15.2aaae0a20940.2090114.00-581.5778509.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 18:48:43 +0000 (UTC)
X-MXL-Hash: 51e4440b361e0411-b3e97fd691599dc99702dd51dce3e298031946b9
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 90444e15.0.2090107.00-176.5778481.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 18:48:42 +0000 (UTC)
X-MXL-Hash: 51e4440a278157e3-8f057217cb87968c7ae770bde628eea403a04a10
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FImfN9029156; Mon, 15 Jul 2013 14:48:41 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FImZl2028948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 14:48:39 -0400
Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 15 Jul 2013 18:48:21 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 14:48:21 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "jguichar@cisco.com" <jguichar@cisco.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: AQHOgXWv1pEzluyOGkGkenYfxSqcd5ll9L9AgAAPSkCAABBJ4A==
Date: Mon, 15 Jul 2013 18:48:21 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012030D6@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.118.216]
Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E012030D6MISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=esxoOPVX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=kkgtkFppdtMA:10 a=udf1vONPOAQA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=GO6QpIho8]
X-AnalysisOut: [WgA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=VnNF1IyMAAAA:8 ]
X-AnalysisOut: [a=2clOPd4PAAAA:8 a=DR_9I_piAAAA:8 a=HIioZBrcqxXYk02OPXsA:9]
X-AnalysisOut: [ a=CjuIK1q_8ugA:10 a=ZF8ZrD0BOmYA:10 a=kkUMZHjH4KkA:10 a=J]
X-AnalysisOut: [fD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=bDUki]
X-AnalysisOut: [_mJ7DgA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVk]
X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10]
X-AnalysisOut: [ a=_w2d0xXIGTEQpcb4:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: [nsc] FW:  Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 18:48:55 -0000

--_000_1D70D757A2C9D54D83B4CBD7625FA80E012030D6MISOUT7MSGUSR9I_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jim,

Thanks for the reply. Please my responses in-line.

Maria

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, July 15, 2013 12:09 PM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Maria,

Thank you for your comments on our draft. Please see inline for responses.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten' <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>=
, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

*        Is it necessary to have a new header that identifies a service (ca=
lled Base Header in the draft)? Base Header implies new forwarding paradigm=
 on the edge. In my opinion using MPLS labels to identify a service chain a=
nd a specific service will do the job.

Jim>  it is certainly a true statement that an MPLS label could be used (as=
suming that the network environment supports/deploys MPLS; a large assumpti=
on),

<MN> The draft introduces new encapsulation which would need to be supporte=
d at the network edge.
      At least, MPLS is not new ;-)

as could an IP tunnel, to get packets from point A to point B and at point =
B use said label value, or IP tunnel context, to indicate a given service f=
unction to be applied to the traffic. However, service chaining will requir=
e more than simply a forwarding mechanism between service functions: at a m=
inimum service visibility and information exchange will be key.

<MN> I am not sure what is meant by "service visibility"?
     MPLS label can be also used to identify the service. Metadata would fo=
llow MPLS label stack.

*        Having a Global service chain identifier (called Service Path whic=
h is a part of Base Header) might not be a good idea. It will make service =
chaining less flexible. MPLS labels, on the other hand, have only local sig=
nificance.

Jim> could you provide a more detailed description of why service chaining =
would be less flexible if a global service chain identifier is adopted?

<MN> A specific service may belong to multiple service chains. IMO, a servi=
ce node should not be aware of service chains it serves but only of what se=
rvices it provides.
Since the draft makes the service nodes aware of service chains, the servic=
e nodes need to carry mappings between service chains and the services they=
 provide. This introduces additional complexity on the service nodes.
For example, if a particular service is removed from a service chain, the s=
ervice_chain-to-service mapping has to be cleaned up on the removed service=
 node.
Assume initially, two flow classifications (say, class1 and class2) are map=
ped to the same service chain (say, chain1). Subsequently, class2 traffic n=
eeds one additional service in front of chain1. According to the draft, new=
 unique service chain has to be created (say, chain2) for class2 traffic. T=
his creates a lot of duplicated state. Hence, what is needed is a locally s=
ignificant chain identifier.
Since service chain identifiers have to be globally unique, maintaining the=
m will not be trivial.


[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_1D70D757A2C9D54D83B4CBD7625FA80E012030D6MISOUT7MSGUSR9I_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:629045871;
	mso-list-template-ids:-1707463826;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1349528975;
	mso-list-template-ids:498245268;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">Hi Jim,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">Thanks for the reply. Please my responses in-line.<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">Maria<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Jim Guic=
hard (jguichar) [<a href=3D"mailto:jguichar@cisco.com">mailto:jguichar@cisc=
o.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:09 PM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Hi Maria,<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Thank you for your comments =
on our draft. Please see inline for responses.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:black">&lt;NAPIERALA&gt;, MARIA H &lt;<a href=
=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<b>Date: </b>Monday, July 15, 2013 11:23 AM<br>
<b>To: </b>'Thomas Narten' &lt;<a href=3D"mailto:narten@us.ibm.com">narten@=
us.ibm.com</a>&gt;<br>
<b>Cc: </b>&quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt=
;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;, Robert Raszuk &lt;<a=
 href=3D"mailto:robert@raszuk.net">robert@raszuk.net</a>&gt;<br>
<b>Subject: </b>Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Thomas Narten &lt;<a href=3D"mailto:narten@DOM=
AIN.HIDDEN">narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; IMO, discussions about how best to encode=
 stuff is a tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; should focus discussion on whether some i=
tem of information needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; be included in a packet or not, and the m=
otivation/pros/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">I agree. I have three comments that fall in th=
is category:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=
or:black"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt=
 &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:10.0pt;font-family:=
&quot;Courier New&quot;;color:black">Is it necessary to have a new header t=
hat identifies a service (called Base Header in the draft)? Base Header imp=
lies new forwarding paradigm on the edge. In
 my opinion using MPLS labels to identify a service chain and a specific se=
rvice will do the job.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;">Jim&gt; &nbsp;it is certainly a true sta=
tement that an MPLS label could be used (assuming that the network environm=
ent supports/deploys MPLS; a large assumption),<span style=3D"color:#1F497D=
"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&lt;MN&gt; The draft introduces new encapsulation which wo=
uld need to be supported at the network edge. &nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;At least, MPLS is not =
new ;-)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;">as could an IP tunnel,&nbsp;to get packe=
ts from point A to point B and at point B use said label value, or IP tunne=
l context, to indicate a given service function to be applied
 to the traffic.&nbsp;However, service chaining&nbsp;will require&nbsp;more=
 than simply a forwarding mechanism between service functions: at a minimum=
 service visibility and information exchange will be key.&nbsp;<span style=
=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&lt;MN&gt; I am not sure what is meant by &#8220;service v=
isibility&#8221;?
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPLS label can be also used =
to identify the service. Metadata would follow MPLS label stack.<o:p></o:p>=
</span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l1 level1 lfo4">
<![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=
or:black"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt=
 &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:10.0pt;font-family:=
&quot;Courier New&quot;;color:black">Having a Global service chain identifi=
er (called Service Path which is a part of Base Header) might not be a good=
 idea. It will make service chaining less flexible.
 MPLS labels, on the other hand, have only local significance.<o:p></o:p></=
span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;">Jim&gt;&nbsp;could you provide a more de=
tailed description of why service chaining would be less flexible if a glob=
al service chain identifier is adopted?&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&lt;MN&gt; A specific service may belong to multiple servi=
ce chains. IMO, a service node should not<span style=3D"color:#1F497D">
</span>be aware of service chains it serves but only of what<span style=3D"=
color:#1F497D">
</span>services it provides.<span style=3D"color:#1F497D"> <o:p></o:p></spa=
n></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Since the draft makes the service<span style=3D"color:#1F4=
97D">
</span>nodes aware of service chains, the service nodes need to carry mappi=
ng<span style=3D"color:#1F497D">s</span> between service chains and the ser=
vices they provide. This introduces additional complexity on the service no=
des.
<span style=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">For example,
<span style=3D"color:#1F497D">i</span>f a particular service is removed fro=
m a service chain, the service_chain-to-service mapping has to be cleaned u=
p on the removed service node.<span style=3D"color:#1F497D">
<o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Assume initially, two flow classifications (say, class1 an=
d class2) are mapped to the same service chain (say, chain1). Subsequently,=
 class2 traffic needs one additional service in
 front of chain1. According to the draft, new unique service chain has to b=
e created (say, chain2) for class2 traffic. This creates a lot of duplicate=
d state. Hence, what is needed is a locally significant chain identifier.<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Since service chain identifiers have to be globally unique=
, maintaining them will not be trivial.<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><img border=3D"0" width=3D"=
83" height=3D"41" id=3D"_x0000_i1025" src=3D"rtfimage://"></span><span styl=
e=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:black"><o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; -----Original Message-----</span><span st=
yle=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:black"><o=
:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; From: Thomas Narten &lt;<a href=3D"mailto=
:narten@DOMAIN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;=
color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:r=
obert@DOMAIN.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;=
color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDD=
EN">nsc at ietf.org</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;=
color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;=
color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Robert Raszuk &lt;robert at raszuk.net&gt; wri=
tes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; I have a basic question reg Network Servi=
ce Header draft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Don't we already have sufficient room in =
v6 header (including it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; extension header) to embed services in it=
 ? Do we need to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; header each time someone proposes a new a=
pproach ;) ?<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">IMO, discussions about how best to encode stuf=
f is a tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">should focus discussion on whether some item o=
f information needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">be included in a packet or not, and the motiva=
tion/pros/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Just like we can get service discovery ac=
complished for free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; embed service in its reachability adverti=
sement:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt;
<a href=3D"http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-con=
test-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&quot;service discovery for free&quot; is an o=
xymoron. There are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">reasons why the above proposal is not a good i=
dea. Encoding additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">semantics into IP addresses is fraught with di=
fficulties, and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">in very limited situations, the IETF has not b=
een willing to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:black"><o:p></o=
:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:black"><o:p></o=
:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_1D70D757A2C9D54D83B4CBD7625FA80E012030D6MISOUT7MSGUSR9I_--

From mn1921@att.com  Mon Jul 15 12:43:53 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B6F11E8220 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 12:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.098
X-Spam-Level: 
X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlrDq7wVoK9J for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 12:43:48 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 359C111E822C for <nsc@ietf.org>; Mon, 15 Jul 2013 12:43:46 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 2f054e15.2aaabd401940.2132023.00-563.5898919.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 19:43:46 +0000 (UTC)
X-MXL-Hash: 51e450f268ffe447-29be3d3c41cb13c60ca4258736e5869c2f55d353
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0f054e15.0.2132003.00-493.5898828.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 19:43:45 +0000 (UTC)
X-MXL-Hash: 51e450f10b6d0664-db7e1170f3224a1e1cdeeb6d306495edef00e231
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FJhhrE028050; Mon, 15 Jul 2013 15:43:44 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FJhXmM027881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 15:43:35 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 15 Jul 2013 19:43:24 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 15:43:24 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "'Thomas Narten'" <narten@us.ibm.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: AQHOgXCjirru2EVnp0GQKr6sQClwy5ll4eFAgABPUYD///EMwA==
Date: Mon, 15 Jul 2013 19:43:23 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01203149@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01202E02@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.118.216]
Content-Type: multipart/related; boundary="_004_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_"; type="multipart/alternative"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=esxoOPVX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=kkgtkFppdtMA:10 a=BUO9sMsmufgA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HqxhTrMpf]
X-AnalysisOut: [q0A:10 a=qN95wPeSAAAA:8 a=48vgC7mUAAAA:8 a=VnNF1IyMAAAA:8 ]
X-AnalysisOut: [a=2clOPd4PAAAA:8 a=DR_9I_piAAAA:8 a=V94pn1ZTgYneBCV4s7sA:9]
X-AnalysisOut: [ a=CjuIK1q_8ugA:10 a=ZF8ZrD0BOmYA:10 a=kkUMZHjH4KkA:10 a=p]
X-AnalysisOut: [aC5pjApGzsA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=yMhMj]
X-AnalysisOut: [lubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4]
X-AnalysisOut: [A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=rkLeuzYYjGHoKPe]
X-AnalysisOut: [9:21 a=FoLopk8cqeGNkQHUyrUA:9 a=KQqxNPgzF0kA:10 a=mI4lhpPz]
X-AnalysisOut: [hsoA:10 a=7xRO5NLo5R4A:10 a=gwPS-ypuvqpQIx8o:18]
Cc: "nsc@ietf.org" <nsc@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 19:43:53 -0000

--_004_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_
Content-Type: multipart/alternative;
	boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_"

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ron,

Thanks. Please see in-line.

Maria

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 15, 2013 12:30 PM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Thanks, Maria.

My followup, inline after yours.

   Ron


From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
Sent: Monday, July 15, 2013 12:15 PM
To: Ron Parker; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Ron,

Please see in-line.

Maria

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 15, 2013 11:33 AM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discu=
ssed ahead of the actual content.
One important input to that discussion is whether MPLS is a requirement for=
 Network Service Chaining, or if Network Service Chaining merely requires I=
P connectivity amongst the
<MN> IP-only connectivity (if I understand you correctly) will require IP f=
low classification at every service hop .
<Ron> -- Without an encapsulation of some sort, then yes, each hop would ne=
ed to independently determine the next hop.   But I don't think this is the=
 approach envisioned by the NSC drafts, so far, including Quinn and Boucada=
ir.   There are 2 approaches that can be considered.   In the first, a glob=
al chain ID could be conveyed on the wire.   Either via a control plane or =
via coordinated management plane actions, each hop would fully understand t=
he semantics of the global chain ID.

<mn> I have a different view. I don't think a global chain ID is a good ide=
a. MPLS labels can locally identify service chains and services on service =
nodes. They have local significance and would be swapped at every service h=
op.

In the second approach a stack of hops could be sent on the wire with an ex=
pectation that each hop pops its own entry.
<mn> I must admit I have not read this draft.

Both approaches could be achieved with MPLS (single label or stack of label=
s).   The first could also be achieved through existing IP layer encapsulat=
ions (i.e., GRE, using its key as the chain ID), or new encapsulations.   T=
he latter could also be achieved with a new encapsulation.
<Ron>

network functions.   Another input to the discussion is whether the chain d=
escribes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely the=
 identity of the sequence of network functions, or also suggests a per-netw=
ork-function policy set to be applied (that is, additional value provided b=
y the orchestrator).

<MN> In my opinion, both.
<Ron> Mine, also.



   Ron Parker
   Affirmed Networks


From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of NAPIERALA, MARIA H
Sent: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

*         Is it necessary to have a new header that identifies a service (c=
alled Base Header in the draft)? Base Header implies new forwarding paradig=
m on the edge. In my opinion using MPLS labels to identify a service chain =
and a specific service will do the job.
*         Having a Global service chain identifier (called Service Path whi=
ch is a part of Base Header) might not be a good idea. It will make service=
 chaining less flexible. MPLS labels, on the other hand, have only local si=
gnificance.
*         Having a fixed size Metadata might be too limiting. I believe we =
need to structure it such that it is extensible.

Maria
[Image removed by sender.]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks. Please see in-lin=
e.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ron Park=
er [mailto:Ron_Parker@affirmednetworks.com]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:30 PM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> nsc@ietf.org; Robert Raszuk<br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks, Maria.<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">My followup, inline after=
 yours.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> NAPIER=
ALA, MARIA H [<a href=3D"mailto:mn1921@att.com">mailto:mn1921@att.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:15 PM<br>
<b>To:</b> Ron Parker; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Please see in-line.<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ron Park=
er [<a href=3D"mailto:Ron_Parker@affirmednetworks.com">mailto:Ron_Parker@af=
firmednetworks.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 11:33 AM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that the pros/con=
s of a new IP-level encapsulation need to be discussed ahead of the actual =
content.&nbsp;&nbsp;&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">One important input to th=
at discussion is whether MPLS is a requirement for Network Service Chaining=
, or if Network Service Chaining merely requires IP connectivity
 amongst the <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; IP-only connec=
tivity (if I understand you correctly) will require IP flow classification =
at every service hop .
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt; -- Without an=
 encapsulation of some sort, then yes, each hop would need to independently=
 determine the next hop.&nbsp;&nbsp; But I don&#8217;t think this is the ap=
proach
 envisioned by the NSC drafts, so far, including Quinn and Boucadair.&nbsp;=
&nbsp; There are 2 approaches that can be considered.&nbsp;&nbsp; In the fi=
rst, a global chain ID could be conveyed on the wire.&nbsp;&nbsp; Either vi=
a a control plane or via coordinated management plane actions,
 each hop would fully understand the semantics of the global chain ID.&nbsp=
;&nbsp; </span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&qu=
ot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;mn&gt; I have a diffe=
rent view. I don&#8217;t think a global chain ID is a good idea. MPLS label=
s can locally identify service chains and services on service nodes.
 They have local significance and would be swapped at every service hop.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In the second approach a =
stack of hops could be sent on the wire with an expectation that each hop p=
ops its own entry.&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;mn&gt; I must admit I=
 have not read this draft.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Both approaches could be =
achieved with MPLS (single label or stack of labels).&nbsp;&nbsp; The first=
 could also be achieved through existing IP layer encapsulations (i.e.,
 GRE, using its key as the chain ID), or new encapsulations.&nbsp;&nbsp; Th=
e latter could also be achieved with a new encapsulation.<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt;<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">network functions.&nbsp;&=
nbsp; Another input to the discussion is whether the chain describes (e.g.,=
 via MPLS label(s) and/or IP-level encapsulation) merely the identity
 of the sequence of network functions, or also suggests a per-network-funct=
ion policy set to be applied (that is, additional value provided by the orc=
hestrator).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; In my opinion,=
 both.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt; Mine, also.<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron Parker<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Affirmed Net=
works<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>NAPIERALA, MARIA H<br>
<b>Sent:</b> Monday, July 15, 2013 11:23 AM<br>
<b>To:</b> 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN">=
narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; IMO, discussions about how best to encode stuff is a =
tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; should focus discussion on whether some item of infor=
mation needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; be included in a packet or not, and the motivation/pr=
os/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">I agree. I have three comments that fall in this category:=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Is it necessary to have a new header that identifies a service (called Bas=
e Header in the draft)? Base Header implies new forwarding paradigm on the =
edge. In my opinion using MPLS labels to identify
 a service chain and a specific service will do the job.<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a Global service chain identifier (called Service Path which is a p=
art of Base Header) might not be a good idea. It will make service chaining=
 less flexible. MPLS labels, on the other hand,
 have only local significance.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a fixed size Metadata might be too limiting. I believe we need to s=
tructure it such that it is extensible.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Maria<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;border:solid windowtext 1.0pt;padding:0i=
n"><img border=3D"0" width=3D"83" height=3D"41" id=3D"_x0000_i1025" src=3D"=
cid:image001.jpg@01CE8171.ACDDD5F0" alt=3D"Image removed by sender."></span=
><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; -----Original Message-----</span><span style=3D"font-=
size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; From: Thomas Narten &lt;<a href=3D"mailto:narten@DOMA=
IN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:robert@DOMAIN=
.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDDEN">nsc at i=
etf.org</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Robert Raszuk &lt;robert at raszuk.net&gt; writes:<o:p></o=
:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; I have a basic question reg Network Service Header dr=
aft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Don't we already have sufficient room in v6 header (i=
ncluding it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; extension header) to embed services in it ? Do we nee=
d to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; header each time someone proposes a new approach ;) ?=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">IMO, discussions about how best to encode stuff is a tad p=
remature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">should focus discussion on whether some item of informatio=
n needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">be included in a packet or not, and the motivation/pros/co=
ns of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Just like we can get service discovery accomplished f=
or free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; embed service in its reachability advertisement:<o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; <a href=3D"http://telematics.tm.kit.edu/publications/=
Files/491/ipv6-app-contest-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&quot;service discovery for free&quot; is an oxymoron. The=
re are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">reasons why the above proposal is not a good idea. Encodin=
g additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">semantics into IP addresses is fraught with difficulties, =
and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">in very limited situations, the IETF has not been willing =
to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_--

--_004_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=381;
	creation-date="Mon, 15 Jul 2013 19:43:23 GMT";
	modification-date="Mon, 15 Jul 2013 19:43:23 GMT"
Content-ID: <image001.jpg@01CE8171.ACDDD5F0>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg
IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAApAFMBAREA/8QAHwAAAQUBAQEB
AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh
ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ
WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK//Z

--_004_1D70D757A2C9D54D83B4CBD7625FA80E01203149MISOUT7MSGUSR9I_--

From Ron_Parker@affirmednetworks.com  Mon Jul 15 12:55:17 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5092221E8153 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 12:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level: 
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d6tqBFMRUVj for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 12:55:11 -0700 (PDT)
Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7911E822F for <nsc@ietf.org>; Mon, 15 Jul 2013 12:55:07 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 12:55:06 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, 'Thomas Narten' <narten@us.ibm.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: Ac6BbvX6D9IjzqAtTXmJbuDZa8Rd+QAAQI2wABBKdAAADo3YIP//xceAgABzqhA=
Date: Mon, 15 Jul 2013 19:55:05 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A67514B@MBX021-W3-CA-2.exch021.domain.local>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01202E02@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01203149@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01203149@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.150.224]
Content-Type: multipart/related; boundary="_004_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 19:55:17 -0000

--_004_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_
Content-Type: multipart/alternative;
	boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_"

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Maria,

Conveyance of a stack of next-hops explicitly on the wire, via MPLS or a ne=
w IP-layer encapsulation, is not currently discussed in the NSC-related Int=
ernet-Drafts, to my knowledge.   I think it is a fruitful area for a new I-=
D, however, to facilitate consideration of the concept.

   Ron

From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
Sent: Monday, July 15, 2013 3:43 PM
To: Ron Parker; 'Thomas Narten'
Cc: nsc@ietf.org; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Ron,

Thanks. Please see in-line.

Maria

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 15, 2013 12:30 PM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Thanks, Maria.

My followup, inline after yours.

   Ron


From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
Sent: Monday, July 15, 2013 12:15 PM
To: Ron Parker; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Ron,

Please see in-line.

Maria

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Monday, July 15, 2013 11:33 AM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: RE: [nsc] Comments on draft-quinn-nsh-00

Maria,

I agree that the pros/cons of a new IP-level encapsulation need to be discu=
ssed ahead of the actual content.
One important input to that discussion is whether MPLS is a requirement for=
 Network Service Chaining, or if Network Service Chaining merely requires I=
P connectivity amongst the
<MN> IP-only connectivity (if I understand you correctly) will require IP f=
low classification at every service hop .
<Ron> -- Without an encapsulation of some sort, then yes, each hop would ne=
ed to independently determine the next hop.   But I don't think this is the=
 approach envisioned by the NSC drafts, so far, including Quinn and Boucada=
ir.   There are 2 approaches that can be considered.   In the first, a glob=
al chain ID could be conveyed on the wire.   Either via a control plane or =
via coordinated management plane actions, each hop would fully understand t=
he semantics of the global chain ID.

<mn> I have a different view. I don't think a global chain ID is a good ide=
a. MPLS labels can locally identify service chains and services on service =
nodes. They have local significance and would be swapped at every service h=
op.

In the second approach a stack of hops could be sent on the wire with an ex=
pectation that each hop pops its own entry.
<mn> I must admit I have not read this draft.

Both approaches could be achieved with MPLS (single label or stack of label=
s).   The first could also be achieved through existing IP layer encapsulat=
ions (i.e., GRE, using its key as the chain ID), or new encapsulations.   T=
he latter could also be achieved with a new encapsulation.
<Ron>

network functions.   Another input to the discussion is whether the chain d=
escribes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely the=
 identity of the sequence of network functions, or also suggests a per-netw=
ork-function policy set to be applied (that is, additional value provided b=
y the orchestrator).

<MN> In my opinion, both.
<Ron> Mine, also.



   Ron Parker
   Affirmed Networks


From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of NAPIERALA, MARIA H
Sent: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

*         Is it necessary to have a new header that identifies a service (c=
alled Base Header in the draft)? Base Header implies new forwarding paradig=
m on the edge. In my opinion using MPLS labels to identify a service chain =
and a specific service will do the job.
*         Having a Global service chain identifier (called Service Path whi=
ch is a part of Base Header) might not be a good idea. It will make service=
 chaining less flexible. MPLS labels, on the other hand, have only local si=
gnificance.
*         Having a fixed size Metadata might be too limiting. I believe we =
need to structure it such that it is extensible.

Maria
[Image removed by sender.]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Conveyance of a stack of =
next-hops explicitly on the wire, via MPLS or a new IP-layer encapsulation,=
 is not currently discussed in the NSC-related Internet-Drafts,
 to my knowledge.&nbsp;&nbsp; I think it is a fruitful area for a new I-D, =
however, to facilitate consideration of the concept.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> NAPIER=
ALA, MARIA H [mailto:mn1921@att.com]
<br>
<b>Sent:</b> Monday, July 15, 2013 3:43 PM<br>
<b>To:</b> Ron Parker; 'Thomas Narten'<br>
<b>Cc:</b> nsc@ietf.org; Robert Raszuk<br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks. Please see in-lin=
e.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ron Park=
er [<a href=3D"mailto:Ron_Parker@affirmednetworks.com">mailto:Ron_Parker@af=
firmednetworks.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:30 PM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks, Maria.<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">My followup, inline after=
 yours.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> NAPIER=
ALA, MARIA H [<a href=3D"mailto:mn1921@att.com">mailto:mn1921@att.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:15 PM<br>
<b>To:</b> Ron Parker; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Please see in-line.<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ron Park=
er [<a href=3D"mailto:Ron_Parker@affirmednetworks.com">mailto:Ron_Parker@af=
firmednetworks.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 11:33 AM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> RE: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Maria,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that the pros/con=
s of a new IP-level encapsulation need to be discussed ahead of the actual =
content.&nbsp;&nbsp;&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">One important input to th=
at discussion is whether MPLS is a requirement for Network Service Chaining=
, or if Network Service Chaining merely requires IP connectivity
 amongst the <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; IP-only connec=
tivity (if I understand you correctly) will require IP flow classification =
at every service hop .
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt; -- Without an=
 encapsulation of some sort, then yes, each hop would need to independently=
 determine the next hop.&nbsp;&nbsp; But I don&#8217;t think this is the ap=
proach
 envisioned by the NSC drafts, so far, including Quinn and Boucadair.&nbsp;=
&nbsp; There are 2 approaches that can be considered.&nbsp;&nbsp; In the fi=
rst, a global chain ID could be conveyed on the wire.&nbsp;&nbsp; Either vi=
a a control plane or via coordinated management plane actions,
 each hop would fully understand the semantics of the global chain ID.&nbsp=
;&nbsp; <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;mn&gt; I have a diffe=
rent view. I don&#8217;t think a global chain ID is a good idea. MPLS label=
s can locally identify service chains and services on service nodes.
 They have local significance and would be swapped at every service hop.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In the second approach a =
stack of hops could be sent on the wire with an expectation that each hop p=
ops its own entry.&nbsp;&nbsp;&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;mn&gt; I must admit I=
 have not read this draft.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Both approaches could be =
achieved with MPLS (single label or stack of labels).&nbsp;&nbsp; The first=
 could also be achieved through existing IP layer encapsulations (i.e.,
 GRE, using its key as the chain ID), or new encapsulations.&nbsp;&nbsp; Th=
e latter could also be achieved with a new encapsulation.<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt;<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">network functions.&nbsp;&=
nbsp; Another input to the discussion is whether the chain describes (e.g.,=
 via MPLS label(s) and/or IP-level encapsulation) merely the identity
 of the sequence of network functions, or also suggests a per-network-funct=
ion policy set to be applied (that is, additional value provided by the orc=
hestrator).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;MN&gt; In my opinion,=
 both.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&lt;Ron&gt; Mine, also.<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Ron Parker<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; Affirmed Net=
works<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>NAPIERALA, MARIA H<br>
<b>Sent:</b> Monday, July 15, 2013 11:23 AM<br>
<b>To:</b> 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.HIDDEN">=
narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; IMO, discussions about how best to encode stuff is a =
tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; should focus discussion on whether some item of infor=
mation needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; be included in a packet or not, and the motivation/pr=
os/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">I agree. I have three comments that fall in this category:=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Is it necessary to have a new header that identifies a service (called Bas=
e Header in the draft)? Base Header implies new forwarding paradigm on the =
edge. In my opinion using MPLS labels to identify
 a service chain and a specific service will do the job.<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a Global service chain identifier (called Service Path which is a p=
art of Base Header) might not be a good idea. It will make service chaining=
 less flexible. MPLS labels, on the other hand,
 have only local significance.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-.25in">
<span style=3D"font-size:10.0pt;font-family:Symbol">&middot;</span><span st=
yle=3D"font-size:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
>Having a fixed size Metadata might be too limiting. I believe we need to s=
tructure it such that it is extensible.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Maria<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;border:solid windowtext 1.0pt;padding:0i=
n"><img border=3D"0" width=3D"83" height=3D"41" id=3D"_x0000_i1025" src=3D"=
cid:image001.jpg@01CE8173.AB9BA710" alt=3D"Image removed by sender."></span=
><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; -----Original Message-----</span><span style=3D"font-=
size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; From: Thomas Narten &lt;<a href=3D"mailto:narten@DOMA=
IN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:robert@DOMAIN=
.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDDEN">nsc at i=
etf.org</a>&gt;
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"=
><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Robert Raszuk &lt;robert at raszuk.net&gt; writes:<o:p></o=
:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; I have a basic question reg Network Service Header dr=
aft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Don't we already have sufficient room in v6 header (i=
ncluding it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; extension header) to embed services in it ? Do we nee=
d to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; header each time someone proposes a new approach ;) ?=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">IMO, discussions about how best to encode stuff is a tad p=
remature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">should focus discussion on whether some item of informatio=
n needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">be included in a packet or not, and the motivation/pros/co=
ns of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; Just like we can get service discovery accomplished f=
or free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; embed service in its reachability advertisement:<o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&gt; <a href=3D"http://telematics.tm.kit.edu/publications/=
Files/491/ipv6-app-contest-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&quot;service discovery for free&quot; is an oxymoron. The=
re are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">reasons why the above proposal is not a good idea. Encodin=
g additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">semantics into IP addresses is fraught with difficulties, =
and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">in very limited situations, the IETF has not been willing =
to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;</span><span style=3D"font-size:1=
0.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_--

--_004_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=381;
	creation-date="Mon, 15 Jul 2013 19:55:04 GMT";
	modification-date="Mon, 15 Jul 2013 19:55:04 GMT"
Content-ID: <image001.jpg@01CE8173.AB9BA710>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg
IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAApAFMBAREA/8QAHwAAAQUBAQEB
AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh
ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ
WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK//Z

--_004_CDF2F015F4429F458815ED2A6C2B6B0B1A67514BMBX021W3CA2exch_--

From rraszuk@gmail.com  Mon Jul 15 13:15:29 2013
Return-Path: <rraszuk@gmail.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C8721E814F for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 13:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level: 
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=0.286,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAvQbQdU0Pvs for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 13:15:28 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8521E811F for <nsc@ietf.org>; Mon, 15 Jul 2013 13:15:28 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id ar20so27441111iec.35 for <nsc@ietf.org>; Mon, 15 Jul 2013 13:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M8D/0do88su36NBdNiTZJj//mGnFrPe3D9fmp4vgXmA=; b=P56I9oYOQ/2CvpwDFzUQ2XCQthGKUP2BbHLv0ovzG7tGg09IQQY/5gCs8ogSwqvgCN 1QTNinmEcb+UVVlZ4IOlcgMCcLRKeB8oh348P0j4OjV3spd/cxstkyGjISczsWinNNkn QTpNyYGws58xBsV3HeE9lEU4Na5DwQBLJ2b0wULtKnox6eTHddyI/aUwJRkcGHcj7qL2 8iHXHCMDpYQHu7NAyEcznC2cW4T7Cp196MGjQjKWtb9dNjnoJKlwQzgLw9MNGCIBFpBj PwFeQhXyd61F7HKT8eRnZIryByuhfaZJvMbKfjCcWcxpo9fiMW844AgcoaV01x6Yo3cp LOTQ==
MIME-Version: 1.0
X-Received: by 10.50.18.5 with SMTP id s5mr8051922igd.6.1373919327353; Mon, 15 Jul 2013 13:15:27 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.28.168 with HTTP; Mon, 15 Jul 2013 13:15:27 -0700 (PDT)
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67514B@MBX021-W3-CA-2.exch021.domain.local>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01202E02@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01203149@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67514B@MBX021-W3-CA-2.exch021.domain.local>
Date: Mon, 15 Jul 2013 22:15:27 +0200
X-Google-Sender-Auth: tHz0IE76x-1hG42E1ttF0xxm6F4
Message-ID: <CA+b+ER=pQAiQ_p0CCbj88j7PLjK=6ErLumZ_d294f1hR-VXbaA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Ron Parker <Ron_Parker@affirmednetworks.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten <narten@us.ibm.com>, "nsc@ietf.org" <nsc@ietf.org>, "NAPIERALA, MARIA H" <mn1921@att.com>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 20:15:29 -0000

Hi Ron,

Just out of curiosity are you familiar with
draft-patel-raszuk-bgp-vector-routing-00.txt

NSC is one of target's WG for this draft.

Cheers,
R.


On Mon, Jul 15, 2013 at 9:55 PM, Ron Parker
<Ron_Parker@affirmednetworks.com> wrote:
>
> Maria,
>
>
>
> Conveyance of a stack of next-hops explicitly on the wire, via MPLS or a =
new IP-layer encapsulation, is not currently discussed in the NSC-related I=
nternet-Drafts, to my knowledge.   I think it is a fruitful area for a new =
I-D, however, to facilitate consideration of the concept.
>
>
>
>    Ron
>
>
>
> From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
> Sent: Monday, July 15, 2013 3:43 PM
>
>
> To: Ron Parker; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Ron,
>
>
>
> Thanks. Please see in-line.
>
>
>
> Maria
>
>
>
> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
> Sent: Monday, July 15, 2013 12:30 PM
> To: NAPIERALA, MARIA H; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Thanks, Maria.
>
>
>
> My followup, inline after yours.
>
>
>
>    Ron
>
>
>
>
>
> From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
> Sent: Monday, July 15, 2013 12:15 PM
> To: Ron Parker; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Ron,
>
>
>
> Please see in-line.
>
>
>
> Maria
>
>
>
> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
> Sent: Monday, July 15, 2013 11:33 AM
> To: NAPIERALA, MARIA H; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Maria,
>
>
>
> I agree that the pros/cons of a new IP-level encapsulation need to be dis=
cussed ahead of the actual content.
>
> One important input to that discussion is whether MPLS is a requirement f=
or Network Service Chaining, or if Network Service Chaining merely requires=
 IP connectivity amongst the
>
> <MN> IP-only connectivity (if I understand you correctly) will require IP=
 flow classification at every service hop .
>
> <Ron> -- Without an encapsulation of some sort, then yes, each hop would =
need to independently determine the next hop.   But I don=92t think this is=
 the approach envisioned by the NSC drafts, so far, including Quinn and Bou=
cadair.   There are 2 approaches that can be considered.   In the first, a =
global chain ID could be conveyed on the wire.   Either via a control plane=
 or via coordinated management plane actions, each hop would fully understa=
nd the semantics of the global chain ID.
>
>
>
> <mn> I have a different view. I don=92t think a global chain ID is a good=
 idea. MPLS labels can locally identify service chains and services on serv=
ice nodes. They have local significance and would be swapped at every servi=
ce hop.
>
>
>
> In the second approach a stack of hops could be sent on the wire with an =
expectation that each hop pops its own entry.
>
> <mn> I must admit I have not read this draft.
>
>
>
> Both approaches could be achieved with MPLS (single label or stack of lab=
els).   The first could also be achieved through existing IP layer encapsul=
ations (i.e., GRE, using its key as the chain ID), or new encapsulations.  =
 The latter could also be achieved with a new encapsulation.
>
> <Ron>
>
>
>
> network functions.   Another input to the discussion is whether the chain=
 describes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely t=
he identity of the sequence of network functions, or also suggests a per-ne=
twork-function policy set to be applied (that is, additional value provided=
 by the orchestrator).
>
>
>
> <MN> In my opinion, both.
>
> <Ron> Mine, also.
>
>
>
>
>
>
>
>    Ron Parker
>
>    Affirmed Networks
>
>
>
>
>
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of NAP=
IERALA, MARIA H
> Sent: Monday, July 15, 2013 11:23 AM
> To: 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: Re: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Thomas Narten <narten at us.ibm.com> writes:
>
>
>
> > IMO, discussions about how best to encode stuff is a tad premature. We
>
> > should focus discussion on whether some item of information needs to
>
> > be included in a packet or not, and the motivation/pros/cons of doing t=
hat.
>
>
>
> I agree. I have three comments that fall in this category:
>
>
>
> =B7         Is it necessary to have a new header that identifies a servic=
e (called Base Header in the draft)? Base Header implies new forwarding par=
adigm on the edge. In my opinion using MPLS labels to identify a service ch=
ain and a specific service will do the job.
>
> =B7         Having a Global service chain identifier (called Service Path=
 which is a part of Base Header) might not be a good idea. It will make ser=
vice chaining less flexible. MPLS labels, on the other hand, have only loca=
l significance.
>
> =B7         Having a fixed size Metadata might be too limiting. I believe=
 we need to structure it such that it is extensible.
>
>
>
> Maria
>
> > -----Original Message-----
>
> > From: Thomas Narten <narten at us.ibm.com>
>
> > To: Robert Raszuk <robert at raszuk.net>
>
> > Cc: <nsc at ietf.org>
>
> > Date: Thu, 27 Jun 2013 09:29:56 -0400
>
>
>
> Robert Raszuk <robert at raszuk.net> writes:
>
>
>
> > I have a basic question reg Network Service Header draft.
>
>
>
> > Don't we already have sufficient room in v6 header (including it's
>
> > extension header) to embed services in it ? Do we need to invent new
>
> > header each time someone proposes a new approach ;) ?
>
>
>
> IMO, discussions about how best to encode stuff is a tad premature. We
>
> should focus discussion on whether some item of information needs to
>
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.
>
>
>
> > Just like we can get service discovery accomplished for free when we
>
> > embed service in its reachability advertisement:
>
> > http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-20=
11-paper.pdf
>
>
>
> "service discovery for free" is an oxymoron. There are a ton of
>
> reasons why the above proposal is not a good idea. Encoding additional
>
> semantics into IP addresses is fraught with difficulties, and except
>
> in very limited situations, the IETF has not been willing to do so.
>
>
>
> Thomas
>
>
>
>
>
>

From Ron_Parker@affirmednetworks.com  Mon Jul 15 14:21:53 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC92D21F9E3D for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 14:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level: 
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb2eL5Ct+w-i for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 14:21:49 -0700 (PDT)
Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3011E815E for <nsc@ietf.org>; Mon, 15 Jul 2013 14:21:46 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 14:21:44 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: Ac6BbvX6D9IjzqAtTXmJbuDZa8Rd+QAAQI2wABBKdAAADo3YIP//xceAgABzqhD//5VMgIAAY1OA
Date: Mon, 15 Jul 2013 21:21:44 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A675201@MBX021-W3-CA-2.exch021.domain.local>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01202B3B@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674CEE@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01202E02@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674DD5@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01203149@MISOUT7MSGUSR9I.ITServices.sbc.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67514B@MBX021-W3-CA-2.exch021.domain.local> <CA+b+ER=pQAiQ_p0CCbj88j7PLjK=6ErLumZ_d294f1hR-VXbaA@mail.gmail.com>
In-Reply-To: <CA+b+ER=pQAiQ_p0CCbj88j7PLjK=6ErLumZ_d294f1hR-VXbaA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.150.224]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Thomas Narten <narten@us.ibm.com>, "nsc@ietf.org" <nsc@ietf.org>, "NAPIERALA, MARIA H" <mn1921@att.com>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 21:21:54 -0000

Thanks, Robert.

I hadn't seen that.   Interesting approach to a control plane that minimize=
s impact on the data plane.   It does, however, impose the BGP requirement,=
 something that is often not true within the data center.

   Ron


-----Original Message-----
From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz=
uk
Sent: Monday, July 15, 2013 4:15 PM
To: Ron Parker
Cc: NAPIERALA, MARIA H; Thomas Narten; nsc@ietf.org
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Ron,

Just out of curiosity are you familiar with draft-patel-raszuk-bgp-vector-r=
outing-00.txt

NSC is one of target's WG for this draft.

Cheers,
R.


On Mon, Jul 15, 2013 at 9:55 PM, Ron Parker <Ron_Parker@affirmednetworks.co=
m> wrote:
>
> Maria,
>
>
>
> Conveyance of a stack of next-hops explicitly on the wire, via MPLS or a =
new IP-layer encapsulation, is not currently discussed in the NSC-related I=
nternet-Drafts, to my knowledge.   I think it is a fruitful area for a new =
I-D, however, to facilitate consideration of the concept.
>
>
>
>    Ron
>
>
>
> From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
> Sent: Monday, July 15, 2013 3:43 PM
>
>
> To: Ron Parker; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Ron,
>
>
>
> Thanks. Please see in-line.
>
>
>
> Maria
>
>
>
> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
> Sent: Monday, July 15, 2013 12:30 PM
> To: NAPIERALA, MARIA H; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Thanks, Maria.
>
>
>
> My followup, inline after yours.
>
>
>
>    Ron
>
>
>
>
>
> From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
> Sent: Monday, July 15, 2013 12:15 PM
> To: Ron Parker; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Ron,
>
>
>
> Please see in-line.
>
>
>
> Maria
>
>
>
> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
> Sent: Monday, July 15, 2013 11:33 AM
> To: NAPIERALA, MARIA H; 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: RE: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Maria,
>
>
>
> I agree that the pros/cons of a new IP-level encapsulation need to be dis=
cussed ahead of the actual content.
>
> One important input to that discussion is whether MPLS is a=20
> requirement for Network Service Chaining, or if Network Service=20
> Chaining merely requires IP connectivity amongst the
>
> <MN> IP-only connectivity (if I understand you correctly) will require IP=
 flow classification at every service hop .
>
> <Ron> -- Without an encapsulation of some sort, then yes, each hop would =
need to independently determine the next hop.   But I don't think this is t=
he approach envisioned by the NSC drafts, so far, including Quinn and Bouca=
dair.   There are 2 approaches that can be considered.   In the first, a gl=
obal chain ID could be conveyed on the wire.   Either via a control plane o=
r via coordinated management plane actions, each hop would fully understand=
 the semantics of the global chain ID.
>
>
>
> <mn> I have a different view. I don't think a global chain ID is a good i=
dea. MPLS labels can locally identify service chains and services on servic=
e nodes. They have local significance and would be swapped at every service=
 hop.
>
>
>
> In the second approach a stack of hops could be sent on the wire with an =
expectation that each hop pops its own entry.
>
> <mn> I must admit I have not read this draft.
>
>
>
> Both approaches could be achieved with MPLS (single label or stack of lab=
els).   The first could also be achieved through existing IP layer encapsul=
ations (i.e., GRE, using its key as the chain ID), or new encapsulations.  =
 The latter could also be achieved with a new encapsulation.
>
> <Ron>
>
>
>
> network functions.   Another input to the discussion is whether the chain=
 describes (e.g., via MPLS label(s) and/or IP-level encapsulation) merely t=
he identity of the sequence of network functions, or also suggests a per-ne=
twork-function policy set to be applied (that is, additional value provided=
 by the orchestrator).
>
>
>
> <MN> In my opinion, both.
>
> <Ron> Mine, also.
>
>
>
>
>
>
>
>    Ron Parker
>
>    Affirmed Networks
>
>
>
>
>
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20
> NAPIERALA, MARIA H
> Sent: Monday, July 15, 2013 11:23 AM
> To: 'Thomas Narten'
> Cc: nsc@ietf.org; Robert Raszuk
> Subject: Re: [nsc] Comments on draft-quinn-nsh-00
>
>
>
> Thomas Narten <narten at us.ibm.com> writes:
>
>
>
> > IMO, discussions about how best to encode stuff is a tad premature.=20
> > We
>
> > should focus discussion on whether some item of information needs to
>
> > be included in a packet or not, and the motivation/pros/cons of doing t=
hat.
>
>
>
> I agree. I have three comments that fall in this category:
>
>
>
> *         Is it necessary to have a new header that identifies a service =
(called Base Header in the draft)? Base Header implies new forwarding parad=
igm on the edge. In my opinion using MPLS labels to identify a service chai=
n and a specific service will do the job.
>
> *         Having a Global service chain identifier (called Service Path w=
hich is a part of Base Header) might not be a good idea. It will make servi=
ce chaining less flexible. MPLS labels, on the other hand, have only local =
significance.
>
> *         Having a fixed size Metadata might be too limiting. I believe w=
e need to structure it such that it is extensible.
>
>
>
> Maria
>
> > -----Original Message-----
>
> > From: Thomas Narten <narten at us.ibm.com>
>
> > To: Robert Raszuk <robert at raszuk.net>
>
> > Cc: <nsc at ietf.org>
>
> > Date: Thu, 27 Jun 2013 09:29:56 -0400
>
>
>
> Robert Raszuk <robert at raszuk.net> writes:
>
>
>
> > I have a basic question reg Network Service Header draft.
>
>
>
> > Don't we already have sufficient room in v6 header (including it's
>
> > extension header) to embed services in it ? Do we need to invent new
>
> > header each time someone proposes a new approach ;) ?
>
>
>
> IMO, discussions about how best to encode stuff is a tad premature. We
>
> should focus discussion on whether some item of information needs to
>
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.
>
>
>
> > Just like we can get service discovery accomplished for free when we
>
> > embed service in its reachability advertisement:
>
> > http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest
> > -2011-paper.pdf
>
>
>
> "service discovery for free" is an oxymoron. There are a ton of
>
> reasons why the above proposal is not a good idea. Encoding additional
>
> semantics into IP addresses is fraught with difficulties, and except
>
> in very limited situations, the IETF has not been willing to do so.
>
>
>
> Thomas
>
>
>
>
>
>

From jguichar@cisco.com  Mon Jul 15 15:33:42 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F4B11E820E for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 15:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.765
X-Spam-Level: 
X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcCPZK1brg0r for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 15:33:15 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4111E823D for <nsc@ietf.org>; Mon, 15 Jul 2013 15:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35054; q=dns/txt; s=iport; t=1373927575; x=1375137175; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=d8r/HBdDt/3DKWy4wr+7CELk2SiXEVZfXz7SlVpPE/8=; b=gL6QCQZcgKSL1IshPYxlNxmibmlhhy0lBXJtTSeVETs4TKAJtgH6t57z yqvMeVNjL5/q2sB1asNO7+dPQKGB6lITYEM9JiMcIiKjw9egr0l/tBqeB hlTELmbzq18GNg1wE2sWQF+aO9say+OC3rmCQZ7Bw5PtuigTdvEhalpt1 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlMGAH135FGtJXG9/2dsb2JhbABQCoJCRDRPr2eJOIg9gQ4WdIIjAQEBAgEBLUwFBwYBCBEDAQEBCxYBBjkUCQgCBA4FCBOHbwYMtjeOIgYEgQcGBxMRBgECBAODAm0DjD2MSIVsijiDEoFoCRcg
X-IronPort-AV: E=Sophos;i="4.89,671,1367971200";  d="scan'208,217";a="235255822"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jul 2013 22:32:55 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6FMWsos011865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 22:32:54 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 17:32:54 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: AQHOgXWvD9IjzqAtTXmJbuDZa8Rd+Zll9L9AgAAPSkCAABBJ4IAAUACA
Date: Mon, 15 Jul 2013 22:32:54 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5960F4@xmb-rcd-x01.cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012030D6@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.212]
Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F5960F4xmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 22:33:42 -0000
X-List-Received-Date: Mon, 15 Jul 2013 22:33:42 -0000

--_000_68B171751455884590F8E38E96416F363F5960F4xmbrcdx01ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Maria,

As I indicated in a previous email it is certainly possible, and valid, to =
build simple service chains through construction of a forwarding path using=
 import/export policy such as suggested in draft-rfernando-l3vpn-service-ch=
aining-01, or an MPLS label stack where each label in the stack provides co=
ntext to indicates which service function should be applied at which servic=
e hop.

However, the problem space is much broader than this as we have tried to ou=
tline in draft-quinn-nsc-problem-statement-02. If it is necessary (and I be=
lieve there are a growing number of use cases to support such an assumption=
) to construct service chains that will require the passing of metadata bet=
ween service functions along the chain then relying on IP forwarding or an =
MPLS label stack is not sufficient; there needs to be additional intelligen=
ce that enables these existing forwarding mechanisms to carry said metadata=
.

I outlined a possible method for this in draft-guichard-mpls-metadata-00; t=
he proposed solution in that draft is to utilize the existing GAL label (ra=
ther than obtaining a reserved label that may only serve a single purpose s=
uch as the passing of metadata relevant to service chaining) to indicate th=
at metadata follows the label stack. As you will see in that draft, once yo=
u get past the label stack you have to define a common format that is able =
to carry the metadata (we call this a Metadata Channel Header (MCH) which w=
ould have a reserved type to signal the presence of NSH) and once you do th=
at you have already gone above and beyond what existing standards provide w=
hether it be IP or MPLS based.  The GAL label signals the presence of the N=
SH service header, where we can leverage the chain (pathing) _and_ the serv=
ice context headers.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 2:48 PM
To: Microsoft Office User <jguichar@cisco.com<mailto:jguichar@cisco.com>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>
Subject: FW: [nsc] Comments on draft-quinn-nsh-00

Hi Jim,

Thanks for the reply. Please my responses in-line.

Maria

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, July 15, 2013 12:09 PM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Maria,

Thank you for your comments on our draft. Please see inline for responses.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten' <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>=
, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

=B7        Is it necessary to have a new header that identifies a service (=
called Base Header in the draft)? Base Header implies new forwarding paradi=
gm on the edge. In my opinion using MPLS labels to identify a service chain=
 and a specific service will do the job.

Jim>  it is certainly a true statement that an MPLS label could be used (as=
suming that the network environment supports/deploys MPLS; a large assumpti=
on),

<MN> The draft introduces new encapsulation which would need to be supporte=
d at the network edge.
      At least, MPLS is not new ;-)

as could an IP tunnel, to get packets from point A to point B and at point =
B use said label value, or IP tunnel context, to indicate a given service f=
unction to be applied to the traffic. However, service chaining will requir=
e more than simply a forwarding mechanism between service functions: at a m=
inimum service visibility and information exchange will be key.

<MN> I am not sure what is meant by =93service visibility=94?
     MPLS label can be also used to identify the service. Metadata would fo=
llow MPLS label stack.

=B7        Having a Global service chain identifier (called Service Path wh=
ich is a part of Base Header) might not be a good idea. It will make servic=
e chaining less flexible. MPLS labels, on the other hand, have only local s=
ignificance.

Jim> could you provide a more detailed description of why service chaining =
would be less flexible if a global service chain identifier is adopted?

<MN> A specific service may belong to multiple service chains. IMO, a servi=
ce node should notbe aware of service chains it serves but only of whatserv=
ices it provides.
Since the draft makes the servicenodes aware of service chains, the service=
 nodes need to carry mappings between service chains and the services they =
provide. This introduces additional complexity on the service nodes.
For example, if a particular service is removed from a service chain, the s=
ervice_chain-to-service mapping has to be cleaned up on the removed service=
 node.
Assume initially, two flow classifications (say, class1 and class2) are map=
ped to the same service chain (say, chain1). Subsequently, class2 traffic n=
eeds one additional service in front of chain1. According to the draft, new=
 unique service chain has to be created (say, chain2) for class2 traffic. T=
his creates a lot of duplicated state. Hence, what is needed is a locally s=
ignificant chain identifier.
Since service chain identifiers have to be globally unique, maintaining the=
m will not be trivial.


[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_68B171751455884590F8E38E96416F363F5960F4xmbrcdx01ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <A0BBB120CA319B4B9515FB9FC095542D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; font-size: 14px; font-family: Calibri, sans-ser=
if; color: rgb(0, 0, 0); ">
<div>
<div style=3D"font-family: Calibri; font-size: medium; ">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; font-size: 14px; font-family: Calibri, sans-seri=
f; ">
<div style=3D"color: rgb(0, 0, 0); ">Hi Maria,</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">As I indicated in a previous&nbsp;<fon=
t>email</font>&nbsp;it is certainly possible, and valid, to build simple se=
rvice chains through construction of a forwarding&nbsp;<font color=3D"#cd1f=
07" style=3D"color: rgb(0, 0, 0); ">path</font>&nbsp;using
 import/export policy such as suggested in draft-rfernando-l3vpn-service-ch=
aining-01, or an MPLS label stack where each label in the stack provides co=
ntext to indicates which service function should be applied at which servic=
e hop.</div>
</div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; font-size: 14px; font-family: Calibri, sans-seri=
f; ">
<div><br>
</div>
<div>However, the problem space is much broader than this as we have tried =
to outline in draft-quinn-nsc-problem-statement-02. If it is necessary (and=
 I believe there are a growing number of use cases to support such an assum=
ption) to construct service chains
 that will require the passing of metadata between service functions along =
the chain then relying on IP forwarding or an MPLS label stack is not suffi=
cient; there needs to be additional intelligence that enables these existin=
g forwarding mechanisms to carry
 said metadata.</div>
<div><br>
</div>
<div>I outlined a possible method for this in draft-guichard-mpls-metadata-=
00; the proposed solution in that draft is to utilize the existing GAL labe=
l (rather than obtaining a reserved label that may only serve a single purp=
ose such as the passing of metadata
 relevant to service chaining) to indicate that metadata follows the label =
stack. As you will see in that draft, once you get past the label stack you=
 have to define a common format that is able to carry the metadata (we call=
 this a Metadata Channel Header
 (MCH) which would have a reserved type to signal the presence of NSH) and =
once you do that you have already gone above and beyond what existing stand=
ards provide whether it be IP or MPLS based. &nbsp;<font>The GAL label sign=
als the presence of the NSH service header,
 where we can leverage the chain (pathing) _and_ the service context header=
s.</font></div>
<div><font><br>
</font></div>
</div>
</div>
</div>
</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&lt;NAPIERALA&gt;, MARIA H &l=
t;<a href=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Monday, July 15, 2013 2:48 PM=
<br>
<span style=3D"font-weight:bold">To: </span>Microsoft Office User &lt;<a hr=
ef=3D"mailto:jguichar@cisco.com">jguichar@cisco.com</a>&gt;<br>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:nsc@iet=
f.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>FW: [nsc] Comments on draf=
t-quinn-nsh-00<br>
</div>
<div><br>
</div>
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:629045871;
	mso-list-template-ids:-1707463826;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1349528975;
	mso-list-template-ids:498245268;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">Hi Jim,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">Thanks for the reply. Please my responses in-line.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">Maria<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=
25); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho=
ma, sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; font-fami=
ly: Tahoma, sans-serif; "> Jim Guichard (jguichar) [<a href=3D"mailto:jguic=
har@cisco.com">mailto:jguichar@cisco.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:09 PM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; ">Hi Maria,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; ">Thank you for your comments on our draft. Pl=
ease see inline for responses.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 11pt; color: black; fon=
t-family: Calibri, sans-serif; ">From:
</span></b><span style=3D"font-size: 11pt; color: black; font-family: Calib=
ri, sans-serif; ">&lt;NAPIERALA&gt;, MARIA H &lt;<a href=3D"mailto:mn1921@a=
tt.com">mn1921@att.com</a>&gt;<br>
<b>Date: </b>Monday, July 15, 2013 11:23 AM<br>
<b>To: </b>'Thomas Narten' &lt;<a href=3D"mailto:narten@us.ibm.com">narten@=
us.ibm.com</a>&gt;<br>
<b>Cc: </b>&quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt=
;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;, Robert Raszuk &lt;<a=
 href=3D"mailto:robert@raszuk.net">robert@raszuk.net</a>&gt;<br>
<b>Subject: </b>Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.H=
IDDEN">narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; IMO, discussions about how best to encode stuf=
f is a tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; should focus discussion on whether some item o=
f information needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; be included in a packet or not, and the motiva=
tion/pros/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">I agree. I have three comments that fall in this ca=
tegory:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<!--[if !supportLists]--><span style=3D"font-size: 10pt; color: black; "><s=
pan style=3D"mso-list:Ignore">=B7<span style=3D"font:7.0pt &quot;Times New =
Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; color: b=
lack; font-family: 'Courier New'; ">Is it necessary to have a new header th=
at identifies a service (called Base Header in the draft)? Base Header impl=
ies new forwarding paradigm on the
 edge. In my opinion using MPLS labels to identify a service chain and a sp=
ecific service will do the job.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; ">Jim&gt; &nbsp;it is certainly a true statement that an MPL=
S label could be used (assuming that the network environment supports/deplo=
ys MPLS; a large assumption),<span style=3D"color:#1F497D"><o:p></o:p></spa=
n></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=
25); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&lt;MN&gt; The draft introduces new encapsulation which would nee=
d to be supported at the network edge. &nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;At least, MPLS is not new ;-)=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=
25); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; ">as could an IP tunnel,&nbsp;to get packets from point A to=
 point B and at point B use said label value, or IP tunnel context, to indi=
cate a given service function to be applied
 to the traffic.&nbsp;However, service chaining&nbsp;will require&nbsp;more=
 than simply a forwarding mechanism between service functions: at a minimum=
 service visibility and information exchange will be key.&nbsp;<span style=
=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=
25); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&lt;MN&gt; I am not sure what is meant by =93service visibility=
=94?
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPLS label can be also used to iden=
tify the service. Metadata would follow MPLS label stack.<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l1 level1 lfo4">
<!--[if !supportLists]--><span style=3D"font-size: 10pt; color: black; "><s=
pan style=3D"mso-list:Ignore">=B7<span style=3D"font:7.0pt &quot;Times New =
Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; color: b=
lack; font-family: 'Courier New'; ">Having a Global service chain identifie=
r (called Service Path which is a part of Base Header) might not be a good =
idea. It will make service chaining
 less flexible. MPLS labels, on the other hand, have only local significanc=
e.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; ">Jim&gt;&nbsp;could you provide a more detailed description=
 of why service chaining would be less flexible if a global service chain i=
dentifier is adopted?&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=
25); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">&lt;MN&gt; A specific service may belong to multiple service chai=
ns. IMO, a service node should not<span style=3D"color:#1F497D"></span>be a=
ware of service chains it serves but only of
 what<span style=3D"color:#1F497D"></span>services it provides.<span style=
=3D"color:#1F497D">
<o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">Since the draft makes the service<span style=3D"color:#1F497D"></=
span>nodes aware of service chains, the service nodes need to carry mapping=
<span style=3D"color:#1F497D">s</span> between
 service chains and the services they provide. This introduces additional c=
omplexity on the service nodes.
<span style=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">For example,
<span style=3D"color:#1F497D">i</span>f a particular service is removed fro=
m a service chain, the service_chain-to-service mapping has to be cleaned u=
p on the removed service node.<span style=3D"color:#1F497D"><o:p></o:p></sp=
an></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">Assume initially, two flow classifications (say, class1 and class=
2) are mapped to the same service chain (say, chain1). Subsequently, class2=
 traffic needs one additional service
 in front of chain1. According to the draft, new unique service chain has t=
o be created (say, chain2) for class2 traffic. This creates a lot of duplic=
ated state. Hence, what is needed is a locally significant chain identifier=
.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">Since service chain identifiers have to be globally unique, maint=
aining them will not be trivial.<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: black; font-f=
amily: Calibri, sans-serif; "><img border=3D"0" width=3D"83" height=3D"41" =
id=3D"_x0000_i1025" src=3D"rtfimage://"></span><span style=3D"font-size: 10=
pt; color: black; font-family: 'Courier New'; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; color: black; font=
-family: 'Courier New'; ">&gt; -----Original Message-----</span><span style=
=3D"font-size: 10pt; color: black; font-family: 'Courier New'; "><o:p></o:p=
></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; color: black; font=
-family: 'Courier New'; ">&gt; From: Thomas Narten &lt;<a href=3D"mailto:na=
rten@DOMAIN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size: 10pt; color: black; font-family: 'Courier =
New'; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; color: black; font=
-family: 'Courier New'; ">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:robe=
rt@DOMAIN.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size: 10pt; color: black; font-family: 'Courier =
New'; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; color: black; font=
-family: 'Courier New'; ">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDDEN"=
>nsc at ietf.org</a>&gt;
</span><span style=3D"font-size: 10pt; color: black; font-family: 'Courier =
New'; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; color: black; font=
-family: 'Courier New'; ">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size: 10pt; color: black; font-family: 'Courier =
New'; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">Robert Raszuk &lt;robert at raszuk.net&gt; writes:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; I have a basic question reg Network Service He=
ader draft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; Don't we already have sufficient room in v6 he=
ader (including it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; extension header) to embed services in it ? Do=
 we need to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; header each time someone proposes a new approa=
ch ;) ?<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">IMO, discussions about how best to encode stuff is =
a tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">should focus discussion on whether some item of inf=
ormation needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">be included in a packet or not, and the motivation/=
pros/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; Just like we can get service discovery accompl=
ished for free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt; embed service in its reachability advertisemen=
t:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&gt;
<a href=3D"http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-con=
test-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&quot;service discovery for free&quot; is an oxymor=
on. There are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">reasons why the above proposal is not a good idea. =
Encoding additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">semantics into IP addresses is fraught with difficu=
lties, and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">in very limited situations, the IETF has not been w=
illing to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; color: black; font-f=
amily: 'Courier New'; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: black; font-f=
amily: Calibri, sans-serif; ">&nbsp;</span><span style=3D"font-size: 10pt; =
color: black; font-family: 'Courier New'; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: black; font-f=
amily: Calibri, sans-serif; ">&nbsp;</span><span style=3D"font-size: 10pt; =
color: black; font-family: 'Courier New'; "><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_68B171751455884590F8E38E96416F363F5960F4xmbrcdx01ciscoc_--

From mn1921@att.com  Mon Jul 15 16:09:02 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B3411E8258 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 16:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.473
X-Spam-Level: 
X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbMz8ZaA3RY7 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 16:08:57 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09011E8109 for <nsc@ietf.org>; Mon, 15 Jul 2013 16:08:56 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 80184e15.2aaad5c15940.100067.00-542.284630.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 23:08:56 +0000 (UTC)
X-MXL-Hash: 51e481086a07d225-ec031a1342bdd91e23f0bf113abcfce8b3f15e4c
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 70184e15.0.100062.00-350.284607.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Mon, 15 Jul 2013 23:08:55 +0000 (UTC)
X-MXL-Hash: 51e4810707c6e8f9-23b1920de3510f47a5555e36eb471e508c631a03
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FN8tKA003189; Mon, 15 Jul 2013 19:08:55 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6FN8nYs003152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 19:08:51 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 15 Jul 2013 23:08:31 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 19:08:31 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "jguichar@cisco.com" <jguichar@cisco.com>
Thread-Topic: [nsc] Comments on draft-quinn-nsh-00
Thread-Index: AQHOgXWv1pEzluyOGkGkenYfxSqcd5ll9L9AgAAPSkCAABBJ4IAAgk8A//+9z4CAAAOvUA==
Date: Mon, 15 Jul 2013 23:08:31 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01203578@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.118.216]
Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01203578MISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=IP61/HTG c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=kkgtkFppdtMA:10 a=BUO9sMsmufgA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HqxhTrMpf]
X-AnalysisOut: [q0A:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=VnNF1IyMAAAA:8 ]
X-AnalysisOut: [a=2clOPd4PAAAA:8 a=DR_9I_piAAAA:8 a=2okh10NAP4UHDLlL6uMA:9]
X-AnalysisOut: [ a=CjuIK1q_8ugA:10 a=ZF8ZrD0BOmYA:10 a=kkUMZHjH4KkA:10 a=J]
X-AnalysisOut: [fD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=bDUki]
X-AnalysisOut: [_mJ7DgA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVk]
X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10]
X-AnalysisOut: [ a=Qyb49msDZF0pTBRj:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 23:09:02 -0000

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01203578MISOUT7MSGUSR9I_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jim,

Yes, metadata is required. A special purpose label would be used to indicat=
e the presence of metadata (as you indicated).  I am familiar with the meth=
od you suggested in the drafts (I actually read them all ;-).

I followed Thomas Narten suggestion (which is a good one) to "focus discuss=
ion on whether some item of information needs to be included in a packet or=
 not, and the motivation/pros/cons of doing that". I was trying to point ou=
t some potential "cons" with the approach defined in the draft under discus=
sion.

There are certainly solutions possible where NSH base header (and MCH) are =
not needed, and where is there is no global service chain identifier signal=
ed in the data plane. They just need to be documented.

Maria

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, July 15, 2013 6:33 PM
To: NAPIERALA, MARIA H
Cc: nsc@ietf.org<mailto:nsc@ietf.org>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Maria,

As I indicated in a previous email it is certainly possible, and valid, to =
build simple service chains through construction of a forwarding path using=
 import/export policy such as suggested in draft-rfernando-l3vpn-service-ch=
aining-01, or an MPLS label stack where each label in the stack provides co=
ntext to indicates which service function should be applied at which servic=
e hop.

However, the problem space is much broader than this as we have tried to ou=
tline in draft-quinn-nsc-problem-statement-02. If it is necessary (and I be=
lieve there are a growing number of use cases to support such an assumption=
) to construct service chains that will require the passing of metadata bet=
ween service functions along the chain then relying on IP forwarding or an =
MPLS label stack is not sufficient; there needs to be additional intelligen=
ce that enables these existing forwarding mechanisms to carry said metadata=
.

I outlined a possible method for this in draft-guichard-mpls-metadata-00; t=
he proposed solution in that draft is to utilize the existing GAL label (ra=
ther than obtaining a reserved label that may only serve a single purpose s=
uch as the passing of metadata relevant to service chaining) to indicate th=
at metadata follows the label stack. As you will see in that draft, once yo=
u get past the label stack you have to define a common format that is able =
to carry the metadata (we call this a Metadata Channel Header (MCH) which w=
ould have a reserved type to signal the presence of NSH) and once you do th=
at you have already gone above and beyond what existing standards provide w=
hether it be IP or MPLS based.  The GAL label signals the presence of the N=
SH service header, where we can leverage the chain (pathing) _and_ the serv=
ice context headers.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 2:48 PM
To: Microsoft Office User <jguichar@cisco.com<mailto:jguichar@cisco.com>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>
Subject: FW: [nsc] Comments on draft-quinn-nsh-00

Hi Jim,

Thanks for the reply. Please my responses in-line.

Maria

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, July 15, 2013 12:09 PM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Maria,

Thank you for your comments on our draft. Please see inline for responses.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten' <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>=
, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

*        Is it necessary to have a new header that identifies a service (ca=
lled Base Header in the draft)? Base Header implies new forwarding paradigm=
 on the edge. In my opinion using MPLS labels to identify a service chain a=
nd a specific service will do the job.

Jim>  it is certainly a true statement that an MPLS label could be used (as=
suming that the network environment supports/deploys MPLS; a large assumpti=
on),

<MN> The draft introduces new encapsulation which would need to be supporte=
d at the network edge.
      At least, MPLS is not new ;-)

as could an IP tunnel, to get packets from point A to point B and at point =
B use said label value, or IP tunnel context, to indicate a given service f=
unction to be applied to the traffic. However, service chaining will requir=
e more than simply a forwarding mechanism between service functions: at a m=
inimum service visibility and information exchange will be key.

<MN> I am not sure what is meant by "service visibility"?
     MPLS label can be also used to identify the service. Metadata would fo=
llow MPLS label stack.

*        Having a Global service chain identifier (called Service Path whic=
h is a part of Base Header) might not be a good idea. It will make service =
chaining less flexible. MPLS labels, on the other hand, have only local sig=
nificance.

Jim> could you provide a more detailed description of why service chaining =
would be less flexible if a global service chain identifier is adopted?

<MN> A specific service may belong to multiple service chains. IMO, a servi=
ce node should notbe aware of service chains it serves but only of whatserv=
ices it provides.
Since the draft makes the servicenodes aware of service chains, the service=
 nodes need to carry mappings between service chains and the services they =
provide. This introduces additional complexity on the service nodes.
For example, if a particular service is removed from a service chain, the s=
ervice_chain-to-service mapping has to be cleaned up on the removed service=
 node.
Assume initially, two flow classifications (say, class1 and class2) are map=
ped to the same service chain (say, chain1). Subsequently, class2 traffic n=
eeds one additional service in front of chain1. According to the draft, new=
 unique service chain has to be created (say, chain2) for class2 traffic. T=
his creates a lot of duplicated state. Hence, what is needed is a locally s=
ignificant chain identifier.
Since service chain identifiers have to be globally unique, maintaining the=
m will not be trivial.


[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_1D70D757A2C9D54D83B4CBD7625FA80E01203578MISOUT7MSGUSR9I_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:629045871;
	mso-list-template-ids:-1707463826;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1349528975;
	mso-list-template-ids:498245268;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Jim,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Yes, metadata is required. A special purpose label would b=
e used to indicate the presence of metadata (as you indicated). &nbsp;I am =
familiar with the method you suggested in the drafts
 (I actually read them all ;-).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">I followed Thomas Narten suggestion (which is a good one) =
to &#8220;focus discussion on whether some item of information needs to be =
included in a packet or not, and the motivation/pros/cons
 of doing that&#8221;. I was trying to point out some potential &#8220;cons=
&#8221; with the approach defined in the draft under discussion.<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">There are certainly solutions possible where NSH base head=
er (and MCH) are not needed, and where is there is no global service chain =
identifier signaled in the data plane. They just
 need to be documented.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;">Maria<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;"><o:p>&nbsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Jim Guic=
hard (jguichar) [<a href=3D"mailto:jguichar@cisco.com">mailto:jguichar@cisc=
o.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 6:33 PM<br>
<b>To:</b> NAPIERALA, MARIA H<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Hi Maria,<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">As I indicated in a previous=
&nbsp;email&nbsp;it is certainly possible, and valid, to build simple servi=
ce chains through construction of a forwarding&nbsp;path&nbsp;using import/=
export
 policy such as suggested in draft-rfernando-l3vpn-service-chaining-01, or =
an MPLS label stack where each label in the stack provides context to indic=
ates which service function should be applied at which service hop.<o:p></o=
:p></span></p>
</div>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">However, the problem space i=
s much broader than this as we have tried to outline in draft-quinn-nsc-pro=
blem-statement-02. If it is necessary (and I believe there
 are a growing number of use cases to support such an assumption) to constr=
uct service chains that will require the passing of metadata between servic=
e functions along the chain then relying on IP forwarding or an MPLS label =
stack is not sufficient; there needs
 to be additional intelligence that enables these existing forwarding mecha=
nisms to carry said metadata.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">I outlined a possible method=
 for this in draft-guichard-mpls-metadata-00; the proposed solution in that=
 draft is to utilize the existing GAL label (rather than
 obtaining a reserved label that may only serve a single purpose such as th=
e passing of metadata relevant to service chaining) to indicate that metada=
ta follows the label stack. As you will see in that draft, once you get pas=
t the label stack you have to define
 a common format that is able to carry the metadata (we call this a Metadat=
a Channel Header (MCH) which would have a reserved type to signal the prese=
nce of NSH) and once you do that you have already gone above and beyond wha=
t existing standards provide whether
 it be IP or MPLS based. &nbsp;The GAL label signals the presence of the NS=
H service header, where we can leverage the chain (pathing) _and_ the servi=
ce context headers.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:black">&lt;NAPIERALA&gt;, MARIA H &lt;<a href=
=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<b>Date: </b>Monday, July 15, 2013 2:48 PM<br>
<b>To: </b>Microsoft Office User &lt;<a href=3D"mailto:jguichar@cisco.com">=
jguichar@cisco.com</a>&gt;<br>
<b>Cc: </b>&quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt=
;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;<br>
<b>Subject: </b>FW: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Hi Jim,</span><span style=3D"color:black"><o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Thanks for the reply. Please my responses in-l=
ine.</span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Maria</span><span style=3D"color:black"><o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:black">From:</span></b><span sty=
le=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot=
;;color:black"> Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisco.c=
om">mailto:jguichar@cisco.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:09 PM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00</span><span style=
=3D"color:black"><o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span style=3D"color:black">&nbsp;<o:p></o:p></span>=
</p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Hi Maria,</span><span style=
=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D"=
color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Thank you for your comments =
on our draft. Please see inline for responses.&nbsp;</span><span style=3D"c=
olor:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D"=
color:black"><o:p></o:p></span></p>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:black">&lt;NAPIERALA&gt;, MARIA H &lt;<a href=
=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<b>Date: </b>Monday, July 15, 2013 11:23 AM<br>
<b>To: </b>'Thomas Narten' &lt;<a href=3D"mailto:narten@us.ibm.com">narten@=
us.ibm.com</a>&gt;<br>
<b>Cc: </b>&quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt=
;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;, Robert Raszuk &lt;<a=
 href=3D"mailto:robert@raszuk.net">robert@raszuk.net</a>&gt;<br>
<b>Subject: </b>Re: [nsc] Comments on draft-quinn-nsh-00</span><span style=
=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D"=
color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Thomas Narten &lt;<a href=3D"mailto:narten@DOM=
AIN.HIDDEN">narten at us.ibm.com</a>&gt; writes:</span><span style=3D"color=
:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; IMO, discussions about how best to encode=
 stuff is a tad premature. We</span><span style=3D"color:black"><o:p></o:p>=
</span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; should focus discussion on whether some i=
tem of information needs to</span><span style=3D"color:black"><o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; be included in a packet or not, and the m=
otivation/pros/cons of doing that.</span><span style=3D"color:black"><o:p><=
/o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">I agree. I have three comments that fall in th=
is category:</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=
or:black"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt=
 &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:10.0pt;font-family:=
&quot;Courier New&quot;;color:black">Is it necessary to have a new header t=
hat identifies a service (called Base Header in the draft)? Base Header imp=
lies new forwarding paradigm on the edge. In
 my opinion using MPLS labels to identify a service chain and a specific se=
rvice will do the job.</span><span style=3D"color:black"><o:p></o:p></span>=
</p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D"=
color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Jim&gt; &nbsp;it is certainl=
y a true statement that an MPLS label could be used (assuming that the netw=
ork environment supports/deploys MPLS; a large assumption),</span><span sty=
le=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&lt;MN&gt; The draft introduces new encapsulat=
ion which would need to be supported at the network edge. &nbsp;</span><spa=
n style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;At least, =
MPLS is not new ;-)</span><span style=3D"color:black"><o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">as could an IP tunnel,&nbsp;=
to get packets from point A to point B and at point B use said label value,=
 or IP tunnel context, to indicate a given service function to
 be applied to the traffic.&nbsp;However, service chaining&nbsp;will requir=
e&nbsp;more than simply a forwarding mechanism between service functions: a=
t a minimum service visibility and information exchange will be key.&nbsp;<=
/span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&lt;MN&gt; I am not sure what is meant by &#82=
20;service visibility&#8221;?
</span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPLS label can b=
e also used to identify the service. Metadata would follow MPLS label stack=
.</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D"=
color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l1 level1 lfo4">
<![if !supportLists]><span style=3D"font-size:10.0pt;font-family:Symbol;col=
or:black"><span style=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt=
 &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:10.0pt;font-family:=
&quot;Courier New&quot;;color:black">Having a Global service chain identifi=
er (called Service Path which is a part of Base Header) might not be a good=
 idea. It will make service chaining less flexible.
 MPLS labels, on the other hand, have only local significance.</span><span =
style=3D"color:black"><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D"=
color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Jim&gt;&nbsp;could you provi=
de a more detailed description of why service chaining would be less flexib=
le if a global service chain identifier is adopted?&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&lt;MN&gt; A specific service may belong to mu=
ltiple service chains. IMO, a service node should notbe aware of service ch=
ains it serves but only of whatservices it provides.</span><span style=3D"f=
ont-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1F497D">
</span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Since the draft makes the servicenodes aware o=
f service chains, the service nodes need to carry mapping</span><span style=
=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1F497D">s</=
span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;co=
lor:black">
 between service chains and the services they provide. This introduces addi=
tional complexity on the service nodes.
</span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">For example,
</span><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;=
color:#1F497D">i</span><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">f a particular service is removed from a servi=
ce chain, the service_chain-to-service mapping has to be
 cleaned up on the removed service node.</span><span style=3D"color:black">=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Assume initially, two flow classifications (sa=
y, class1 and class2) are mapped to the same service chain (say, chain1). S=
ubsequently, class2 traffic needs one additional
 service in front of chain1. According to the draft, new unique service cha=
in has to be created (say, chain2) for class2 traffic. This creates a lot o=
f duplicated state. Hence, what is needed is a locally significant chain id=
entifier.</span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Since service chain identifiers have to be glo=
bally unique, maintaining them will not be trivial.</span><span style=3D"co=
lor:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><img border=3D"0" width=3D"=
83" height=3D"41" id=3D"_x0000_i1025" src=3D"rtfimage://"></span><span styl=
e=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; -----Original Message-----</span><span st=
yle=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; From: Thomas Narten &lt;<a href=3D"mailto=
:narten@DOMAIN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:r=
obert@DOMAIN.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDD=
EN">nsc at ietf.org</a>&gt;
</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Robert Raszuk &lt;robert at raszuk.net&gt; wri=
tes:</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; I have a basic question reg Network Servi=
ce Header draft.</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Don't we already have sufficient room in =
v6 header (including it's</span><span style=3D"color:black"><o:p></o:p></sp=
an></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; extension header) to embed services in it=
 ? Do we need to invent new</span><span style=3D"color:black"><o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; header each time someone proposes a new a=
pproach ;) ?</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">IMO, discussions about how best to encode stuf=
f is a tad premature. We</span><span style=3D"color:black"><o:p></o:p></spa=
n></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">should focus discussion on whether some item o=
f information needs to</span><span style=3D"color:black"><o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">be included in a packet or not, and the motiva=
tion/pros/cons of doing that.</span><span style=3D"color:black"><o:p></o:p>=
</span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; Just like we can get service discovery ac=
complished for free when we</span><span style=3D"color:black"><o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt; embed service in its reachability adverti=
sement:</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&gt;
<a href=3D"http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-con=
test-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a></span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&quot;service discovery for free&quot; is an o=
xymoron. There are a ton of</span><span style=3D"color:black"><o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">reasons why the above proposal is not a good i=
dea. Encoding additional</span><span style=3D"color:black"><o:p></o:p></spa=
n></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">semantics into IP addresses is fraught with di=
fficulties, and except</span><span style=3D"color:black"><o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">in very limited situations, the IETF has not b=
een willing to do so.</span><span style=3D"color:black"><o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">Thomas</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:black">&nbsp;</span><span style=3D"color:black"><o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01203578MISOUT7MSGUSR9I_--

From liushucheng@huawei.com  Mon Jul 15 17:56:24 2013
Return-Path: <liushucheng@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C9E21E80F8 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 17:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzSsxV4DNleV for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 17:56:20 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B28B421E80CB for <nsc@ietf.org>; Mon, 15 Jul 2013 17:56:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVA92447; Tue, 16 Jul 2013 00:56:18 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 16 Jul 2013 01:55:43 +0100
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 16 Jul 2013 01:56:16 +0100
Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.169]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Tue, 16 Jul 2013 08:56:11 +0800
From: "Will Liu (Shucheng)" <liushucheng@huawei.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: New Version Notification for draft-liu-service-chaining-use-cases-01.txt
Thread-Index: AQHOgUMAko7qoXa1Sk2bxhwbeGMDtJlme4fQ
Date: Tue, 16 Jul 2013 00:56:10 +0000
Message-ID: <C9B5F12337F6F841B35C404CF0554ACB4B4B45EE@szxeml546-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.78.79]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [nsc] FW: New Version Notification for	draft-liu-service-chaining-use-cases-01.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 00:56:24 -0000

SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2Ygc2VydmljZSBjaGFpbmlu
ZyB1c2UgY2FzZXMgZG9jdW1lbnQuDQoNCllvdXIgY29tbWVudHMgYXJlIGhpZ2hseSBhcHByZWNp
YXRlZC4NCg0KUmVnYXJkcywNCldpbGwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll
dGYub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAxNSwgMjAxMyA2OjA2IFBNDQpUbzogV2lsbCBM
aXUgKFNodWNoZW5nKTsgSG9uZ3l1IExpIChKdWxpbyk7IEh1YW5neW9uZyAoT2xpdmVyKTsgV2ls
bCBMaXUgKFNodWNoZW5nKTsgTmljb2xhaSBMZXltYW5uOyBaaGVuIENhbw0KU3ViamVjdDogTmV3
IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtc2VydmljZS1jaGFpbmluZy11c2Ut
Y2FzZXMtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS1zZXJ2aWNl
LWNoYWluaW5nLXVzZS1jYXNlcy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0
ZWQgYnkgV2lsbChTaHVjaGVuZykgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv
cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbGl1LXNlcnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzDQpS
ZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBTZXJ2aWNlIENoYWluaW5nIFVzZSBDYXNlcw0KQ3JlYXRp
b24gZGF0ZToJIDIwMTMtMDctMTUNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVt
YmVyIG9mIHBhZ2VzOiA4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50
ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNlcy0wMS50eHQN
ClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1s
aXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LXNlcnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzLTAx
DQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0
LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNlcy0wMQ0KDQpBYnN0cmFjdDoNCiAgIEZvciBz
b21lIG5ldHdvcmsgc2VydmljZXMsIHRyYWZmaWMgaXMgZm9yd2FyZGVkIHRocm91Z2ggYSBzZXF1
ZW5jZSBvZg0KICAgbmV0d29yayBmdW5jdGlvbnMsIHdoaWNoIHVzdWFsbHkgaGF2ZSBkZWRpY2F0
ZWQgY2FwYWJpbGl0aWVzIG90aGVyDQogICB0aGFuIGZvcndhcmRpbmcsIGUuZy4gZmlyZXdhbGwu
ICBGb3J3YXJkaW5nIG9mIHRyYWZmaWMgYWxvbmcgYQ0KICAgc2VxdWVuY2Ugb2Ygc2VydmljZSBw
cm9jZXNzaW5nIGZ1bmN0aW9ucyBpcyB1c3VhbGx5IGJhc2VkIG9uIHNlcnZpY2UNCiAgIGNoYXJh
Y3RlcmlzdGljcywgYnV0IG5vdCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMuICBXZSBjYWxsIHN1Y2gg
d2F5IG9mDQogICBmb3J3YXJkaW5nIGFzIHNlcnZpY2UgY2hhaW5pbmcuICBUaGlzIG1lbW8gZGVz
Y3JpYmVzIHVzZSBjYXNlcyBvZg0KICAgc2VydmljZSBjaGFpbmluZy4NCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==

From seungiklee@gmail.com  Mon Jul 15 18:22:23 2013
Return-Path: <seungiklee@gmail.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0821F9951 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 18:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level: 
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqlaFh19HsEZ for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 18:22:21 -0700 (PDT)
Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id AAE2411E80F2 for <nsc@ietf.org>; Mon, 15 Jul 2013 18:22:05 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id cz11so62537qeb.36 for <nsc@ietf.org>; Mon, 15 Jul 2013 18:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sc8aXJZw/glR4JDB6EgeGhSAcz6xEChhvQZssSa7ugw=; b=y7RUdQvsz81XzendZuKcaHqSWyNBsepwk5Aiyk9FbRTlx+fnGZ1sCRi+l9ZWaAMina LZq6BhoTlI+tidaJUwcgUQymZHjs3rq4e5Vp/Pz61N3y2XrFacWmvC7fVoNpEKDUrfZM 4X4Guv2Ulmg3Byt3yjZxAzMPlPWX2I/W/i/rVMot7+cC3m5No5x8bvd8dY7SuUoeLif5 JaIzGZYJwiSDRFsOHqoARH46ldExucf5y6d/8Je3vaayCKI278nTv7VoDs5LMbyE6w69 /1owhyN4xJghth06Ob3/Eem1DD1qqWiqKA+PHj2m0HHtV9xZ75ZByM6tuRBBGZuWEtrI cyvw==
X-Received: by 10.49.41.6 with SMTP id b6mr53915101qel.13.1373937724214; Mon, 15 Jul 2013 18:22:04 -0700 (PDT)
MIME-Version: 1.0
Sender: seungiklee@gmail.com
Received: by 10.49.26.106 with HTTP; Mon, 15 Jul 2013 18:21:43 -0700 (PDT)
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A674D1F@MBX021-W3-CA-2.exch021.domain.local>
References: <20130715152326.5661.78824.idtracker@ietfa.amsl.com> <CAHMWmA8vNm3PB+jW02SE3ukC-RkOHqxWU1y-YM=aARegdqq5Ww@mail.gmail.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A674D1F@MBX021-W3-CA-2.exch021.domain.local>
From: Seung-Ik Lee <seungiklee@etri.re.kr>
Date: Tue, 16 Jul 2013 10:21:43 +0900
X-Google-Sender-Auth: HaJv4qVw5nXpQewyyL2U_koTGMc
Message-ID: <CAHMWmA8J+x6F6SjCkX0QgiYJ3duO+5NOXh8UBxFVwgwbuWrjVw@mail.gmail.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Fwd: New Version Notification for draft-lee-nsc-verification-problem-statement-01.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 01:22:23 -0000

Hello Ron,

Thank you for the comments.
Please see my in-line responses:

2013/7/16 Ron Parker <Ron_Parker@affirmednetworks.com>:
> Seung-Ik, et al,
>
> Thanks for contributing on this topic.
>
> If I read this correctly, you are interested in identifying the number of=
 rules that specify a particular network function instance.   One reason to=
 wish to do this is because there may be many service orchestrators in the =
network.   Do I have this correct?
>

Not about a physical instance but a logical function.
We think that the rule should specify logical network functions. The
corresponding physical service nodes and processes can be dynamically
located at invocation procedures.
For example, rule A specifies a logical function NFa in its service
chain. And NFa is deployed at LOCa and LOCb so that
system/administrator can automatically/manually select one of the
locators to invoke NFa according to the network or service status
(e.g., load or path strech).


> While it is informative to know how many rules, network wide, select a pa=
rticular network function instance, it would also be informative to know th=
e actual processing load on that network function instance.   The existence=
 of a rule doesn't imply that the rule is being executed with any particula=
r frequency.
>

You're correct. The existence of a rule does not imply that the rule
or target network function instances are being executed.
It just gives the *possibilities* of a use of network function (not an
instance but a logical one) and indicates that the corresponding
resources would be requested in the future.

The current verification approach in the draft is a sort of off-line
tools which indicates the relationships among the service chains in
terms of resources and rules.
Based on this idea, we are under study on an on-line verification
approach to see what happens with the service chains in the network
right now.
With this on-line approach, we expect that it can handle the actual
processing load of a network instance and the actual executions of the
rule.

> Also, in your proposal, how does the network function instance discover t=
hat it is referenced by a rule?   And conversely, how does it discover that=
 the reference is no longer valid?   Are there control plane requirements h=
ere?
>

We can formally check the occurrences of the network function in the
service chains.
We cannot see and don't care the validity of the reference to the
network function instance at this moment.
But this information would be helpful for verification and can be
obtained with additional control plane requirements.
Let us study further on it.

Thanks.

> Thanks.
>
>    Ron Parker
>    Affirmed Networks
>
>
> -----Original Message-----
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Seu=
ng-Ik Lee
> Sent: Monday, July 15, 2013 11:29 AM
> To: nsc@ietf.org
> Subject: [nsc] Fwd: New Version Notification for draft-lee-nsc-verificati=
on-problem-statement-01.txt
>
> FYI,
>
> We have submitted an I-D to address the problem of service chain conflict=
s with a verification method.
> Your comments are appreciated.
>
> Thanks.
>
> ---------- Forwarded message ----------
> From:  <internet-drafts@ietf.org>
> Date: 2013/7/16
> Subject: New Version Notification for
> draft-lee-nsc-verification-problem-statement-01.txt
> To: Myung-Ki Shin <mkshin@etri.re.kr>, Yoon-Chul Choi <cyc79@etri.re.kr>,=
 Seung-Ik Lee <seungiklee@etri.re.kr>
>
>
>
>
> A new version of I-D, draft-lee-nsc-verification-problem-statement-01.txt
> has been successfully submitted by Seung-Ik Lee and posted to the IETF re=
pository.
>
> Filename:        draft-lee-nsc-verification-problem-statement
> Revision:        01
> Title:           Problem statement for Verification of Network Service Ch=
ains
> Creation date:   2013-07-15
> Group:           Individual Submission
> Number of pages: 5
> URL:
> http://www.ietf.org/internet-drafts/draft-lee-nsc-verification-problem-st=
atement-01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-lee-nsc-verification-problem-statem=
ent
> Htmlized:
> http://tools.ietf.org/html/draft-lee-nsc-verification-problem-statement-0=
1
> Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-lee-nsc-verification-problem-sta=
tement-01
>
> Abstract:
>    This document addresses the possible conflicts between service
>    overlays in the network service chaining.  These conflicts are due to
>    overlapping in classification rules and resource sharing of service
>    overlays.  The verification of service chains provides a method for
>    network administrators to detect such conflicts and correct a
>    problematic service chain before applying it on the real network.
>
>
>
>
> The IETF Secretariat
>
>
>
> --
> Seung-Ik Lee (=EC=9D=B4=EC=8A=B9=EC=9D=B5)
> Protocol Engineering Center, ETRI
> Tel.    +82-42-860-1483
> Fax.   +82-42-861-5404
> Email. seungiklee@etri.re.kr; seungiklee@gmail.com ______________________=
_________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc



--=20
Seung-Ik Lee (=EC=9D=B4=EC=8A=B9=EC=9D=B5)
Protocol Engineering Center, ETRI
Tel.    +82-42-860-1483
Fax.   +82-42-861-5404
Email. seungiklee@etri.re.kr; seungiklee@gmail.com

From smkumar@cisco.com  Tue Jul 16 12:38:26 2013
Return-Path: <smkumar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50FC21F9E47 for <nsc@ietfa.amsl.com>; Tue, 16 Jul 2013 12:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.932
X-Spam-Level: 
X-Spam-Status: No, score=-8.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvj0-N1ypkNF for <nsc@ietfa.amsl.com>; Tue, 16 Jul 2013 12:38:22 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 56D6321F9C13 for <nsc@ietf.org>; Tue, 16 Jul 2013 12:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35390; q=dns/txt; s=iport; t=1374003501; x=1375213101; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=dV9K0ETNkUazzfk7kRxpVNnoCIpz0iNzlcS27mG7NAA=; b=eBvI1z0IESiyT/aSFjaT9clHyTMuZyNrtZ7BnjF3ppPwN/JMUgH4BbWb IShi+TwxZuOc6e6CgUWhE7GBSAaVWjW8Z4keqrMYmENI8GSl7dUa1qc+p 3+HDmqXFJRrn8JTJ9hBDjI7BXgb5esKHm2dYj9rfWGLA4Y/4bEVqt3/t2 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIGAO+f5VGtJXG//2dsb2JhbABQCoJCRDRPsAOJOIg9gRIWdIIjAQEBAgEBLUwFBwYBCBEDAQEBCxYBBjkUCAEIAgQBDQUIiAIFAQy1Y44jBIEHBgcTEQYBAgQDgwNtA4w9jEiFbIo4gxKBaEA
X-IronPort-AV: E=Sophos;i="4.89,679,1367971200";  d="scan'208,217";a="235599653"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jul 2013 19:38:20 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GJcKfp028007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 19:38:20 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 14:38:20 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Thread-Topic: [nsc] FW:  Comments on draft-quinn-nsh-00
Thread-Index: AQHOgXWv1pEzluyOGkGkenYfxSqcd5ll9L9AgAAPSkCAABBJ4IABf0YA
Date: Tue, 16 Jul 2013 19:38:19 +0000
Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C91DDEA1F2@xmb-aln-x09.cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012030D6@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [171.71.12.166]
Content-Type: multipart/alternative; boundary="_000_8E86B6E7C6FB9F40A00B0E269045A7C91DDEA1F2xmbalnx09ciscoc_"
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW:  Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 19:38:26 -0000

--_000_8E86B6E7C6FB9F40A00B0E269045A7C91DDEA1F2xmbalnx09ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Maria,

See comments inline.

Surendra.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 11:48 AM
To: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.com=
>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>
Subject: [nsc] FW: Comments on draft-quinn-nsh-00

Hi Jim,

Thanks for the reply. Please my responses in-line.

Maria

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Monday, July 15, 2013 12:09 PM
To: NAPIERALA, MARIA H; 'Thomas Narten'
Cc: nsc@ietf.org<mailto:nsc@ietf.org>; Robert Raszuk
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Maria,

Thank you for your comments on our draft. Please see inline for responses.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Monday, July 15, 2013 11:23 AM
To: 'Thomas Narten' <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>=
, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>> writes:

> IMO, discussions about how best to encode stuff is a tad premature. We
> should focus discussion on whether some item of information needs to
> be included in a packet or not, and the motivation/pros/cons of doing tha=
t.

I agree. I have three comments that fall in this category:

=B7        Is it necessary to have a new header that identifies a service (=
called Base Header in the draft)? Base Header implies new forwarding paradi=
gm on the edge. In my opinion using MPLS labels to identify a service chain=
 and a specific service will do the job.

Jim>  it is certainly a true statement that an MPLS label could be used (as=
suming that the network environment supports/deploys MPLS; a large assumpti=
on),

<MN> The draft introduces new encapsulation which would need to be supporte=
d at the network edge.
      At least, MPLS is not new ;-)

as could an IP tunnel, to get packets from point A to point B and at point =
B use said label value, or IP tunnel context, to indicate a given service f=
unction to be applied to the traffic. However, service chaining will requir=
e more than simply a forwarding mechanism between service functions: at a m=
inimum service visibility and information exchange will be key.

<MN> I am not sure what is meant by =93service visibility=94?
     MPLS label can be also used to identify the service. Metadata would fo=
llow MPLS label stack.

=B7        Having a Global service chain identifier (called Service Path wh=
ich is a part of Base Header) might not be a good idea. It will make servic=
e chaining less flexible. MPLS labels, on the other hand, have only local s=
ignificance.

Jim> could you provide a more detailed description of why service chaining =
would be less flexible if a global service chain identifier is adopted?

<MN> A specific service may belong to multiple service chains.
<SK> Indeed!
IMO, a service node should notbe aware of service chains it serves but only=
 of whatservices it provides.
<SK> In general I would tend to agree with notion that services should be f=
ocused on the service functions. A service has the service function and it =
may have a forwarding component or interact with one. The forwarding compon=
ent may be tasked to manipulate the service header. The network or the infr=
astructure may provide that for the service to integrate with (see below co=
mment as well) strongly or as a proxy. The header does not dictate any of t=
his. For those services that do own both the components, the draft does not=
 prevent the use of the header.
Since the draft makes the servicenodes aware of service chains, the service=
 nodes need to carry mappings between service chains and the services they =
provide. This introduces additional complexity on the service nodes.
<SK> Service nodes do not necessarily have to be aware of the service chain=
s. One way to achieve this is for the network to absorb the mappings and fe=
ed only the NSH payload to the services; likewise, the flip of it in the re=
verse direction. Again, the draft does not specify how to realize this and =
leaves it to the implementations.
For example, if a particular service is removed from a service chain, the s=
ervice_chain-to-service mapping has to be cleaned up on the removed service=
 node.
Assume initially, two flow classifications (say, class1 and class2) are map=
ped to the same service chain (say, chain1). Subsequently, class2 traffic n=
eeds one additional service in front of chain1. According to the draft, new=
 unique service chain has to be created (say, chain2) for class2 traffic. T=
his creates a lot of duplicated state. Hence, what is needed is a locally s=
ignificant chain identifier.
Since service chain identifiers have to be globally unique, maintaining the=
m will not be trivial.
<SK> This would be one way to implement it but not the only way. Draft does=
 not impose requirements on how to manipulate the service path or the servi=
ce index.


[X]
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com<mailto:narten@DOMAIN.HIDDEN>>
> To: Robert Raszuk <robert at raszuk.net<mailto:robert@DOMAIN.HIDDEN>>
> Cc: <nsc at ietf.org<mailto:nsc@DOMAIN.HIDDEN>>
> Date: Thu, 27 Jun 2013 09:29:56 -0400

Robert Raszuk <robert at raszuk.net> writes:

> I have a basic question reg Network Service Header draft.

> Don't we already have sufficient room in v6 header (including it's
> extension header) to embed services in it ? Do we need to invent new
> header each time someone proposes a new approach ;) ?

IMO, discussions about how best to encode stuff is a tad premature. We
should focus discussion on whether some item of information needs to
be included in a packet or not, and the motivation/pros/cons of doing that.

> Just like we can get service discovery accomplished for free when we
> embed service in its reachability advertisement:
> http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011=
-paper.pdf

"service discovery for free" is an oxymoron. There are a ton of
reasons why the above proposal is not a good idea. Encoding additional
semantics into IP addresses is fraught with difficulties, and except
in very limited situations, the IETF has not been willing to do so.

Thomas




--_000_8E86B6E7C6FB9F40A00B0E269045A7C91DDEA1F2xmbalnx09ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <3AAFEA5FAA1C0948B0D21493FC4B3E86@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>Maria,</div>
<div><br>
</div>
<div>See comments inline.</div>
<div><br>
</div>
<div>Surendra.</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&lt;NAPIERALA&gt;, MARIA H &l=
t;<a href=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Monday, July 15, 2013 11:48 A=
M<br>
<span style=3D"font-weight:bold">To: </span>&quot;Jim Guichard (jguichar)&q=
uot; &lt;<a href=3D"mailto:jguichar@cisco.com">jguichar@cisco.com</a>&gt;<b=
r>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:nsc@iet=
f.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>[nsc] FW: Comments on draf=
t-quinn-nsh-00<br>
</div>
<div><br>
</div>
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:629045871;
	mso-list-template-ids:-1707463826;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1349528975;
	mso-list-template-ids:498245268;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">Hi Jim,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">Thanks for the reply. Please my responses in-line.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">Maria<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho=
ma, sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; font-fami=
ly: Tahoma, sans-serif; "> Jim Guichard (jguichar) [<a href=3D"mailto:jguic=
har@cisco.com">mailto:jguichar@cisco.com</a>]
<br>
<b>Sent:</b> Monday, July 15, 2013 12:09 PM<br>
<b>To:</b> NAPIERALA, MARIA H; 'Thomas Narten'<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>; Robert Raszuk<=
br>
<b>Subject:</b> Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; color: black; ">Hi Maria,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; color: black; ">Thank you for your comments on our draft. Pl=
ease see inline for responses.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 11pt; font-family: Cali=
bri, sans-serif; color: black; ">From:
</span></b><span style=3D"font-size: 11pt; font-family: Calibri, sans-serif=
; color: black; ">&lt;NAPIERALA&gt;, MARIA H &lt;<a href=3D"mailto:mn1921@a=
tt.com">mn1921@att.com</a>&gt;<br>
<b>Date: </b>Monday, July 15, 2013 11:23 AM<br>
<b>To: </b>'Thomas Narten' &lt;<a href=3D"mailto:narten@us.ibm.com">narten@=
us.ibm.com</a>&gt;<br>
<b>Cc: </b>&quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt=
;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;, Robert Raszuk &lt;<a=
 href=3D"mailto:robert@raszuk.net">robert@raszuk.net</a>&gt;<br>
<b>Subject: </b>Re: [nsc] Comments on draft-quinn-nsh-00<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">Thomas Narten &lt;<a href=3D"mailto:narten@DOMAIN.H=
IDDEN">narten at us.ibm.com</a>&gt; writes:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; IMO, discussions about how best to encode stuf=
f is a tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; should focus discussion on whether some item o=
f information needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; be included in a packet or not, and the motiva=
tion/pros/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">I agree. I have three comments that fall in this ca=
tegory:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<!--[if !supportLists]--><span style=3D"font-size: 10pt; color: black; "><s=
pan style=3D"mso-list:Ignore">=B7<span style=3D"font-style: normal; font-va=
riant: normal; font-weight: normal; font-size: 7pt; line-height: normal; fo=
nt-family: 'Times New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; font-fam=
ily: 'Courier New'; color: black; ">Is it necessary to have a new header th=
at identifies a service (called Base Header in the draft)? Base Header impl=
ies new forwarding paradigm on the
 edge. In my opinion using MPLS labels to identify a service chain and a sp=
ecific service will do the job.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; ">Jim&gt; &nbsp;it is certainly a true statement that an MPL=
S label could be used (assuming that the network environment supports/deplo=
ys MPLS; a large assumption),<span style=3D"color:#1F497D"><o:p></o:p></spa=
n></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&lt;MN&gt; The draft introduces new encapsulation which would nee=
d to be supported at the network edge. &nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;At least, MPLS is not new ;-)=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; ">as could an IP tunnel,&nbsp;to get packets from point A to=
 point B and at point B use said label value, or IP tunnel context, to indi=
cate a given service function to be applied
 to the traffic.&nbsp;However, service chaining&nbsp;will require&nbsp;more=
 than simply a forwarding mechanism between service functions: at a minimum=
 service visibility and information exchange will be key.&nbsp;<span style=
=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&lt;MN&gt; I am not sure what is meant by =93service visibility=
=94?
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: 'Courie=
r New'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPLS label can be also used to iden=
tify the service. Metadata would follow MPLS label stack.<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l1 level1 lfo4">
<!--[if !supportLists]--><span style=3D"font-size: 10pt; color: black; "><s=
pan style=3D"mso-list:Ignore">=B7<span style=3D"font-style: normal; font-va=
riant: normal; font-weight: normal; font-size: 7pt; line-height: normal; fo=
nt-family: 'Times New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; font-fam=
ily: 'Courier New'; color: black; ">Having a Global service chain identifie=
r (called Service Path which is a part of Base Header) might not be a good =
idea. It will make service chaining
 less flexible. MPLS labels, on the other hand, have only local significanc=
e.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; font-family: Calibr=
i, sans-serif; ">Jim&gt;&nbsp;could you provide a more detailed description=
 of why service chaining would be less flexible if a global service chain i=
dentifier is adopted?&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">&lt;MN&gt; A specific service may belong to multiple service chai=
ns.</span></p>
</div>
</div>
</div>
</div>
</span>
<div>&lt;SK&gt; Indeed!</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">IMO, a service node should not<span style=3D"color:#1F497D"></spa=
n>be aware of service chains it serves but only of what<span style=3D"color=
:#1F497D"></span>services it provides.</span></p>
</div>
</div>
</div>
</div>
</span>
<div>&lt;SK&gt; In general I would tend to agree with notion that services =
should be focused on the service functions. A service has the service funct=
ion and it
<span style=3D"font-weight: bold; ">may</span> have a forwarding component =
or interact with one. The forwarding component may be tasked to manipulate =
the service header. The network or the infrastructure may provide that for =
the service to integrate with (see
 below comment as well) strongly or as a proxy. The header does not dictate=
 any of this. For those services that do own both the components, the draft=
 does not prevent the use of the header.</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; "><span style=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">Since the draft makes the service<span style=3D"color:#1F497D"></=
span>nodes aware of service chains, the service nodes need to carry mapping=
<span style=3D"color:#1F497D">s</span> between
 service chains and the services they provide. This introduces additional c=
omplexity on the service nodes.</span></p>
</div>
</div>
</div>
</div>
</span>
<div>&lt;SK&gt; Service nodes do not necessarily have to be aware of the se=
rvice chains. One way to achieve this is for the network to absorb the mapp=
ings and feed only the NSH payload to the services; likewise, the flip of i=
t in the reverse direction. Again, the
 draft does not specify how to realize this and leaves it to the implementa=
tions.</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; "><span style=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">For example,
<span style=3D"color:#1F497D">i</span>f a particular service is removed fro=
m a service chain, the service_chain-to-service mapping has to be cleaned u=
p on the removed service node.<span style=3D"color:#1F497D"><o:p></o:p></sp=
an></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">Assume initially, two flow classifications (say, class1 and class=
2) are mapped to the same service chain (say, chain1). Subsequently, class2=
 traffic needs one additional service
 in front of chain1. According to the draft, new unique service chain has t=
o be created (say, chain2) for class2 traffic. This creates a lot of duplic=
ated state. Hence, what is needed is a locally significant chain identifier=
.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; ">Since service chain identifiers have to be globally unique, maint=
aining them will not be trivial.</span></p>
</div>
</div>
</div>
</div>
</span>
<div>&lt;SK&gt; This would be one way to implement it but not the only way.=
 Draft does not impose requirements on how to manipulate the service path o=
r the service index.</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; "><o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: black; "><img border=3D"0" width=3D"83" height=3D"41" =
id=3D"_x0000_i1025" src=3D"rtfimage://"></span><span style=3D"font-size: 10=
pt; font-family: 'Courier New'; color: black; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; font-family: 'Cour=
ier New'; color: black; ">&gt; -----Original Message-----</span><span style=
=3D"font-size: 10pt; font-family: 'Courier New'; color: black; "><o:p></o:p=
></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; font-family: 'Cour=
ier New'; color: black; ">&gt; From: Thomas Narten &lt;<a href=3D"mailto:na=
rten@DOMAIN.HIDDEN">narten at us.ibm.com</a>&gt;
</span><span style=3D"font-size: 10pt; font-family: 'Courier New'; color: b=
lack; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; font-family: 'Cour=
ier New'; color: black; ">&gt; To: Robert Raszuk &lt;<a href=3D"mailto:robe=
rt@DOMAIN.HIDDEN">robert at raszuk.net</a>&gt;
</span><span style=3D"font-size: 10pt; font-family: 'Courier New'; color: b=
lack; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; font-family: 'Cour=
ier New'; color: black; ">&gt; Cc: &lt;<a href=3D"mailto:nsc@DOMAIN.HIDDEN"=
>nsc at ietf.org</a>&gt;
</span><span style=3D"font-size: 10pt; font-family: 'Courier New'; color: b=
lack; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; font-family: 'Cour=
ier New'; color: black; ">&gt; Date: Thu, 27 Jun 2013 09:29:56 -0400
</span><span style=3D"font-size: 10pt; font-family: 'Courier New'; color: b=
lack; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">Robert Raszuk &lt;robert at raszuk.net&gt; writes:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; I have a basic question reg Network Service He=
ader draft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; Don't we already have sufficient room in v6 he=
ader (including it's<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; extension header) to embed services in it ? Do=
 we need to invent new<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; header each time someone proposes a new approa=
ch ;) ?<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">IMO, discussions about how best to encode stuff is =
a tad premature. We<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">should focus discussion on whether some item of inf=
ormation needs to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">be included in a packet or not, and the motivation/=
pros/cons of doing that.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; Just like we can get service discovery accompl=
ished for free when we<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt; embed service in its reachability advertisemen=
t:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&gt;
<a href=3D"http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-con=
test-2011-paper.pdf">
http://telematics.tm.kit.edu/publications/Files/491/ipv6-app-contest-2011-p=
aper.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&quot;service discovery for free&quot; is an oxymor=
on. There are a ton of<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">reasons why the above proposal is not a good idea. =
Encoding additional<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">semantics into IP addresses is fraught with difficu=
lties, and except<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">in very limited situations, the IETF has not been w=
illing to do so.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">Thomas<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Courie=
r New'; color: black; ">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: black; ">&nbsp;</span><span style=3D"font-size: 10pt; =
font-family: 'Courier New'; color: black; "><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: black; ">&nbsp;</span><span style=3D"font-size: 10pt; =
font-family: 'Courier New'; color: black; "><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_8E86B6E7C6FB9F40A00B0E269045A7C91DDEA1F2xmbalnx09ciscoc_--

From damascene.joachimpillai@verizon.com  Mon Jul 15 10:57:30 2013
Return-Path: <damascene.joachimpillai@verizon.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA9721E80C6 for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 10:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.854
X-Spam-Level: 
X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyJOm2MShDEx for <nsc@ietfa.amsl.com>; Mon, 15 Jul 2013 10:57:23 -0700 (PDT)
Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D511E80DC for <nsc@ietf.org>; Mon, 15 Jul 2013 10:57:23 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 15 Jul 2013 17:57:19 +0000
From: "Joachimpillai, Damascene M" <damascene.joachimpillai@verizon.com>
X-IronPort-AV: E=Sophos;i="4.89,670,1367971200";  d="scan'208,217";a="517380338"
Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 15 Jul 2013 17:57:19 +0000
Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Mon, 15 Jul 2013 13:57:19 -0400
To: "nsc@ietf.org" <nsc@ietf.org>
Date: Mon, 15 Jul 2013 13:57:18 -0400
Thread-Topic: Presenting ForCES Applicability to NSC
Thread-Index: Ac6BhJtNPgOB++poTvmOvQcstZKDoQ==
Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4681@FHDP1LUMXC7V31.us.one.verizon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4681FHDP1LUMXC7V3_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 16 Jul 2013 12:53:05 -0700
Subject: [nsc] Presenting ForCES Applicability to NSC
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 17:57:30 -0000

--_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4681FHDP1LUMXC7V3_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I would like to request a slot to present ForCES applicability to NSC in th=
e upcoming BOF.

Regards,
DJ



--_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4681FHDP1LUMXC7V3_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi,<o:p></o:p></=
p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I would li=
ke to request a slot to present ForCES applicability to NSC in the upcoming=
 BOF.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
oNormal>Regards,<o:p></o:p></p><p class=3DMsoNormal>DJ<o:p></o:p></p><p cla=
ss=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p><=
/p></div></body></html>=

--_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4681FHDP1LUMXC7V3_--

From damascene.joachimpillai@verizon.com  Tue Jul 16 12:43:50 2013
Return-Path: <damascene.joachimpillai@verizon.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0821E8054 for <nsc@ietfa.amsl.com>; Tue, 16 Jul 2013 12:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level: 
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi+yYxm-7MdS for <nsc@ietfa.amsl.com>; Tue, 16 Jul 2013 12:43:45 -0700 (PDT)
Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4128421F9A72 for <nsc@ietf.org>; Tue, 16 Jul 2013 12:43:45 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 16 Jul 2013 19:43:44 +0000
From: "Joachimpillai, Damascene M" <damascene.joachimpillai@verizon.com>
X-IronPort-AV: E=Sophos;i="4.89,679,1367971200";  d="scan'208,217";a="518248687"
Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 16 Jul 2013 19:43:43 +0000
Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Tue, 16 Jul 2013 15:43:43 -0400
To: "nsc@ietf.org" <nsc@ietf.org>
Date: Tue, 16 Jul 2013 15:43:43 -0400
Thread-Topic: Presenting ForCES Applicability to NSC
Thread-Index: Ac6CXMcWB3LqUJkjRLujmVaqZ3c9Fw==
Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4EB4@FHDP1LUMXC7V31.us.one.verizon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4EB4FHDP1LUMXC7V3_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 16 Jul 2013 12:53:05 -0700
Subject: [nsc] Presenting ForCES Applicability to NSC
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 19:43:50 -0000

--_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4EB4FHDP1LUMXC7V3_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I would like to request a slot to present ForCES applicability to NSC in th=
e upcoming BOF.

Regards,
DJ


Damascene M Joachimpillai (DJ)
Systems Engineering, Internet Software and Technology Group | Verizon Corpo=
rate Technology
Tel: +1 781 466 1619 | Mob: +1 781 999 4620
60 Sylvan Drive, Waltham, MA, 02451, USA


Visit us at verizon.com/
Click here to Manage Your Account Online<http://enterprisecenter.verizon.co=
m/>


Twitter<https://twitter.com/VZenterprise>  |  Facebook<http://www.facebook.=
com/VerizonBusiness>   |  YouTube<http://www.youtube.com/user/verizonbusine=
ss>   |  LinkedIn<http://www.linkedin.com/company/verizon>


--_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4EB4FHDP1LUMXC7V3_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi,<o:p></o:p></=
p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I would li=
ke to request a slot to present ForCES applicability to NSC in the upcoming=
 BOF.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
oNormal>Regards,<o:p></o:p></p><p class=3DMsoNormal>DJ<o:p></o:p></p><p cla=
ss=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p><=
/p><p class=3DMsoNormal><b><span style=3D'font-size:9.0pt;font-family:"Aria=
l","sans-serif";color:#595959;mso-fareast-language:EN-GB'>Damascene M Joach=
impillai (DJ)<o:p></o:p></span></b></p><p class=3DMsoNormal><span style=3D'=
font-size:9.0pt;font-family:"Arial","sans-serif";color:#595959;mso-fareast-=
language:EN-GB'>Systems Engineering, Internet Software and Technology Group=
 | </span><b><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif=
";color:#C00000;mso-fareast-language:EN-GB'>Verizon Corporate Technology</s=
pan></b><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";col=
or:#595959;mso-fareast-language:EN-GB'><o:p></o:p></span></p><p class=3DMso=
Normal><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";colo=
r:#595959;mso-fareast-language:EN-GB'>Tel: +1 781 466 1619 | Mob: +1 781 99=
9 4620<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:9=
.0pt;font-family:"Arial","sans-serif";color:#595959;mso-fareast-language:EN=
-GB'>60 Sylvan Drive, Waltham, MA, 02451, USA<o:p></o:p></span></p><p class=
=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif=
";color:#595959;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Arial","sans-=
serif";color:#595959;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></=
p><p class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Arial","=
sans-serif";color:#595959;mso-fareast-language:EN-GB'>Visit us at </span><s=
pan style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497D=
'>verizon.com/</span><u><span style=3D'color:#1F497D'><o:p></o:p></span></u=
></p><p class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Arial=
","sans-serif";color:#595959;mso-fareast-language:EN-GB'>Click here to </sp=
an><u><span style=3D'color:blue'><a href=3D"http://enterprisecenter.verizon=
.com/"><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";colo=
r:blue'>Manage Your Account Online</span></a></span></u><span style=3D'colo=
r:#595959;mso-fareast-language:EN-GB'><o:p></o:p></span></p><p class=3DMsoN=
ormal><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'><o:p=
>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:9.0pt=
;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=3DM=
soNormal><a href=3D"https://twitter.com/VZenterprise"><span style=3D'font-s=
ize:9.0pt;font-family:"Arial","sans-serif";color:blue'>Twitter</span></a><s=
pan style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'> &nbsp;|&nbs=
p; </span><a href=3D"http://www.facebook.com/VerizonBusiness"><span style=
=3D'font-size:9.0pt;font-family:"Arial","sans-serif";color:blue'>Facebook</=
span></a><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>&=
nbsp;&nbsp; |&nbsp; </span><a href=3D"http://www.youtube.com/user/verizonbu=
siness"><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";col=
or:blue'>YouTube</span></a><span style=3D'font-size:9.0pt;font-family:"Aria=
l","sans-serif"'>&nbsp;&nbsp; |&nbsp; </span><a href=3D"http://www.linkedin=
.com/company/verizon"><span style=3D'font-size:9.0pt;font-family:"Arial","s=
ans-serif";color:blue'>LinkedIn</span></a><span style=3D'font-size:9.0pt;fo=
nt-family:"Arial","sans-serif"'><o:p></o:p></span></p><p class=3DMsoNormal>=
<o:p>&nbsp;</o:p></p></div></body></html>=

--_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB01214F4EB4FHDP1LUMXC7V3_--

From lucy.yong@huawei.com  Wed Jul 17 08:29:28 2013
Return-Path: <lucy.yong@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A098D11E8106 for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.313
X-Spam-Level: 
X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43gV9uj+qvKi for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:29:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC521E8050 for <nsc@ietf.org>; Wed, 17 Jul 2013 08:29:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN52434; Wed, 17 Jul 2013 15:29:21 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:28:23 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:29:16 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 08:29:14 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: New Version Notification for draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
Thread-Index: AQHOgDqz/fprVVYjXUy8vckKNjqxwJlpA3bQ
Date: Wed, 17 Jul 2013 15:29:13 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4527C4AD@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.133.69]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [nsc] FW: New Version Notification for	draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 15:29:28 -0000

DQpGWUkuIFRoaXMgZHJhZnQgcHJvcG9zZXMgdGhlIHVzZSBvZiBncmUtaW4tdWRwIGVuY2Fwc3Vs
YXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25z
IGFyZSB3ZWxjb21lLg0KDQpMdWN5DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll
dGYub3JnXQ0KPiBTZW50OiBTYXR1cmRheSwgSnVseSAxMywgMjAxMyA5OjM1IFBNDQo+IFRvOiBM
dWN5IHlvbmcNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15
b25nLWdyZS1pbi11ZHAtZW5jYXAtNC0NCj4gc2VydmljZS1jaGFpbmluZy0wMC50eHQNCj4gDQo+
IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteW9uZy1ncmUtaW4tdWRwLWVuY2FwLTQt
c2VydmljZS1jaGFpbmluZy0NCj4gMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt
aXR0ZWQgYnkgTHVjeSBZb25nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4N
Cj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQteW9uZy1ncmUtaW4tdWRwLWVuY2FwLTQtc2VydmljZS1j
aGFpbmluZw0KPiBSZXZpc2lvbjoJIDAwDQo+IFRpdGxlOgkJIEdSRS1pbi1VRFAgRW5jYXBzdWxh
dGlvbiBmb3IgU2VydmljZSBDaGFpbmluZw0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMw0K
PiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiA2DQo+
IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh
ZnQteW9uZy1ncmUtaW4tDQo+IHVkcC1lbmNhcC00LXNlcnZpY2UtY2hhaW5pbmctMDAudHh0DQo+
IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15
b25nLWdyZS1pbi11ZHAtDQo+IGVuY2FwLTQtc2VydmljZS1jaGFpbmluZw0KPiBIdG1saXplZDog
ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvbmctZ3JlLWluLXVkcC0N
Cj4gZW5jYXAtNC1zZXJ2aWNlLWNoYWluaW5nLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAg
IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdXNlIG9mIHRoZSBHUkUtaW4tVURQIGVuY2Fwc3VsYXRp
b24gW0dSRS1pbi0NCj4gICAgVURQXSBmb3IgdGhlIHBhY2tldCBlbmNhcHN1bGF0aW9uIGluIHNl
cnZpY2UgY2hhaW5pbmcuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp
YXQNCg0K

From Ron_Parker@affirmednetworks.com  Wed Jul 17 08:37:21 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C306811E8112 for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf561UrnUJlz for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:37:06 -0700 (PDT)
Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6E11E8109 for <nsc@ietf.org>; Wed, 17 Jul 2013 08:37:06 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 08:37:05 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: comments on draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
Thread-Index: Ac6DAxuZdz2jPIeWSGSlVnfO+RkXtw==
Date: Wed, 17 Jul 2013 15:37:04 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FD@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FDMBX021W3CA2exch_"
MIME-Version: 1.0
Subject: [nsc] comments on draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 15:37:22 -0000

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FDMBX021W3CA2exch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, Lucy.

I think the addition of the UDP entropy is a very valuable concept to bette=
r support ECMP, LAG, and RSS (within a multi-core network entity).

My question is what value is added by the GRE header?   As an alternative, =
have you considered a well-known NSH-in-UDP port instead of a well-known GR=
E-in-UDP port?

Thanks.

    Ron Parker
    Affirmed Networks


--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FDMBX021W3CA2exch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi, Lucy.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I think the addition of the UDP entropy is a very va=
luable concept to better support ECMP, LAG, and RSS (within a multi-core ne=
twork entity).<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">My question is what value is added by the GRE header=
?&nbsp;&nbsp; As an alternative, have you considered a well-known NSH-in-UD=
P port instead of a well-known GRE-in-UDP port?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; Ron Parker<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; Affirmed Networks<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FDMBX021W3CA2exch_--

From jdrake@juniper.net  Wed Jul 17 08:41:39 2013
Return-Path: <jdrake@juniper.net>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4151211E8116 for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.716
X-Spam-Level: 
X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=1.750,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwnJH-XbKNw1 for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:41:32 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 498B611E810A for <nsc@ietf.org>; Wed, 17 Jul 2013 08:41:32 -0700 (PDT)
Received: from mail209-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 15:41:31 +0000
Received: from mail209-tx2 (localhost [127.0.0.1])	by mail209-tx2-R.bigfish.com (Postfix) with ESMTP id 90B282C0150	for <nsc@ietf.org>; Wed, 17 Jul 2013 15:41:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VPS-21(zz9371Ic85fhdb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail209-tx2: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=jdrake@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail209-tx2 (localhost.localdomain [127.0.0.1]) by mail209-tx2 (MessageSwitch) id 137407568936979_16812; Wed, 17 Jul 2013 15:41:29 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.236])	by mail209-tx2.bigfish.com (Postfix) with ESMTP id F136CD8004E	for <nsc@ietf.org>; Wed, 17 Jul 2013 15:41:28 +0000 (UTC)
Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Jul 2013 15:41:28 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Jul 2013 08:41:28 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Wed, 17 Jul 2013 08:41:27 -0700
Received: from am1outboundpool.messaging.microsoft.com (213.199.154.208) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 17 Jul 2013 08:54:35 -0700
Received: from mail101-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE017.bigfish.com (10.3.207.139) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 15:41:24 +0000
Received: from mail101-am1 (localhost [127.0.0.1])	by mail101-am1-R.bigfish.com (Postfix) with ESMTP id B9724600FE	for <nsc@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Wed, 17 Jul 2013 15:41:24 +0000 (UTC)
Received: from mail101-am1 (localhost.localdomain [127.0.0.1]) by mail101-am1 (MessageSwitch) id 1374075680963235_27719; Wed, 17 Jul 2013 15:41:20 +0000 (UTC)
Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.246])	by mail101-am1.bigfish.com (Postfix) with ESMTP id DD2181A0046; Wed, 17 Jul 2013 15:41:20 +0000 (UTC)
Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 15:41:20 +0000
Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.14]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0329.000; Wed, 17 Jul 2013 15:41:20 +0000
From: John E Drake <jdrake@juniper.net>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] comments on draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
Thread-Index: Ac6DAxuZdz2jPIeWSGSlVnfO+RkXtwAAK/Bw
Date: Wed, 17 Jul 2013 15:41:19 +0000
Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E2073D107@BL2PRD0510MB349.namprd05.prod.outlook.com>
References: <CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FD@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FD@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.224.53]
Content-Type: multipart/alternative; boundary="_000_0182DEA5604B3A44A2EE61F3EE3ED69E2073D107BL2PRD0510MB349_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%AFFIRMEDNETWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
Subject: Re: [nsc] comments on	draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 15:41:39 -0000

--_000_0182DEA5604B3A44A2EE61F3EE3ED69E2073D107BL2PRD0510MB349_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ron,

That was our original proposal.  It was shot down by the UDP police because=
 it used too many of their precious ports.

Yours Irrespectively,

John

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P=
arker
Sent: Wednesday, July 17, 2013 8:37 AM
To: nsc@ietf.org
Subject: [nsc] comments on draft-yong-gre-in-udp-encap-4-service-chaining-0=
0.txt

Hi, Lucy.

I think the addition of the UDP entropy is a very valuable concept to bette=
r support ECMP, LAG, and RSS (within a multi-core network entity).

My question is what value is added by the GRE header?   As an alternative, =
have you considered a well-known NSH-in-UDP port instead of a well-known GR=
E-in-UDP port?

Thanks.

    Ron Parker
    Affirmed Networks


--_000_0182DEA5604B3A44A2EE61F3EE3ED69E2073D107BL2PRD0510MB349_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Ron,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">That was our original =
proposal.&nbsp; It was shot down by the UDP police because it used too many=
 of their precious ports.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Yours Irrespectively,<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">John<o:p></o:p></span>=
</p>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> nsc-boun=
ces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>Ron Parker<br>
<b>Sent:</b> Wednesday, July 17, 2013 8:37 AM<br>
<b>To:</b> nsc@ietf.org<br>
<b>Subject:</b> [nsc] comments on draft-yong-gre-in-udp-encap-4-service-cha=
ining-00.txt<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi, Lucy.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I think the addition of the UDP entropy is a very va=
luable concept to better support ECMP, LAG, and RSS (within a multi-core ne=
twork entity).<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">My question is what value is added by the GRE header=
?&nbsp;&nbsp; As an alternative, have you considered a well-known NSH-in-UD=
P port instead of a well-known GRE-in-UDP port?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; Ron Parker<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; Affirmed Networks<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_0182DEA5604B3A44A2EE61F3EE3ED69E2073D107BL2PRD0510MB349_--

From lucy.yong@huawei.com  Wed Jul 17 08:43:23 2013
Return-Path: <lucy.yong@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD6A21F9343 for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.333
X-Spam-Level: 
X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.265,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSCNjT6qkDWM for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 08:43:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 644F021F8F4F for <nsc@ietf.org>; Wed, 17 Jul 2013 08:43:17 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN53497; Wed, 17 Jul 2013 15:43:16 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:42:37 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 16:43:15 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 08:43:10 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] comments on draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
Thread-Index: Ac6DAxuZdz2jPIeWSGSlVnfO+RkXtwAAITxQ
Date: Wed, 17 Jul 2013 15:43:08 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4527C4F3@dfweml509-mbx.china.huawei.com>
References: <CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FD@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67A0FD@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.133.69]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4527C4F3dfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [nsc] comments on	draft-yong-gre-in-udp-encap-4-service-chaining-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 15:43:23 -0000

--_000_2691CE0099834E4A9C5044EEC662BB9D4527C4F3dfweml509mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ron,

As you see, gre header is used for encoding payload protocol type identific=
ation/demultiplexing. Without it, we have to burn UDP ports, i.e. destinati=
on ports, for each payload protocol that IP network may tunnel.

Thanks,
Lucy

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P=
arker
Sent: Wednesday, July 17, 2013 10:37 AM
To: nsc@ietf.org
Subject: [nsc] comments on draft-yong-gre-in-udp-encap-4-service-chaining-0=
0.txt

Hi, Lucy.

I think the addition of the UDP entropy is a very valuable concept to bette=
r support ECMP, LAG, and RSS (within a multi-core network entity).

My question is what value is added by the GRE header?   As an alternative, =
have you considered a well-known NSH-in-UDP port instead of a well-known GR=
E-in-UDP port?

Thanks.

    Ron Parker
    Affirmed Networks


--_000_2691CE0099834E4A9C5044EEC662BB9D4527C4F3dfweml509mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Ron,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">As you see, gre header=
 is used for encoding payload protocol type identification/demultiplexing. =
Without it, we have to burn UDP ports, i.e. destination ports, for each pay=
load protocol that IP network may tunnel.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Lucy<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> nsc-boun=
ces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>Ron Parker<br>
<b>Sent:</b> Wednesday, July 17, 2013 10:37 AM<br>
<b>To:</b> nsc@ietf.org<br>
<b>Subject:</b> [nsc] comments on draft-yong-gre-in-udp-encap-4-service-cha=
ining-00.txt<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi, Lucy.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I think the addition of the UDP entropy is a very va=
luable concept to better support ECMP, LAG, and RSS (within a multi-core ne=
twork entity).<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">My question is what value is added by the GRE header=
?&nbsp;&nbsp; As an alternative, have you considered a well-known NSH-in-UD=
P port instead of a well-known GRE-in-UDP port?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; Ron Parker<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; Affirmed Networks<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_2691CE0099834E4A9C5044EEC662BB9D4527C4F3dfweml509mbxchi_--

From lucy.yong@huawei.com  Wed Jul 17 11:44:27 2013
Return-Path: <lucy.yong@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A013421F9FE4 for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 11:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.35
X-Spam-Level: 
X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODwwqVM6Yydp for <nsc@ietfa.amsl.com>; Wed, 17 Jul 2013 11:44:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B875A21F9CA6 for <nsc@ietf.org>; Wed, 17 Jul 2013 11:44:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN62728; Wed, 17 Jul 2013 18:44:20 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 19:43:24 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 19:44:18 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 11:44:15 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: question to draft-patel-raszuk-bgp-vector-routing-00.txt
Thread-Index: Ac6DHaCg6QMVWqJGSlyvNPXV0nfJKw==
Date: Wed, 17 Jul 2013 18:44:14 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4527C65A@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.133.69]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4527C65Adfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: [nsc] question to draft-patel-raszuk-bgp-vector-routing-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 18:44:28 -0000

--_000_2691CE0099834E4A9C5044EEC662BB9D4527C65Adfweml509mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

I read this draft and understand the mechanism. My question is that, in the=
 service chaining,  it is rare that the route origin has the service chain =
knowledge and determines the service chain for the packets delivered to it.=
 It is often that the source of the forwarder or some controller has the kn=
owledge and makes the service chain decision on the packets delivered to a =
certain destination.

Thus, does the source forwarding point needs to advertise the route on beha=
lf of the route origin to make it work?  Will this create some problem?

Thanks,
Lucy



--_000_2691CE0099834E4A9C5044EEC662BB9D4527C65Adfweml509mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi Robert,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I read this draft and understand the mechanism. My q=
uestion is that, in the service chaining, &nbsp;it is rare that the route o=
rigin has the service chain knowledge and determines the service chain for =
the packets delivered to it. It is often
 that the source of the forwarder or some controller has the knowledge and =
makes the service chain decision on the packets delivered to a certain dest=
ination.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thus, does the source forwarding point needs to adve=
rtise the route on behalf of the route origin to make it work? &nbsp;Will t=
his create some problem?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks,<o:p></o:p></p>
<p class=3D"MsoNormal">Lucy<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_2691CE0099834E4A9C5044EEC662BB9D4527C65Adfweml509mbxchi_--

From linda.dunbar@huawei.com  Thu Jul 18 16:52:55 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B3521E818A for <nsc@ietfa.amsl.com>; Thu, 18 Jul 2013 16:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHCw6FRL7zZm for <nsc@ietfa.amsl.com>; Thu, 18 Jul 2013 16:52:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6090221E8187 for <nsc@ietf.org>; Thu, 18 Jul 2013 16:52:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO67663; Thu, 18 Jul 2013 23:52:45 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 00:52:02 +0100
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 00:52:43 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 16:52:40 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Diego R. Lopez" <diego@tid.es>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Thread-Topic: Questions to "draft-boucadair-network-function-chaining":
Thread-Index: Ac6EEeMD+H/GHyACSj6NwGXiidp5Mw==
Date: Thu, 18 Jul 2013 23:52:39 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4B078@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.150.41]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B4B078dfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: [nsc] Questions to "draft-boucadair-network-function-chaining":
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 23:52:55 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4B078dfweml509mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mohamed, et al

The examples in your draft for "Network Located Functions" are called  by m=
any people as Layer 4 to 7 services, such as Firewall, Security services, N=
AT, etc.
What does "Located" mean in your context?

How different is the term "DiffForward"  (differentiated forwarding procedu=
re) from traditional router's differentiated forwarding based on some prior=
ity bits?

Your draft touches upon "Network Located Function Map", are you advocating =
that this "Map" should be dynamically formed or adjusted from heartbeat mes=
sages sent from all the "Network Located Functions" scatted in the network?


It seems to me that your draft tries to cover three major categories:

-        Dynamic formulating the "Network Located Function Map"

o   i.e. monitoring all the network service functions scattered in the netw=
ork, and create a dynamic map of all those functions.

o   It is almost like "Topology discovery of all network functions". Correc=
t?



-        Automatically create chronology of service functions based on user=
 demand and network resource availability:

o   For example, client demand could be: "Traffic-Filtering-Criteria <-> a =
sequence of service modules {S1, S2}, where Si is generic function like Fir=
ewall or IPS.

o   Your draft states that there should be automation system that dynamical=
ly locate "Service Modules" for S1 and S2, and determine where traffic shou=
ld be steering to S1, and where traffic should be steering to S2. Is it cor=
rect?



-        Proper enforcement of selective traffic to go through their design=
ated "Service Functions" through the network.


Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4B078dfweml509mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:2065249496;
	mso-list-type:hybrid;
	mso-list-template-ids:1115954778 1013360006 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:20;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Mohamed, et al<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The examples in your draft for &#8220;Network Locate=
d Functions&#8221; are called &nbsp;by many people as Layer 4 to 7 services=
, such as Firewall, Security services, NAT, etc.
<o:p></o:p></p>
<p class=3D"MsoNormal">What does &#8220;Located&#8221; mean in your context=
?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none">How different is the t=
erm &#8220;DiffForward&#8221; &nbsp;(<span style=3D"font-size:9.0pt;font-fa=
mily:Courier">differentiated forwarding procedure)
</span>from traditional router&#8217;s differentiated forwarding based on s=
ome priority bits?<span style=3D"font-size:10.0pt;font-family:Courier"><o:p=
></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:10.0pt;font-family:Courier"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Your draft touches upon &#8220;Network Located Funct=
ion Map&#8221;, are you advocating that this &#8220;Map&#8221; should be dy=
namically formed or adjusted from heartbeat messages sent from all the &#82=
20;Network Located Functions&#8221; scatted in the network?
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">It seems to me that your draft tries to cover three =
major categories:<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></span><![endif]>Dynamic formulating the &#8220;Network Located Func=
tion Map&#8221;<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:1.0in;text-indent:-.25in=
;mso-list:l0 level2 lfo1">
<![if !supportLists]><span style=3D"font-family:&quot;Courier New&quot;"><s=
pan style=3D"mso-list:Ignore">o<span style=3D"font:7.0pt &quot;Times New Ro=
man&quot;">&nbsp;&nbsp;
</span></span></span><![endif]>i.e. monitoring all the network service func=
tions scattered in the network, and create a dynamic map of all those funct=
ions.
<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:1.0in;text-indent:-.25in=
;mso-list:l0 level2 lfo1">
<![if !supportLists]><span style=3D"font-family:&quot;Courier New&quot;"><s=
pan style=3D"mso-list:Ignore">o<span style=3D"font:7.0pt &quot;Times New Ro=
man&quot;">&nbsp;&nbsp;
</span></span></span><![endif]>It is almost like &#8220;Topology discovery =
of all network functions&#8221;. Correct?
<o:p></o:p></p>
<p class=3D"MsoListParagraph"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></span><![endif]>Automatically create chronology of service function=
s based on user demand and network resource availability:<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:1.0in;text-indent:-.25in=
;mso-list:l0 level2 lfo1">
<![if !supportLists]><span style=3D"font-family:&quot;Courier New&quot;"><s=
pan style=3D"mso-list:Ignore">o<span style=3D"font:7.0pt &quot;Times New Ro=
man&quot;">&nbsp;&nbsp;
</span></span></span><![endif]>For example, client demand could be: &#8220;=
Traffic-Filtering-Criteria &lt;-&gt; a sequence of service modules {S1, S2}=
, where Si is generic function like Firewall or IPS.
<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:1.0in;text-indent:-.25in=
;mso-list:l0 level2 lfo1">
<![if !supportLists]><span style=3D"font-family:&quot;Courier New&quot;"><s=
pan style=3D"mso-list:Ignore">o<span style=3D"font:7.0pt &quot;Times New Ro=
man&quot;">&nbsp;&nbsp;
</span></span></span><![endif]>Your draft states that there should be autom=
ation system that dynamically locate &#8220;Service Modules&#8221; for S1 a=
nd S2, and determine where traffic should be steering to S1, and where traf=
fic should be steering to S2. Is it correct?
<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:1.0in"><o:p>&nbsp;</o:p>=
</p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></span><![endif]>Proper enforcement of selective traffic to go throu=
gh their designated &#8220;Service Functions&#8221; through the network.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Linda Dunbar<o:p></o:p></p>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4B078dfweml509mbxchi_--

From hongyu.li@huawei.com  Thu Jul 18 20:34:12 2013
Return-Path: <hongyu.li@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A360011E8275 for <nsc@ietfa.amsl.com>; Thu, 18 Jul 2013 20:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.3
X-Spam-Level: 
X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TgUd6f7hrgg for <nsc@ietfa.amsl.com>; Thu, 18 Jul 2013 20:34:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23C9411E8271 for <nsc@ietf.org>; Thu, 18 Jul 2013 20:34:07 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO78551; Fri, 19 Jul 2013 03:34:05 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 04:33:21 +0100
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 04:34:03 +0100
Received: from szxeml560-mbx.china.huawei.com ([169.254.3.63]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 11:34:00 +0800
From: "Hongyu Li (Julio)" <hongyu.li@huawei.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: Another draft on Service Chaining Method with a Header //FW: New Version Notification for draft-niu-service-chaining-header-00.txt
Thread-Index: AQHOhDDOrWvoZO/Eck6m1SlpWYgV8Q==
Date: Fri, 19 Jul 2013 03:33:59 +0000
Message-ID: <6EB34CB5D82C4645B826C56144826EA97DF11425@szxeml560-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.114.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [nsc] Another draft on Service Chaining Method with a Header //FW: New Version Notification for draft-niu-service-chaining-header-00.txt
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 03:34:12 -0000

SGksDQoNCldlIGhhdmUgdXBsb2FkZWQgYSBkcmFmdCBwcm92aWRpbmcgYW5vdGhlciBtZXRob2Qg
d2l0aCBhIHNlcnZpY2UgaGVhZGVyLg0KDQpDaGVlcnMsDQpIb25neXUNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu
dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgMTUsIDIwMTMgODox
NCBQTQ0KVG86IEhvbmd5dSBMaSAoSnVsaW8pOyBKaWFuZ3l1YW5sb25nOyBOaXVsZWhvbmcNClN1
YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbml1LXNlcnZpY2UtY2hh
aW5pbmctaGVhZGVyLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1uaXUt
c2VydmljZS1jaGFpbmluZy1oZWFkZXItMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi
bWl0dGVkIGJ5IExlaG9uZyBOaXUgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N
Cg0KRmlsZW5hbWU6CSBkcmFmdC1uaXUtc2VydmljZS1jaGFpbmluZy1oZWFkZXINClJldmlzaW9u
OgkgMDANClRpdGxlOgkJIFNlcnZpY2UgQ2hhaW5pbmcgSGVhZGVyIGFuZCBTZXJ2aWNlIENoYWlu
aW5nIE1lY2hhbmlzbQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDctMTUNCkdyb3VwOgkJIEluZGl2
aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQpVUkw6ICAgICAgICAgICAgIGh0
dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5pdS1zZXJ2aWNlLWNoYWlu
aW5nLWhlYWRlci0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1uaXUtc2VydmljZS1jaGFpbmluZy1oZWFkZXINCkh0bWxpemVkOiAg
ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbml1LXNlcnZpY2UtY2hhaW5p
bmctaGVhZGVyLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh
IHNlcnZpY2UgY2hhaW5pbmcgbWVjaGFuaXNtLCB3aGljaCBpcyB1c2VkDQogICB0byBpbmRpY2F0
ZSB0aGUgZGF0YSBwYWNrZXRzIGdvaW5nIHRocm91Z2ggbXVsdGlwbGUgU2VydmljZQ0KICAgUHJv
Y2Vzc2luZyBFbnRpdGllcyBhbmQgcHJvY2Vzc2VkIGJ5IHRob3NlIFNlcnZpY2UgUHJvY2Vzc2lu
Zw0KICAgRW50aXRpZXMgd2l0aCBwcmVzZXQgb3JkZXIuIFRoaXMgZG9jdW1lbnQgYWxzbyBwcm92
aWRlcyBhIG5ldyBzZXJ2aWNlDQogICBjaGFpbmluZyBoZWFkZXIgZW5jYXBzdWxhdGlvbiBmb3Ig
cGFja2V0cyBpbiBhIHNlcnZpY2UgY2hhaW4uIFRoZQ0KICAgc3lzdGVtIGNhbiBnZXQgdGhlIGlu
Zm9ybWF0aW9uIG9mIHRoZSBuZXh0IFNlcnZpY2UgUHJvY2Vzc2luZyBFbnRpdHkNCiAgIHdoZXJl
IHRoZSBkYXRhIHBhY2tldCBzaG91bGQgZ28gYnkgY2hlY2tpbmcgdGhlIHNlcnZpY2UgY2hhaW5p
bmcNCiAgIGhlYWRlci4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRG
IFNlY3JldGFyaWF0DQoNCg==

From mn1921@att.com  Thu Jul 18 21:58:54 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1820C21E81B6 for <nsc@ietfa.amsl.com>; Thu, 18 Jul 2013 21:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.515
X-Spam-Level: 
X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8b2oUuQopyF for <nsc@ietfa.amsl.com>; Thu, 18 Jul 2013 21:58:47 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id E471621E81B7 for <nsc@ietf.org>; Thu, 18 Jul 2013 21:58:46 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 687c8e15.2aaaf964e940.8612508.00-510.23900081.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 19 Jul 2013 04:58:46 +0000 (UTC)
X-MXL-Hash: 51e8c78655218cce-d4b3ae016dc66edb5d5dd98e593b945c130e205d
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 587c8e15.0.8612503.00-300.23900066.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 19 Jul 2013 04:58:46 +0000 (UTC)
X-MXL-Hash: 51e8c7863b98d160-fe59f5c730ba31250506598abb983b5c2c4019ed
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6J4wjIl026645; Fri, 19 Jul 2013 00:58:45 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6J4wbqM026617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 00:58:43 -0400
Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 19 Jul 2013 04:58:26 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Fri, 19 Jul 2013 00:58:26 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "smkumar@cisco.com" <smkumar@cisco.com>
Thread-Topic: [nsc] FW:  Comments on draft-quinn-nsh-00
Thread-Index: AQHOglwM/lqj+DTtt0mpYMhGN7n3vplqiA7QgAAldPCAAB3MYIAAd/LwgAAvefA=
Date: Fri, 19 Jul 2013 04:58:26 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01205798@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.12.210]
Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01205798MISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=Hb+juF48 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=Xd9F2WBWzO0A:10 a=F7Y3WDz8uFUA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=ueHtt8qDd]
X-AnalysisOut: [IkA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=jSyKE18EWEGF3XV]
X-AnalysisOut: [UAnwA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA]
X-AnalysisOut: [:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=FgLpnA1__UN01ZdQLu]
X-AnalysisOut: [AA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10]
X-AnalysisOut: [ a=frz4AuCg-hUA:10 a=NAyk01pEcHNc6KLi:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: [nsc] FW:  FW:  Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 04:58:54 -0000

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01205798MISOUT7MSGUSR9I_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Surendra,

Thanks for clarifying few aspects of the proposal. Please see in-line.

Maria

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Tuesday, July 16, 2013 3:38 PM
To: NAPIERALA, MARIA H; Jim Guichard (jguichar)
Cc: nsc@ietf.org<mailto:nsc@ietf.org>
Subject: Re: [nsc] FW: Comments on draft-quinn-nsh-00

<MN> Cut off text.
[...]

<SK> In general I would tend to agree with notion that services should be f=
ocused on the service functions. A service has the service function and it =
may have a forwarding component or interact with one.
The forwarding component may be tasked to manipulate the service header. Th=
e network or the infrastructure may provide that for the service to integra=
te with (see below comment as well) strongly or as a proxy. The header does=
 not dictate any of this. For those services that do own both the component=
s, the draft does not prevent the use of the header.


<MN> Actually, the draft says that "Participating nodes *MUST* use the base=
 header for selecting the next service in the service path".

Commingling signaling of network connectivity with signaling of metadata is=
 unnecessary and counterproductive, IMO.






--_000_1D70D757A2C9D54D83B4CBD7625FA80E01205798MISOUT7MSGUSR9I_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle28
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle29
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">Surendra,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">Thanks for clarifying few aspects of the proposal. Please see in-line.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">Maria<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Surendra=
 Kumar (smkumar) [<a href=3D"mailto:smkumar@cisco.com">mailto:smkumar@cisco=
.com</a>]
<br>
<b>Sent:</b> Tuesday, July 16, 2013 3:38 PM<br>
<b>To:</b> NAPIERALA, MARIA H; Jim Guichard (jguichar)<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] FW: Comments on draft-quinn-nsh-00<o:p></o:p></sp=
an></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">&lt;MN&gt; Cut off text.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">[&#8230;]<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&lt;SK&gt; In general I woul=
d tend to agree with notion that services should be focused on the service =
functions. A service has the service function and it
<b>may</b> have a forwarding component or interact with one. </span><span s=
tyle=3D"font-size:8.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&qu=
ot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">The forwarding component may=
 be tasked to manipulate the service header. The network or the infrastruct=
ure may provide that for the service to integrate with (see
 below comment as well) strongly or as a proxy. The header does not dictate=
 any of this. For those services that do own both the components, the draft=
 does not prevent the use of the header.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:Consolas">&lt;MN&gt; Actually, the draft says that &#8220;</span><=
span lang=3D"EN" style=3D"font-size:11.0pt;font-family:Consolas">Participat=
ing nodes *<b>MUST</b>* use the base header for selecting the next service =
in the service path&#8221;. <o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:11.0pt;font-family:Consolas">Commingling signaling of network connectivit=
y with signaling of metadata is unnecessary and counterproductive, IMO. <o:=
p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:10.0pt;col=
or:black">&nbsp;</span><span lang=3D"EN" style=3D"font-size:11.0pt;font-fam=
ily:Consolas"><o:p></o:p></span></pre>
</div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><img border=3D"0" width=3D"=
5" height=3D"5" id=3D"_x0000_i1025" src=3D"rtfimage://"></span><span style=
=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:black">&nbsp=
;</span><span style=3D"color:#1F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01205798MISOUT7MSGUSR9I_--

From jguichar@cisco.com  Fri Jul 19 10:29:54 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7CA11E8147 for <nsc@ietfa.amsl.com>; Fri, 19 Jul 2013 10:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.181
X-Spam-Level: 
X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWHW-aBsOzot for <nsc@ietfa.amsl.com>; Fri, 19 Jul 2013 10:29:49 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8E29021F9D4C for <nsc@ietf.org>; Fri, 19 Jul 2013 10:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4998; q=dns/txt; s=iport; t=1374254984; x=1375464584; h=from:to:subject:date:message-id:mime-version; bh=+6+g9YWtvejDrnS76q0b1s/PhcjWLIdBcSbh2zMwOzg=; b=PtGNW85BFuA7TuV/1vS2nbqn50SZO3Il47F0Cfp52HgEqZHXLdfNaqY7 q0peCp3fCgX/vSPfDDmEdNaIqE5fp2Z0IYc1qdRIOa0rrFsSnxEtgbsfg QW0D1qQq4F6Uwik7+b+2bm9uXgAaluFdGkOqg4aIWzE7id3Q/xbVnJLSp U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAMF26VGtJV2d/2dsb2JhbABbgkJENVDASYEQFnSCJgEEJ0cdAQweVicEG4gIDJYtoEyOVwGBBoNIbgOZBpAkgxKBaAEfIg
X-IronPort-AV: E=Sophos;i="4.89,703,1367971200";  d="scan'208,217";a="237024145"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 19 Jul 2013 17:29:43 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6JHTg72005911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <nsc@ietf.org>; Fri, 19 Jul 2013 17:29:42 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 12:29:42 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: IETF 87 NSC BoF
Thread-Index: AQHOhKWNlKAmCdAXlkyHmg+EA7xg5Q==
Date: Fri, 19 Jul 2013 17:29:41 +0000
Message-ID: <68B171751455884590F8E38E96416F363F59B14F@xmb-rcd-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.212]
Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F59B14Fxmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: [nsc] IETF 87 NSC BoF
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 17:29:54 -0000

--_000_68B171751455884590F8E38E96416F363F59B14Fxmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greetings,


As you are hopefully aware by now a Network Service Chaining (NSC) BoF has =
been scheduled for IETF 87 in Berlin (Monday, July 29th, 1510-1610 CEST).  =
A preliminary (subject to change) agenda has been posted and may be found h=
ere -> http://tools.ietf.org/agenda/87/agenda-87-nsc.html. Presentations fo=
r the BoF will be posted the end of next week (week of July 21st) so that y=
ou have time to review them prior to the meeting in Berlin.


The primary goal of this BoF is to let network operators explain their NSC =
use cases and requirements so that the IETF is exposed to the problem space=
. Our agenda is therefore tailored toward that end. We hope that through th=
is use case discussion, the scope and broad industry interest for service c=
haining becomes apparent, as well as the need to start formally working on =
the problem space. Ideally, from this BoF, there will be enough consensus t=
o start planning for an NSC working group.


With the limited amount of time we have available we respectfully ask that =
you limit questions and comments during the BoF to the set of use cases pre=
sented. We have allocated 15 minutes at the end of the presentations for Q&=
A and with > 230 subscribers to our mailing list we expect a lively discuss=
ion!


Although this BoF is focused on the presentation of use cases and general s=
ervice chaining requirements, there are several NSC-related drafts posted (=
http://trac.tools.ietf.org/bof/trac/). Given the time constraints these doc=
uments will not be discussed during the BoF but we encourage you to review =
them as they provide informative context about the subject of service chain=
ing.

--_000_68B171751455884590F8E38E96416F363F59B14Fxmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <972FD5AF0E4BA2449C5FE4D060DD0098@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri">Greeting=
s,</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri; min-heig=
ht: 17.0px">
<br>
</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri">As you a=
re hopefully aware by now a Network Service Chaining (NSC) BoF has been sch=
eduled for IETF 87 in Berlin (Monday, July 29th, 1510-1610 CEST).&nbsp;&nbs=
p;A preliminary (subject to change) agenda has
 been posted and may be found here -&gt; http://tools.ietf.org/agenda/87/ag=
enda-87-nsc.html. Presentations for the BoF will be posted the end of next =
week (week of July 21st) so that you have time to review them prior to the =
meeting in Berlin.&nbsp;</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri; min-heig=
ht: 17.0px">
<br>
</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri">The prim=
ary goal of this BoF is to let network operators explain their NSC use case=
s and requirements so that the IETF is exposed to the problem space. Our ag=
enda is therefore tailored toward
 that end. We hope that through this use case discussion, the scope and bro=
ad industry interest for service chaining becomes apparent, as well as the =
need to start formally working on the problem space. Ideally, from this BoF=
, there will be enough consensus
 to start planning for an NSC working group.&nbsp;</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri; min-heig=
ht: 17.0px">
<br>
</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri">With the=
 limited amount of time we have available we respectfully ask that you limi=
t questions and comments during the BoF to the set of use cases presented. =
We have allocated 15 minutes at the
 end of the presentations for Q&amp;A and with &gt; 230 subscribers to our =
mailing list we expect a lively discussion!&nbsp;</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri; min-heig=
ht: 17.0px">
<br>
</p>
<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Calibri">Although=
 this BoF is focused on the presentation of use cases and general service c=
haining requirements, there are several NSC-related drafts posted (http://t=
rac.tools.ietf.org/bof/trac/). Given
 the time constraints these documents will not be discussed during the BoF =
but we encourage you to review them as they provide informative context abo=
ut the subject of service chaining.&nbsp;</p>
</div>
</body>
</html>

--_000_68B171751455884590F8E38E96416F363F59B14Fxmbrcdx01ciscoc_--

From jguichar@cisco.com  Fri Jul 19 12:24:08 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8260511E8158 for <nsc@ietfa.amsl.com>; Fri, 19 Jul 2013 12:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSAC09RQo7uz for <nsc@ietfa.amsl.com>; Fri, 19 Jul 2013 12:24:03 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BDADA21F9AA3 for <nsc@ietf.org>; Fri, 19 Jul 2013 12:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12200; q=dns/txt; s=iport; t=1374261843; x=1375471443; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=g9BaddimEJOcDu1i/gzND1yBA/+Ecf0W9wLkDedPLJE=; b=DfPT7b3GYwHROD+5aOU60SKA36F7k5Z0sRwIWAYifZ4b5plk+8fkzpXI mtoKWpiN/hx25BFrKSm3LiQFiVrWKLhU6/nXdMsSegpYAZaL4OabKHsAs ikvvRMpIPChcghYjb4iirD7GCFxySVpSOcxTHVunDQzCS8WENpXT6BEv5 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFALGR6VGtJXHA/2dsb2JhbABbgkJENVDASYERFnSCJAEBAQQtOhISAQgRAwEBAQsdORQIAQgCBAENBQiICLckj14NExEGAYMQbgOpKoMSgio
X-IronPort-AV: E=Sophos;i="4.89,704,1367971200";  d="scan'208,217";a="237074128"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 19 Jul 2013 19:23:50 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6JJNoc2000615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 19:23:50 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 14:23:49 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "Surendra Kumar (smkumar)" <smkumar@cisco.com>
Thread-Topic: [nsc] FW:  FW:  Comments on draft-quinn-nsh-00
Thread-Index: AQHOglwM/lqj+DTtt0mpYMhGN7n3vplqiA7QgAAldPCAAB3MYIAAd/LwgAAvefCAAQRNgA==
Date: Fri, 19 Jul 2013 19:23:49 +0000
Message-ID: <68B171751455884590F8E38E96416F363F59B444@xmb-rcd-x01.cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01205798@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.212]
Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F59B444xmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW:  FW:  Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 19:24:08 -0000

--_000_68B171751455884590F8E38E96416F363F59B444xmbrcdx01ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Maria,
The draft specifies that the participating node must use the base header fo=
r selecting the next service in the service path but its does not specify t=
hat the location of said next service must be carried in the header. There =
is therefore no co-mingling of network connectivity and signaling of metada=
ta implied in the wording of the draft.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Friday, July 19, 2013 12:58 AM
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com<mailto:smkumar@cisco.com>=
>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>
Subject: [nsc] FW: FW: Comments on draft-quinn-nsh-00

Surendra,

Thanks for clarifying few aspects of the proposal. Please see in-line.

Maria

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Tuesday, July 16, 2013 3:38 PM
To: NAPIERALA, MARIA H; Jim Guichard (jguichar)
Cc: nsc@ietf.org<mailto:nsc@ietf.org>
Subject: Re: [nsc] FW: Comments on draft-quinn-nsh-00

<MN> Cut off text.
[=85]

<SK> In general I would tend to agree with notion that services should be f=
ocused on the service functions. A service has the service function and it =
may have a forwarding component or interact with one.
The forwarding component may be tasked to manipulate the service header. Th=
e network or the infrastructure may provide that for the service to integra=
te with (see below comment as well) strongly or as a proxy. The header does=
 not dictate any of this. For those services that do own both the component=
s, the draft does not prevent the use of the header.


<MN> Actually, the draft says that =93Participating nodes *MUST* use the ba=
se header for selecting the next service in the service path=94.

Commingling signaling of network connectivity with signaling of metadata is=
 unnecessary and counterproductive, IMO.






--_000_68B171751455884590F8E38E96416F363F59B444xmbrcdx01ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <DE06DF0075360C42969D4311311AC369@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>Maria,</div>
<div>The draft specifies that the participating node must use the base head=
er for selecting the next service in the service path but its does
<span style=3D"font-weight: bold; ">not</span>&nbsp;specify that the locati=
on of said next service
<span style=3D"font-weight: bold; ">must</span>&nbsp;be carried in the head=
er. There is therefore no co-mingling of network connectivity and signaling=
 of metadata implied in the wording of the draft.&nbsp;</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&lt;NAPIERALA&gt;, MARIA H &l=
t;<a href=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Friday, July 19, 2013 12:58 A=
M<br>
<span style=3D"font-weight:bold">To: </span>&quot;Surendra Kumar (smkumar)&=
quot; &lt;<a href=3D"mailto:smkumar@cisco.com">smkumar@cisco.com</a>&gt;<br=
>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:nsc@iet=
f.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>[nsc] FW: FW: Comments on =
draft-quinn-nsh-00<br>
</div>
<div><br>
</div>
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle28
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle29
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">Surendra,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">Thanks for clarifying few aspects of the proposal. Please see in-line.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">Maria<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=
25); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho=
ma, sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; font-fami=
ly: Tahoma, sans-serif; "> Surendra Kumar (smkumar) [<a href=3D"mailto:smku=
mar@cisco.com">mailto:smkumar@cisco.com</a>]
<br>
<b>Sent:</b> Tuesday, July 16, 2013 3:38 PM<br>
<b>To:</b> NAPIERALA, MARIA H; Jim Guichard (jguichar)<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] FW: Comments on draft-quinn-nsh-00<o:p></o:p></sp=
an></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">&lt;MN&gt; Cut off text.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
">[=85]<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; ">&lt;SK&gt; In general I would tend to agree =
with notion that services should be focused on the service functions. A ser=
vice has the service function and it
<b>may</b> have a forwarding component or interact with one. </span><span s=
tyle=3D"font-size: 8.5pt; color: rgb(31, 73, 125); font-family: Calibri, sa=
ns-serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 8.5pt; color: black; font-=
family: Calibri, sans-serif; ">The forwarding component may be tasked to ma=
nipulate the service header. The network or the infrastructure may provide =
that for the service to integrate with
 (see below comment as well) strongly or as a proxy. The header does not di=
ctate any of this. For those services that do own both the components, the =
draft does not prevent the use of the header.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1=
25); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:Consolas">&lt;MN&gt; Actually, the draft says that =93</span><span=
 lang=3D"EN" style=3D"font-size:11.0pt;font-family:Consolas">Participating =
nodes *<b>MUST</b>* use the base header for selecting the next service in t=
he service path=94. <o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:11.0pt;font-family:Consolas">Commingling signaling of network connectivit=
y with signaling of metadata is unnecessary and counterproductive, IMO. <o:=
p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:10.0pt;col=
or:black">&nbsp;</span><span lang=3D"EN" style=3D"font-size:11.0pt;font-fam=
ily:Consolas"><o:p></o:p></span></pre>
</div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: black; font-f=
amily: Calibri, sans-serif; "><img border=3D"0" width=3D"5" height=3D"5" id=
=3D"_x0000_i1025" src=3D"rtfimage://"></span><span style=3D"font-size: 10pt=
; color: black; font-family: 'Courier New'; ">&nbsp;</span><span style=3D"c=
olor:#1F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: black; font-f=
amily: Calibri, sans-serif; ">&nbsp;</span><span style=3D"color:black"><o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: black; font-f=
amily: Calibri, sans-serif; ">&nbsp;</span><span style=3D"color:black"><o:p=
></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_68B171751455884590F8E38E96416F363F59B444xmbrcdx01ciscoc_--

From mn1921@att.com  Fri Jul 19 15:20:36 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6605B21E8091 for <nsc@ietfa.amsl.com>; Fri, 19 Jul 2013 15:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.527
X-Spam-Level: 
X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4PM9e8YC0kx for <nsc@ietfa.amsl.com>; Fri, 19 Jul 2013 15:20:29 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 22E8011E80DF for <nsc@ietf.org>; Fri, 19 Jul 2013 15:20:29 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id dabb9e15.5d518940.2061056.00-552.5739877.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 19 Jul 2013 22:20:29 +0000 (UTC)
X-MXL-Hash: 51e9bbad5ef9cfab-aaa3598d1da9ba1343f7b2ac4e2a80f44d5b63e2
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id babb9e15.0.2061044.00-332.5739832.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 19 Jul 2013 22:20:28 +0000 (UTC)
X-MXL-Hash: 51e9bbac34815d7b-5f06c8869ed304621dff373bd48e391f47bcbd8a
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6JMKQD3026886; Fri, 19 Jul 2013 18:20:27 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6JMKDPh026787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 18:20:20 -0400
Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 19 Jul 2013 22:20:01 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Fri, 19 Jul 2013 18:20:01 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "jguichar@cisco.com" <jguichar@cisco.com>
Thread-Topic: [nsc] FW:  FW:  Comments on draft-quinn-nsh-00
Thread-Index: AQHOhLWClnkBbRYB80e1YdQrmj/715lsiXvg
Date: Fri, 19 Jul 2013 22:20:00 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01205DDE@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.104.36]
Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01205DDEMISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=FtiyCRXq c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=lCoYrEqtJCoA:10 a=pJf8Lfpts84A:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=9wdBdeR05]
X-AnalysisOut: [60A:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=F8Lpj0PEnupa4Cm]
X-AnalysisOut: [n0msA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA]
X-AnalysisOut: [:10 a=Hz7IrDYlS0cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=]
X-AnalysisOut: [e0w-IzB58pvLsBhCQv0A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10]
X-AnalysisOut: [ a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=zkSNqnqqMMrFzK9n:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: [nsc] FW:  FW:  FW:  Comments on draft-quinn-nsh-00
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 22:20:36 -0000

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01205DDEMISOUT7MSGUSR9I_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jim,

In that case, the chain identifier is not needed. This information is alrea=
dy present, i.e., it is implicit in the chain's forwarding path (e.g., MPLS=
 VPN). Managing and carrying an explicit chain identifier is an unnecessary=
 overhead.

Maria

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Friday, July 19, 2013 3:24 PM
To: NAPIERALA, MARIA H; Surendra Kumar (smkumar)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: FW: Comments on draft-quinn-nsh-00

Maria,
The draft specifies that the participating node must use the base header fo=
r selecting the next service in the service path but its does not specify t=
hat the location of said next service must be carried in the header. There =
is therefore no co-mingling of network connectivity and signaling of metada=
ta implied in the wording of the draft.

From: <NAPIERALA>, MARIA H <mn1921@att.com<mailto:mn1921@att.com>>
Date: Friday, July 19, 2013 12:58 AM
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com<mailto:smkumar@cisco.com>=
>
Cc: "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>
Subject: [nsc] FW: FW: Comments on draft-quinn-nsh-00

Surendra,

Thanks for clarifying few aspects of the proposal. Please see in-line.

Maria

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Tuesday, July 16, 2013 3:38 PM
To: NAPIERALA, MARIA H; Jim Guichard (jguichar)
Cc: nsc@ietf.org<mailto:nsc@ietf.org>
Subject: Re: [nsc] FW: Comments on draft-quinn-nsh-00

<MN> Cut off text.
[...]

<SK> In general I would tend to agree with notion that services should be f=
ocused on the service functions. A service has the service function and it =
may have a forwarding component or interact with one.
The forwarding component may be tasked to manipulate the service header. Th=
e network or the infrastructure may provide that for the service to integra=
te with (see below comment as well) strongly or as a proxy. The header does=
 not dictate any of this. For those services that do own both the component=
s, the draft does not prevent the use of the header.


<MN> Actually, the draft says that "Participating nodes *MUST* use the base=
 header for selecting the next service in the service path".

Commingling signaling of network connectivity with signaling of metadata is=
 unnecessary and counterproductive, IMO.






--_000_1D70D757A2C9D54D83B4CBD7625FA80E01205DDEMISOUT7MSGUSR9I_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle28
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle29
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle30
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:#1F497D">Jim,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:#1F497D">In that case, the chain identifier is not needed. This info=
rmation is already present, i.e., it is implicit in the chain&#8217;s forwa=
rding path (e.g., MPLS VPN). Managing and
 carrying an explicit chain identifier is an unnecessary overhead.<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:#1F497D">Maria<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Jim Guic=
hard (jguichar) [mailto:jguichar@cisco.com]
<br>
<b>Sent:</b> Friday, July 19, 2013 3:24 PM<br>
<b>To:</b> NAPIERALA, MARIA H; Surendra Kumar (smkumar)<br>
<b>Cc:</b> nsc@ietf.org<br>
<b>Subject:</b> Re: [nsc] FW: FW: Comments on draft-quinn-nsh-00<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">Maria,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">The draft specifies that the=
 participating node must use the base header for selecting the next service=
 in the service path but its does
<b>not</b>&nbsp;specify that the location of said next service <b>must</b>&=
nbsp;be carried in the header. There is therefore no co-mingling of network=
 connectivity and signaling of metadata implied in the wording of the draft=
.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:black">&lt;NAPIERALA&gt;, MARIA H &lt;<a href=
=3D"mailto:mn1921@att.com">mn1921@att.com</a>&gt;<br>
<b>Date: </b>Friday, July 19, 2013 12:58 AM<br>
<b>To: </b>&quot;Surendra Kumar (smkumar)&quot; &lt;<a href=3D"mailto:smkum=
ar@cisco.com">smkumar@cisco.com</a>&gt;<br>
<b>Cc: </b>&quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt=
;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;<br>
<b>Subject: </b>[nsc] FW: FW: Comments on draft-quinn-nsh-00<o:p></o:p></sp=
an></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">Surendra,</span><span style=3D"color:black"><o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">&nbsp;</span><span style=3D"color:black"><o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">Thanks for clarifying few aspects of the proposal. Please see=
 in-line.</span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">&nbsp;</span><span style=3D"color:black"><o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">Maria</span><span style=3D"color:black"><o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:black">From:</span></b><span sty=
le=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot=
;;color:black"> Surendra Kumar (smkumar) [<a href=3D"mailto:smkumar@cisco.c=
om">mailto:smkumar@cisco.com</a>]
<br>
<b>Sent:</b> Tuesday, July 16, 2013 3:38 PM<br>
<b>To:</b> NAPIERALA, MARIA H; Jim Guichard (jguichar)<br>
<b>Cc:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] FW: Comments on draft-quinn-nsh-00</span><span st=
yle=3D"color:black"><o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span style=3D"color:black">&nbsp;<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">&lt;MN&gt; Cut off text.</span><span style=3D"color:black"><o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">[&#8230;]</span><span style=3D"color:black"><o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">&nbsp;</span><span style=3D"color:black"><o:p></o:p></span></=
p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">&lt;SK&gt; In general I woul=
d tend to agree with notion that services should be focused on the service =
functions. A service has the service function and it
<b>may</b> have a forwarding component or interact with one. </span><span s=
tyle=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.5pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:black">The forwarding component may=
 be tasked to manipulate the service header. The network or the infrastruct=
ure may provide that for the service to integrate with (see
 below comment as well) strongly or as a proxy. The header does not dictate=
 any of this. For those services that do own both the components, the draft=
 does not prevent the use of the header.</span><span style=3D"color:black">=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span style=
=3D"color:black"><o:p></o:p></span></p>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:Consolas;color:black">&lt;MN&gt; Actually, the draft says that &#8=
220;</span><span lang=3D"EN" style=3D"font-size:11.0pt;font-family:Consolas=
;color:black">Participating nodes *<b>MUST</b>* use the base header for sel=
ecting the next service in the service path&#8221;. </span><span style=3D"c=
olor:black"><o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:11.0pt;font-family:Consolas;color:black">Commingling signaling of network=
 connectivity with signaling of metadata is unnecessary and counterproducti=
ve, IMO. </span><span style=3D"color:black"><o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:10.0pt;col=
or:black">&nbsp;</span><span style=3D"color:black"><o:p></o:p></span></pre>
</div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><img border=3D"0" width=3D"=
5" height=3D"5" id=3D"_x0000_i1029" src=3D"rtfimage://"></span><span style=
=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:black">&nbsp=
;</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"color:black"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><span style=3D=
"color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01205DDEMISOUT7MSGUSR9I_--

From linda.dunbar@huawei.com  Sun Jul 21 16:20:45 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317D221F9BD8 for <nsc@ietfa.amsl.com>; Sun, 21 Jul 2013 16:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2NNn7m0Eufu for <nsc@ietfa.amsl.com>; Sun, 21 Jul 2013 16:20:41 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E330621F9BF3 for <nsc@ietf.org>; Sun, 21 Jul 2013 16:20:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVG87140; Sun, 21 Jul 2013 23:20:38 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 00:19:43 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 00:20:32 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Sun, 21 Jul 2013 16:20:29 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: IETF 87 NSC BoF
Thread-Index: AQHOhKWNlKAmCdAXlkyHmg+EA7xg5ZlvvH7Q
Date: Sun, 21 Jul 2013 23:20:28 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4BB50@dfweml509-mbx.china.huawei.com>
References: <68B171751455884590F8E38E96416F363F59B14F@xmb-rcd-x01.cisco.com>
In-Reply-To: <68B171751455884590F8E38E96416F363F59B14F@xmb-rcd-x01.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.151.147]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B4BB50dfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Subject: Re: [nsc] IETF 87 NSC BoF
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2013 23:20:45 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4BB50dfweml509mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jim, et al,

After reading all of the drafts posted in the NSC BoF website, I see three =
distinct problem spaces that are addressed by those drafts:


1.      Locating available Network service functions
"draft-boucadair-network-function-chaining" has very good description of th=
is problem space.

It reminds me of Rserpool WG. "Rserpool" focused on supporting high availab=
ility and scalability of applications through the use of pools of servers, =
whereas "Locating Network Service Functions" will be on monitoring and buil=
ding topology of available service functions (either on physical devices or=
 virtual devices).




2.      Creating chronology of service functions based on user demand and n=
etwork resource availability.

For any given network service function, there might be multiple service mod=
ules capable of doing the task. It can be challenging to build a service ch=
ain that maximizes the performance and minimizes the network resource used.

This categories reminds me of PCE. PCE is for computing optimal path, where=
as this space is for selecting set of service modules for traffic to traver=
se through and identifying  specific points (or nodes) in the network for t=
he selected traffic to be steered to the corresponding service modules.



3.      Methods along data path to enforce specific traffic going through t=
heir designated service functions.

There are several drafts proposing various methods to achieve this goal, su=
ch as l3vpn-service-chaining, metadata-header carried by IP or MPLS, etc.





I hope the BOF can be organized to associate use cases with their distinct =
problem space.



Linda Dunbar

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G=
uichard (jguichar)
Sent: Friday, July 19, 2013 12:30 PM
To: nsc@ietf.org
Subject: [nsc] IETF 87 NSC BoF


Greetings,



As you are hopefully aware by now a Network Service Chaining (NSC) BoF has =
been scheduled for IETF 87 in Berlin (Monday, July 29th, 1510-1610 CEST).  =
A preliminary (subject to change) agenda has been posted and may be found h=
ere -> http://tools.ietf.org/agenda/87/agenda-87-nsc.html. Presentations fo=
r the BoF will be posted the end of next week (week of July 21st) so that y=
ou have time to review them prior to the meeting in Berlin.



The primary goal of this BoF is to let network operators explain their NSC =
use cases and requirements so that the IETF is exposed to the problem space=
. Our agenda is therefore tailored toward that end. We hope that through th=
is use case discussion, the scope and broad industry interest for service c=
haining becomes apparent, as well as the need to start formally working on =
the problem space. Ideally, from this BoF, there will be enough consensus t=
o start planning for an NSC working group.



With the limited amount of time we have available we respectfully ask that =
you limit questions and comments during the BoF to the set of use cases pre=
sented. We have allocated 15 minutes at the end of the presentations for Q&=
A and with > 230 subscribers to our mailing list we expect a lively discuss=
ion!



Although this BoF is focused on the presentation of use cases and general s=
ervice chaining requirements, there are several NSC-related drafts posted (=
http://trac.tools.ietf.org/bof/trac/). Given the time constraints these doc=
uments will not be discussed during the BoF but we encourage you to review =
them as they provide informative context about the subject of service chain=
ing.

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4BB50dfweml509mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:147862296;
	mso-list-type:hybrid;
	mso-list-template-ids:-580648924 67698703 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1445686636;
	mso-list-type:hybrid;
	mso-list-template-ids:1927080730 -1509114470 67698691 67698693 67698689 67=
698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:"Times New Roman";}
@list l2
	{mso-list-id:2065249496;
	mso-list-type:hybrid;
	mso-list-template-ids:1115954778 1013360006 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l2:level1
	{mso-level-start-at:20;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:"Times New Roman";}
@list l2:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l2:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"word-wrap: bre=
ak-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Jim, et al,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">After reading all of the =
drafts posted in the NSC BoF website, I see three distinct problem spaces t=
hat are addressed by those drafts:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo3"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Locating availabl=
e Network service functions
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D=
">&#8220;draft-boucadair-network-function-chaining&#8221; has very good des=
cription of this problem space.
<o:p></o:p></span></p>
<pre style=3D"margin-left:.5in"><span style=3D"font-size:11.0pt;font-family=
:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">It reminds me of=
 Rserpool WG. &#8220;Rserpool&#8221; focused on supporting high availabilit=
y and scalability of applications through the use of pools of servers, wher=
eas &#8220;Locating Network Service Functions&#8221; will be on monitoring =
and building topology of available service functions (either on physical de=
vices or virtual devices). <o:p></o:p></span></pre>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D=
"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoListParagraph"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p><=
/span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo3"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Creating chronolo=
gy of service functions based on user demand and network resource availabil=
ity.
<o:p></o:p></span></p>
<p class=3D"MsoListParagraph"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">For any given netw=
ork service function, there might be multiple service modules capable of do=
ing the task. It can be challenging to build a service chain
 that maximizes the performance and minimizes the network resource used. &n=
bsp;<o:p></o:p></span></p>
<p class=3D"MsoListParagraph"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">This categories re=
minds me of PCE. PCE is for computing optimal path, whereas this space is f=
or selecting set of service modules for traffic to traverse
 through and identifying &nbsp;specific points (or nodes) in the network fo=
r the selected traffic to be steered to the corresponding service modules.
<o:p></o:p></span></p>
<p class=3D"MsoListParagraph"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p><=
/span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo3"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Methods along dat=
a path to enforce specific traffic going through their designated service f=
unctions.
<o:p></o:p></span></p>
<p class=3D"MsoListParagraph"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">There are several =
drafts proposing various methods to achieve this goal, such as l3vpn-servic=
e-chaining, metadata-header carried by IP or MPLS, etc.
 &nbsp;<o:p></o:p></span></p>
<p class=3D"MsoListParagraph"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p><=
/span></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:4.8pt"><span style=3D"fo=
nt-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:4.8pt"><span style=3D"fo=
nt-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color=
:#1F497D">I hope the BOF can be organized to associate use cases with their=
 distinct problem space.
<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:4.8pt"><span style=3D"fo=
nt-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color=
:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:4.8pt"><span style=3D"fo=
nt-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color=
:#1F497D">Linda Dunbar<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> nsc-boun=
ces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>Jim Guichard (jguichar)<br>
<b>Sent:</b> Friday, July 19, 2013 12:30 PM<br>
<b>To:</b> nsc@ietf.org<br>
<b>Subject:</b> [nsc] IETF 87 NSC BoF<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:8.5p=
t;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Greet=
ings,<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt;min-height: 17.0px"><span styl=
e=3D"font-size:8.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:8.5p=
t;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">As yo=
u are hopefully aware by now a Network Service Chaining (NSC) BoF has been =
scheduled for IETF 87 in Berlin (Monday, July 29th, 1510-1610
 CEST).&nbsp;&nbsp;A preliminary (subject to change) agenda has been posted=
 and may be found here -&gt; http://tools.ietf.org/agenda/87/agenda-87-nsc.=
html. Presentations for the BoF will be posted the end of next week (week o=
f July 21st) so that you have time to review
 them prior to the meeting in Berlin.&nbsp;<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt;min-height: 17.0px"><span styl=
e=3D"font-size:8.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:8.5p=
t;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">The p=
rimary goal of this BoF is to let network operators explain their NSC use c=
ases and requirements so that the IETF is exposed to the
 problem space. Our agenda is therefore tailored toward that end. We hope t=
hat through this use case discussion, the scope and broad industry interest=
 for service chaining becomes apparent, as well as the need to start formal=
ly working on the problem space.
 Ideally, from this BoF, there will be enough consensus to start planning f=
or an NSC working group.&nbsp;<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt;min-height: 17.0px"><span styl=
e=3D"font-size:8.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:8.5p=
t;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">With =
the limited amount of time we have available we respectfully ask that you l=
imit questions and comments during the BoF to the set of
 use cases presented. We have allocated 15 minutes at the end of the presen=
tations for Q&amp;A and with &gt; 230 subscribers to our mailing list we ex=
pect a lively discussion!&nbsp;<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt;min-height: 17.0px"><span styl=
e=3D"font-size:8.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:8.5p=
t;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Altho=
ugh this BoF is focused on the presentation of use cases and general servic=
e chaining requirements, there are several NSC-related drafts
 posted (http://trac.tools.ietf.org/bof/trac/). Given the time constraints =
these documents will not be discussed during the BoF but we encourage you t=
o review them as they provide informative context about the subject of serv=
ice chaining.&nbsp;<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4BB50dfweml509mbxchi_--

From mohamed.boucadair@orange.com  Mon Jul 22 01:39:42 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E330221F8468 for <nsc@ietfa.amsl.com>; Mon, 22 Jul 2013 01:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yJp0SixKCIz for <nsc@ietfa.amsl.com>; Mon, 22 Jul 2013 01:39:26 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C033B21E8050 for <nsc@ietf.org>; Mon, 22 Jul 2013 01:14:49 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D3DF532534D; Mon, 22 Jul 2013 10:13:30 +0200 (CEST)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AC10223805E; Mon, 22 Jul 2013 10:13:30 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 22 Jul 2013 10:13:30 +0200
From: <mohamed.boucadair@orange.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "Diego R. Lopez" <diego@tid.es>
Date: Mon, 22 Jul 2013 10:13:28 +0200
Thread-Topic: Questions to "draft-boucadair-network-function-chaining":
Thread-Index: Ac6Gs1PhrRxwShJGTNqPPg7rS+2nMQ==
Message-ID: <94C682931C08B048B7A8645303FDC9F36EE2DDBA81@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EE2DDBA81PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.22.74241
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Questions to "draft-boucadair-network-function-chaining":
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 08:40:00 -0000

--_000_94C682931C08B048B7A8645303FDC9F36EE2DDBA81PUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Linda,

Please see inline.

Cheers,
Med

De : Linda Dunbar [mailto:linda.dunbar@huawei.com]
Envoy=E9 : vendredi 19 juillet 2013 01:53
=C0 : Diego R. Lopez; BOUCADAIR Mohamed OLNC/OLN
Cc : nsc@ietf.org
Objet : Questions to "draft-boucadair-network-function-chaining":

Mohamed, et al

The examples in your draft for "Network Located Functions" are called  by m=
any people as Layer 4 to 7 services, such as Firewall, Security services, N=
AT, etc.
[Med] Saying L4-L7 is not accurate IMHO because some of these functions can=
 be enforced at Layer 3 for instance (e.g., NPTv6 (RFC 6296)). Restricting =
these functions to L4-L7 is a pre-requisite which is not required for this =
work. IMO, we should not make any assumption on the layer on which a functi=
on, located in administrative domain, act on. The exact characterization of=
 each of these functions is up to each administrative entity: it is deploym=
ent-specific and policy-based.

What does "Located" mean in your context?
[Med] The rationale behind that characterization is as follows: As you know=
 in order to deliver connectivity services, several functions are invoked; =
 some of these functions are ** located in the network side ** while others=
 are ** embedded in a host, a home router/CPE **. Examples of functions tha=
t are located in the host side or the CPE side include (non-exclusive list)=
: NAT44, A+P NAT, MAP-E CE, MAP-T CE, DHCP client, DHCP server, DNS resolve=
r, DNS proxy, NTP server, NTP Proxy, SIP Proxy Server, SIP User Agent, DNSS=
EC validator, cache, TCP profiler, IPv4 firewall, IPv6 firewall, DS-Lite B4=
 element, NAT64, etc. Orchestrating these functions is out of scope. Hence,=
 the need to characterize the brand of functions which are in scope: only t=
hose located in the network side (i.e., Network-Located Functions).
Note, the he use of "located" avoids any confusion that can be induced by "=
network function" since some may think these functions act at the "network =
layer"...which is not true.

How different is the term "DiffForward"  (differentiated forwarding procedu=
re) from traditional router's differentiated forwarding based on some prior=
ity bits?
[Med] Undertaking local decisions based on some priority criteria is more c=
lose to the notion of differentiated services...We are using DiffForward te=
rm in the sense of differentiated forwarding paths: distinct packets may fo=
llow distinct forwarding path under some classification conditions. These c=
lassification conditions are policy-driven. In order to benefit from this d=
ifferentiated forwarding behavior, some marking may be needed. The marking =
bits may be the same as the priority bits you mentioned or be new ones.

Your draft touches upon "Network Located Function Map", are you advocating =
that this "Map" should be dynamically formed or adjusted from heartbeat mes=
sages sent from all the "Network Located Functions" scatted in the network?
[Med] The proposed framework may accommodate that need but this is an OPTIO=
NAL feature. Please refer to http://tools.ietf.org/html/draft-boucadair-net=
work-function-chaining-02#section-6.7. Are you referring to such liveness d=
etection feature?


It seems to me that your draft tries to cover three major categories:
[Med] The document proposes an architecture framework document for the chai=
ning of functions. The document explains in particular the role of each fun=
ctional entity and the interactions between these entities. It also identif=
ies and discusses some deployment options. The overall architecture is poli=
cy-driven. How these policies are generated and what are the required input=
 to the decision-making process is orthogonal to the architectural discussi=
ons.


-          Dynamic formulating the "Network Located Function Map"

o   i.e. monitoring all the network service functions scattered in the netw=
ork, and create a dynamic map of all those functions.

o   It is almost like "Topology discovery of all network functions". Correc=
t?
[Med] These are optional feedback features. The overall architecture works =
without such dynamic detection and feedback means. The PDP (Policy Decision=
 Point) can be provisioned using both static of dynamic means.



-          Automatically create chronology of service functions based on us=
er demand and network resource availability:
[Med] Yes, this can be met with the proposed framework since the PDP is res=
ponsible for generating and enforcing the policies. Nevertheless, the docum=
ent does not make any assumption on the provisioning cycle and the interact=
ions with an administrator/user nor any order handling module. The usabilit=
y of the proposed architecture is another dimension that can be detailed fu=
rther if needed.

o   For example, client demand could be: "Traffic-Filtering-Criteria <-> a =
sequence of service modules {S1, S2}, where Si is generic function like Fir=
ewall or IPS.

o   Your draft states that there should be automation system that dynamical=
ly locate "Service Modules" for S1 and S2, and determine where traffic shou=
ld be steering to S1, and where traffic should be steering to S2. Is it cor=
rect?



-          Proper enforcement of selective traffic to go through their desi=
gnated "Service Functions" through the network.
[Med] Yes.

Linda Dunbar

--_000_94C682931C08B048B7A8645303FDC9F36EE2DDBA81PUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Micr=
osoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"Pr=E9format=E9 HTML Car";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PrformatHTMLCar
	{mso-style-name:"Pr=E9format=E9 HTML Car";
	mso-style-priority:99;
	mso-style-link:"Pr=E9format=E9 HTML";
	font-family:Consolas;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
p.HTMLPreformatted, li.HTMLPreformatted, div.HTMLPreformatted
	{mso-style-name:"HTML Preformatted";
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Courier New";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:2065249496;
	mso-list-type:hybrid;
	mso-list-template-ids:1115954778 1013360006 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:20;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:10.0pt;font-family:"Courier New";color:#1F497D'>Dear Linda,<o:p></=
o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-fa=
mily:"Courier New";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMs=
oNormal><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F=
497D'>Please see inline.=A0 <o:p></o:p></span></p><p class=3DMsoNormal><spa=
n style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'><o:p>&=
nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;=
font-family:"Courier New";color:#1F497D'>Cheers,<o:p></o:p></span></p><p cl=
ass=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier New";c=
olor:#1F497D'>Med<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'=
font-size:10.0pt;font-family:"Courier New";color:#1F497D'><o:p>&nbsp;</o:p>=
</span></p><div style=3D'border:none;border-left:solid blue 1.5pt;padding:0=
cm 0cm 0cm 4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF 1=
.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span style=3D'font=
-size:10.0pt;font-family:"Tahoma","sans-serif"'>De&nbsp;:</span></b><span s=
tyle=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Linda Dunbar [=
mailto:linda.dunbar@huawei.com] <br><b>Envoy=E9&nbsp;:</b> vendredi 19 juil=
let 2013 01:53<br><b>=C0&nbsp;:</b> Diego R. Lopez; BOUCADAIR Mohamed OLNC/=
OLN<br><b>Cc&nbsp;:</b> nsc@ietf.org<br><b>Objet&nbsp;:</b> Questions to &q=
uot;draft-boucadair-network-function-chaining&quot;:<o:p></o:p></span></p><=
/div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>M=
ohamed, et al<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p cl=
ass=3DMsoNormal>The examples in your draft for &#8220;Network Located Funct=
ions&#8221; are called &nbsp;by many people as Layer 4 to 7 services, such =
as Firewall, Security services, NAT, etc. <o:p></o:p></p><p class=3DMsoNorm=
al><b><i><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1=
F497D'>[Med] Saying L4-L7 is not accurate IMHO because some of these functi=
ons can be enforced at Layer 3 for instance (e.g., NPTv6 (RFC 6296)). Restr=
icting these functions to L4-L7 is a pre-requisite which is not required fo=
r this work. IMO, we should not make any assumption on the layer on which a=
 function, located in administrative domain, act on. The exact characteriza=
tion of each of these functions is up to each administrative entity: it is =
deployment-specific and policy-based.<o:p></o:p></span></i></b></p><p class=
=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier New";colo=
r:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal>What does &#822=
0;Located&#8221; mean in your context?<o:p></o:p></p><p class=3DMsoNormal><=
b><i><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497=
D'>[Med] The rationale behind that characterization is as follows: As you k=
now in order to deliver connectivity services, several functions are invoke=
d;=A0 some of these functions are ** located in the network side ** while o=
thers are ** embedded in a host, a home router/CPE **. Examples of function=
s that are located in the host side or the CPE side include (non-exclusive =
list): NAT44, A+P NAT, MAP-E CE, MAP-T CE, DHCP client, DHCP server, DNS re=
solver, DNS proxy, NTP server, NTP Proxy, SIP Proxy Server, SIP User Agent,=
 DNSSEC validator, cache, TCP profiler, IPv4 firewall, IPv6 firewall, DS-Li=
te B4 element, NAT64, etc. Orchestrating these functions is out of scope. H=
ence, the need to characterize the brand of functions which are in scope: o=
nly those located in the network side (i.e., Network-Located Functions). <o=
:p></o:p></span></i></b></p><p class=3DMsoNormal><b><i><span style=3D'font-=
size:10.0pt;font-family:"Courier New";color:#1F497D'>Note, the he use of &#=
8220;located&#8221; avoids any confusion that can be induced by &#8220;netw=
ork function&#8221; since some may think these functions act at the &#8220;=
network layer&#8221;&#8230;which is not true. <o:p></o:p></span></i></b></p=
><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier =
New";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=
=3D'text-autospace:none'>How different is the term &#8220;DiffForward&#8221=
; &nbsp;(<span style=3D'font-size:9.0pt;font-family:Courier'>differentiated=
 forwarding procedure) </span>from traditional router&#8217;s differentiate=
d forwarding based on some priority bits?<o:p></o:p></p><p class=3DMsoNorma=
l style=3D'text-autospace:none'><b><i><span style=3D'font-size:10.0pt;font-=
family:"Courier New";color:#1F497D'>[Med] Undertaking local decisions based=
 on some priority criteria is more close to the notion of differentiated se=
rvices&#8230;We are using DiffForward term in the sense of differentiated f=
orwarding paths: distinct packets may follow distinct forwarding path under=
 some classification conditions. These classification conditions are policy=
-driven. In order to benefit from this differentiated forwarding behavior, =
some marking may be needed. The marking bits may be the same as the priorit=
y bits you mentioned or be new ones. </span></i></b><span style=3D'font-siz=
e:10.0pt;font-family:"Courier New";color:#1F497D'><o:p></o:p></span></p><p =
class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:10=
.0pt;font-family:Courier'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal>=
Your draft touches upon &#8220;Network Located Function Map&#8221;, are you=
 advocating that this &#8220;Map&#8221; should be dynamically formed or adj=
usted from heartbeat messages sent from all the &#8220;Network Located Func=
tions&#8221; scatted in the network? <o:p></o:p></p><p class=3DMsoNormal><b=
><i><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D=
'>[Med] The proposed framework may accommodate that need but this is an OPT=
IONAL feature. Please refer to </span></i></b><a href=3D"http://tools.ietf.=
org/html/draft-boucadair-network-function-chaining-02#section-6.7"><b><i><s=
pan style=3D'font-size:10.0pt;font-family:"Courier New"'>http://tools.ietf.=
org/html/draft-boucadair-network-function-chaining-02#section-6.7</span></i=
></b></a><b><i><span style=3D'font-size:10.0pt;font-family:"Courier New";co=
lor:#1F497D'>. Are you referring to such liveness detection feature? </span=
></i></b><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1=
F497D'><o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p c=
lass=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>It seems to me t=
hat your draft tries to cover three major categories:<o:p></o:p></p><p clas=
s=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;font-family:"Courier Ne=
w";color:#1F497D'>[Med] The document proposes an architecture framework doc=
ument for the chaining of functions. The document explains in particular th=
e role of each functional entity and the interactions between these entitie=
s. It also identifies and discusses some deployment options. The overall ar=
chitecture is policy-driven. How these policies are generated and what are =
the required input to the decision-making process is orthogonal to the arch=
itectural discussions.</span></i></b><span style=3D'font-size:10.0pt;font-f=
amily:"Courier New";color:#1F497D'><o:p></o:p></span></p><p class=3DMsoNorm=
al><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMso=
ListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !=
supportLists]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "T=
imes New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></span><![endif]>Dynamic formulating the &#8220;Network Located Functio=
n Map&#8221;<o:p></o:p></p><p class=3DMsoListParagraph style=3D'margin-left=
:72.0pt;text-indent:-18.0pt;mso-list:l0 level2 lfo2'><![if !supportLists]><=
span style=3D'font-family:"Courier New"'><span style=3D'mso-list:Ignore'>o<=
span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp; </span></span></sp=
an><![endif]>i.e. monitoring all the network service functions scattered in=
 the network, and create a dynamic map of all those functions. <o:p></o:p><=
/p><p class=3DMsoListParagraph style=3D'margin-left:72.0pt;text-indent:-18.=
0pt;mso-list:l0 level2 lfo2'><![if !supportLists]><span style=3D'font-famil=
y:"Courier New"'><span style=3D'mso-list:Ignore'>o<span style=3D'font:7.0pt=
 "Times New Roman"'>&nbsp;&nbsp; </span></span></span><![endif]>It is almos=
t like &#8220;Topology discovery of all network functions&#8221;. Correct? =
<o:p></o:p></p><p class=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;f=
ont-family:"Courier New";color:#1F497D'>[Med] These are optional feedback f=
eatures. The overall architecture works without such dynamic detection and =
feedback means. The PDP (Policy Decision Point) can be provisioned using bo=
th static of dynamic means. </span></i></b><span style=3D'font-size:10.0pt;=
font-family:"Courier New";color:#1F497D'><o:p></o:p></span></p><p class=3DM=
soListParagraph><o:p>&nbsp;</o:p></p><p class=3DMsoListParagraph style=3D't=
ext-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span styl=
e=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Aut=
omatically create chronology of service functions based on user demand and =
network resource availability:<o:p></o:p></p><p class=3DMsoNormal><b><i><sp=
an style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>[Med]=
 Yes, this can be met with the proposed framework since the PDP is responsi=
ble for generating and enforcing the policies. Nevertheless, the document d=
oes not make any assumption on the provisioning cycle and the interactions =
with an administrator/user nor any order handling module. The usability of =
the proposed architecture is another dimension that can be detailed further=
 if needed.</span></i></b><span style=3D'font-size:10.0pt;font-family:"Cour=
ier New";color:#1F497D'><o:p></o:p></span></p><p class=3DMsoListParagraph s=
tyle=3D'margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level2 lfo2'><![=
if !supportLists]><span style=3D'font-family:"Courier New"'><span style=3D'=
mso-list:Ignore'>o<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;=
 </span></span></span><![endif]>For example, client demand could be: &#8220=
;Traffic-Filtering-Criteria &lt;-&gt; a sequence of service modules {S1, S2=
}, where Si is generic function like Firewall or IPS. <o:p></o:p></p><p cla=
ss=3DMsoListParagraph style=3D'margin-left:72.0pt;text-indent:-18.0pt;mso-l=
ist:l0 level2 lfo2'><![if !supportLists]><span style=3D'font-family:"Courie=
r New"'><span style=3D'mso-list:Ignore'>o<span style=3D'font:7.0pt "Times N=
ew Roman"'>&nbsp;&nbsp; </span></span></span><![endif]>Your draft states th=
at there should be automation system that dynamically locate &#8220;Service=
 Modules&#8221; for S1 and S2, and determine where traffic should be steeri=
ng to S1, and where traffic should be steering to S2. Is it correct? <o:p><=
/o:p></p><p class=3DMsoListParagraph style=3D'margin-left:72.0pt'><o:p>&nbs=
p;</o:p></p><p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-li=
st:l0 level1 lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>-<s=
pan style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Proper enforcement of select=
ive traffic to go through their designated &#8220;Service Functions&#8221; =
through the network. <o:p></o:p></p><p class=3DMsoNormal><b><i><span style=
=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>[Med] Yes.</s=
pan></i></b><o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p cla=
ss=3DMsoNormal>Linda Dunbar<o:p></o:p></p></div></div></body></html>=

--_000_94C682931C08B048B7A8645303FDC9F36EE2DDBA81PUEXCB1Bnante_--

From linda.dunbar@huawei.com  Mon Jul 22 16:45:00 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851E011E81A8 for <nsc@ietfa.amsl.com>; Mon, 22 Jul 2013 16:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5bZPlo5KA4I for <nsc@ietfa.amsl.com>; Mon, 22 Jul 2013 16:44:56 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CD11D11E819B for <nsc@ietf.org>; Mon, 22 Jul 2013 16:44:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR54725; Mon, 22 Jul 2013 23:44:48 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 00:43:26 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 00:44:18 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 16:44:14 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Diego R. Lopez" <diego@tid.es>
Thread-Topic: Questions to "draft-boucadair-network-function-chaining":
Thread-Index: Ac6Gs1PhrRxwShJGTNqPPg7rS+2nMQAfQDiA
Date: Mon, 22 Jul 2013 23:44:13 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4C1F6@dfweml509-mbx.china.huawei.com>
References: <94C682931C08B048B7A8645303FDC9F36EE2DDBA81@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE2DDBA81@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.151.196]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B4C1F6dfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Questions to "draft-boucadair-network-function-chaining":
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 23:45:00 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4C1F6dfweml509mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mohamed,

Thank you very much for the reply. More clarification questions are inserte=
d blow:


What does "Located" mean in your context?
[Med] The rationale behind that characterization is as follows: As you know=
 in order to deliver connectivity services, several functions are invoked; =
 some of these functions are ** located in the network side ** while others=
 are ** embedded in a host, a home router/CPE **. Examples of functions tha=
t are located in the host side or the CPE side include (non-exclusive list)=
: NAT44, A+P NAT, MAP-E CE, MAP-T CE, DHCP client, DHCP server, DNS resolve=
r, DNS proxy, NTP server, NTP Proxy, SIP Proxy Server, SIP User Agent, DNSS=
EC validator, cache, TCP profiler, IPv4 firewall, IPv6 firewall, DS-Lite B4=
 element, NAT64, etc. Orchestrating these functions is out of scope. Hence,=
 the need to characterize the brand of functions which are in scope: only t=
hose located in the network side (i.e., Network-Located Functions).

[Linda] That is a very interesting point. You are saying that all the funct=
ions listed above on the client side, or sometimes referred to as services =
associated with access routers, are not in the scope of the Network Located=
 Services.

Can you give some examples of services that are located "in the network sid=
e"?


Note, the he use of "located" avoids any confusion that can be induced by "=
network function" since some may think these functions act at the "network =
layer"...which is not true.




Your draft touches upon "Network Located Function Map", are you advocating =
that this "Map" should be dynamically formed or adjusted from heartbeat mes=
sages sent from all the "Network Located Functions" scatted in the network?
[Med] The proposed framework may accommodate that need but this is an OPTIO=
NAL feature. Please refer to http://tools.ietf.org/html/draft-boucadair-net=
work-function-chaining-02#section-6.7. Are you referring to such liveness d=
etection feature?

[Linda] Yes. But I think you need to include more dimensions in the Livenes=
s Detection. First of all, you need to specify different service categories=
: e.g. video optimization, content caching, security (DDoS prevention, SSL =
Inspection, Malware analysis, etc), HTTP message recognition, etc. This is =
a very big problem space already.

It seems to me that your draft tries to cover three major categories:
[Med] The document proposes an architecture framework document for the chai=
ning of functions. The document explains in particular the role of each fun=
ctional entity and the interactions between these entities. It also identif=
ies and discusses some deployment options. The overall architecture is poli=
cy-driven. How these policies are generated and what are the required input=
 to the decision-making process is orthogonal to the architectural discussi=
ons.
[Linda] do you mean network architecture? i.e. methods  to enforce selected=
 traffic to go through their designated service modules?


The PDP (Policy Decision Point) can be provisioned using both static of dyn=
amic means.

[Linda] is PDP more like "Policy Driven Traffic Steering Point"? It is less=
 about deciding policies, is it?



-        Automatically create chronology of service functions based on user=
 demand and network resource availability:
[Med] Yes, this can be met with the proposed framework since the PDP is res=
ponsible for generating and enforcing the policies.

[Linda] is PDP in the data path or an entity, that could be separated from =
data path,  for making the policy decision?

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4C1F6dfweml509mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
p.PrformatHTML, li.PrformatHTML, div.PrformatHTML
	{mso-style-name:"Pr\00E9format\00E9 HTML";
	mso-style-link:"Pr\00E9format\00E9 HTML Car";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PrformatHTMLCar
	{mso-style-name:"Pr\00E9format\00E9 HTML Car";
	mso-style-priority:99;
	mso-style-link:"Pr\00E9format\00E9 HTML";
	font-family:Consolas;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Courier New";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:2065249496;
	mso-list-type:hybrid;
	mso-list-template-ids:1115954778 1013360006 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:20;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Mohamed, <o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thank you very much fo=
r the reply. More clarification questions are inserted blow:
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">What does &#8220;Located&#8221; mean in your context=
?<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:10.0pt;font-family:&q=
uot;Courier New&quot;;color:#1F497D">[Med] The rationale behind that charac=
terization is as follows: As you know in order to deliver connectivity serv=
ices, several functions are invoked;&nbsp; some of
 these functions are ** located in the network side ** while others are ** =
embedded in a host, a home router/CPE **. Examples of functions that are lo=
cated in the host side or the CPE side include (non-exclusive list): NAT44,=
 A&#43;P NAT, MAP-E CE, MAP-T CE, DHCP
 client, DHCP server, DNS resolver, DNS proxy, NTP server, NTP Proxy, SIP P=
roxy Server, SIP User Agent, DNSSEC validator, cache, TCP profiler, IPv4 fi=
rewall, IPv6 firewall, DS-Lite B4 element, NAT64, etc. Orchestrating these =
functions is out of scope. Hence,
 the need to characterize the brand of functions which are in scope: only t=
hose located in the network side (i.e., Network-Located Functions).
<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0">[Linda] That is a v=
ery interesting point. You are saying that all the functions listed above o=
n the client side, or sometimes referred to as services associated with acc=
ess routers, are not in the scope of
 the Network Located Services. <o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0"><o:p>&nbsp;</o:p></=
span></b></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0">Can you give some e=
xamples of services that are located &#8220;in the network side&#8221;?
<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0"><o:p>&nbsp;</o:p></=
span></b></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0"><o:p>&nbsp;</o:p></=
span></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:10.0pt;font-family:&q=
uot;Courier New&quot;;color:#1F497D">Note, the he use of &#8220;located&#82=
21; avoids any confusion that can be induced by &#8220;network function&#82=
21; since some may think these functions act at the &#8220;network layer&#8=
221;&#8230;which
 is not true. <o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:10.0pt;font-family:Courier"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Your draft touches upon &#8220;Network Located Funct=
ion Map&#8221;, are you advocating that this &#8220;Map&#8221; should be dy=
namically formed or adjusted from heartbeat messages sent from all the &#82=
20;Network Located Functions&#8221; scatted in the network?
<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:10.0pt;font-family:&q=
uot;Courier New&quot;;color:#1F497D">[Med] The proposed framework may accom=
modate that need but this is an OPTIONAL feature. Please refer to
</span></i></b><a href=3D"http://tools.ietf.org/html/draft-boucadair-networ=
k-function-chaining-02#section-6.7"><b><i><span style=3D"font-size:10.0pt;f=
ont-family:&quot;Courier New&quot;">http://tools.ietf.org/html/draft-boucad=
air-network-function-chaining-02#section-6.7</span></i></b></a><b><i><span =
style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1F497D=
">.
 Are you referring to such liveness detection feature? </span></i></b><span=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1F497=
D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0">[Linda] Yes. But I =
think you need to include more dimensions in the Liveness Detection. First =
of all, you need to specify different service categories: e.g. video optimi=
zation, content caching, security (DDoS
 prevention, SSL Inspection, Malware analysis, etc), HTTP message recogniti=
on, etc. This is a very big problem space already.
<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal">It seems to me that your draft tries to cover three =
major categories:<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:10.0pt;font-family:&q=
uot;Courier New&quot;;color:#1F497D">[Med] The document proposes an archite=
cture framework document for the chaining of functions. The document explai=
ns in particular the role of each functional entity
 and the interactions between these entities. It also identifies and discus=
ses some deployment options. The overall architecture is policy-driven. How=
 these policies are generated and what are the required input to the decisi=
on-making process is orthogonal
 to the architectural discussions.<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0">[Linda] do you mean=
 network architecture? i.e. methods &nbsp;to enforce selected traffic to go=
 through their designated service modules?
<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:10.0pt;font-family:&q=
uot;Courier New&quot;;color:#1F497D">The PDP (Policy Decision Point) can be=
 provisioned using both static of dynamic means.
<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0">[Linda] is PDP more=
 like &#8220;Policy Driven Traffic Steering Point&#8221;? It is less about =
deciding policies, is it?
<o:p></o:p></span></b></p>
<p class=3D"MsoListParagraph"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;
</span></span><![endif]>Automatically create chronology of service function=
s based on user demand and network resource availability:<o:p></o:p></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:10.0pt;font-family:&q=
uot;Courier New&quot;;color:#1F497D">[Med] Yes, this can be met with the pr=
oposed framework since the PDP is responsible for generating and enforcing =
the policies.
</span></i></b><b><i><span style=3D"font-size:10.0pt;font-family:&quot;Cour=
ier New&quot;;color:#1F497D"><o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p=
></span></i></b></p>
<p class=3D"MsoNormal"><b><span style=3D"color:#7030A0">[Linda] is PDP in t=
he data path or an entity, that could be separated from data path, &nbsp;fo=
r making the policy decision?
<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p=
></span></i></b></p>
<p class=3D"MsoNormal">Linda Dunbar<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4C1F6dfweml509mbxchi_--

From wim.henderickx@alcatel-lucent.com  Wed Jul 24 02:52:03 2013
Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C06011E83F0 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 02:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.422
X-Spam-Level: 
X-Spam-Status: No, score=-9.422 tagged_above=-999 required=5 tests=[AWL=1.176,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQwpAmtu+V88 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 02:51:56 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 230D211E8156 for <nsc@ietf.org>; Wed, 24 Jul 2013 02:51:53 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6O9po6b017227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <nsc@ietf.org>; Wed, 24 Jul 2013 04:51:52 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6O9pjBd017315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <nsc@ietf.org>; Wed, 24 Jul 2013 11:51:50 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 11:51:44 +0200
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9Pw==
Date: Wed, 24 Jul 2013 09:51:44 +0000
Message-ID: <CE156BAC.6A02B%wim.henderickx@alcatel-lucent.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_CE156BAC6A02Bwimhenderickxalcatellucentcom_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 09:52:03 -0000

--_000_CE156BAC6A02Bwimhenderickxalcatellucentcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_CE156BAC6A02Bwimhenderickxalcatellucentcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <4425F0422B2F3F4587EE7BB849E88E73@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>I have a basic question with respect to the architecture/framework so =
far mentioned in the drafts in NSC. I understand the meta-data is a mechani=
sm to avoid multiple re-classifications when the packet enters the NSC doma=
in and identifies the chain of service
 functions. Now my understanding is that the services/applications are unaw=
are of the meta-data and that a layer underneath should provide the mediati=
on and that we use a well defined interface to the application/service to i=
ndicate the chain. In the context
 of Cloud/enterprise environment I can see this work given you can use a de=
dicate VLAN e.g. within the tenant. However we also try to address resident=
ial use cases for mobile and fixed and here this becomes more tricky afais.=
&nbsp;In the residential environment
 we can't expose a VLAN per application/service per chain since this would =
not be very effective. So I am wondering how we envision this to work?</div=
>
</body>
</html>

--_000_CE156BAC6A02Bwimhenderickxalcatellucentcom_--

From mohamed.boucadair@orange.com  Wed Jul 24 05:12:07 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDDE11E8205 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 05:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpfpM3QlqpKc for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 05:12:03 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D49DE11E80DC for <nsc@ietf.org>; Wed, 24 Jul 2013 05:12:02 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0883C2DCBAF; Wed, 24 Jul 2013 14:12:02 +0200 (CEST)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8C9B927C057; Wed, 24 Jul 2013 14:12:01 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 24 Jul 2013 14:12:01 +0200
From: <mohamed.boucadair@orange.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "Diego R.	Lopez" <diego@tid.es>
Date: Wed, 24 Jul 2013 14:11:59 +0200
Thread-Topic: Questions to "draft-boucadair-network-function-chaining":
Thread-Index: Ac6Gs1PhrRxwShJGTNqPPg7rS+2nMQAfQDiAAEzZinA=
Message-ID: <94C682931C08B048B7A8645303FDC9F36EE4BA581F@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36EE2DDBA81@PUEXCB1B.nanterre.francetelecom.fr> <4A95BA014132FF49AE685FAB4B9F17F645B4C1F6@dfweml509-mbx.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B4C1F6@dfweml509-mbx.china.huawei.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EE4BA581FPUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Questions to "draft-boucadair-network-function-chaining":
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 12:12:07 -0000

--_000_94C682931C08B048B7A8645303FDC9F36EE4BA581FPUEXCB1Bnante_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Linda,

Please see inline.
Cheers,
Med

De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Linda=
 Dunbar
Envoy=E9 : mardi 23 juillet 2013 01:44
=C0 : BOUCADAIR Mohamed OLNC/OLN; Diego R. Lopez
Cc : nsc@ietf.org
Objet : Re: [nsc] Questions to "draft-boucadair-network-function-chaining":

Mohamed,

Thank you very much for the reply. More clarification questions are inserte=
d blow:


What does "Located" mean in your context?
[Med] The rationale behind that characterization is as follows: As you know=
 in order to deliver connectivity services, several functions are invoked; =
 some of these functions are ** located in the network side ** while others=
 are ** embedded in a host, a home router/CPE **. Examples of functions tha=
t are located in the host side or the CPE side include (non-exclusive list)=
: NAT44, A+P NAT, MAP-E CE, MAP-T CE, DHCP client, DHCP server, DNS resolve=
r, DNS proxy, NTP server, NTP Proxy, SIP Proxy Server, SIP User Agent, DNSS=
EC validator, cache, TCP profiler, IPv4 firewall, IPv6 firewall, DS-Lite B4=
 element, NAT64, etc. Orchestrating these functions is out of scope. Hence,=
 the need to characterize the brand of functions which are in scope: only t=
hose located in the network side (i.e., Network-Located Functions).

[Linda] That is a very interesting point. You are saying that all the funct=
ions listed above on the client side, or sometimes referred to as services =
associated with access routers, are not in the scope of the Network Located=
 Services.

Can you give some examples of services that are located "in the network sid=
e"?
[Med] Examples of NLFs are cited in draft-boucadair-*. In addition to that =
list, some of the functions located in the customer side can also be enable=
d at the network side (e.g., SIP Proxy, NAT64, etc.). This is why, I prefer=
 to characterize the function with regards to its location rather than its =
outcome. This recalls me another assumption I would vote to consider for th=
is work: These functions do no span multiple administrative domains (but an=
 administrative domain can host multiple DiffForward domains).

Note, the he use of "located" avoids any confusion that can be induced by "=
network function" since some may think these functions act at the "network =
layer"...which is not true.



Your draft touches upon "Network Located Function Map", are you advocating =
that this "Map" should be dynamically formed or adjusted from heartbeat mes=
sages sent from all the "Network Located Functions" scatted in the network?
[Med] The proposed framework may accommodate that need but this is an OPTIO=
NAL feature. Please refer to http://tools.ietf.org/html/draft-boucadair-net=
work-function-chaining-02#section-6.7. Are you referring to such liveness d=
etection feature?

[Linda] Yes. But I think you need to include more dimensions in the Livenes=
s Detection. First of all, you need to specify different service categories=
: e.g. video optimization, content caching, security (DDoS prevention, SSL =
Inspection, Malware analysis, etc), HTTP message recognition, etc. This is =
a very big problem space already.

It seems to me that your draft tries to cover three major categories:
[Med] The document proposes an architecture framework document for the chai=
ning of functions. The document explains in particular the role of each fun=
ctional entity and the interactions between these entities. It also identif=
ies and discusses some deployment options. The overall architecture is poli=
cy-driven. How these policies are generated and what are the required input=
 to the decision-making process is orthogonal to the architectural discussi=
ons.
[Linda] do you mean network architecture? i.e. methods  to enforce selected=
 traffic to go through their designated service modules?
[Med] Not only methods but also the behavior of involved functional element=
s.


The PDP (Policy Decision Point) can be provisioned using both static of dyn=
amic means.

[Linda] is PDP more like "Policy Driven Traffic Steering Point"? It is less=
 about deciding policies, is it?
[Med] This is part of the PDP responsibility but the PDP is also responsibl=
e for:

=B7         Configuring NLF-specific policies (e.g., configure distinct use=
r profiles, activate specific traffic filters, configure traffic conditione=
rs,    etc.)

=B7         Selecting NLF profiles (see for instance http://tools.ietf.org/=
html/draft-boucadair-network-function-chaining-02#section-6.2)



-          Automatically create chronology of service functions based on us=
er demand and network resource availability:
[Med] Yes, this can be met with the proposed framework since the PDP is res=
ponsible for generating and enforcing the policies.

[Linda] is PDP in the data path or an entity, that could be separated from =
data path,  for making the policy decision?
[Med] The typical model is to have the PDP separated from the data path.

Linda Dunbar

--_000_94C682931C08B048B7A8645303FDC9F36EE4BA581FPUEXCB1Bnante_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Micr=
osoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"Pr=E9format=E9 HTML Car";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PrformatHTMLCar
	{mso-style-name:"Pr=E9format=E9 HTML Car";
	mso-style-priority:99;
	mso-style-link:"Pr=E9format=E9 HTML";
	font-family:Consolas;}
p.HTMLPreformatted, li.HTMLPreformatted, div.HTMLPreformatted
	{mso-style-name:"HTML Preformatted";
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Courier New";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal-reply;
	font-family:"Courier New";
	color:#993366;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1309558256;
	mso-list-type:hybrid;
	mso-list-template-ids:635236896 1188343866 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	mso-ansi-font-style:italic;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l1
	{mso-list-id:2065249496;
	mso-list-type:hybrid;
	mso-list-template-ids:1115954778 1013360006 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:20;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:SimSun;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:10.0pt;font-family:"Courier New";color:#993366'>Dear Linda,<o:p></=
o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-fa=
mily:"Courier New";color:#993366'><o:p>&nbsp;</o:p></span></p><p class=3DMs=
oNormal><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#99=
3366'>Please see inline.<o:p></o:p></span></p><p class=3DMsoNormal><span st=
yle=3D'font-size:10.0pt;font-family:"Courier New";color:#993366'>Cheers,<o:=
p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;fon=
t-family:"Courier New";color:#993366'>Med<o:p></o:p></span></p><p class=3DM=
soNormal><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#9=
93366'><o:p>&nbsp;</o:p></span></p><div style=3D'border:none;border-left:so=
lid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style=3D'border:none;bo=
rder-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNorma=
l><b><span lang=3DFR style=3D'font-size:10.0pt;font-family:"Tahoma","sans-s=
erif"'>De&nbsp;:</span></b><span lang=3DFR style=3D'font-size:10.0pt;font-f=
amily:"Tahoma","sans-serif"'> nsc-bounces@ietf.org [mailto:nsc-bounces@ietf=
.org] <b>De la part de</b> Linda Dunbar<br><b>Envoy=E9&nbsp;:</b> mardi 23 =
juillet 2013 01:44<br><b>=C0&nbsp;:</b> BOUCADAIR Mohamed OLNC/OLN; Diego R=
. Lopez<br><b>Cc&nbsp;:</b> nsc@ietf.org<br><b>Objet&nbsp;:</b> Re: [nsc] Q=
uestions to &quot;draft-boucadair-network-function-chaining&quot;:<o:p></o:=
p></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=
=3DMsoNormal><span style=3D'color:#1F497D'>Mohamed, <o:p></o:p></span></p><=
p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span><=
/p><p class=3DMsoNormal><span style=3D'color:#1F497D'>Thank you very much f=
or the reply. More clarification questions are inserted blow: <o:p></o:p></=
span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:=
p></span></p><div style=3D'border:none;border-left:solid blue 1.5pt;padding=
:0cm 0cm 0cm 4.0pt'><div style=3D'border:none;border-left:solid blue 1.5pt;=
padding:0cm 0cm 0cm 4.0pt'><p class=3DMsoNormal><span style=3D'font-size:10=
.0pt;font-family:"Courier New";color:#1F497D'><o:p>&nbsp;</o:p></span></p><=
p class=3DMsoNormal>What does &#8220;Located&#8221; mean in your context?<o=
:p></o:p></p><p class=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;fon=
t-family:"Courier New";color:#1F497D'>[Med] The rationale behind that chara=
cterization is as follows: As you know in order to deliver connectivity ser=
vices, several functions are invoked;&nbsp; some of these functions are ** =
located in the network side ** while others are ** embedded in a host, a ho=
me router/CPE **. Examples of functions that are located in the host side o=
r the CPE side include (non-exclusive list): NAT44, A+P NAT, MAP-E CE, MAP-=
T CE, DHCP client, DHCP server, DNS resolver, DNS proxy, NTP server, NTP Pr=
oxy, SIP Proxy Server, SIP User Agent, DNSSEC validator, cache, TCP profile=
r, IPv4 firewall, IPv6 firewall, DS-Lite B4 element, NAT64, etc. Orchestrat=
ing these functions is out of scope. Hence, the need to characterize the br=
and of functions which are in scope: only those located in the network side=
 (i.e., Network-Located Functions). <o:p></o:p></span></i></b></p><p class=
=3DMsoNormal><b><i><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></=
i></b></p><p class=3DMsoNormal><b><span style=3D'color:#7030A0'>[Linda] Tha=
t is a very interesting point. You are saying that all the functions listed=
 above on the client side, or sometimes referred to as services associated =
with access routers, are not in the scope of the Network Located Services. =
<o:p></o:p></span></b></p><p class=3DMsoNormal><b><span style=3D'color:#703=
0A0'><o:p>&nbsp;</o:p></span></b></p><p class=3DMsoNormal><b><span style=3D=
'color:#7030A0'>Can you give some examples of services that are located &#8=
220;in the network side&#8221;? <o:p></o:p></span></b></p><p class=3DMsoNor=
mal><b><i><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#=
993366'>[Med] Examples of NLFs are cited in draft-boucadair-*. In addition =
to that list, some of the functions located in the customer side can also b=
e enabled at the network side (e.g., SIP Proxy, NAT64, etc.). This is why, =
I prefer to characterize the function with regards to its location rather t=
han its outcome. This recalls me another assumption I would vote to conside=
r for this work: These functions do no span multiple administrative domains=
 (but an administrative domain can host multiple DiffForward domains).</spa=
n></i><span style=3D'color:#7030A0'><o:p></o:p></span></b></p><p class=3DMs=
oNormal><b><span style=3D'color:#7030A0'><o:p>&nbsp;</o:p></span></b></p><p=
 class=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;font-family:"Couri=
er New";color:#1F497D'>Note, the he use of &#8220;located&#8221; avoids any=
 confusion that can be induced by &#8220;network function&#8221; since some=
 may think these functions act at the &#8220;network layer&#8221;&#8230;whi=
ch is not true. <o:p></o:p></span></i></b></p><p class=3DMsoNormal><b><i><s=
pan style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></i></b></p><p class=3D=
MsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#=
1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'text-auto=
space:none'><span style=3D'font-size:10.0pt;font-family:Courier'><o:p>&nbsp=
;</o:p></span></p><p class=3DMsoNormal>Your draft touches upon &#8220;Netwo=
rk Located Function Map&#8221;, are you advocating that this &#8220;Map&#82=
21; should be dynamically formed or adjusted from heartbeat messages sent f=
rom all the &#8220;Network Located Functions&#8221; scatted in the network?=
 <o:p></o:p></p><p class=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;=
font-family:"Courier New";color:#1F497D'>[Med] The proposed framework may a=
ccommodate that need but this is an OPTIONAL feature. Please refer to </spa=
n></i></b><a href=3D"http://tools.ietf.org/html/draft-boucadair-network-fun=
ction-chaining-02#section-6.7"><b><i><span style=3D'font-size:10.0pt;font-f=
amily:"Courier New"'>http://tools.ietf.org/html/draft-boucadair-network-fun=
ction-chaining-02#section-6.7</span></i></b></a><b><i><span style=3D'font-s=
ize:10.0pt;font-family:"Courier New";color:#1F497D'>. Are you referring to =
such liveness detection feature? </span></i></b><span style=3D'font-size:10=
.0pt;font-family:"Courier New";color:#1F497D'><o:p></o:p></span></p><p clas=
s=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><b><span style=3D'c=
olor:#7030A0'>[Linda] Yes. But I think you need to include more dimensions =
in the Liveness Detection. First of all, you need to specify different serv=
ice categories: e.g. video optimization, content caching, security (DDoS pr=
evention, SSL Inspection, Malware analysis, etc), HTTP message recognition,=
 etc. This is a very big problem space already. <o:p></o:p></span></b></p><=
p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span><=
/p><p class=3DMsoNormal>It seems to me that your draft tries to cover three=
 major categories:<o:p></o:p></p><p class=3DMsoNormal><b><i><span style=3D'=
font-size:10.0pt;font-family:"Courier New";color:#1F497D'>[Med] The documen=
t proposes an architecture framework document for the chaining of functions=
. The document explains in particular the role of each functional entity an=
d the interactions between these entities. It also identifies and discusses=
 some deployment options. The overall architecture is policy-driven. How th=
ese policies are generated and what are the required input to the decision-=
making process is orthogonal to the architectural discussions.<o:p></o:p></=
span></i></b></p><p class=3DMsoNormal><b><span style=3D'color:#7030A0'>[Lin=
da] do you mean network architecture? i.e. methods &nbsp;to enforce selecte=
d traffic to go through their designated service modules? <o:p></o:p></span=
></b></p><p class=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;font-fa=
mily:"Courier New";color:#993366'>[Med] Not only methods but also the behav=
ior of involved functional elements. </span></i></b><b><span style=3D'font-=
size:10.0pt;font-family:"Courier New";color:#993366'><o:p></o:p></span></b>=
</p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></s=
pan></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;font=
-family:"Courier New";color:#1F497D'>The PDP (Policy Decision Point) can be=
 provisioned using both static of dynamic means. <o:p></o:p></span></i></b>=
</p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></s=
pan></p><p class=3DMsoNormal><b><span style=3D'color:#7030A0'>[Linda] is PD=
P more like &#8220;Policy Driven Traffic Steering Point&#8221;? It is less =
about deciding policies, is it? <o:p></o:p></span></b></p><p class=3DMsoNor=
mal><b><i><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#=
993366'>[Med] This is part of the PDP responsibility but the PDP is also re=
sponsible for:<o:p></o:p></span></i></b></p><p class=3DMsoListParagraph sty=
le=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo3'><![if !supportLists]><sp=
an style=3D'font-size:10.0pt;font-family:Symbol;color:#993366'><span style=
=3D'mso-list:Ignore'>=B7<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><=
b><span style=3D'font-size:10.0pt;font-family:"Courier New";color:#993366'>=
Configuring NLF-specific policies (e.g., configure distinct user profiles, =
activate specific traffic filters, configure traffic conditioners, =A0=A0=
=A0etc.)<o:p></o:p></span></b></p><p class=3DMsoListParagraph style=3D'text=
-indent:-18.0pt;mso-list:l0 level1 lfo3'><![if !supportLists]><span style=
=3D'font-size:10.0pt;font-family:Symbol;color:#993366'><span style=3D'mso-l=
ist:Ignore'>=B7<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><b><span s=
tyle=3D'font-size:10.0pt;font-family:"Courier New";color:#993366'>Selecting=
 NLF profiles (see for instance <a href=3D"http://tools.ietf.org/html/draft=
-boucadair-network-function-chaining-02#section-6.2">http://tools.ietf.org/=
html/draft-boucadair-network-function-chaining-02#section-6.2</a>)<o:p></o:=
p></span></b></p><p class=3DMsoListParagraph><o:p>&nbsp;</o:p></p><p class=
=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l1 level1 lfo2'><=
![if !supportLists]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.=
0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span></span><![endif]>Automatically create chronology of service funct=
ions based on user demand and network resource availability:<o:p></o:p></p>=
<p class=3DMsoNormal><b><i><span style=3D'font-size:10.0pt;font-family:"Cou=
rier New";color:#1F497D'>[Med] Yes, this can be met with the proposed frame=
work since the PDP is responsible for generating and enforcing the policies=
. <o:p></o:p></span></i></b></p><p class=3DMsoNormal><b><i><span style=3D'c=
olor:#1F497D'><o:p>&nbsp;</o:p></span></i></b></p><p class=3DMsoNormal><b><=
span style=3D'color:#7030A0'>[Linda] is PDP in the data path or an entity, =
that could be separated from data path, &nbsp;for making the policy decisio=
n? <o:p></o:p></span></b></p><p class=3DMsoNormal><b><i><span style=3D'font=
-size:10.0pt;font-family:"Courier New";color:#993366'>[Med] The typical mod=
el is to have the PDP separated from the data path.</span></i></b><b><span =
style=3D'font-size:10.0pt;font-family:"Courier New";color:#993366'><o:p></o=
:p></span></b></p><p class=3DMsoNormal><b><i><span style=3D'color:#1F497D'>=
<o:p>&nbsp;</o:p></span></i></b></p><p class=3DMsoNormal>Linda Dunbar<o:p><=
/o:p></p></div></div></div></div></body></html>=

--_000_94C682931C08B048B7A8645303FDC9F36EE4BA581FPUEXCB1Bnante_--

From N.Leymann@telekom.de  Wed Jul 24 06:55:23 2013
Return-Path: <N.Leymann@telekom.de>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB211E8142 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 06:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb3UOM3uOZ4e for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 06:55:17 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id E110E11E80E8 for <nsc@ietf.org>; Wed, 24 Jul 2013 06:54:51 -0700 (PDT)
Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jul 2013 15:54:34 +0200
Received: from HE100014.emea1.cds.t-internal.com (10.125.65.197) by HE101251.emea1.cds.t-internal.com (10.125.92.154) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 24 Jul 2013 15:54:34 +0200
Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE100014.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 24 Jul 2013 15:54:33 +0200
From: <N.Leymann@telekom.de>
To: <wim.henderickx@alcatel-lucent.com>, <nsc@ietf.org>
Date: Wed, 24 Jul 2013 15:54:33 +0200
Thread-Topic: Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TA
Message-ID: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com>
References: <CE156BAC.6A02B%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <CE156BAC.6A02B%wim.henderickx@alcatel-lucent.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_9762ACF04FA26B4388476841256BDE02011ADFB8CDBEHE111543eme_"
MIME-Version: 1.0
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 13:55:23 -0000

--_000_9762ACF04FA26B4388476841256BDE02011ADFB8CDBEHE111543eme_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Wim,

I think not only effectivness/scalability might be a problem but also the f=
act that not all applications (service bringing functions) are able to hand=
le packets coming from/going to potentially thousands of different VLANs at=
 the same time. VLANs will work in certain environments but not in all. I s=
ee the need for an information exchange between the application and a media=
tion layer as well. Ideally this should be as simple as possible without he=
avy impact on the application itself (might be difficult to achieve but fro=
m my experience it is not very likely, that there will be big rewrites of e=
xisting applications in order to support the chaining).

  regards

     Nic

________________________________
Von: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] Im Auftrag von Hend=
erickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org
Betreff: [nsc] Service chaining architecture question

I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_9762ACF04FA26B4388476841256BDE02011ADFB8CDBEHE111543eme_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.23501"></HEAD>
<BODY=20
style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLOR: rg=
b(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-break: af=
ter-white-space">
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT size=3D2=
>Hi=20
Wim,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT size=3D2=
>I think not=20
only effectivness/scalability might be a problem but also the fact that not=
 all=20
applications (service bringing functions) are able to handle packets coming=
=20
from/going to&nbsp;potentially thousands of different VLANs at the same tim=
e.=20
VLANs will work in certain environments but not in all. I see the need for =
an=20
information exchange between the application and a mediation layer as well.=
=20
Ideally this should be as simple as possible without heavy impact on the=20
application itself (might be difficult to achieve but from my experience it=
 is=20
not very likely, that there will be big rewrites of existing applications i=
n=20
order to support the chaining).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT size=3D2=
>&nbsp;=20
regards</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; Nic</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D912565709-24072013><FONT=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2 face=3DTahoma><B>Von:</B>=20
nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] <B>Im Auftrag von=20
</B>Henderickx, Wim (Wim)<BR><B>Gesendet:</B> Mittwoch, 24. Juli 2013=20
11:52<BR><B>An:</B> nsc@ietf.org<BR><B>Betreff:</B> [nsc] Service chaining=
=20
architecture question<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>I have a basic question with respect to the architecture/framework so =
far=20
mentioned in the drafts in NSC. I understand the meta-data is a mechanism t=
o=20
avoid multiple re-classifications when the packet enters the NSC domain and=
=20
identifies the chain of service functions. Now my understanding is that the=
=20
services/applications are unaware of the meta-data and that a layer underne=
ath=20
should provide the mediation and that we use a well defined interface to th=
e=20
application/service to indicate the chain. In the context of Cloud/enterpri=
se=20
environment I can see this work given you can use a dedicate VLAN e.g. with=
in=20
the tenant. However we also try to address residential use cases for mobile=
 and=20
fixed and here this becomes more tricky afais.&nbsp;In the residential=20
environment we can't expose a VLAN per application/service per chain since =
this=20
would not be very effective. So I am wondering how we envision this to=20
work?</DIV></BODY></HTML>

--_000_9762ACF04FA26B4388476841256BDE02011ADFB8CDBEHE111543eme_--

From wim.henderickx@alcatel-lucent.com  Wed Jul 24 09:30:26 2013
Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A721521F8445 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 09:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.01
X-Spam-Level: 
X-Spam-Status: No, score=-10.01 tagged_above=-999 required=5 tests=[AWL=0.588,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP8fFUHCC0Ek for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 09:30:20 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id EC56311E80FE for <nsc@ietf.org>; Wed, 24 Jul 2013 09:30:19 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6OGUHd8022193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2013 11:30:18 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6OGUGnR020806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 18:30:16 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 18:30:16 +0200
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: AW: Service chaining architecture question
Thread-Index: AQHOiFJWFN5gRDEUd0K4kdr4filTYplzuHqAgABM/QA=
Date: Wed, 24 Jul 2013 16:30:16 +0000
Message-ID: <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_CE15CDAA6A243wimhenderickxalcatellucentcom_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 16:30:26 -0000

--_000_CE15CDAA6A243wimhenderickxalcatellucentcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

indeed

From: "N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>" <N.Leymann@teleko=
m.de<mailto:N.Leymann@telekom.de>>
Date: Wednesday 24 July 2013 15:54
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx=
@alcatel-lucent.com>>, "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<ma=
ilto:nsc@ietf.org>>
Subject: AW: Service chaining architecture question

Hi Wim,

I think not only effectivness/scalability might be a problem but also the f=
act that not all applications (service bringing functions) are able to hand=
le packets coming from/going to potentially thousands of different VLANs at=
 the same time. VLANs will work in certain environments but not in all. I s=
ee the need for an information exchange between the application and a media=
tion layer as well. Ideally this should be as simple as possible without he=
avy impact on the application itself (might be difficult to achieve but fro=
m my experience it is not very likely, that there will be big rewrites of e=
xisting applications in order to support the chaining).

  regards

     Nic

________________________________
Von: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces@=
ietf.org] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org<mailto:nsc@ietf.org>
Betreff: [nsc] Service chaining architecture question

I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_CE15CDAA6A243wimhenderickxalcatellucentcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <8066FF66E28CD947BFF883ADC0F53BDC@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>indeed</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&quot;<a href=3D"mailto:N.Ley=
mann@telekom.de">N.Leymann@telekom.de</a>&quot; &lt;<a href=3D"mailto:N.Ley=
mann@telekom.de">N.Leymann@telekom.de</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Wednesday 24 July 2013 15:54<=
br>
<span style=3D"font-weight:bold">To: </span>Wim Henderickx &lt;<a href=3D"m=
ailto:wim.henderickx@alcatel-lucent.com">wim.henderickx@alcatel-lucent.com<=
/a>&gt;, &quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt;<=
a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>AW: Service chaining archi=
tecture question<br>
</div>
<div><br>
</div>
<div>
<meta name=3D"GENERATOR" content=3D"MSHTML 8.00.6001.23501">
<div style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLO=
R: rgb(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space">
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2">Hi Wim,</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2">I think not only effectivness/scalability might be a problem but a=
lso the fact that not all applications (service bringing functions) are abl=
e to handle packets coming from/going to&nbsp;potentially
 thousands of different VLANs at the same time. VLANs will work in certain =
environments but not in all. I see the need for an information exchange bet=
ween the application and a mediation layer as well. Ideally this should be =
as simple as possible without heavy
 impact on the application itself (might be difficult to achieve but from m=
y experience it is not very likely, that there will be big rewrites of exis=
ting applications in order to support the chaining).</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2">&nbsp; regards</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2">&nbsp;&nbsp;&nbsp;&nbsp; Nic</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left">
<hr tabindex=3D"-1">
</div>
<div dir=3D"ltr" align=3D"left"><font size=3D"2" face=3D"Tahoma"><b>Von:</b=
> <a href=3D"mailto:nsc-bounces@ietf.org">
nsc-bounces@ietf.org</a> [<a href=3D"mailto:nsc-bounces@ietf.org">mailto:ns=
c-bounces@ietf.org</a>]
<b>Im Auftrag von </b>Henderickx, Wim (Wim)<br>
<b>Gesendet:</b> Mittwoch, 24. Juli 2013 11:52<br>
<b>An:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Betreff:</b> [nsc] Service chaining architecture question<br>
</font><br>
</div>
<div></div>
<div>I have a basic question with respect to the architecture/framework so =
far mentioned in the drafts in NSC. I understand the meta-data is a mechani=
sm to avoid multiple re-classifications when the packet enters the NSC doma=
in and identifies the chain of service
 functions. Now my understanding is that the services/applications are unaw=
are of the meta-data and that a layer underneath should provide the mediati=
on and that we use a well defined interface to the application/service to i=
ndicate the chain. In the context
 of Cloud/enterprise environment I can see this work given you can use a de=
dicate VLAN e.g. within the tenant. However we also try to address resident=
ial use cases for mobile and fixed and here this becomes more tricky afais.=
&nbsp;In the residential environment
 we can't expose a VLAN per application/service per chain since this would =
not be very effective. So I am wondering how we envision this to work?</div=
>
</div>
</div>
</span>
</body>
</html>

--_000_CE15CDAA6A243wimhenderickxalcatellucentcom_--

From david.i.allan@ericsson.com  Wed Jul 24 12:52:49 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3366F11E824A for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 12:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hz2RzP1pAmr for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 12:52:42 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4266911E8215 for <nsc@ietf.org>; Wed, 24 Jul 2013 12:52:40 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-f9-51f030777f8b
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4E.8B.13034.77030F15; Wed, 24 Jul 2013 21:52:23 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 15:52:20 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYA==
Date: Wed, 24 Jul 2013 19:52:20 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C115D649Beusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPuG65wYdAg6lvLCwmLZzCZHF83342 i9mPf7A5MHu0PtvL6rFkyU8mj7aXCgHMUVw2Kak5mWWpRfp2CVwZi2bcZCo42cJYcfrqc8YG xnclXYycHBICJhI3p81mgbDFJC7cW8/WxcjFISRwlFFi9dw2ZghnOaPE5e2/mEGq2AQMJPb8 /8IIkhAR6GeUmH7sMitIQljAUuJ482t2EFtEwEri7KZuRgjbSeJj52mwFSwCqhI7f68Ci/MK +Eo0TDjKDrFhIqPEgvUfwQZxCthLrH20HqyIEeim76fWMIHYzALiEreezGeCuFVAYsme88wQ tqjEy8f/WCFsZYklT/azQNTnS/zYDhHnFRCUODnzCcsERpFZSEbNQlI2C0kZRFxHYsHuT2wQ trbEsoWvmWHsMwceMyGLL2BkX8XIUVqcWpabbmSwiREYV8ck2HR3MO55aXmIUZqDRUmcd5Xe mUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNIvBadOuH/n8da6izncO7P0k69w7G7TOPZH KGT2+v70fdvZLd6fst9qrbzd+8v02bwrr5Q/fzT9wM6Zl5W+XT30evrW8sJXXubXc9e1ajRH eL82cdf9t24x08HaxNfV87TMq57VzZnF+zN/k+QU7pmL4mbMme6VwsO+zaaaO8tRdMrLLMG6 E++VWIozEg21mIuKEwFDGUWJeQIAAA==
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 19:52:49 -0000

--_000_E6C17D2345AC7A45B7D054D407AA205C115D649Beusaamb105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Saying functions will have a problem with something that exists as a potent=
ial rationale for defining something new with exactly the same properties a=
nd problems does not quite work for me....

VLANs on a vNIC or multiple vNICs (depending on the application stack const=
ruction and this being combined with application "cooperation" to preserve =
pairwise mappings of either VID/NIC tuples or simply NICs) currently exist =
as potential vehicles for preserving chain context and avoiding per hop cla=
ssification. Anything else will be implemented more or less the same way an=
d have exactly the same set of scaling and application design issues...Some=
 extra information available on a single interface, or achieved by mapping =
chain instances onto one of a plurality of interfaces....

But to back up... I'm not a carrier employee but I cannot envision a carrie=
r offering potentially 1000s of distinct service bundles ("pick 53 from col=
umn A and 49 from column B"). So I suspect a much smaller number is realist=
ic for  the number of chains a function instance is expected to participate=
 in, even allowing for dynamic reclassification of flows at a chain ingress=
 to "skip a few functions".... These are things that are fully operationali=
zed in OSS, have policy associated with, have been industrialized and demon=
strated to work prior to deployment. Going all combinatorial on this will b=
reak that big time....

So are we really discussing a function participating in more than a handful=
 of chain instances? And either a plurality of vNICs or VIDs being actually=
 more than sufficient?

Thanks
Dave

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Hende=
rickx, Wim (Wim)
Sent: Wednesday, July 24, 2013 9:30 AM
To: N.Leymann@telekom.de; nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

indeed

From: "N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>" <N.Leymann@teleko=
m.de<mailto:N.Leymann@telekom.de>>
Date: Wednesday 24 July 2013 15:54
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx=
@alcatel-lucent.com>>, "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<ma=
ilto:nsc@ietf.org>>
Subject: AW: Service chaining architecture question

Hi Wim,

I think not only effectivness/scalability might be a problem but also the f=
act that not all applications (service bringing functions) are able to hand=
le packets coming from/going to potentially thousands of different VLANs at=
 the same time. VLANs will work in certain environments but not in all. I s=
ee the need for an information exchange between the application and a media=
tion layer as well. Ideally this should be as simple as possible without he=
avy impact on the application itself (might be difficult to achieve but fro=
m my experience it is not very likely, that there will be big rewrites of e=
xisting applications in order to support the chaining).

  regards

     Nic

________________________________
Von: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces@=
ietf.org] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org<mailto:nsc@ietf.org>
Betreff: [nsc] Service chaining architecture question
I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_E6C17D2345AC7A45B7D054D407AA205C115D649Beusaamb105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Saying functions will hav=
e a problem with something that exists as a potential rationale for definin=
g something new with exactly the same properties and problems
 does not quite work for me&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">VLANs on a vNIC or multip=
le vNICs (depending on the application stack construction and this being co=
mbined with application &#8220;cooperation&#8221; to preserve pairwise
 mappings of either VID/NIC tuples or simply NICs) currently exist as poten=
tial vehicles for preserving chain context and avoiding per hop classificat=
ion. Anything else will be implemented more or less the same way and have e=
xactly the same set of scaling and
 application design issues&#8230;Some extra information available on a sing=
le interface, or achieved by mapping chain instances onto one of a pluralit=
y of interfaces&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">But to back up&#8230; I&#=
8217;m not a carrier employee but I cannot envision a carrier offering pote=
ntially 1000s of distinct service bundles (&#8220;pick 53 from column A and
 49 from column B&#8221;). So I suspect a much smaller number is realistic =
for &nbsp;the number of chains a function instance is expected to participa=
te in, even allowing for dynamic reclassification of flows at a chain ingre=
ss to &#8220;skip a few functions&#8221;&#8230;. These are things
 that are fully operationalized in OSS, have policy associated with, have b=
een industrialized and demonstrated to work prior to deployment. Going all =
combinatorial on this will break that big time&#8230;.<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So are we really discussi=
ng a function participating in more than a handful of chain instances? And =
either a plurality of vNICs or VIDs being actually more
 than sufficient?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> nsc-boun=
ces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>Henderickx, Wim (Wim)<br>
<b>Sent:</b> Wednesday, July 24, 2013 9:30 AM<br>
<b>To:</b> N.Leymann@telekom.de; nsc@ietf.org<br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">indeed<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:black">&quot;<a href=3D"mailto:N.Leymann@telek=
om.de">N.Leymann@telekom.de</a>&quot; &lt;<a href=3D"mailto:N.Leymann@telek=
om.de">N.Leymann@telekom.de</a>&gt;<br>
<b>Date: </b>Wednesday 24 July 2013 15:54<br>
<b>To: </b>Wim Henderickx &lt;<a href=3D"mailto:wim.henderickx@alcatel-luce=
nt.com">wim.henderickx@alcatel-lucent.com</a>&gt;, &quot;<a href=3D"mailto:=
nsc@ietf.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">ns=
c@ietf.org</a>&gt;<br>
<b>Subject: </b>AW: Service chaining architecture question<o:p></o:p></span=
></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Hi Wim,</span><span style=
=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I think not only effectivne=
ss/scalability might be a problem but also the fact that not all applicatio=
ns (service bringing functions) are able to handle packets
 coming from/going to&nbsp;potentially thousands of different VLANs at the =
same time. VLANs will work in certain environments but not in all. I see th=
e need for an information exchange between the application and a mediation =
layer as well. Ideally this should be
 as simple as possible without heavy impact on the application itself (migh=
t be difficult to achieve but from my experience it is not very likely, tha=
t there will be big rewrites of existing applications in order to support t=
he chaining).</span><span style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp; regards</span><span =
style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&=
quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp; Ni=
c</span><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&qu=
ot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span=
 style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=
&quot;;color:black">
<hr size=3D"2" width=3D"100%" align=3D"center">
</span></div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=
t-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:b=
lack">Von:</span></b><span style=3D"font-size:10.0pt;font-family:&quot;Taho=
ma&quot;,&quot;sans-serif&quot;;color:black">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>Im Auftrag von </b>Henderickx, Wim (Wim)<br>
<b>Gesendet:</b> Mittwoch, 24. Juli 2013 11:52<br>
<b>An:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Betreff:</b> [nsc] Service chaining architecture question</span><span st=
yle=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&qu=
ot;;color:black"><o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I have a basic question wit=
h respect to the architecture/framework so far mentioned in the drafts in N=
SC. I understand the meta-data is a mechanism to avoid multiple
 re-classifications when the packet enters the NSC domain and identifies th=
e chain of service functions. Now my understanding is that the services/app=
lications are unaware of the meta-data and that a layer underneath should p=
rovide the mediation and that we
 use a well defined interface to the application/service to indicate the ch=
ain. In the context of Cloud/enterprise environment I can see this work giv=
en you can use a dedicate VLAN e.g. within the tenant. However we also try =
to address residential use cases
 for mobile and fixed and here this becomes more tricky afais.&nbsp;In the =
residential environment we can't expose a VLAN per application/service per =
chain since this would not be very effective. So I am wondering how we envi=
sion this to work?<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_E6C17D2345AC7A45B7D054D407AA205C115D649Beusaamb105erics_--

From Ron_Parker@affirmednetworks.com  Wed Jul 24 13:05:35 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA8E11E80D9 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3hvyZ1Vni7J for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:05:29 -0700 (PDT)
Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6435411E80D5 for <nsc@ietf.org>; Wed, 24 Jul 2013 13:05:29 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0123.003; Wed, 24 Jul 2013 13:05:28 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: David Allan I <david.i.allan@ericsson.com>, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0g
Date: Wed, 24 Jul 2013 20:05:27 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se>
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67E167MBX021W3CA2exch_"
MIME-Version: 1.0
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 20:05:36 -0000

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67E167MBX021W3CA2exch_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dave,

I agree that the number of chains is unlikely to scale to vast numbers (i.e=
., millions).     And I agree that it is bounded from a practical business =
perspective, as you point out.

You may already be on this page, but I wanted to point out a distinction of=
 coarse-grained definition of a service function vs. finer-grained definiti=
on of a service function.   Consider a service function to be logical in su=
ch a way that the identity of the logical function may also imply some diff=
erentiated behavior.   For example, a conceptual function is HTTP content f=
iltering.    This conceptual function can then be further instantiated at t=
he logical level based on differentiated policies such as content-filter-ch=
ildren, content-filter-adults-no-porn, content-filter-adults (I'm taking no=
 stand on opt-in vs. opt-out, Mr. Cameron).   It may be that the same netwo=
rk element (dedicated physical box or virtual network function) realizes al=
l 3 of the example policies.   The HTTP content filtering network function =
is really 3 logical network functions from the perspective of inclusion in =
a service chain.   Now extend this to multiple conceptual functions that ut=
ilize differentiated policies and the number of combinations will grow, at =
least modestly.

Thanks,
Ron


From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David=
 Allan I
Sent: Wednesday, July 24, 2013 3:52 PM
To: Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Saying functions will have a problem with something that exists as a potent=
ial rationale for defining something new with exactly the same properties a=
nd problems does not quite work for me....

VLANs on a vNIC or multiple vNICs (depending on the application stack const=
ruction and this being combined with application "cooperation" to preserve =
pairwise mappings of either VID/NIC tuples or simply NICs) currently exist =
as potential vehicles for preserving chain context and avoiding per hop cla=
ssification. Anything else will be implemented more or less the same way an=
d have exactly the same set of scaling and application design issues...Some=
 extra information available on a single interface, or achieved by mapping =
chain instances onto one of a plurality of interfaces....

But to back up... I'm not a carrier employee but I cannot envision a carrie=
r offering potentially 1000s of distinct service bundles ("pick 53 from col=
umn A and 49 from column B"). So I suspect a much smaller number is realist=
ic for  the number of chains a function instance is expected to participate=
 in, even allowing for dynamic reclassification of flows at a chain ingress=
 to "skip a few functions".... These are things that are fully operationali=
zed in OSS, have policy associated with, have been industrialized and demon=
strated to work prior to deployment. Going all combinatorial on this will b=
reak that big time....

So are we really discussing a function participating in more than a handful=
 of chain instances? And either a plurality of vNICs or VIDs being actually=
 more than sufficient?

Thanks
Dave

From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 24, 2013 9:30 AM
To: N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>; nsc@ietf.org<mailto:=
nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question

indeed

From: "N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>" <N.Leymann@teleko=
m.de<mailto:N.Leymann@telekom.de>>
Date: Wednesday 24 July 2013 15:54
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx=
@alcatel-lucent.com>>, "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<ma=
ilto:nsc@ietf.org>>
Subject: AW: Service chaining architecture question

Hi Wim,

I think not only effectivness/scalability might be a problem but also the f=
act that not all applications (service bringing functions) are able to hand=
le packets coming from/going to potentially thousands of different VLANs at=
 the same time. VLANs will work in certain environments but not in all. I s=
ee the need for an information exchange between the application and a media=
tion layer as well. Ideally this should be as simple as possible without he=
avy impact on the application itself (might be difficult to achieve but fro=
m my experience it is not very likely, that there will be big rewrites of e=
xisting applications in order to support the chaining).

  regards

     Nic

________________________________
Von: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces@=
ietf.org] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org<mailto:nsc@ietf.org>
Betreff: [nsc] Service chaining architecture question
I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67E167MBX021W3CA2exch_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave,<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that the number o=
f chains is unlikely to scale to vast numbers (i.e., millions).&nbsp;&nbsp;=
 &nbsp;&nbsp;And I agree that it is bounded from a practical business persp=
ective,
 as you point out.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">You may already be on thi=
s page, but I wanted to point out a distinction of coarse-grained definitio=
n of a service function vs. finer-grained definition of
 a service function. &nbsp;&nbsp;Consider a service function to be logical =
in such a way that the identity of the logical function may also imply some=
 differentiated behavior.&nbsp;&nbsp; For example, a conceptual function is=
 HTTP content filtering.&nbsp;&nbsp; &nbsp;This conceptual function
 can then be further instantiated at the logical level based on differentia=
ted policies such as content-filter-children, content-filter-adults-no-porn=
, content-filter-adults (I&#8217;m taking no stand on opt-in vs. opt-out, M=
r. Cameron).&nbsp;&nbsp; It may be that the same
 network element (dedicated physical box or virtual network function) reali=
zes all 3 of the example policies.&nbsp;&nbsp; The HTTP content filtering n=
etwork function is really 3 logical network functions from the perspective =
of inclusion in a service chain.&nbsp;&nbsp; Now extend
 this to multiple conceptual functions that utilize differentiated policies=
 and the number of combinations will grow, at least modestly.<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> nsc-boun=
ces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>David Allan I<br>
<b>Sent:</b> Wednesday, July 24, 2013 3:52 PM<br>
<b>To:</b> Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org<br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Saying functions will hav=
e a problem with something that exists as a potential rationale for definin=
g something new with exactly the same properties and problems
 does not quite work for me&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">VLANs on a vNIC or multip=
le vNICs (depending on the application stack construction and this being co=
mbined with application &#8220;cooperation&#8221; to preserve pairwise
 mappings of either VID/NIC tuples or simply NICs) currently exist as poten=
tial vehicles for preserving chain context and avoiding per hop classificat=
ion. Anything else will be implemented more or less the same way and have e=
xactly the same set of scaling and
 application design issues&#8230;Some extra information available on a sing=
le interface, or achieved by mapping chain instances onto one of a pluralit=
y of interfaces&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">But to back up&#8230; I&#=
8217;m not a carrier employee but I cannot envision a carrier offering pote=
ntially 1000s of distinct service bundles (&#8220;pick 53 from column A and
 49 from column B&#8221;). So I suspect a much smaller number is realistic =
for &nbsp;the number of chains a function instance is expected to participa=
te in, even allowing for dynamic reclassification of flows at a chain ingre=
ss to &#8220;skip a few functions&#8221;&#8230;. These are things
 that are fully operationalized in OSS, have policy associated with, have b=
een industrialized and demonstrated to work prior to deployment. Going all =
combinatorial on this will break that big time&#8230;.<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So are we really discussi=
ng a function participating in more than a handful of chain instances? And =
either a plurality of vNICs or VIDs being actually more
 than sufficient?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Henderickx, Wim (Wim)<br>
<b>Sent:</b> Wednesday, July 24, 2013 9:30 AM<br>
<b>To:</b> <a href=3D"mailto:N.Leymann@telekom.de">N.Leymann@telekom.de</a>=
; <a href=3D"mailto:nsc@ietf.org">
nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">indeed<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:black">&quot;<a href=3D"mailto:N.Leymann@telek=
om.de">N.Leymann@telekom.de</a>&quot; &lt;<a href=3D"mailto:N.Leymann@telek=
om.de">N.Leymann@telekom.de</a>&gt;<br>
<b>Date: </b>Wednesday 24 July 2013 15:54<br>
<b>To: </b>Wim Henderickx &lt;<a href=3D"mailto:wim.henderickx@alcatel-luce=
nt.com">wim.henderickx@alcatel-lucent.com</a>&gt;, &quot;<a href=3D"mailto:=
nsc@ietf.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">ns=
c@ietf.org</a>&gt;<br>
<b>Subject: </b>AW: Service chaining architecture question<o:p></o:p></span=
></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Hi Wim,</span><span style=
=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I think not only effectivne=
ss/scalability might be a problem but also the fact that not all applicatio=
ns (service bringing functions) are able to handle packets
 coming from/going to&nbsp;potentially thousands of different VLANs at the =
same time. VLANs will work in certain environments but not in all. I see th=
e need for an information exchange between the application and a mediation =
layer as well. Ideally this should be
 as simple as possible without heavy impact on the application itself (migh=
t be difficult to achieve but from my experience it is not very likely, tha=
t there will be big rewrites of existing applications in order to support t=
he chaining).</span><span style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp; regards</span><span =
style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&=
quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp; Ni=
c</span><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&qu=
ot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span=
 style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=
&quot;;color:black">
<hr size=3D"2" width=3D"100%" align=3D"center">
</span></div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=
t-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:b=
lack">Von:</span></b><span style=3D"font-size:10.0pt;font-family:&quot;Taho=
ma&quot;,&quot;sans-serif&quot;;color:black">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>Im Auftrag von </b>Henderickx, Wim (Wim)<br>
<b>Gesendet:</b> Mittwoch, 24. Juli 2013 11:52<br>
<b>An:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Betreff:</b> [nsc] Service chaining architecture question</span><span st=
yle=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&qu=
ot;;color:black"><o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I have a basic question wit=
h respect to the architecture/framework so far mentioned in the drafts in N=
SC. I understand the meta-data is a mechanism to avoid multiple
 re-classifications when the packet enters the NSC domain and identifies th=
e chain of service functions. Now my understanding is that the services/app=
lications are unaware of the meta-data and that a layer underneath should p=
rovide the mediation and that we
 use a well defined interface to the application/service to indicate the ch=
ain. In the context of Cloud/enterprise environment I can see this work giv=
en you can use a dedicate VLAN e.g. within the tenant. However we also try =
to address residential use cases
 for mobile and fixed and here this becomes more tricky afais.&nbsp;In the =
residential environment we can't expose a VLAN per application/service per =
chain since this would not be very effective. So I am wondering how we envi=
sion this to work?<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A67E167MBX021W3CA2exch_--

From david.i.allan@ericsson.com  Wed Jul 24 13:18:03 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56DD11E8240 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx5I4YrfuBmZ for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:17:57 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7835E11E8239 for <nsc@ietf.org>; Wed, 24 Jul 2013 13:17:56 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-e6-51f036738749
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E8.5D.13034.37630F15; Wed, 24 Jul 2013 22:17:55 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 16:17:54 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeA//+9oQA=
Date: Wed, 24 Jul 2013 20:17:54 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D6502@eusaamb105.ericsson.se>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C115D6502eusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPgm6x2YdAg2W92haTFk5hsji+bz+b xYWnU5ktZj/+webA4vHiyjNmj9Zne1k9liz5yeTR9lIhgCWKyyYlNSezLLVI3y6BK2NG03nG gr2XGCt2/JdrYHy1k7GLkZNDQsBEYtqFp6wQtpjEhXvr2boYuTiEBI4ySrTMOg9WJCSwnFHi RrstiM0mYCCx5/8XRpAiEYH9jBLTrrSxgSSEBSwljje/ZgexRQSsJM5u6maEsP0kftyYxQxi swioSuybMwEszivgK3H90kQmiG3LmCRmN35lAklwCkRL/O9+AlbECHTS91NrwOLMAuISt57M Z4I4VUBiyZ7zzBC2qMTLx/+gXlCWWPJkPwtEfb7EyuWb2CGWCUqcnPmEZQKjyCwko2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLU4ty003MtjECIy0YxJsujsY97y0 PMQozcGiJM67Su9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGMoklX6XvuJzRfKh2iWHx xaB9qxfstWtd7uX2NXWhx9XZtmLTHoeeU7kZEuCxYOnZPSUCO2cGTmS80H829Ue3u8Vf/XuR YtUsS9OT52tJvwnYrfjT+0o+t69J0fWAHVn15w8vvLbGaRfX96mXAplfCh7VEWYMuDi7l2/i j+Diz846F5YWOxbpKbEUZyQaajEXFScCAN7/PQOCAgAA
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 20:18:04 -0000

--_000_E6C17D2345AC7A45B7D054D407AA205C115D6502eusaamb105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'd tend to look at your example as a class of  function that implements su=
bscriber specific policies, of which there can be multiple outcomes. Either=
 pass the traffic or proxy a "forbidden response".

>From a networking point of view I don't think multiple function outcomes ha=
s scaling implications for the network part of the implementation with the =
exception of when the function has a means to self-elect to be bypassed as =
an outcome...."I no longer need to process this flow...".

In which case I would need chain permutations with and without that class o=
f function....

Wow, long way to say I think I agree ;-)
Dave



From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Wednesday, July 24, 2013 1:05 PM
To: David Allan I; Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.or=
g
Subject: RE: [nsc] Service chaining architecture question

Dave,

I agree that the number of chains is unlikely to scale to vast numbers (i.e=
., millions).     And I agree that it is bounded from a practical business =
perspective, as you point out.

You may already be on this page, but I wanted to point out a distinction of=
 coarse-grained definition of a service function vs. finer-grained definiti=
on of a service function.   Consider a service function to be logical in su=
ch a way that the identity of the logical function may also imply some diff=
erentiated behavior.   For example, a conceptual function is HTTP content f=
iltering.    This conceptual function can then be further instantiated at t=
he logical level based on differentiated policies such as content-filter-ch=
ildren, content-filter-adults-no-porn, content-filter-adults (I'm taking no=
 stand on opt-in vs. opt-out, Mr. Cameron).   It may be that the same netwo=
rk element (dedicated physical box or virtual network function) realizes al=
l 3 of the example policies.   The HTTP content filtering network function =
is really 3 logical network functions from the perspective of inclusion in =
a service chain.   Now extend this to multiple conceptual functions that ut=
ilize differentiated policies and the number of combinations will grow, at =
least modestly.

Thanks,
Ron


From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of David Allan I
Sent: Wednesday, July 24, 2013 3:52 PM
To: Henderickx, Wim (Wim); N.Leymann@telekom.de<mailto:N.Leymann@telekom.de=
>; nsc@ietf.org<mailto:nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question

Saying functions will have a problem with something that exists as a potent=
ial rationale for defining something new with exactly the same properties a=
nd problems does not quite work for me....

VLANs on a vNIC or multiple vNICs (depending on the application stack const=
ruction and this being combined with application "cooperation" to preserve =
pairwise mappings of either VID/NIC tuples or simply NICs) currently exist =
as potential vehicles for preserving chain context and avoiding per hop cla=
ssification. Anything else will be implemented more or less the same way an=
d have exactly the same set of scaling and application design issues...Some=
 extra information available on a single interface, or achieved by mapping =
chain instances onto one of a plurality of interfaces....

But to back up... I'm not a carrier employee but I cannot envision a carrie=
r offering potentially 1000s of distinct service bundles ("pick 53 from col=
umn A and 49 from column B"). So I suspect a much smaller number is realist=
ic for  the number of chains a function instance is expected to participate=
 in, even allowing for dynamic reclassification of flows at a chain ingress=
 to "skip a few functions".... These are things that are fully operationali=
zed in OSS, have policy associated with, have been industrialized and demon=
strated to work prior to deployment. Going all combinatorial on this will b=
reak that big time....

So are we really discussing a function participating in more than a handful=
 of chain instances? And either a plurality of vNICs or VIDs being actually=
 more than sufficient?

Thanks
Dave

From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 24, 2013 9:30 AM
To: N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>; nsc@ietf.org<mailto:=
nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question

indeed

From: "N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>" <N.Leymann@teleko=
m.de<mailto:N.Leymann@telekom.de>>
Date: Wednesday 24 July 2013 15:54
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx=
@alcatel-lucent.com>>, "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<ma=
ilto:nsc@ietf.org>>
Subject: AW: Service chaining architecture question

Hi Wim,

I think not only effectivness/scalability might be a problem but also the f=
act that not all applications (service bringing functions) are able to hand=
le packets coming from/going to potentially thousands of different VLANs at=
 the same time. VLANs will work in certain environments but not in all. I s=
ee the need for an information exchange between the application and a media=
tion layer as well. Ideally this should be as simple as possible without he=
avy impact on the application itself (might be difficult to achieve but fro=
m my experience it is not very likely, that there will be big rewrites of e=
xisting applications in order to support the chaining).

  regards

     Nic

________________________________
Von: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces@=
ietf.org] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org<mailto:nsc@ietf.org>
Betreff: [nsc] Service chaining architecture question
I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_E6C17D2345AC7A45B7D054D407AA205C115D6502eusaamb105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I&#8217;d tend to look at=
 your example as a class of &nbsp;function that implements subscriber speci=
fic policies, of which there can be multiple outcomes. Either pass
 the traffic or proxy a &#8220;forbidden response&#8221;.<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">From a networking point o=
f view I don&#8217;t think multiple function outcomes has scaling implicati=
ons for the network part of the implementation with the exception
 of when the function has a means to self-elect to be bypassed as an outcom=
e&#8230;.&#8221;I no longer need to process this flow&#8230;&#8221;.<o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In which case I would nee=
d chain permutations with and without that class of function&#8230;.<o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Wow, long way to say I th=
ink I agree ;-)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ron Park=
er [mailto:Ron_Parker@affirmednetworks.com]
<br>
<b>Sent:</b> Wednesday, July 24, 2013 1:05 PM<br>
<b>To:</b> David Allan I; Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@=
ietf.org<br>
<b>Subject:</b> RE: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave,<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that the number o=
f chains is unlikely to scale to vast numbers (i.e., millions).&nbsp;&nbsp;=
 &nbsp;&nbsp;And I agree that it is bounded from a practical business persp=
ective,
 as you point out.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">You may already be on thi=
s page, but I wanted to point out a distinction of coarse-grained definitio=
n of a service function vs. finer-grained definition of
 a service function. &nbsp;&nbsp;Consider a service function to be logical =
in such a way that the identity of the logical function may also imply some=
 differentiated behavior.&nbsp;&nbsp; For example, a conceptual function is=
 HTTP content filtering.&nbsp;&nbsp; &nbsp;This conceptual function
 can then be further instantiated at the logical level based on differentia=
ted policies such as content-filter-children, content-filter-adults-no-porn=
, content-filter-adults (I&#8217;m taking no stand on opt-in vs. opt-out, M=
r. Cameron).&nbsp;&nbsp; It may be that the same
 network element (dedicated physical box or virtual network function) reali=
zes all 3 of the example policies.&nbsp;&nbsp; The HTTP content filtering n=
etwork function is really 3 logical network functions from the perspective =
of inclusion in a service chain.&nbsp;&nbsp; Now extend
 this to multiple conceptual functions that utilize differentiated policies=
 and the number of combinations will grow, at least modestly.<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>David Allan I<br>
<b>Sent:</b> Wednesday, July 24, 2013 3:52 PM<br>
<b>To:</b> Henderickx, Wim (Wim); <a href=3D"mailto:N.Leymann@telekom.de">N=
.Leymann@telekom.de</a>;
<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Saying functions will hav=
e a problem with something that exists as a potential rationale for definin=
g something new with exactly the same properties and problems
 does not quite work for me&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">VLANs on a vNIC or multip=
le vNICs (depending on the application stack construction and this being co=
mbined with application &#8220;cooperation&#8221; to preserve pairwise
 mappings of either VID/NIC tuples or simply NICs) currently exist as poten=
tial vehicles for preserving chain context and avoiding per hop classificat=
ion. Anything else will be implemented more or less the same way and have e=
xactly the same set of scaling and
 application design issues&#8230;Some extra information available on a sing=
le interface, or achieved by mapping chain instances onto one of a pluralit=
y of interfaces&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">But to back up&#8230; I&#=
8217;m not a carrier employee but I cannot envision a carrier offering pote=
ntially 1000s of distinct service bundles (&#8220;pick 53 from column A and
 49 from column B&#8221;). So I suspect a much smaller number is realistic =
for &nbsp;the number of chains a function instance is expected to participa=
te in, even allowing for dynamic reclassification of flows at a chain ingre=
ss to &#8220;skip a few functions&#8221;&#8230;. These are things
 that are fully operationalized in OSS, have policy associated with, have b=
een industrialized and demonstrated to work prior to deployment. Going all =
combinatorial on this will break that big time&#8230;.<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So are we really discussi=
ng a function participating in more than a handful of chain instances? And =
either a plurality of vNICs or VIDs being actually more
 than sufficient?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Henderickx, Wim (Wim)<br>
<b>Sent:</b> Wednesday, July 24, 2013 9:30 AM<br>
<b>To:</b> <a href=3D"mailto:N.Leymann@telekom.de">N.Leymann@telekom.de</a>=
; <a href=3D"mailto:nsc@ietf.org">
nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">indeed<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:black">&quot;<a href=3D"mailto:N.Leymann@telek=
om.de">N.Leymann@telekom.de</a>&quot; &lt;<a href=3D"mailto:N.Leymann@telek=
om.de">N.Leymann@telekom.de</a>&gt;<br>
<b>Date: </b>Wednesday 24 July 2013 15:54<br>
<b>To: </b>Wim Henderickx &lt;<a href=3D"mailto:wim.henderickx@alcatel-luce=
nt.com">wim.henderickx@alcatel-lucent.com</a>&gt;, &quot;<a href=3D"mailto:=
nsc@ietf.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">ns=
c@ietf.org</a>&gt;<br>
<b>Subject: </b>AW: Service chaining architecture question<o:p></o:p></span=
></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Hi Wim,</span><span style=
=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I think not only effectivne=
ss/scalability might be a problem but also the fact that not all applicatio=
ns (service bringing functions) are able to handle packets
 coming from/going to&nbsp;potentially thousands of different VLANs at the =
same time. VLANs will work in certain environments but not in all. I see th=
e need for an information exchange between the application and a mediation =
layer as well. Ideally this should be
 as simple as possible without heavy impact on the application itself (migh=
t be difficult to achieve but from my experience it is not very likely, tha=
t there will be big rewrites of existing applications in order to support t=
he chaining).</span><span style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp; regards</span><span =
style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&=
quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp; Ni=
c</span><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&qu=
ot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p=
>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span=
 style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=
&quot;;color:black">
<hr size=3D"2" width=3D"100%" align=3D"center">
</span></div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=
t-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:b=
lack">Von:</span></b><span style=3D"font-size:10.0pt;font-family:&quot;Taho=
ma&quot;,&quot;sans-serif&quot;;color:black">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>Im Auftrag von </b>Henderickx, Wim (Wim)<br>
<b>Gesendet:</b> Mittwoch, 24. Juli 2013 11:52<br>
<b>An:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Betreff:</b> [nsc] Service chaining architecture question</span><span st=
yle=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&qu=
ot;;color:black"><o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I have a basic question wit=
h respect to the architecture/framework so far mentioned in the drafts in N=
SC. I understand the meta-data is a mechanism to avoid multiple
 re-classifications when the packet enters the NSC domain and identifies th=
e chain of service functions. Now my understanding is that the services/app=
lications are unaware of the meta-data and that a layer underneath should p=
rovide the mediation and that we
 use a well defined interface to the application/service to indicate the ch=
ain. In the context of Cloud/enterprise environment I can see this work giv=
en you can use a dedicate VLAN e.g. within the tenant. However we also try =
to address residential use cases
 for mobile and fixed and here this becomes more tricky afais.&nbsp;In the =
residential environment we can't expose a VLAN per application/service per =
chain since this would not be very effective. So I am wondering how we envi=
sion this to work?<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_E6C17D2345AC7A45B7D054D407AA205C115D6502eusaamb105erics_--

From jguichar@cisco.com  Wed Jul 24 13:31:06 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6411E8239 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkduUSW-g-EX for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:30:56 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DC30211E80DE for <nsc@ietf.org>; Wed, 24 Jul 2013 13:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8493; q=dns/txt; s=iport; t=1374697855; x=1375907455; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=mmeUpIOU32UPynZrJuoh7lB58TtRnGkbO0zin1w0pV0=; b=Fas4sFV7uiEetKgQVzkBDkvAx9rwR7gCuEunfpOVBSlmqNpvLhrie9rS N/THh2WoDUu77QCGgUJc6t1mAv9HbkvLfKPSYKWpY8H11bcB+0el7xwDz qdq6yDdWBSnbdzHetylLRUHCkYTy3XhzTq/cniot93mzwneAReP/ZMOqV g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMFACo48FGtJXHB/2dsb2JhbABbgkJEgQW9Z4EWFnSCJAEBAQQnZAEIEhAdORQDDgIEARIIiAi6B49MNwGDEm4DohKHGoMUgio
X-IronPort-AV: E=Sophos;i="4.89,737,1367971200";  d="scan'208,217";a="238971918"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2013 20:30:54 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6OKUsoA008430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 20:30:54 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 15:30:53 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAAAApgA==
Date: Wed, 24 Jul 2013 20:30:54 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5C4483@xmb-rcd-x01.cisco.com>
In-Reply-To: <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.211]
Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F5C4483xmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 20:31:06 -0000

--_000_68B171751455884590F8E38E96416F363F5C4483xmbrcdx01ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Wim,

A few comments/questions inline ..

________________________________
Von: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces@=
ietf.org] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org<mailto:nsc@ietf.org>
Betreff: [nsc] Service chaining architecture question

I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data

Jim> this is true in the proxy-mode case but it is also possible that the s=
ervice functions themselves understand the NSH metadata. Both modes of oper=
ation are valid imho.

and that a layer underneath should provide the mediation and that we use a =
well defined interface to the application/service to indicate the chain. In=
 the context of Cloud/enterprise environment I can see this work given you =
can use a dedicate VLAN e.g. within the tenant.

Jim> note that the dedicated VLAN you describe is local between the proxy a=
nd the service e.g. We are not talking about domain-wide VLANs in this cont=
ext. So this interface between the proxy and the service is in fact a "loca=
l identifier" where that might be a VLAN but could also be something else s=
uch as the IP address of the residential consumer. Further, the number of l=
ocal identifier's you will need will be dependent on the differentiation yo=
u require; for example, is differentiation needed by user, or "class" of us=
er (i.e. Gold, silver, bronze analogy), or something else.  So this boils d=
own to what the local identifier is used for and whether it has policy asso=
ciated with it e.g. vlan-1 -> do firewall rule "x", vlan-2 -> do firewall r=
ule "y", and so on.

However we also try to address residential use cases for mobile and fixed a=
nd here this becomes more tricky afais. In the residential environment we c=
an't expose a VLAN per application/service per chain since this would not b=
e very effective. So I am wondering how we envision this to work?

Jim> I'm assuming when you say residential, you mean serving residential cu=
stomers with services in the POP or head-end, NOT services in the home righ=
t?

--_000_68B171751455884590F8E38E96416F363F5C4483xmbrcdx01ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <69263CCE5565AC45AC22C34C2EE000AB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; font-size: 14px; font-family: Calibri, sans-ser=
if; ">
<div style=3D"color: rgb(0, 0, 0); ">Hi Wim,</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">A few comments/questions inline ..&nbs=
p;</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil=
y: Calibri, sans-serif; ">
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLO=
R: rgb(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space">
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left">
<hr tabindex=3D"-1">
</div>
<div dir=3D"ltr" align=3D"left"><font size=3D"2" face=3D"Tahoma"><b>Von:</b=
> <a href=3D"mailto:nsc-bounces@ietf.org">
nsc-bounces@ietf.org</a> [<a href=3D"mailto:nsc-bounces@ietf.org">mailto:ns=
c-bounces@ietf.org</a>]
<b>Im Auftrag von </b>Henderickx, Wim (Wim)<br>
<b>Gesendet:</b> Mittwoch, 24. Juli 2013 11:52<br>
<b>An:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Betreff:</b> [nsc] Service chaining architecture question<br>
</font><br>
</div>
<div></div>
<div>I have a basic question with respect to the architecture/framework so =
far mentioned in the drafts in NSC. I understand the meta-data is a mechani=
sm to avoid multiple re-classifications when the packet enters the NSC doma=
in and identifies the chain of service
 functions. Now my understanding is that the services/applications are unaw=
are of the meta-data</div>
</div>
</div>
</span></div>
</div>
</span>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><font class=3D"Apple-style-span" color=3D"#ff0000">Jim&gt; this is tru=
e in the proxy-mode case but it is also possible that the service functions=
 themselves understand the NSH metadata. Both modes of operation are valid =
imho.&nbsp;</font></div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil=
y: Calibri, sans-serif; ">
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLO=
R: rgb(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space">
<div>and that a layer underneath should provide the mediation and that we u=
se a well defined interface to the application/service to indicate the chai=
n. In the context of Cloud/enterprise environment I can see this work given=
 you can use a dedicate VLAN e.g.
 within the tenant.</div>
</div>
</div>
</span></div>
</div>
</span>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><font class=3D"Apple-style-span" color=3D"#ff0000">Jim&gt; note that t=
he dedicated VLAN you describe is local between the proxy and the service e=
.g. We are not talking about domain-wide VLANs in this context. So this int=
erface between the proxy and the service
 is in fact a &quot;local identifier&quot; where that might be a VLAN but c=
ould also be something else such as the IP address of the residential consu=
mer. Further, the number of local identifier's you will need will be depend=
ent on the differentiation you require; for
 example, is differentiation needed by user, or &quot;class&quot; of user (=
i.e. Gold, silver, bronze analogy), or something else. &nbsp;</font><span c=
lass=3D"Apple-style-span" style=3D"color: rgb(255, 0, 0); ">So this boils d=
own to what the local identifier is used for and whether
 it has policy associated with it e.g. vlan-1 -&gt; do firewall rule &quot;=
x&quot;, vlan-2 -&gt; do firewall rule &quot;y&quot;, and so on.&nbsp;</spa=
n></div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil=
y: Calibri, sans-serif; ">
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLO=
R: rgb(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space">
<div>However we also try to address residential use cases for mobile and fi=
xed and here this becomes more tricky afais.&nbsp;In the residential enviro=
nment we can't expose a VLAN per application/service per chain since this w=
ould not be very effective. So I am wondering
 how we envision this to work?</div>
</div>
</div>
</span></div>
</div>
</span>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><font class=3D"Apple-style-span" color=3D"#ff0000">Jim&gt; <span class=
=3D"Apple-style-span" style=3D"font-family: Calibri; font-size: medium; ">
I'm assuming when you say residential, you mean serving residential custome=
rs with services in the POP or head-end, NOT services in the home right?&nb=
sp;</span></font></div>
</body>
</html>

--_000_68B171751455884590F8E38E96416F363F5C4483xmbrcdx01ciscoc_--

From jmh@joelhalpern.com  Wed Jul 24 13:46:47 2013
Return-Path: <jmh@joelhalpern.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBF311E8241 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zkCjdIGHbk9 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 13:46:42 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id A937B11E8273 for <nsc@ietf.org>; Wed, 24 Jul 2013 13:46:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A1D701D89C1; Wed, 24 Jul 2013 13:46:42 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9E2611D89D2; Wed, 24 Jul 2013 13:46:41 -0700 (PDT)
Message-ID: <51F03D30.4020401@joelhalpern.com>
Date: Wed, 24 Jul 2013 16:46:40 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ron Parker <Ron_Parker@affirmednetworks.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 20:46:47 -0000

Ron,
     maybe I am missing something, but you seem to lay out very nicely 
the case for wanting both service chain identification and separately 
subscriber identification.  Then the HTTP filter can use the subscriber 
ID to decide which exact content filtering behavior it should apply.  I 
would not want to fold that level of detail into the chain identification.

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> Dave,
>
> I agree that the number of chains is unlikely to scale to vast numbers
> (i.e., millions).     And I agree that it is bounded from a practical
> business perspective, as you point out.
>
> You may already be on this page, but I wanted to point out a distinction
> of coarse-grained definition of a service function vs. finer-grained
> definition of a service function.   Consider a service function to be
> logical in such a way that the identity of the logical function may also
> imply some differentiated behavior.   For example, a conceptual function
> is HTTP content filtering.    This conceptual function can then be
> further instantiated at the logical level based on differentiated
> policies such as content-filter-children, content-filter-adults-no-porn,
> content-filter-adults (I’m taking no stand on opt-in vs. opt-out, Mr.
> Cameron).   It may be that the same network element (dedicated physical
> box or virtual network function) realizes all 3 of the example
> policies.   The HTTP content filtering network function is really 3
> logical network functions from the perspective of inclusion in a service
> chain.   Now extend this to multiple conceptual functions that utilize
> differentiated policies and the number of combinations will grow, at
> least modestly.
>
> Thanks,
>
> Ron
>
> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf Of
> *David Allan I
> *Sent:* Wednesday, July 24, 2013 3:52 PM
> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> *Subject:* Re: [nsc] Service chaining architecture question
>
> Saying functions will have a problem with something that exists as a
> potential rationale for defining something new with exactly the same
> properties and problems does not quite work for me….
>
> VLANs on a vNIC or multiple vNICs (depending on the application stack
> construction and this being combined with application “cooperation” to
> preserve pairwise mappings of either VID/NIC tuples or simply NICs)
> currently exist as potential vehicles for preserving chain context and
> avoiding per hop classification. Anything else will be implemented more
> or less the same way and have exactly the same set of scaling and
> application design issues…Some extra information available on a single
> interface, or achieved by mapping chain instances onto one of a
> plurality of interfaces….
>
> But to back up… I’m not a carrier employee but I cannot envision a
> carrier offering potentially 1000s of distinct service bundles (“pick 53
> from column A and 49 from column B”). So I suspect a much smaller number
> is realistic for  the number of chains a function instance is expected
> to participate in, even allowing for dynamic reclassification of flows
> at a chain ingress to “skip a few functions”…. These are things that are
> fully operationalized in OSS, have policy associated with, have been
> industrialized and demonstrated to work prior to deployment. Going all
> combinatorial on this will break that big time….
>
> So are we really discussing a function participating in more than a
> handful of chain instances? And either a plurality of vNICs or VIDs
> being actually more than sufficient?
>
> Thanks
>
> Dave
>
> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> *Sent:* Wednesday, July 24, 2013 9:30 AM
> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>; nsc@ietf.org
> <mailto:nsc@ietf.org>
> *Subject:* Re: [nsc] Service chaining architecture question
>
> indeed
>
> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> *Date: *Wednesday 24 July 2013 15:54
> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> *Subject: *AW: Service chaining architecture question
>
> Hi Wim,
>
> I think not only effectivness/scalability might be a problem but also
> the fact that not all applications (service bringing functions) are able
> to handle packets coming from/going to potentially thousands of
> different VLANs at the same time. VLANs will work in certain
> environments but not in all. I see the need for an information exchange
> between the application and a mediation layer as well. Ideally this
> should be as simple as possible without heavy impact on the application
> itself (might be difficult to achieve but from my experience it is not
> very likely, that there will be big rewrites of existing applications in
> order to support the chaining).
>
>    regards
>
>       Nic
>
> ------------------------------------------------------------------------
>
> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> *Betreff:* [nsc] Service chaining architecture question
>
> I have a basic question with respect to the architecture/framework so
> far mentioned in the drafts in NSC. I understand the meta-data is a
> mechanism to avoid multiple re-classifications when the packet enters
> the NSC domain and identifies the chain of service functions. Now my
> understanding is that the services/applications are unaware of the
> meta-data and that a layer underneath should provide the mediation and
> that we use a well defined interface to the application/service to
> indicate the chain. In the context of Cloud/enterprise environment I can
> see this work given you can use a dedicate VLAN e.g. within the tenant.
> However we also try to address residential use cases for mobile and
> fixed and here this becomes more tricky afais. In the residential
> environment we can't expose a VLAN per application/service per chain
> since this would not be very effective. So I am wondering how we
> envision this to work?
>
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>

From Ron_Parker@affirmednetworks.com  Wed Jul 24 15:01:48 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD9711E8269 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPRcL98jAhbG for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:01:43 -0700 (PDT)
Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 1080311E815E for <nsc@ietf.org>; Wed, 24 Jul 2013 15:01:42 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0123.003; Wed, 24 Jul 2013 15:01:41 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwA==
Date: Wed, 24 Jul 2013 22:01:41 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>
In-Reply-To: <51F03D30.4020401@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 22:01:48 -0000

Joel,

IMO, the primary reason for understanding the subscriber identity at a netw=
ork service is to choose from a differentiated set of policies.    I think =
there is utility and efficiency in driving that selection from one place --=
 the network services classifier.     Say there were 2 groups of subscriber=
s -- children and adults.   Let's now define 2 chains, where the chains hav=
e a business-based meaning to the operator.    Chain 1 =3D HTTP-filter-chil=
d + Firewall-child.   Chain 2 =3D HTTP-filter-adult + Firewall-adult.    Th=
e referenced network services are logical and it is possible, but not requi=
red, that multiple logical network services be located at the same IP addre=
ss or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID, G=
RE key, NSH chain ID, ...) allows the IP-addressable server that realizes t=
hese service(s) to know two things -- 1) which logical network function sho=
uld be invoked and 2) which logical network function is next.=20

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Ron,
     maybe I am missing something, but you seem to lay out very nicely the =
case for wanting both service chain identification and separately subscribe=
r identification.  Then the HTTP filter can use the subscriber ID to decide=
 which exact content filtering behavior it should apply.  I would not want =
to fold that level of detail into the chain identification.

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> Dave,
>
> I agree that the number of chains is unlikely to scale to vast numbers
> (i.e., millions).     And I agree that it is bounded from a practical
> business perspective, as you point out.
>
> You may already be on this page, but I wanted to point out a=20
> distinction of coarse-grained definition of a service function vs. finer-=
grained
> definition of a service function.   Consider a service function to be
> logical in such a way that the identity of the logical function may also
> imply some differentiated behavior.   For example, a conceptual function
> is HTTP content filtering.    This conceptual function can then be
> further instantiated at the logical level based on differentiated=20
> policies such as content-filter-children,=20
> content-filter-adults-no-porn, content-filter-adults (I'm taking no stand=
 on opt-in vs. opt-out, Mr.
> Cameron).   It may be that the same network element (dedicated physical
> box or virtual network function) realizes all 3 of the example
> policies.   The HTTP content filtering network function is really 3
> logical network functions from the perspective of inclusion in a service
> chain.   Now extend this to multiple conceptual functions that utilize
> differentiated policies and the number of combinations will grow, at=20
> least modestly.
>
> Thanks,
>
> Ron
>
> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20
> Of *David Allan I
> *Sent:* Wednesday, July 24, 2013 3:52 PM
> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> *Subject:* Re: [nsc] Service chaining architecture question
>
> Saying functions will have a problem with something that exists as a=20
> potential rationale for defining something new with exactly the same=20
> properties and problems does not quite work for me....
>
> VLANs on a vNIC or multiple vNICs (depending on the application stack=20
> construction and this being combined with application "cooperation" to=20
> preserve pairwise mappings of either VID/NIC tuples or simply NICs)=20
> currently exist as potential vehicles for preserving chain context and=20
> avoiding per hop classification. Anything else will be implemented=20
> more or less the same way and have exactly the same set of scaling and=20
> application design issues...Some extra information available on a single=
=20
> interface, or achieved by mapping chain instances onto one of a=20
> plurality of interfaces....
>
> But to back up... I'm not a carrier employee but I cannot envision a=20
> carrier offering potentially 1000s of distinct service bundles ("pick=20
> 53 from column A and 49 from column B"). So I suspect a much smaller=20
> number is realistic for  the number of chains a function instance is=20
> expected to participate in, even allowing for dynamic reclassification=20
> of flows at a chain ingress to "skip a few functions".... These are=20
> things that are fully operationalized in OSS, have policy associated=20
> with, have been industrialized and demonstrated to work prior to=20
> deployment. Going all combinatorial on this will break that big time....
>
> So are we really discussing a function participating in more than a=20
> handful of chain instances? And either a plurality of vNICs or VIDs=20
> being actually more than sufficient?
>
> Thanks
>
> Dave
>
> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> *Sent:* Wednesday, July 24, 2013 9:30 AM
> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>; nsc@ietf.org=20
> <mailto:nsc@ietf.org>
> *Subject:* Re: [nsc] Service chaining architecture question
>
> indeed
>
> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> *Date: *Wednesday 24 July 2013 15:54
> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> *Subject: *AW: Service chaining architecture question
>
> Hi Wim,
>
> I think not only effectivness/scalability might be a problem but also=20
> the fact that not all applications (service bringing functions) are=20
> able to handle packets coming from/going to potentially thousands of=20
> different VLANs at the same time. VLANs will work in certain=20
> environments but not in all. I see the need for an information=20
> exchange between the application and a mediation layer as well.=20
> Ideally this should be as simple as possible without heavy impact on=20
> the application itself (might be difficult to achieve but from my=20
> experience it is not very likely, that there will be big rewrites of=20
> existing applications in order to support the chaining).
>
>    regards
>
>       Nic
>
> ----------------------------------------------------------------------
> --
>
> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> *Betreff:* [nsc] Service chaining architecture question
>
> I have a basic question with respect to the architecture/framework so=20
> far mentioned in the drafts in NSC. I understand the meta-data is a=20
> mechanism to avoid multiple re-classifications when the packet enters=20
> the NSC domain and identifies the chain of service functions. Now my=20
> understanding is that the services/applications are unaware of the=20
> meta-data and that a layer underneath should provide the mediation and=20
> that we use a well defined interface to the application/service to=20
> indicate the chain. In the context of Cloud/enterprise environment I=20
> can see this work given you can use a dedicate VLAN e.g. within the tenan=
t.
> However we also try to address residential use cases for mobile and=20
> fixed and here this becomes more tricky afais. In the residential=20
> environment we can't expose a VLAN per application/service per chain=20
> since this would not be very effective. So I am wondering how we=20
> envision this to work?
>
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>

From jguichar@cisco.com  Wed Jul 24 15:16:59 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913A711E8137 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BmJNeimIDRT for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:16:54 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1F84911E812D for <nsc@ietf.org>; Wed, 24 Jul 2013 15:16:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8703; q=dns/txt; s=iport; t=1374704213; x=1375913813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KMlXIjkIqRHIMSiaF6dIyvFYvYn+xbvSaDUqmB3OBE8=; b=kQFACy+tiPOPocelhsyhpSnUV9NOK6KMeqhhVA2EJOR1oxKGCmU0EuTw A5QZgy61WYD241GJ7eEVOWWZ+3RunJclxkgqbGpUBMHVSkG+r9X7FfMiA R+jhHpJ2B6k0sHGvDhYj/0evPrNXUe7KcMMGRUqDfZzME2BHkTSvHamZf A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFADdR8FGtJXG8/2dsb2JhbABSCYMGNb43gRYWdIIkAQEBAwEBAQE3LQcLBQcEAgEIEQECAQEBAR4JBycLFAMGCAIEDgWICgYMugMEjkWBBQgrBwIEgwxuA5QIg1eKM4cagxQ
X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208";a="239070653"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jul 2013 22:16:52 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6OMGqlt021865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 22:16:52 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 17:16:52 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyC
Date: Wed, 24 Jul 2013 22:16:51 +0000
Message-ID: <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 22:16:59 -0000

Ron,
Or alternatively carry the subscriber awareness in metadata thereby utilizi=
ng a single chain.

Sent from my iPhone

On Jul 24, 2013, at 6:02 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com>=
 wrote:

> Joel,
>=20
> IMO, the primary reason for understanding the subscriber identity at a ne=
twork service is to choose from a differentiated set of policies.    I thin=
k there is utility and efficiency in driving that selection from one place =
-- the network services classifier.     Say there were 2 groups of subscrib=
ers -- children and adults.   Let's now define 2 chains, where the chains h=
ave a business-based meaning to the operator.    Chain 1 =3D HTTP-filter-ch=
ild + Firewall-child.   Chain 2 =3D HTTP-filter-adult + Firewall-adult.    =
The referenced network services are logical and it is possible, but not req=
uired, that multiple logical network services be located at the same IP add=
ress or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID,=
 GRE key, NSH chain ID, ...) allows the IP-addressable server that realizes=
 these service(s) to know two things -- 1) which logical network function s=
hould be invoked and 2) which logical network function is next.=20
>=20
> Thanks.
> Ron
>=20
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20
> Sent: Wednesday, July 24, 2013 4:47 PM
> To: Ron Parker
> Cc: nsc@ietf.org
> Subject: Re: [nsc] Service chaining architecture question
>=20
> Ron,
>     maybe I am missing something, but you seem to lay out very nicely the=
 case for wanting both service chain identification and separately subscrib=
er identification.  Then the HTTP filter can use the subscriber ID to decid=
e which exact content filtering behavior it should apply.  I would not want=
 to fold that level of detail into the chain identification.
>=20
> Yours,
> Joel
>=20
> On 7/24/13 4:05 PM, Ron Parker wrote:
>> Dave,
>>=20
>> I agree that the number of chains is unlikely to scale to vast numbers
>> (i.e., millions).     And I agree that it is bounded from a practical
>> business perspective, as you point out.
>>=20
>> You may already be on this page, but I wanted to point out a=20
>> distinction of coarse-grained definition of a service function vs. finer=
-grained
>> definition of a service function.   Consider a service function to be
>> logical in such a way that the identity of the logical function may also
>> imply some differentiated behavior.   For example, a conceptual function
>> is HTTP content filtering.    This conceptual function can then be
>> further instantiated at the logical level based on differentiated=20
>> policies such as content-filter-children,=20
>> content-filter-adults-no-porn, content-filter-adults (I'm taking no stan=
d on opt-in vs. opt-out, Mr.
>> Cameron).   It may be that the same network element (dedicated physical
>> box or virtual network function) realizes all 3 of the example
>> policies.   The HTTP content filtering network function is really 3
>> logical network functions from the perspective of inclusion in a service
>> chain.   Now extend this to multiple conceptual functions that utilize
>> differentiated policies and the number of combinations will grow, at=20
>> least modestly.
>>=20
>> Thanks,
>>=20
>> Ron
>>=20
>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20
>> Of *David Allan I
>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> *Subject:* Re: [nsc] Service chaining architecture question
>>=20
>> Saying functions will have a problem with something that exists as a=20
>> potential rationale for defining something new with exactly the same=20
>> properties and problems does not quite work for me....
>>=20
>> VLANs on a vNIC or multiple vNICs (depending on the application stack=20
>> construction and this being combined with application "cooperation" to=20
>> preserve pairwise mappings of either VID/NIC tuples or simply NICs)=20
>> currently exist as potential vehicles for preserving chain context and=20
>> avoiding per hop classification. Anything else will be implemented=20
>> more or less the same way and have exactly the same set of scaling and=20
>> application design issues...Some extra information available on a single=
=20
>> interface, or achieved by mapping chain instances onto one of a=20
>> plurality of interfaces....
>>=20
>> But to back up... I'm not a carrier employee but I cannot envision a=20
>> carrier offering potentially 1000s of distinct service bundles ("pick=20
>> 53 from column A and 49 from column B"). So I suspect a much smaller=20
>> number is realistic for  the number of chains a function instance is=20
>> expected to participate in, even allowing for dynamic reclassification=20
>> of flows at a chain ingress to "skip a few functions".... These are=20
>> things that are fully operationalized in OSS, have policy associated=20
>> with, have been industrialized and demonstrated to work prior to=20
>> deployment. Going all combinatorial on this will break that big time....
>>=20
>> So are we really discussing a function participating in more than a=20
>> handful of chain instances? And either a plurality of vNICs or VIDs=20
>> being actually more than sufficient?
>>=20
>> Thanks
>>=20
>> Dave
>>=20
>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>; nsc@ietf.org=20
>> <mailto:nsc@ietf.org>
>> *Subject:* Re: [nsc] Service chaining architecture question
>>=20
>> indeed
>>=20
>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> *Date: *Wednesday 24 July 2013 15:54
>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> *Subject: *AW: Service chaining architecture question
>>=20
>> Hi Wim,
>>=20
>> I think not only effectivness/scalability might be a problem but also=20
>> the fact that not all applications (service bringing functions) are=20
>> able to handle packets coming from/going to potentially thousands of=20
>> different VLANs at the same time. VLANs will work in certain=20
>> environments but not in all. I see the need for an information=20
>> exchange between the application and a mediation layer as well.=20
>> Ideally this should be as simple as possible without heavy impact on=20
>> the application itself (might be difficult to achieve but from my=20
>> experience it is not very likely, that there will be big rewrites of=20
>> existing applications in order to support the chaining).
>>=20
>>   regards
>>=20
>>      Nic
>>=20
>> ----------------------------------------------------------------------
>> --
>>=20
>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> *Betreff:* [nsc] Service chaining architecture question
>>=20
>> I have a basic question with respect to the architecture/framework so=20
>> far mentioned in the drafts in NSC. I understand the meta-data is a=20
>> mechanism to avoid multiple re-classifications when the packet enters=20
>> the NSC domain and identifies the chain of service functions. Now my=20
>> understanding is that the services/applications are unaware of the=20
>> meta-data and that a layer underneath should provide the mediation and=20
>> that we use a well defined interface to the application/service to=20
>> indicate the chain. In the context of Cloud/enterprise environment I=20
>> can see this work given you can use a dedicate VLAN e.g. within the tena=
nt.
>> However we also try to address residential use cases for mobile and=20
>> fixed and here this becomes more tricky afais. In the residential=20
>> environment we can't expose a VLAN per application/service per chain=20
>> since this would not be very effective. So I am wondering how we=20
>> envision this to work?
>>=20
>>=20
>>=20
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From Ron_Parker@affirmednetworks.com  Wed Jul 24 15:20:30 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B40B11E824B for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OykKfZEhgZFX for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:20:23 -0700 (PDT)
Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 2925F11E8229 for <nsc@ietf.org>; Wed, 24 Jul 2013 15:20:23 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0123.003; Wed, 24 Jul 2013 15:20:22 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTA=
Date: Wed, 24 Jul 2013 22:20:22 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com>
In-Reply-To: <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 22:20:30 -0000

Jim,

Yes, that could work, too, conceptually.   But it does require that each co=
arsely-defined network service have access to a subscriber-aware policy res=
olution mechanism.   IMO, it is better to have fewer network elements makin=
g subscriber-aware policy decisions.

   Ron


-----Original Message-----
From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20
Sent: Wednesday, July 24, 2013 6:17 PM
To: Ron Parker
Cc: Joel M. Halpern; nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Ron,
Or alternatively carry the subscriber awareness in metadata thereby utilizi=
ng a single chain.

Sent from my iPhone

On Jul 24, 2013, at 6:02 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com>=
 wrote:

> Joel,
>=20
> IMO, the primary reason for understanding the subscriber identity at a ne=
twork service is to choose from a differentiated set of policies.    I thin=
k there is utility and efficiency in driving that selection from one place =
-- the network services classifier.     Say there were 2 groups of subscrib=
ers -- children and adults.   Let's now define 2 chains, where the chains h=
ave a business-based meaning to the operator.    Chain 1 =3D HTTP-filter-ch=
ild + Firewall-child.   Chain 2 =3D HTTP-filter-adult + Firewall-adult.    =
The referenced network services are logical and it is possible, but not req=
uired, that multiple logical network services be located at the same IP add=
ress or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID,=
 GRE key, NSH chain ID, ...) allows the IP-addressable server that realizes=
 these service(s) to know two things -- 1) which logical network function s=
hould be invoked and 2) which logical network function is next.=20
>=20
> Thanks.
> Ron
>=20
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Wednesday, July 24, 2013 4:47 PM
> To: Ron Parker
> Cc: nsc@ietf.org
> Subject: Re: [nsc] Service chaining architecture question
>=20
> Ron,
>     maybe I am missing something, but you seem to lay out very nicely the=
 case for wanting both service chain identification and separately subscrib=
er identification.  Then the HTTP filter can use the subscriber ID to decid=
e which exact content filtering behavior it should apply.  I would not want=
 to fold that level of detail into the chain identification.
>=20
> Yours,
> Joel
>=20
> On 7/24/13 4:05 PM, Ron Parker wrote:
>> Dave,
>>=20
>> I agree that the number of chains is unlikely to scale to vast numbers
>> (i.e., millions).     And I agree that it is bounded from a practical
>> business perspective, as you point out.
>>=20
>> You may already be on this page, but I wanted to point out a=20
>> distinction of coarse-grained definition of a service function vs. finer=
-grained
>> definition of a service function.   Consider a service function to be
>> logical in such a way that the identity of the logical function may also
>> imply some differentiated behavior.   For example, a conceptual function
>> is HTTP content filtering.    This conceptual function can then be
>> further instantiated at the logical level based on differentiated=20
>> policies such as content-filter-children,=20
>> content-filter-adults-no-porn, content-filter-adults (I'm taking no stan=
d on opt-in vs. opt-out, Mr.
>> Cameron).   It may be that the same network element (dedicated physical
>> box or virtual network function) realizes all 3 of the example
>> policies.   The HTTP content filtering network function is really 3
>> logical network functions from the perspective of inclusion in a service
>> chain.   Now extend this to multiple conceptual functions that utilize
>> differentiated policies and the number of combinations will grow, at=20
>> least modestly.
>>=20
>> Thanks,
>>=20
>> Ron
>>=20
>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20
>> Of *David Allan I
>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> *Subject:* Re: [nsc] Service chaining architecture question
>>=20
>> Saying functions will have a problem with something that exists as a=20
>> potential rationale for defining something new with exactly the same=20
>> properties and problems does not quite work for me....
>>=20
>> VLANs on a vNIC or multiple vNICs (depending on the application stack=20
>> construction and this being combined with application "cooperation"=20
>> to preserve pairwise mappings of either VID/NIC tuples or simply=20
>> NICs) currently exist as potential vehicles for preserving chain=20
>> context and avoiding per hop classification. Anything else will be=20
>> implemented more or less the same way and have exactly the same set=20
>> of scaling and application design issues...Some extra information=20
>> available on a single interface, or achieved by mapping chain=20
>> instances onto one of a plurality of interfaces....
>>=20
>> But to back up... I'm not a carrier employee but I cannot envision a=20
>> carrier offering potentially 1000s of distinct service bundles ("pick
>> 53 from column A and 49 from column B"). So I suspect a much smaller=20
>> number is realistic for  the number of chains a function instance is=20
>> expected to participate in, even allowing for dynamic=20
>> reclassification of flows at a chain ingress to "skip a few=20
>> functions".... These are things that are fully operationalized in=20
>> OSS, have policy associated with, have been industrialized and=20
>> demonstrated to work prior to deployment. Going all combinatorial on thi=
s will break that big time....
>>=20
>> So are we really discussing a function participating in more than a=20
>> handful of chain instances? And either a plurality of vNICs or VIDs=20
>> being actually more than sufficient?
>>=20
>> Thanks
>>=20
>> Dave
>>=20
>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
>> nsc@ietf.org <mailto:nsc@ietf.org>
>> *Subject:* Re: [nsc] Service chaining architecture question
>>=20
>> indeed
>>=20
>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> *Date: *Wednesday 24 July 2013 15:54
>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> *Subject: *AW: Service chaining architecture question
>>=20
>> Hi Wim,
>>=20
>> I think not only effectivness/scalability might be a problem but also=20
>> the fact that not all applications (service bringing functions) are=20
>> able to handle packets coming from/going to potentially thousands of=20
>> different VLANs at the same time. VLANs will work in certain=20
>> environments but not in all. I see the need for an information=20
>> exchange between the application and a mediation layer as well.
>> Ideally this should be as simple as possible without heavy impact on=20
>> the application itself (might be difficult to achieve but from my=20
>> experience it is not very likely, that there will be big rewrites of=20
>> existing applications in order to support the chaining).
>>=20
>>   regards
>>=20
>>      Nic
>>=20
>> ---------------------------------------------------------------------
>> -
>> --
>>=20
>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> *Betreff:* [nsc] Service chaining architecture question
>>=20
>> I have a basic question with respect to the architecture/framework so=20
>> far mentioned in the drafts in NSC. I understand the meta-data is a=20
>> mechanism to avoid multiple re-classifications when the packet enters=20
>> the NSC domain and identifies the chain of service functions. Now my=20
>> understanding is that the services/applications are unaware of the=20
>> meta-data and that a layer underneath should provide the mediation=20
>> and that we use a well defined interface to the application/service=20
>> to indicate the chain. In the context of Cloud/enterprise environment=20
>> I can see this work given you can use a dedicate VLAN e.g. within the te=
nant.
>> However we also try to address residential use cases for mobile and=20
>> fixed and here this becomes more tricky afais. In the residential=20
>> environment we can't expose a VLAN per application/service per chain=20
>> since this would not be very effective. So I am wondering how we=20
>> envision this to work?
>>=20
>>=20
>>=20
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From jguichar@cisco.com  Wed Jul 24 15:27:58 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451B021F9CA8 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4DFX9gsJyeR for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:27:53 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 79C9921F84E3 for <nsc@ietf.org>; Wed, 24 Jul 2013 15:27:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9716; q=dns/txt; s=iport; t=1374704872; x=1375914472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oSKihUae8aTXtwYsukeUQofs5bwM0gxFhGORv3hw7jk=; b=PpNr/8utAml+NZw3G7oxoADDBFts5RiRTVkTM10zwkHYl5XKvp8wOyWq 32bL0JC9r+ZN2S2RRC0LFwUvlYZD70tHCYIj7hFRXT0XJTWFB4LSTvg4j 7h5ZVU54mjf0h88kl5sz64bl303pecVXZzR3mZvSY8hI3kB9S7MJKTeHW c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFAIRU8FGtJXHA/2dsb2JhbABSCYMGNb43gRcWdIIkAQEBAwEBAQE3LQcLBQcEAgEIEQECAQEBAR4JBycLFAMGCAIEDgWICgYMugYEjkWBBQgrBwIEgwxuA5QIg1eKM4cagxQ
X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208";a="239068141"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 24 Jul 2013 22:27:49 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6OMRnbw023935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 22:27:49 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 17:27:49 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQD//65C4g==
Date: Wed, 24 Jul 2013 22:27:49 +0000
Message-ID: <425B7DC9-3A01-435F-B59A-0730FA343A78@cisco.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 22:27:58 -0000

Hi Ron,

I would think that either way requires an "identifier" to "service function=
" mapping to be available at the service invocation point.

Sent from my iPhone

On Jul 24, 2013, at 6:20 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com>=
 wrote:

> Jim,
>=20
> Yes, that could work, too, conceptually.   But it does require that each =
coarsely-defined network service have access to a subscriber-aware policy r=
esolution mechanism.   IMO, it is better to have fewer network elements mak=
ing subscriber-aware policy decisions.
>=20
>   Ron
>=20
>=20
> -----Original Message-----
> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20
> Sent: Wednesday, July 24, 2013 6:17 PM
> To: Ron Parker
> Cc: Joel M. Halpern; nsc@ietf.org
> Subject: Re: [nsc] Service chaining architecture question
>=20
> Ron,
> Or alternatively carry the subscriber awareness in metadata thereby utili=
zing a single chain.
>=20
> Sent from my iPhone
>=20
> On Jul 24, 2013, at 6:02 PM, "Ron Parker" <Ron_Parker@affirmednetworks.co=
m> wrote:
>=20
>> Joel,
>>=20
>> IMO, the primary reason for understanding the subscriber identity at a n=
etwork service is to choose from a differentiated set of policies.    I thi=
nk there is utility and efficiency in driving that selection from one place=
 -- the network services classifier.     Say there were 2 groups of subscri=
bers -- children and adults.   Let's now define 2 chains, where the chains =
have a business-based meaning to the operator.    Chain 1 =3D HTTP-filter-c=
hild + Firewall-child.   Chain 2 =3D HTTP-filter-adult + Firewall-adult.   =
 The referenced network services are logical and it is possible, but not re=
quired, that multiple logical network services be located at the same IP ad=
dress or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID=
, GRE key, NSH chain ID, ...) allows the IP-addressable server that realize=
s these service(s) to know two things -- 1) which logical network function =
should be invoked and 2) which logical network function is next.=20
>>=20
>> Thanks.
>> Ron
>>=20
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Wednesday, July 24, 2013 4:47 PM
>> To: Ron Parker
>> Cc: nsc@ietf.org
>> Subject: Re: [nsc] Service chaining architecture question
>>=20
>> Ron,
>>    maybe I am missing something, but you seem to lay out very nicely the=
 case for wanting both service chain identification and separately subscrib=
er identification.  Then the HTTP filter can use the subscriber ID to decid=
e which exact content filtering behavior it should apply.  I would not want=
 to fold that level of detail into the chain identification.
>>=20
>> Yours,
>> Joel
>>=20
>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>> Dave,
>>>=20
>>> I agree that the number of chains is unlikely to scale to vast numbers
>>> (i.e., millions).     And I agree that it is bounded from a practical
>>> business perspective, as you point out.
>>>=20
>>> You may already be on this page, but I wanted to point out a=20
>>> distinction of coarse-grained definition of a service function vs. fine=
r-grained
>>> definition of a service function.   Consider a service function to be
>>> logical in such a way that the identity of the logical function may als=
o
>>> imply some differentiated behavior.   For example, a conceptual functio=
n
>>> is HTTP content filtering.    This conceptual function can then be
>>> further instantiated at the logical level based on differentiated=20
>>> policies such as content-filter-children,=20
>>> content-filter-adults-no-porn, content-filter-adults (I'm taking no sta=
nd on opt-in vs. opt-out, Mr.
>>> Cameron).   It may be that the same network element (dedicated physical
>>> box or virtual network function) realizes all 3 of the example
>>> policies.   The HTTP content filtering network function is really 3
>>> logical network functions from the perspective of inclusion in a servic=
e
>>> chain.   Now extend this to multiple conceptual functions that utilize
>>> differentiated policies and the number of combinations will grow, at=20
>>> least modestly.
>>>=20
>>> Thanks,
>>>=20
>>> Ron
>>>=20
>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20
>>> Of *David Allan I
>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>=20
>>> Saying functions will have a problem with something that exists as a=20
>>> potential rationale for defining something new with exactly the same=20
>>> properties and problems does not quite work for me....
>>>=20
>>> VLANs on a vNIC or multiple vNICs (depending on the application stack=20
>>> construction and this being combined with application "cooperation"=20
>>> to preserve pairwise mappings of either VID/NIC tuples or simply=20
>>> NICs) currently exist as potential vehicles for preserving chain=20
>>> context and avoiding per hop classification. Anything else will be=20
>>> implemented more or less the same way and have exactly the same set=20
>>> of scaling and application design issues...Some extra information=20
>>> available on a single interface, or achieved by mapping chain=20
>>> instances onto one of a plurality of interfaces....
>>>=20
>>> But to back up... I'm not a carrier employee but I cannot envision a=20
>>> carrier offering potentially 1000s of distinct service bundles ("pick
>>> 53 from column A and 49 from column B"). So I suspect a much smaller=20
>>> number is realistic for  the number of chains a function instance is=20
>>> expected to participate in, even allowing for dynamic=20
>>> reclassification of flows at a chain ingress to "skip a few=20
>>> functions".... These are things that are fully operationalized in=20
>>> OSS, have policy associated with, have been industrialized and=20
>>> demonstrated to work prior to deployment. Going all combinatorial on th=
is will break that big time....
>>>=20
>>> So are we really discussing a function participating in more than a=20
>>> handful of chain instances? And either a plurality of vNICs or VIDs=20
>>> being actually more than sufficient?
>>>=20
>>> Thanks
>>>=20
>>> Dave
>>>=20
>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>=20
>>> indeed
>>>=20
>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>> *Date: *Wednesday 24 July 2013 15:54
>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>> *Subject: *AW: Service chaining architecture question
>>>=20
>>> Hi Wim,
>>>=20
>>> I think not only effectivness/scalability might be a problem but also=20
>>> the fact that not all applications (service bringing functions) are=20
>>> able to handle packets coming from/going to potentially thousands of=20
>>> different VLANs at the same time. VLANs will work in certain=20
>>> environments but not in all. I see the need for an information=20
>>> exchange between the application and a mediation layer as well.
>>> Ideally this should be as simple as possible without heavy impact on=20
>>> the application itself (might be difficult to achieve but from my=20
>>> experience it is not very likely, that there will be big rewrites of=20
>>> existing applications in order to support the chaining).
>>>=20
>>>  regards
>>>=20
>>>     Nic
>>>=20
>>> ---------------------------------------------------------------------
>>> -
>>> --
>>>=20
>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>> *Betreff:* [nsc] Service chaining architecture question
>>>=20
>>> I have a basic question with respect to the architecture/framework so=20
>>> far mentioned in the drafts in NSC. I understand the meta-data is a=20
>>> mechanism to avoid multiple re-classifications when the packet enters=20
>>> the NSC domain and identifies the chain of service functions. Now my=20
>>> understanding is that the services/applications are unaware of the=20
>>> meta-data and that a layer underneath should provide the mediation=20
>>> and that we use a well defined interface to the application/service=20
>>> to indicate the chain. In the context of Cloud/enterprise environment=20
>>> I can see this work given you can use a dedicate VLAN e.g. within the t=
enant.
>>> However we also try to address residential use cases for mobile and=20
>>> fixed and here this becomes more tricky afais. In the residential=20
>>> environment we can't expose a VLAN per application/service per chain=20
>>> since this would not be very effective. So I am wondering how we=20
>>> envision this to work?
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> nsc mailing list
>>> nsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nsc
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc

From linda.dunbar@huawei.com  Wed Jul 24 15:54:23 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D2311E811E for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-hxC+iuFyZQ for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:54:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1DF11E811B for <nsc@ietf.org>; Wed, 24 Jul 2013 15:54:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATT43549; Wed, 24 Jul 2013 22:54:06 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 23:53:06 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 23:54:03 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 15:53:56 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkA==
Date: Wed, 24 Jul 2013 22:53:56 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.128.98]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 22:54:23 -0000

Agree with Ron that it is better to have fewer nodes in network to make sub=
scriber-aware policy decisions.

Besides, it is not uncommon for multiple subscribers to share same sequence=
 of service modules. In this environment, if the network edge nodes, such a=
s Broadband Network Gateway or Cell Site Gateway, can use Layer 2 or 3 labe=
ls to mark the traffic, the subsequent network nodes can steer traffic to t=
he needed service modules without looking into "Mega data" or other higher =
layer fields in the data frames.=20

This approach can make "service chain" work without making changes to major=
ity of existing deployed network elements.=20

Linda =20



> -----Original Message-----
> Jim,
>=20
> Yes, that could work, too, conceptually.   But it does require that
> each coarsely-defined network service have access to a subscriber-aware
> policy resolution mechanism.   IMO, it is better to have fewer network
> elements making subscriber-aware policy decisions.


>=20
>    Ron
>=20
>=20
> -----Original Message-----
> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> Sent: Wednesday, July 24, 2013 6:17 PM
> To: Ron Parker
> Cc: Joel M. Halpern; nsc@ietf.org
> Subject: Re: [nsc] Service chaining architecture question
>=20
> Ron,
> Or alternatively carry the subscriber awareness in metadata thereby
> utilizing a single chain.
>=20
> Sent from my iPhone
>=20
> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> <Ron_Parker@affirmednetworks.com> wrote:
>=20
> > Joel,
> >
> > IMO, the primary reason for understanding the subscriber identity at
> a network service is to choose from a differentiated set of policies.
> I think there is utility and efficiency in driving that selection from
> one place -- the network services classifier.     Say there were 2
> groups of subscribers -- children and adults.   Let's now define 2
> chains, where the chains have a business-based meaning to the operator.
> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-filter=
-
> adult + Firewall-adult.    The referenced network services are logical
> and it is possible, but not required, that multiple logical network
> services be located at the same IP address or FQDN.     Conveying the
> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain ID, ...)
> allows the IP-addressable server that realizes these service(s) to know
> two things -- 1) which logical network function should be invoked and 2)
> which logical network function is next.
> >
> > Thanks.
> > Ron
> >
> > -----Original Message-----
> > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > Sent: Wednesday, July 24, 2013 4:47 PM
> > To: Ron Parker
> > Cc: nsc@ietf.org
> > Subject: Re: [nsc] Service chaining architecture question
> >
> > Ron,
> >     maybe I am missing something, but you seem to lay out very nicely
> the case for wanting both service chain identification and separately
> subscriber identification.  Then the HTTP filter can use the subscriber
> ID to decide which exact content filtering behavior it should apply.  I
> would not want to fold that level of detail into the chain
> identification.
> >
> > Yours,
> > Joel
> >
> > On 7/24/13 4:05 PM, Ron Parker wrote:
> >> Dave,
> >>
> >> I agree that the number of chains is unlikely to scale to vast
> numbers
> >> (i.e., millions).     And I agree that it is bounded from a
> practical
> >> business perspective, as you point out.
> >>
> >> You may already be on this page, but I wanted to point out a
> >> distinction of coarse-grained definition of a service function vs.
> finer-grained
> >> definition of a service function.   Consider a service function to
> be
> >> logical in such a way that the identity of the logical function may
> also
> >> imply some differentiated behavior.   For example, a conceptual
> function
> >> is HTTP content filtering.    This conceptual function can then be
> >> further instantiated at the logical level based on differentiated
> >> policies such as content-filter-children,
> >> content-filter-adults-no-porn, content-filter-adults (I'm taking no
> stand on opt-in vs. opt-out, Mr.
> >> Cameron).   It may be that the same network element (dedicated
> physical
> >> box or virtual network function) realizes all 3 of the example
> >> policies.   The HTTP content filtering network function is really 3
> >> logical network functions from the perspective of inclusion in a
> service
> >> chain.   Now extend this to multiple conceptual functions that
> utilize
> >> differentiated policies and the number of combinations will grow, at
> >> least modestly.
> >>
> >> Thanks,
> >>
> >> Ron
> >>
> >> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf
> >> Of *David Allan I
> >> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> >> *Subject:* Re: [nsc] Service chaining architecture question
> >>
> >> Saying functions will have a problem with something that exists as a
> >> potential rationale for defining something new with exactly the same
> >> properties and problems does not quite work for me....
> >>
> >> VLANs on a vNIC or multiple vNICs (depending on the application
> stack
> >> construction and this being combined with application "cooperation"
> >> to preserve pairwise mappings of either VID/NIC tuples or simply
> >> NICs) currently exist as potential vehicles for preserving chain
> >> context and avoiding per hop classification. Anything else will be
> >> implemented more or less the same way and have exactly the same set
> >> of scaling and application design issues...Some extra information
> >> available on a single interface, or achieved by mapping chain
> >> instances onto one of a plurality of interfaces....
> >>
> >> But to back up... I'm not a carrier employee but I cannot envision a
> >> carrier offering potentially 1000s of distinct service bundles
> ("pick
> >> 53 from column A and 49 from column B"). So I suspect a much smaller
> >> number is realistic for  the number of chains a function instance is
> >> expected to participate in, even allowing for dynamic
> >> reclassification of flows at a chain ingress to "skip a few
> >> functions".... These are things that are fully operationalized in
> >> OSS, have policy associated with, have been industrialized and
> >> demonstrated to work prior to deployment. Going all combinatorial on
> this will break that big time....
> >>
> >> So are we really discussing a function participating in more than a
> >> handful of chain instances? And either a plurality of vNICs or VIDs
> >> being actually more than sufficient?
> >>
> >> Thanks
> >>
> >> Dave
> >>
> >> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> >> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >> nsc@ietf.org <mailto:nsc@ietf.org>
> >> *Subject:* Re: [nsc] Service chaining architecture question
> >>
> >> indeed
> >>
> >> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >> *Date: *Wednesday 24 July 2013 15:54
> >> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >> *Subject: *AW: Service chaining architecture question
> >>
> >> Hi Wim,
> >>
> >> I think not only effectivness/scalability might be a problem but
> also
> >> the fact that not all applications (service bringing functions) are
> >> able to handle packets coming from/going to potentially thousands of
> >> different VLANs at the same time. VLANs will work in certain
> >> environments but not in all. I see the need for an information
> >> exchange between the application and a mediation layer as well.
> >> Ideally this should be as simple as possible without heavy impact on
> >> the application itself (might be difficult to achieve but from my
> >> experience it is not very likely, that there will be big rewrites of
> >> existing applications in order to support the chaining).
> >>
> >>   regards
> >>
> >>      Nic
> >>
> >> --------------------------------------------------------------------
> -
> >> -
> >> --
> >>
> >> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
> >> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >> *Betreff:* [nsc] Service chaining architecture question
> >>
> >> I have a basic question with respect to the architecture/framework
> so
> >> far mentioned in the drafts in NSC. I understand the meta-data is a
> >> mechanism to avoid multiple re-classifications when the packet
> enters
> >> the NSC domain and identifies the chain of service functions. Now my
> >> understanding is that the services/applications are unaware of the
> >> meta-data and that a layer underneath should provide the mediation
> >> and that we use a well defined interface to the application/service
> >> to indicate the chain. In the context of Cloud/enterprise
> environment
> >> I can see this work given you can use a dedicate VLAN e.g. within
> the tenant.
> >> However we also try to address residential use cases for mobile and
> >> fixed and here this becomes more tricky afais. In the residential
> >> environment we can't expose a VLAN per application/service per chain
> >> since this would not be very effective. So I am wondering how we
> >> envision this to work?
> >>
> >>
> >>
> >> _______________________________________________
> >> nsc mailing list
> >> nsc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nsc
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From david.i.allan@ericsson.com  Wed Jul 24 15:56:12 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A783111E811B for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55CwZA2VDJZN for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 15:56:07 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B853D11E8123 for <nsc@ietf.org>; Wed, 24 Jul 2013 15:56:06 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-6b-51f05b85ddad
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4F.26.13034.58B50F15; Thu, 25 Jul 2013 00:56:05 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 18:56:05 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAABmwg
Date: Wed, 24 Jul 2013 22:56:05 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D6775@eusaamb105.ericsson.se>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyuXRPgm5r9IdAg86/5hYfT71hsji+bz+b xYWnU5kdmD1eXHnG7LFkyU8mj3NTvjMGMEdx2aSk5mSWpRbp2yVwZZzbeoytYIlvxbeO1ewN jGvtuxg5OSQETCQ6PixnhbDFJC7cW8/WxcjFISRwlFHi77R2FghnOaPE3KnrWECq2AQMJPb8 /8IIYosIREs8ubqNGcRmFlCUOPJkNjuILSxgKXG8+TU7RI2VxNlN3VD1URLL5j4Aq2cRUJX4 2fwJbCavgK/Enr8foTbPYZZYtX06WDMn0IJTZ7ewgdiMQOd9P7WGCWKZuMStJ/OZIM4WkFiy 5zwzhC0q8fLxP6h3lCWWPNnPAlGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTM QtIyC0nLAkaWVYwcpcWpZbnpRgabGIHRc0yCTXcH456XlocYpTlYlMR5V+mdCRQSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAGJDCwDRD8sPZqpPdPbbq1lvPMVf+eXLyho2I4LddDO+CVJW2 X2KXN+D4+H96gO6vP1VmX5fdcfu7feqKrws279f52NdS7jzBKPnkufsPEzUX3HGueJhu9IDv Y0CZX0GJilWNko/ov6tqMgpfFU8dLz8s6hDxdNWReuHrVw0Ob0vcIpxfF9Iur8RSnJFoqMVc VJwIAK+Pz9BsAgAA
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 22:56:12 -0000

Hmmm

I would have a problem with this as I'm driving up the combinatorial number=
 of chains on the basis of identifying  specific policy classes. The actual=
 enforcement action may be similar, all HTTP requests processed against a c=
ommon database with multiple permit-deny classes in it. Specifying multiple=
 chains as a mechanism of encoding permit deny class is a hopeless overload=
ing of the chain identifier and pushing some degree of function awareness i=
nto the front end chain classifier.

This places an inappropriate burden on both the initial classification func=
tion as well as the intra chain networking. At the same time I would actual=
ly expect the individual HTTP filter function instances to participate in t=
he multiple sub-class chains as it likely is a common filtering database, a=
nd I wish to have a larger  flow base using that function at any given time=
 for statistical load balancing purposes. =20

My opinion of what a chain ID should do is identify a set of PEPs/VFs to be=
 traversed by any flow mapped to the chain, not to try and subclass PEPs/VF=
s of common function by making the front end classification subclass aware.=
  That actually strike me as an impediment to TTM as introduction of a new =
subclass involves software upgrade of multiple functions in the chain, but =
the function itself and the front end classifier...

My 2 cents
Dave



-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P=
arker
Sent: Wednesday, July 24, 2013 3:02 PM
To: Joel M. Halpern
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Joel,

IMO, the primary reason for understanding the subscriber identity at a netw=
ork service is to choose from a differentiated set of policies.    I think =
there is utility and efficiency in driving that selection from one place --=
 the network services classifier.     Say there were 2 groups of subscriber=
s -- children and adults.   Let's now define 2 chains, where the chains hav=
e a business-based meaning to the operator.    Chain 1 =3D HTTP-filter-chil=
d + Firewall-child.   Chain 2 =3D HTTP-filter-adult + Firewall-adult.    Th=
e referenced network services are logical and it is possible, but not requi=
red, that multiple logical network services be located at the same IP addre=
ss or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID, G=
RE key, NSH chain ID, ...) allows the IP-addressable server that realizes t=
hese service(s) to know two things -- 1) which logical network function sho=
uld be invoked and 2) which logical network function is next.=20

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Ron,
     maybe I am missing something, but you seem to lay out very nicely the =
case for wanting both service chain identification and separately subscribe=
r identification.  Then the HTTP filter can use the subscriber ID to decide=
 which exact content filtering behavior it should apply.  I would not want =
to fold that level of detail into the chain identification.

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> Dave,
>
> I agree that the number of chains is unlikely to scale to vast numbers
> (i.e., millions).     And I agree that it is bounded from a practical
> business perspective, as you point out.
>
> You may already be on this page, but I wanted to point out a=20
> distinction of coarse-grained definition of a service function vs. finer-=
grained
> definition of a service function.   Consider a service function to be
> logical in such a way that the identity of the logical function may also
> imply some differentiated behavior.   For example, a conceptual function
> is HTTP content filtering.    This conceptual function can then be
> further instantiated at the logical level based on differentiated=20
> policies such as content-filter-children,=20
> content-filter-adults-no-porn, content-filter-adults (I'm taking no stand=
 on opt-in vs. opt-out, Mr.
> Cameron).   It may be that the same network element (dedicated physical
> box or virtual network function) realizes all 3 of the example
> policies.   The HTTP content filtering network function is really 3
> logical network functions from the perspective of inclusion in a service
> chain.   Now extend this to multiple conceptual functions that utilize
> differentiated policies and the number of combinations will grow, at=20
> least modestly.
>
> Thanks,
>
> Ron
>
> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20
> Of *David Allan I
> *Sent:* Wednesday, July 24, 2013 3:52 PM
> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> *Subject:* Re: [nsc] Service chaining architecture question
>
> Saying functions will have a problem with something that exists as a=20
> potential rationale for defining something new with exactly the same=20
> properties and problems does not quite work for me....
>
> VLANs on a vNIC or multiple vNICs (depending on the application stack=20
> construction and this being combined with application "cooperation" to=20
> preserve pairwise mappings of either VID/NIC tuples or simply NICs)=20
> currently exist as potential vehicles for preserving chain context and=20
> avoiding per hop classification. Anything else will be implemented=20
> more or less the same way and have exactly the same set of scaling and=20
> application design issues...Some extra information available on a=20
> single interface, or achieved by mapping chain instances onto one of a=20
> plurality of interfaces....
>
> But to back up... I'm not a carrier employee but I cannot envision a=20
> carrier offering potentially 1000s of distinct service bundles ("pick
> 53 from column A and 49 from column B"). So I suspect a much smaller=20
> number is realistic for  the number of chains a function instance is=20
> expected to participate in, even allowing for dynamic reclassification=20
> of flows at a chain ingress to "skip a few functions".... These are=20
> things that are fully operationalized in OSS, have policy associated=20
> with, have been industrialized and demonstrated to work prior to=20
> deployment. Going all combinatorial on this will break that big time....
>
> So are we really discussing a function participating in more than a=20
> handful of chain instances? And either a plurality of vNICs or VIDs=20
> being actually more than sufficient?
>
> Thanks
>
> Dave
>
> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> *Sent:* Wednesday, July 24, 2013 9:30 AM
> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>; nsc@ietf.org=20
> <mailto:nsc@ietf.org>
> *Subject:* Re: [nsc] Service chaining architecture question
>
> indeed
>
> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> *Date: *Wednesday 24 July 2013 15:54
> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> *Subject: *AW: Service chaining architecture question
>
> Hi Wim,
>
> I think not only effectivness/scalability might be a problem but also=20
> the fact that not all applications (service bringing functions) are=20
> able to handle packets coming from/going to potentially thousands of=20
> different VLANs at the same time. VLANs will work in certain=20
> environments but not in all. I see the need for an information=20
> exchange between the application and a mediation layer as well.
> Ideally this should be as simple as possible without heavy impact on=20
> the application itself (might be difficult to achieve but from my=20
> experience it is not very likely, that there will be big rewrites of=20
> existing applications in order to support the chaining).
>
>    regards
>
>       Nic
>
> ----------------------------------------------------------------------
> --
>
> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> *Betreff:* [nsc] Service chaining architecture question
>
> I have a basic question with respect to the architecture/framework so=20
> far mentioned in the drafts in NSC. I understand the meta-data is a=20
> mechanism to avoid multiple re-classifications when the packet enters=20
> the NSC domain and identifies the chain of service functions. Now my=20
> understanding is that the services/applications are unaware of the=20
> meta-data and that a layer underneath should provide the mediation and=20
> that we use a well defined interface to the application/service to=20
> indicate the chain. In the context of Cloud/enterprise environment I=20
> can see this work given you can use a dedicate VLAN e.g. within the tenan=
t.
> However we also try to address residential use cases for mobile and=20
> fixed and here this becomes more tricky afais. In the residential=20
> environment we can't expose a VLAN per application/service per chain=20
> since this would not be very effective. So I am wondering how we=20
> envision this to work?
>
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

From david.i.allan@ericsson.com  Wed Jul 24 16:11:21 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD7811E8137 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLZaChn1GGfI for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:11:16 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B3DC711E812E for <nsc@ietf.org>; Wed, 24 Jul 2013 16:11:15 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-9b-51f05f13cd80
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 47.B6.13034.31F50F15; Thu, 25 Jul 2013 01:11:15 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 19:11:14 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: David Allan I <david.i.allan@ericsson.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAABmwggAAQEsA=
Date: Wed, 24 Jul 2013 23:11:14 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D6884@eusaamb105.ericsson.se>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <E6C17D2345AC7A45B7D054D407AA205C115D6775@eusaamb105.ericsson.se>
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C115D6775@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPlK5w/IdAgwcrZCw+nnrDZHF83342 iwtPpzI7MHu8uPKM2WPJkp9MHuemfGcMYI7isklJzcksSy3St0vgynj6dzFjwaeAiuMHfrA3 MG526mLk5JAQMJFYunkeM4QtJnHh3nq2LkYuDiGBo4wSZ3ZcY4JwljNK7Dxwhx2kik3AQGLP /y+MIAkRgXZGiQ0//zCCJJgFFCWOPJkNViQsYClxvPk1mC0iYCVxdlM3I4SdJPF2wSSgOAcH i4CqxM3jGSBhXgFfiRvn1rNCLHvALNH4uhWshlPAT+Ls33yQGkag676fWsMEsUpc4taT+UwQ VwtILNlzHuoDUYmXj/+xQtjKEkue7GeBqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ 2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjg02MwNg5JsGmu4Nxz0vLQ4zSHCxK4ryr9M4ECgmk J5akZqemFqQWxReV5qQWH2Jk4uCUamDcHsZx8NulbqmZe3+9b83f/lu++Y5m3U5e27Vebycl nv1QZJTkOUNqjkaES+CMBR3hJWfmM8mcm5+YZdymdHTmnBNXq1L1X9Y0fbR+LP/k9oUzDUc8 ztUfzbq4Snfa7cxLLzb0WJ5ie+e160XnEUFx650OXjtXRJzlqProztnpNHn27LdX5j+MV2Ip zkg01GIuKk4EAO4OwhRrAgAA
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:11:21 -0000

Joys of autocorrect....

An edit below c/but/both/

Cheers
D

-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David=
 Allan I
Sent: Wednesday, July 24, 2013 3:56 PM
To: Ron Parker; Joel M. Halpern
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Hmmm

I would have a problem with this as I'm driving up the combinatorial number=
 of chains on the basis of identifying  specific policy classes. The actual=
 enforcement action may be similar, all HTTP requests processed against a c=
ommon database with multiple permit-deny classes in it. Specifying multiple=
 chains as a mechanism of encoding permit deny class is a hopeless overload=
ing of the chain identifier and pushing some degree of function awareness i=
nto the front end chain classifier.

This places an inappropriate burden on both the initial classification func=
tion as well as the intra chain networking. At the same time I would actual=
ly expect the individual HTTP filter function instances to participate in t=
he multiple sub-class chains as it likely is a common filtering database, a=
nd I wish to have a larger  flow base using that function at any given time=
 for statistical load balancing purposes. =20

My opinion of what a chain ID should do is identify a set of PEPs/VFs to be=
 traversed by any flow mapped to the chain, not to try and subclass PEPs/VF=
s of common function by making the front end classification subclass aware.=
  That actually strike me as an impediment to TTM as introduction of a new =
subclass involves software upgrade of multiple functions in the chain, both=
 the function itself and the front end classifier...

My 2 cents
Dave



-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P=
arker
Sent: Wednesday, July 24, 2013 3:02 PM
To: Joel M. Halpern
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Joel,

IMO, the primary reason for understanding the subscriber identity at a netw=
ork service is to choose from a differentiated set of policies.    I think =
there is utility and efficiency in driving that selection from one place --=
 the network services classifier.     Say there were 2 groups of subscriber=
s -- children and adults.   Let's now define 2 chains, where the chains hav=
e a business-based meaning to the operator.    Chain 1 =3D HTTP-filter-chil=
d + Firewall-child.   Chain 2 =3D HTTP-filter-adult + Firewall-adult.    Th=
e referenced network services are logical and it is possible, but not requi=
red, that multiple logical network services be located at the same IP addre=
ss or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID, G=
RE key, NSH chain ID, ...) allows the IP-addressable server that realizes t=
hese service(s) to know two things -- 1) which logical network function sho=
uld be invoked and 2) which logical network function is next.=20

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Ron,
     maybe I am missing something, but you seem to lay out very nicely the =
case for wanting both service chain identification and separately subscribe=
r identification.  Then the HTTP filter can use the subscriber ID to decide=
 which exact content filtering behavior it should apply.  I would not want =
to fold that level of detail into the chain identification.

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> Dave,
>
> I agree that the number of chains is unlikely to scale to vast numbers
> (i.e., millions).     And I agree that it is bounded from a practical
> business perspective, as you point out.
>
> You may already be on this page, but I wanted to point out a=20
> distinction of coarse-grained definition of a service function vs. finer-=
grained
> definition of a service function.   Consider a service function to be
> logical in such a way that the identity of the logical function may also
> imply some differentiated behavior.   For example, a conceptual function
> is HTTP content filtering.    This conceptual function can then be
> further instantiated at the logical level based on differentiated=20
> policies such as content-filter-children,=20
> content-filter-adults-no-porn, content-filter-adults (I'm taking no stand=
 on opt-in vs. opt-out, Mr.
> Cameron).   It may be that the same network element (dedicated physical
> box or virtual network function) realizes all 3 of the example
> policies.   The HTTP content filtering network function is really 3
> logical network functions from the perspective of inclusion in a service
> chain.   Now extend this to multiple conceptual functions that utilize
> differentiated policies and the number of combinations will grow, at=20
> least modestly.
>
> Thanks,
>
> Ron
>
> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20
> Of *David Allan I
> *Sent:* Wednesday, July 24, 2013 3:52 PM
> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> *Subject:* Re: [nsc] Service chaining architecture question
>
> Saying functions will have a problem with something that exists as a=20
> potential rationale for defining something new with exactly the same=20
> properties and problems does not quite work for me....
>
> VLANs on a vNIC or multiple vNICs (depending on the application stack=20
> construction and this being combined with application "cooperation" to=20
> preserve pairwise mappings of either VID/NIC tuples or simply NICs)=20
> currently exist as potential vehicles for preserving chain context and=20
> avoiding per hop classification. Anything else will be implemented=20
> more or less the same way and have exactly the same set of scaling and=20
> application design issues...Some extra information available on a=20
> single interface, or achieved by mapping chain instances onto one of a=20
> plurality of interfaces....
>
> But to back up... I'm not a carrier employee but I cannot envision a=20
> carrier offering potentially 1000s of distinct service bundles ("pick
> 53 from column A and 49 from column B"). So I suspect a much smaller=20
> number is realistic for  the number of chains a function instance is=20
> expected to participate in, even allowing for dynamic reclassification=20
> of flows at a chain ingress to "skip a few functions".... These are=20
> things that are fully operationalized in OSS, have policy associated=20
> with, have been industrialized and demonstrated to work prior to=20
> deployment. Going all combinatorial on this will break that big time....
>
> So are we really discussing a function participating in more than a=20
> handful of chain instances? And either a plurality of vNICs or VIDs=20
> being actually more than sufficient?
>
> Thanks
>
> Dave
>
> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> *Sent:* Wednesday, July 24, 2013 9:30 AM
> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>; nsc@ietf.org=20
> <mailto:nsc@ietf.org>
> *Subject:* Re: [nsc] Service chaining architecture question
>
> indeed
>
> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> *Date: *Wednesday 24 July 2013 15:54
> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> *Subject: *AW: Service chaining architecture question
>
> Hi Wim,
>
> I think not only effectivness/scalability might be a problem but also=20
> the fact that not all applications (service bringing functions) are=20
> able to handle packets coming from/going to potentially thousands of=20
> different VLANs at the same time. VLANs will work in certain=20
> environments but not in all. I see the need for an information=20
> exchange between the application and a mediation layer as well.
> Ideally this should be as simple as possible without heavy impact on=20
> the application itself (might be difficult to achieve but from my=20
> experience it is not very likely, that there will be big rewrites of=20
> existing applications in order to support the chaining).
>
>    regards
>
>       Nic
>
> ----------------------------------------------------------------------
> --
>
> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> *Betreff:* [nsc] Service chaining architecture question
>
> I have a basic question with respect to the architecture/framework so=20
> far mentioned in the drafts in NSC. I understand the meta-data is a=20
> mechanism to avoid multiple re-classifications when the packet enters=20
> the NSC domain and identifies the chain of service functions. Now my=20
> understanding is that the services/applications are unaware of the=20
> meta-data and that a layer underneath should provide the mediation and=20
> that we use a well defined interface to the application/service to=20
> indicate the chain. In the context of Cloud/enterprise environment I=20
> can see this work given you can use a dedicate VLAN e.g. within the tenan=
t.
> However we also try to address residential use cases for mobile and=20
> fixed and here this becomes more tricky afais. In the residential=20
> environment we can't expose a VLAN per application/service per chain=20
> since this would not be very effective. So I am wondering how we=20
> envision this to work?
>
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

From jmh@joelhalpern.com  Wed Jul 24 16:12:37 2013
Return-Path: <jmh@joelhalpern.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54CA11E8137 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcG2wT5ZpzL4 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:12:33 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8A11E812E for <nsc@ietf.org>; Wed, 24 Jul 2013 16:12:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E3C471C06FE; Wed, 24 Jul 2013 16:12:30 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 643211C0541; Wed, 24 Jul 2013 16:12:29 -0700 (PDT)
Message-ID: <51F05F5C.5050202@joelhalpern.com>
Date: Wed, 24 Jul 2013 19:12:28 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Linda Dunbar <linda.dunbar@huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:12:37 -0000

Yes, having the chain ingress node mark the traffic makes good sense.
Having it mark the subscriber identity and the chain to be traversed 
seems quite sensible.

The difference I think I have with Ron is that he proposes to use one 
identifier for both entities.  That causes, as Dave said, a 
combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two MPLS 
labels.

And if the existing boxes don't know how to handle that (as seems 
likely) then we need a proxy / support function to translate the common 
protocol into whatever they used before we got something generally 
usable out there.

Yours,
Joel

On 7/24/13 6:53 PM, Linda Dunbar wrote:
>
> Agree with Ron that it is better to have fewer nodes in network to make subscriber-aware policy decisions.
>
> Besides, it is not uncommon for multiple subscribers to share same sequence of service modules. In this environment, if the network edge nodes, such as Broadband Network Gateway or Cell Site Gateway, can use Layer 2 or 3 labels to mark the traffic, the subsequent network nodes can steer traffic to the needed service modules without looking into "Mega data" or other higher layer fields in the data frames.
>
> This approach can make "service chain" work without making changes to majority of existing deployed network elements.
>
> Linda
>
>
>
>> -----Original Message-----
>> Jim,
>>
>> Yes, that could work, too, conceptually.   But it does require that
>> each coarsely-defined network service have access to a subscriber-aware
>> policy resolution mechanism.   IMO, it is better to have fewer network
>> elements making subscriber-aware policy decisions.
>
>
>>
>>     Ron
>>
>>
>> -----Original Message-----
>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> Sent: Wednesday, July 24, 2013 6:17 PM
>> To: Ron Parker
>> Cc: Joel M. Halpern; nsc@ietf.org
>> Subject: Re: [nsc] Service chaining architecture question
>>
>> Ron,
>> Or alternatively carry the subscriber awareness in metadata thereby
>> utilizing a single chain.
>>
>> Sent from my iPhone
>>
>> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> <Ron_Parker@affirmednetworks.com> wrote:
>>
>>> Joel,
>>>
>>> IMO, the primary reason for understanding the subscriber identity at
>> a network service is to choose from a differentiated set of policies.
>> I think there is utility and efficiency in driving that selection from
>> one place -- the network services classifier.     Say there were 2
>> groups of subscribers -- children and adults.   Let's now define 2
>> chains, where the chains have a business-based meaning to the operator.
>> Chain 1 = HTTP-filter-child + Firewall-child.   Chain 2 = HTTP-filter-
>> adult + Firewall-adult.    The referenced network services are logical
>> and it is possible, but not required, that multiple logical network
>> services be located at the same IP address or FQDN.     Conveying the
>> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain ID, ...)
>> allows the IP-addressable server that realizes these service(s) to know
>> two things -- 1) which logical network function should be invoked and 2)
>> which logical network function is next.
>>>
>>> Thanks.
>>> Ron
>>>
>>> -----Original Message-----
>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> Sent: Wednesday, July 24, 2013 4:47 PM
>>> To: Ron Parker
>>> Cc: nsc@ietf.org
>>> Subject: Re: [nsc] Service chaining architecture question
>>>
>>> Ron,
>>>      maybe I am missing something, but you seem to lay out very nicely
>> the case for wanting both service chain identification and separately
>> subscriber identification.  Then the HTTP filter can use the subscriber
>> ID to decide which exact content filtering behavior it should apply.  I
>> would not want to fold that level of detail into the chain
>> identification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>>> Dave,
>>>>
>>>> I agree that the number of chains is unlikely to scale to vast
>> numbers
>>>> (i.e., millions).     And I agree that it is bounded from a
>> practical
>>>> business perspective, as you point out.
>>>>
>>>> You may already be on this page, but I wanted to point out a
>>>> distinction of coarse-grained definition of a service function vs.
>> finer-grained
>>>> definition of a service function.   Consider a service function to
>> be
>>>> logical in such a way that the identity of the logical function may
>> also
>>>> imply some differentiated behavior.   For example, a conceptual
>> function
>>>> is HTTP content filtering.    This conceptual function can then be
>>>> further instantiated at the logical level based on differentiated
>>>> policies such as content-filter-children,
>>>> content-filter-adults-no-porn, content-filter-adults (I'm taking no
>> stand on opt-in vs. opt-out, Mr.
>>>> Cameron).   It may be that the same network element (dedicated
>> physical
>>>> box or virtual network function) realizes all 3 of the example
>>>> policies.   The HTTP content filtering network function is really 3
>>>> logical network functions from the perspective of inclusion in a
>> service
>>>> chain.   Now extend this to multiple conceptual functions that
>> utilize
>>>> differentiated policies and the number of combinations will grow, at
>>>> least modestly.
>>>>
>>>> Thanks,
>>>>
>>>> Ron
>>>>
>>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf
>>>> Of *David Allan I
>>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>>
>>>> Saying functions will have a problem with something that exists as a
>>>> potential rationale for defining something new with exactly the same
>>>> properties and problems does not quite work for me....
>>>>
>>>> VLANs on a vNIC or multiple vNICs (depending on the application
>> stack
>>>> construction and this being combined with application "cooperation"
>>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>>>> NICs) currently exist as potential vehicles for preserving chain
>>>> context and avoiding per hop classification. Anything else will be
>>>> implemented more or less the same way and have exactly the same set
>>>> of scaling and application design issues...Some extra information
>>>> available on a single interface, or achieved by mapping chain
>>>> instances onto one of a plurality of interfaces....
>>>>
>>>> But to back up... I'm not a carrier employee but I cannot envision a
>>>> carrier offering potentially 1000s of distinct service bundles
>> ("pick
>>>> 53 from column A and 49 from column B"). So I suspect a much smaller
>>>> number is realistic for  the number of chains a function instance is
>>>> expected to participate in, even allowing for dynamic
>>>> reclassification of flows at a chain ingress to "skip a few
>>>> functions".... These are things that are fully operationalized in
>>>> OSS, have policy associated with, have been industrialized and
>>>> demonstrated to work prior to deployment. Going all combinatorial on
>> this will break that big time....
>>>>
>>>> So are we really discussing a function participating in more than a
>>>> handful of chain instances? And either a plurality of vNICs or VIDs
>>>> being actually more than sufficient?
>>>>
>>>> Thanks
>>>>
>>>> Dave
>>>>
>>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>>
>>>> indeed
>>>>
>>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>>> *Date: *Wednesday 24 July 2013 15:54
>>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>>> *Subject: *AW: Service chaining architecture question
>>>>
>>>> Hi Wim,
>>>>
>>>> I think not only effectivness/scalability might be a problem but
>> also
>>>> the fact that not all applications (service bringing functions) are
>>>> able to handle packets coming from/going to potentially thousands of
>>>> different VLANs at the same time. VLANs will work in certain
>>>> environments but not in all. I see the need for an information
>>>> exchange between the application and a mediation layer as well.
>>>> Ideally this should be as simple as possible without heavy impact on
>>>> the application itself (might be difficult to achieve but from my
>>>> experience it is not very likely, that there will be big rewrites of
>>>> existing applications in order to support the chaining).
>>>>
>>>>    regards
>>>>
>>>>       Nic
>>>>
>>>> --------------------------------------------------------------------
>> -
>>>> -
>>>> --
>>>>
>>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
>>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>>> *Betreff:* [nsc] Service chaining architecture question
>>>>
>>>> I have a basic question with respect to the architecture/framework
>> so
>>>> far mentioned in the drafts in NSC. I understand the meta-data is a
>>>> mechanism to avoid multiple re-classifications when the packet
>> enters
>>>> the NSC domain and identifies the chain of service functions. Now my
>>>> understanding is that the services/applications are unaware of the
>>>> meta-data and that a layer underneath should provide the mediation
>>>> and that we use a well defined interface to the application/service
>>>> to indicate the chain. In the context of Cloud/enterprise
>> environment
>>>> I can see this work given you can use a dedicate VLAN e.g. within
>> the tenant.
>>>> However we also try to address residential use cases for mobile and
>>>> fixed and here this becomes more tricky afais. In the residential
>>>> environment we can't expose a VLAN per application/service per chain
>>>> since this would not be very effective. So I am wondering how we
>>>> envision this to work?
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> nsc mailing list
>>>> nsc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/nsc
>>> _______________________________________________
>>> nsc mailing list
>>> nsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nsc
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>

From jguichar@cisco.com  Wed Jul 24 16:29:55 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4221F8617 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqGDvqf6FYZc for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:29:50 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EA8C021F8613 for <nsc@ietf.org>; Wed, 24 Jul 2013 16:29:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11136; q=dns/txt; s=iport; t=1374708590; x=1375918190; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1jJJh++MYfqZAYFRKMvavyeuT4GB/qtiAFpgEt2lHAU=; b=LfKPcAYixUHeSLY2jSzO6tNLZz99tCyyb1i/lqiEeZjKxaObeQd7GxfL B02RLrHyZVG8G9jCdpqjLpfN8zqFtn+ioQTFu86oP3pgn9gbMFZIvoNhA OY89SnB9KTGJ0mFtL0k40Te0nP55GJIwZOxIu+SPTWuUwY/kE+/wuUpD7 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAIpi8FGtJV2Y/2dsb2JhbABSCYMGNVC9Z4EWFnSCJAEBAQMBAQEBJBMtBwsMBgEIEQECAQEBAQoUCS4LFAMGCAIEAQ0FCIgCBgy5dwSORYEFAgYrBwIEgwxuA5QIjgqHGoMUgio
X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208";a="239053846"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2013 23:29:47 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6ONTleN019732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 23:29:47 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 18:29:46 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAP//xvIA
Date: Wed, 24 Jul 2013 23:29:46 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5C47F0@xmb-rcd-x01.cisco.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.211]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0C2D79178432254EA027EFD89D9D1EB3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:29:55 -0000

Hi Linda,

The service chaining "problem" is not just about data plane and getting
packets from point A to point B. That's the easy bit. True, some basic
services may be just fine with this approach but the wider issue is how to
share "intelligence" between the network and services, and between
services. A simple label allocation may not satisfy such requirements.
Mapping 1:1 chain-id<->policy seems the wrong direction to take imho.

On 7/24/13 6:53 PM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:

>
>Agree with Ron that it is better to have fewer nodes in network to make
>subscriber-aware policy decisions.
>
>Besides, it is not uncommon for multiple subscribers to share same
>sequence of service modules. In this environment, if the network edge
>nodes, such as Broadband Network Gateway or Cell Site Gateway, can use
>Layer 2 or 3 labels to mark the traffic, the subsequent network nodes can
>steer traffic to the needed service modules without looking into "Mega
>data" or other higher layer fields in the data frames.
>
>This approach can make "service chain" work without making changes to
>majority of existing deployed network elements.
>
>Linda =20
>
>
>
>> -----Original Message-----
>> Jim,
>>=20
>> Yes, that could work, too, conceptually.   But it does require that
>> each coarsely-defined network service have access to a subscriber-aware
>> policy resolution mechanism.   IMO, it is better to have fewer network
>> elements making subscriber-aware policy decisions.
>
>
>>=20
>>    Ron
>>=20
>>=20
>> -----Original Message-----
>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> Sent: Wednesday, July 24, 2013 6:17 PM
>> To: Ron Parker
>> Cc: Joel M. Halpern; nsc@ietf.org
>> Subject: Re: [nsc] Service chaining architecture question
>>=20
>> Ron,
>> Or alternatively carry the subscriber awareness in metadata thereby
>> utilizing a single chain.
>>=20
>> Sent from my iPhone
>>=20
>> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> <Ron_Parker@affirmednetworks.com> wrote:
>>=20
>> > Joel,
>> >
>> > IMO, the primary reason for understanding the subscriber identity at
>> a network service is to choose from a differentiated set of policies.
>> I think there is utility and efficiency in driving that selection from
>> one place -- the network services classifier.     Say there were 2
>> groups of subscribers -- children and adults.   Let's now define 2
>> chains, where the chains have a business-based meaning to the operator.
>> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-filte=
r-
>> adult + Firewall-adult.    The referenced network services are logical
>> and it is possible, but not required, that multiple logical network
>> services be located at the same IP address or FQDN.     Conveying the
>> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain ID, ...)
>> allows the IP-addressable server that realizes these service(s) to know
>> two things -- 1) which logical network function should be invoked and 2)
>> which logical network function is next.
>> >
>> > Thanks.
>> > Ron
>> >
>> > -----Original Message-----
>> > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> > Sent: Wednesday, July 24, 2013 4:47 PM
>> > To: Ron Parker
>> > Cc: nsc@ietf.org
>> > Subject: Re: [nsc] Service chaining architecture question
>> >
>> > Ron,
>> >     maybe I am missing something, but you seem to lay out very nicely
>> the case for wanting both service chain identification and separately
>> subscriber identification.  Then the HTTP filter can use the subscriber
>> ID to decide which exact content filtering behavior it should apply.  I
>> would not want to fold that level of detail into the chain
>> identification.
>> >
>> > Yours,
>> > Joel
>> >
>> > On 7/24/13 4:05 PM, Ron Parker wrote:
>> >> Dave,
>> >>
>> >> I agree that the number of chains is unlikely to scale to vast
>> numbers
>> >> (i.e., millions).     And I agree that it is bounded from a
>> practical
>> >> business perspective, as you point out.
>> >>
>> >> You may already be on this page, but I wanted to point out a
>> >> distinction of coarse-grained definition of a service function vs.
>> finer-grained
>> >> definition of a service function.   Consider a service function to
>> be
>> >> logical in such a way that the identity of the logical function may
>> also
>> >> imply some differentiated behavior.   For example, a conceptual
>> function
>> >> is HTTP content filtering.    This conceptual function can then be
>> >> further instantiated at the logical level based on differentiated
>> >> policies such as content-filter-children,
>> >> content-filter-adults-no-porn, content-filter-adults (I'm taking no
>> stand on opt-in vs. opt-out, Mr.
>> >> Cameron).   It may be that the same network element (dedicated
>> physical
>> >> box or virtual network function) realizes all 3 of the example
>> >> policies.   The HTTP content filtering network function is really 3
>> >> logical network functions from the perspective of inclusion in a
>> service
>> >> chain.   Now extend this to multiple conceptual functions that
>> utilize
>> >> differentiated policies and the number of combinations will grow, at
>> >> least modestly.
>> >>
>> >> Thanks,
>> >>
>> >> Ron
>> >>
>> >> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf
>> >> Of *David Allan I
>> >> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> >> *Subject:* Re: [nsc] Service chaining architecture question
>> >>
>> >> Saying functions will have a problem with something that exists as a
>> >> potential rationale for defining something new with exactly the same
>> >> properties and problems does not quite work for me....
>> >>
>> >> VLANs on a vNIC or multiple vNICs (depending on the application
>> stack
>> >> construction and this being combined with application "cooperation"
>> >> to preserve pairwise mappings of either VID/NIC tuples or simply
>> >> NICs) currently exist as potential vehicles for preserving chain
>> >> context and avoiding per hop classification. Anything else will be
>> >> implemented more or less the same way and have exactly the same set
>> >> of scaling and application design issues...Some extra information
>> >> available on a single interface, or achieved by mapping chain
>> >> instances onto one of a plurality of interfaces....
>> >>
>> >> But to back up... I'm not a carrier employee but I cannot envision a
>> >> carrier offering potentially 1000s of distinct service bundles
>> ("pick
>> >> 53 from column A and 49 from column B"). So I suspect a much smaller
>> >> number is realistic for  the number of chains a function instance is
>> >> expected to participate in, even allowing for dynamic
>> >> reclassification of flows at a chain ingress to "skip a few
>> >> functions".... These are things that are fully operationalized in
>> >> OSS, have policy associated with, have been industrialized and
>> >> demonstrated to work prior to deployment. Going all combinatorial on
>> this will break that big time....
>> >>
>> >> So are we really discussing a function participating in more than a
>> >> handful of chain instances? And either a plurality of vNICs or VIDs
>> >> being actually more than sufficient?
>> >>
>> >> Thanks
>> >>
>> >> Dave
>> >>
>> >> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>> >> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>> >> nsc@ietf.org <mailto:nsc@ietf.org>
>> >> *Subject:* Re: [nsc] Service chaining architecture question
>> >>
>> >> indeed
>> >>
>> >> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >> *Date: *Wednesday 24 July 2013 15:54
>> >> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>> >> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >> *Subject: *AW: Service chaining architecture question
>> >>
>> >> Hi Wim,
>> >>
>> >> I think not only effectivness/scalability might be a problem but
>> also
>> >> the fact that not all applications (service bringing functions) are
>> >> able to handle packets coming from/going to potentially thousands of
>> >> different VLANs at the same time. VLANs will work in certain
>> >> environments but not in all. I see the need for an information
>> >> exchange between the application and a mediation layer as well.
>> >> Ideally this should be as simple as possible without heavy impact on
>> >> the application itself (might be difficult to achieve but from my
>> >> experience it is not very likely, that there will be big rewrites of
>> >> existing applications in order to support the chaining).
>> >>
>> >>   regards
>> >>
>> >>      Nic
>> >>
>> >> --------------------------------------------------------------------
>> -
>> >> -
>> >> --
>> >>
>> >> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
>> >> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >> *Betreff:* [nsc] Service chaining architecture question
>> >>
>> >> I have a basic question with respect to the architecture/framework
>> so
>> >> far mentioned in the drafts in NSC. I understand the meta-data is a
>> >> mechanism to avoid multiple re-classifications when the packet
>> enters
>> >> the NSC domain and identifies the chain of service functions. Now my
>> >> understanding is that the services/applications are unaware of the
>> >> meta-data and that a layer underneath should provide the mediation
>> >> and that we use a well defined interface to the application/service
>> >> to indicate the chain. In the context of Cloud/enterprise
>> environment
>> >> I can see this work given you can use a dedicate VLAN e.g. within
>> the tenant.
>> >> However we also try to address residential use cases for mobile and
>> >> fixed and here this becomes more tricky afais. In the residential
>> >> environment we can't expose a VLAN per application/service per chain
>> >> since this would not be very effective. So I am wondering how we
>> >> envision this to work?
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> nsc mailing list
>> >> nsc@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/nsc
>> > _______________________________________________
>> > nsc mailing list
>> > nsc@ietf.org
>> > https://www.ietf.org/mailman/listinfo/nsc
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From linda.dunbar@huawei.com  Wed Jul 24 16:30:25 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37D321F864D for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi+0+btNZOYg for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:30:21 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1A21F8618 for <nsc@ietf.org>; Wed, 24 Jul 2013 16:30:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ89154; Wed, 24 Jul 2013 23:30:17 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 00:30:02 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 00:30:16 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 16:30:09 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAPrusAAA6WcXA=
Date: Wed, 24 Jul 2013 23:30:09 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com>
In-Reply-To: <51F05F5C.5050202@joelhalpern.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.128.98]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645B4D37Edfweml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:30:26 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4D37Edfweml509mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Joel,

> -----Original Message-----
>
> Yes, having the chain ingress node mark the traffic makes good sense.
> Having it mark the subscriber identity and the chain to be traversed
> seems quite sensible.
>
> The difference I think I have with Ron is that he proposes to use one
> identifier for both entities.

[Linda] I hope you don't mean per subscriber identity, do you? With today's=
 PCRF, subscribers are categorized based on their subscription types. Throu=
ghout the network, the "subscription types" dictate what service modules th=
eir corresponding traffic need to traverse through.
Some service modules might need to examine packets deeper (i.e. look into p=
ayload) for their intended functions. They may need to extract the "HTTP he=
ader" or HTTP messages from one or multiple packets.



That causes, as Dave said, a
> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two MPLS
> labels.

[Linda] It doesn't have to be two "VLANs" or two MPLS, right?
The subscriber identity could be some bits in the payload.


>
> And if the existing boxes don't know how to handle that (as seems
> likely) then we need a proxy / support function to translate the common
> protocol into whatever they used before we got something generally
> usable out there.
>
> Yours,
> Joel
>
> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >
> > Agree with Ron that it is better to have fewer nodes in network to
> make subscriber-aware policy decisions.
> >
> > Besides, it is not uncommon for multiple subscribers to share same
> sequence of service modules. In this environment, if the network edge
> nodes, such as Broadband Network Gateway or Cell Site Gateway, can use
> Layer 2 or 3 labels to mark the traffic, the subsequent network nodes
> can steer traffic to the needed service modules without looking into
> "Mega data" or other higher layer fields in the data frames.
> >
> > This approach can make "service chain" work without making changes to
> majority of existing deployed network elements.
> >
> > Linda
> >
> >
> >
> >> -----Original Message-----
> >> Jim,
> >>
> >> Yes, that could work, too, conceptually.   But it does require that
> >> each coarsely-defined network service have access to a subscriber-
> aware
> >> policy resolution mechanism.   IMO, it is better to have fewer
> network
> >> elements making subscriber-aware policy decisions.
> >
> >
> >>
> >>     Ron
> >>
> >>
> >> -----Original Message-----
> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >> To: Ron Parker
> >> Cc: Joel M. Halpern; nsc@ietf.org
> >> Subject: Re: [nsc] Service chaining architecture question
> >>
> >> Ron,
> >> Or alternatively carry the subscriber awareness in metadata thereby
> >> utilizing a single chain.
> >>
> >> Sent from my iPhone
> >>
> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >> <Ron_Parker@affirmednetworks.com> wrote:
> >>
> >>> Joel,
> >>>
> >>> IMO, the primary reason for understanding the subscriber identity
> at
> >> a network service is to choose from a differentiated set of policies.
> >> I think there is utility and efficiency in driving that selection
> from
> >> one place -- the network services classifier.     Say there were 2
> >> groups of subscribers -- children and adults.   Let's now define 2
> >> chains, where the chains have a business-based meaning to the
> operator.
> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
> filter-
> >> adult + Firewall-adult.    The referenced network services are
> logical
> >> and it is possible, but not required, that multiple logical network
> >> services be located at the same IP address or FQDN.     Conveying
> the
> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> ID, ...)
> >> allows the IP-addressable server that realizes these service(s) to
> know
> >> two things -- 1) which logical network function should be invoked
> and 2)
> >> which logical network function is next.
> >>>
> >>> Thanks.
> >>> Ron
> >>>
> >>> -----Original Message-----
> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> >>> To: Ron Parker
> >>> Cc: nsc@ietf.org
> >>> Subject: Re: [nsc] Service chaining architecture question
> >>>
> >>> Ron,
> >>>      maybe I am missing something, but you seem to lay out very
> nicely
> >> the case for wanting both service chain identification and
> separately
> >> subscriber identification.  Then the HTTP filter can use the
> subscriber
> >> ID to decide which exact content filtering behavior it should apply.
> I
> >> would not want to fold that level of detail into the chain
> >> identification.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >>>> Dave,
> >>>>
> >>>> I agree that the number of chains is unlikely to scale to vast
> >> numbers
> >>>> (i.e., millions).     And I agree that it is bounded from a
> >> practical
> >>>> business perspective, as you point out.
> >>>>
> >>>> You may already be on this page, but I wanted to point out a
> >>>> distinction of coarse-grained definition of a service function vs.
> >> finer-grained
> >>>> definition of a service function.   Consider a service function to
> >> be
> >>>> logical in such a way that the identity of the logical function
> may
> >> also
> >>>> imply some differentiated behavior.   For example, a conceptual
> >> function
> >>>> is HTTP content filtering.    This conceptual function can then be
> >>>> further instantiated at the logical level based on differentiated
> >>>> policies such as content-filter-children,
> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
> no
> >> stand on opt-in vs. opt-out, Mr.
> >>>> Cameron).   It may be that the same network element (dedicated
> >> physical
> >>>> box or virtual network function) realizes all 3 of the example
> >>>> policies.   The HTTP content filtering network function is really
> 3
> >>>> logical network functions from the perspective of inclusion in a
> >> service
> >>>> chain.   Now extend this to multiple conceptual functions that
> >> utilize
> >>>> differentiated policies and the number of combinations will grow,
> at
> >>>> least modestly.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Ron
> >>>>
> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
> Behalf
> >>>> Of *David Allan I
> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>>>
> >>>> Saying functions will have a problem with something that exists as
> a
> >>>> potential rationale for defining something new with exactly the
> same
> >>>> properties and problems does not quite work for me....
> >>>>
> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
> >> stack
> >>>> construction and this being combined with application
> "cooperation"
> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
> >>>> NICs) currently exist as potential vehicles for preserving chain
> >>>> context and avoiding per hop classification. Anything else will be
> >>>> implemented more or less the same way and have exactly the same
> set
> >>>> of scaling and application design issues...Some extra information
> >>>> available on a single interface, or achieved by mapping chain
> >>>> instances onto one of a plurality of interfaces....
> >>>>
> >>>> But to back up... I'm not a carrier employee but I cannot envision
> a
> >>>> carrier offering potentially 1000s of distinct service bundles
> >> ("pick
> >>>> 53 from column A and 49 from column B"). So I suspect a much
> smaller
> >>>> number is realistic for  the number of chains a function instance
> is
> >>>> expected to participate in, even allowing for dynamic
> >>>> reclassification of flows at a chain ingress to "skip a few
> >>>> functions".... These are things that are fully operationalized in
> >>>> OSS, have policy associated with, have been industrialized and
> >>>> demonstrated to work prior to deployment. Going all combinatorial
> on
> >> this will break that big time....
> >>>>
> >>>> So are we really discussing a function participating in more than
> a
> >>>> handful of chain instances? And either a plurality of vNICs or
> VIDs
> >>>> being actually more than sufficient?
> >>>>
> >>>> Thanks
> >>>>
> >>>> Dave
> >>>>
> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>>>
> >>>> indeed
> >>>>
> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >>>> *Date: *Wednesday 24 July 2013 15:54
> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >>>> *Subject: *AW: Service chaining architecture question
> >>>>
> >>>> Hi Wim,
> >>>>
> >>>> I think not only effectivness/scalability might be a problem but
> >> also
> >>>> the fact that not all applications (service bringing functions)
> are
> >>>> able to handle packets coming from/going to potentially thousands
> of
> >>>> different VLANs at the same time. VLANs will work in certain
> >>>> environments but not in all. I see the need for an information
> >>>> exchange between the application and a mediation layer as well.
> >>>> Ideally this should be as simple as possible without heavy impact
> on
> >>>> the application itself (might be difficult to achieve but from my
> >>>> experience it is not very likely, that there will be big rewrites
> of
> >>>> existing applications in order to support the chaining).
> >>>>
> >>>>    regards
> >>>>
> >>>>       Nic
> >>>>
> >>>> ------------------------------------------------------------------
> --
> >> -
> >>>> -
> >>>> --
> >>>>
> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
> (Wim)
> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >>>> *Betreff:* [nsc] Service chaining architecture question
> >>>>
> >>>> I have a basic question with respect to the architecture/framework
> >> so
> >>>> far mentioned in the drafts in NSC. I understand the meta-data is
> a
> >>>> mechanism to avoid multiple re-classifications when the packet
> >> enters
> >>>> the NSC domain and identifies the chain of service functions. Now
> my
> >>>> understanding is that the services/applications are unaware of the
> >>>> meta-data and that a layer underneath should provide the mediation
> >>>> and that we use a well defined interface to the
> application/service
> >>>> to indicate the chain. In the context of Cloud/enterprise
> >> environment
> >>>> I can see this work given you can use a dedicate VLAN e.g. within
> >> the tenant.
> >>>> However we also try to address residential use cases for mobile
> and
> >>>> fixed and here this becomes more tricky afais. In the residential
> >>>> environment we can't expose a VLAN per application/service per
> chain
> >>>> since this would not be very effective. So I am wondering how we
> >>>> envision this to work?
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> nsc mailing list
> >>>> nsc@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/nsc
> >>> _______________________________________________
> >>> nsc mailing list
> >>> nsc@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/nsc
> >> _______________________________________________
> >> nsc mailing list
> >> nsc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nsc
> >


--_000_4A95BA014132FF49AE685FAB4B9F17F645B4D37Edfweml509mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Consolas" size=3D"2"><span style=3D"font-size:10.5pt;">
<div>Joel, </div>
<div><font face=3D"Times New Roman">&nbsp;</font></div>
<div>&gt; -----Original Message-----</div>
<div>&gt; </div>
<div>&gt; Yes, having the chain ingress node mark the traffic makes good se=
nse.</div>
<div>&gt; Having it mark the subscriber identity and the chain to be traver=
sed</div>
<div>&gt; seems quite sensible.</div>
<div>&gt; </div>
<div>&gt; The difference I think I have with Ron is that he proposes to use=
 one</div>
<div>&gt; identifier for both entities.&nbsp; </div>
<div><font face=3D"Times New Roman">&nbsp;</font></div>
<div><font color=3D"#7030A0">[Linda] I hope you don't mean per subscriber i=
dentity, do you? With today's PCRF, subscribers are categorized based on th=
eir subscription types. Throughout the network, the &quot;subscription type=
s&quot; dictate what service modules their corresponding
traffic need to traverse through. </font></div>
<div><font color=3D"#7030A0">Some service modules might need to examine pac=
kets deeper (i.e. look into payload) for their intended functions. They may=
 need to extract the &quot;HTTP header&quot; or HTTP messages from one or m=
ultiple packets.</font></div>
<div><font face=3D"Times New Roman" color=3D"#7030A0">&nbsp;</font></div>
<div><font face=3D"Times New Roman">&nbsp;</font></div>
<div>  </div>
<div>That causes, as Dave said, a</div>
<div>&gt; combinatorial explosion.&nbsp; Rather, use two fields.&nbsp; Two =
VLANs.&nbsp; Two MPLS</div>
<div>&gt; labels.</div>
<div><font face=3D"Times New Roman">&nbsp;</font></div>
<div><font color=3D"#7030A0">[Linda] It doesn't have to be two &quot;VLANs&=
quot; or two MPLS, right? </font></div>
<div><font color=3D"#7030A0">The subscriber identity could be some bits in =
the payload. </font></div>
<div><font face=3D"Times New Roman">&nbsp;</font></div>
<div><font face=3D"Times New Roman">&nbsp;</font></div>
<div>&gt; </div>
<div>&gt; And if the existing boxes don't know how to handle that (as seems=
</div>
<div>&gt; likely) then we need a proxy / support function to translate the =
common</div>
<div>&gt; protocol into whatever they used before we got something generall=
y</div>
<div>&gt; usable out there.</div>
<div>&gt; </div>
<div>&gt; Yours,</div>
<div>&gt; Joel</div>
<div>&gt; </div>
<div>&gt; On 7/24/13 6:53 PM, Linda Dunbar wrote:</div>
<div>&gt; &gt;</div>
<div>&gt; &gt; Agree with Ron that it is better to have fewer nodes in netw=
ork to</div>
<div>&gt; make subscriber-aware policy decisions.</div>
<div>&gt; &gt;</div>
<div>&gt; &gt; Besides, it is not uncommon for multiple subscribers to shar=
e same</div>
<div>&gt; sequence of service modules. In this environment, if the network =
edge</div>
<div>&gt; nodes, such as Broadband Network Gateway or Cell Site Gateway, ca=
n use</div>
<div>&gt; Layer 2 or 3 labels to mark the traffic, the subsequent network n=
odes</div>
<div>&gt; can steer traffic to the needed service modules without looking i=
nto</div>
<div>&gt; &quot;Mega data&quot; or other higher layer fields in the data fr=
ames.</div>
<div>&gt; &gt;</div>
<div>&gt; &gt; This approach can make &quot;service chain&quot; work withou=
t making changes to</div>
<div>&gt; majority of existing deployed network elements.</div>
<div>&gt; &gt;</div>
<div>&gt; &gt; Linda</div>
<div>&gt; &gt;</div>
<div>&gt; &gt;</div>
<div>&gt; &gt;</div>
<div>&gt; &gt;&gt; -----Original Message-----</div>
<div>&gt; &gt;&gt; Jim,</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt; Yes, that could work, too, conceptually.&nbsp;&nbsp; But=
 it does require that</div>
<div>&gt; &gt;&gt; each coarsely-defined network service have access to a s=
ubscriber-</div>
<div>&gt; aware</div>
<div>&gt; &gt;&gt; policy resolution mechanism.&nbsp;&nbsp; IMO, it is bett=
er to have fewer</div>
<div>&gt; network</div>
<div>&gt; &gt;&gt; elements making subscriber-aware policy decisions.</div>
<div>&gt; &gt;</div>
<div>&gt; &gt;</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Ron</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt; -----Original Message-----</div>
<div>&gt; &gt;&gt; From: Jim Guichard (jguichar) [<a href=3D"mailto:jguicha=
r@cisco.com">mailto:jguichar@cisco.com</a>]</div>
<div>&gt; &gt;&gt; Sent: Wednesday, July 24, 2013 6:17 PM</div>
<div>&gt; &gt;&gt; To: Ron Parker</div>
<div>&gt; &gt;&gt; Cc: Joel M. Halpern; nsc@ietf.org</div>
<div>&gt; &gt;&gt; Subject: Re: [nsc] Service chaining architecture questio=
n</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt; Ron,</div>
<div>&gt; &gt;&gt; Or alternatively carry the subscriber awareness in metad=
ata thereby</div>
<div>&gt; &gt;&gt; utilizing a single chain.</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt; Sent from my iPhone</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt; On Jul 24, 2013, at 6:02 PM, &quot;Ron Parker&quot;</div=
>
<div>&gt; &gt;&gt; &lt;Ron_Parker@affirmednetworks.com&gt; wrote:</div>
<div>&gt; &gt;&gt;</div>
<div>&gt; &gt;&gt;&gt; Joel,</div>
<div>&gt; &gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt; IMO, the primary reason for understanding the subscr=
iber identity</div>
<div>&gt; at</div>
<div>&gt; &gt;&gt; a network service is to choose from a differentiated set=
 of policies.</div>
<div>&gt; &gt;&gt; I think there is utility and efficiency in driving that =
selection</div>
<div>&gt; from</div>
<div>&gt; &gt;&gt; one place -- the network services classifier.&nbsp;&nbsp=
;&nbsp;&nbsp; Say there were 2</div>
<div>&gt; &gt;&gt; groups of subscribers -- children and adults.&nbsp;&nbsp=
; Let's now define 2</div>
<div>&gt; &gt;&gt; chains, where the chains have a business-based meaning t=
o the</div>
<div>&gt; operator.</div>
<div>&gt; &gt;&gt; Chain 1 =3D HTTP-filter-child &#43; Firewall-child.&nbsp=
;&nbsp; Chain 2 =3D HTTP-</div>
<div>&gt; filter-</div>
<div>&gt; &gt;&gt; adult &#43; Firewall-adult.&nbsp;&nbsp;&nbsp; The refere=
nced network services are</div>
<div>&gt; logical</div>
<div>&gt; &gt;&gt; and it is possible, but not required, that multiple logi=
cal network</div>
<div>&gt; &gt;&gt; services be located at the same IP address or FQDN.&nbsp=
;&nbsp;&nbsp;&nbsp; Conveying</div>
<div>&gt; the</div>
<div>&gt; &gt;&gt; actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH=
 chain</div>
<div>&gt; ID, ...)</div>
<div>&gt; &gt;&gt; allows the IP-addressable server that realizes these ser=
vice(s) to</div>
<div>&gt; know</div>
<div>&gt; &gt;&gt; two things -- 1) which logical network function should b=
e invoked</div>
<div>&gt; and 2)</div>
<div>&gt; &gt;&gt; which logical network function is next.</div>
<div>&gt; &gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt; Thanks.</div>
<div>&gt; &gt;&gt;&gt; Ron</div>
<div>&gt; &gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt; -----Original Message-----</div>
<div>&gt; &gt;&gt;&gt; From: Joel M. Halpern [<a href=3D"mailto:jmh@joelhal=
pern.com">mailto:jmh@joelhalpern.com</a>]</div>
<div>&gt; &gt;&gt;&gt; Sent: Wednesday, July 24, 2013 4:47 PM</div>
<div>&gt; &gt;&gt;&gt; To: Ron Parker</div>
<div>&gt; &gt;&gt;&gt; Cc: nsc@ietf.org</div>
<div>&gt; &gt;&gt;&gt; Subject: Re: [nsc] Service chaining architecture que=
stion</div>
<div>&gt; &gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt; Ron,</div>
<div>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maybe I am missing som=
ething, but you seem to lay out very</div>
<div>&gt; nicely</div>
<div>&gt; &gt;&gt; the case for wanting both service chain identification a=
nd</div>
<div>&gt; separately</div>
<div>&gt; &gt;&gt; subscriber identification.&nbsp; Then the HTTP filter ca=
n use the</div>
<div>&gt; subscriber</div>
<div>&gt; &gt;&gt; ID to decide which exact content filtering behavior it s=
hould apply.</div>
<div>&gt; I</div>
<div>&gt; &gt;&gt; would not want to fold that level of detail into the cha=
in</div>
<div>&gt; &gt;&gt; identification.</div>
<div>&gt; &gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt; Yours,</div>
<div>&gt; &gt;&gt;&gt; Joel</div>
<div>&gt; &gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt; On 7/24/13 4:05 PM, Ron Parker wrote:</div>
<div>&gt; &gt;&gt;&gt;&gt; Dave,</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; I agree that the number of chains is unlikely to=
 scale to vast</div>
<div>&gt; &gt;&gt; numbers</div>
<div>&gt; &gt;&gt;&gt;&gt; (i.e., millions).&nbsp;&nbsp;&nbsp;&nbsp; And I =
agree that it is bounded from a</div>
<div>&gt; &gt;&gt; practical</div>
<div>&gt; &gt;&gt;&gt;&gt; business perspective, as you point out.</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; You may already be on this page, but I wanted to=
 point out a</div>
<div>&gt; &gt;&gt;&gt;&gt; distinction of coarse-grained definition of a se=
rvice function vs.</div>
<div>&gt; &gt;&gt; finer-grained</div>
<div>&gt; &gt;&gt;&gt;&gt; definition of a service function.&nbsp;&nbsp; Co=
nsider a service function to</div>
<div>&gt; &gt;&gt; be</div>
<div>&gt; &gt;&gt;&gt;&gt; logical in such a way that the identity of the l=
ogical function</div>
<div>&gt; may</div>
<div>&gt; &gt;&gt; also</div>
<div>&gt; &gt;&gt;&gt;&gt; imply some differentiated behavior.&nbsp;&nbsp; =
For example, a conceptual</div>
<div>&gt; &gt;&gt; function</div>
<div>&gt; &gt;&gt;&gt;&gt; is HTTP content filtering.&nbsp;&nbsp;&nbsp; Thi=
s conceptual function can then be</div>
<div>&gt; &gt;&gt;&gt;&gt; further instantiated at the logical level based =
on differentiated</div>
<div>&gt; &gt;&gt;&gt;&gt; policies such as content-filter-children,</div>
<div>&gt; &gt;&gt;&gt;&gt; content-filter-adults-no-porn, content-filter-ad=
ults (I'm taking</div>
<div>&gt; no</div>
<div>&gt; &gt;&gt; stand on opt-in vs. opt-out, Mr.</div>
<div>&gt; &gt;&gt;&gt;&gt; Cameron).&nbsp;&nbsp; It may be that the same ne=
twork element (dedicated</div>
<div>&gt; &gt;&gt; physical</div>
<div>&gt; &gt;&gt;&gt;&gt; box or virtual network function) realizes all 3 =
of the example</div>
<div>&gt; &gt;&gt;&gt;&gt; policies.&nbsp;&nbsp; The HTTP content filtering=
 network function is really</div>
<div>&gt; 3</div>
<div>&gt; &gt;&gt;&gt;&gt; logical network functions from the perspective o=
f inclusion in a</div>
<div>&gt; &gt;&gt; service</div>
<div>&gt; &gt;&gt;&gt;&gt; chain.&nbsp;&nbsp; Now extend this to multiple c=
onceptual functions that</div>
<div>&gt; &gt;&gt; utilize</div>
<div>&gt; &gt;&gt;&gt;&gt; differentiated policies and the number of combin=
ations will grow,</div>
<div>&gt; at</div>
<div>&gt; &gt;&gt;&gt;&gt; least modestly.</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; Thanks,</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; Ron</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *From:*nsc-bounces@ietf.org [<a href=3D"mailto:n=
sc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>] *On</div>
<div>&gt; Behalf</div>
<div>&gt; &gt;&gt;&gt;&gt; Of *David Allan I</div>
<div>&gt; &gt;&gt;&gt;&gt; *Sent:* Wednesday, July 24, 2013 3:52 PM</div>
<div>&gt; &gt;&gt;&gt;&gt; *To:* Henderickx, Wim (Wim); N.Leymann@telekom.d=
e; nsc@ietf.org</div>
<div>&gt; &gt;&gt;&gt;&gt; *Subject:* Re: [nsc] Service chaining architectu=
re question</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; Saying functions will have a problem with someth=
ing that exists as</div>
<div>&gt; a</div>
<div>&gt; &gt;&gt;&gt;&gt; potential rationale for defining something new w=
ith exactly the</div>
<div>&gt; same</div>
<div>&gt; &gt;&gt;&gt;&gt; properties and problems does not quite work for =
me....</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; VLANs on a vNIC or multiple vNICs (depending on =
the application</div>
<div>&gt; &gt;&gt; stack</div>
<div>&gt; &gt;&gt;&gt;&gt; construction and this being combined with applic=
ation</div>
<div>&gt; &quot;cooperation&quot;</div>
<div>&gt; &gt;&gt;&gt;&gt; to preserve pairwise mappings of either VID/NIC =
tuples or simply</div>
<div>&gt; &gt;&gt;&gt;&gt; NICs) currently exist as potential vehicles for =
preserving chain</div>
<div>&gt; &gt;&gt;&gt;&gt; context and avoiding per hop classification. Any=
thing else will be</div>
<div>&gt; &gt;&gt;&gt;&gt; implemented more or less the same way and have e=
xactly the same</div>
<div>&gt; set</div>
<div>&gt; &gt;&gt;&gt;&gt; of scaling and application design issues...Some =
extra information</div>
<div>&gt; &gt;&gt;&gt;&gt; available on a single interface, or achieved by =
mapping chain</div>
<div>&gt; &gt;&gt;&gt;&gt; instances onto one of a plurality of interfaces.=
...</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; But to back up... I'm not a carrier employee but=
 I cannot envision</div>
<div>&gt; a</div>
<div>&gt; &gt;&gt;&gt;&gt; carrier offering potentially 1000s of distinct s=
ervice bundles</div>
<div>&gt; &gt;&gt; (&quot;pick</div>
<div>&gt; &gt;&gt;&gt;&gt; 53 from column A and 49 from column B&quot;). So=
 I suspect a much</div>
<div>&gt; smaller</div>
<div>&gt; &gt;&gt;&gt;&gt; number is realistic for&nbsp; the number of chai=
ns a function instance</div>
<div>&gt; is</div>
<div>&gt; &gt;&gt;&gt;&gt; expected to participate in, even allowing for dy=
namic</div>
<div>&gt; &gt;&gt;&gt;&gt; reclassification of flows at a chain ingress to =
&quot;skip a few</div>
<div>&gt; &gt;&gt;&gt;&gt; functions&quot;.... These are things that are fu=
lly operationalized in</div>
<div>&gt; &gt;&gt;&gt;&gt; OSS, have policy associated with, have been indu=
strialized and</div>
<div>&gt; &gt;&gt;&gt;&gt; demonstrated to work prior to deployment. Going =
all combinatorial</div>
<div>&gt; on</div>
<div>&gt; &gt;&gt; this will break that big time....</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; So are we really discussing a function participa=
ting in more than</div>
<div>&gt; a</div>
<div>&gt; &gt;&gt;&gt;&gt; handful of chain instances? And either a plurali=
ty of vNICs or</div>
<div>&gt; VIDs</div>
<div>&gt; &gt;&gt;&gt;&gt; being actually more than sufficient?</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; Thanks</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; Dave</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *From:*nsc-bounces@ietf.org &lt;<a href=3D"mailt=
o:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; [<a href=3D"mailto:nsc-bounces@ietf.org">mailto:=
nsc-bounces@ietf.org</a>] *On Behalf Of *Henderickx, Wim (Wim)</div>
<div>&gt; &gt;&gt;&gt;&gt; *Sent:* Wednesday, July 24, 2013 9:30 AM</div>
<div>&gt; &gt;&gt;&gt;&gt; *To:* N.Leymann@telekom.de &lt;<a href=3D"mailto=
:N.Leymann@telekom.de">mailto:N.Leymann@telekom.de</a>&gt;;</div>
<div>&gt; &gt;&gt;&gt;&gt; nsc@ietf.org &lt;<a href=3D"mailto:nsc@ietf.org"=
>mailto:nsc@ietf.org</a>&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *Subject:* Re: [nsc] Service chaining architectu=
re question</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; indeed</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *From: *&quot;N.Leymann@telekom.de &lt;<a href=
=3D"mailto:N.Leymann@telekom.de">mailto:N.Leymann@telekom.de</a>&gt;&quot;<=
/div>
<div>&gt; &gt;&gt;&gt;&gt; &lt;N.Leymann@telekom.de &lt;<a href=3D"mailto:N=
.Leymann@telekom.de">mailto:N.Leymann@telekom.de</a>&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *Date: *Wednesday 24 July 2013 15:54</div>
<div>&gt; &gt;&gt;&gt;&gt; *To: *Wim Henderickx &lt;wim.henderickx@alcatel-=
lucent.com</div>
<div>&gt; &gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:wim.henderickx@alcatel-luc=
ent.com">mailto:wim.henderickx@alcatel-lucent.com</a>&gt;&gt;, &quot;nsc@ie=
tf.org</div>
<div>&gt; &gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:nsc@ietf.org">mailto:nsc@i=
etf.org</a>&gt;&quot; &lt;nsc@ietf.org &lt;<a href=3D"mailto:nsc@ietf.org">=
mailto:nsc@ietf.org</a>&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *Subject: *AW: Service chaining architecture que=
stion</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; Hi Wim,</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; I think not only effectivness/scalability might =
be a problem but</div>
<div>&gt; &gt;&gt; also</div>
<div>&gt; &gt;&gt;&gt;&gt; the fact that not all applications (service brin=
ging functions)</div>
<div>&gt; are</div>
<div>&gt; &gt;&gt;&gt;&gt; able to handle packets coming from/going to pote=
ntially thousands</div>
<div>&gt; of</div>
<div>&gt; &gt;&gt;&gt;&gt; different VLANs at the same time. VLANs will wor=
k in certain</div>
<div>&gt; &gt;&gt;&gt;&gt; environments but not in all. I see the need for =
an information</div>
<div>&gt; &gt;&gt;&gt;&gt; exchange between the application and a mediation=
 layer as well.</div>
<div>&gt; &gt;&gt;&gt;&gt; Ideally this should be as simple as possible wit=
hout heavy impact</div>
<div>&gt; on</div>
<div>&gt; &gt;&gt;&gt;&gt; the application itself (might be difficult to ac=
hieve but from my</div>
<div>&gt; &gt;&gt;&gt;&gt; experience it is not very likely, that there wil=
l be big rewrites</div>
<div>&gt; of</div>
<div>&gt; &gt;&gt;&gt;&gt; existing applications in order to support the ch=
aining).</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; regards</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Nic</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; ------------------------------------------------=
------------------</div>
<div>&gt; --</div>
<div>&gt; &gt;&gt; -</div>
<div>&gt; &gt;&gt;&gt;&gt; -</div>
<div>&gt; &gt;&gt;&gt;&gt; --</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *Von:*nsc-bounces@ietf.org &lt;<a href=3D"mailto=
:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; [<a href=3D"mailto:nsc-bounces@ietf.org">mailto:=
nsc-bounces@ietf.org</a>] *Im Auftrag von *Henderickx, Wim</div>
<div>&gt; (Wim)</div>
<div>&gt; &gt;&gt;&gt;&gt; *Gesendet:* Mittwoch, 24. Juli 2013 11:52</div>
<div>&gt; &gt;&gt;&gt;&gt; *An:* nsc@ietf.org &lt;<a href=3D"mailto:nsc@iet=
f.org">mailto:nsc@ietf.org</a>&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; *Betreff:* [nsc] Service chaining architecture q=
uestion</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; I have a basic question with respect to the arch=
itecture/framework</div>
<div>&gt; &gt;&gt; so</div>
<div>&gt; &gt;&gt;&gt;&gt; far mentioned in the drafts in NSC. I understand=
 the meta-data is</div>
<div>&gt; a</div>
<div>&gt; &gt;&gt;&gt;&gt; mechanism to avoid multiple re-classifications w=
hen the packet</div>
<div>&gt; &gt;&gt; enters</div>
<div>&gt; &gt;&gt;&gt;&gt; the NSC domain and identifies the chain of servi=
ce functions. Now</div>
<div>&gt; my</div>
<div>&gt; &gt;&gt;&gt;&gt; understanding is that the services/applications =
are unaware of the</div>
<div>&gt; &gt;&gt;&gt;&gt; meta-data and that a layer underneath should pro=
vide the mediation</div>
<div>&gt; &gt;&gt;&gt;&gt; and that we use a well defined interface to the<=
/div>
<div>&gt; application/service</div>
<div>&gt; &gt;&gt;&gt;&gt; to indicate the chain. In the context of Cloud/e=
nterprise</div>
<div>&gt; &gt;&gt; environment</div>
<div>&gt; &gt;&gt;&gt;&gt; I can see this work given you can use a dedicate=
 VLAN e.g. within</div>
<div>&gt; &gt;&gt; the tenant.</div>
<div>&gt; &gt;&gt;&gt;&gt; However we also try to address residential use c=
ases for mobile</div>
<div>&gt; and</div>
<div>&gt; &gt;&gt;&gt;&gt; fixed and here this becomes more tricky afais. I=
n the residential</div>
<div>&gt; &gt;&gt;&gt;&gt; environment we can't expose a VLAN per applicati=
on/service per</div>
<div>&gt; chain</div>
<div>&gt; &gt;&gt;&gt;&gt; since this would not be very effective. So I am =
wondering how we</div>
<div>&gt; &gt;&gt;&gt;&gt; envision this to work?</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt;</div>
<div>&gt; &gt;&gt;&gt;&gt; _______________________________________________<=
/div>
<div>&gt; &gt;&gt;&gt;&gt; nsc mailing list</div>
<div>&gt; &gt;&gt;&gt;&gt; nsc@ietf.org</div>
<div>&gt; &gt;&gt;&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo=
/nsc">https://www.ietf.org/mailman/listinfo/nsc</a></div>
<div>&gt; &gt;&gt;&gt; _______________________________________________</div=
>
<div>&gt; &gt;&gt;&gt; nsc mailing list</div>
<div>&gt; &gt;&gt;&gt; nsc@ietf.org</div>
<div>&gt; &gt;&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/nsc=
">https://www.ietf.org/mailman/listinfo/nsc</a></div>
<div>&gt; &gt;&gt; _______________________________________________</div>
<div>&gt; &gt;&gt; nsc mailing list</div>
<div>&gt; &gt;&gt; nsc@ietf.org</div>
<div>&gt; &gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/nsc">ht=
tps://www.ietf.org/mailman/listinfo/nsc</a></div>
<div>&gt; &gt;</div>
<div><font face=3D"Times New Roman">&nbsp;</font></div>
</span></font>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F645B4D37Edfweml509mbxchi_--

From Chuong.D.Pham@team.telstra.com  Wed Jul 24 16:30:52 2013
Return-Path: <Chuong.D.Pham@team.telstra.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2734721F9301 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfEUq6dXaHXT for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:30:45 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3B12021F9343 for <nsc@ietf.org>; Wed, 24 Jul 2013 16:30:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.89,737,1367935200";  d="scan'208,217";a="148094980"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 25 Jul 2013 09:30:40 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7146"; a="145977932"
Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipccvi.tcif.telstra.com.au with ESMTP; 25 Jul 2013 09:30:40 +1000
Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 25 Jul 2013 09:30:39 +1000
From: "Pham, Chuong D" <Chuong.D.Pham@team.telstra.com>
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "nsc@ietf.org" <nsc@ietf.org>
Date: Thu, 25 Jul 2013 09:30:37 +1000
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: Ac6IZwnltxTlbl5XThOqY6Xjp7tE8QAW838A
Message-ID: <5602569641FB314FB4D9AD5659D41B9C23E10899B8@WSMSG3154V.srv.dir.telstra.com>
References: <CE156BAC.6A02B%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <CE156BAC.6A02B%wim.henderickx@alcatel-lucent.com>
Accept-Language: en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-AU
Content-Type: multipart/alternative; boundary="_000_5602569641FB314FB4D9AD5659D41B9C23E10899B8WSMSG3154Vsrv_"
MIME-Version: 1.0
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:30:52 -0000

--_000_5602569641FB314FB4D9AD5659D41B9C23E10899B8WSMSG3154Vsrv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Wim,
We are also investigating service chaining in a Mobile/Fixed Broadband serv=
ice provider environment.
I understand that your question is about what information element can be us=
ed to identify an individual user i.e. a Mobile subscriber in the meta-data=
 set. If this is correct then we have the same concern.
The way I envision it works is for the per-subscriber meta-data to be obtai=
ned/created in the "control plane". One example is using Mobile/Fixed user =
identification such as MSISDN and MAC-address to identify the users in the =
meta-data. The "control plane" entity would receive identification informat=
ion via control plane messages from entities such as PCRF and AAA server. S=
uch messages also have the user's dynamically allocated IP addresses.  The =
control plane entity will push identity <User identity>-<IP address> value =
pairs to the edge node. The edge node now can use these value pairs to matc=
h with per-user policies and include the information in the meta-data.


From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Wednesday, 24 July 2013 7:52 PM
To: nsc@ietf.org
Subject: [nsc] Service chaining architecture question

I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_5602569641FB314FB4D9AD5659D41B9C23E10899B8WSMSG3154Vsrv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-AU link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Wim,<o:p>=
</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D'>We are also investigating serv=
ice chaining in a Mobile/Fixed Broadband service provider environment.<o:p>=
</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D'>I understand that your questio=
n is about what information element can be used to identify an individual u=
ser i.e. a Mobile subscriber in the meta-data set. If this is correct then =
we have the same concern.<o:p></o:p></span></p><p class=3DMsoNormal><span s=
tyle=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>=
The way I envision it works is for the per-subscriber meta-data to be obtai=
ned/created in the &#8220;control plane&#8221;. One example is using Mobile=
/Fixed user identification such as MSISDN and MAC-address to identify the u=
sers in the meta-data. The &#8220;control plane&#8221; entity would receive=
 identification information via control plane messages from entities such a=
s PCRF and AAA server. Such messages also have the user&#8217;s dynamically=
 allocated IP addresses. &nbsp;The control plane entity will push identity =
&lt;User identity&gt;-&lt;IP address&gt; value pairs to the edge node. The =
edge node now can use these value pairs to match with per-user policies and=
 include the information in the meta-data.<o:p></o:p></span></p><p class=3D=
MsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif=
";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span sty=
le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o=
:p>&nbsp;</o:p></span></p><div><div style=3D'border:none;border-top:solid #=
B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span lang=
=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:=
</span></b><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'> Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucen=
t.com] <br><b>Sent:</b> Wednesday, 24 July 2013 7:52 PM<br><b>To:</b> nsc@i=
etf.org<br><b>Subject:</b> [nsc] Service chaining architecture question<o:p=
></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><di=
v><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:"Calibri=
","sans-serif";color:black'>I have a basic question with respect to the arc=
hitecture/framework so far mentioned in the drafts in NSC. I understand the=
 meta-data is a mechanism to avoid multiple re-classifications when the pac=
ket enters the NSC domain and identifies the chain of service functions. No=
w my understanding is that the services/applications are unaware of the met=
a-data and that a layer underneath should provide the mediation and that we=
 use a well defined interface to the application/service to indicate the ch=
ain. In the context of Cloud/enterprise environment I can see this work giv=
en you can use a dedicate VLAN e.g. within the tenant. However we also try =
to address residential use cases for mobile and fixed and here this becomes=
 more tricky afais.&nbsp;In the residential environment we can't expose a V=
LAN per application/service per chain since this would not be very effectiv=
e. So I am wondering how we envision this to work?<o:p></o:p></span></p></d=
iv></div></body></html>=

--_000_5602569641FB314FB4D9AD5659D41B9C23E10899B8WSMSG3154Vsrv_--

From jmh@joelhalpern.com  Wed Jul 24 16:35:09 2013
Return-Path: <jmh@joelhalpern.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9FC21F9477 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wDbXwiXtTBg for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:35:04 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id EE1EC21F94DC for <nsc@ietf.org>; Wed, 24 Jul 2013 16:35:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CFFC01CC2DF4; Wed, 24 Jul 2013 16:35:01 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 217DE1CC2DF3; Wed, 24 Jul 2013 16:35:00 -0700 (PDT)
Message-ID: <51F064A2.3060601@joelhalpern.com>
Date: Wed, 24 Jul 2013 19:34:58 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Linda Dunbar <linda.dunbar@huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:35:09 -0000

I would not be surprised if we want all three of
Service Chain,
Service Policy, and
Subscriber / user identity
in the packet.
If the Chain is in the VLAN / MPLS label, then we can discuss whether 
the other information goes in additional ids of the same type or in a 
carried header.  I can construct arguments for either approach.

It may be easier to just carry the subscriber identity, and used the 
same management systems to assign policies to the devices that care.  I 
am concerned that it may not be practical to use a single policy 
identifier to specify which HTTP rule set to use, which Firewall rule 
set to use, and then which specific policy for other user selected 
policy applications.

Yours,
Joel

On 7/24/13 7:30 PM, Linda Dunbar wrote:
> Joel,
>> -----Original Message-----
>>
>> Yes, having the chain ingress node mark the traffic makes good sense.
>> Having it mark the subscriber identity and the chain to be traversed
>> seems quite sensible.
>>
>> The difference I think I have with Ron is that he proposes to use one
>> identifier for both entities.
> [Linda] I hope you don't mean per subscriber identity, do you? With
> today's PCRF, subscribers are categorized based on their subscription
> types. Throughout the network, the "subscription types" dictate what
> service modules their corresponding traffic need to traverse through.
> Some service modules might need to examine packets deeper (i.e. look
> into payload) for their intended functions. They may need to extract the
> "HTTP header" or HTTP messages from one or multiple packets.
> That causes, as Dave said, a
>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two MPLS
>> labels.
> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> The subscriber identity could be some bits in the payload.
>>
>> And if the existing boxes don't know how to handle that (as seems
>> likely) then we need a proxy / support function to translate the common
>> protocol into whatever they used before we got something generally
>> usable out there.
>>
>> Yours,
>> Joel
>>
>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>> >
>> > Agree with Ron that it is better to have fewer nodes in network to
>> make subscriber-aware policy decisions.
>> >
>> > Besides, it is not uncommon for multiple subscribers to share same
>> sequence of service modules. In this environment, if the network edge
>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can use
>> Layer 2 or 3 labels to mark the traffic, the subsequent network nodes
>> can steer traffic to the needed service modules without looking into
>> "Mega data" or other higher layer fields in the data frames.
>> >
>> > This approach can make "service chain" work without making changes to
>> majority of existing deployed network elements.
>> >
>> > Linda
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> Jim,
>> >>
>> >> Yes, that could work, too, conceptually.   But it does require that
>> >> each coarsely-defined network service have access to a subscriber-
>> aware
>> >> policy resolution mechanism.   IMO, it is better to have fewer
>> network
>> >> elements making subscriber-aware policy decisions.
>> >
>> >
>> >>
>> >>     Ron
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>> >> To: Ron Parker
>> >> Cc: Joel M. Halpern; nsc@ietf.org
>> >> Subject: Re: [nsc] Service chaining architecture question
>> >>
>> >> Ron,
>> >> Or alternatively carry the subscriber awareness in metadata thereby
>> >> utilizing a single chain.
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> >> <Ron_Parker@affirmednetworks.com> wrote:
>> >>
>> >>> Joel,
>> >>>
>> >>> IMO, the primary reason for understanding the subscriber identity
>> at
>> >> a network service is to choose from a differentiated set of policies.
>> >> I think there is utility and efficiency in driving that selection
>> from
>> >> one place -- the network services classifier.     Say there were 2
>> >> groups of subscribers -- children and adults.   Let's now define 2
>> >> chains, where the chains have a business-based meaning to the
>> operator.
>> >> Chain 1 = HTTP-filter-child + Firewall-child.   Chain 2 = HTTP-
>> filter-
>> >> adult + Firewall-adult.    The referenced network services are
>> logical
>> >> and it is possible, but not required, that multiple logical network
>> >> services be located at the same IP address or FQDN.     Conveying
>> the
>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>> ID, ...)
>> >> allows the IP-addressable server that realizes these service(s) to
>> know
>> >> two things -- 1) which logical network function should be invoked
>> and 2)
>> >> which logical network function is next.
>> >>>
>> >>> Thanks.
>> >>> Ron
>> >>>
>> >>> -----Original Message-----
>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>> >>> To: Ron Parker
>> >>> Cc: nsc@ietf.org
>> >>> Subject: Re: [nsc] Service chaining architecture question
>> >>>
>> >>> Ron,
>> >>>      maybe I am missing something, but you seem to lay out very
>> nicely
>> >> the case for wanting both service chain identification and
>> separately
>> >> subscriber identification.  Then the HTTP filter can use the
>> subscriber
>> >> ID to decide which exact content filtering behavior it should apply.
>> I
>> >> would not want to fold that level of detail into the chain
>> >> identification.
>> >>>
>> >>> Yours,
>> >>> Joel
>> >>>
>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>> >>>> Dave,
>> >>>>
>> >>>> I agree that the number of chains is unlikely to scale to vast
>> >> numbers
>> >>>> (i.e., millions).     And I agree that it is bounded from a
>> >> practical
>> >>>> business perspective, as you point out.
>> >>>>
>> >>>> You may already be on this page, but I wanted to point out a
>> >>>> distinction of coarse-grained definition of a service function vs.
>> >> finer-grained
>> >>>> definition of a service function.   Consider a service function to
>> >> be
>> >>>> logical in such a way that the identity of the logical function
>> may
>> >> also
>> >>>> imply some differentiated behavior.   For example, a conceptual
>> >> function
>> >>>> is HTTP content filtering.    This conceptual function can then be
>> >>>> further instantiated at the logical level based on differentiated
>> >>>> policies such as content-filter-children,
>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
>> no
>> >> stand on opt-in vs. opt-out, Mr.
>> >>>> Cameron).   It may be that the same network element (dedicated
>> >> physical
>> >>>> box or virtual network function) realizes all 3 of the example
>> >>>> policies.   The HTTP content filtering network function is really
>> 3
>> >>>> logical network functions from the perspective of inclusion in a
>> >> service
>> >>>> chain.   Now extend this to multiple conceptual functions that
>> >> utilize
>> >>>> differentiated policies and the number of combinations will grow,
>> at
>> >>>> least modestly.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Ron
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>> Behalf
>> >>>> Of *David Allan I
>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> Saying functions will have a problem with something that exists as
>> a
>> >>>> potential rationale for defining something new with exactly the
>> same
>> >>>> properties and problems does not quite work for me....
>> >>>>
>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>> >> stack
>> >>>> construction and this being combined with application
>> "cooperation"
>> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>> >>>> NICs) currently exist as potential vehicles for preserving chain
>> >>>> context and avoiding per hop classification. Anything else will be
>> >>>> implemented more or less the same way and have exactly the same
>> set
>> >>>> of scaling and application design issues...Some extra information
>> >>>> available on a single interface, or achieved by mapping chain
>> >>>> instances onto one of a plurality of interfaces....
>> >>>>
>> >>>> But to back up... I'm not a carrier employee but I cannot envision
>> a
>> >>>> carrier offering potentially 1000s of distinct service bundles
>> >> ("pick
>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>> smaller
>> >>>> number is realistic for  the number of chains a function instance
>> is
>> >>>> expected to participate in, even allowing for dynamic
>> >>>> reclassification of flows at a chain ingress to "skip a few
>> >>>> functions".... These are things that are fully operationalized in
>> >>>> OSS, have policy associated with, have been industrialized and
>> >>>> demonstrated to work prior to deployment. Going all combinatorial
>> on
>> >> this will break that big time....
>> >>>>
>> >>>> So are we really discussing a function participating in more than
>> a
>> >>>> handful of chain instances? And either a plurality of vNICs or
>> VIDs
>> >>>> being actually more than sufficient?
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> Dave
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> indeed
>> >>>>
>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >>>> *Date: *Wednesday 24 July 2013 15:54
>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >>>> *Subject: *AW: Service chaining architecture question
>> >>>>
>> >>>> Hi Wim,
>> >>>>
>> >>>> I think not only effectivness/scalability might be a problem but
>> >> also
>> >>>> the fact that not all applications (service bringing functions)
>> are
>> >>>> able to handle packets coming from/going to potentially thousands
>> of
>> >>>> different VLANs at the same time. VLANs will work in certain
>> >>>> environments but not in all. I see the need for an information
>> >>>> exchange between the application and a mediation layer as well.
>> >>>> Ideally this should be as simple as possible without heavy impact
>> on
>> >>>> the application itself (might be difficult to achieve but from my
>> >>>> experience it is not very likely, that there will be big rewrites
>> of
>> >>>> existing applications in order to support the chaining).
>> >>>>
>> >>>>    regards
>> >>>>
>> >>>>       Nic
>> >>>>
>> >>>> ------------------------------------------------------------------
>> --
>> >> -
>> >>>> -
>> >>>> --
>> >>>>
>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>> (Wim)
>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Betreff:* [nsc] Service chaining architecture question
>> >>>>
>> >>>> I have a basic question with respect to the architecture/framework
>> >> so
>> >>>> far mentioned in the drafts in NSC. I understand the meta-data is
>> a
>> >>>> mechanism to avoid multiple re-classifications when the packet
>> >> enters
>> >>>> the NSC domain and identifies the chain of service functions. Now
>> my
>> >>>> understanding is that the services/applications are unaware of the
>> >>>> meta-data and that a layer underneath should provide the mediation
>> >>>> and that we use a well defined interface to the
>> application/service
>> >>>> to indicate the chain. In the context of Cloud/enterprise
>> >> environment
>> >>>> I can see this work given you can use a dedicate VLAN e.g. within
>> >> the tenant.
>> >>>> However we also try to address residential use cases for mobile
>> and
>> >>>> fixed and here this becomes more tricky afais. In the residential
>> >>>> environment we can't expose a VLAN per application/service per
>> chain
>> >>>> since this would not be very effective. So I am wondering how we
>> >>>> envision this to work?
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> nsc mailing list
>> >>>> nsc@ietf.org
>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>> >>> _______________________________________________
>> >>> nsc mailing list
>> >>> nsc@ietf.org
>> >>>https://www.ietf.org/mailman/listinfo/nsc
>> >> _______________________________________________
>> >> nsc mailing list
>> >> nsc@ietf.org
>> >>https://www.ietf.org/mailman/listinfo/nsc
>> >
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>

From linda.dunbar@huawei.com  Wed Jul 24 16:42:57 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2368A21F9958 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcpdaFPqDPuf for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:42:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E144121F9946 for <nsc@ietf.org>; Wed, 24 Jul 2013 16:42:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATT45384; Wed, 24 Jul 2013 23:42:50 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 00:40:52 +0100
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 00:41:49 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 16:41:43 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAQSZgAAA6LpRA=
Date: Wed, 24 Jul 2013 23:41:42 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4D3A1@dfweml509-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <68B171751455884590F8E38E96416F363F5C47F0@xmb-rcd-x01.cisco.com>
In-Reply-To: <68B171751455884590F8E38E96416F363F5C47F0@xmb-rcd-x01.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.128.98]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:42:57 -0000

Jim,=20

Do you mean that some service modules need information inserted by the upst=
ream service modules to make the needed actions?=20

That is fine. Then those "mega data" inserted by the service modules are re=
ally internal among the service modules.=20

Layer 4-7 services have been discussed in ONF for quite some time. We have =
decided to describe service modules in two categories: Proxy based and pack=
et based.=20

*	Proxy based service functions: these service functions terminate original=
 packets, may reassemble multiple packets, reopen a new connection, or form=
ulate new packets based on the received packets.

*	Packet based service functions: these service modules maintain original p=
ackets, i.e. they don't make changes to packets traversed through except po=
ssibly changing some header fields.

Linda


> -----Original Message-----
> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> Sent: Wednesday, July 24, 2013 6:30 PM
> To: Linda Dunbar; Ron Parker
> Cc: nsc@ietf.org; Joel M. Halpern
> Subject: Re: [nsc] Service chaining architecture question
>=20
> Hi Linda,
>=20
> The service chaining "problem" is not just about data plane and getting
> packets from point A to point B. That's the easy bit. True, some basic
> services may be just fine with this approach but the wider issue is how
> to
> share "intelligence" between the network and services, and between
> services. A simple label allocation may not satisfy such requirements.
> Mapping 1:1 chain-id<->policy seems the wrong direction to take imho.
>=20
> On 7/24/13 6:53 PM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:
>=20
> >
> >Agree with Ron that it is better to have fewer nodes in network to
> make
> >subscriber-aware policy decisions.
> >
> >Besides, it is not uncommon for multiple subscribers to share same
> >sequence of service modules. In this environment, if the network edge
> >nodes, such as Broadband Network Gateway or Cell Site Gateway, can use
> >Layer 2 or 3 labels to mark the traffic, the subsequent network nodes
> can
> >steer traffic to the needed service modules without looking into "Mega
> >data" or other higher layer fields in the data frames.
> >
> >This approach can make "service chain" work without making changes to
> >majority of existing deployed network elements.
> >
> >Linda
> >
> >
> >
> >> -----Original Message-----
> >> Jim,
> >>
> >> Yes, that could work, too, conceptually.   But it does require that
> >> each coarsely-defined network service have access to a subscriber-
> aware
> >> policy resolution mechanism.   IMO, it is better to have fewer
> network
> >> elements making subscriber-aware policy decisions.
> >
> >
> >>
> >>    Ron
> >>
> >>
> >> -----Original Message-----
> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >> To: Ron Parker
> >> Cc: Joel M. Halpern; nsc@ietf.org
> >> Subject: Re: [nsc] Service chaining architecture question
> >>
> >> Ron,
> >> Or alternatively carry the subscriber awareness in metadata thereby
> >> utilizing a single chain.
> >>
> >> Sent from my iPhone
> >>
> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >> <Ron_Parker@affirmednetworks.com> wrote:
> >>
> >> > Joel,
> >> >
> >> > IMO, the primary reason for understanding the subscriber identity
> at
> >> a network service is to choose from a differentiated set of policies.
> >> I think there is utility and efficiency in driving that selection
> from
> >> one place -- the network services classifier.     Say there were 2
> >> groups of subscribers -- children and adults.   Let's now define 2
> >> chains, where the chains have a business-based meaning to the
> operator.
> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
> filter-
> >> adult + Firewall-adult.    The referenced network services are
> logical
> >> and it is possible, but not required, that multiple logical network
> >> services be located at the same IP address or FQDN.     Conveying
> the
> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> ID, ...)
> >> allows the IP-addressable server that realizes these service(s) to
> know
> >> two things -- 1) which logical network function should be invoked
> and 2)
> >> which logical network function is next.
> >> >
> >> > Thanks.
> >> > Ron
> >> >
> >> > -----Original Message-----
> >> > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> > Sent: Wednesday, July 24, 2013 4:47 PM
> >> > To: Ron Parker
> >> > Cc: nsc@ietf.org
> >> > Subject: Re: [nsc] Service chaining architecture question
> >> >
> >> > Ron,
> >> >     maybe I am missing something, but you seem to lay out very
> nicely
> >> the case for wanting both service chain identification and
> separately
> >> subscriber identification.  Then the HTTP filter can use the
> subscriber
> >> ID to decide which exact content filtering behavior it should apply.
> I
> >> would not want to fold that level of detail into the chain
> >> identification.
> >> >
> >> > Yours,
> >> > Joel
> >> >
> >> > On 7/24/13 4:05 PM, Ron Parker wrote:
> >> >> Dave,
> >> >>
> >> >> I agree that the number of chains is unlikely to scale to vast
> >> numbers
> >> >> (i.e., millions).     And I agree that it is bounded from a
> >> practical
> >> >> business perspective, as you point out.
> >> >>
> >> >> You may already be on this page, but I wanted to point out a
> >> >> distinction of coarse-grained definition of a service function vs.
> >> finer-grained
> >> >> definition of a service function.   Consider a service function
> to
> >> be
> >> >> logical in such a way that the identity of the logical function
> may
> >> also
> >> >> imply some differentiated behavior.   For example, a conceptual
> >> function
> >> >> is HTTP content filtering.    This conceptual function can then
> be
> >> >> further instantiated at the logical level based on differentiated
> >> >> policies such as content-filter-children,
> >> >> content-filter-adults-no-porn, content-filter-adults (I'm taking
> no
> >> stand on opt-in vs. opt-out, Mr.
> >> >> Cameron).   It may be that the same network element (dedicated
> >> physical
> >> >> box or virtual network function) realizes all 3 of the example
> >> >> policies.   The HTTP content filtering network function is really
> 3
> >> >> logical network functions from the perspective of inclusion in a
> >> service
> >> >> chain.   Now extend this to multiple conceptual functions that
> >> utilize
> >> >> differentiated policies and the number of combinations will grow,
> at
> >> >> least modestly.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Ron
> >> >>
> >> >> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
> Behalf
> >> >> Of *David Allan I
> >> >> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >> >> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> >> >> *Subject:* Re: [nsc] Service chaining architecture question
> >> >>
> >> >> Saying functions will have a problem with something that exists
> as a
> >> >> potential rationale for defining something new with exactly the
> same
> >> >> properties and problems does not quite work for me....
> >> >>
> >> >> VLANs on a vNIC or multiple vNICs (depending on the application
> >> stack
> >> >> construction and this being combined with application
> "cooperation"
> >> >> to preserve pairwise mappings of either VID/NIC tuples or simply
> >> >> NICs) currently exist as potential vehicles for preserving chain
> >> >> context and avoiding per hop classification. Anything else will
> be
> >> >> implemented more or less the same way and have exactly the same
> set
> >> >> of scaling and application design issues...Some extra information
> >> >> available on a single interface, or achieved by mapping chain
> >> >> instances onto one of a plurality of interfaces....
> >> >>
> >> >> But to back up... I'm not a carrier employee but I cannot
> envision a
> >> >> carrier offering potentially 1000s of distinct service bundles
> >> ("pick
> >> >> 53 from column A and 49 from column B"). So I suspect a much
> smaller
> >> >> number is realistic for  the number of chains a function instance
> is
> >> >> expected to participate in, even allowing for dynamic
> >> >> reclassification of flows at a chain ingress to "skip a few
> >> >> functions".... These are things that are fully operationalized in
> >> >> OSS, have policy associated with, have been industrialized and
> >> >> demonstrated to work prior to deployment. Going all combinatorial
> on
> >> this will break that big time....
> >> >>
> >> >> So are we really discussing a function participating in more than
> a
> >> >> handful of chain instances? And either a plurality of vNICs or
> VIDs
> >> >> being actually more than sufficient?
> >> >>
> >> >> Thanks
> >> >>
> >> >> Dave
> >> >>
> >> >> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> >> >> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >> >> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >> >> nsc@ietf.org <mailto:nsc@ietf.org>
> >> >> *Subject:* Re: [nsc] Service chaining architecture question
> >> >>
> >> >> indeed
> >> >>
> >> >> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >> >> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >> >> *Date: *Wednesday 24 July 2013 15:54
> >> >> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >> >> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >> >> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >> >> *Subject: *AW: Service chaining architecture question
> >> >>
> >> >> Hi Wim,
> >> >>
> >> >> I think not only effectivness/scalability might be a problem but
> >> also
> >> >> the fact that not all applications (service bringing functions)
> are
> >> >> able to handle packets coming from/going to potentially thousands
> of
> >> >> different VLANs at the same time. VLANs will work in certain
> >> >> environments but not in all. I see the need for an information
> >> >> exchange between the application and a mediation layer as well.
> >> >> Ideally this should be as simple as possible without heavy impact
> on
> >> >> the application itself (might be difficult to achieve but from my
> >> >> experience it is not very likely, that there will be big rewrites
> of
> >> >> existing applications in order to support the chaining).
> >> >>
> >> >>   regards
> >> >>
> >> >>      Nic
> >> >>
> >> >> -----------------------------------------------------------------
> ---
> >> -
> >> >> -
> >> >> --
> >> >>
> >> >> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
> (Wim)
> >> >> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >> >> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >> >> *Betreff:* [nsc] Service chaining architecture question
> >> >>
> >> >> I have a basic question with respect to the
> architecture/framework
> >> so
> >> >> far mentioned in the drafts in NSC. I understand the meta-data is
> a
> >> >> mechanism to avoid multiple re-classifications when the packet
> >> enters
> >> >> the NSC domain and identifies the chain of service functions. Now
> my
> >> >> understanding is that the services/applications are unaware of
> the
> >> >> meta-data and that a layer underneath should provide the
> mediation
> >> >> and that we use a well defined interface to the
> application/service
> >> >> to indicate the chain. In the context of Cloud/enterprise
> >> environment
> >> >> I can see this work given you can use a dedicate VLAN e.g. within
> >> the tenant.
> >> >> However we also try to address residential use cases for mobile
> and
> >> >> fixed and here this becomes more tricky afais. In the residential
> >> >> environment we can't expose a VLAN per application/service per
> chain
> >> >> since this would not be very effective. So I am wondering how we
> >> >> envision this to work?
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> nsc mailing list
> >> >> nsc@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/nsc
> >> > _______________________________________________
> >> > nsc mailing list
> >> > nsc@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/nsc
> >> _______________________________________________
> >> nsc mailing list
> >> nsc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nsc
> >_______________________________________________
> >nsc mailing list
> >nsc@ietf.org
> >https://www.ietf.org/mailman/listinfo/nsc


From david.i.allan@ericsson.com  Wed Jul 24 16:44:08 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271F421F995B for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpclxA693nTZ for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:44:02 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6237F21F995A for <nsc@ietf.org>; Wed, 24 Jul 2013 16:44:02 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-dd-51f066c0fa34
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DD.77.13034.0C660F15; Thu, 25 Jul 2013 01:44:00 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 19:44:00 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAASuGAgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAP//vWyA
Date: Wed, 24 Jul 2013 23:43:59 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D6918@eusaamb105.ericsson.se>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com>
In-Reply-To: <51F064A2.3060601@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPlO6BtA+BBrveaFssnadu8fHUGyaL uy0TmSyO79vPZnHh6VRmB1aPF1eeMXtM+b2R1aPlyFtWjyVLfjJ5nJvynTGANYrLJiU1J7Ms tUjfLoEr486cvSwFn4sqPv02a2BsjO1i5OSQEDCReDpzPjOELSZx4d56ti5GLg4hgaOMEv9X TmSBcJYzSuyfeokdpIpNwEBiz/8vjCC2iECoRP+HZrAiZoFGRonlmxaBjRIWsJQ43vyaHaLI SuLspm5GkCIRgSZGie2H28GKWARUJd7+/M4CYvMK+Epcn/KBCWJdM5vEhzVXwVZwCuhLTFrV AlbECHTg91NrmEBsZgFxiVtP5jNBHC4gsWTPeagnRCVePv7HCmErSyx5sp8Fol5HYsHuT2wQ trbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDYxAqPsmASb 7g7GPS8tDzFKc7AoifOu0jsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExZHa23w6nM8+E VSpXaT5m8i3gtyrp2yV9q2DPSdPQTf/PKmfIVtj/T1v6vk21T/fum4Xfv7HNL3reNM35lQRL bOvit6U/MgQ2dMnZf9u6uEbKWHeCQf3t6OAHF8J2/hfpfrz6yLNGwQ2JU2w+RqX1iE5bWPwq dr+tqfSzPWlsEx4f2ayzukRGiaU4I9FQi7moOBEAtJiL44ACAAA=
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:44:08 -0000

My suspicion is that source IP address would stunt double for subscriber ID=
 for the forseeable future, and NAT in the home means effective maintenance=
 of subclassing the subscriber (for example associating children with speci=
fic devices behind the NAT) is an intractable problem at the classifier unl=
ess it becomes a full ALG/service portal in its own right, and duplicating =
functionality best deployed in the VF....

Cheers
Dave

-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Joel =
M. Halpern
Sent: Wednesday, July 24, 2013 4:35 PM
To: Linda Dunbar
Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
Subject: Re: [nsc] Service chaining architecture question

I would not be surprised if we want all three of Service Chain, Service Pol=
icy, and Subscriber / user identity in the packet.
If the Chain is in the VLAN / MPLS label, then we can discuss whether the o=
ther information goes in additional ids of the same type or in a carried he=
ader.  I can construct arguments for either approach.

It may be easier to just carry the subscriber identity, and used the same m=
anagement systems to assign policies to the devices that care.  I am concer=
ned that it may not be practical to use a single policy identifier to speci=
fy which HTTP rule set to use, which Firewall rule set to use, and then whi=
ch specific policy for other user selected policy applications.

Yours,
Joel

On 7/24/13 7:30 PM, Linda Dunbar wrote:
> Joel,
>> -----Original Message-----
>>
>> Yes, having the chain ingress node mark the traffic makes good sense.
>> Having it mark the subscriber identity and the chain to be traversed=20
>> seems quite sensible.
>>
>> The difference I think I have with Ron is that he proposes to use one=20
>> identifier for both entities.
> [Linda] I hope you don't mean per subscriber identity, do you? With=20
> today's PCRF, subscribers are categorized based on their subscription=20
> types. Throughout the network, the "subscription types" dictate what=20
> service modules their corresponding traffic need to traverse through.
> Some service modules might need to examine packets deeper (i.e. look=20
> into payload) for their intended functions. They may need to extract=20
> the "HTTP header" or HTTP messages from one or multiple packets.
> That causes, as Dave said, a
>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two=20
>> MPLS labels.
> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> The subscriber identity could be some bits in the payload.
>>
>> And if the existing boxes don't know how to handle that (as seems
>> likely) then we need a proxy / support function to translate the=20
>> common protocol into whatever they used before we got something=20
>> generally usable out there.
>>
>> Yours,
>> Joel
>>
>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>> >
>> > Agree with Ron that it is better to have fewer nodes in network to
>> make subscriber-aware policy decisions.
>> >
>> > Besides, it is not uncommon for multiple subscribers to share same
>> sequence of service modules. In this environment, if the network edge=20
>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can=20
>> use Layer 2 or 3 labels to mark the traffic, the subsequent network=20
>> nodes can steer traffic to the needed service modules without looking=20
>> into "Mega data" or other higher layer fields in the data frames.
>> >
>> > This approach can make "service chain" work without making changes=20
>> > to
>> majority of existing deployed network elements.
>> >
>> > Linda
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> Jim,
>> >>
>> >> Yes, that could work, too, conceptually.   But it does require that
>> >> each coarsely-defined network service have access to a subscriber-
>> aware
>> >> policy resolution mechanism.   IMO, it is better to have fewer
>> network
>> >> elements making subscriber-aware policy decisions.
>> >
>> >
>> >>
>> >>     Ron
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>> >> To: Ron Parker
>> >> Cc: Joel M. Halpern; nsc@ietf.org
>> >> Subject: Re: [nsc] Service chaining architecture question
>> >>
>> >> Ron,
>> >> Or alternatively carry the subscriber awareness in metadata=20
>> >> thereby utilizing a single chain.
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> >> <Ron_Parker@affirmednetworks.com> wrote:
>> >>
>> >>> Joel,
>> >>>
>> >>> IMO, the primary reason for understanding the subscriber identity
>> at
>> >> a network service is to choose from a differentiated set of policies.
>> >> I think there is utility and efficiency in driving that selection
>> from
>> >> one place -- the network services classifier.     Say there were 2
>> >> groups of subscribers -- children and adults.   Let's now define 2
>> >> chains, where the chains have a business-based meaning to the
>> operator.
>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>> filter-
>> >> adult + Firewall-adult.    The referenced network services are
>> logical
>> >> and it is possible, but not required, that multiple logical network
>> >> services be located at the same IP address or FQDN.     Conveying
>> the
>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>> ID, ...)
>> >> allows the IP-addressable server that realizes these service(s) to
>> know
>> >> two things -- 1) which logical network function should be invoked
>> and 2)
>> >> which logical network function is next.
>> >>>
>> >>> Thanks.
>> >>> Ron
>> >>>
>> >>> -----Original Message-----
>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>> >>> To: Ron Parker
>> >>> Cc: nsc@ietf.org
>> >>> Subject: Re: [nsc] Service chaining architecture question
>> >>>
>> >>> Ron,
>> >>>      maybe I am missing something, but you seem to lay out very
>> nicely
>> >> the case for wanting both service chain identification and
>> separately
>> >> subscriber identification.  Then the HTTP filter can use the
>> subscriber
>> >> ID to decide which exact content filtering behavior it should apply.
>> I
>> >> would not want to fold that level of detail into the chain=20
>> >> identification.
>> >>>
>> >>> Yours,
>> >>> Joel
>> >>>
>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>> >>>> Dave,
>> >>>>
>> >>>> I agree that the number of chains is unlikely to scale to vast
>> >> numbers
>> >>>> (i.e., millions).     And I agree that it is bounded from a
>> >> practical
>> >>>> business perspective, as you point out.
>> >>>>
>> >>>> You may already be on this page, but I wanted to point out a=20
>> >>>> distinction of coarse-grained definition of a service function vs.
>> >> finer-grained
>> >>>> definition of a service function.   Consider a service function to
>> >> be
>> >>>> logical in such a way that the identity of the logical function
>> may
>> >> also
>> >>>> imply some differentiated behavior.   For example, a conceptual
>> >> function
>> >>>> is HTTP content filtering.    This conceptual function can then be
>> >>>> further instantiated at the logical level based on=20
>> >>>> differentiated policies such as content-filter-children,=20
>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
>> no
>> >> stand on opt-in vs. opt-out, Mr.
>> >>>> Cameron).   It may be that the same network element (dedicated
>> >> physical
>> >>>> box or virtual network function) realizes all 3 of the example
>> >>>> policies.   The HTTP content filtering network function is really
>> 3
>> >>>> logical network functions from the perspective of inclusion in a
>> >> service
>> >>>> chain.   Now extend this to multiple conceptual functions that
>> >> utilize
>> >>>> differentiated policies and the number of combinations will=20
>> >>>> grow,
>> at
>> >>>> least modestly.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Ron
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>> Behalf
>> >>>> Of *David Allan I
>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> Saying functions will have a problem with something that exists=20
>> >>>> as
>> a
>> >>>> potential rationale for defining something new with exactly the
>> same
>> >>>> properties and problems does not quite work for me....
>> >>>>
>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>> >> stack
>> >>>> construction and this being combined with application
>> "cooperation"
>> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>> >>>> NICs) currently exist as potential vehicles for preserving chain=20
>> >>>> context and avoiding per hop classification. Anything else will=20
>> >>>> be implemented more or less the same way and have exactly the=20
>> >>>> same
>> set
>> >>>> of scaling and application design issues...Some extra=20
>> >>>> information available on a single interface, or achieved by=20
>> >>>> mapping chain instances onto one of a plurality of interfaces....
>> >>>>
>> >>>> But to back up... I'm not a carrier employee but I cannot=20
>> >>>> envision
>> a
>> >>>> carrier offering potentially 1000s of distinct service bundles
>> >> ("pick
>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>> smaller
>> >>>> number is realistic for  the number of chains a function=20
>> >>>> instance
>> is
>> >>>> expected to participate in, even allowing for dynamic=20
>> >>>> reclassification of flows at a chain ingress to "skip a few=20
>> >>>> functions".... These are things that are fully operationalized=20
>> >>>> in OSS, have policy associated with, have been industrialized=20
>> >>>> and demonstrated to work prior to deployment. Going all=20
>> >>>> combinatorial
>> on
>> >> this will break that big time....
>> >>>>
>> >>>> So are we really discussing a function participating in more=20
>> >>>> than
>> a
>> >>>> handful of chain instances? And either a plurality of vNICs or
>> VIDs
>> >>>> being actually more than sufficient?
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> Dave
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim=20
>> >>>> (Wim)
>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> indeed
>> >>>>
>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >>>> *Date: *Wednesday 24 July 2013 15:54
>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >>>> *Subject: *AW: Service chaining architecture question
>> >>>>
>> >>>> Hi Wim,
>> >>>>
>> >>>> I think not only effectivness/scalability might be a problem but
>> >> also
>> >>>> the fact that not all applications (service bringing functions)
>> are
>> >>>> able to handle packets coming from/going to potentially=20
>> >>>> thousands
>> of
>> >>>> different VLANs at the same time. VLANs will work in certain=20
>> >>>> environments but not in all. I see the need for an information=20
>> >>>> exchange between the application and a mediation layer as well.
>> >>>> Ideally this should be as simple as possible without heavy=20
>> >>>> impact
>> on
>> >>>> the application itself (might be difficult to achieve but from=20
>> >>>> my experience it is not very likely, that there will be big=20
>> >>>> rewrites
>> of
>> >>>> existing applications in order to support the chaining).
>> >>>>
>> >>>>    regards
>> >>>>
>> >>>>       Nic
>> >>>>
>> >>>> ----------------------------------------------------------------
>> >>>> --
>> --
>> >> -
>> >>>> -
>> >>>> --
>> >>>>
>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>> (Wim)
>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Betreff:* [nsc] Service chaining architecture question
>> >>>>
>> >>>> I have a basic question with respect to the=20
>> >>>> architecture/framework
>> >> so
>> >>>> far mentioned in the drafts in NSC. I understand the meta-data=20
>> >>>> is
>> a
>> >>>> mechanism to avoid multiple re-classifications when the packet
>> >> enters
>> >>>> the NSC domain and identifies the chain of service functions.=20
>> >>>> Now
>> my
>> >>>> understanding is that the services/applications are unaware of=20
>> >>>> the meta-data and that a layer underneath should provide the=20
>> >>>> mediation and that we use a well defined interface to the
>> application/service
>> >>>> to indicate the chain. In the context of Cloud/enterprise
>> >> environment
>> >>>> I can see this work given you can use a dedicate VLAN e.g.=20
>> >>>> within
>> >> the tenant.
>> >>>> However we also try to address residential use cases for mobile
>> and
>> >>>> fixed and here this becomes more tricky afais. In the=20
>> >>>> residential environment we can't expose a VLAN per=20
>> >>>> application/service per
>> chain
>> >>>> since this would not be very effective. So I am wondering how we=20
>> >>>> envision this to work?
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> nsc mailing list
>> >>>> nsc@ietf.org
>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>> >>> _______________________________________________
>> >>> nsc mailing list
>> >>> nsc@ietf.org
>> >>>https://www.ietf.org/mailman/listinfo/nsc
>> >> _______________________________________________
>> >> nsc mailing list
>> >> nsc@ietf.org
>> >>https://www.ietf.org/mailman/listinfo/nsc
>> >
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

From mn1921@att.com  Wed Jul 24 16:47:51 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4621F995E for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV1hQB5QEtVW for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:47:45 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id ADDD221F9958 for <nsc@ietf.org>; Wed, 24 Jul 2013 16:47:44 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 0a760f15.2aaade21c940.1273550.00-516.3515503.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Wed, 24 Jul 2013 23:47:44 +0000 (UTC)
X-MXL-Hash: 51f067a01b6b67cf-ed2746f89d28df6593ba7b878c28483d958abe1e
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b9760f15.0.1273477.00-143.3515386.nbfkord-smmo07.seg.att.com (envelope-from <mn1921@att.com>);  Wed, 24 Jul 2013 23:47:43 +0000 (UTC)
X-MXL-Hash: 51f0679f3dfff91e-a0572158c70b9afac5e8d308fc8b3ba5b5976dbd
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ONlcZo001912; Wed, 24 Jul 2013 19:47:39 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6ONlXdq001831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 19:47:33 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 24 Jul 2013 23:47:17 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Wed, 24 Jul 2013 19:47:17 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeAgAALhACAABT2gIAABD2AgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAP//vmwQ
Date: Wed, 24 Jul 2013 23:47:16 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01207D79@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com>
In-Reply-To: <51F064A2.3060601@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.77.163]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=Mq3IGAk562kA:10 a=2DTnKp0c6ewA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=QNNNeoGkA4wA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=qN95wPeSAAAA:8 a=ABeY7kuGAAAA:8 a=gxZvrgisAAAA:8 a=2o1F]
X-AnalysisOut: [lb5fptiHbaXVSeIA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=l]
X-AnalysisOut: [ZB815dzVvQA:10 a=paC5pjApGzsA:10 a=chC_agHSu74A:10 a=p3EP0]
X-AnalysisOut: [m9KMXkA:10 a=3FZX-ydVlcEA:10 a=WJLjwcJVPdJOmral:21 a=6pdsV]
X-AnalysisOut: [ELhpI-0-Gje:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:47:51 -0000

I would add the following:

> I would not be surprised if we want all three of
> Service Chain,
> Service Policy, and
> Subscriber / user identity
> in the packet.

> If the Chain is in the VLAN / MPLS label,=20

Yes. We should separate signaling of network connectivity from metadata ass=
ociated with the payload. These are two separate problems. In a data center=
, some VMs will be participating in service chains, some not, at a given ti=
me. We don't want to end up with two different forwarding paradigms for bot=
h types of those VMs.

> then we can discuss whether the other information goes in additional ids =
of the same type or in a
> carried header.  I can construct arguments for either approach.

We should avoid introducing a new header for carrying metadata (such as sub=
scriber-id). The same result can be achieved by using the IP header of the =
payload packet (such as IP option or flow label).=20

> It may be easier to just carry the subscriber identity, and used the
> same management systems to assign policies to the devices that care.  I
> am concerned that it may not be practical to use a single policy
> identifier to specify which HTTP rule set to use, which Firewall rule
> set to use, and then which specific policy for other user selected
> policy applications.

Agree. Or use a *local* (to a given appliance) logical interface per servic=
e "profile" but. Typically though, a "service" would be realized by softwar=
e and the goal would be to run it on a VM of a virtualized x86 server. It i=
s cheap to spin a VM. So, instead of having different profiles in the same =
VM it will be much simpler to manage a larger number of VMs, each with limi=
ted bandwidth.
=20
Maria

>=20
> On 7/24/13 7:30 PM, Linda Dunbar wrote:
> > Joel,
> >> -----Original Message-----
> >>
> >> Yes, having the chain ingress node mark the traffic makes good
> sense.
> >> Having it mark the subscriber identity and the chain to be traversed
> >> seems quite sensible.
> >>
> >> The difference I think I have with Ron is that he proposes to use
> one
> >> identifier for both entities.
> > [Linda] I hope you don't mean per subscriber identity, do you? With
> > today's PCRF, subscribers are categorized based on their subscription
> > types. Throughout the network, the "subscription types" dictate what
> > service modules their corresponding traffic need to traverse through.
> > Some service modules might need to examine packets deeper (i.e. look
> > into payload) for their intended functions. They may need to extract
> the
> > "HTTP header" or HTTP messages from one or multiple packets.
> > That causes, as Dave said, a
> >> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
> MPLS
> >> labels.
> > [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> > The subscriber identity could be some bits in the payload.
> >>
> >> And if the existing boxes don't know how to handle that (as seems
> >> likely) then we need a proxy / support function to translate the
> common
> >> protocol into whatever they used before we got something generally
> >> usable out there.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >> >
> >> > Agree with Ron that it is better to have fewer nodes in network to
> >> make subscriber-aware policy decisions.
> >> >
> >> > Besides, it is not uncommon for multiple subscribers to share same
> >> sequence of service modules. In this environment, if the network
> edge
> >> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
> use
> >> Layer 2 or 3 labels to mark the traffic, the subsequent network
> nodes
> >> can steer traffic to the needed service modules without looking into
> >> "Mega data" or other higher layer fields in the data frames.
> >> >
> >> > This approach can make "service chain" work without making changes
> to
> >> majority of existing deployed network elements.
> >> >
> >> > Linda
> >> >
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> Jim,
> >> >>
> >> >> Yes, that could work, too, conceptually.   But it does require
> that
> >> >> each coarsely-defined network service have access to a
> subscriber-
> >> aware
> >> >> policy resolution mechanism.   IMO, it is better to have fewer
> >> network
> >> >> elements making subscriber-aware policy decisions.
> >> >
> >> >
> >> >>
> >> >>     Ron
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >> >> To: Ron Parker
> >> >> Cc: Joel M. Halpern; nsc@ietf.org
> >> >> Subject: Re: [nsc] Service chaining architecture question
> >> >>
> >> >> Ron,
> >> >> Or alternatively carry the subscriber awareness in metadata
> thereby
> >> >> utilizing a single chain.
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >> >> <Ron_Parker@affirmednetworks.com> wrote:
> >> >>
> >> >>> Joel,
> >> >>>
> >> >>> IMO, the primary reason for understanding the subscriber
> identity
> >> at
> >> >> a network service is to choose from a differentiated set of
> policies.
> >> >> I think there is utility and efficiency in driving that selection
> >> from
> >> >> one place -- the network services classifier.     Say there were
> 2
> >> >> groups of subscribers -- children and adults.   Let's now define
> 2
> >> >> chains, where the chains have a business-based meaning to the
> >> operator.
> >> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
> >> filter-
> >> >> adult + Firewall-adult.    The referenced network services are
> >> logical
> >> >> and it is possible, but not required, that multiple logical
> network
> >> >> services be located at the same IP address or FQDN.     Conveying
> >> the
> >> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> >> ID, ...)
> >> >> allows the IP-addressable server that realizes these service(s)
> to
> >> know
> >> >> two things -- 1) which logical network function should be invoked
> >> and 2)
> >> >> which logical network function is next.
> >> >>>
> >> >>> Thanks.
> >> >>> Ron
> >> >>>
> >> >>> -----Original Message-----
> >> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> >> >>> To: Ron Parker
> >> >>> Cc: nsc@ietf.org
> >> >>> Subject: Re: [nsc] Service chaining architecture question
> >> >>>
> >> >>> Ron,
> >> >>>      maybe I am missing something, but you seem to lay out very
> >> nicely
> >> >> the case for wanting both service chain identification and
> >> separately
> >> >> subscriber identification.  Then the HTTP filter can use the
> >> subscriber
> >> >> ID to decide which exact content filtering behavior it should
> apply.
> >> I
> >> >> would not want to fold that level of detail into the chain
> >> >> identification.
> >> >>>
> >> >>> Yours,
> >> >>> Joel
> >> >>>
> >> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >> >>>> Dave,
> >> >>>>
> >> >>>> I agree that the number of chains is unlikely to scale to vast
> >> >> numbers
> >> >>>> (i.e., millions).     And I agree that it is bounded from a
> >> >> practical
> >> >>>> business perspective, as you point out.
> >> >>>>
> >> >>>> You may already be on this page, but I wanted to point out a
> >> >>>> distinction of coarse-grained definition of a service function
> vs.
> >> >> finer-grained
> >> >>>> definition of a service function.   Consider a service function
> to
> >> >> be
> >> >>>> logical in such a way that the identity of the logical function
> >> may
> >> >> also
> >> >>>> imply some differentiated behavior.   For example, a conceptual
> >> >> function
> >> >>>> is HTTP content filtering.    This conceptual function can then
> be
> >> >>>> further instantiated at the logical level based on
> differentiated
> >> >>>> policies such as content-filter-children,
> >> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
> taking
> >> no
> >> >> stand on opt-in vs. opt-out, Mr.
> >> >>>> Cameron).   It may be that the same network element (dedicated
> >> >> physical
> >> >>>> box or virtual network function) realizes all 3 of the example
> >> >>>> policies.   The HTTP content filtering network function is
> really
> >> 3
> >> >>>> logical network functions from the perspective of inclusion in
> a
> >> >> service
> >> >>>> chain.   Now extend this to multiple conceptual functions that
> >> >> utilize
> >> >>>> differentiated policies and the number of combinations will
> grow,
> >> at
> >> >>>> least modestly.
> >> >>>>
> >> >>>> Thanks,
> >> >>>>
> >> >>>> Ron
> >> >>>>
> >> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
> >> Behalf
> >> >>>> Of *David Allan I
> >> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >>>>
> >> >>>> Saying functions will have a problem with something that exists
> as
> >> a
> >> >>>> potential rationale for defining something new with exactly the
> >> same
> >> >>>> properties and problems does not quite work for me....
> >> >>>>
> >> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
> >> >> stack
> >> >>>> construction and this being combined with application
> >> "cooperation"
> >> >>>> to preserve pairwise mappings of either VID/NIC tuples or
> simply
> >> >>>> NICs) currently exist as potential vehicles for preserving
> chain
> >> >>>> context and avoiding per hop classification. Anything else will
> be
> >> >>>> implemented more or less the same way and have exactly the same
> >> set
> >> >>>> of scaling and application design issues...Some extra
> information
> >> >>>> available on a single interface, or achieved by mapping chain
> >> >>>> instances onto one of a plurality of interfaces....
> >> >>>>
> >> >>>> But to back up... I'm not a carrier employee but I cannot
> envision
> >> a
> >> >>>> carrier offering potentially 1000s of distinct service bundles
> >> >> ("pick
> >> >>>> 53 from column A and 49 from column B"). So I suspect a much
> >> smaller
> >> >>>> number is realistic for  the number of chains a function
> instance
> >> is
> >> >>>> expected to participate in, even allowing for dynamic
> >> >>>> reclassification of flows at a chain ingress to "skip a few
> >> >>>> functions".... These are things that are fully operationalized
> in
> >> >>>> OSS, have policy associated with, have been industrialized and
> >> >>>> demonstrated to work prior to deployment. Going all
> combinatorial
> >> on
> >> >> this will break that big time....
> >> >>>>
> >> >>>> So are we really discussing a function participating in more
> than
> >> a
> >> >>>> handful of chain instances? And either a plurality of vNICs or
> >> VIDs
> >> >>>> being actually more than sufficient?
> >> >>>>
> >> >>>> Thanks
> >> >>>>
> >> >>>> Dave
> >> >>>>
> >> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
> (Wim)
> >> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >>>>
> >> >>>> indeed
> >> >>>>
> >> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >> >>>> *Date: *Wednesday 24 July 2013 15:54
> >> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >> >>>> *Subject: *AW: Service chaining architecture question
> >> >>>>
> >> >>>> Hi Wim,
> >> >>>>
> >> >>>> I think not only effectivness/scalability might be a problem
> but
> >> >> also
> >> >>>> the fact that not all applications (service bringing functions)
> >> are
> >> >>>> able to handle packets coming from/going to potentially
> thousands
> >> of
> >> >>>> different VLANs at the same time. VLANs will work in certain
> >> >>>> environments but not in all. I see the need for an information
> >> >>>> exchange between the application and a mediation layer as well.
> >> >>>> Ideally this should be as simple as possible without heavy
> impact
> >> on
> >> >>>> the application itself (might be difficult to achieve but from
> my
> >> >>>> experience it is not very likely, that there will be big
> rewrites
> >> of
> >> >>>> existing applications in order to support the chaining).
> >> >>>>
> >> >>>>    regards
> >> >>>>
> >> >>>>       Nic
> >> >>>>
> >> >>>> ---------------------------------------------------------------
> ---
> >> --
> >> >> -
> >> >>>> -
> >> >>>> --
> >> >>>>
> >> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
> >> (Wim)
> >> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >> >>>> *Betreff:* [nsc] Service chaining architecture question
> >> >>>>
> >> >>>> I have a basic question with respect to the
> architecture/framework
> >> >> so
> >> >>>> far mentioned in the drafts in NSC. I understand the meta-data
> is
> >> a
> >> >>>> mechanism to avoid multiple re-classifications when the packet
> >> >> enters
> >> >>>> the NSC domain and identifies the chain of service functions.
> Now
> >> my
> >> >>>> understanding is that the services/applications are unaware of
> the
> >> >>>> meta-data and that a layer underneath should provide the
> mediation
> >> >>>> and that we use a well defined interface to the
> >> application/service
> >> >>>> to indicate the chain. In the context of Cloud/enterprise
> >> >> environment
> >> >>>> I can see this work given you can use a dedicate VLAN e.g.
> within
> >> >> the tenant.
> >> >>>> However we also try to address residential use cases for mobile
> >> and
> >> >>>> fixed and here this becomes more tricky afais. In the
> residential
> >> >>>> environment we can't expose a VLAN per application/service per
> >> chain
> >> >>>> since this would not be very effective. So I am wondering how
> we
> >> >>>> envision this to work?
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> nsc mailing list
> >> >>>> nsc@ietf.org
> >> >>>>https://www.ietf.org/mailman/listinfo/nsc
> >> >>> _______________________________________________
> >> >>> nsc mailing list
> >> >>> nsc@ietf.org
> >> >>>https://www.ietf.org/mailman/listinfo/nsc
> >> >> _______________________________________________
> >> >> nsc mailing list
> >> >> nsc@ietf.org
> >> >>https://www.ietf.org/mailman/listinfo/nsc
> >> >
> >
> >
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc
> >
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From jguichar@cisco.com  Wed Jul 24 16:48:49 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E1621F99FB for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGO46o0EsWSl for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:48:44 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 02EF521F9958 for <nsc@ietf.org>; Wed, 24 Jul 2013 16:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14612; q=dns/txt; s=iport; t=1374709724; x=1375919324; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ql+3yWhP6cVrDGW8xBOHhyKARhaEfxJx95bKTkkZuXo=; b=j2ge5eiTagZBR4RMymnSbWtqQfi7Vi4CB9s5hlqTp/ju9sQbc3imnkdP L8jK5mLmDJb1Cr2ZXte4Bl2uZ+Y+B0yZpf3XHq49yN+/KSrnqSkmPxsXZ sx/WJxQcg/nOoTgdNUBgtUDZWK7G9vxIT74tZDuYLbUkKrKwwVe7R9Oqj I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYFAEVn8FGtJXHA/2dsb2JhbABSCYMGNVC9ZIEWFnSCJAEBAQQBAQEkEy0HCwwGAQgRAQIBAQEBChQJLgsUAwYIAgQBDQUIiAgMuXQEjkWBBwYrBwIEgwxuA5QIjgqHGoMUgio
X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208";a="236083052"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jul 2013 23:48:43 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6ONmgGA018094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 23:48:42 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 18:48:42 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAP//xvIAgABGZgD//77hgA==
Date: Wed, 24 Jul 2013 23:48:41 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5C48CD@xmb-rcd-x01.cisco.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B4D3A1@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.211]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <209567713DDBFE4BB58E2CB9DA42CC2B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:48:49 -0000

Hi Linda,

There are actually many use cases. Here are just a small sample:

- forwarding information, such as VRF: the ingress VRF of the packet on
the 1st classifier.  Using this encoded VRF the last node in the chain can
place the (post service(s)) packets into the right forwarding context.
This way the service chain is "vrf enabled" without the service
participating in the routing topology, and there is no need to return the
packets, after chaining, to the original classifier.

- application id: if the first classifier knows the application (from
direct classification, or from an external source such as a VM manager),
that application can be carried in the metadata.  For example, the
classifier imposes a value that indicates that the packet belong to
"oracle".  The firewall now no longer has to try to figure out if packets
are "oracle" or not, and can permit/deny based on the pre-classified
context.  This model gets even more powerful when extended to services:
they can update contexts as well and share it amongst themselves.

- External information about a flow: for example, PCRF subscriber
information can be encoded in the data plane.  The services can use this
context to apply subscriber-aware policy without having to participate in
the policy/control planes.




On 7/24/13 7:41 PM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:

>Jim,=20
>
>Do you mean that some service modules need information inserted by the
>upstream service modules to make the needed actions?
>
>That is fine. Then those "mega data" inserted by the service modules are
>really internal among the service modules.
>
>Layer 4-7 services have been discussed in ONF for quite some time. We
>have decided to describe service modules in two categories: Proxy based
>and packet based.=20
>
>*	Proxy based service functions: these service functions terminate
>original packets, may reassemble multiple packets, reopen a new
>connection, or formulate new packets based on the received packets.
>
>*	Packet based service functions: these service modules maintain original
>packets, i.e. they don't make changes to packets traversed through except
>possibly changing some header fields.
>
>Linda
>
>
>> -----Original Message-----
>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> Sent: Wednesday, July 24, 2013 6:30 PM
>> To: Linda Dunbar; Ron Parker
>> Cc: nsc@ietf.org; Joel M. Halpern
>> Subject: Re: [nsc] Service chaining architecture question
>>=20
>> Hi Linda,
>>=20
>> The service chaining "problem" is not just about data plane and getting
>> packets from point A to point B. That's the easy bit. True, some basic
>> services may be just fine with this approach but the wider issue is how
>> to
>> share "intelligence" between the network and services, and between
>> services. A simple label allocation may not satisfy such requirements.
>> Mapping 1:1 chain-id<->policy seems the wrong direction to take imho.
>>=20
>> On 7/24/13 6:53 PM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:
>>=20
>> >
>> >Agree with Ron that it is better to have fewer nodes in network to
>> make
>> >subscriber-aware policy decisions.
>> >
>> >Besides, it is not uncommon for multiple subscribers to share same
>> >sequence of service modules. In this environment, if the network edge
>> >nodes, such as Broadband Network Gateway or Cell Site Gateway, can use
>> >Layer 2 or 3 labels to mark the traffic, the subsequent network nodes
>> can
>> >steer traffic to the needed service modules without looking into "Mega
>> >data" or other higher layer fields in the data frames.
>> >
>> >This approach can make "service chain" work without making changes to
>> >majority of existing deployed network elements.
>> >
>> >Linda
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> Jim,
>> >>
>> >> Yes, that could work, too, conceptually.   But it does require that
>> >> each coarsely-defined network service have access to a subscriber-
>> aware
>> >> policy resolution mechanism.   IMO, it is better to have fewer
>> network
>> >> elements making subscriber-aware policy decisions.
>> >
>> >
>> >>
>> >>    Ron
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>> >> To: Ron Parker
>> >> Cc: Joel M. Halpern; nsc@ietf.org
>> >> Subject: Re: [nsc] Service chaining architecture question
>> >>
>> >> Ron,
>> >> Or alternatively carry the subscriber awareness in metadata thereby
>> >> utilizing a single chain.
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> >> <Ron_Parker@affirmednetworks.com> wrote:
>> >>
>> >> > Joel,
>> >> >
>> >> > IMO, the primary reason for understanding the subscriber identity
>> at
>> >> a network service is to choose from a differentiated set of policies.
>> >> I think there is utility and efficiency in driving that selection
>> from
>> >> one place -- the network services classifier.     Say there were 2
>> >> groups of subscribers -- children and adults.   Let's now define 2
>> >> chains, where the chains have a business-based meaning to the
>> operator.
>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>> filter-
>> >> adult + Firewall-adult.    The referenced network services are
>> logical
>> >> and it is possible, but not required, that multiple logical network
>> >> services be located at the same IP address or FQDN.     Conveying
>> the
>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>> ID, ...)
>> >> allows the IP-addressable server that realizes these service(s) to
>> know
>> >> two things -- 1) which logical network function should be invoked
>> and 2)
>> >> which logical network function is next.
>> >> >
>> >> > Thanks.
>> >> > Ron
>> >> >
>> >> > -----Original Message-----
>> >> > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> >> > Sent: Wednesday, July 24, 2013 4:47 PM
>> >> > To: Ron Parker
>> >> > Cc: nsc@ietf.org
>> >> > Subject: Re: [nsc] Service chaining architecture question
>> >> >
>> >> > Ron,
>> >> >     maybe I am missing something, but you seem to lay out very
>> nicely
>> >> the case for wanting both service chain identification and
>> separately
>> >> subscriber identification.  Then the HTTP filter can use the
>> subscriber
>> >> ID to decide which exact content filtering behavior it should apply.
>> I
>> >> would not want to fold that level of detail into the chain
>> >> identification.
>> >> >
>> >> > Yours,
>> >> > Joel
>> >> >
>> >> > On 7/24/13 4:05 PM, Ron Parker wrote:
>> >> >> Dave,
>> >> >>
>> >> >> I agree that the number of chains is unlikely to scale to vast
>> >> numbers
>> >> >> (i.e., millions).     And I agree that it is bounded from a
>> >> practical
>> >> >> business perspective, as you point out.
>> >> >>
>> >> >> You may already be on this page, but I wanted to point out a
>> >> >> distinction of coarse-grained definition of a service function vs.
>> >> finer-grained
>> >> >> definition of a service function.   Consider a service function
>> to
>> >> be
>> >> >> logical in such a way that the identity of the logical function
>> may
>> >> also
>> >> >> imply some differentiated behavior.   For example, a conceptual
>> >> function
>> >> >> is HTTP content filtering.    This conceptual function can then
>> be
>> >> >> further instantiated at the logical level based on differentiated
>> >> >> policies such as content-filter-children,
>> >> >> content-filter-adults-no-porn, content-filter-adults (I'm taking
>> no
>> >> stand on opt-in vs. opt-out, Mr.
>> >> >> Cameron).   It may be that the same network element (dedicated
>> >> physical
>> >> >> box or virtual network function) realizes all 3 of the example
>> >> >> policies.   The HTTP content filtering network function is really
>> 3
>> >> >> logical network functions from the perspective of inclusion in a
>> >> service
>> >> >> chain.   Now extend this to multiple conceptual functions that
>> >> utilize
>> >> >> differentiated policies and the number of combinations will grow,
>> at
>> >> >> least modestly.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Ron
>> >> >>
>> >> >> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>> Behalf
>> >> >> Of *David Allan I
>> >> >> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >> >> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> >> >> *Subject:* Re: [nsc] Service chaining architecture question
>> >> >>
>> >> >> Saying functions will have a problem with something that exists
>> as a
>> >> >> potential rationale for defining something new with exactly the
>> same
>> >> >> properties and problems does not quite work for me....
>> >> >>
>> >> >> VLANs on a vNIC or multiple vNICs (depending on the application
>> >> stack
>> >> >> construction and this being combined with application
>> "cooperation"
>> >> >> to preserve pairwise mappings of either VID/NIC tuples or simply
>> >> >> NICs) currently exist as potential vehicles for preserving chain
>> >> >> context and avoiding per hop classification. Anything else will
>> be
>> >> >> implemented more or less the same way and have exactly the same
>> set
>> >> >> of scaling and application design issues...Some extra information
>> >> >> available on a single interface, or achieved by mapping chain
>> >> >> instances onto one of a plurality of interfaces....
>> >> >>
>> >> >> But to back up... I'm not a carrier employee but I cannot
>> envision a
>> >> >> carrier offering potentially 1000s of distinct service bundles
>> >> ("pick
>> >> >> 53 from column A and 49 from column B"). So I suspect a much
>> smaller
>> >> >> number is realistic for  the number of chains a function instance
>> is
>> >> >> expected to participate in, even allowing for dynamic
>> >> >> reclassification of flows at a chain ingress to "skip a few
>> >> >> functions".... These are things that are fully operationalized in
>> >> >> OSS, have policy associated with, have been industrialized and
>> >> >> demonstrated to work prior to deployment. Going all combinatorial
>> on
>> >> this will break that big time....
>> >> >>
>> >> >> So are we really discussing a function participating in more than
>> a
>> >> >> handful of chain instances? And either a plurality of vNICs or
>> VIDs
>> >> >> being actually more than sufficient?
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Dave
>> >> >>
>> >> >> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >> >> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>> >> >> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >> >> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>> >> >> nsc@ietf.org <mailto:nsc@ietf.org>
>> >> >> *Subject:* Re: [nsc] Service chaining architecture question
>> >> >>
>> >> >> indeed
>> >> >>
>> >> >> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >> >> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >> >> *Date: *Wednesday 24 July 2013 15:54
>> >> >> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >> >> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>> >> >> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >> >> *Subject: *AW: Service chaining architecture question
>> >> >>
>> >> >> Hi Wim,
>> >> >>
>> >> >> I think not only effectivness/scalability might be a problem but
>> >> also
>> >> >> the fact that not all applications (service bringing functions)
>> are
>> >> >> able to handle packets coming from/going to potentially thousands
>> of
>> >> >> different VLANs at the same time. VLANs will work in certain
>> >> >> environments but not in all. I see the need for an information
>> >> >> exchange between the application and a mediation layer as well.
>> >> >> Ideally this should be as simple as possible without heavy impact
>> on
>> >> >> the application itself (might be difficult to achieve but from my
>> >> >> experience it is not very likely, that there will be big rewrites
>> of
>> >> >> existing applications in order to support the chaining).
>> >> >>
>> >> >>   regards
>> >> >>
>> >> >>      Nic
>> >> >>
>> >> >> -----------------------------------------------------------------
>> ---
>> >> -
>> >> >> -
>> >> >> --
>> >> >>
>> >> >> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >> >> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>> (Wim)
>> >> >> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >> >> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >> >> *Betreff:* [nsc] Service chaining architecture question
>> >> >>
>> >> >> I have a basic question with respect to the
>> architecture/framework
>> >> so
>> >> >> far mentioned in the drafts in NSC. I understand the meta-data is
>> a
>> >> >> mechanism to avoid multiple re-classifications when the packet
>> >> enters
>> >> >> the NSC domain and identifies the chain of service functions. Now
>> my
>> >> >> understanding is that the services/applications are unaware of
>> the
>> >> >> meta-data and that a layer underneath should provide the
>> mediation
>> >> >> and that we use a well defined interface to the
>> application/service
>> >> >> to indicate the chain. In the context of Cloud/enterprise
>> >> environment
>> >> >> I can see this work given you can use a dedicate VLAN e.g. within
>> >> the tenant.
>> >> >> However we also try to address residential use cases for mobile
>> and
>> >> >> fixed and here this becomes more tricky afais. In the residential
>> >> >> environment we can't expose a VLAN per application/service per
>> chain
>> >> >> since this would not be very effective. So I am wondering how we
>> >> >> envision this to work?
>> >> >>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> nsc mailing list
>> >> >> nsc@ietf.org
>> >> >> https://www.ietf.org/mailman/listinfo/nsc
>> >> > _______________________________________________
>> >> > nsc mailing list
>> >> > nsc@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/nsc
>> >> _______________________________________________
>> >> nsc mailing list
>> >> nsc@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/nsc
>> >_______________________________________________
>> >nsc mailing list
>> >nsc@ietf.org
>> >https://www.ietf.org/mailman/listinfo/nsc
>


From linda.dunbar@huawei.com  Wed Jul 24 16:52:56 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D7F21F99F4 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdgYLx-A+Zuc for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 16:52:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E7A8B21F9931 for <nsc@ietf.org>; Wed, 24 Jul 2013 16:52:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ90031; Wed, 24 Jul 2013 23:52:49 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 00:52:34 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 00:52:48 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 16:52:45 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAPrusAAA6WcXD//5GVAIAAckyA
Date: Wed, 24 Jul 2013 23:52:44 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4D3C3@dfweml509-mbx.china.huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com>
In-Reply-To: <51F064A2.3060601@joelhalpern.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.128.98]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 23:52:56 -0000

Joel,=20

Agree with what you said and your concern. I think that Service Chain from =
subscriber perspective is different from service chain from network traffic=
 steering perspective. The information to be passed among service modules f=
or specific flows is at another dimension.=20


>From user's (or subscriber) perspective, the service chain is a sequence of=
 service functions, such as Chain#1 {s1, s4, s6}, Chain#2{s4, s7} applied t=
o the user's (or subscriber's) traffic.


>From the traffic steering perspective, a Service Chain guarantees that spec=
ific data flows go through a specific sequence of service modules at design=
ated points along the flow paths in the network. Those flows can be aggrega=
ted traffic among multiple subscribers.=20

>From traffic steering point of view, one service chain consists of:
-	Identifier
-	{Steering point List}
-	Steering Point #1, {list of Service Modules}
-	Steering Point #2, {list of Service Modules}
-	...

Two service chains with the same sequence of service modules but different =
steering points should be considered as two different service chains from t=
raffic steering point of view.

Linda

> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Wednesday, July 24, 2013 6:35 PM
> To: Linda Dunbar
> Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
> Subject: Re: [nsc] Service chaining architecture question
>=20
> I would not be surprised if we want all three of
> Service Chain,
> Service Policy, and
> Subscriber / user identity
> in the packet.
> If the Chain is in the VLAN / MPLS label, then we can discuss whether
> the other information goes in additional ids of the same type or in a
> carried header.  I can construct arguments for either approach.
>=20
> It may be easier to just carry the subscriber identity, and used the
> same management systems to assign policies to the devices that care.  I
> am concerned that it may not be practical to use a single policy
> identifier to specify which HTTP rule set to use, which Firewall rule
> set to use, and then which specific policy for other user selected
> policy applications.
>=20
> Yours,
> Joel
>=20
> On 7/24/13 7:30 PM, Linda Dunbar wrote:
> > Joel,
> >> -----Original Message-----
> >>
> >> Yes, having the chain ingress node mark the traffic makes good sense.
> >> Having it mark the subscriber identity and the chain to be traversed
> >> seems quite sensible.
> >>
> >> The difference I think I have with Ron is that he proposes to use
> one
> >> identifier for both entities.
> > [Linda] I hope you don't mean per subscriber identity, do you? With
> > today's PCRF, subscribers are categorized based on their subscription
> > types. Throughout the network, the "subscription types" dictate what
> > service modules their corresponding traffic need to traverse through.
> > Some service modules might need to examine packets deeper (i.e. look
> > into payload) for their intended functions. They may need to extract
> the
> > "HTTP header" or HTTP messages from one or multiple packets.
> > That causes, as Dave said, a
> >> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
> MPLS
> >> labels.
> > [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> > The subscriber identity could be some bits in the payload.
> >>
> >> And if the existing boxes don't know how to handle that (as seems
> >> likely) then we need a proxy / support function to translate the
> common
> >> protocol into whatever they used before we got something generally
> >> usable out there.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >> >
> >> > Agree with Ron that it is better to have fewer nodes in network to
> >> make subscriber-aware policy decisions.
> >> >
> >> > Besides, it is not uncommon for multiple subscribers to share same
> >> sequence of service modules. In this environment, if the network
> edge
> >> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
> use
> >> Layer 2 or 3 labels to mark the traffic, the subsequent network
> nodes
> >> can steer traffic to the needed service modules without looking into
> >> "Mega data" or other higher layer fields in the data frames.
> >> >
> >> > This approach can make "service chain" work without making changes
> to
> >> majority of existing deployed network elements.
> >> >
> >> > Linda
> >> >
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> Jim,
> >> >>
> >> >> Yes, that could work, too, conceptually.   But it does require
> that
> >> >> each coarsely-defined network service have access to a
> subscriber-
> >> aware
> >> >> policy resolution mechanism.   IMO, it is better to have fewer
> >> network
> >> >> elements making subscriber-aware policy decisions.
> >> >
> >> >
> >> >>
> >> >>     Ron
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >> >> To: Ron Parker
> >> >> Cc: Joel M. Halpern; nsc@ietf.org
> >> >> Subject: Re: [nsc] Service chaining architecture question
> >> >>
> >> >> Ron,
> >> >> Or alternatively carry the subscriber awareness in metadata
> thereby
> >> >> utilizing a single chain.
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >> >> <Ron_Parker@affirmednetworks.com> wrote:
> >> >>
> >> >>> Joel,
> >> >>>
> >> >>> IMO, the primary reason for understanding the subscriber
> identity
> >> at
> >> >> a network service is to choose from a differentiated set of
> policies.
> >> >> I think there is utility and efficiency in driving that selection
> >> from
> >> >> one place -- the network services classifier.     Say there were
> 2
> >> >> groups of subscribers -- children and adults.   Let's now define
> 2
> >> >> chains, where the chains have a business-based meaning to the
> >> operator.
> >> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
> >> filter-
> >> >> adult + Firewall-adult.    The referenced network services are
> >> logical
> >> >> and it is possible, but not required, that multiple logical
> network
> >> >> services be located at the same IP address or FQDN.     Conveying
> >> the
> >> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> >> ID, ...)
> >> >> allows the IP-addressable server that realizes these service(s)
> to
> >> know
> >> >> two things -- 1) which logical network function should be invoked
> >> and 2)
> >> >> which logical network function is next.
> >> >>>
> >> >>> Thanks.
> >> >>> Ron
> >> >>>
> >> >>> -----Original Message-----
> >> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> >> >>> To: Ron Parker
> >> >>> Cc: nsc@ietf.org
> >> >>> Subject: Re: [nsc] Service chaining architecture question
> >> >>>
> >> >>> Ron,
> >> >>>      maybe I am missing something, but you seem to lay out very
> >> nicely
> >> >> the case for wanting both service chain identification and
> >> separately
> >> >> subscriber identification.  Then the HTTP filter can use the
> >> subscriber
> >> >> ID to decide which exact content filtering behavior it should
> apply.
> >> I
> >> >> would not want to fold that level of detail into the chain
> >> >> identification.
> >> >>>
> >> >>> Yours,
> >> >>> Joel
> >> >>>
> >> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >> >>>> Dave,
> >> >>>>
> >> >>>> I agree that the number of chains is unlikely to scale to vast
> >> >> numbers
> >> >>>> (i.e., millions).     And I agree that it is bounded from a
> >> >> practical
> >> >>>> business perspective, as you point out.
> >> >>>>
> >> >>>> You may already be on this page, but I wanted to point out a
> >> >>>> distinction of coarse-grained definition of a service function
> vs.
> >> >> finer-grained
> >> >>>> definition of a service function.   Consider a service function
> to
> >> >> be
> >> >>>> logical in such a way that the identity of the logical function
> >> may
> >> >> also
> >> >>>> imply some differentiated behavior.   For example, a conceptual
> >> >> function
> >> >>>> is HTTP content filtering.    This conceptual function can then
> be
> >> >>>> further instantiated at the logical level based on
> differentiated
> >> >>>> policies such as content-filter-children,
> >> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
> taking
> >> no
> >> >> stand on opt-in vs. opt-out, Mr.
> >> >>>> Cameron).   It may be that the same network element (dedicated
> >> >> physical
> >> >>>> box or virtual network function) realizes all 3 of the example
> >> >>>> policies.   The HTTP content filtering network function is
> really
> >> 3
> >> >>>> logical network functions from the perspective of inclusion in
> a
> >> >> service
> >> >>>> chain.   Now extend this to multiple conceptual functions that
> >> >> utilize
> >> >>>> differentiated policies and the number of combinations will
> grow,
> >> at
> >> >>>> least modestly.
> >> >>>>
> >> >>>> Thanks,
> >> >>>>
> >> >>>> Ron
> >> >>>>
> >> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
> >> Behalf
> >> >>>> Of *David Allan I
> >> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >>>>
> >> >>>> Saying functions will have a problem with something that exists
> as
> >> a
> >> >>>> potential rationale for defining something new with exactly the
> >> same
> >> >>>> properties and problems does not quite work for me....
> >> >>>>
> >> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
> >> >> stack
> >> >>>> construction and this being combined with application
> >> "cooperation"
> >> >>>> to preserve pairwise mappings of either VID/NIC tuples or
> simply
> >> >>>> NICs) currently exist as potential vehicles for preserving
> chain
> >> >>>> context and avoiding per hop classification. Anything else will
> be
> >> >>>> implemented more or less the same way and have exactly the same
> >> set
> >> >>>> of scaling and application design issues...Some extra
> information
> >> >>>> available on a single interface, or achieved by mapping chain
> >> >>>> instances onto one of a plurality of interfaces....
> >> >>>>
> >> >>>> But to back up... I'm not a carrier employee but I cannot
> envision
> >> a
> >> >>>> carrier offering potentially 1000s of distinct service bundles
> >> >> ("pick
> >> >>>> 53 from column A and 49 from column B"). So I suspect a much
> >> smaller
> >> >>>> number is realistic for  the number of chains a function
> instance
> >> is
> >> >>>> expected to participate in, even allowing for dynamic
> >> >>>> reclassification of flows at a chain ingress to "skip a few
> >> >>>> functions".... These are things that are fully operationalized
> in
> >> >>>> OSS, have policy associated with, have been industrialized and
> >> >>>> demonstrated to work prior to deployment. Going all
> combinatorial
> >> on
> >> >> this will break that big time....
> >> >>>>
> >> >>>> So are we really discussing a function participating in more
> than
> >> a
> >> >>>> handful of chain instances? And either a plurality of vNICs or
> >> VIDs
> >> >>>> being actually more than sufficient?
> >> >>>>
> >> >>>> Thanks
> >> >>>>
> >> >>>> Dave
> >> >>>>
> >> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
> (Wim)
> >> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >>>>
> >> >>>> indeed
> >> >>>>
> >> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >> >>>> *Date: *Wednesday 24 July 2013 15:54
> >> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >> >>>> *Subject: *AW: Service chaining architecture question
> >> >>>>
> >> >>>> Hi Wim,
> >> >>>>
> >> >>>> I think not only effectivness/scalability might be a problem
> but
> >> >> also
> >> >>>> the fact that not all applications (service bringing functions)
> >> are
> >> >>>> able to handle packets coming from/going to potentially
> thousands
> >> of
> >> >>>> different VLANs at the same time. VLANs will work in certain
> >> >>>> environments but not in all. I see the need for an information
> >> >>>> exchange between the application and a mediation layer as well.
> >> >>>> Ideally this should be as simple as possible without heavy
> impact
> >> on
> >> >>>> the application itself (might be difficult to achieve but from
> my
> >> >>>> experience it is not very likely, that there will be big
> rewrites
> >> of
> >> >>>> existing applications in order to support the chaining).
> >> >>>>
> >> >>>>    regards
> >> >>>>
> >> >>>>       Nic
> >> >>>>
> >> >>>> ---------------------------------------------------------------
> ---
> >> --
> >> >> -
> >> >>>> -
> >> >>>> --
> >> >>>>
> >> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
> >> (Wim)
> >> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >> >>>> *Betreff:* [nsc] Service chaining architecture question
> >> >>>>
> >> >>>> I have a basic question with respect to the
> architecture/framework
> >> >> so
> >> >>>> far mentioned in the drafts in NSC. I understand the meta-data
> is
> >> a
> >> >>>> mechanism to avoid multiple re-classifications when the packet
> >> >> enters
> >> >>>> the NSC domain and identifies the chain of service functions.
> Now
> >> my
> >> >>>> understanding is that the services/applications are unaware of
> the
> >> >>>> meta-data and that a layer underneath should provide the
> mediation
> >> >>>> and that we use a well defined interface to the
> >> application/service
> >> >>>> to indicate the chain. In the context of Cloud/enterprise
> >> >> environment
> >> >>>> I can see this work given you can use a dedicate VLAN e.g.
> within
> >> >> the tenant.
> >> >>>> However we also try to address residential use cases for mobile
> >> and
> >> >>>> fixed and here this becomes more tricky afais. In the
> residential
> >> >>>> environment we can't expose a VLAN per application/service per
> >> chain
> >> >>>> since this would not be very effective. So I am wondering how
> we
> >> >>>> envision this to work?
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> nsc mailing list
> >> >>>> nsc@ietf.org
> >> >>>>https://www.ietf.org/mailman/listinfo/nsc
> >> >>> _______________________________________________
> >> >>> nsc mailing list
> >> >>> nsc@ietf.org
> >> >>>https://www.ietf.org/mailman/listinfo/nsc
> >> >> _______________________________________________
> >> >> nsc mailing list
> >> >> nsc@ietf.org
> >> >>https://www.ietf.org/mailman/listinfo/nsc
> >> >
> >
> >
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc
> >

From Ron_Parker@affirmednetworks.com  Wed Jul 24 17:42:32 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1978F21F92B8 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 17:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkhyXd+eNMtk for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 17:42:27 -0700 (PDT)
Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id D064321F89A5 for <nsc@ietf.org>; Wed, 24 Jul 2013 17:42:23 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0123.003; Wed, 24 Jul 2013 17:42:21 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAPrusAAA6WcXD//5GVAIAAbh9w
Date: Thu, 25 Jul 2013 00:42:20 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E3F7@MBX021-W3-CA-2.exch021.domain.local>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com>
In-Reply-To: <51F064A2.3060601@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.150.224]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 00:42:32 -0000

Thanks, all, for a lively discussion on this topic.

One thing that flavors the discussion of network service chaining is the de=
finition of "service".   It really means different things to different peop=
le.   We networking types tend to look at it as a software application or s=
oftware system composed of multiple software applications (i.e., an HTTP co=
ntent filter).   But when I interact with the business folks, especially on=
 the operator side, I hear a different notion of "service" -- something sub=
scribers pay for, government mandates, etc.   This is why, IMO, it is defen=
sible to say that the HTTP-content-filter-children is a distinct service fr=
om HTTP-content-filter-adult, even if both are realized on the same server =
by the same software application using the same global URL database.

It does sound like at least some that have chimed in do feel that both the =
general service type (i.e., HTTP content filter) and the policy set need to=
 be conveyed in some manner.    How to do this is a set of tradeoffs around=
 control plane protocol and data plane encapsulation.    Without any contro=
l plane, both types of information need to be on the wire in some form.   I=
 will assume that the policy set identity is distinct at each service insta=
nce (i.e, policy set 2 at the HTTP content filter does not imply the same s=
et of subscribers as policy set 2 at the firewall).   I will also assume th=
at the meaning and interpretation of a policy set identity is specific to t=
hat type of service and probably to the vendor that supplied the service.  =
 This is similar to when a PCRF names a PCC rulebase rather than supplying =
the full set of explicit PCC rules.    =20

The advantage of a single chain ID that can be interpreted as a sequence of=
 {service-type-instance, policy-set} is that it minimizes the per-packet en=
capsulation requirement (i.e., a single GRE key could suffice).   The disad=
vantage that has been pointed out is that global coordination of this ident=
ity is required and the number of combinations could become unwieldy.  =20

Another approach could be to have a new encapsulation that represents a sta=
ck of 2-tuples {service-ip-address, service-specific-policy-id}, or even 3-=
tuples {service-ip-address, service-type, service-specific-policy-id} where=
 the 3-tuple brings the added advantage of allowing for multiple dissimilar=
 services realized by the same server at the same server ip address.   The =
advantage of this approach is that it avoids the combinatorial explosion pr=
oblem, but it requires a larger and variable length encapsulation.

If the global chain id approach is used, a control plane protocol could be =
used to distribute the definitions of each chain (i.e, each chain is really=
 a stack of 2-tuples or 3-tuples, per description above).   =20

Thanks.

    Ron

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20
Sent: Wednesday, July 24, 2013 7:35 PM
To: Linda Dunbar
Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
Subject: Re: [nsc] Service chaining architecture question

I would not be surprised if we want all three of Service Chain, Service Pol=
icy, and Subscriber / user identity in the packet.
If the Chain is in the VLAN / MPLS label, then we can discuss whether the o=
ther information goes in additional ids of the same type or in a carried he=
ader.  I can construct arguments for either approach.

It may be easier to just carry the subscriber identity, and used the same m=
anagement systems to assign policies to the devices that care.  I am concer=
ned that it may not be practical to use a single policy identifier to speci=
fy which HTTP rule set to use, which Firewall rule set to use, and then whi=
ch specific policy for other user selected policy applications.

Yours,
Joel

On 7/24/13 7:30 PM, Linda Dunbar wrote:
> Joel,
>> -----Original Message-----
>>
>> Yes, having the chain ingress node mark the traffic makes good sense.
>> Having it mark the subscriber identity and the chain to be traversed=20
>> seems quite sensible.
>>
>> The difference I think I have with Ron is that he proposes to use one=20
>> identifier for both entities.
> [Linda] I hope you don't mean per subscriber identity, do you? With=20
> today's PCRF, subscribers are categorized based on their subscription=20
> types. Throughout the network, the "subscription types" dictate what=20
> service modules their corresponding traffic need to traverse through.
> Some service modules might need to examine packets deeper (i.e. look=20
> into payload) for their intended functions. They may need to extract=20
> the "HTTP header" or HTTP messages from one or multiple packets.
> That causes, as Dave said, a
>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two=20
>> MPLS labels.
> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> The subscriber identity could be some bits in the payload.
>>
>> And if the existing boxes don't know how to handle that (as seems
>> likely) then we need a proxy / support function to translate the=20
>> common protocol into whatever they used before we got something=20
>> generally usable out there.
>>
>> Yours,
>> Joel
>>
>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>> >
>> > Agree with Ron that it is better to have fewer nodes in network to
>> make subscriber-aware policy decisions.
>> >
>> > Besides, it is not uncommon for multiple subscribers to share same
>> sequence of service modules. In this environment, if the network edge=20
>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can=20
>> use Layer 2 or 3 labels to mark the traffic, the subsequent network=20
>> nodes can steer traffic to the needed service modules without looking=20
>> into "Mega data" or other higher layer fields in the data frames.
>> >
>> > This approach can make "service chain" work without making changes=20
>> > to
>> majority of existing deployed network elements.
>> >
>> > Linda
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> Jim,
>> >>
>> >> Yes, that could work, too, conceptually.   But it does require that
>> >> each coarsely-defined network service have access to a subscriber-
>> aware
>> >> policy resolution mechanism.   IMO, it is better to have fewer
>> network
>> >> elements making subscriber-aware policy decisions.
>> >
>> >
>> >>
>> >>     Ron
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>> >> To: Ron Parker
>> >> Cc: Joel M. Halpern; nsc@ietf.org
>> >> Subject: Re: [nsc] Service chaining architecture question
>> >>
>> >> Ron,
>> >> Or alternatively carry the subscriber awareness in metadata=20
>> >> thereby utilizing a single chain.
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> >> <Ron_Parker@affirmednetworks.com> wrote:
>> >>
>> >>> Joel,
>> >>>
>> >>> IMO, the primary reason for understanding the subscriber identity
>> at
>> >> a network service is to choose from a differentiated set of policies.
>> >> I think there is utility and efficiency in driving that selection
>> from
>> >> one place -- the network services classifier.     Say there were 2
>> >> groups of subscribers -- children and adults.   Let's now define 2
>> >> chains, where the chains have a business-based meaning to the
>> operator.
>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>> filter-
>> >> adult + Firewall-adult.    The referenced network services are
>> logical
>> >> and it is possible, but not required, that multiple logical network
>> >> services be located at the same IP address or FQDN.     Conveying
>> the
>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>> ID, ...)
>> >> allows the IP-addressable server that realizes these service(s) to
>> know
>> >> two things -- 1) which logical network function should be invoked
>> and 2)
>> >> which logical network function is next.
>> >>>
>> >>> Thanks.
>> >>> Ron
>> >>>
>> >>> -----Original Message-----
>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>> >>> To: Ron Parker
>> >>> Cc: nsc@ietf.org
>> >>> Subject: Re: [nsc] Service chaining architecture question
>> >>>
>> >>> Ron,
>> >>>      maybe I am missing something, but you seem to lay out very
>> nicely
>> >> the case for wanting both service chain identification and
>> separately
>> >> subscriber identification.  Then the HTTP filter can use the
>> subscriber
>> >> ID to decide which exact content filtering behavior it should apply.
>> I
>> >> would not want to fold that level of detail into the chain=20
>> >> identification.
>> >>>
>> >>> Yours,
>> >>> Joel
>> >>>
>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>> >>>> Dave,
>> >>>>
>> >>>> I agree that the number of chains is unlikely to scale to vast
>> >> numbers
>> >>>> (i.e., millions).     And I agree that it is bounded from a
>> >> practical
>> >>>> business perspective, as you point out.
>> >>>>
>> >>>> You may already be on this page, but I wanted to point out a=20
>> >>>> distinction of coarse-grained definition of a service function vs.
>> >> finer-grained
>> >>>> definition of a service function.   Consider a service function to
>> >> be
>> >>>> logical in such a way that the identity of the logical function
>> may
>> >> also
>> >>>> imply some differentiated behavior.   For example, a conceptual
>> >> function
>> >>>> is HTTP content filtering.    This conceptual function can then be
>> >>>> further instantiated at the logical level based on=20
>> >>>> differentiated policies such as content-filter-children,=20
>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
>> no
>> >> stand on opt-in vs. opt-out, Mr.
>> >>>> Cameron).   It may be that the same network element (dedicated
>> >> physical
>> >>>> box or virtual network function) realizes all 3 of the example
>> >>>> policies.   The HTTP content filtering network function is really
>> 3
>> >>>> logical network functions from the perspective of inclusion in a
>> >> service
>> >>>> chain.   Now extend this to multiple conceptual functions that
>> >> utilize
>> >>>> differentiated policies and the number of combinations will=20
>> >>>> grow,
>> at
>> >>>> least modestly.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Ron
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>> Behalf
>> >>>> Of *David Allan I
>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> Saying functions will have a problem with something that exists=20
>> >>>> as
>> a
>> >>>> potential rationale for defining something new with exactly the
>> same
>> >>>> properties and problems does not quite work for me....
>> >>>>
>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>> >> stack
>> >>>> construction and this being combined with application
>> "cooperation"
>> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>> >>>> NICs) currently exist as potential vehicles for preserving chain=20
>> >>>> context and avoiding per hop classification. Anything else will=20
>> >>>> be implemented more or less the same way and have exactly the=20
>> >>>> same
>> set
>> >>>> of scaling and application design issues...Some extra=20
>> >>>> information available on a single interface, or achieved by=20
>> >>>> mapping chain instances onto one of a plurality of interfaces....
>> >>>>
>> >>>> But to back up... I'm not a carrier employee but I cannot=20
>> >>>> envision
>> a
>> >>>> carrier offering potentially 1000s of distinct service bundles
>> >> ("pick
>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>> smaller
>> >>>> number is realistic for  the number of chains a function=20
>> >>>> instance
>> is
>> >>>> expected to participate in, even allowing for dynamic=20
>> >>>> reclassification of flows at a chain ingress to "skip a few=20
>> >>>> functions".... These are things that are fully operationalized=20
>> >>>> in OSS, have policy associated with, have been industrialized=20
>> >>>> and demonstrated to work prior to deployment. Going all=20
>> >>>> combinatorial
>> on
>> >> this will break that big time....
>> >>>>
>> >>>> So are we really discussing a function participating in more=20
>> >>>> than
>> a
>> >>>> handful of chain instances? And either a plurality of vNICs or
>> VIDs
>> >>>> being actually more than sufficient?
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> Dave
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim=20
>> >>>> (Wim)
>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> indeed
>> >>>>
>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >>>> *Date: *Wednesday 24 July 2013 15:54
>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >>>> *Subject: *AW: Service chaining architecture question
>> >>>>
>> >>>> Hi Wim,
>> >>>>
>> >>>> I think not only effectivness/scalability might be a problem but
>> >> also
>> >>>> the fact that not all applications (service bringing functions)
>> are
>> >>>> able to handle packets coming from/going to potentially=20
>> >>>> thousands
>> of
>> >>>> different VLANs at the same time. VLANs will work in certain=20
>> >>>> environments but not in all. I see the need for an information=20
>> >>>> exchange between the application and a mediation layer as well.
>> >>>> Ideally this should be as simple as possible without heavy=20
>> >>>> impact
>> on
>> >>>> the application itself (might be difficult to achieve but from=20
>> >>>> my experience it is not very likely, that there will be big=20
>> >>>> rewrites
>> of
>> >>>> existing applications in order to support the chaining).
>> >>>>
>> >>>>    regards
>> >>>>
>> >>>>       Nic
>> >>>>
>> >>>> ----------------------------------------------------------------
>> >>>> --
>> --
>> >> -
>> >>>> -
>> >>>> --
>> >>>>
>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>> (Wim)
>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Betreff:* [nsc] Service chaining architecture question
>> >>>>
>> >>>> I have a basic question with respect to the=20
>> >>>> architecture/framework
>> >> so
>> >>>> far mentioned in the drafts in NSC. I understand the meta-data=20
>> >>>> is
>> a
>> >>>> mechanism to avoid multiple re-classifications when the packet
>> >> enters
>> >>>> the NSC domain and identifies the chain of service functions.=20
>> >>>> Now
>> my
>> >>>> understanding is that the services/applications are unaware of=20
>> >>>> the meta-data and that a layer underneath should provide the=20
>> >>>> mediation and that we use a well defined interface to the
>> application/service
>> >>>> to indicate the chain. In the context of Cloud/enterprise
>> >> environment
>> >>>> I can see this work given you can use a dedicate VLAN e.g.=20
>> >>>> within
>> >> the tenant.
>> >>>> However we also try to address residential use cases for mobile
>> and
>> >>>> fixed and here this becomes more tricky afais. In the=20
>> >>>> residential environment we can't expose a VLAN per=20
>> >>>> application/service per
>> chain
>> >>>> since this would not be very effective. So I am wondering how we=20
>> >>>> envision this to work?
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> nsc mailing list
>> >>>> nsc@ietf.org
>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>> >>> _______________________________________________
>> >>> nsc mailing list
>> >>> nsc@ietf.org
>> >>>https://www.ietf.org/mailman/listinfo/nsc
>> >> _______________________________________________
>> >> nsc mailing list
>> >> nsc@ietf.org
>> >>https://www.ietf.org/mailman/listinfo/nsc
>> >
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>

From david.i.allan@ericsson.com  Wed Jul 24 18:25:54 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE621F96A7 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 18:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g+YDPaVZWj0 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 18:25:48 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40CE721F99A6 for <nsc@ietf.org>; Wed, 24 Jul 2013 18:25:48 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-ba-51f07e98a54c
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4E.69.13034.89E70F15; Thu, 25 Jul 2013 03:25:45 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 21:25:44 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAASuGAgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAIAAEtIA///E+wA=
Date: Thu, 25 Jul 2013 01:25:43 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D697E@eusaamb105.ericsson.se>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E3F7@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E3F7@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPrO7Mug+BBlO7uS2WzlO3+HjqDZPF 3ZaJTBbH9+1ns7jwdCqzA6vHiyvPmD2m/N7I6tFy5C2rx5IlP5k8zk35zhjAGsVlk5Kak1mW WqRvl8CVcfvkHOaCyZMYK6bvVGlgnFrWxcjJISFgIrFp0wN2CFtM4sK99WxdjFwcQgJHGSUe nXzFAuEsZ5Ro3raGGaSKTcBAYs//L4wgCRGBZkaJl9ceMYIkmAWCJV4tfwxmCwtYShxvfg02 VkTASuLspm6ohi5GiQtTP7GBJFgEVCVWb/4INpVXwFfiWUs3O8S6K2wSC+bvAuvmFIiW2LLi KFgDI9CB30+tYYLYJi5x68l8JojDBSSW7DnPDGGLSrx8/I8VwlaWWPJkPwtEvY7Egt0Qi5kF tCWWLXwNtVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmSwiREYZ8ck2HR3 MO55aXmIUZqDRUmcd5XemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKsnqd//P/n8ostr c6YcPl7xZFHWzUKGHZ27hVmFg/67JKX+YTU1CQic29/UFPJlVwSvTRizOE9yoWv9pKcPdi3Y 1CplKb+Oia803zb5VaRG9dFGE08RRe7INIuE8g1z3PI7Cl7vfugmM+HuKdnZXEfDXzyZsDtf 1Or0i2vBPIL/Dm9YMyFkjRJLcUaioRZzUXEiAF3jT/2BAgAA
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 01:25:54 -0000

I would prefer to think what is on the wire facilitates the forwarding of f=
rames, e.g. chain ID (analogous to VPN), perhaps an entropy shorthand to he=
lp both LB and  testabilty....and facilitates uniquely identifying the subs=
criber. (within the bounds of the art of the possible, see my last post on =
NAT). I cannot envision a need for more. And ideally I should be able to al=
ign such an approach with existing Cloud technologies.

The individual VF should be able to determine actual subscriber to a granul=
arity suitable for it's purposes and obtain the necessary profile informati=
on via a northbound interface. If you then read between the lines,  I'm all=
 for separation of concerns as much as possible ;-) and not creating depend=
encies across chain components beyond the networking level.

I also do not see a huge difference between a service chain, and any other =
flow of information across a string of processing elements. Just in one app=
lication, the packet is preserved with perhaps a bit of fondling, and in ot=
hers the content may be completely deconstructed, and repackaged into a set=
 of transactions....and what is on the wire between chain components does n=
ot remotely look like what went in the front end...

Cheers
Dave






-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P=
arker
Sent: Wednesday, July 24, 2013 5:42 PM
To: Joel M. Halpern; Linda Dunbar
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Service chaining architecture question

Thanks, all, for a lively discussion on this topic.

One thing that flavors the discussion of network service chaining is the de=
finition of "service".   It really means different things to different peop=
le.   We networking types tend to look at it as a software application or s=
oftware system composed of multiple software applications (i.e., an HTTP co=
ntent filter).   But when I interact with the business folks, especially on=
 the operator side, I hear a different notion of "service" -- something sub=
scribers pay for, government mandates, etc.   This is why, IMO, it is defen=
sible to say that the HTTP-content-filter-children is a distinct service fr=
om HTTP-content-filter-adult, even if both are realized on the same server =
by the same software application using the same global URL database.

It does sound like at least some that have chimed in do feel that both the =
general service type (i.e., HTTP content filter) and the policy set need to=
 be conveyed in some manner.    How to do this is a set of tradeoffs around=
 control plane protocol and data plane encapsulation.    Without any contro=
l plane, both types of information need to be on the wire in some form.   I=
 will assume that the policy set identity is distinct at each service insta=
nce (i.e, policy set 2 at the HTTP content filter does not imply the same s=
et of subscribers as policy set 2 at the firewall).   I will also assume th=
at the meaning and interpretation of a policy set identity is specific to t=
hat type of service and probably to the vendor that supplied the service.  =
 This is similar to when a PCRF names a PCC rulebase rather than supplying =
the full set of explicit PCC rules.    =20

The advantage of a single chain ID that can be interpreted as a sequence of=
 {service-type-instance, policy-set} is that it minimizes the per-packet en=
capsulation requirement (i.e., a single GRE key could suffice).   The disad=
vantage that has been pointed out is that global coordination of this ident=
ity is required and the number of combinations could become unwieldy.  =20

Another approach could be to have a new encapsulation that represents a sta=
ck of 2-tuples {service-ip-address, service-specific-policy-id}, or even 3-=
tuples {service-ip-address, service-type, service-specific-policy-id} where=
 the 3-tuple brings the added advantage of allowing for multiple dissimilar=
 services realized by the same server at the same server ip address.   The =
advantage of this approach is that it avoids the combinatorial explosion pr=
oblem, but it requires a larger and variable length encapsulation.

If the global chain id approach is used, a control plane protocol could be =
used to distribute the definitions of each chain (i.e, each chain is really=
 a stack of 2-tuples or 3-tuples, per description above).   =20

Thanks.

    Ron

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Wednesday, July 24, 2013 7:35 PM
To: Linda Dunbar
Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
Subject: Re: [nsc] Service chaining architecture question

I would not be surprised if we want all three of Service Chain, Service Pol=
icy, and Subscriber / user identity in the packet.
If the Chain is in the VLAN / MPLS label, then we can discuss whether the o=
ther information goes in additional ids of the same type or in a carried he=
ader.  I can construct arguments for either approach.

It may be easier to just carry the subscriber identity, and used the same m=
anagement systems to assign policies to the devices that care.  I am concer=
ned that it may not be practical to use a single policy identifier to speci=
fy which HTTP rule set to use, which Firewall rule set to use, and then whi=
ch specific policy for other user selected policy applications.

Yours,
Joel

On 7/24/13 7:30 PM, Linda Dunbar wrote:
> Joel,
>> -----Original Message-----
>>
>> Yes, having the chain ingress node mark the traffic makes good sense.
>> Having it mark the subscriber identity and the chain to be traversed=20
>> seems quite sensible.
>>
>> The difference I think I have with Ron is that he proposes to use one=20
>> identifier for both entities.
> [Linda] I hope you don't mean per subscriber identity, do you? With=20
> today's PCRF, subscribers are categorized based on their subscription=20
> types. Throughout the network, the "subscription types" dictate what=20
> service modules their corresponding traffic need to traverse through.
> Some service modules might need to examine packets deeper (i.e. look=20
> into payload) for their intended functions. They may need to extract=20
> the "HTTP header" or HTTP messages from one or multiple packets.
> That causes, as Dave said, a
>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two=20
>> MPLS labels.
> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> The subscriber identity could be some bits in the payload.
>>
>> And if the existing boxes don't know how to handle that (as seems
>> likely) then we need a proxy / support function to translate the=20
>> common protocol into whatever they used before we got something=20
>> generally usable out there.
>>
>> Yours,
>> Joel
>>
>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>> >
>> > Agree with Ron that it is better to have fewer nodes in network to
>> make subscriber-aware policy decisions.
>> >
>> > Besides, it is not uncommon for multiple subscribers to share same
>> sequence of service modules. In this environment, if the network edge=20
>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can=20
>> use Layer 2 or 3 labels to mark the traffic, the subsequent network=20
>> nodes can steer traffic to the needed service modules without looking=20
>> into "Mega data" or other higher layer fields in the data frames.
>> >
>> > This approach can make "service chain" work without making changes=20
>> > to
>> majority of existing deployed network elements.
>> >
>> > Linda
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> Jim,
>> >>
>> >> Yes, that could work, too, conceptually.   But it does require that
>> >> each coarsely-defined network service have access to a subscriber-
>> aware
>> >> policy resolution mechanism.   IMO, it is better to have fewer
>> network
>> >> elements making subscriber-aware policy decisions.
>> >
>> >
>> >>
>> >>     Ron
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>> >> To: Ron Parker
>> >> Cc: Joel M. Halpern; nsc@ietf.org
>> >> Subject: Re: [nsc] Service chaining architecture question
>> >>
>> >> Ron,
>> >> Or alternatively carry the subscriber awareness in metadata=20
>> >> thereby utilizing a single chain.
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> >> <Ron_Parker@affirmednetworks.com> wrote:
>> >>
>> >>> Joel,
>> >>>
>> >>> IMO, the primary reason for understanding the subscriber identity
>> at
>> >> a network service is to choose from a differentiated set of policies.
>> >> I think there is utility and efficiency in driving that selection
>> from
>> >> one place -- the network services classifier.     Say there were 2
>> >> groups of subscribers -- children and adults.   Let's now define 2
>> >> chains, where the chains have a business-based meaning to the
>> operator.
>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>> filter-
>> >> adult + Firewall-adult.    The referenced network services are
>> logical
>> >> and it is possible, but not required, that multiple logical network
>> >> services be located at the same IP address or FQDN.     Conveying
>> the
>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>> ID, ...)
>> >> allows the IP-addressable server that realizes these service(s) to
>> know
>> >> two things -- 1) which logical network function should be invoked
>> and 2)
>> >> which logical network function is next.
>> >>>
>> >>> Thanks.
>> >>> Ron
>> >>>
>> >>> -----Original Message-----
>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>> >>> To: Ron Parker
>> >>> Cc: nsc@ietf.org
>> >>> Subject: Re: [nsc] Service chaining architecture question
>> >>>
>> >>> Ron,
>> >>>      maybe I am missing something, but you seem to lay out very
>> nicely
>> >> the case for wanting both service chain identification and
>> separately
>> >> subscriber identification.  Then the HTTP filter can use the
>> subscriber
>> >> ID to decide which exact content filtering behavior it should apply.
>> I
>> >> would not want to fold that level of detail into the chain=20
>> >> identification.
>> >>>
>> >>> Yours,
>> >>> Joel
>> >>>
>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>> >>>> Dave,
>> >>>>
>> >>>> I agree that the number of chains is unlikely to scale to vast
>> >> numbers
>> >>>> (i.e., millions).     And I agree that it is bounded from a
>> >> practical
>> >>>> business perspective, as you point out.
>> >>>>
>> >>>> You may already be on this page, but I wanted to point out a=20
>> >>>> distinction of coarse-grained definition of a service function vs.
>> >> finer-grained
>> >>>> definition of a service function.   Consider a service function to
>> >> be
>> >>>> logical in such a way that the identity of the logical function
>> may
>> >> also
>> >>>> imply some differentiated behavior.   For example, a conceptual
>> >> function
>> >>>> is HTTP content filtering.    This conceptual function can then be
>> >>>> further instantiated at the logical level based on=20
>> >>>> differentiated policies such as content-filter-children,=20
>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
>> no
>> >> stand on opt-in vs. opt-out, Mr.
>> >>>> Cameron).   It may be that the same network element (dedicated
>> >> physical
>> >>>> box or virtual network function) realizes all 3 of the example
>> >>>> policies.   The HTTP content filtering network function is really
>> 3
>> >>>> logical network functions from the perspective of inclusion in a
>> >> service
>> >>>> chain.   Now extend this to multiple conceptual functions that
>> >> utilize
>> >>>> differentiated policies and the number of combinations will=20
>> >>>> grow,
>> at
>> >>>> least modestly.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Ron
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>> Behalf
>> >>>> Of *David Allan I
>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> Saying functions will have a problem with something that exists=20
>> >>>> as
>> a
>> >>>> potential rationale for defining something new with exactly the
>> same
>> >>>> properties and problems does not quite work for me....
>> >>>>
>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>> >> stack
>> >>>> construction and this being combined with application
>> "cooperation"
>> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>> >>>> NICs) currently exist as potential vehicles for preserving chain=20
>> >>>> context and avoiding per hop classification. Anything else will=20
>> >>>> be implemented more or less the same way and have exactly the=20
>> >>>> same
>> set
>> >>>> of scaling and application design issues...Some extra=20
>> >>>> information available on a single interface, or achieved by=20
>> >>>> mapping chain instances onto one of a plurality of interfaces....
>> >>>>
>> >>>> But to back up... I'm not a carrier employee but I cannot=20
>> >>>> envision
>> a
>> >>>> carrier offering potentially 1000s of distinct service bundles
>> >> ("pick
>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>> smaller
>> >>>> number is realistic for  the number of chains a function=20
>> >>>> instance
>> is
>> >>>> expected to participate in, even allowing for dynamic=20
>> >>>> reclassification of flows at a chain ingress to "skip a few=20
>> >>>> functions".... These are things that are fully operationalized=20
>> >>>> in OSS, have policy associated with, have been industrialized=20
>> >>>> and demonstrated to work prior to deployment. Going all=20
>> >>>> combinatorial
>> on
>> >> this will break that big time....
>> >>>>
>> >>>> So are we really discussing a function participating in more=20
>> >>>> than
>> a
>> >>>> handful of chain instances? And either a plurality of vNICs or
>> VIDs
>> >>>> being actually more than sufficient?
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>> Dave
>> >>>>
>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>> >>>> (Wim)
>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>
>> >>>> indeed
>> >>>>
>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >>>> *Date: *Wednesday 24 July 2013 15:54
>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >>>> *Subject: *AW: Service chaining architecture question
>> >>>>
>> >>>> Hi Wim,
>> >>>>
>> >>>> I think not only effectivness/scalability might be a problem but
>> >> also
>> >>>> the fact that not all applications (service bringing functions)
>> are
>> >>>> able to handle packets coming from/going to potentially=20
>> >>>> thousands
>> of
>> >>>> different VLANs at the same time. VLANs will work in certain=20
>> >>>> environments but not in all. I see the need for an information=20
>> >>>> exchange between the application and a mediation layer as well.
>> >>>> Ideally this should be as simple as possible without heavy=20
>> >>>> impact
>> on
>> >>>> the application itself (might be difficult to achieve but from=20
>> >>>> my experience it is not very likely, that there will be big=20
>> >>>> rewrites
>> of
>> >>>> existing applications in order to support the chaining).
>> >>>>
>> >>>>    regards
>> >>>>
>> >>>>       Nic
>> >>>>
>> >>>> ----------------------------------------------------------------
>> >>>> --
>> --
>> >> -
>> >>>> -
>> >>>> --
>> >>>>
>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>> (Wim)
>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>> *Betreff:* [nsc] Service chaining architecture question
>> >>>>
>> >>>> I have a basic question with respect to the=20
>> >>>> architecture/framework
>> >> so
>> >>>> far mentioned in the drafts in NSC. I understand the meta-data=20
>> >>>> is
>> a
>> >>>> mechanism to avoid multiple re-classifications when the packet
>> >> enters
>> >>>> the NSC domain and identifies the chain of service functions.=20
>> >>>> Now
>> my
>> >>>> understanding is that the services/applications are unaware of=20
>> >>>> the meta-data and that a layer underneath should provide the=20
>> >>>> mediation and that we use a well defined interface to the
>> application/service
>> >>>> to indicate the chain. In the context of Cloud/enterprise
>> >> environment
>> >>>> I can see this work given you can use a dedicate VLAN e.g.=20
>> >>>> within
>> >> the tenant.
>> >>>> However we also try to address residential use cases for mobile
>> and
>> >>>> fixed and here this becomes more tricky afais. In the=20
>> >>>> residential environment we can't expose a VLAN per=20
>> >>>> application/service per
>> chain
>> >>>> since this would not be very effective. So I am wondering how we=20
>> >>>> envision this to work?
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> nsc mailing list
>> >>>> nsc@ietf.org
>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>> >>> _______________________________________________
>> >>> nsc mailing list
>> >>> nsc@ietf.org
>> >>>https://www.ietf.org/mailman/listinfo/nsc
>> >> _______________________________________________
>> >> nsc mailing list
>> >> nsc@ietf.org
>> >>https://www.ietf.org/mailman/listinfo/nsc
>> >
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

From smkumar@cisco.com  Wed Jul 24 23:24:01 2013
Return-Path: <smkumar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057CD21F8934 for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 23:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drr0bdYx0NgF for <nsc@ietfa.amsl.com>; Wed, 24 Jul 2013 23:23:56 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B364721F93BF for <nsc@ietf.org>; Wed, 24 Jul 2013 23:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16710; q=dns/txt; s=iport; t=1374733435; x=1375943035; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=d7YqAL71iaWPEKQkwS06J/ii/t7lLIvKneRQ0Y2/bQY=; b=NWcvjh2JleL8vko95h3VjJHFOHZ+kQD2dagjR/ehf2dSrxNdT5bmqGOB HdxY9yi1WWTj4qE5w0/9lFImrQGwTNDbeillN00YC0YWcG5U8Mzlvxo// mP3JlKitdD1flZcv98gFR8wQXYGnCc8Xzz4TL+mOT2X8HUFKayGJX1Quh 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFACrD8FGtJXG9/2dsb2JhbABRCYMGNVC9XoEYFnSCJAEBAQQBAQE3LQcLDAYBCBEBAgEBAQEKAxEJLgsUAwYIAgQBDQUIiAgMuXcEjkWBBQIGKwcCBIMMbgOUCI4KhxqDFIIq
X-IronPort-AV: E=Sophos;i="4.89,741,1367971200"; d="scan'208";a="239022700"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2013 06:23:54 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6P6NrgO031531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 06:23:53 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 01:23:53 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAABPYAgADJeQA=
Date: Thu, 25 Jul 2013 06:23:52 +0000
Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF363D@xmb-aln-x09.cisco.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B4D3C3@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.21.150.117]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <22C68A33F3785F4E9BC7A9F73540C9A7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 06:24:01 -0000

On 7/25/13 5:22 AM, "Linda Dunbar" <linda.dunbar@huawei.com> wrote:

>Joel,=20
>
>Agree with what you said and your concern. I think that Service Chain
>from subscriber perspective is different from service chain from network
>traffic steering perspective. The information to be passed among service
>modules for specific flows is at another dimension.
>
>
>From user's (or subscriber) perspective, the service chain is a sequence
>of service functions, such as Chain#1 {s1, s4, s6}, Chain#2{s4, s7}
>applied to the user's (or subscriber's) traffic.
>
>
>From the traffic steering perspective, a Service Chain guarantees that
>specific data flows go through a specific sequence of service modules at
>designated points along the flow paths in the network. Those flows can be
>aggregated traffic among multiple subscribers.
>
>From traffic steering point of view, one service chain consists of:
>-	Identifier
>-	{Steering point List}
>-	Steering Point #1, {list of Service Modules}
>-	Steering Point #2, {list of Service Modules}
>-	...

=3D=3D
>Two service chains with the same sequence of service modules but
>different steering points should be considered as two different service
>chains from traffic steering point of view.
=3D=3D
SK> That is the definition of "Service Path" in NSH - actual forwarding
path; you get two *service paths* for the same *service chain*, in your
example. Service Chain exists in the control plane while Service Path
exists in the data plane, so to speak.

Surendra.

>
>Linda
>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Wednesday, July 24, 2013 6:35 PM
>> To: Linda Dunbar
>> Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
>> Subject: Re: [nsc] Service chaining architecture question
>>=20
>> I would not be surprised if we want all three of
>> Service Chain,
>> Service Policy, and
>> Subscriber / user identity
>> in the packet.
>> If the Chain is in the VLAN / MPLS label, then we can discuss whether
>> the other information goes in additional ids of the same type or in a
>> carried header.  I can construct arguments for either approach.
>>=20
>> It may be easier to just carry the subscriber identity, and used the
>> same management systems to assign policies to the devices that care.  I
>> am concerned that it may not be practical to use a single policy
>> identifier to specify which HTTP rule set to use, which Firewall rule
>> set to use, and then which specific policy for other user selected
>> policy applications.
>>=20
>> Yours,
>> Joel
>>=20
>> On 7/24/13 7:30 PM, Linda Dunbar wrote:
>> > Joel,
>> >> -----Original Message-----
>> >>
>> >> Yes, having the chain ingress node mark the traffic makes good sense.
>> >> Having it mark the subscriber identity and the chain to be traversed
>> >> seems quite sensible.
>> >>
>> >> The difference I think I have with Ron is that he proposes to use
>> one
>> >> identifier for both entities.
>> > [Linda] I hope you don't mean per subscriber identity, do you? With
>> > today's PCRF, subscribers are categorized based on their subscription
>> > types. Throughout the network, the "subscription types" dictate what
>> > service modules their corresponding traffic need to traverse through.
>> > Some service modules might need to examine packets deeper (i.e. look
>> > into payload) for their intended functions. They may need to extract
>> the
>> > "HTTP header" or HTTP messages from one or multiple packets.
>> > That causes, as Dave said, a
>> >> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
>> MPLS
>> >> labels.
>> > [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>> > The subscriber identity could be some bits in the payload.
>> >>
>> >> And if the existing boxes don't know how to handle that (as seems
>> >> likely) then we need a proxy / support function to translate the
>> common
>> >> protocol into whatever they used before we got something generally
>> >> usable out there.
>> >>
>> >> Yours,
>> >> Joel
>> >>
>> >> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>> >> >
>> >> > Agree with Ron that it is better to have fewer nodes in network to
>> >> make subscriber-aware policy decisions.
>> >> >
>> >> > Besides, it is not uncommon for multiple subscribers to share same
>> >> sequence of service modules. In this environment, if the network
>> edge
>> >> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
>> use
>> >> Layer 2 or 3 labels to mark the traffic, the subsequent network
>> nodes
>> >> can steer traffic to the needed service modules without looking into
>> >> "Mega data" or other higher layer fields in the data frames.
>> >> >
>> >> > This approach can make "service chain" work without making changes
>> to
>> >> majority of existing deployed network elements.
>> >> >
>> >> > Linda
>> >> >
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> Jim,
>> >> >>
>> >> >> Yes, that could work, too, conceptually.   But it does require
>> that
>> >> >> each coarsely-defined network service have access to a
>> subscriber-
>> >> aware
>> >> >> policy resolution mechanism.   IMO, it is better to have fewer
>> >> network
>> >> >> elements making subscriber-aware policy decisions.
>> >> >
>> >> >
>> >> >>
>> >> >>     Ron
>> >> >>
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >> >> Sent: Wednesday, July 24, 2013 6:17 PM
>> >> >> To: Ron Parker
>> >> >> Cc: Joel M. Halpern; nsc@ietf.org
>> >> >> Subject: Re: [nsc] Service chaining architecture question
>> >> >>
>> >> >> Ron,
>> >> >> Or alternatively carry the subscriber awareness in metadata
>> thereby
>> >> >> utilizing a single chain.
>> >> >>
>> >> >> Sent from my iPhone
>> >> >>
>> >> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> >> >> <Ron_Parker@affirmednetworks.com> wrote:
>> >> >>
>> >> >>> Joel,
>> >> >>>
>> >> >>> IMO, the primary reason for understanding the subscriber
>> identity
>> >> at
>> >> >> a network service is to choose from a differentiated set of
>> policies.
>> >> >> I think there is utility and efficiency in driving that selection
>> >> from
>> >> >> one place -- the network services classifier.     Say there were
>> 2
>> >> >> groups of subscribers -- children and adults.   Let's now define
>> 2
>> >> >> chains, where the chains have a business-based meaning to the
>> >> operator.
>> >> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP=
-
>> >> filter-
>> >> >> adult + Firewall-adult.    The referenced network services are
>> >> logical
>> >> >> and it is possible, but not required, that multiple logical
>> network
>> >> >> services be located at the same IP address or FQDN.     Conveying
>> >> the
>> >> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>> >> ID, ...)
>> >> >> allows the IP-addressable server that realizes these service(s)
>> to
>> >> know
>> >> >> two things -- 1) which logical network function should be invoked
>> >> and 2)
>> >> >> which logical network function is next.
>> >> >>>
>> >> >>> Thanks.
>> >> >>> Ron
>> >> >>>
>> >> >>> -----Original Message-----
>> >> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> >> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>> >> >>> To: Ron Parker
>> >> >>> Cc: nsc@ietf.org
>> >> >>> Subject: Re: [nsc] Service chaining architecture question
>> >> >>>
>> >> >>> Ron,
>> >> >>>      maybe I am missing something, but you seem to lay out very
>> >> nicely
>> >> >> the case for wanting both service chain identification and
>> >> separately
>> >> >> subscriber identification.  Then the HTTP filter can use the
>> >> subscriber
>> >> >> ID to decide which exact content filtering behavior it should
>> apply.
>> >> I
>> >> >> would not want to fold that level of detail into the chain
>> >> >> identification.
>> >> >>>
>> >> >>> Yours,
>> >> >>> Joel
>> >> >>>
>> >> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>> >> >>>> Dave,
>> >> >>>>
>> >> >>>> I agree that the number of chains is unlikely to scale to vast
>> >> >> numbers
>> >> >>>> (i.e., millions).     And I agree that it is bounded from a
>> >> >> practical
>> >> >>>> business perspective, as you point out.
>> >> >>>>
>> >> >>>> You may already be on this page, but I wanted to point out a
>> >> >>>> distinction of coarse-grained definition of a service function
>> vs.
>> >> >> finer-grained
>> >> >>>> definition of a service function.   Consider a service function
>> to
>> >> >> be
>> >> >>>> logical in such a way that the identity of the logical function
>> >> may
>> >> >> also
>> >> >>>> imply some differentiated behavior.   For example, a conceptual
>> >> >> function
>> >> >>>> is HTTP content filtering.    This conceptual function can then
>> be
>> >> >>>> further instantiated at the logical level based on
>> differentiated
>> >> >>>> policies such as content-filter-children,
>> >> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
>> taking
>> >> no
>> >> >> stand on opt-in vs. opt-out, Mr.
>> >> >>>> Cameron).   It may be that the same network element (dedicated
>> >> >> physical
>> >> >>>> box or virtual network function) realizes all 3 of the example
>> >> >>>> policies.   The HTTP content filtering network function is
>> really
>> >> 3
>> >> >>>> logical network functions from the perspective of inclusion in
>> a
>> >> >> service
>> >> >>>> chain.   Now extend this to multiple conceptual functions that
>> >> >> utilize
>> >> >>>> differentiated policies and the number of combinations will
>> grow,
>> >> at
>> >> >>>> least modestly.
>> >> >>>>
>> >> >>>> Thanks,
>> >> >>>>
>> >> >>>> Ron
>> >> >>>>
>> >> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>> >> Behalf
>> >> >>>> Of *David Allan I
>> >> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >> >>>>
>> >> >>>> Saying functions will have a problem with something that exists
>> as
>> >> a
>> >> >>>> potential rationale for defining something new with exactly the
>> >> same
>> >> >>>> properties and problems does not quite work for me....
>> >> >>>>
>> >> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>> >> >> stack
>> >> >>>> construction and this being combined with application
>> >> "cooperation"
>> >> >>>> to preserve pairwise mappings of either VID/NIC tuples or
>> simply
>> >> >>>> NICs) currently exist as potential vehicles for preserving
>> chain
>> >> >>>> context and avoiding per hop classification. Anything else will
>> be
>> >> >>>> implemented more or less the same way and have exactly the same
>> >> set
>> >> >>>> of scaling and application design issues...Some extra
>> information
>> >> >>>> available on a single interface, or achieved by mapping chain
>> >> >>>> instances onto one of a plurality of interfaces....
>> >> >>>>
>> >> >>>> But to back up... I'm not a carrier employee but I cannot
>> envision
>> >> a
>> >> >>>> carrier offering potentially 1000s of distinct service bundles
>> >> >> ("pick
>> >> >>>> 53 from column A and 49 from column B"). So I suspect a much
>> >> smaller
>> >> >>>> number is realistic for  the number of chains a function
>> instance
>> >> is
>> >> >>>> expected to participate in, even allowing for dynamic
>> >> >>>> reclassification of flows at a chain ingress to "skip a few
>> >> >>>> functions".... These are things that are fully operationalized
>> in
>> >> >>>> OSS, have policy associated with, have been industrialized and
>> >> >>>> demonstrated to work prior to deployment. Going all
>> combinatorial
>> >> on
>> >> >> this will break that big time....
>> >> >>>>
>> >> >>>> So are we really discussing a function participating in more
>> than
>> >> a
>> >> >>>> handful of chain instances? And either a plurality of vNICs or
>> >> VIDs
>> >> >>>> being actually more than sufficient?
>> >> >>>>
>> >> >>>> Thanks
>> >> >>>>
>> >> >>>> Dave
>> >> >>>>
>> >> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>> (Wim)
>> >> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>> >> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >> >>>>
>> >> >>>> indeed
>> >> >>>>
>> >> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >> >>>> *Date: *Wednesday 24 July 2013 15:54
>> >> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>> >> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >> >>>> *Subject: *AW: Service chaining architecture question
>> >> >>>>
>> >> >>>> Hi Wim,
>> >> >>>>
>> >> >>>> I think not only effectivness/scalability might be a problem
>> but
>> >> >> also
>> >> >>>> the fact that not all applications (service bringing functions)
>> >> are
>> >> >>>> able to handle packets coming from/going to potentially
>> thousands
>> >> of
>> >> >>>> different VLANs at the same time. VLANs will work in certain
>> >> >>>> environments but not in all. I see the need for an information
>> >> >>>> exchange between the application and a mediation layer as well.
>> >> >>>> Ideally this should be as simple as possible without heavy
>> impact
>> >> on
>> >> >>>> the application itself (might be difficult to achieve but from
>> my
>> >> >>>> experience it is not very likely, that there will be big
>> rewrites
>> >> of
>> >> >>>> existing applications in order to support the chaining).
>> >> >>>>
>> >> >>>>    regards
>> >> >>>>
>> >> >>>>       Nic
>> >> >>>>
>> >> >>>> ---------------------------------------------------------------
>> ---
>> >> --
>> >> >> -
>> >> >>>> -
>> >> >>>> --
>> >> >>>>
>> >> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>> >> (Wim)
>> >> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >> >>>> *Betreff:* [nsc] Service chaining architecture question
>> >> >>>>
>> >> >>>> I have a basic question with respect to the
>> architecture/framework
>> >> >> so
>> >> >>>> far mentioned in the drafts in NSC. I understand the meta-data
>> is
>> >> a
>> >> >>>> mechanism to avoid multiple re-classifications when the packet
>> >> >> enters
>> >> >>>> the NSC domain and identifies the chain of service functions.
>> Now
>> >> my
>> >> >>>> understanding is that the services/applications are unaware of
>> the
>> >> >>>> meta-data and that a layer underneath should provide the
>> mediation
>> >> >>>> and that we use a well defined interface to the
>> >> application/service
>> >> >>>> to indicate the chain. In the context of Cloud/enterprise
>> >> >> environment
>> >> >>>> I can see this work given you can use a dedicate VLAN e.g.
>> within
>> >> >> the tenant.
>> >> >>>> However we also try to address residential use cases for mobile
>> >> and
>> >> >>>> fixed and here this becomes more tricky afais. In the
>> residential
>> >> >>>> environment we can't expose a VLAN per application/service per
>> >> chain
>> >> >>>> since this would not be very effective. So I am wondering how
>> we
>> >> >>>> envision this to work?
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> _______________________________________________
>> >> >>>> nsc mailing list
>> >> >>>> nsc@ietf.org
>> >> >>>>https://www.ietf.org/mailman/listinfo/nsc
>> >> >>> _______________________________________________
>> >> >>> nsc mailing list
>> >> >>> nsc@ietf.org
>> >> >>>https://www.ietf.org/mailman/listinfo/nsc
>> >> >> _______________________________________________
>> >> >> nsc mailing list
>> >> >> nsc@ietf.org
>> >> >>https://www.ietf.org/mailman/listinfo/nsc
>> >> >
>> >
>> >
>> > _______________________________________________
>> > nsc mailing list
>> > nsc@ietf.org
>> > https://www.ietf.org/mailman/listinfo/nsc
>> >
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From mohamed.boucadair@orange.com  Thu Jul 25 00:46:30 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED82C21F9A15 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 00:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPFL+P+QtxjT for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 00:46:26 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 497DC21F9A2D for <nsc@ietf.org>; Thu, 25 Jul 2013 00:46:26 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A965418C904; Thu, 25 Jul 2013 09:46:25 +0200 (CEST)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 85A6D238077; Thu, 25 Jul 2013 09:46:25 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 25 Jul 2013 09:46:25 +0200
From: <mohamed.boucadair@orange.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Date: Thu, 25 Jul 2013 09:46:23 +0200
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: Ac6IxnR6BN8vdz7eTFmXIwn+MQnsSwAQzmtw
Message-ID: <94C682931C08B048B7A8645303FDC9F36EE4BA5A3F@PUEXCB1B.nanterre.francetelecom.fr>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com>
In-Reply-To: <51F064A2.3060601@joelhalpern.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.25.65424
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 07:46:31 -0000

Hi Joel,

I'm not sure there is a need for such granularity (i.e., individual rules l=
evel) which may lead to unjustified complications. Some of the policies can=
 be configured off-band without having the need to carry it the packet itse=
lf.

If instead distinct (few) profiles are configured in a device, this can be =
considered as distinct instances of the same function but can be distinguis=
hed using distinct identifiers. FWIW, we have touched in this point at: htt=
p://tools.ietf.org/html/draft-boucadair-network-function-chaining-02#sectio=
n-6.2

Cheers,
Med

>-----Message d'origine-----
>De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Joel
>M. Halpern
>Envoy=E9 : jeudi 25 juillet 2013 01:35
>=C0 : Linda Dunbar
>Cc : nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
>Objet : Re: [nsc] Service chaining architecture question
>
>I would not be surprised if we want all three of
>Service Chain,
>Service Policy, and
>Subscriber / user identity
>in the packet.
>If the Chain is in the VLAN / MPLS label, then we can discuss whether
>the other information goes in additional ids of the same type or in a
>carried header.  I can construct arguments for either approach.
>
>It may be easier to just carry the subscriber identity, and used the
>same management systems to assign policies to the devices that care.  I
>am concerned that it may not be practical to use a single policy
>identifier to specify which HTTP rule set to use, which Firewall rule
>set to use, and then which specific policy for other user selected
>policy applications.
>
>Yours,
>Joel
>
>On 7/24/13 7:30 PM, Linda Dunbar wrote:
>> Joel,
>>> -----Original Message-----
>>>
>>> Yes, having the chain ingress node mark the traffic makes good sense.
>>> Having it mark the subscriber identity and the chain to be traversed
>>> seems quite sensible.
>>>
>>> The difference I think I have with Ron is that he proposes to use one
>>> identifier for both entities.
>> [Linda] I hope you don't mean per subscriber identity, do you? With
>> today's PCRF, subscribers are categorized based on their subscription
>> types. Throughout the network, the "subscription types" dictate what
>> service modules their corresponding traffic need to traverse through.
>> Some service modules might need to examine packets deeper (i.e. look
>> into payload) for their intended functions. They may need to extract the
>> "HTTP header" or HTTP messages from one or multiple packets.
>> That causes, as Dave said, a
>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two MPLS
>>> labels.
>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>> The subscriber identity could be some bits in the payload.
>>>
>>> And if the existing boxes don't know how to handle that (as seems
>>> likely) then we need a proxy / support function to translate the common
>>> protocol into whatever they used before we got something generally
>>> usable out there.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>>> >
>>> > Agree with Ron that it is better to have fewer nodes in network to
>>> make subscriber-aware policy decisions.
>>> >
>>> > Besides, it is not uncommon for multiple subscribers to share same
>>> sequence of service modules. In this environment, if the network edge
>>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can use
>>> Layer 2 or 3 labels to mark the traffic, the subsequent network nodes
>>> can steer traffic to the needed service modules without looking into
>>> "Mega data" or other higher layer fields in the data frames.
>>> >
>>> > This approach can make "service chain" work without making changes to
>>> majority of existing deployed network elements.
>>> >
>>> > Linda
>>> >
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> Jim,
>>> >>
>>> >> Yes, that could work, too, conceptually.   But it does require that
>>> >> each coarsely-defined network service have access to a subscriber-
>>> aware
>>> >> policy resolution mechanism.   IMO, it is better to have fewer
>>> network
>>> >> elements making subscriber-aware policy decisions.
>>> >
>>> >
>>> >>
>>> >>     Ron
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>>> >> To: Ron Parker
>>> >> Cc: Joel M. Halpern; nsc@ietf.org
>>> >> Subject: Re: [nsc] Service chaining architecture question
>>> >>
>>> >> Ron,
>>> >> Or alternatively carry the subscriber awareness in metadata thereby
>>> >> utilizing a single chain.
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>>> >> <Ron_Parker@affirmednetworks.com> wrote:
>>> >>
>>> >>> Joel,
>>> >>>
>>> >>> IMO, the primary reason for understanding the subscriber identity
>>> at
>>> >> a network service is to choose from a differentiated set of policies=
.
>>> >> I think there is utility and efficiency in driving that selection
>>> from
>>> >> one place -- the network services classifier.     Say there were 2
>>> >> groups of subscribers -- children and adults.   Let's now define 2
>>> >> chains, where the chains have a business-based meaning to the
>>> operator.
>>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>>> filter-
>>> >> adult + Firewall-adult.    The referenced network services are
>>> logical
>>> >> and it is possible, but not required, that multiple logical network
>>> >> services be located at the same IP address or FQDN.     Conveying
>>> the
>>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>>> ID, ...)
>>> >> allows the IP-addressable server that realizes these service(s) to
>>> know
>>> >> two things -- 1) which logical network function should be invoked
>>> and 2)
>>> >> which logical network function is next.
>>> >>>
>>> >>> Thanks.
>>> >>> Ron
>>> >>>
>>> >>> -----Original Message-----
>>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>>> >>> To: Ron Parker
>>> >>> Cc: nsc@ietf.org
>>> >>> Subject: Re: [nsc] Service chaining architecture question
>>> >>>
>>> >>> Ron,
>>> >>>      maybe I am missing something, but you seem to lay out very
>>> nicely
>>> >> the case for wanting both service chain identification and
>>> separately
>>> >> subscriber identification.  Then the HTTP filter can use the
>>> subscriber
>>> >> ID to decide which exact content filtering behavior it should apply.
>>> I
>>> >> would not want to fold that level of detail into the chain
>>> >> identification.
>>> >>>
>>> >>> Yours,
>>> >>> Joel
>>> >>>
>>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>> >>>> Dave,
>>> >>>>
>>> >>>> I agree that the number of chains is unlikely to scale to vast
>>> >> numbers
>>> >>>> (i.e., millions).     And I agree that it is bounded from a
>>> >> practical
>>> >>>> business perspective, as you point out.
>>> >>>>
>>> >>>> You may already be on this page, but I wanted to point out a
>>> >>>> distinction of coarse-grained definition of a service function vs.
>>> >> finer-grained
>>> >>>> definition of a service function.   Consider a service function to
>>> >> be
>>> >>>> logical in such a way that the identity of the logical function
>>> may
>>> >> also
>>> >>>> imply some differentiated behavior.   For example, a conceptual
>>> >> function
>>> >>>> is HTTP content filtering.    This conceptual function can then be
>>> >>>> further instantiated at the logical level based on differentiated
>>> >>>> policies such as content-filter-children,
>>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
>>> no
>>> >> stand on opt-in vs. opt-out, Mr.
>>> >>>> Cameron).   It may be that the same network element (dedicated
>>> >> physical
>>> >>>> box or virtual network function) realizes all 3 of the example
>>> >>>> policies.   The HTTP content filtering network function is really
>>> 3
>>> >>>> logical network functions from the perspective of inclusion in a
>>> >> service
>>> >>>> chain.   Now extend this to multiple conceptual functions that
>>> >> utilize
>>> >>>> differentiated policies and the number of combinations will grow,
>>> at
>>> >>>> least modestly.
>>> >>>>
>>> >>>> Thanks,
>>> >>>>
>>> >>>> Ron
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>>> Behalf
>>> >>>> Of *David Allan I
>>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> Saying functions will have a problem with something that exists as
>>> a
>>> >>>> potential rationale for defining something new with exactly the
>>> same
>>> >>>> properties and problems does not quite work for me....
>>> >>>>
>>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>>> >> stack
>>> >>>> construction and this being combined with application
>>> "cooperation"
>>> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>>> >>>> NICs) currently exist as potential vehicles for preserving chain
>>> >>>> context and avoiding per hop classification. Anything else will be
>>> >>>> implemented more or less the same way and have exactly the same
>>> set
>>> >>>> of scaling and application design issues...Some extra information
>>> >>>> available on a single interface, or achieved by mapping chain
>>> >>>> instances onto one of a plurality of interfaces....
>>> >>>>
>>> >>>> But to back up... I'm not a carrier employee but I cannot envision
>>> a
>>> >>>> carrier offering potentially 1000s of distinct service bundles
>>> >> ("pick
>>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>>> smaller
>>> >>>> number is realistic for  the number of chains a function instance
>>> is
>>> >>>> expected to participate in, even allowing for dynamic
>>> >>>> reclassification of flows at a chain ingress to "skip a few
>>> >>>> functions".... These are things that are fully operationalized in
>>> >>>> OSS, have policy associated with, have been industrialized and
>>> >>>> demonstrated to work prior to deployment. Going all combinatorial
>>> on
>>> >> this will break that big time....
>>> >>>>
>>> >>>> So are we really discussing a function participating in more than
>>> a
>>> >>>> handful of chain instances? And either a plurality of vNICs or
>>> VIDs
>>> >>>> being actually more than sufficient?
>>> >>>>
>>> >>>> Thanks
>>> >>>>
>>> >>>> Dave
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> indeed
>>> >>>>
>>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>> >>>> *Date: *Wednesday 24 July 2013 15:54
>>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>> >>>> *Subject: *AW: Service chaining architecture question
>>> >>>>
>>> >>>> Hi Wim,
>>> >>>>
>>> >>>> I think not only effectivness/scalability might be a problem but
>>> >> also
>>> >>>> the fact that not all applications (service bringing functions)
>>> are
>>> >>>> able to handle packets coming from/going to potentially thousands
>>> of
>>> >>>> different VLANs at the same time. VLANs will work in certain
>>> >>>> environments but not in all. I see the need for an information
>>> >>>> exchange between the application and a mediation layer as well.
>>> >>>> Ideally this should be as simple as possible without heavy impact
>>> on
>>> >>>> the application itself (might be difficult to achieve but from my
>>> >>>> experience it is not very likely, that there will be big rewrites
>>> of
>>> >>>> existing applications in order to support the chaining).
>>> >>>>
>>> >>>>    regards
>>> >>>>
>>> >>>>       Nic
>>> >>>>
>>> >>>> ------------------------------------------------------------------
>>> --
>>> >> -
>>> >>>> -
>>> >>>> --
>>> >>>>
>>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>>> (Wim)
>>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Betreff:* [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> I have a basic question with respect to the architecture/framework
>>> >> so
>>> >>>> far mentioned in the drafts in NSC. I understand the meta-data is
>>> a
>>> >>>> mechanism to avoid multiple re-classifications when the packet
>>> >> enters
>>> >>>> the NSC domain and identifies the chain of service functions. Now
>>> my
>>> >>>> understanding is that the services/applications are unaware of the
>>> >>>> meta-data and that a layer underneath should provide the mediation
>>> >>>> and that we use a well defined interface to the
>>> application/service
>>> >>>> to indicate the chain. In the context of Cloud/enterprise
>>> >> environment
>>> >>>> I can see this work given you can use a dedicate VLAN e.g. within
>>> >> the tenant.
>>> >>>> However we also try to address residential use cases for mobile
>>> and
>>> >>>> fixed and here this becomes more tricky afais. In the residential
>>> >>>> environment we can't expose a VLAN per application/service per
>>> chain
>>> >>>> since this would not be very effective. So I am wondering how we
>>> >>>> envision this to work?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> nsc mailing list
>>> >>>> nsc@ietf.org
>>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>>> >>> _______________________________________________
>>> >>> nsc mailing list
>>> >>> nsc@ietf.org
>>> >>>https://www.ietf.org/mailman/listinfo/nsc
>>> >> _______________________________________________
>>> >> nsc mailing list
>>> >> nsc@ietf.org
>>> >>https://www.ietf.org/mailman/listinfo/nsc
>>> >
>>
>>
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc

From linda.dunbar@huawei.com  Thu Jul 25 09:01:47 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1F421F9A44 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 09:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQFwPDPPR10g for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 09:01:28 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2021F9928 for <nsc@ietf.org>; Thu, 25 Jul 2013 09:01:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVK62817; Thu, 25 Jul 2013 16:01:24 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 17:00:22 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 17:01:21 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Thu, 25 Jul 2013 09:01:15 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAPrusAAA6WcXD//5GVAIAAckyA////8wD//9g2oA==
Date: Thu, 25 Jul 2013 16:01:15 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4D707@dfweml509-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F645B4D3C3@dfweml509-mbx.china.huawei.com> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF363D@xmb-aln-x09.cisco.com>
In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF363D@xmb-aln-x09.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.128.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 16:01:47 -0000

Surendra,=20

Thank you very much for the clarification. I like this distinction: Service=
 Path & Service Chain.=20

Is "Service Chain Path" more accurate?=20
"Service path" can be easily interpreted as Network Service Path, like the =
path along a sequence of network nodes that data packets traverse. They are=
 so much like today's network.=20

Is NSC also try to re-characterize today's network using a new term?=20
I can see that all today's network elements can be re-characterized as vari=
ous service modules, like L2/L3 forwarding service, GRE encapsulating servi=
ce, pushing/popping MPLS label  service, etc, but is it necessary to do so?=
=20
=20

Linda

=20

> -----Original Message-----
> SK> That is the definition of "Service Path" in NSH - actual forwarding
> path; you get two *service paths* for the same *service chain*, in your
> example. Service Chain exists in the control plane while Service Path
> exists in the data plane, so to speak.
>=20
> Surendra.
>=20
> >
> >Linda
> >
> >> -----Original Message-----
> >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> Sent: Wednesday, July 24, 2013 6:35 PM
> >> To: Linda Dunbar
> >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
> >> Subject: Re: [nsc] Service chaining architecture question
> >>
> >> I would not be surprised if we want all three of
> >> Service Chain,
> >> Service Policy, and
> >> Subscriber / user identity
> >> in the packet.
> >> If the Chain is in the VLAN / MPLS label, then we can discuss
> whether
> >> the other information goes in additional ids of the same type or in
> a
> >> carried header.  I can construct arguments for either approach.
> >>
> >> It may be easier to just carry the subscriber identity, and used the
> >> same management systems to assign policies to the devices that care.
> I
> >> am concerned that it may not be practical to use a single policy
> >> identifier to specify which HTTP rule set to use, which Firewall
> rule
> >> set to use, and then which specific policy for other user selected
> >> policy applications.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 7/24/13 7:30 PM, Linda Dunbar wrote:
> >> > Joel,
> >> >> -----Original Message-----
> >> >>
> >> >> Yes, having the chain ingress node mark the traffic makes good
> sense.
> >> >> Having it mark the subscriber identity and the chain to be
> traversed
> >> >> seems quite sensible.
> >> >>
> >> >> The difference I think I have with Ron is that he proposes to use
> >> one
> >> >> identifier for both entities.
> >> > [Linda] I hope you don't mean per subscriber identity, do you?
> With
> >> > today's PCRF, subscribers are categorized based on their
> subscription
> >> > types. Throughout the network, the "subscription types" dictate
> what
> >> > service modules their corresponding traffic need to traverse
> through.
> >> > Some service modules might need to examine packets deeper (i.e.
> look
> >> > into payload) for their intended functions. They may need to
> extract
> >> the
> >> > "HTTP header" or HTTP messages from one or multiple packets.
> >> > That causes, as Dave said, a
> >> >> combinatorial explosion.  Rather, use two fields.  Two VLANs.
> Two
> >> MPLS
> >> >> labels.
> >> > [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> >> > The subscriber identity could be some bits in the payload.
> >> >>
> >> >> And if the existing boxes don't know how to handle that (as seems
> >> >> likely) then we need a proxy / support function to translate the
> >> common
> >> >> protocol into whatever they used before we got something
> generally
> >> >> usable out there.
> >> >>
> >> >> Yours,
> >> >> Joel
> >> >>
> >> >> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >> >> >
> >> >> > Agree with Ron that it is better to have fewer nodes in network
> to
> >> >> make subscriber-aware policy decisions.
> >> >> >
> >> >> > Besides, it is not uncommon for multiple subscribers to share
> same
> >> >> sequence of service modules. In this environment, if the network
> >> edge
> >> >> nodes, such as Broadband Network Gateway or Cell Site Gateway,
> can
> >> use
> >> >> Layer 2 or 3 labels to mark the traffic, the subsequent network
> >> nodes
> >> >> can steer traffic to the needed service modules without looking
> into
> >> >> "Mega data" or other higher layer fields in the data frames.
> >> >> >
> >> >> > This approach can make "service chain" work without making
> changes
> >> to
> >> >> majority of existing deployed network elements.
> >> >> >
> >> >> > Linda
> >> >> >
> >> >> >
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> Jim,
> >> >> >>
> >> >> >> Yes, that could work, too, conceptually.   But it does require
> >> that
> >> >> >> each coarsely-defined network service have access to a
> >> subscriber-
> >> >> aware
> >> >> >> policy resolution mechanism.   IMO, it is better to have fewer
> >> >> network
> >> >> >> elements making subscriber-aware policy decisions.
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>     Ron
> >> >> >>
> >> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >> >> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >> >> >> To: Ron Parker
> >> >> >> Cc: Joel M. Halpern; nsc@ietf.org
> >> >> >> Subject: Re: [nsc] Service chaining architecture question
> >> >> >>
> >> >> >> Ron,
> >> >> >> Or alternatively carry the subscriber awareness in metadata
> >> thereby
> >> >> >> utilizing a single chain.
> >> >> >>
> >> >> >> Sent from my iPhone
> >> >> >>
> >> >> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >> >> >> <Ron_Parker@affirmednetworks.com> wrote:
> >> >> >>
> >> >> >>> Joel,
> >> >> >>>
> >> >> >>> IMO, the primary reason for understanding the subscriber
> >> identity
> >> >> at
> >> >> >> a network service is to choose from a differentiated set of
> >> policies.
> >> >> >> I think there is utility and efficiency in driving that
> selection
> >> >> from
> >> >> >> one place -- the network services classifier.     Say there
> were
> >> 2
> >> >> >> groups of subscribers -- children and adults.   Let's now
> define
> >> 2
> >> >> >> chains, where the chains have a business-based meaning to the
> >> >> operator.
> >> >> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D
> HTTP-
> >> >> filter-
> >> >> >> adult + Firewall-adult.    The referenced network services are
> >> >> logical
> >> >> >> and it is possible, but not required, that multiple logical
> >> network
> >> >> >> services be located at the same IP address or FQDN.
> Conveying
> >> >> the
> >> >> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> >> >> ID, ...)
> >> >> >> allows the IP-addressable server that realizes these service(s)
> >> to
> >> >> know
> >> >> >> two things -- 1) which logical network function should be
> invoked
> >> >> and 2)
> >> >> >> which logical network function is next.
> >> >> >>>
> >> >> >>> Thanks.
> >> >> >>> Ron
> >> >> >>>
> >> >> >>> -----Original Message-----
> >> >> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> >> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> >> >> >>> To: Ron Parker
> >> >> >>> Cc: nsc@ietf.org
> >> >> >>> Subject: Re: [nsc] Service chaining architecture question
> >> >> >>>
> >> >> >>> Ron,
> >> >> >>>      maybe I am missing something, but you seem to lay out
> very
> >> >> nicely
> >> >> >> the case for wanting both service chain identification and
> >> >> separately
> >> >> >> subscriber identification.  Then the HTTP filter can use the
> >> >> subscriber
> >> >> >> ID to decide which exact content filtering behavior it should
> >> apply.
> >> >> I
> >> >> >> would not want to fold that level of detail into the chain
> >> >> >> identification.
> >> >> >>>
> >> >> >>> Yours,
> >> >> >>> Joel
> >> >> >>>
> >> >> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >> >> >>>> Dave,
> >> >> >>>>
> >> >> >>>> I agree that the number of chains is unlikely to scale to
> vast
> >> >> >> numbers
> >> >> >>>> (i.e., millions).     And I agree that it is bounded from a
> >> >> >> practical
> >> >> >>>> business perspective, as you point out.
> >> >> >>>>
> >> >> >>>> You may already be on this page, but I wanted to point out a
> >> >> >>>> distinction of coarse-grained definition of a service
> function
> >> vs.
> >> >> >> finer-grained
> >> >> >>>> definition of a service function.   Consider a service
> function
> >> to
> >> >> >> be
> >> >> >>>> logical in such a way that the identity of the logical
> function
> >> >> may
> >> >> >> also
> >> >> >>>> imply some differentiated behavior.   For example, a
> conceptual
> >> >> >> function
> >> >> >>>> is HTTP content filtering.    This conceptual function can
> then
> >> be
> >> >> >>>> further instantiated at the logical level based on
> >> differentiated
> >> >> >>>> policies such as content-filter-children,
> >> >> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
> >> taking
> >> >> no
> >> >> >> stand on opt-in vs. opt-out, Mr.
> >> >> >>>> Cameron).   It may be that the same network element
> (dedicated
> >> >> >> physical
> >> >> >>>> box or virtual network function) realizes all 3 of the
> example
> >> >> >>>> policies.   The HTTP content filtering network function is
> >> really
> >> >> 3
> >> >> >>>> logical network functions from the perspective of inclusion
> in
> >> a
> >> >> >> service
> >> >> >>>> chain.   Now extend this to multiple conceptual functions
> that
> >> >> >> utilize
> >> >> >>>> differentiated policies and the number of combinations will
> >> grow,
> >> >> at
> >> >> >>>> least modestly.
> >> >> >>>>
> >> >> >>>> Thanks,
> >> >> >>>>
> >> >> >>>> Ron
> >> >> >>>>
> >> >> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]
> *On
> >> >> Behalf
> >> >> >>>> Of *David Allan I
> >> >> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >> >> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
> nsc@ietf.org
> >> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >> >>>>
> >> >> >>>> Saying functions will have a problem with something that
> exists
> >> as
> >> >> a
> >> >> >>>> potential rationale for defining something new with exactly
> the
> >> >> same
> >> >> >>>> properties and problems does not quite work for me....
> >> >> >>>>
> >> >> >>>> VLANs on a vNIC or multiple vNICs (depending on the
> application
> >> >> >> stack
> >> >> >>>> construction and this being combined with application
> >> >> "cooperation"
> >> >> >>>> to preserve pairwise mappings of either VID/NIC tuples or
> >> simply
> >> >> >>>> NICs) currently exist as potential vehicles for preserving
> >> chain
> >> >> >>>> context and avoiding per hop classification. Anything else
> will
> >> be
> >> >> >>>> implemented more or less the same way and have exactly the
> same
> >> >> set
> >> >> >>>> of scaling and application design issues...Some extra
> >> information
> >> >> >>>> available on a single interface, or achieved by mapping
> chain
> >> >> >>>> instances onto one of a plurality of interfaces....
> >> >> >>>>
> >> >> >>>> But to back up... I'm not a carrier employee but I cannot
> >> envision
> >> >> a
> >> >> >>>> carrier offering potentially 1000s of distinct service
> bundles
> >> >> >> ("pick
> >> >> >>>> 53 from column A and 49 from column B"). So I suspect a much
> >> >> smaller
> >> >> >>>> number is realistic for  the number of chains a function
> >> instance
> >> >> is
> >> >> >>>> expected to participate in, even allowing for dynamic
> >> >> >>>> reclassification of flows at a chain ingress to "skip a few
> >> >> >>>> functions".... These are things that are fully
> operationalized
> >> in
> >> >> >>>> OSS, have policy associated with, have been industrialized
> and
> >> >> >>>> demonstrated to work prior to deployment. Going all
> >> combinatorial
> >> >> on
> >> >> >> this will break that big time....
> >> >> >>>>
> >> >> >>>> So are we really discussing a function participating in more
> >> than
> >> >> a
> >> >> >>>> handful of chain instances? And either a plurality of vNICs
> or
> >> >> VIDs
> >> >> >>>> being actually more than sufficient?
> >> >> >>>>
> >> >> >>>> Thanks
> >> >> >>>>
> >> >> >>>> Dave
> >> >> >>>>
> >> >> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
> >> (Wim)
> >> >> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >> >> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >> >> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >> >>>>
> >> >> >>>> indeed
> >> >> >>>>
> >> >> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >> >> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >> >> >>>> *Date: *Wednesday 24 July 2013 15:54
> >> >> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >> >> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >> >> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >> >> >>>> *Subject: *AW: Service chaining architecture question
> >> >> >>>>
> >> >> >>>> Hi Wim,
> >> >> >>>>
> >> >> >>>> I think not only effectivness/scalability might be a problem
> >> but
> >> >> >> also
> >> >> >>>> the fact that not all applications (service bringing
> functions)
> >> >> are
> >> >> >>>> able to handle packets coming from/going to potentially
> >> thousands
> >> >> of
> >> >> >>>> different VLANs at the same time. VLANs will work in certain
> >> >> >>>> environments but not in all. I see the need for an
> information
> >> >> >>>> exchange between the application and a mediation layer as
> well.
> >> >> >>>> Ideally this should be as simple as possible without heavy
> >> impact
> >> >> on
> >> >> >>>> the application itself (might be difficult to achieve but
> from
> >> my
> >> >> >>>> experience it is not very likely, that there will be big
> >> rewrites
> >> >> of
> >> >> >>>> existing applications in order to support the chaining).
> >> >> >>>>
> >> >> >>>>    regards
> >> >> >>>>
> >> >> >>>>       Nic
> >> >> >>>>
> >> >> >>>> ------------------------------------------------------------
> ---
> >> ---
> >> >> --
> >> >> >> -
> >> >> >>>> -
> >> >> >>>> --
> >> >> >>>>
> >> >> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >> >> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx,
> Wim
> >> >> (Wim)
> >> >> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >> >> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >> >> >>>> *Betreff:* [nsc] Service chaining architecture question
> >> >> >>>>
> >> >> >>>> I have a basic question with respect to the
> >> architecture/framework
> >> >> >> so
> >> >> >>>> far mentioned in the drafts in NSC. I understand the meta-
> data
> >> is
> >> >> a
> >> >> >>>> mechanism to avoid multiple re-classifications when the
> packet
> >> >> >> enters
> >> >> >>>> the NSC domain and identifies the chain of service functions.
> >> Now
> >> >> my
> >> >> >>>> understanding is that the services/applications are unaware
> of
> >> the
> >> >> >>>> meta-data and that a layer underneath should provide the
> >> mediation
> >> >> >>>> and that we use a well defined interface to the
> >> >> application/service
> >> >> >>>> to indicate the chain. In the context of Cloud/enterprise
> >> >> >> environment
> >> >> >>>> I can see this work given you can use a dedicate VLAN e.g.
> >> within
> >> >> >> the tenant.
> >> >> >>>> However we also try to address residential use cases for
> mobile
> >> >> and
> >> >> >>>> fixed and here this becomes more tricky afais. In the
> >> residential
> >> >> >>>> environment we can't expose a VLAN per application/service
> per
> >> >> chain
> >> >> >>>> since this would not be very effective. So I am wondering
> how
> >> we
> >> >> >>>> envision this to work?
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> _______________________________________________
> >> >> >>>> nsc mailing list
> >> >> >>>> nsc@ietf.org
> >> >> >>>>https://www.ietf.org/mailman/listinfo/nsc
> >> >> >>> _______________________________________________
> >> >> >>> nsc mailing list
> >> >> >>> nsc@ietf.org
> >> >> >>>https://www.ietf.org/mailman/listinfo/nsc
> >> >> >> _______________________________________________
> >> >> >> nsc mailing list
> >> >> >> nsc@ietf.org
> >> >> >>https://www.ietf.org/mailman/listinfo/nsc
> >> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > nsc mailing list
> >> > nsc@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/nsc
> >> >
> >_______________________________________________
> >nsc mailing list
> >nsc@ietf.org
> >https://www.ietf.org/mailman/listinfo/nsc
>=20
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From paulq@cisco.com  Thu Jul 25 09:26:41 2013
Return-Path: <paulq@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1E321F8749 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 09:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP1onYq1oJQO for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 09:26:36 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3E44B21F85B4 for <nsc@ietf.org>; Thu, 25 Jul 2013 09:26:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16318; q=dns/txt; s=iport; t=1374769590; x=1375979190; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=t3VThKIhplV5CxqSQUms7t9ivlgCTAqnrIywkeWCEKc=; b=kehnt2N1ZxtQ0oCo7/gQIS+QjJzuKZK36emWKBV1Hw3NNQTT/EV7TCMb J/BFdPA1KkHZ/9jPScNZMOffXPXDj6IFro+6ZeexdI1FrVYyJ8jZbradZ ClLKkXylqgmHExJEkrrenxAOZtDWlh9MnZ+1LLGlxBZCmkDBI1JX0+VCZ Q=;
X-IronPort-AV: E=Sophos;i="4.89,744,1367971200"; d="scan'208";a="84676725"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 25 Jul 2013 16:26:26 +0000
Received: from sjc-paquinn-8714.cisco.com (sjc-paquinn-8714.cisco.com [10.19.172.245]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6PGQORN010244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 16:26:24 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Paul Quinn <paulq@cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01207D79@MISOUT7MSGUSR9I.ITServices.sbc.com>
Date: Thu, 25 Jul 2013 09:26:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <26D10EA4-D7F4-4F4C-8AFE-F6EA40BA152E@cisco.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01207D79@MISOUT7MSGUSR9I.ITServices.sbc.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>
X-Mailer: Apple Mail (2.1508)
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 16:26:41 -0000

Hi Maria,


On Jul 24, 2013, at 4:47 PM, "NAPIERALA, MARIA H" <mn1921@att.com> =
wrote:

> I would add the following:
>=20
>> I would not be surprised if we want all three of
>> Service Chain,
>> Service Policy, and
>> Subscriber / user identity
>> in the packet.
>=20
>> If the Chain is in the VLAN / MPLS label,=20
>=20
> Yes. We should separate signaling of network connectivity from =
metadata associated with the payload. These are two separate problems. =
In a data center, some VMs will be participating in service chains, some =
not, at a given time. We don't want to end up with two different =
forwarding paradigms for both types of those VMs.
>=20

IMHO, you want to separate both chaining information and metadata.  The =
chain information is used to provide a form of indirection into the =
existing forward models.



>> then we can discuss whether the other information goes in additional =
ids of the same type or in a
>> carried header.  I can construct arguments for either approach.
>=20
> We should avoid introducing a new header for carrying metadata (such =
as subscriber-id). The same result can be achieved by using the IP =
header of the payload packet (such as IP option or flow label).=20
>=20

Adding data to existing IP headers might not prove viable, most fields =
are either spoken for, or have significant technical limitations.  For =
example, IP options are usually filtered/dropped and rarely handled in =
the fast path for forwarding.



>> It may be easier to just carry the subscriber identity, and used the
>> same management systems to assign policies to the devices that care.  =
I
>> am concerned that it may not be practical to use a single policy
>> identifier to specify which HTTP rule set to use, which Firewall rule
>> set to use, and then which specific policy for other user selected
>> policy applications.
>=20
> Agree. Or use a *local* (to a given appliance) logical interface per =
service "profile" but. Typically though, a "service" would be realized =
by software and the goal would be to run it on a VM of a virtualized x86 =
server. It is cheap to spin a VM. So, instead of having different =
profiles in the same VM it will be much simpler to manage a larger =
number of VMs, each with limited bandwidth.
>=20

In many environments, physical and/or shared services must be supported =
as well for a variety of reasons.



> Maria
>=20
>>=20
>> On 7/24/13 7:30 PM, Linda Dunbar wrote:
>>> Joel,
>>>> -----Original Message-----
>>>>=20
>>>> Yes, having the chain ingress node mark the traffic makes good
>> sense.
>>>> Having it mark the subscriber identity and the chain to be =
traversed
>>>> seems quite sensible.
>>>>=20
>>>> The difference I think I have with Ron is that he proposes to use
>> one
>>>> identifier for both entities.
>>> [Linda] I hope you don't mean per subscriber identity, do you? With
>>> today's PCRF, subscribers are categorized based on their =
subscription
>>> types. Throughout the network, the "subscription types" dictate what
>>> service modules their corresponding traffic need to traverse =
through.
>>> Some service modules might need to examine packets deeper (i.e. look
>>> into payload) for their intended functions. They may need to extract
>> the
>>> "HTTP header" or HTTP messages from one or multiple packets.
>>> That causes, as Dave said, a
>>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
>> MPLS
>>>> labels.
>>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>>> The subscriber identity could be some bits in the payload.
>>>>=20
>>>> And if the existing boxes don't know how to handle that (as seems
>>>> likely) then we need a proxy / support function to translate the
>> common
>>>> protocol into whatever they used before we got something generally
>>>> usable out there.
>>>>=20
>>>> Yours,
>>>> Joel
>>>>=20
>>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>>>>>=20
>>>>> Agree with Ron that it is better to have fewer nodes in network to
>>>> make subscriber-aware policy decisions.
>>>>>=20
>>>>> Besides, it is not uncommon for multiple subscribers to share same
>>>> sequence of service modules. In this environment, if the network
>> edge
>>>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
>> use
>>>> Layer 2 or 3 labels to mark the traffic, the subsequent network
>> nodes
>>>> can steer traffic to the needed service modules without looking =
into
>>>> "Mega data" or other higher layer fields in the data frames.
>>>>>=20
>>>>> This approach can make "service chain" work without making changes
>> to
>>>> majority of existing deployed network elements.
>>>>>=20
>>>>> Linda
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> Jim,
>>>>>>=20
>>>>>> Yes, that could work, too, conceptually.   But it does require
>> that
>>>>>> each coarsely-defined network service have access to a
>> subscriber-
>>>> aware
>>>>>> policy resolution mechanism.   IMO, it is better to have fewer
>>>> network
>>>>>> elements making subscriber-aware policy decisions.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>    Ron
>>>>>>=20
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>>>>> Sent: Wednesday, July 24, 2013 6:17 PM
>>>>>> To: Ron Parker
>>>>>> Cc: Joel M. Halpern; nsc@ietf.org
>>>>>> Subject: Re: [nsc] Service chaining architecture question
>>>>>>=20
>>>>>> Ron,
>>>>>> Or alternatively carry the subscriber awareness in metadata
>> thereby
>>>>>> utilizing a single chain.
>>>>>>=20
>>>>>> Sent from my iPhone
>>>>>>=20
>>>>>> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>>>>>> <Ron_Parker@affirmednetworks.com> wrote:
>>>>>>=20
>>>>>>> Joel,
>>>>>>>=20
>>>>>>> IMO, the primary reason for understanding the subscriber
>> identity
>>>> at
>>>>>> a network service is to choose from a differentiated set of
>> policies.
>>>>>> I think there is utility and efficiency in driving that selection
>>>> from
>>>>>> one place -- the network services classifier.     Say there were
>> 2
>>>>>> groups of subscribers -- children and adults.   Let's now define
>> 2
>>>>>> chains, where the chains have a business-based meaning to the
>>>> operator.
>>>>>> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D =
HTTP-
>>>> filter-
>>>>>> adult + Firewall-adult.    The referenced network services are
>>>> logical
>>>>>> and it is possible, but not required, that multiple logical
>> network
>>>>>> services be located at the same IP address or FQDN.     Conveying
>>>> the
>>>>>> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>>>> ID, ...)
>>>>>> allows the IP-addressable server that realizes these service(s)
>> to
>>>> know
>>>>>> two things -- 1) which logical network function should be invoked
>>>> and 2)
>>>>>> which logical network function is next.
>>>>>>>=20
>>>>>>> Thanks.
>>>>>>> Ron
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>>>>> Sent: Wednesday, July 24, 2013 4:47 PM
>>>>>>> To: Ron Parker
>>>>>>> Cc: nsc@ietf.org
>>>>>>> Subject: Re: [nsc] Service chaining architecture question
>>>>>>>=20
>>>>>>> Ron,
>>>>>>>     maybe I am missing something, but you seem to lay out very
>>>> nicely
>>>>>> the case for wanting both service chain identification and
>>>> separately
>>>>>> subscriber identification.  Then the HTTP filter can use the
>>>> subscriber
>>>>>> ID to decide which exact content filtering behavior it should
>> apply.
>>>> I
>>>>>> would not want to fold that level of detail into the chain
>>>>>> identification.
>>>>>>>=20
>>>>>>> Yours,
>>>>>>> Joel
>>>>>>>=20
>>>>>>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>>>>>>> Dave,
>>>>>>>>=20
>>>>>>>> I agree that the number of chains is unlikely to scale to vast
>>>>>> numbers
>>>>>>>> (i.e., millions).     And I agree that it is bounded from a
>>>>>> practical
>>>>>>>> business perspective, as you point out.
>>>>>>>>=20
>>>>>>>> You may already be on this page, but I wanted to point out a
>>>>>>>> distinction of coarse-grained definition of a service function
>> vs.
>>>>>> finer-grained
>>>>>>>> definition of a service function.   Consider a service function
>> to
>>>>>> be
>>>>>>>> logical in such a way that the identity of the logical function
>>>> may
>>>>>> also
>>>>>>>> imply some differentiated behavior.   For example, a conceptual
>>>>>> function
>>>>>>>> is HTTP content filtering.    This conceptual function can then
>> be
>>>>>>>> further instantiated at the logical level based on
>> differentiated
>>>>>>>> policies such as content-filter-children,
>>>>>>>> content-filter-adults-no-porn, content-filter-adults (I'm
>> taking
>>>> no
>>>>>> stand on opt-in vs. opt-out, Mr.
>>>>>>>> Cameron).   It may be that the same network element (dedicated
>>>>>> physical
>>>>>>>> box or virtual network function) realizes all 3 of the example
>>>>>>>> policies.   The HTTP content filtering network function is
>> really
>>>> 3
>>>>>>>> logical network functions from the perspective of inclusion in
>> a
>>>>>> service
>>>>>>>> chain.   Now extend this to multiple conceptual functions that
>>>>>> utilize
>>>>>>>> differentiated policies and the number of combinations will
>> grow,
>>>> at
>>>>>>>> least modestly.
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>>=20
>>>>>>>> Ron
>>>>>>>>=20
>>>>>>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>>>> Behalf
>>>>>>>> Of *David Allan I
>>>>>>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>>>>>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>>>>>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>>>>>>=20
>>>>>>>> Saying functions will have a problem with something that exists
>> as
>>>> a
>>>>>>>> potential rationale for defining something new with exactly the
>>>> same
>>>>>>>> properties and problems does not quite work for me....
>>>>>>>>=20
>>>>>>>> VLANs on a vNIC or multiple vNICs (depending on the application
>>>>>> stack
>>>>>>>> construction and this being combined with application
>>>> "cooperation"
>>>>>>>> to preserve pairwise mappings of either VID/NIC tuples or
>> simply
>>>>>>>> NICs) currently exist as potential vehicles for preserving
>> chain
>>>>>>>> context and avoiding per hop classification. Anything else will
>> be
>>>>>>>> implemented more or less the same way and have exactly the same
>>>> set
>>>>>>>> of scaling and application design issues...Some extra
>> information
>>>>>>>> available on a single interface, or achieved by mapping chain
>>>>>>>> instances onto one of a plurality of interfaces....
>>>>>>>>=20
>>>>>>>> But to back up... I'm not a carrier employee but I cannot
>> envision
>>>> a
>>>>>>>> carrier offering potentially 1000s of distinct service bundles
>>>>>> ("pick
>>>>>>>> 53 from column A and 49 from column B"). So I suspect a much
>>>> smaller
>>>>>>>> number is realistic for  the number of chains a function
>> instance
>>>> is
>>>>>>>> expected to participate in, even allowing for dynamic
>>>>>>>> reclassification of flows at a chain ingress to "skip a few
>>>>>>>> functions".... These are things that are fully operationalized
>> in
>>>>>>>> OSS, have policy associated with, have been industrialized and
>>>>>>>> demonstrated to work prior to deployment. Going all
>> combinatorial
>>>> on
>>>>>> this will break that big time....
>>>>>>>>=20
>>>>>>>> So are we really discussing a function participating in more
>> than
>>>> a
>>>>>>>> handful of chain instances? And either a plurality of vNICs or
>>>> VIDs
>>>>>>>> being actually more than sufficient?
>>>>>>>>=20
>>>>>>>> Thanks
>>>>>>>>=20
>>>>>>>> Dave
>>>>>>>>=20
>>>>>>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>>>>>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>> (Wim)
>>>>>>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>>>>>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>>>>>>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>>>>>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>>>>>>=20
>>>>>>>> indeed
>>>>>>>>=20
>>>>>>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>>>>>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>>>>>>> *Date: *Wednesday 24 July 2013 15:54
>>>>>>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>>>>>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>>>>>>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>>>>>>> *Subject: *AW: Service chaining architecture question
>>>>>>>>=20
>>>>>>>> Hi Wim,
>>>>>>>>=20
>>>>>>>> I think not only effectivness/scalability might be a problem
>> but
>>>>>> also
>>>>>>>> the fact that not all applications (service bringing functions)
>>>> are
>>>>>>>> able to handle packets coming from/going to potentially
>> thousands
>>>> of
>>>>>>>> different VLANs at the same time. VLANs will work in certain
>>>>>>>> environments but not in all. I see the need for an information
>>>>>>>> exchange between the application and a mediation layer as well.
>>>>>>>> Ideally this should be as simple as possible without heavy
>> impact
>>>> on
>>>>>>>> the application itself (might be difficult to achieve but from
>> my
>>>>>>>> experience it is not very likely, that there will be big
>> rewrites
>>>> of
>>>>>>>> existing applications in order to support the chaining).
>>>>>>>>=20
>>>>>>>>   regards
>>>>>>>>=20
>>>>>>>>      Nic
>>>>>>>>=20
>>>>>>>> ---------------------------------------------------------------
>> ---
>>>> --
>>>>>> -
>>>>>>>> -
>>>>>>>> --
>>>>>>>>=20
>>>>>>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>>>>>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>>>> (Wim)
>>>>>>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>>>>>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>>>>>>> *Betreff:* [nsc] Service chaining architecture question
>>>>>>>>=20
>>>>>>>> I have a basic question with respect to the
>> architecture/framework
>>>>>> so
>>>>>>>> far mentioned in the drafts in NSC. I understand the meta-data
>> is
>>>> a
>>>>>>>> mechanism to avoid multiple re-classifications when the packet
>>>>>> enters
>>>>>>>> the NSC domain and identifies the chain of service functions.
>> Now
>>>> my
>>>>>>>> understanding is that the services/applications are unaware of
>> the
>>>>>>>> meta-data and that a layer underneath should provide the
>> mediation
>>>>>>>> and that we use a well defined interface to the
>>>> application/service
>>>>>>>> to indicate the chain. In the context of Cloud/enterprise
>>>>>> environment
>>>>>>>> I can see this work given you can use a dedicate VLAN e.g.
>> within
>>>>>> the tenant.
>>>>>>>> However we also try to address residential use cases for mobile
>>>> and
>>>>>>>> fixed and here this becomes more tricky afais. In the
>> residential
>>>>>>>> environment we can't expose a VLAN per application/service per
>>>> chain
>>>>>>>> since this would not be very effective. So I am wondering how
>> we
>>>>>>>> envision this to work?
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> nsc mailing list
>>>>>>>> nsc@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc
>>>>>>> _______________________________________________
>>>>>>> nsc mailing list
>>>>>>> nsc@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/nsc
>>>>>> _______________________________________________
>>>>>> nsc mailing list
>>>>>> nsc@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/nsc
>>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> nsc mailing list
>>> nsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nsc
>>>=20
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc


From Ron_Parker@affirmednetworks.com  Thu Jul 25 10:30:17 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2E21F995E for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 10:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4ghj5KGqYlt for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 10:30:12 -0700 (PDT)
Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id E028C21F9971 for <nsc@ietf.org>; Thu, 25 Jul 2013 10:30:11 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0123.003; Thu, 25 Jul 2013 10:30:10 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "Surendra Kumar (smkumar)" <smkumar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAPrusAAA6WcXD//5GVAIAAckyA////8wD//9g2oP//lfBg
Date: Thu, 25 Jul 2013 17:30:10 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A67EC7A@MBX021-W3-CA-2.exch021.domain.local>
References: <4A95BA014132FF49AE685FAB4B9F17F645B4D3C3@dfweml509-mbx.china.huawei.com> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF363D@xmb-aln-x09.cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D707@dfweml509-mbx.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645B4D707@dfweml509-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 17:30:17 -0000

Linda,

When the classifier determines the appropriate chain, it should do so in 2 =
steps.   In the first step, it should determine the sequence of network ser=
vices to be applied where each service is abstract and is not yet mapped to=
 an addressable network entity.   In the second step, each abstract service=
 function is mapped to an addressable entity that will be engaged to actual=
ly perform the required service.   This approach would lend itself to 1:1 m=
apping as well as 1:N mapping, implying a load balancing function may be pe=
rformed by the classifier.   This is covered, in part, by draft-boucadair-n=
etwork-function-chaining-02 section 3.4, Building NLFC Policy Tables.

   Ron


-----Original Message-----
From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20
Sent: Thursday, July 25, 2013 12:01 PM
To: Surendra Kumar (smkumar); Joel M. Halpern
Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
Subject: RE: [nsc] Service chaining architecture question

Surendra,=20

Thank you very much for the clarification. I like this distinction: Service=
 Path & Service Chain.=20

Is "Service Chain Path" more accurate?=20
"Service path" can be easily interpreted as Network Service Path, like the =
path along a sequence of network nodes that data packets traverse. They are=
 so much like today's network.=20

Is NSC also try to re-characterize today's network using a new term?=20
I can see that all today's network elements can be re-characterized as vari=
ous service modules, like L2/L3 forwarding service, GRE encapsulating servi=
ce, pushing/popping MPLS label  service, etc, but is it necessary to do so?=
=20
=20

Linda

=20

> -----Original Message-----
> SK> That is the definition of "Service Path" in NSH - actual=20
> SK> forwarding
> path; you get two *service paths* for the same *service chain*, in=20
> your example. Service Chain exists in the control plane while Service=20
> Path exists in the data plane, so to speak.
>=20
> Surendra.
>=20
> >
> >Linda
> >
> >> -----Original Message-----
> >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> Sent: Wednesday, July 24, 2013 6:35 PM
> >> To: Linda Dunbar
> >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
> >> Subject: Re: [nsc] Service chaining architecture question
> >>
> >> I would not be surprised if we want all three of Service Chain,=20
> >> Service Policy, and Subscriber / user identity in the packet.
> >> If the Chain is in the VLAN / MPLS label, then we can discuss
> whether
> >> the other information goes in additional ids of the same type or in
> a
> >> carried header.  I can construct arguments for either approach.
> >>
> >> It may be easier to just carry the subscriber identity, and used=20
> >> the same management systems to assign policies to the devices that car=
e.
> I
> >> am concerned that it may not be practical to use a single policy=20
> >> identifier to specify which HTTP rule set to use, which Firewall
> rule
> >> set to use, and then which specific policy for other user selected=20
> >> policy applications.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 7/24/13 7:30 PM, Linda Dunbar wrote:
> >> > Joel,
> >> >> -----Original Message-----
> >> >>
> >> >> Yes, having the chain ingress node mark the traffic makes good
> sense.
> >> >> Having it mark the subscriber identity and the chain to be
> traversed
> >> >> seems quite sensible.
> >> >>
> >> >> The difference I think I have with Ron is that he proposes to=20
> >> >> use
> >> one
> >> >> identifier for both entities.
> >> > [Linda] I hope you don't mean per subscriber identity, do you?
> With
> >> > today's PCRF, subscribers are categorized based on their
> subscription
> >> > types. Throughout the network, the "subscription types" dictate
> what
> >> > service modules their corresponding traffic need to traverse
> through.
> >> > Some service modules might need to examine packets deeper (i.e.
> look
> >> > into payload) for their intended functions. They may need to
> extract
> >> the
> >> > "HTTP header" or HTTP messages from one or multiple packets.
> >> > That causes, as Dave said, a
> >> >> combinatorial explosion.  Rather, use two fields.  Two VLANs.
> Two
> >> MPLS
> >> >> labels.
> >> > [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> >> > The subscriber identity could be some bits in the payload.
> >> >>
> >> >> And if the existing boxes don't know how to handle that (as=20
> >> >> seems
> >> >> likely) then we need a proxy / support function to translate the
> >> common
> >> >> protocol into whatever they used before we got something
> generally
> >> >> usable out there.
> >> >>
> >> >> Yours,
> >> >> Joel
> >> >>
> >> >> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >> >> >
> >> >> > Agree with Ron that it is better to have fewer nodes in=20
> >> >> > network
> to
> >> >> make subscriber-aware policy decisions.
> >> >> >
> >> >> > Besides, it is not uncommon for multiple subscribers to share
> same
> >> >> sequence of service modules. In this environment, if the network
> >> edge
> >> >> nodes, such as Broadband Network Gateway or Cell Site Gateway,
> can
> >> use
> >> >> Layer 2 or 3 labels to mark the traffic, the subsequent network
> >> nodes
> >> >> can steer traffic to the needed service modules without looking
> into
> >> >> "Mega data" or other higher layer fields in the data frames.
> >> >> >
> >> >> > This approach can make "service chain" work without making
> changes
> >> to
> >> >> majority of existing deployed network elements.
> >> >> >
> >> >> > Linda
> >> >> >
> >> >> >
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> Jim,
> >> >> >>
> >> >> >> Yes, that could work, too, conceptually.   But it does require
> >> that
> >> >> >> each coarsely-defined network service have access to a
> >> subscriber-
> >> >> aware
> >> >> >> policy resolution mechanism.   IMO, it is better to have fewer
> >> >> network
> >> >> >> elements making subscriber-aware policy decisions.
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>     Ron
> >> >> >>
> >> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >> >> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >> >> >> To: Ron Parker
> >> >> >> Cc: Joel M. Halpern; nsc@ietf.org
> >> >> >> Subject: Re: [nsc] Service chaining architecture question
> >> >> >>
> >> >> >> Ron,
> >> >> >> Or alternatively carry the subscriber awareness in metadata
> >> thereby
> >> >> >> utilizing a single chain.
> >> >> >>
> >> >> >> Sent from my iPhone
> >> >> >>
> >> >> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >> >> >> <Ron_Parker@affirmednetworks.com> wrote:
> >> >> >>
> >> >> >>> Joel,
> >> >> >>>
> >> >> >>> IMO, the primary reason for understanding the subscriber
> >> identity
> >> >> at
> >> >> >> a network service is to choose from a differentiated set of
> >> policies.
> >> >> >> I think there is utility and efficiency in driving that
> selection
> >> >> from
> >> >> >> one place -- the network services classifier.     Say there
> were
> >> 2
> >> >> >> groups of subscribers -- children and adults.   Let's now
> define
> >> 2
> >> >> >> chains, where the chains have a business-based meaning to the
> >> >> operator.
> >> >> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D
> HTTP-
> >> >> filter-
> >> >> >> adult + Firewall-adult.    The referenced network services are
> >> >> logical
> >> >> >> and it is possible, but not required, that multiple logical
> >> network
> >> >> >> services be located at the same IP address or FQDN.
> Conveying
> >> >> the
> >> >> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH=20
> >> >> >> chain
> >> >> ID, ...)
> >> >> >> allows the IP-addressable server that realizes these=20
> >> >> >> service(s)
> >> to
> >> >> know
> >> >> >> two things -- 1) which logical network function should be
> invoked
> >> >> and 2)
> >> >> >> which logical network function is next.
> >> >> >>>
> >> >> >>> Thanks.
> >> >> >>> Ron
> >> >> >>>
> >> >> >>> -----Original Message-----
> >> >> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> >> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> >> >> >>> To: Ron Parker
> >> >> >>> Cc: nsc@ietf.org
> >> >> >>> Subject: Re: [nsc] Service chaining architecture question
> >> >> >>>
> >> >> >>> Ron,
> >> >> >>>      maybe I am missing something, but you seem to lay out
> very
> >> >> nicely
> >> >> >> the case for wanting both service chain identification and
> >> >> separately
> >> >> >> subscriber identification.  Then the HTTP filter can use the
> >> >> subscriber
> >> >> >> ID to decide which exact content filtering behavior it should
> >> apply.
> >> >> I
> >> >> >> would not want to fold that level of detail into the chain=20
> >> >> >> identification.
> >> >> >>>
> >> >> >>> Yours,
> >> >> >>> Joel
> >> >> >>>
> >> >> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >> >> >>>> Dave,
> >> >> >>>>
> >> >> >>>> I agree that the number of chains is unlikely to scale to
> vast
> >> >> >> numbers
> >> >> >>>> (i.e., millions).     And I agree that it is bounded from a
> >> >> >> practical
> >> >> >>>> business perspective, as you point out.
> >> >> >>>>
> >> >> >>>> You may already be on this page, but I wanted to point out=20
> >> >> >>>> a distinction of coarse-grained definition of a service
> function
> >> vs.
> >> >> >> finer-grained
> >> >> >>>> definition of a service function.   Consider a service
> function
> >> to
> >> >> >> be
> >> >> >>>> logical in such a way that the identity of the logical
> function
> >> >> may
> >> >> >> also
> >> >> >>>> imply some differentiated behavior.   For example, a
> conceptual
> >> >> >> function
> >> >> >>>> is HTTP content filtering.    This conceptual function can
> then
> >> be
> >> >> >>>> further instantiated at the logical level based on
> >> differentiated
> >> >> >>>> policies such as content-filter-children,=20
> >> >> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
> >> taking
> >> >> no
> >> >> >> stand on opt-in vs. opt-out, Mr.
> >> >> >>>> Cameron).   It may be that the same network element
> (dedicated
> >> >> >> physical
> >> >> >>>> box or virtual network function) realizes all 3 of the
> example
> >> >> >>>> policies.   The HTTP content filtering network function is
> >> really
> >> >> 3
> >> >> >>>> logical network functions from the perspective of inclusion
> in
> >> a
> >> >> >> service
> >> >> >>>> chain.   Now extend this to multiple conceptual functions
> that
> >> >> >> utilize
> >> >> >>>> differentiated policies and the number of combinations will
> >> grow,
> >> >> at
> >> >> >>>> least modestly.
> >> >> >>>>
> >> >> >>>> Thanks,
> >> >> >>>>
> >> >> >>>> Ron
> >> >> >>>>
> >> >> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]
> *On
> >> >> Behalf
> >> >> >>>> Of *David Allan I
> >> >> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >> >> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
> nsc@ietf.org
> >> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >> >>>>
> >> >> >>>> Saying functions will have a problem with something that
> exists
> >> as
> >> >> a
> >> >> >>>> potential rationale for defining something new with exactly
> the
> >> >> same
> >> >> >>>> properties and problems does not quite work for me....
> >> >> >>>>
> >> >> >>>> VLANs on a vNIC or multiple vNICs (depending on the
> application
> >> >> >> stack
> >> >> >>>> construction and this being combined with application
> >> >> "cooperation"
> >> >> >>>> to preserve pairwise mappings of either VID/NIC tuples or
> >> simply
> >> >> >>>> NICs) currently exist as potential vehicles for preserving
> >> chain
> >> >> >>>> context and avoiding per hop classification. Anything else
> will
> >> be
> >> >> >>>> implemented more or less the same way and have exactly the
> same
> >> >> set
> >> >> >>>> of scaling and application design issues...Some extra
> >> information
> >> >> >>>> available on a single interface, or achieved by mapping
> chain
> >> >> >>>> instances onto one of a plurality of interfaces....
> >> >> >>>>
> >> >> >>>> But to back up... I'm not a carrier employee but I cannot
> >> envision
> >> >> a
> >> >> >>>> carrier offering potentially 1000s of distinct service
> bundles
> >> >> >> ("pick
> >> >> >>>> 53 from column A and 49 from column B"). So I suspect a=20
> >> >> >>>> much
> >> >> smaller
> >> >> >>>> number is realistic for  the number of chains a function
> >> instance
> >> >> is
> >> >> >>>> expected to participate in, even allowing for dynamic=20
> >> >> >>>> reclassification of flows at a chain ingress to "skip a few=20
> >> >> >>>> functions".... These are things that are fully
> operationalized
> >> in
> >> >> >>>> OSS, have policy associated with, have been industrialized
> and
> >> >> >>>> demonstrated to work prior to deployment. Going all
> >> combinatorial
> >> >> on
> >> >> >> this will break that big time....
> >> >> >>>>
> >> >> >>>> So are we really discussing a function participating in=20
> >> >> >>>> more
> >> than
> >> >> a
> >> >> >>>> handful of chain instances? And either a plurality of vNICs
> or
> >> >> VIDs
> >> >> >>>> being actually more than sufficient?
> >> >> >>>>
> >> >> >>>> Thanks
> >> >> >>>>
> >> >> >>>> Dave
> >> >> >>>>
> >> >> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> >> >> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx,=20
> >> >> >>>> Wim
> >> (Wim)
> >> >> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >> >> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
> >> >> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >> >> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >> >> >>>>
> >> >> >>>> indeed
> >> >> >>>>
> >> >> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >> >> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >> >> >>>> *Date: *Wednesday 24 July 2013 15:54
> >> >> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >> >> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
> >> >> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >> >> >>>> *Subject: *AW: Service chaining architecture question
> >> >> >>>>
> >> >> >>>> Hi Wim,
> >> >> >>>>
> >> >> >>>> I think not only effectivness/scalability might be a=20
> >> >> >>>> problem
> >> but
> >> >> >> also
> >> >> >>>> the fact that not all applications (service bringing
> functions)
> >> >> are
> >> >> >>>> able to handle packets coming from/going to potentially
> >> thousands
> >> >> of
> >> >> >>>> different VLANs at the same time. VLANs will work in=20
> >> >> >>>> certain environments but not in all. I see the need for an
> information
> >> >> >>>> exchange between the application and a mediation layer as
> well.
> >> >> >>>> Ideally this should be as simple as possible without heavy
> >> impact
> >> >> on
> >> >> >>>> the application itself (might be difficult to achieve but
> from
> >> my
> >> >> >>>> experience it is not very likely, that there will be big
> >> rewrites
> >> >> of
> >> >> >>>> existing applications in order to support the chaining).
> >> >> >>>>
> >> >> >>>>    regards
> >> >> >>>>
> >> >> >>>>       Nic
> >> >> >>>>
> >> >> >>>> -----------------------------------------------------------
> >> >> >>>> -
> ---
> >> ---
> >> >> --
> >> >> >> -
> >> >> >>>> -
> >> >> >>>> --
> >> >> >>>>
> >> >> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> >> >> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx,
> Wim
> >> >> (Wim)
> >> >> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >> >> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >> >> >>>> *Betreff:* [nsc] Service chaining architecture question
> >> >> >>>>
> >> >> >>>> I have a basic question with respect to the
> >> architecture/framework
> >> >> >> so
> >> >> >>>> far mentioned in the drafts in NSC. I understand the meta-
> data
> >> is
> >> >> a
> >> >> >>>> mechanism to avoid multiple re-classifications when the
> packet
> >> >> >> enters
> >> >> >>>> the NSC domain and identifies the chain of service functions.
> >> Now
> >> >> my
> >> >> >>>> understanding is that the services/applications are unaware
> of
> >> the
> >> >> >>>> meta-data and that a layer underneath should provide the
> >> mediation
> >> >> >>>> and that we use a well defined interface to the
> >> >> application/service
> >> >> >>>> to indicate the chain. In the context of Cloud/enterprise
> >> >> >> environment
> >> >> >>>> I can see this work given you can use a dedicate VLAN e.g.
> >> within
> >> >> >> the tenant.
> >> >> >>>> However we also try to address residential use cases for
> mobile
> >> >> and
> >> >> >>>> fixed and here this becomes more tricky afais. In the
> >> residential
> >> >> >>>> environment we can't expose a VLAN per application/service
> per
> >> >> chain
> >> >> >>>> since this would not be very effective. So I am wondering
> how
> >> we
> >> >> >>>> envision this to work?
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> _______________________________________________
> >> >> >>>> nsc mailing list
> >> >> >>>> nsc@ietf.org
> >> >> >>>>https://www.ietf.org/mailman/listinfo/nsc
> >> >> >>> _______________________________________________
> >> >> >>> nsc mailing list
> >> >> >>> nsc@ietf.org
> >> >> >>>https://www.ietf.org/mailman/listinfo/nsc
> >> >> >> _______________________________________________
> >> >> >> nsc mailing list
> >> >> >> nsc@ietf.org
> >> >> >>https://www.ietf.org/mailman/listinfo/nsc
> >> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > nsc mailing list
> >> > nsc@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/nsc
> >> >
> >_______________________________________________
> >nsc mailing list
> >nsc@ietf.org
> >https://www.ietf.org/mailman/listinfo/nsc
>=20
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From mn1921@att.com  Thu Jul 25 11:04:32 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BD621F997E for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L94GQqaKm5lk for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:04:26 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E21BE21F9974 for <nsc@ietf.org>; Thu, 25 Jul 2013 11:04:25 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 9a861f15.2aab01c55940.3183981.00-571.8727903.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Thu, 25 Jul 2013 18:04:25 +0000 (UTC)
X-MXL-Hash: 51f168a92c51ea1e-d1befe351fc563dea814f658a3c4854e4fd5623f
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 3a861f15.0.3183904.00-111.8727575.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Thu, 25 Jul 2013 18:04:20 +0000 (UTC)
X-MXL-Hash: 51f168a43ff44b39-17a97067bbcd0e97e0e7d1941842149447ed2e3f
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6PI4I0R016308; Thu, 25 Jul 2013 14:04:19 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6PI40n6015937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 14:04:03 -0400
Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 25 Jul 2013 18:03:41 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 14:03:41 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: Paul Quinn <paulq@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeAgAALhACAABT2gIAABD2AgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAP//vmwQgAFcKwD//9PSoA==
Date: Thu, 25 Jul 2013 18:03:40 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E0120863D@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01207D79@MISOUT7MSGUSR9I.ITServices.sbc.com> <26D10EA4-D7F4-4F4C-8AFE-F6EA40BA152E@cisco.com>
In-Reply-To: <26D10EA4-D7F4-4F4C-8AFE-F6EA40BA152E@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.38.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=WbS7nTdX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=0o18Hi0vUFMA:10 a=2DTnKp0c6ewA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=QNNNeoGkA4wA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=qN95wPeSAAAA:8 a=ABeY7kuGAAAA:8 a=gxZvrgisAAAA:8 a=m6C7]
X-AnalysisOut: [nczHQsaLfmzaiVsA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=l]
X-AnalysisOut: [ZB815dzVvQA:10 a=paC5pjApGzsA:10 a=chC_agHSu74A:10 a=p3EP0]
X-AnalysisOut: [m9KMXkA:10 a=3FZX-ydVlcEA:10 a=5n1r7BKVyez_iVxN:21 a=vD9no]
X-AnalysisOut: [FHkYOzWpKUR:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 18:04:32 -0000

Hi Paul,

> > Yes. We should separate signaling of network connectivity from
> metadata associated with the payload. These are two separate problems.
> In a data center, some VMs will be participating in service chains,
> some not, at a given time. We don't want to end up with two different
> forwarding paradigms for both types of those VMs.
> >
>=20
> IMHO, you want to separate both chaining information and metadata.  The
> chain information is used to provide a form of indirection into the
> existing forward models.

Could you clarify what you mean by "a form of indirection into the existing=
 forward models",=20
especially in the scenario of virtualized servers (services running in VMs)=
?=20

>=20
> >> then we can discuss whether the other information goes in additional
> ids of the same type or in a
> >> carried header.  I can construct arguments for either approach.
> >
> > We should avoid introducing a new header for carrying metadata (such
> as subscriber-id). The same result can be achieved by using the IP
> header of the payload packet (such as IP option or flow label).
> >
>=20
> Adding data to existing IP headers might not prove viable, most fields
> are either spoken for, or have significant technical limitations.  For
> example, IP options are usually filtered/dropped and rarely handled in
> the fast path for forwarding.

IMO, services should be deployed on the "edge" of the network in software. =
There is only one type of forwarding in software.=20

>=20
> >> It may be easier to just carry the subscriber identity, and used the
> >> same management systems to assign policies to the devices that care.
> I
> >> am concerned that it may not be practical to use a single policy
> >> identifier to specify which HTTP rule set to use, which Firewall
> rule
> >> set to use, and then which specific policy for other user selected
> >> policy applications.
> >
> > Agree. Or use a *local* (to a given appliance) logical interface per
> service "profile" but. Typically though, a "service" would be realized
> by software and the goal would be to run it on a VM of a virtualized
> x86 server. It is cheap to spin a VM. So, instead of having different
> profiles in the same VM it will be much simpler to manage a larger
> number of VMs, each with limited bandwidth.
> >
>=20
> In many environments, physical and/or shared services must be supported
> as well for a variety of reasons.

If a physical (typically, legacy) device needs to participate in a service =
chain, I would proxy it.

Maria
=20
>=20
> > Maria
> >
> >>
> >> On 7/24/13 7:30 PM, Linda Dunbar wrote:
> >>> Joel,
> >>>> -----Original Message-----
> >>>>
> >>>> Yes, having the chain ingress node mark the traffic makes good
> >> sense.
> >>>> Having it mark the subscriber identity and the chain to be
> traversed
> >>>> seems quite sensible.
> >>>>
> >>>> The difference I think I have with Ron is that he proposes to use
> >> one
> >>>> identifier for both entities.
> >>> [Linda] I hope you don't mean per subscriber identity, do you? With
> >>> today's PCRF, subscribers are categorized based on their
> subscription
> >>> types. Throughout the network, the "subscription types" dictate
> what
> >>> service modules their corresponding traffic need to traverse
> through.
> >>> Some service modules might need to examine packets deeper (i.e.
> look
> >>> into payload) for their intended functions. They may need to
> extract
> >> the
> >>> "HTTP header" or HTTP messages from one or multiple packets.
> >>> That causes, as Dave said, a
> >>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
> >> MPLS
> >>>> labels.
> >>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> >>> The subscriber identity could be some bits in the payload.
> >>>>
> >>>> And if the existing boxes don't know how to handle that (as seems
> >>>> likely) then we need a proxy / support function to translate the
> >> common
> >>>> protocol into whatever they used before we got something generally
> >>>> usable out there.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >>>>>
> >>>>> Agree with Ron that it is better to have fewer nodes in network
> to
> >>>> make subscriber-aware policy decisions.
> >>>>>
> >>>>> Besides, it is not uncommon for multiple subscribers to share
> same
> >>>> sequence of service modules. In this environment, if the network
> >> edge
> >>>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
> >> use
> >>>> Layer 2 or 3 labels to mark the traffic, the subsequent network
> >> nodes
> >>>> can steer traffic to the needed service modules without looking
> into
> >>>> "Mega data" or other higher layer fields in the data frames.
> >>>>>
> >>>>> This approach can make "service chain" work without making
> changes
> >> to
> >>>> majority of existing deployed network elements.
> >>>>>
> >>>>> Linda
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> Jim,
> >>>>>>
> >>>>>> Yes, that could work, too, conceptually.   But it does require
> >> that
> >>>>>> each coarsely-defined network service have access to a
> >> subscriber-
> >>>> aware
> >>>>>> policy resolution mechanism.   IMO, it is better to have fewer
> >>>> network
> >>>>>> elements making subscriber-aware policy decisions.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>    Ron
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >>>>>> Sent: Wednesday, July 24, 2013 6:17 PM
> >>>>>> To: Ron Parker
> >>>>>> Cc: Joel M. Halpern; nsc@ietf.org
> >>>>>> Subject: Re: [nsc] Service chaining architecture question
> >>>>>>
> >>>>>> Ron,
> >>>>>> Or alternatively carry the subscriber awareness in metadata
> >> thereby
> >>>>>> utilizing a single chain.
> >>>>>>
> >>>>>> Sent from my iPhone
> >>>>>>
> >>>>>> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >>>>>> <Ron_Parker@affirmednetworks.com> wrote:
> >>>>>>
> >>>>>>> Joel,
> >>>>>>>
> >>>>>>> IMO, the primary reason for understanding the subscriber
> >> identity
> >>>> at
> >>>>>> a network service is to choose from a differentiated set of
> >> policies.
> >>>>>> I think there is utility and efficiency in driving that
> selection
> >>>> from
> >>>>>> one place -- the network services classifier.     Say there were
> >> 2
> >>>>>> groups of subscribers -- children and adults.   Let's now define
> >> 2
> >>>>>> chains, where the chains have a business-based meaning to the
> >>>> operator.
> >>>>>> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP=
-
> >>>> filter-
> >>>>>> adult + Firewall-adult.    The referenced network services are
> >>>> logical
> >>>>>> and it is possible, but not required, that multiple logical
> >> network
> >>>>>> services be located at the same IP address or FQDN.
> Conveying
> >>>> the
> >>>>>> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> >>>> ID, ...)
> >>>>>> allows the IP-addressable server that realizes these service(s)
> >> to
> >>>> know
> >>>>>> two things -- 1) which logical network function should be
> invoked
> >>>> and 2)
> >>>>>> which logical network function is next.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>> Ron
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >>>>>>> Sent: Wednesday, July 24, 2013 4:47 PM
> >>>>>>> To: Ron Parker
> >>>>>>> Cc: nsc@ietf.org
> >>>>>>> Subject: Re: [nsc] Service chaining architecture question
> >>>>>>>
> >>>>>>> Ron,
> >>>>>>>     maybe I am missing something, but you seem to lay out very
> >>>> nicely
> >>>>>> the case for wanting both service chain identification and
> >>>> separately
> >>>>>> subscriber identification.  Then the HTTP filter can use the
> >>>> subscriber
> >>>>>> ID to decide which exact content filtering behavior it should
> >> apply.
> >>>> I
> >>>>>> would not want to fold that level of detail into the chain
> >>>>>> identification.
> >>>>>>>
> >>>>>>> Yours,
> >>>>>>> Joel
> >>>>>>>
> >>>>>>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >>>>>>>> Dave,
> >>>>>>>>
> >>>>>>>> I agree that the number of chains is unlikely to scale to vast
> >>>>>> numbers
> >>>>>>>> (i.e., millions).     And I agree that it is bounded from a
> >>>>>> practical
> >>>>>>>> business perspective, as you point out.
> >>>>>>>>
> >>>>>>>> You may already be on this page, but I wanted to point out a
> >>>>>>>> distinction of coarse-grained definition of a service function
> >> vs.
> >>>>>> finer-grained
> >>>>>>>> definition of a service function.   Consider a service
> function
> >> to
> >>>>>> be
> >>>>>>>> logical in such a way that the identity of the logical
> function
> >>>> may
> >>>>>> also
> >>>>>>>> imply some differentiated behavior.   For example, a
> conceptual
> >>>>>> function
> >>>>>>>> is HTTP content filtering.    This conceptual function can
> then
> >> be
> >>>>>>>> further instantiated at the logical level based on
> >> differentiated
> >>>>>>>> policies such as content-filter-children,
> >>>>>>>> content-filter-adults-no-porn, content-filter-adults (I'm
> >> taking
> >>>> no
> >>>>>> stand on opt-in vs. opt-out, Mr.
> >>>>>>>> Cameron).   It may be that the same network element (dedicated
> >>>>>> physical
> >>>>>>>> box or virtual network function) realizes all 3 of the example
> >>>>>>>> policies.   The HTTP content filtering network function is
> >> really
> >>>> 3
> >>>>>>>> logical network functions from the perspective of inclusion in
> >> a
> >>>>>> service
> >>>>>>>> chain.   Now extend this to multiple conceptual functions that
> >>>>>> utilize
> >>>>>>>> differentiated policies and the number of combinations will
> >> grow,
> >>>> at
> >>>>>>>> least modestly.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Ron
> >>>>>>>>
> >>>>>>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
> >>>> Behalf
> >>>>>>>> Of *David Allan I
> >>>>>>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >>>>>>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
> nsc@ietf.org
> >>>>>>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>>>>>>>
> >>>>>>>> Saying functions will have a problem with something that
> exists
> >> as
> >>>> a
> >>>>>>>> potential rationale for defining something new with exactly
> the
> >>>> same
> >>>>>>>> properties and problems does not quite work for me....
> >>>>>>>>
> >>>>>>>> VLANs on a vNIC or multiple vNICs (depending on the
> application
> >>>>>> stack
> >>>>>>>> construction and this being combined with application
> >>>> "cooperation"
> >>>>>>>> to preserve pairwise mappings of either VID/NIC tuples or
> >> simply
> >>>>>>>> NICs) currently exist as potential vehicles for preserving
> >> chain
> >>>>>>>> context and avoiding per hop classification. Anything else
> will
> >> be
> >>>>>>>> implemented more or less the same way and have exactly the
> same
> >>>> set
> >>>>>>>> of scaling and application design issues...Some extra
> >> information
> >>>>>>>> available on a single interface, or achieved by mapping chain
> >>>>>>>> instances onto one of a plurality of interfaces....
> >>>>>>>>
> >>>>>>>> But to back up... I'm not a carrier employee but I cannot
> >> envision
> >>>> a
> >>>>>>>> carrier offering potentially 1000s of distinct service bundles
> >>>>>> ("pick
> >>>>>>>> 53 from column A and 49 from column B"). So I suspect a much
> >>>> smaller
> >>>>>>>> number is realistic for  the number of chains a function
> >> instance
> >>>> is
> >>>>>>>> expected to participate in, even allowing for dynamic
> >>>>>>>> reclassification of flows at a chain ingress to "skip a few
> >>>>>>>> functions".... These are things that are fully operationalized
> >> in
> >>>>>>>> OSS, have policy associated with, have been industrialized and
> >>>>>>>> demonstrated to work prior to deployment. Going all
> >> combinatorial
> >>>> on
> >>>>>> this will break that big time....
> >>>>>>>>
> >>>>>>>> So are we really discussing a function participating in more
> >> than
> >>>> a
> >>>>>>>> handful of chain instances? And either a plurality of vNICs or
> >>>> VIDs
> >>>>>>>> being actually more than sufficient?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> Dave
> >>>>>>>>
> >>>>>>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >>>>>>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
> >> (Wim)
> >>>>>>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >>>>>>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >>>>>>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >>>>>>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>>>>>>>
> >>>>>>>> indeed
> >>>>>>>>
> >>>>>>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >>>>>>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >>>>>>>> *Date: *Wednesday 24 July 2013 15:54
> >>>>>>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >>>>>>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >>>>>>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >>>>>>>> *Subject: *AW: Service chaining architecture question
> >>>>>>>>
> >>>>>>>> Hi Wim,
> >>>>>>>>
> >>>>>>>> I think not only effectivness/scalability might be a problem
> >> but
> >>>>>> also
> >>>>>>>> the fact that not all applications (service bringing
> functions)
> >>>> are
> >>>>>>>> able to handle packets coming from/going to potentially
> >> thousands
> >>>> of
> >>>>>>>> different VLANs at the same time. VLANs will work in certain
> >>>>>>>> environments but not in all. I see the need for an information
> >>>>>>>> exchange between the application and a mediation layer as
> well.
> >>>>>>>> Ideally this should be as simple as possible without heavy
> >> impact
> >>>> on
> >>>>>>>> the application itself (might be difficult to achieve but from
> >> my
> >>>>>>>> experience it is not very likely, that there will be big
> >> rewrites
> >>>> of
> >>>>>>>> existing applications in order to support the chaining).
> >>>>>>>>
> >>>>>>>>   regards
> >>>>>>>>
> >>>>>>>>      Nic
> >>>>>>>>
> >>>>>>>> --------------------------------------------------------------
> -
> >> ---
> >>>> --
> >>>>>> -
> >>>>>>>> -
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >>>>>>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
> >>>> (Wim)
> >>>>>>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >>>>>>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >>>>>>>> *Betreff:* [nsc] Service chaining architecture question
> >>>>>>>>
> >>>>>>>> I have a basic question with respect to the
> >> architecture/framework
> >>>>>> so
> >>>>>>>> far mentioned in the drafts in NSC. I understand the meta-data
> >> is
> >>>> a
> >>>>>>>> mechanism to avoid multiple re-classifications when the packet
> >>>>>> enters
> >>>>>>>> the NSC domain and identifies the chain of service functions.
> >> Now
> >>>> my
> >>>>>>>> understanding is that the services/applications are unaware of
> >> the
> >>>>>>>> meta-data and that a layer underneath should provide the
> >> mediation
> >>>>>>>> and that we use a well defined interface to the
> >>>> application/service
> >>>>>>>> to indicate the chain. In the context of Cloud/enterprise
> >>>>>> environment
> >>>>>>>> I can see this work given you can use a dedicate VLAN e.g.
> >> within
> >>>>>> the tenant.
> >>>>>>>> However we also try to address residential use cases for
> mobile
> >>>> and
> >>>>>>>> fixed and here this becomes more tricky afais. In the
> >> residential
> >>>>>>>> environment we can't expose a VLAN per application/service per
> >>>> chain
> >>>>>>>> since this would not be very effective. So I am wondering how
> >> we
> >>>>>>>> envision this to work?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> nsc mailing list
> >>>>>>>> nsc@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc
> >>>>>>> _______________________________________________
> >>>>>>> nsc mailing list
> >>>>>>> nsc@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/nsc
> >>>>>> _______________________________________________
> >>>>>> nsc mailing list
> >>>>>> nsc@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/nsc
> >>>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> nsc mailing list
> >>> nsc@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/nsc
> >>>
> >> _______________________________________________
> >> nsc mailing list
> >> nsc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nsc
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc


From smkumar@cisco.com  Thu Jul 25 11:05:44 2013
Return-Path: <smkumar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0DC21F997E for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwSVwd+VtMZi for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:05:39 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B121F9957 for <nsc@ietf.org>; Thu, 25 Jul 2013 11:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18950; q=dns/txt; s=iport; t=1374775539; x=1375985139; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8+f6j3I/IO/UeytzXqKQJtfm/PTiDAGm6om0BM0WimI=; b=Sgjd37SDUfbGbI85Qb3bZFRm+aUhep2uExuZCgQDQMCdrwwlhJ0oHN7L HMRdoosYS3b6D3aflhn6ptij8fv1+l80YHfNtBgdv5X4H2rDE5p+KN8WV JvLSBXHftBWZfn+Dfhq3BUWV53IIYOWSL10OjQU+K5JtAdkopVL6DAbAg 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAC5o8VGtJXG+/2dsb2JhbABSCYMGNVC9YIEXFnSCJAEBAQMBAQEBNy0HCwUHBgEIEQECAQEBAQoDEQkuCxQDBggCBAENBQgTh28GDLl1BI5FA4EEBisHAgSDDG4DlAiOCocagxSBaEI
X-IronPort-AV: E=Sophos;i="4.89,744,1367971200"; d="scan'208";a="239462488"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2013 18:05:37 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6PI5bFI021035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 18:05:37 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 13:05:37 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAEtIAgAF/rQA=
Date: Thu, 25 Jul 2013 18:05:35 +0000
Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF38EE@xmb-aln-x09.cisco.com>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E3F7@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.21.76.153]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2DD00C595B229440BD5CC7FD5EFE2CE4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 18:05:44 -0000

On 7/25/13 6:12 AM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wrote:

>Thanks, all, for a lively discussion on this topic.
>
>One thing that flavors the discussion of network service chaining is the
>definition of "service".   It really means different things to different
>people.   We networking types tend to look at it as a software
>application or software system composed of multiple software applications
>(i.e., an HTTP content filter).   But when I interact with the business
>folks, especially on the operator side, I hear a different notion of
>"service" -- something subscribers pay for, government mandates, etc.
>This is why, IMO, it is defensible to say that the
>HTTP-content-filter-children is a distinct service from
>HTTP-content-filter-adult, even if both are realized on the same server
>by the same software application using the same global URL database.
>
>It does sound like at least some that have chimed in do feel that both
>the general service type (i.e., HTTP content filter) and the policy set
>need to be conveyed in some manner.    How to do this is a set of
>tradeoffs around control plane protocol and data plane encapsulation.
>Without any control plane, both types of information need to be on the
>wire in some form.   I will assume that the policy set identity is
>distinct at each service instance (i.e, policy set 2 at the HTTP content
>filter does not imply the same set of subscribers as policy set 2 at the
>firewall).   I will also assume that the meaning and interpretation of a
>policy set identity is specific to that type of service and probably to
>the vendor that supplied the service.
SK> The last statement is very true and I want add to it a bit: There are
two extremes to this: a) All services in the solution (or in a service
chain) are controlled by the same policy/control planes, in which case the
same policy-id may be relevant across all services. The policy-plane may
organize the policies in that fashion. b) Every service in the solution
(or chain) belongs to a different vendor and they all have their own
policy planes. Obviously the policy-id at one service has no meaning at
another or has a different meaning.
In fact, some services may not even rely on external
classification/policies or meta-data.

>   This is similar to when a PCRF names a PCC rulebase rather than
>supplying the full set of explicit PCC rules.
>    =20
>
>The advantage of a single chain ID that can be interpreted as a sequence
>of {service-type-instance, policy-set} is that it minimizes the
>per-packet encapsulation requirement (i.e., a single GRE key could
>suffice).   The disadvantage that has been pointed out is that global
>coordination of this identity is required and the number of combinations
>could become unwieldy.
>
>Another approach could be to have a new encapsulation that represents a
>stack of 2-tuples {service-ip-address, service-specific-policy-id}, or
>even 3-tuples {service-ip-address, service-type,
>service-specific-policy-id} where the 3-tuple brings the added advantage
>of allowing for multiple dissimilar services realized by the same server
>at the same server ip address.   The advantage of this approach is that
>it avoids the combinatorial explosion problem, but it requires a larger
>and variable length encapsulation.
>
>If the global chain id approach is used, a control plane protocol could
>be used to distribute the definitions of each chain (i.e, each chain is
>really a stack of 2-tuples or 3-tuples, per description above).
SK> Keeping the chain ID (actually, the service path ID) for the purposes
of service forwarding is simple and clean. One can definitely encode these
identifiers to mux a lot of things into it but it will get messy. They are
better solved differently. Since classification is not limited to the
network; a service-plane entity could re-classify and re-steer using a
different service-path based on the re-classification. This
re-classification may be based on the subscriber-policy for instance. In
this sense, a service-path can be influenced while still keeping it simple.
A global chain-id mapped to a unique data-plane-id (service path id)
allows for keeping (service) forwarding path distinct from policy and
other aspects. I do not believe you need large/complex encapsulations.
Yes, you do need control-plane co-ordination, but may not be with all
services, depending on how it is done.


Surendra.


>
>Thanks.
>
>    Ron
>
>-----Original Message-----
>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>Sent: Wednesday, July 24, 2013 7:35 PM
>To: Linda Dunbar
>Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
>Subject: Re: [nsc] Service chaining architecture question
>
>I would not be surprised if we want all three of Service Chain, Service
>Policy, and Subscriber / user identity in the packet.
>If the Chain is in the VLAN / MPLS label, then we can discuss whether the
>other information goes in additional ids of the same type or in a carried
>header.  I can construct arguments for either approach.
>
>It may be easier to just carry the subscriber identity, and used the same
>management systems to assign policies to the devices that care.  I am
>concerned that it may not be practical to use a single policy identifier
>to specify which HTTP rule set to use, which Firewall rule set to use,
>and then which specific policy for other user selected policy
>applications.
>
>Yours,
>Joel
>
>On 7/24/13 7:30 PM, Linda Dunbar wrote:
>> Joel,
>>> -----Original Message-----
>>>
>>> Yes, having the chain ingress node mark the traffic makes good sense.
>>> Having it mark the subscriber identity and the chain to be traversed
>>> seems quite sensible.
>>>
>>> The difference I think I have with Ron is that he proposes to use one
>>> identifier for both entities.
>> [Linda] I hope you don't mean per subscriber identity, do you? With
>> today's PCRF, subscribers are categorized based on their subscription
>> types. Throughout the network, the "subscription types" dictate what
>> service modules their corresponding traffic need to traverse through.
>> Some service modules might need to examine packets deeper (i.e. look
>> into payload) for their intended functions. They may need to extract
>> the "HTTP header" or HTTP messages from one or multiple packets.
>> That causes, as Dave said, a
>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
>>> MPLS labels.
>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>> The subscriber identity could be some bits in the payload.
>>>
>>> And if the existing boxes don't know how to handle that (as seems
>>> likely) then we need a proxy / support function to translate the
>>> common protocol into whatever they used before we got something
>>> generally usable out there.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>>> >
>>> > Agree with Ron that it is better to have fewer nodes in network to
>>> make subscriber-aware policy decisions.
>>> >
>>> > Besides, it is not uncommon for multiple subscribers to share same
>>> sequence of service modules. In this environment, if the network edge
>>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
>>> use Layer 2 or 3 labels to mark the traffic, the subsequent network
>>> nodes can steer traffic to the needed service modules without looking
>>> into "Mega data" or other higher layer fields in the data frames.
>>> >
>>> > This approach can make "service chain" work without making changes
>>> > to
>>> majority of existing deployed network elements.
>>> >
>>> > Linda
>>> >
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> Jim,
>>> >>
>>> >> Yes, that could work, too, conceptually.   But it does require that
>>> >> each coarsely-defined network service have access to a subscriber-
>>> aware
>>> >> policy resolution mechanism.   IMO, it is better to have fewer
>>> network
>>> >> elements making subscriber-aware policy decisions.
>>> >
>>> >
>>> >>
>>> >>     Ron
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>>> >> To: Ron Parker
>>> >> Cc: Joel M. Halpern; nsc@ietf.org
>>> >> Subject: Re: [nsc] Service chaining architecture question
>>> >>
>>> >> Ron,
>>> >> Or alternatively carry the subscriber awareness in metadata
>>> >> thereby utilizing a single chain.
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>>> >> <Ron_Parker@affirmednetworks.com> wrote:
>>> >>
>>> >>> Joel,
>>> >>>
>>> >>> IMO, the primary reason for understanding the subscriber identity
>>> at
>>> >> a network service is to choose from a differentiated set of
>>>policies.
>>> >> I think there is utility and efficiency in driving that selection
>>> from
>>> >> one place -- the network services classifier.     Say there were 2
>>> >> groups of subscribers -- children and adults.   Let's now define 2
>>> >> chains, where the chains have a business-based meaning to the
>>> operator.
>>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>>> filter-
>>> >> adult + Firewall-adult.    The referenced network services are
>>> logical
>>> >> and it is possible, but not required, that multiple logical network
>>> >> services be located at the same IP address or FQDN.     Conveying
>>> the
>>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>>> ID, ...)
>>> >> allows the IP-addressable server that realizes these service(s) to
>>> know
>>> >> two things -- 1) which logical network function should be invoked
>>> and 2)
>>> >> which logical network function is next.
>>> >>>
>>> >>> Thanks.
>>> >>> Ron
>>> >>>
>>> >>> -----Original Message-----
>>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>>> >>> To: Ron Parker
>>> >>> Cc: nsc@ietf.org
>>> >>> Subject: Re: [nsc] Service chaining architecture question
>>> >>>
>>> >>> Ron,
>>> >>>      maybe I am missing something, but you seem to lay out very
>>> nicely
>>> >> the case for wanting both service chain identification and
>>> separately
>>> >> subscriber identification.  Then the HTTP filter can use the
>>> subscriber
>>> >> ID to decide which exact content filtering behavior it should apply.
>>> I
>>> >> would not want to fold that level of detail into the chain
>>> >> identification.
>>> >>>
>>> >>> Yours,
>>> >>> Joel
>>> >>>
>>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>> >>>> Dave,
>>> >>>>
>>> >>>> I agree that the number of chains is unlikely to scale to vast
>>> >> numbers
>>> >>>> (i.e., millions).     And I agree that it is bounded from a
>>> >> practical
>>> >>>> business perspective, as you point out.
>>> >>>>
>>> >>>> You may already be on this page, but I wanted to point out a
>>> >>>> distinction of coarse-grained definition of a service function vs.
>>> >> finer-grained
>>> >>>> definition of a service function.   Consider a service function to
>>> >> be
>>> >>>> logical in such a way that the identity of the logical function
>>> may
>>> >> also
>>> >>>> imply some differentiated behavior.   For example, a conceptual
>>> >> function
>>> >>>> is HTTP content filtering.    This conceptual function can then be
>>> >>>> further instantiated at the logical level based on
>>> >>>> differentiated policies such as content-filter-children,
>>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
>>> no
>>> >> stand on opt-in vs. opt-out, Mr.
>>> >>>> Cameron).   It may be that the same network element (dedicated
>>> >> physical
>>> >>>> box or virtual network function) realizes all 3 of the example
>>> >>>> policies.   The HTTP content filtering network function is really
>>> 3
>>> >>>> logical network functions from the perspective of inclusion in a
>>> >> service
>>> >>>> chain.   Now extend this to multiple conceptual functions that
>>> >> utilize
>>> >>>> differentiated policies and the number of combinations will
>>> >>>> grow,
>>> at
>>> >>>> least modestly.
>>> >>>>
>>> >>>> Thanks,
>>> >>>>
>>> >>>> Ron
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>>> Behalf
>>> >>>> Of *David Allan I
>>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> Saying functions will have a problem with something that exists
>>> >>>> as
>>> a
>>> >>>> potential rationale for defining something new with exactly the
>>> same
>>> >>>> properties and problems does not quite work for me....
>>> >>>>
>>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>>> >> stack
>>> >>>> construction and this being combined with application
>>> "cooperation"
>>> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>>> >>>> NICs) currently exist as potential vehicles for preserving chain
>>> >>>> context and avoiding per hop classification. Anything else will
>>> >>>> be implemented more or less the same way and have exactly the
>>> >>>> same
>>> set
>>> >>>> of scaling and application design issues...Some extra
>>> >>>> information available on a single interface, or achieved by
>>> >>>> mapping chain instances onto one of a plurality of interfaces....
>>> >>>>
>>> >>>> But to back up... I'm not a carrier employee but I cannot
>>> >>>> envision
>>> a
>>> >>>> carrier offering potentially 1000s of distinct service bundles
>>> >> ("pick
>>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>>> smaller
>>> >>>> number is realistic for  the number of chains a function
>>> >>>> instance
>>> is
>>> >>>> expected to participate in, even allowing for dynamic
>>> >>>> reclassification of flows at a chain ingress to "skip a few
>>> >>>> functions".... These are things that are fully operationalized
>>> >>>> in OSS, have policy associated with, have been industrialized
>>> >>>> and demonstrated to work prior to deployment. Going all
>>> >>>> combinatorial
>>> on
>>> >> this will break that big time....
>>> >>>>
>>> >>>> So are we really discussing a function participating in more
>>> >>>> than
>>> a
>>> >>>> handful of chain instances? And either a plurality of vNICs or
>>> VIDs
>>> >>>> being actually more than sufficient?
>>> >>>>
>>> >>>> Thanks
>>> >>>>
>>> >>>> Dave
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>>> >>>> (Wim)
>>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> indeed
>>> >>>>
>>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>> >>>> *Date: *Wednesday 24 July 2013 15:54
>>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>> >>>> *Subject: *AW: Service chaining architecture question
>>> >>>>
>>> >>>> Hi Wim,
>>> >>>>
>>> >>>> I think not only effectivness/scalability might be a problem but
>>> >> also
>>> >>>> the fact that not all applications (service bringing functions)
>>> are
>>> >>>> able to handle packets coming from/going to potentially
>>> >>>> thousands
>>> of
>>> >>>> different VLANs at the same time. VLANs will work in certain
>>> >>>> environments but not in all. I see the need for an information
>>> >>>> exchange between the application and a mediation layer as well.
>>> >>>> Ideally this should be as simple as possible without heavy
>>> >>>> impact
>>> on
>>> >>>> the application itself (might be difficult to achieve but from
>>> >>>> my experience it is not very likely, that there will be big
>>> >>>> rewrites
>>> of
>>> >>>> existing applications in order to support the chaining).
>>> >>>>
>>> >>>>    regards
>>> >>>>
>>> >>>>       Nic
>>> >>>>
>>> >>>> ----------------------------------------------------------------
>>> >>>> --
>>> --
>>> >> -
>>> >>>> -
>>> >>>> --
>>> >>>>
>>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>>> (Wim)
>>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Betreff:* [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> I have a basic question with respect to the
>>> >>>> architecture/framework
>>> >> so
>>> >>>> far mentioned in the drafts in NSC. I understand the meta-data
>>> >>>> is
>>> a
>>> >>>> mechanism to avoid multiple re-classifications when the packet
>>> >> enters
>>> >>>> the NSC domain and identifies the chain of service functions.
>>> >>>> Now
>>> my
>>> >>>> understanding is that the services/applications are unaware of
>>> >>>> the meta-data and that a layer underneath should provide the
>>> >>>> mediation and that we use a well defined interface to the
>>> application/service
>>> >>>> to indicate the chain. In the context of Cloud/enterprise
>>> >> environment
>>> >>>> I can see this work given you can use a dedicate VLAN e.g.
>>> >>>> within
>>> >> the tenant.
>>> >>>> However we also try to address residential use cases for mobile
>>> and
>>> >>>> fixed and here this becomes more tricky afais. In the
>>> >>>> residential environment we can't expose a VLAN per
>>> >>>> application/service per
>>> chain
>>> >>>> since this would not be very effective. So I am wondering how we
>>> >>>> envision this to work?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> nsc mailing list
>>> >>>> nsc@ietf.org
>>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>>> >>> _______________________________________________
>>> >>> nsc mailing list
>>> >>> nsc@ietf.org
>>> >>>https://www.ietf.org/mailman/listinfo/nsc
>>> >> _______________________________________________
>>> >> nsc mailing list
>>> >> nsc@ietf.org
>>> >>https://www.ietf.org/mailman/listinfo/nsc
>>> >
>>
>>
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From smkumar@cisco.com  Thu Jul 25 11:32:48 2013
Return-Path: <smkumar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9E821F859A for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcluxer-ZTxg for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:32:43 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5E721F844D for <nsc@ietf.org>; Thu, 25 Jul 2013 11:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18026; q=dns/txt; s=iport; t=1374777163; x=1375986763; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kk7z8rl2CKijZinU2tG7XQfm8o+KtAoacbKyxU5BEzc=; b=Woi4SRSOusGKzfb5Z8UUGDwyjJ8she2MwxRv9CQYJSlHS6dfn2ESo2BE O/NxrvfuOzfV0itH4aSc6EDRtgojxeH7Z0jPcaYen/OqO9RvJ3PdivsVI OFfoEk9xG00i6CTA05v1P6dWjCTaqpT1tkNBfY+10T/ZlCEWmn+IxS+P1 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAHhu8VGtJXG+/2dsb2JhbABSCYMGNVC9YYEXFnSCJAEBAQQBAQE3LQcLDAYBCBEBAgEBAQEKAwgJCS4LFAMGCAIEAQ0FCIgIDLl5BI5FA4ECAgYrBwIEBIMIbgOUCI4KhxqDFIFoQg
X-IronPort-AV: E=Sophos;i="4.89,744,1367971200"; d="scan'208";a="239523070"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2013 18:32:42 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6PIWgvw031999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 18:32:42 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 13:32:41 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAABstAIAAZEsA
Date: Thu, 25 Jul 2013 18:32:40 +0000
Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF393F@xmb-aln-x09.cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E0120863D@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.21.76.153]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AC316806D29CFB4E8CA47FD6CC77D59D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 18:32:48 -0000

On 7/25/13 11:33 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

>Hi Paul,
>
>> > Yes. We should separate signaling of network connectivity from
>> metadata associated with the payload. These are two separate problems.
>> In a data center, some VMs will be participating in service chains,
>> some not, at a given time. We don't want to end up with two different
>> forwarding paradigms for both types of those VMs.
>> >
>>=20
>> IMHO, you want to separate both chaining information and metadata.  The
>> chain information is used to provide a form of indirection into the
>> existing forward models.
>
>Could you clarify what you mean by "a form of indirection into the
>existing forward models",
>especially in the scenario of virtualized servers (services running in
>VMs)?=20
>
>>=20
>> >> then we can discuss whether the other information goes in additional
>> ids of the same type or in a
>> >> carried header.  I can construct arguments for either approach.
>> >
>> > We should avoid introducing a new header for carrying metadata (such
>> as subscriber-id). The same result can be achieved by using the IP
>> header of the payload packet (such as IP option or flow label).
>> >
>>=20
>> Adding data to existing IP headers might not prove viable, most fields
>> are either spoken for, or have significant technical limitations.  For
>> example, IP options are usually filtered/dropped and rarely handled in
>> the fast path for forwarding.
>
>IMO, services should be deployed on the "edge" of the network in
>software. There is only one type of forwarding in software.
SK> Services should be "deployable" in software and so should they be in
physical appliances - we need to account for them given the
transitional/hybrid data centers that exist today, as one reason.

Surendra.

>=20
>
>>=20
>> >> It may be easier to just carry the subscriber identity, and used the
>> >> same management systems to assign policies to the devices that care.
>> I
>> >> am concerned that it may not be practical to use a single policy
>> >> identifier to specify which HTTP rule set to use, which Firewall
>> rule
>> >> set to use, and then which specific policy for other user selected
>> >> policy applications.
>> >
>> > Agree. Or use a *local* (to a given appliance) logical interface per
>> service "profile" but. Typically though, a "service" would be realized
>> by software and the goal would be to run it on a VM of a virtualized
>> x86 server. It is cheap to spin a VM. So, instead of having different
>> profiles in the same VM it will be much simpler to manage a larger
>> number of VMs, each with limited bandwidth.
>> >
>>=20
>> In many environments, physical and/or shared services must be supported
>> as well for a variety of reasons.
>
>If a physical (typically, legacy) device needs to participate in a
>service chain, I would proxy it.
>
>Maria
>=20
>>=20
>> > Maria
>> >
>> >>
>> >> On 7/24/13 7:30 PM, Linda Dunbar wrote:
>> >>> Joel,
>> >>>> -----Original Message-----
>> >>>>
>> >>>> Yes, having the chain ingress node mark the traffic makes good
>> >> sense.
>> >>>> Having it mark the subscriber identity and the chain to be
>> traversed
>> >>>> seems quite sensible.
>> >>>>
>> >>>> The difference I think I have with Ron is that he proposes to use
>> >> one
>> >>>> identifier for both entities.
>> >>> [Linda] I hope you don't mean per subscriber identity, do you? With
>> >>> today's PCRF, subscribers are categorized based on their
>> subscription
>> >>> types. Throughout the network, the "subscription types" dictate
>> what
>> >>> service modules their corresponding traffic need to traverse
>> through.
>> >>> Some service modules might need to examine packets deeper (i.e.
>> look
>> >>> into payload) for their intended functions. They may need to
>> extract
>> >> the
>> >>> "HTTP header" or HTTP messages from one or multiple packets.
>> >>> That causes, as Dave said, a
>> >>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
>> >> MPLS
>> >>>> labels.
>> >>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>> >>> The subscriber identity could be some bits in the payload.
>> >>>>
>> >>>> And if the existing boxes don't know how to handle that (as seems
>> >>>> likely) then we need a proxy / support function to translate the
>> >> common
>> >>>> protocol into whatever they used before we got something generally
>> >>>> usable out there.
>> >>>>
>> >>>> Yours,
>> >>>> Joel
>> >>>>
>> >>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>> >>>>>
>> >>>>> Agree with Ron that it is better to have fewer nodes in network
>> to
>> >>>> make subscriber-aware policy decisions.
>> >>>>>
>> >>>>> Besides, it is not uncommon for multiple subscribers to share
>> same
>> >>>> sequence of service modules. In this environment, if the network
>> >> edge
>> >>>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
>> >> use
>> >>>> Layer 2 or 3 labels to mark the traffic, the subsequent network
>> >> nodes
>> >>>> can steer traffic to the needed service modules without looking
>> into
>> >>>> "Mega data" or other higher layer fields in the data frames.
>> >>>>>
>> >>>>> This approach can make "service chain" work without making
>> changes
>> >> to
>> >>>> majority of existing deployed network elements.
>> >>>>>
>> >>>>> Linda
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> Jim,
>> >>>>>>
>> >>>>>> Yes, that could work, too, conceptually.   But it does require
>> >> that
>> >>>>>> each coarsely-defined network service have access to a
>> >> subscriber-
>> >>>> aware
>> >>>>>> policy resolution mechanism.   IMO, it is better to have fewer
>> >>>> network
>> >>>>>> elements making subscriber-aware policy decisions.
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>>    Ron
>> >>>>>>
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >>>>>> Sent: Wednesday, July 24, 2013 6:17 PM
>> >>>>>> To: Ron Parker
>> >>>>>> Cc: Joel M. Halpern; nsc@ietf.org
>> >>>>>> Subject: Re: [nsc] Service chaining architecture question
>> >>>>>>
>> >>>>>> Ron,
>> >>>>>> Or alternatively carry the subscriber awareness in metadata
>> >> thereby
>> >>>>>> utilizing a single chain.
>> >>>>>>
>> >>>>>> Sent from my iPhone
>> >>>>>>
>> >>>>>> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>> >>>>>> <Ron_Parker@affirmednetworks.com> wrote:
>> >>>>>>
>> >>>>>>> Joel,
>> >>>>>>>
>> >>>>>>> IMO, the primary reason for understanding the subscriber
>> >> identity
>> >>>> at
>> >>>>>> a network service is to choose from a differentiated set of
>> >> policies.
>> >>>>>> I think there is utility and efficiency in driving that
>> selection
>> >>>> from
>> >>>>>> one place -- the network services classifier.     Say there were
>> >> 2
>> >>>>>> groups of subscribers -- children and adults.   Let's now define
>> >> 2
>> >>>>>> chains, where the chains have a business-based meaning to the
>> >>>> operator.
>> >>>>>> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTT=
P-
>> >>>> filter-
>> >>>>>> adult + Firewall-adult.    The referenced network services are
>> >>>> logical
>> >>>>>> and it is possible, but not required, that multiple logical
>> >> network
>> >>>>>> services be located at the same IP address or FQDN.
>> Conveying
>> >>>> the
>> >>>>>> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>> >>>> ID, ...)
>> >>>>>> allows the IP-addressable server that realizes these service(s)
>> >> to
>> >>>> know
>> >>>>>> two things -- 1) which logical network function should be
>> invoked
>> >>>> and 2)
>> >>>>>> which logical network function is next.
>> >>>>>>>
>> >>>>>>> Thanks.
>> >>>>>>> Ron
>> >>>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> >>>>>>> Sent: Wednesday, July 24, 2013 4:47 PM
>> >>>>>>> To: Ron Parker
>> >>>>>>> Cc: nsc@ietf.org
>> >>>>>>> Subject: Re: [nsc] Service chaining architecture question
>> >>>>>>>
>> >>>>>>> Ron,
>> >>>>>>>     maybe I am missing something, but you seem to lay out very
>> >>>> nicely
>> >>>>>> the case for wanting both service chain identification and
>> >>>> separately
>> >>>>>> subscriber identification.  Then the HTTP filter can use the
>> >>>> subscriber
>> >>>>>> ID to decide which exact content filtering behavior it should
>> >> apply.
>> >>>> I
>> >>>>>> would not want to fold that level of detail into the chain
>> >>>>>> identification.
>> >>>>>>>
>> >>>>>>> Yours,
>> >>>>>>> Joel
>> >>>>>>>
>> >>>>>>> On 7/24/13 4:05 PM, Ron Parker wrote:
>> >>>>>>>> Dave,
>> >>>>>>>>
>> >>>>>>>> I agree that the number of chains is unlikely to scale to vast
>> >>>>>> numbers
>> >>>>>>>> (i.e., millions).     And I agree that it is bounded from a
>> >>>>>> practical
>> >>>>>>>> business perspective, as you point out.
>> >>>>>>>>
>> >>>>>>>> You may already be on this page, but I wanted to point out a
>> >>>>>>>> distinction of coarse-grained definition of a service function
>> >> vs.
>> >>>>>> finer-grained
>> >>>>>>>> definition of a service function.   Consider a service
>> function
>> >> to
>> >>>>>> be
>> >>>>>>>> logical in such a way that the identity of the logical
>> function
>> >>>> may
>> >>>>>> also
>> >>>>>>>> imply some differentiated behavior.   For example, a
>> conceptual
>> >>>>>> function
>> >>>>>>>> is HTTP content filtering.    This conceptual function can
>> then
>> >> be
>> >>>>>>>> further instantiated at the logical level based on
>> >> differentiated
>> >>>>>>>> policies such as content-filter-children,
>> >>>>>>>> content-filter-adults-no-porn, content-filter-adults (I'm
>> >> taking
>> >>>> no
>> >>>>>> stand on opt-in vs. opt-out, Mr.
>> >>>>>>>> Cameron).   It may be that the same network element (dedicated
>> >>>>>> physical
>> >>>>>>>> box or virtual network function) realizes all 3 of the example
>> >>>>>>>> policies.   The HTTP content filtering network function is
>> >> really
>> >>>> 3
>> >>>>>>>> logical network functions from the perspective of inclusion in
>> >> a
>> >>>>>> service
>> >>>>>>>> chain.   Now extend this to multiple conceptual functions that
>> >>>>>> utilize
>> >>>>>>>> differentiated policies and the number of combinations will
>> >> grow,
>> >>>> at
>> >>>>>>>> least modestly.
>> >>>>>>>>
>> >>>>>>>> Thanks,
>> >>>>>>>>
>> >>>>>>>> Ron
>> >>>>>>>>
>> >>>>>>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>> >>>> Behalf
>> >>>>>>>> Of *David Allan I
>> >>>>>>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> >>>>>>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
>> nsc@ietf.org
>> >>>>>>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>>>>>
>> >>>>>>>> Saying functions will have a problem with something that
>> exists
>> >> as
>> >>>> a
>> >>>>>>>> potential rationale for defining something new with exactly
>> the
>> >>>> same
>> >>>>>>>> properties and problems does not quite work for me....
>> >>>>>>>>
>> >>>>>>>> VLANs on a vNIC or multiple vNICs (depending on the
>> application
>> >>>>>> stack
>> >>>>>>>> construction and this being combined with application
>> >>>> "cooperation"
>> >>>>>>>> to preserve pairwise mappings of either VID/NIC tuples or
>> >> simply
>> >>>>>>>> NICs) currently exist as potential vehicles for preserving
>> >> chain
>> >>>>>>>> context and avoiding per hop classification. Anything else
>> will
>> >> be
>> >>>>>>>> implemented more or less the same way and have exactly the
>> same
>> >>>> set
>> >>>>>>>> of scaling and application design issues...Some extra
>> >> information
>> >>>>>>>> available on a single interface, or achieved by mapping chain
>> >>>>>>>> instances onto one of a plurality of interfaces....
>> >>>>>>>>
>> >>>>>>>> But to back up... I'm not a carrier employee but I cannot
>> >> envision
>> >>>> a
>> >>>>>>>> carrier offering potentially 1000s of distinct service bundles
>> >>>>>> ("pick
>> >>>>>>>> 53 from column A and 49 from column B"). So I suspect a much
>> >>>> smaller
>> >>>>>>>> number is realistic for  the number of chains a function
>> >> instance
>> >>>> is
>> >>>>>>>> expected to participate in, even allowing for dynamic
>> >>>>>>>> reclassification of flows at a chain ingress to "skip a few
>> >>>>>>>> functions".... These are things that are fully operationalized
>> >> in
>> >>>>>>>> OSS, have policy associated with, have been industrialized and
>> >>>>>>>> demonstrated to work prior to deployment. Going all
>> >> combinatorial
>> >>>> on
>> >>>>>> this will break that big time....
>> >>>>>>>>
>> >>>>>>>> So are we really discussing a function participating in more
>> >> than
>> >>>> a
>> >>>>>>>> handful of chain instances? And either a plurality of vNICs or
>> >>>> VIDs
>> >>>>>>>> being actually more than sufficient?
>> >>>>>>>>
>> >>>>>>>> Thanks
>> >>>>>>>>
>> >>>>>>>> Dave
>> >>>>>>>>
>> >>>>>>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >>>>>>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>> >> (Wim)
>> >>>>>>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> >>>>>>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>> >>>>>>>> nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>>>>>> *Subject:* Re: [nsc] Service chaining architecture question
>> >>>>>>>>
>> >>>>>>>> indeed
>> >>>>>>>>
>> >>>>>>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> >>>>>>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> >>>>>>>> *Date: *Wednesday 24 July 2013 15:54
>> >>>>>>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> >>>>>>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>> >>>>>>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> >>>>>>>> *Subject: *AW: Service chaining architecture question
>> >>>>>>>>
>> >>>>>>>> Hi Wim,
>> >>>>>>>>
>> >>>>>>>> I think not only effectivness/scalability might be a problem
>> >> but
>> >>>>>> also
>> >>>>>>>> the fact that not all applications (service bringing
>> functions)
>> >>>> are
>> >>>>>>>> able to handle packets coming from/going to potentially
>> >> thousands
>> >>>> of
>> >>>>>>>> different VLANs at the same time. VLANs will work in certain
>> >>>>>>>> environments but not in all. I see the need for an information
>> >>>>>>>> exchange between the application and a mediation layer as
>> well.
>> >>>>>>>> Ideally this should be as simple as possible without heavy
>> >> impact
>> >>>> on
>> >>>>>>>> the application itself (might be difficult to achieve but from
>> >> my
>> >>>>>>>> experience it is not very likely, that there will be big
>> >> rewrites
>> >>>> of
>> >>>>>>>> existing applications in order to support the chaining).
>> >>>>>>>>
>> >>>>>>>>   regards
>> >>>>>>>>
>> >>>>>>>>      Nic
>> >>>>>>>>
>> >>>>>>>> --------------------------------------------------------------
>> -
>> >> ---
>> >>>> --
>> >>>>>> -
>> >>>>>>>> -
>> >>>>>>>> --
>> >>>>>>>>
>> >>>>>>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> >>>>>>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>> >>>> (Wim)
>> >>>>>>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> >>>>>>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> >>>>>>>> *Betreff:* [nsc] Service chaining architecture question
>> >>>>>>>>
>> >>>>>>>> I have a basic question with respect to the
>> >> architecture/framework
>> >>>>>> so
>> >>>>>>>> far mentioned in the drafts in NSC. I understand the meta-data
>> >> is
>> >>>> a
>> >>>>>>>> mechanism to avoid multiple re-classifications when the packet
>> >>>>>> enters
>> >>>>>>>> the NSC domain and identifies the chain of service functions.
>> >> Now
>> >>>> my
>> >>>>>>>> understanding is that the services/applications are unaware of
>> >> the
>> >>>>>>>> meta-data and that a layer underneath should provide the
>> >> mediation
>> >>>>>>>> and that we use a well defined interface to the
>> >>>> application/service
>> >>>>>>>> to indicate the chain. In the context of Cloud/enterprise
>> >>>>>> environment
>> >>>>>>>> I can see this work given you can use a dedicate VLAN e.g.
>> >> within
>> >>>>>> the tenant.
>> >>>>>>>> However we also try to address residential use cases for
>> mobile
>> >>>> and
>> >>>>>>>> fixed and here this becomes more tricky afais. In the
>> >> residential
>> >>>>>>>> environment we can't expose a VLAN per application/service per
>> >>>> chain
>> >>>>>>>> since this would not be very effective. So I am wondering how
>> >> we
>> >>>>>>>> envision this to work?
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> nsc mailing list
>> >>>>>>>> nsc@ietf.org
>> >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc
>> >>>>>>> _______________________________________________
>> >>>>>>> nsc mailing list
>> >>>>>>> nsc@ietf.org
>> >>>>>>> https://www.ietf.org/mailman/listinfo/nsc
>> >>>>>> _______________________________________________
>> >>>>>> nsc mailing list
>> >>>>>> nsc@ietf.org
>> >>>>>> https://www.ietf.org/mailman/listinfo/nsc
>> >>>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> nsc mailing list
>> >>> nsc@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/nsc
>> >>>
>> >> _______________________________________________
>> >> nsc mailing list
>> >> nsc@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/nsc
>> > _______________________________________________
>> > nsc mailing list
>> > nsc@ietf.org
>> > https://www.ietf.org/mailman/listinfo/nsc
>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From smkumar@cisco.com  Thu Jul 25 11:49:41 2013
Return-Path: <smkumar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F821F860B for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYAeKU5CjSX2 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 11:49:36 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFEA21F844E for <nsc@ietf.org>; Thu, 25 Jul 2013 11:49:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19391; q=dns/txt; s=iport; t=1374778176; x=1375987776; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jqRfPCbh+tAxFYq7dLy8IyNscyDVbQS5R7ByAysB408=; b=k1bHNG8oeK4X6HEOxw6j6AQ3M3WhOSPGzRDNg6I7n32HXtq6lCVPaZId FIWhNQ0w2eTkCCWXmCFUlKhzEl4OX5DAzeGBVW5Dend9OSSMoEKBhgxHt QK43qHEvbqhtf3xGhLRmzVaDx4WDAeRswAjZ1ECbTak1N1yE+ummk4Evq c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAPJy8VGtJV2Z/2dsb2JhbABSCYMGNVC9YYEXFnSCJAEBAQQBAQE3LQcLDAYBCBEBAgEBAQEKAxEJLgsUAwYIAgQBDQUIiAgMuX4EjkWBBwYrBwIEgwxuA5QIjgqHGoMUgio
X-IronPort-AV: E=Sophos;i="4.89,744,1367971200"; d="scan'208";a="236510330"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2013 18:49:23 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6PInN7X028128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 18:49:23 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 13:49:22 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: David Allan I <david.i.allan@ericsson.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAEtIAgAAMH4CAAX/IgA==
Date: Thu, 25 Jul 2013 18:49:21 +0000
Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF3964@xmb-aln-x09.cisco.com>
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C115D697E@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.21.76.153]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C1464DD259128D408D6AD10556091662@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 18:49:41 -0000

On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:

>I would prefer to think what is on the wire facilitates the forwarding of
>frames, e.g. chain ID (analogous to VPN), perhaps an entropy shorthand to
>help both LB and  testabilty....and facilitates uniquely identifying the
>subscriber. (within the bounds of the art of the possible, see my last
>post on NAT). I cannot envision a need for more. And ideally I should be
>able to align such an approach with existing Cloud technologies.
SK> For entropy you are better off choosing the right transport and
relying on that than the chain-id.
>
>The individual VF should be able to determine actual subscriber to a
>granularity suitable for it's purposes and obtain the necessary profile
>information via a northbound interface. If you then read between the
>lines,  I'm all for separation of concerns as much as possible ;-) and
>not creating dependencies across chain components beyond the networking
>level.
SK> Agree but I would add that subscriber identification may require
policy-plane interaction and if it is done once in the chain, the rest of
the chain can benefit from it.

Surendra.
>
>I also do not see a huge difference between a service chain, and any
>other flow of information across a string of processing elements. Just in
>one application, the packet is preserved with perhaps a bit of fondling,
>and in others the content may be completely deconstructed, and repackaged
>into a set of transactions....and what is on the wire between chain
>components does not remotely look like what went in the front end...
>
>Cheers
>Dave
>
>
>
>
>
>
>-----Original Message-----
>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron
>Parker
>Sent: Wednesday, July 24, 2013 5:42 PM
>To: Joel M. Halpern; Linda Dunbar
>Cc: nsc@ietf.org; Jim Guichard (jguichar)
>Subject: Re: [nsc] Service chaining architecture question
>
>Thanks, all, for a lively discussion on this topic.
>
>One thing that flavors the discussion of network service chaining is the
>definition of "service".   It really means different things to different
>people.   We networking types tend to look at it as a software
>application or software system composed of multiple software applications
>(i.e., an HTTP content filter).   But when I interact with the business
>folks, especially on the operator side, I hear a different notion of
>"service" -- something subscribers pay for, government mandates, etc.
>This is why, IMO, it is defensible to say that the
>HTTP-content-filter-children is a distinct service from
>HTTP-content-filter-adult, even if both are realized on the same server
>by the same software application using the same global URL database.
>
>It does sound like at least some that have chimed in do feel that both
>the general service type (i.e., HTTP content filter) and the policy set
>need to be conveyed in some manner.    How to do this is a set of
>tradeoffs around control plane protocol and data plane encapsulation.
>Without any control plane, both types of information need to be on the
>wire in some form.   I will assume that the policy set identity is
>distinct at each service instance (i.e, policy set 2 at the HTTP content
>filter does not imply the same set of subscribers as policy set 2 at the
>firewall).   I will also assume that the meaning and interpretation of a
>policy set identity is specific to that type of service and probably to
>the vendor that supplied the service.   This is similar to when a PCRF
>names a PCC rulebase rather than supplying the full set of explicit PCC
>rules.    =20
>
>The advantage of a single chain ID that can be interpreted as a sequence
>of {service-type-instance, policy-set} is that it minimizes the
>per-packet encapsulation requirement (i.e., a single GRE key could
>suffice).   The disadvantage that has been pointed out is that global
>coordination of this identity is required and the number of combinations
>could become unwieldy.
>
>Another approach could be to have a new encapsulation that represents a
>stack of 2-tuples {service-ip-address, service-specific-policy-id}, or
>even 3-tuples {service-ip-address, service-type,
>service-specific-policy-id} where the 3-tuple brings the added advantage
>of allowing for multiple dissimilar services realized by the same server
>at the same server ip address.   The advantage of this approach is that
>it avoids the combinatorial explosion problem, but it requires a larger
>and variable length encapsulation.
>
>If the global chain id approach is used, a control plane protocol could
>be used to distribute the definitions of each chain (i.e, each chain is
>really a stack of 2-tuples or 3-tuples, per description above).
>
>Thanks.
>
>    Ron
>
>-----Original Message-----
>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>Sent: Wednesday, July 24, 2013 7:35 PM
>To: Linda Dunbar
>Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
>Subject: Re: [nsc] Service chaining architecture question
>
>I would not be surprised if we want all three of Service Chain, Service
>Policy, and Subscriber / user identity in the packet.
>If the Chain is in the VLAN / MPLS label, then we can discuss whether the
>other information goes in additional ids of the same type or in a carried
>header.  I can construct arguments for either approach.
>
>It may be easier to just carry the subscriber identity, and used the same
>management systems to assign policies to the devices that care.  I am
>concerned that it may not be practical to use a single policy identifier
>to specify which HTTP rule set to use, which Firewall rule set to use,
>and then which specific policy for other user selected policy
>applications.
>
>Yours,
>Joel
>
>On 7/24/13 7:30 PM, Linda Dunbar wrote:
>> Joel,
>>> -----Original Message-----
>>>
>>> Yes, having the chain ingress node mark the traffic makes good sense.
>>> Having it mark the subscriber identity and the chain to be traversed
>>> seems quite sensible.
>>>
>>> The difference I think I have with Ron is that he proposes to use one
>>> identifier for both entities.
>> [Linda] I hope you don't mean per subscriber identity, do you? With
>> today's PCRF, subscribers are categorized based on their subscription
>> types. Throughout the network, the "subscription types" dictate what
>> service modules their corresponding traffic need to traverse through.
>> Some service modules might need to examine packets deeper (i.e. look
>> into payload) for their intended functions. They may need to extract
>> the "HTTP header" or HTTP messages from one or multiple packets.
>> That causes, as Dave said, a
>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
>>> MPLS labels.
>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>> The subscriber identity could be some bits in the payload.
>>>
>>> And if the existing boxes don't know how to handle that (as seems
>>> likely) then we need a proxy / support function to translate the
>>> common protocol into whatever they used before we got something
>>> generally usable out there.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>>> >
>>> > Agree with Ron that it is better to have fewer nodes in network to
>>> make subscriber-aware policy decisions.
>>> >
>>> > Besides, it is not uncommon for multiple subscribers to share same
>>> sequence of service modules. In this environment, if the network edge
>>> nodes, such as Broadband Network Gateway or Cell Site Gateway, can
>>> use Layer 2 or 3 labels to mark the traffic, the subsequent network
>>> nodes can steer traffic to the needed service modules without looking
>>> into "Mega data" or other higher layer fields in the data frames.
>>> >
>>> > This approach can make "service chain" work without making changes
>>> > to
>>> majority of existing deployed network elements.
>>> >
>>> > Linda
>>> >
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> Jim,
>>> >>
>>> >> Yes, that could work, too, conceptually.   But it does require that
>>> >> each coarsely-defined network service have access to a subscriber-
>>> aware
>>> >> policy resolution mechanism.   IMO, it is better to have fewer
>>> network
>>> >> elements making subscriber-aware policy decisions.
>>> >
>>> >
>>> >>
>>> >>     Ron
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>>> >> To: Ron Parker
>>> >> Cc: Joel M. Halpern; nsc@ietf.org
>>> >> Subject: Re: [nsc] Service chaining architecture question
>>> >>
>>> >> Ron,
>>> >> Or alternatively carry the subscriber awareness in metadata
>>> >> thereby utilizing a single chain.
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>>> >> <Ron_Parker@affirmednetworks.com> wrote:
>>> >>
>>> >>> Joel,
>>> >>>
>>> >>> IMO, the primary reason for understanding the subscriber identity
>>> at
>>> >> a network service is to choose from a differentiated set of
>>>policies.
>>> >> I think there is utility and efficiency in driving that selection
>>> from
>>> >> one place -- the network services classifier.     Say there were 2
>>> >> groups of subscribers -- children and adults.   Let's now define 2
>>> >> chains, where the chains have a business-based meaning to the
>>> operator.
>>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>>> filter-
>>> >> adult + Firewall-adult.    The referenced network services are
>>> logical
>>> >> and it is possible, but not required, that multiple logical network
>>> >> services be located at the same IP address or FQDN.     Conveying
>>> the
>>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>>> ID, ...)
>>> >> allows the IP-addressable server that realizes these service(s) to
>>> know
>>> >> two things -- 1) which logical network function should be invoked
>>> and 2)
>>> >> which logical network function is next.
>>> >>>
>>> >>> Thanks.
>>> >>> Ron
>>> >>>
>>> >>> -----Original Message-----
>>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>>> >>> To: Ron Parker
>>> >>> Cc: nsc@ietf.org
>>> >>> Subject: Re: [nsc] Service chaining architecture question
>>> >>>
>>> >>> Ron,
>>> >>>      maybe I am missing something, but you seem to lay out very
>>> nicely
>>> >> the case for wanting both service chain identification and
>>> separately
>>> >> subscriber identification.  Then the HTTP filter can use the
>>> subscriber
>>> >> ID to decide which exact content filtering behavior it should apply.
>>> I
>>> >> would not want to fold that level of detail into the chain
>>> >> identification.
>>> >>>
>>> >>> Yours,
>>> >>> Joel
>>> >>>
>>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>> >>>> Dave,
>>> >>>>
>>> >>>> I agree that the number of chains is unlikely to scale to vast
>>> >> numbers
>>> >>>> (i.e., millions).     And I agree that it is bounded from a
>>> >> practical
>>> >>>> business perspective, as you point out.
>>> >>>>
>>> >>>> You may already be on this page, but I wanted to point out a
>>> >>>> distinction of coarse-grained definition of a service function vs.
>>> >> finer-grained
>>> >>>> definition of a service function.   Consider a service function to
>>> >> be
>>> >>>> logical in such a way that the identity of the logical function
>>> may
>>> >> also
>>> >>>> imply some differentiated behavior.   For example, a conceptual
>>> >> function
>>> >>>> is HTTP content filtering.    This conceptual function can then be
>>> >>>> further instantiated at the logical level based on
>>> >>>> differentiated policies such as content-filter-children,
>>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm taking
>>> no
>>> >> stand on opt-in vs. opt-out, Mr.
>>> >>>> Cameron).   It may be that the same network element (dedicated
>>> >> physical
>>> >>>> box or virtual network function) realizes all 3 of the example
>>> >>>> policies.   The HTTP content filtering network function is really
>>> 3
>>> >>>> logical network functions from the perspective of inclusion in a
>>> >> service
>>> >>>> chain.   Now extend this to multiple conceptual functions that
>>> >> utilize
>>> >>>> differentiated policies and the number of combinations will
>>> >>>> grow,
>>> at
>>> >>>> least modestly.
>>> >>>>
>>> >>>> Thanks,
>>> >>>>
>>> >>>> Ron
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>>> Behalf
>>> >>>> Of *David Allan I
>>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> Saying functions will have a problem with something that exists
>>> >>>> as
>>> a
>>> >>>> potential rationale for defining something new with exactly the
>>> same
>>> >>>> properties and problems does not quite work for me....
>>> >>>>
>>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>>> >> stack
>>> >>>> construction and this being combined with application
>>> "cooperation"
>>> >>>> to preserve pairwise mappings of either VID/NIC tuples or simply
>>> >>>> NICs) currently exist as potential vehicles for preserving chain
>>> >>>> context and avoiding per hop classification. Anything else will
>>> >>>> be implemented more or less the same way and have exactly the
>>> >>>> same
>>> set
>>> >>>> of scaling and application design issues...Some extra
>>> >>>> information available on a single interface, or achieved by
>>> >>>> mapping chain instances onto one of a plurality of interfaces....
>>> >>>>
>>> >>>> But to back up... I'm not a carrier employee but I cannot
>>> >>>> envision
>>> a
>>> >>>> carrier offering potentially 1000s of distinct service bundles
>>> >> ("pick
>>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>>> smaller
>>> >>>> number is realistic for  the number of chains a function
>>> >>>> instance
>>> is
>>> >>>> expected to participate in, even allowing for dynamic
>>> >>>> reclassification of flows at a chain ingress to "skip a few
>>> >>>> functions".... These are things that are fully operationalized
>>> >>>> in OSS, have policy associated with, have been industrialized
>>> >>>> and demonstrated to work prior to deployment. Going all
>>> >>>> combinatorial
>>> on
>>> >> this will break that big time....
>>> >>>>
>>> >>>> So are we really discussing a function participating in more
>>> >>>> than
>>> a
>>> >>>> handful of chain instances? And either a plurality of vNICs or
>>> VIDs
>>> >>>> being actually more than sufficient?
>>> >>>>
>>> >>>> Thanks
>>> >>>>
>>> >>>> Dave
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>>> >>>> (Wim)
>>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> indeed
>>> >>>>
>>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>> >>>> *Date: *Wednesday 24 July 2013 15:54
>>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>> >>>> *Subject: *AW: Service chaining architecture question
>>> >>>>
>>> >>>> Hi Wim,
>>> >>>>
>>> >>>> I think not only effectivness/scalability might be a problem but
>>> >> also
>>> >>>> the fact that not all applications (service bringing functions)
>>> are
>>> >>>> able to handle packets coming from/going to potentially
>>> >>>> thousands
>>> of
>>> >>>> different VLANs at the same time. VLANs will work in certain
>>> >>>> environments but not in all. I see the need for an information
>>> >>>> exchange between the application and a mediation layer as well.
>>> >>>> Ideally this should be as simple as possible without heavy
>>> >>>> impact
>>> on
>>> >>>> the application itself (might be difficult to achieve but from
>>> >>>> my experience it is not very likely, that there will be big
>>> >>>> rewrites
>>> of
>>> >>>> existing applications in order to support the chaining).
>>> >>>>
>>> >>>>    regards
>>> >>>>
>>> >>>>       Nic
>>> >>>>
>>> >>>> ----------------------------------------------------------------
>>> >>>> --
>>> --
>>> >> -
>>> >>>> -
>>> >>>> --
>>> >>>>
>>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>>> (Wim)
>>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Betreff:* [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> I have a basic question with respect to the
>>> >>>> architecture/framework
>>> >> so
>>> >>>> far mentioned in the drafts in NSC. I understand the meta-data
>>> >>>> is
>>> a
>>> >>>> mechanism to avoid multiple re-classifications when the packet
>>> >> enters
>>> >>>> the NSC domain and identifies the chain of service functions.
>>> >>>> Now
>>> my
>>> >>>> understanding is that the services/applications are unaware of
>>> >>>> the meta-data and that a layer underneath should provide the
>>> >>>> mediation and that we use a well defined interface to the
>>> application/service
>>> >>>> to indicate the chain. In the context of Cloud/enterprise
>>> >> environment
>>> >>>> I can see this work given you can use a dedicate VLAN e.g.
>>> >>>> within
>>> >> the tenant.
>>> >>>> However we also try to address residential use cases for mobile
>>> and
>>> >>>> fixed and here this becomes more tricky afais. In the
>>> >>>> residential environment we can't expose a VLAN per
>>> >>>> application/service per
>>> chain
>>> >>>> since this would not be very effective. So I am wondering how we
>>> >>>> envision this to work?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> nsc mailing list
>>> >>>> nsc@ietf.org
>>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>>> >>> _______________________________________________
>>> >>> nsc mailing list
>>> >>> nsc@ietf.org
>>> >>>https://www.ietf.org/mailman/listinfo/nsc
>>> >> _______________________________________________
>>> >> nsc mailing list
>>> >> nsc@ietf.org
>>> >>https://www.ietf.org/mailman/listinfo/nsc
>>> >
>>
>>
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From david.i.allan@ericsson.com  Thu Jul 25 12:57:02 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D4C21F8B04 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 12:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UylehgxUOPVM for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 12:56:56 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 694EA21F8C9D for <nsc@ietf.org>; Thu, 25 Jul 2013 12:56:46 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-06-51f182fdbdf2
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9E.9D.13034.DF281F15; Thu, 25 Jul 2013 21:56:46 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 15:56:45 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>,  Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAASuGAgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAIAAEtIA///E+wAALVdugAAIKR+Q
Date: Thu, 25 Jul 2013 19:56:44 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se>
References: <E6C17D2345AC7A45B7D054D407AA205C115D697E@eusaamb105.ericsson.se> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF3964@xmb-aln-x09.cisco.com>
In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF3964@xmb-aln-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPn+6/po+BBv83Mlksnadu8fHUGyaL uy0TmSyO79vPZnHh6VRmi6ffj7M7sHm8uPKM2WPK742sHi1H3rJ6LFnyk8nj3JTvjAGsUVw2 Kak5mWWpRfp2CVwZn/uesRa8WMxYsfPMDaYGxputjF2MnBwSAiYSizqXsULYYhIX7q1n62Lk 4hASOMooMXXBGzaQhJDAckaJ81eKQGw2AQOJPf+/MIIUiQhsZZTY2DqTHSTBLBAs8Wr5Y7Cp wgKWEsebX4PFRQSsJM5u6oZqmMYocfjnMiaQBIuAqsSEzdvBingFfCUeL33LDrF6AqPE5yNP wYo4gRKNM5+DncEIdN/3U2uYILaJS9x6Mp8J4m4BiSV7zjND2KISLx//g/pHWWLJk/0sEPU6 Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLCJ ERhzxyTYdHcw7nlpeYhRmoNFSZx3ld6ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MIXFT k5a6RFqEvOR6+kelJ/TM6qyoa+7zPaYXctsd1ZczlMnvnuRx1ObsZCsfxpILiwN+vmFg1Wv1 XGR3LPzvu/uzWX/Mzu+2ap/Am/Qy1d+yZRZ75qwrNxTu/N0TvOj+N+s5k5UmPmjeMUPbYVuS qqFMrcCb/ddu9wjkTNef7Jz79OeMsrf9SizFGYmGWsxFxYkA5XgvI4cCAAA=
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 19:57:02 -0000

Hi Surendra:

Unless the intent is to embed RADIUS records or similar in the meta data, a=
ll that is going to be carried is a subscriber ID itself, which implies a p=
olicy lookup for each function that is subscriber stateful and needs subscr=
iber specific policies.

Ultimately the notion of subscriber will be uniquely inferable from informa=
tion embedded in the customer frame when it arrives at the ingress to a cha=
in, and that is without any protocol changes, else the network would alread=
y be broken!  So I'm not sure how that can be improved upon...translating w=
hat is in the frame to yet another identifier would not really have a lot o=
f utility and would add IMO gratuitous complexity

Dave

-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suren=
dra Kumar (smkumar)
Sent: Thursday, July 25, 2013 11:49 AM
To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Service chaining architecture question



On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:

>I would prefer to think what is on the wire facilitates the forwarding=20
>of frames, e.g. chain ID (analogous to VPN), perhaps an entropy=20
>shorthand to help both LB and  testabilty....and facilitates uniquely=20
>identifying the subscriber. (within the bounds of the art of the=20
>possible, see my last post on NAT). I cannot envision a need for more.=20
>And ideally I should be able to align such an approach with existing Cloud=
 technologies.
SK> For entropy you are better off choosing the right transport and
relying on that than the chain-id.
>
>The individual VF should be able to determine actual subscriber to a=20
>granularity suitable for it's purposes and obtain the necessary profile=20
>information via a northbound interface. If you then read between the=20
>lines,  I'm all for separation of concerns as much as possible ;-) and=20
>not creating dependencies across chain components beyond the networking=20
>level.
SK> Agree but I would add that subscriber identification may require
policy-plane interaction and if it is done once in the chain, the rest of t=
he chain can benefit from it.

Surendra.
>
>I also do not see a huge difference between a service chain, and any=20
>other flow of information across a string of processing elements. Just=20
>in one application, the packet is preserved with perhaps a bit of=20
>fondling, and in others the content may be completely deconstructed,=20
>and repackaged into a set of transactions....and what is on the wire=20
>between chain components does not remotely look like what went in the fron=
t end...
>
>Cheers
>Dave
>
>
>
>
>
>
>-----Original Message-----
>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20
>Ron Parker
>Sent: Wednesday, July 24, 2013 5:42 PM
>To: Joel M. Halpern; Linda Dunbar
>Cc: nsc@ietf.org; Jim Guichard (jguichar)
>Subject: Re: [nsc] Service chaining architecture question
>
>Thanks, all, for a lively discussion on this topic.
>
>One thing that flavors the discussion of network service chaining is the
>definition of "service".   It really means different things to different
>people.   We networking types tend to look at it as a software
>application or software system composed of multiple software applications
>(i.e., an HTTP content filter).   But when I interact with the business
>folks, especially on the operator side, I hear a different notion of=20
>"service" -- something subscribers pay for, government mandates, etc.
>This is why, IMO, it is defensible to say that the=20
>HTTP-content-filter-children is a distinct service from=20
>HTTP-content-filter-adult, even if both are realized on the same server=20
>by the same software application using the same global URL database.
>
>It does sound like at least some that have chimed in do feel that both=20
>the general service type (i.e., HTTP content filter) and the policy set
>need to be conveyed in some manner.    How to do this is a set of
>tradeoffs around control plane protocol and data plane encapsulation.
>Without any control plane, both types of information need to be on the
>wire in some form.   I will assume that the policy set identity is
>distinct at each service instance (i.e, policy set 2 at the HTTP=20
>content filter does not imply the same set of subscribers as policy set 2 =
at the
>firewall).   I will also assume that the meaning and interpretation of a
>policy set identity is specific to that type of service and probably to
>the vendor that supplied the service.   This is similar to when a PCRF
>names a PCC rulebase rather than supplying the full set of explicit PCC
>rules.    =20
>
>The advantage of a single chain ID that can be interpreted as a=20
>sequence of {service-type-instance, policy-set} is that it minimizes=20
>the per-packet encapsulation requirement (i.e., a single GRE key could
>suffice).   The disadvantage that has been pointed out is that global
>coordination of this identity is required and the number of=20
>combinations could become unwieldy.
>
>Another approach could be to have a new encapsulation that represents a=20
>stack of 2-tuples {service-ip-address, service-specific-policy-id}, or=20
>even 3-tuples {service-ip-address, service-type,=20
>service-specific-policy-id} where the 3-tuple brings the added=20
>advantage of allowing for multiple dissimilar services realized by the sam=
e server
>at the same server ip address.   The advantage of this approach is that
>it avoids the combinatorial explosion problem, but it requires a larger=20
>and variable length encapsulation.
>
>If the global chain id approach is used, a control plane protocol could=20
>be used to distribute the definitions of each chain (i.e, each chain is=20
>really a stack of 2-tuples or 3-tuples, per description above).
>
>Thanks.
>
>    Ron
>
>-----Original Message-----
>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>Sent: Wednesday, July 24, 2013 7:35 PM
>To: Linda Dunbar
>Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
>Subject: Re: [nsc] Service chaining architecture question
>
>I would not be surprised if we want all three of Service Chain, Service=20
>Policy, and Subscriber / user identity in the packet.
>If the Chain is in the VLAN / MPLS label, then we can discuss whether=20
>the other information goes in additional ids of the same type or in a=20
>carried header.  I can construct arguments for either approach.
>
>It may be easier to just carry the subscriber identity, and used the=20
>same management systems to assign policies to the devices that care.  I=20
>am concerned that it may not be practical to use a single policy=20
>identifier to specify which HTTP rule set to use, which Firewall rule=20
>set to use, and then which specific policy for other user selected=20
>policy applications.
>
>Yours,
>Joel
>
>On 7/24/13 7:30 PM, Linda Dunbar wrote:
>> Joel,
>>> -----Original Message-----
>>>
>>> Yes, having the chain ingress node mark the traffic makes good sense.
>>> Having it mark the subscriber identity and the chain to be traversed=20
>>> seems quite sensible.
>>>
>>> The difference I think I have with Ron is that he proposes to use=20
>>> one identifier for both entities.
>> [Linda] I hope you don't mean per subscriber identity, do you? With=20
>> today's PCRF, subscribers are categorized based on their subscription=20
>> types. Throughout the network, the "subscription types" dictate what=20
>> service modules their corresponding traffic need to traverse through.
>> Some service modules might need to examine packets deeper (i.e. look=20
>> into payload) for their intended functions. They may need to extract=20
>> the "HTTP header" or HTTP messages from one or multiple packets.
>> That causes, as Dave said, a
>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two=20
>>> MPLS labels.
>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>> The subscriber identity could be some bits in the payload.
>>>
>>> And if the existing boxes don't know how to handle that (as seems
>>> likely) then we need a proxy / support function to translate the=20
>>> common protocol into whatever they used before we got something=20
>>> generally usable out there.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>>> >
>>> > Agree with Ron that it is better to have fewer nodes in network to
>>> make subscriber-aware policy decisions.
>>> >
>>> > Besides, it is not uncommon for multiple subscribers to share same
>>> sequence of service modules. In this environment, if the network=20
>>> edge nodes, such as Broadband Network Gateway or Cell Site Gateway,=20
>>> can use Layer 2 or 3 labels to mark the traffic, the subsequent=20
>>> network nodes can steer traffic to the needed service modules=20
>>> without looking into "Mega data" or other higher layer fields in the da=
ta frames.
>>> >
>>> > This approach can make "service chain" work without making changes=20
>>> > to
>>> majority of existing deployed network elements.
>>> >
>>> > Linda
>>> >
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> Jim,
>>> >>
>>> >> Yes, that could work, too, conceptually.   But it does require that
>>> >> each coarsely-defined network service have access to a=20
>>> >> subscriber-
>>> aware
>>> >> policy resolution mechanism.   IMO, it is better to have fewer
>>> network
>>> >> elements making subscriber-aware policy decisions.
>>> >
>>> >
>>> >>
>>> >>     Ron
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>>> >> To: Ron Parker
>>> >> Cc: Joel M. Halpern; nsc@ietf.org
>>> >> Subject: Re: [nsc] Service chaining architecture question
>>> >>
>>> >> Ron,
>>> >> Or alternatively carry the subscriber awareness in metadata=20
>>> >> thereby utilizing a single chain.
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>>> >> <Ron_Parker@affirmednetworks.com> wrote:
>>> >>
>>> >>> Joel,
>>> >>>
>>> >>> IMO, the primary reason for understanding the subscriber=20
>>> >>> identity
>>> at
>>> >> a network service is to choose from a differentiated set of
>>>policies.
>>> >> I think there is utility and efficiency in driving that selection
>>> from
>>> >> one place -- the network services classifier.     Say there were 2
>>> >> groups of subscribers -- children and adults.   Let's now define 2
>>> >> chains, where the chains have a business-based meaning to the
>>> operator.
>>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>>> filter-
>>> >> adult + Firewall-adult.    The referenced network services are
>>> logical
>>> >> and it is possible, but not required, that multiple logical network
>>> >> services be located at the same IP address or FQDN.     Conveying
>>> the
>>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>>> ID, ...)
>>> >> allows the IP-addressable server that realizes these service(s)=20
>>> >> to
>>> know
>>> >> two things -- 1) which logical network function should be invoked
>>> and 2)
>>> >> which logical network function is next.
>>> >>>
>>> >>> Thanks.
>>> >>> Ron
>>> >>>
>>> >>> -----Original Message-----
>>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>>> >>> To: Ron Parker
>>> >>> Cc: nsc@ietf.org
>>> >>> Subject: Re: [nsc] Service chaining architecture question
>>> >>>
>>> >>> Ron,
>>> >>>      maybe I am missing something, but you seem to lay out very
>>> nicely
>>> >> the case for wanting both service chain identification and
>>> separately
>>> >> subscriber identification.  Then the HTTP filter can use the
>>> subscriber
>>> >> ID to decide which exact content filtering behavior it should apply.
>>> I
>>> >> would not want to fold that level of detail into the chain=20
>>> >> identification.
>>> >>>
>>> >>> Yours,
>>> >>> Joel
>>> >>>
>>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>> >>>> Dave,
>>> >>>>
>>> >>>> I agree that the number of chains is unlikely to scale to vast
>>> >> numbers
>>> >>>> (i.e., millions).     And I agree that it is bounded from a
>>> >> practical
>>> >>>> business perspective, as you point out.
>>> >>>>
>>> >>>> You may already be on this page, but I wanted to point out a=20
>>> >>>> distinction of coarse-grained definition of a service function vs.
>>> >> finer-grained
>>> >>>> definition of a service function.   Consider a service function to
>>> >> be
>>> >>>> logical in such a way that the identity of the logical function
>>> may
>>> >> also
>>> >>>> imply some differentiated behavior.   For example, a conceptual
>>> >> function
>>> >>>> is HTTP content filtering.    This conceptual function can then be
>>> >>>> further instantiated at the logical level based on=20
>>> >>>> differentiated policies such as content-filter-children,=20
>>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm=20
>>> >>>> taking
>>> no
>>> >> stand on opt-in vs. opt-out, Mr.
>>> >>>> Cameron).   It may be that the same network element (dedicated
>>> >> physical
>>> >>>> box or virtual network function) realizes all 3 of the example
>>> >>>> policies.   The HTTP content filtering network function is really
>>> 3
>>> >>>> logical network functions from the perspective of inclusion in=20
>>> >>>> a
>>> >> service
>>> >>>> chain.   Now extend this to multiple conceptual functions that
>>> >> utilize
>>> >>>> differentiated policies and the number of combinations will=20
>>> >>>> grow,
>>> at
>>> >>>> least modestly.
>>> >>>>
>>> >>>> Thanks,
>>> >>>>
>>> >>>> Ron
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>>> Behalf
>>> >>>> Of *David Allan I
>>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> Saying functions will have a problem with something that exists=20
>>> >>>> as
>>> a
>>> >>>> potential rationale for defining something new with exactly the
>>> same
>>> >>>> properties and problems does not quite work for me....
>>> >>>>
>>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>>> >> stack
>>> >>>> construction and this being combined with application
>>> "cooperation"
>>> >>>> to preserve pairwise mappings of either VID/NIC tuples or=20
>>> >>>> simply
>>> >>>> NICs) currently exist as potential vehicles for preserving=20
>>> >>>> chain context and avoiding per hop classification. Anything=20
>>> >>>> else will be implemented more or less the same way and have=20
>>> >>>> exactly the same
>>> set
>>> >>>> of scaling and application design issues...Some extra=20
>>> >>>> information available on a single interface, or achieved by=20
>>> >>>> mapping chain instances onto one of a plurality of interfaces....
>>> >>>>
>>> >>>> But to back up... I'm not a carrier employee but I cannot=20
>>> >>>> envision
>>> a
>>> >>>> carrier offering potentially 1000s of distinct service bundles
>>> >> ("pick
>>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>>> smaller
>>> >>>> number is realistic for  the number of chains a function=20
>>> >>>> instance
>>> is
>>> >>>> expected to participate in, even allowing for dynamic=20
>>> >>>> reclassification of flows at a chain ingress to "skip a few=20
>>> >>>> functions".... These are things that are fully operationalized=20
>>> >>>> in OSS, have policy associated with, have been industrialized=20
>>> >>>> and demonstrated to work prior to deployment. Going all=20
>>> >>>> combinatorial
>>> on
>>> >> this will break that big time....
>>> >>>>
>>> >>>> So are we really discussing a function participating in more=20
>>> >>>> than
>>> a
>>> >>>> handful of chain instances? And either a plurality of vNICs or
>>> VIDs
>>> >>>> being actually more than sufficient?
>>> >>>>
>>> >>>> Thanks
>>> >>>>
>>> >>>> Dave
>>> >>>>
>>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>>> >>>> (Wim)
>>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
>>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> indeed
>>> >>>>
>>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>> >>>> *Date: *Wednesday 24 July 2013 15:54
>>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>> >>>> *Subject: *AW: Service chaining architecture question
>>> >>>>
>>> >>>> Hi Wim,
>>> >>>>
>>> >>>> I think not only effectivness/scalability might be a problem=20
>>> >>>> but
>>> >> also
>>> >>>> the fact that not all applications (service bringing functions)
>>> are
>>> >>>> able to handle packets coming from/going to potentially=20
>>> >>>> thousands
>>> of
>>> >>>> different VLANs at the same time. VLANs will work in certain=20
>>> >>>> environments but not in all. I see the need for an information=20
>>> >>>> exchange between the application and a mediation layer as well.
>>> >>>> Ideally this should be as simple as possible without heavy=20
>>> >>>> impact
>>> on
>>> >>>> the application itself (might be difficult to achieve but from=20
>>> >>>> my experience it is not very likely, that there will be big=20
>>> >>>> rewrites
>>> of
>>> >>>> existing applications in order to support the chaining).
>>> >>>>
>>> >>>>    regards
>>> >>>>
>>> >>>>       Nic
>>> >>>>
>>> >>>> ---------------------------------------------------------------
>>> >>>> -
>>> >>>> --
>>> --
>>> >> -
>>> >>>> -
>>> >>>> --
>>> >>>>
>>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>>> (Wim)
>>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>> >>>> *Betreff:* [nsc] Service chaining architecture question
>>> >>>>
>>> >>>> I have a basic question with respect to the=20
>>> >>>> architecture/framework
>>> >> so
>>> >>>> far mentioned in the drafts in NSC. I understand the meta-data=20
>>> >>>> is
>>> a
>>> >>>> mechanism to avoid multiple re-classifications when the packet
>>> >> enters
>>> >>>> the NSC domain and identifies the chain of service functions.
>>> >>>> Now
>>> my
>>> >>>> understanding is that the services/applications are unaware of=20
>>> >>>> the meta-data and that a layer underneath should provide the=20
>>> >>>> mediation and that we use a well defined interface to the
>>> application/service
>>> >>>> to indicate the chain. In the context of Cloud/enterprise
>>> >> environment
>>> >>>> I can see this work given you can use a dedicate VLAN e.g.
>>> >>>> within
>>> >> the tenant.
>>> >>>> However we also try to address residential use cases for mobile
>>> and
>>> >>>> fixed and here this becomes more tricky afais. In the=20
>>> >>>> residential environment we can't expose a VLAN per=20
>>> >>>> application/service per
>>> chain
>>> >>>> since this would not be very effective. So I am wondering how=20
>>> >>>> we envision this to work?
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> nsc mailing list
>>> >>>> nsc@ietf.org
>>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>>> >>> _______________________________________________
>>> >>> nsc mailing list
>>> >>> nsc@ietf.org
>>> >>>https://www.ietf.org/mailman/listinfo/nsc
>>> >> _______________________________________________
>>> >> nsc mailing list
>>> >> nsc@ietf.org
>>> >>https://www.ietf.org/mailman/listinfo/nsc
>>> >
>>
>>
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc

_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

From wim.henderickx@alcatel-lucent.com  Thu Jul 25 13:28:13 2013
Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0F921F8C65 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 13:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.206
X-Spam-Level: 
X-Spam-Status: No, score=-10.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztKf+na29Bcq for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 13:28:05 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 66BA421F8517 for <nsc@ietf.org>; Thu, 25 Jul 2013 13:27:57 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6PKRrOR002039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Jul 2013 15:27:54 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6PKRpRA001692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 22:27:52 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 25 Jul 2013 22:27:51 +0200
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiKy1HR/eGZQXCkiUgUkwI6ipZZl12YCA
Date: Thu, 25 Jul 2013 20:27:50 +0000
Message-ID: <CE1752BF.6A962%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <68B171751455884590F8E38E96416F363F5C4483@xmb-rcd-x01.cisco.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_CE1752BF6A962wimhenderickxalcatellucentcom_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 20:28:13 -0000

--_000_CE1752BF6A962wimhenderickxalcatellucentcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sorry for the late reply but I am traveling quiet a bit with little email a=
ccess.

From: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.c=
om>>
Date: Wednesday 24 July 2013 22:30
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx=
@alcatel-lucent.com>>, "N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>" =
<N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>>, "nsc@ietf.org<mailto:n=
sc@ietf.org>" <nsc@ietf.org<mailto:nsc@ietf.org>>
Subject: Re: [nsc] Service chaining architecture question

Hi Wim,

A few comments/questions inline ..

________________________________
Von: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces@=
ietf.org] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org<mailto:nsc@ietf.org>
Betreff: [nsc] Service chaining architecture question

I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data

Jim> this is true in the proxy-mode case but it is also possible that the s=
ervice functions themselves understand the NSH metadata. Both modes of oper=
ation are valid imho.

WH> My question is more in the context that the service function does not u=
nderstand the NSH metadata, but I do understand going forward that certain =
services could understand the NSH metadata.

and that a layer underneath should provide the mediation and that we use a =
well defined interface to the application/service to indicate the chain. In=
 the context of Cloud/enterprise environment I can see this work given you =
can use a dedicate VLAN e.g. within the tenant.

Jim> note that the dedicated VLAN you describe is local between the proxy a=
nd the service e.g. We are not talking about domain-wide VLANs in this cont=
ext. So this interface between the proxy and the service is in fact a "loca=
l identifier" where that might be a VLAN but could also be something else s=
uch as the IP address of the residential consumer. Further, the number of l=
ocal identifier's you will need will be dependent on the differentiation yo=
u require; for example, is differentiation needed by user, or "class" of us=
er (i.e. Gold, silver, bronze analogy), or something else.  So this boils d=
own to what the local identifier is used for and whether it has policy asso=
ciated with it e.g. vlan-1 -> do firewall rule "x", vlan-2 -> do firewall r=
ule "y", and so on.

WH> I do understand this and I agree the ID is local and managed by the pol=
icy system. The scenario I have in mind is this and a lot of people deploy =
the following scenario afais.
An ADC is configured with the chain function based on Policy interaction fo=
r subscriber profiles and the service/application have a single interface t=
o the ADC. Given the ADC is involved in the flows all the time the service/=
application has a single interface/vlan/vnic/etc irrespective of the differ=
ent chains that are setup. So unless the service/application understands th=
e metadata you need to deploy a different interface/VLAN per network chain =
and this can be cumbersome depending on the environment. E.g. A FW in a res=
idential environment is deployed with a single interface today irrespective=
 of the amount of chains. If we believe that forwarding the meta-data to th=
e application/service is the answer we need to ensure this is easily suppor=
ted by the interface stack such that people can adopt it easily.

However we also try to address residential use cases for mobile and fixed a=
nd here this becomes more tricky afais. In the residential environment we c=
an't expose a VLAN per application/service per chain since this would not b=
e very effective. So I am wondering how we envision this to work?

Jim> I'm assuming when you say residential, you mean serving residential cu=
stomers with services in the POP or head-end, NOT services in the home righ=
t?

WH> correct

--_000_CE1752BF6A962wimhenderickxalcatellucentcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <089356F6F048714E995D8E332F792D74@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>Sorry for the late reply but I am traveling quiet a bit with little em=
ail access.</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&quot;Jim Guichard (jguichar)=
&quot; &lt;<a href=3D"mailto:jguichar@cisco.com">jguichar@cisco.com</a>&gt;=
<br>
<span style=3D"font-weight:bold">Date: </span>Wednesday 24 July 2013 22:30<=
br>
<span style=3D"font-weight:bold">To: </span>Wim Henderickx &lt;<a href=3D"m=
ailto:wim.henderickx@alcatel-lucent.com">wim.henderickx@alcatel-lucent.com<=
/a>&gt;, &quot;<a href=3D"mailto:N.Leymann@telekom.de">N.Leymann@telekom.de=
</a>&quot; &lt;<a href=3D"mailto:N.Leymann@telekom.de">N.Leymann@telekom.de=
</a>&gt;,
 &quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt;<a href=
=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [nsc] Service chaining=
 architecture question<br>
</div>
<div><br>
</div>
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; font-size: 14px; font-family: Calibri, sans-seri=
f; ">
<div style=3D"color: rgb(0, 0, 0); ">Hi Wim,</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">A few comments/questions inline ..&nbs=
p;</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil=
y: Calibri, sans-serif; ">
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLO=
R: rgb(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space">
<div dir=3D"ltr" align=3D"left"><span class=3D"912565709-24072013"><font si=
ze=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left">
<hr tabindex=3D"-1">
</div>
<div dir=3D"ltr" align=3D"left"><font size=3D"2" face=3D"Tahoma"><b>Von:</b=
> <a href=3D"mailto:nsc-bounces@ietf.org">
nsc-bounces@ietf.org</a> [<a href=3D"mailto:nsc-bounces@ietf.org">mailto:ns=
c-bounces@ietf.org</a>]
<b>Im Auftrag von </b>Henderickx, Wim (Wim)<br>
<b>Gesendet:</b> Mittwoch, 24. Juli 2013 11:52<br>
<b>An:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Betreff:</b> [nsc] Service chaining architecture question<br>
</font><br>
</div>
<div></div>
<div>I have a basic question with respect to the architecture/framework so =
far mentioned in the drafts in NSC. I understand the meta-data is a mechani=
sm to avoid multiple re-classifications when the packet enters the NSC doma=
in and identifies the chain of service
 functions. Now my understanding is that the services/applications are unaw=
are of the meta-data</div>
</div>
</div>
</span></div>
</div>
</span>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><font class=3D"Apple-style-span" color=3D"#ff0000">Jim&gt; this is tru=
e in the proxy-mode case but it is also possible that the service functions=
 themselves understand the NSH metadata. Both modes of operation are valid =
imho.&nbsp;</font></div>
</div>
</div>
</span>
<div><br>
</div>
<div>WH&gt; My question is more in the context that the service function do=
es not understand the NSH metadata, but I do understand going forward that =
certain services could understand the NSH metadata.&nbsp;</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; font-size: 14px; font-family: Calibri, sans-seri=
f; ">
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil=
y: Calibri, sans-serif; ">
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLO=
R: rgb(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space">
<div>and that a layer underneath should provide the mediation and that we u=
se a well defined interface to the application/service to indicate the chai=
n. In the context of Cloud/enterprise environment I can see this work given=
 you can use a dedicate VLAN e.g.
 within the tenant.</div>
</div>
</div>
</span></div>
</div>
</span>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><font class=3D"Apple-style-span" color=3D"#ff0000">Jim&gt; note that t=
he dedicated VLAN you describe is local between the proxy and the service e=
.g. We are not talking about domain-wide VLANs in this context. So this int=
erface between the proxy and the service
 is in fact a &quot;local identifier&quot; where that might be a VLAN but c=
ould also be something else such as the IP address of the residential consu=
mer. Further, the number of local identifier's you will need will be depend=
ent on the differentiation you require; for
 example, is differentiation needed by user, or &quot;class&quot; of user (=
i.e. Gold, silver, bronze analogy), or something else. &nbsp;</font><span c=
lass=3D"Apple-style-span" style=3D"color: rgb(255, 0, 0); ">So this boils d=
own to what the local identifier is used for and whether
 it has policy associated with it e.g. vlan-1 -&gt; do firewall rule &quot;=
x&quot;, vlan-2 -&gt; do firewall rule &quot;y&quot;, and so on.&nbsp;</spa=
n></div>
</div>
</div>
</span>
<div><br>
</div>
<div>WH&gt; I do understand this and I agree the ID is local and managed by=
 the policy system. The scenario I have in mind is this and a lot of people=
 deploy the following scenario afais.</div>
<div>An ADC is configured with the chain function based on Policy interacti=
on for subscriber profiles and the service/application have a single interf=
ace to the ADC. Given the ADC is involved in the flows all the time the ser=
vice/application has a single interface/vlan/vnic/etc
 irrespective of the different chains that are setup. So unless the service=
/application understands the metadata you need to deploy a different interf=
ace/VLAN per network chain and this can be cumbersome depending on the envi=
ronment. E.g. A FW in a residential
 environment is deployed with a single interface today irrespective of the =
amount of chains. If we believe that forwarding the meta-data to the applic=
ation/service is the answer we need to ensure this is easily supported by t=
he interface stack such that people
 can adopt it easily.</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; font-size: 14px; font-family: Calibri, sans-seri=
f; ">
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); ">
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil=
y: Calibri, sans-serif; ">
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"FONT-FAMILY: Calibri, sans-serif; WORD-WRAP: break-word; COLO=
R: rgb(0,0,0); FONT-SIZE: 14px; -webkit-nbsp-mode: space; -webkit-line-brea=
k: after-white-space">
<div>However we also try to address residential use cases for mobile and fi=
xed and here this becomes more tricky afais.&nbsp;In the residential enviro=
nment we can't expose a VLAN per application/service per chain since this w=
ould not be very effective. So I am wondering
 how we envision this to work?</div>
</div>
</div>
</span></div>
</div>
</span>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><font class=3D"Apple-style-span" color=3D"#ff0000">Jim&gt; <span class=
=3D"Apple-style-span" style=3D"font-family: Calibri; font-size: medium; ">
I'm assuming when you say residential, you mean serving residential custome=
rs with services in the POP or head-end, NOT services in the home right?&nb=
sp;</span></font></div>
</div>
</div>
</span>
<div><br>
</div>
<div>WH&gt; correct</div>
</body>
</html>

--_000_CE1752BF6A962wimhenderickxalcatellucentcom_--

From wim.henderickx@alcatel-lucent.com  Thu Jul 25 13:34:16 2013
Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F036321F8618 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 13:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.304
X-Spam-Level: 
X-Spam-Status: No, score=-10.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACtEfO3Ok96n for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 13:34:10 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1B98C21F9302 for <nsc@ietf.org>; Thu, 25 Jul 2013 13:34:06 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6PKY37m006334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Jul 2013 15:34:04 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6PKY1GF003565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 22:34:03 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 25 Jul 2013 22:34:01 +0200
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "Pham, Chuong D" <Chuong.D.Pham@team.telstra.com>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5l0WWyAgAGCfYA=
Date: Thu, 25 Jul 2013 20:34:01 +0000
Message-ID: <CE175743.6A9E5%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C23E10899B8@WSMSG3154V.srv.dir.telstra.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_CE1757436A9E5wimhenderickxalcatellucentcom_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 20:34:17 -0000

--_000_CE1757436A9E5wimhenderickxalcatellucentcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I am not talking about the individual subscriber info in the Metadata, but =
how a service is involved in the chain information with respect to forwardi=
ng.
Assume I have an application/service which has an interface to the NSC netw=
ork domain and you have traffic arriving with different chain Metadata, how=
 is the traffic coming out of the application/service going to be mapped to=
 the proper Metadata header w/o doing reclassification.

From: <Pham>, Chuong D <Chuong.D.Pham@team.telstra.com<mailto:Chuong.D.Pham=
@team.telstra.com>>
Date: Thursday 25 July 2013 01:30
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx=
@alcatel-lucent.com>>, "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<ma=
ilto:nsc@ietf.org>>
Subject: RE: [nsc] Service chaining architecture question

Wim,
We are also investigating service chaining in a Mobile/Fixed Broadband serv=
ice provider environment.
I understand that your question is about what information element can be us=
ed to identify an individual user i.e. a Mobile subscriber in the meta-data=
 set. If this is correct then we have the same concern.
The way I envision it works is for the per-subscriber meta-data to be obtai=
ned/created in the =93control plane=94. One example is using Mobile/Fixed u=
ser identification such as MSISDN and MAC-address to identify the users in =
the meta-data. The =93control plane=94 entity would receive identification =
information via control plane messages from entities such as PCRF and AAA s=
erver. Such messages also have the user=92s dynamically allocated IP addres=
ses.  The control plane entity will push identity <User identity>-<IP addre=
ss> value pairs to the edge node. The edge node now can use these value pai=
rs to match with per-user policies and include the information in the meta-=
data.


From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Wednesday, 24 July 2013 7:52 PM
To: nsc@ietf.org<mailto:nsc@ietf.org>
Subject: [nsc] Service chaining architecture question

I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_CE1757436A9E5wimhenderickxalcatellucentcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <5D8EDC4076DB924F9BB516732CCB41E0@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>I am not talking about the individual subscriber info in the Metadata,=
 but how a service is involved in the chain information with respect to for=
warding.</div>
<div>Assume I have an application/service which has an interface to the NSC=
 network domain and you have traffic arriving with different chain Metadata=
, how is the traffic coming out of the application/service going to be mapp=
ed to the proper Metadata header
 w/o doing reclassification.</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b=
lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:=
 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;=
 BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style=3D"font-weight:bold">From: </span>&lt;Pham&gt;, Chuong D &lt;<a=
 href=3D"mailto:Chuong.D.Pham@team.telstra.com">Chuong.D.Pham@team.telstra.=
com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Thursday 25 July 2013 01:30<b=
r>
<span style=3D"font-weight:bold">To: </span>Wim Henderickx &lt;<a href=3D"m=
ailto:wim.henderickx@alcatel-lucent.com">wim.henderickx@alcatel-lucent.com<=
/a>&gt;, &quot;<a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&quot; &lt;<=
a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>RE: [nsc] Service chaining=
 architecture question<br>
</div>
<div><br>
</div>
<div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x=
mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/=
/www.w3.org/TR/REC-html40">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<div lang=3D"EN-AU" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Wim,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">We are also investigating service =
chaining in a Mobile/Fixed Broadband service provider environment.<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">I understand that your question is=
 about what information element can be used to identify an individual user =
i.e. a Mobile subscriber in the meta-data
 set. If this is correct then we have the same concern.<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">The way I envision it works is for=
 the per-subscriber meta-data to be obtained/created in the =93control plan=
e=94. One example is using Mobile/Fixed
 user identification such as MSISDN and MAC-address to identify the users i=
n the meta-data. The =93control plane=94 entity would receive identificatio=
n information via control plane messages from entities such as PCRF and AAA=
 server. Such messages also have the
 user=92s dynamically allocated IP addresses. &nbsp;The control plane entit=
y will push identity &lt;User identity&gt;-&lt;IP address&gt; value pairs t=
o the edge node. The edge node now can use these value pairs to match with =
per-user policies and include the information in the
 meta-data.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size: 10pt; fo=
nt-family: Tahoma, sans-serif; ">From:</span></b><span lang=3D"EN-US" style=
=3D"font-size: 10pt; font-family: Tahoma, sans-serif; "> Henderickx, Wim (W=
im) [<a href=3D"mailto:wim.henderickx@alcatel-lucent.com">mailto:wim.hender=
ickx@alcatel-lucent.com</a>]
<br>
<b>Sent:</b> Wednesday, 24 July 2013 7:52 PM<br>
<b>To:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Subject:</b> [nsc] Service chaining architecture question<o:p></o:p></sp=
an></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size: 10.5pt; font-family: Calib=
ri, sans-serif; color: black; ">I have a basic question with respect to the=
 architecture/framework so far mentioned in the drafts in NSC. I understand=
 the meta-data is a mechanism to avoid
 multiple re-classifications when the packet enters the NSC domain and iden=
tifies the chain of service functions. Now my understanding is that the ser=
vices/applications are unaware of the meta-data and that a layer underneath=
 should provide the mediation and
 that we use a well defined interface to the application/service to indicat=
e the chain. In the context of Cloud/enterprise environment I can see this =
work given you can use a dedicate VLAN e.g. within the tenant. However we a=
lso try to address residential use
 cases for mobile and fixed and here this becomes more tricky afais.&nbsp;I=
n the residential environment we can't expose a VLAN per application/servic=
e per chain since this would not be very effective. So I am wondering how w=
e envision this to work?<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_CE1757436A9E5wimhenderickxalcatellucentcom_--

From mn1921@att.com  Thu Jul 25 14:17:44 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D9721F84EF for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 14:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZfMSmivnzib for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 14:17:38 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1534121F84D9 for <nsc@ietf.org>; Thu, 25 Jul 2013 14:17:37 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 2f591f15.66a29940.3228656.00-517.8892166.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>);  Thu, 25 Jul 2013 21:17:38 +0000 (UTC)
X-MXL-Hash: 51f195f2779af737-fc2309ae55d2e70f8116470d312594edf1fd00ad
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 0f591f15.0.3228645.00-236.8892127.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>);  Thu, 25 Jul 2013 21:17:37 +0000 (UTC)
X-MXL-Hash: 51f195f1593961af-371b4d5709f43dbf33650bebb9683ba035c428e8
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6PLHakq016498; Thu, 25 Jul 2013 17:17:36 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6PLHOZH016358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jul 2013 17:17:26 -0400
Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 25 Jul 2013 21:17:14 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 17:17:14 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: David Allan I <david.i.allan@ericsson.com>, "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeAgAALhACAABT2gIAABD2AgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAIAAEtIAgAAMH4CAASOXgIAAEtQA///R/PA=
Date: Thu, 25 Jul 2013 21:17:14 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01208861@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <E6C17D2345AC7A45B7D054D407AA205C115D697E@eusaamb105.ericsson.se> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF3964@xmb-aln-x09.cisco.com> <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se>
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.38.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=0o18Hi0vUFMA:10 a=2DTnKp0c6ewA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=QNNNeoGkA4wA:10 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8]
X-AnalysisOut: [ a=ABeY7kuGAAAA:8 a=AUd_NHdVAAAA:8 a=qN95wPeSAAAA:8 a=gxZv]
X-AnalysisOut: [rgisAAAA:8 a=mi8dFdkKWeIuRh81a2UA:9 a=CjuIK1q_8ugA:10 a=lZ]
X-AnalysisOut: [B815dzVvQA:10 a=f7GxY0FH8QIA:10 a=chC_agHSu74A:10 a=JfD0Fc]
X-AnalysisOut: [h1gWkA:10 a=paC5pjApGzsA:10 a=p3EP0m9KMXkA:10 a=3FZX-ydVlc]
X-AnalysisOut: [EA:10 a=iWnEzcBRKJ8GY-QM:21 a=GSALG-j_HUDNoNBS:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 21:17:44 -0000

>=20
> Ultimately the notion of subscriber will be uniquely inferable from
> information embedded in the customer frame when it arrives at the
> ingress to a chain, and that is without any protocol changes, else the
> network would already be broken!  So I'm not sure how that can be
> improved upon...translating what is in the frame to yet another
> identifier would not really have a lot of utility and would add IMO
> gratuitous complexity

Right!  Now, the services may want to know what is the subscriber id or app=
lication id. This is where the metadata comes in.
We should handle metadata in such a way that it does not require the entire=
 IP stack on the appliance to be modified to pass this extra data.

Maria
> -----Original Message-----
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of
> Surendra Kumar (smkumar)
> Sent: Thursday, July 25, 2013 11:49 AM
> To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
> Cc: nsc@ietf.org; Jim Guichard (jguichar)
> Subject: Re: [nsc] Service chaining architecture question
>=20
>=20
>=20
> On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:
>=20
> >I would prefer to think what is on the wire facilitates the forwarding
> >of frames, e.g. chain ID (analogous to VPN), perhaps an entropy
> >shorthand to help both LB and  testabilty....and facilitates uniquely
> >identifying the subscriber. (within the bounds of the art of the
> >possible, see my last post on NAT). I cannot envision a need for more.
> >And ideally I should be able to align such an approach with existing
> Cloud technologies.
> SK> For entropy you are better off choosing the right transport and
> relying on that than the chain-id.
> >
> >The individual VF should be able to determine actual subscriber to a
> >granularity suitable for it's purposes and obtain the necessary
> profile
> >information via a northbound interface. If you then read between the
> >lines,  I'm all for separation of concerns as much as possible ;-) and
> >not creating dependencies across chain components beyond the
> networking
> >level.
> SK> Agree but I would add that subscriber identification may require
> policy-plane interaction and if it is done once in the chain, the rest
> of the chain can benefit from it.
>=20
> Surendra.
> >
> >I also do not see a huge difference between a service chain, and any
> >other flow of information across a string of processing elements. Just
> >in one application, the packet is preserved with perhaps a bit of
> >fondling, and in others the content may be completely deconstructed,
> >and repackaged into a set of transactions....and what is on the wire
> >between chain components does not remotely look like what went in the
> front end...
> >
> >Cheers
> >Dave
> >
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of
> >Ron Parker
> >Sent: Wednesday, July 24, 2013 5:42 PM
> >To: Joel M. Halpern; Linda Dunbar
> >Cc: nsc@ietf.org; Jim Guichard (jguichar)
> >Subject: Re: [nsc] Service chaining architecture question
> >
> >Thanks, all, for a lively discussion on this topic.
> >
> >One thing that flavors the discussion of network service chaining is
> the
> >definition of "service".   It really means different things to
> different
> >people.   We networking types tend to look at it as a software
> >application or software system composed of multiple software
> applications
> >(i.e., an HTTP content filter).   But when I interact with the
> business
> >folks, especially on the operator side, I hear a different notion of
> >"service" -- something subscribers pay for, government mandates, etc.
> >This is why, IMO, it is defensible to say that the
> >HTTP-content-filter-children is a distinct service from
> >HTTP-content-filter-adult, even if both are realized on the same
> server
> >by the same software application using the same global URL database.
> >
> >It does sound like at least some that have chimed in do feel that both
> >the general service type (i.e., HTTP content filter) and the policy
> set
> >need to be conveyed in some manner.    How to do this is a set of
> >tradeoffs around control plane protocol and data plane encapsulation.
> >Without any control plane, both types of information need to be on the
> >wire in some form.   I will assume that the policy set identity is
> >distinct at each service instance (i.e, policy set 2 at the HTTP
> >content filter does not imply the same set of subscribers as policy
> set 2 at the
> >firewall).   I will also assume that the meaning and interpretation of
> a
> >policy set identity is specific to that type of service and probably
> to
> >the vendor that supplied the service.   This is similar to when a PCRF
> >names a PCC rulebase rather than supplying the full set of explicit
> PCC
> >rules.
> >
> >The advantage of a single chain ID that can be interpreted as a
> >sequence of {service-type-instance, policy-set} is that it minimizes
> >the per-packet encapsulation requirement (i.e., a single GRE key could
> >suffice).   The disadvantage that has been pointed out is that global
> >coordination of this identity is required and the number of
> >combinations could become unwieldy.
> >
> >Another approach could be to have a new encapsulation that represents
> a
> >stack of 2-tuples {service-ip-address, service-specific-policy-id}, or
> >even 3-tuples {service-ip-address, service-type,
> >service-specific-policy-id} where the 3-tuple brings the added
> >advantage of allowing for multiple dissimilar services realized by the
> same server
> >at the same server ip address.   The advantage of this approach is
> that
> >it avoids the combinatorial explosion problem, but it requires a
> larger
> >and variable length encapsulation.
> >
> >If the global chain id approach is used, a control plane protocol
> could
> >be used to distribute the definitions of each chain (i.e, each chain
> is
> >really a stack of 2-tuples or 3-tuples, per description above).
> >
> >Thanks.
> >
> >    Ron
> >
> >-----Original Message-----
> >From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >Sent: Wednesday, July 24, 2013 7:35 PM
> >To: Linda Dunbar
> >Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
> >Subject: Re: [nsc] Service chaining architecture question
> >
> >I would not be surprised if we want all three of Service Chain,
> Service
> >Policy, and Subscriber / user identity in the packet.
> >If the Chain is in the VLAN / MPLS label, then we can discuss whether
> >the other information goes in additional ids of the same type or in a
> >carried header.  I can construct arguments for either approach.
> >
> >It may be easier to just carry the subscriber identity, and used the
> >same management systems to assign policies to the devices that care.
> I
> >am concerned that it may not be practical to use a single policy
> >identifier to specify which HTTP rule set to use, which Firewall rule
> >set to use, and then which specific policy for other user selected
> >policy applications.
> >
> >Yours,
> >Joel
> >
> >On 7/24/13 7:30 PM, Linda Dunbar wrote:
> >> Joel,
> >>> -----Original Message-----
> >>>
> >>> Yes, having the chain ingress node mark the traffic makes good
> sense.
> >>> Having it mark the subscriber identity and the chain to be
> traversed
> >>> seems quite sensible.
> >>>
> >>> The difference I think I have with Ron is that he proposes to use
> >>> one identifier for both entities.
> >> [Linda] I hope you don't mean per subscriber identity, do you? With
> >> today's PCRF, subscribers are categorized based on their
> subscription
> >> types. Throughout the network, the "subscription types" dictate what
> >> service modules their corresponding traffic need to traverse
> through.
> >> Some service modules might need to examine packets deeper (i.e. look
> >> into payload) for their intended functions. They may need to extract
> >> the "HTTP header" or HTTP messages from one or multiple packets.
> >> That causes, as Dave said, a
> >>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
> >>> MPLS labels.
> >> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> >> The subscriber identity could be some bits in the payload.
> >>>
> >>> And if the existing boxes don't know how to handle that (as seems
> >>> likely) then we need a proxy / support function to translate the
> >>> common protocol into whatever they used before we got something
> >>> generally usable out there.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >>> >
> >>> > Agree with Ron that it is better to have fewer nodes in network
> to
> >>> make subscriber-aware policy decisions.
> >>> >
> >>> > Besides, it is not uncommon for multiple subscribers to share
> same
> >>> sequence of service modules. In this environment, if the network
> >>> edge nodes, such as Broadband Network Gateway or Cell Site Gateway,
> >>> can use Layer 2 or 3 labels to mark the traffic, the subsequent
> >>> network nodes can steer traffic to the needed service modules
> >>> without looking into "Mega data" or other higher layer fields in
> the data frames.
> >>> >
> >>> > This approach can make "service chain" work without making
> changes
> >>> > to
> >>> majority of existing deployed network elements.
> >>> >
> >>> > Linda
> >>> >
> >>> >
> >>> >
> >>> >> -----Original Message-----
> >>> >> Jim,
> >>> >>
> >>> >> Yes, that could work, too, conceptually.   But it does require
> that
> >>> >> each coarsely-defined network service have access to a
> >>> >> subscriber-
> >>> aware
> >>> >> policy resolution mechanism.   IMO, it is better to have fewer
> >>> network
> >>> >> elements making subscriber-aware policy decisions.
> >>> >
> >>> >
> >>> >>
> >>> >>     Ron
> >>> >>
> >>> >>
> >>> >> -----Original Message-----
> >>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >>> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >>> >> To: Ron Parker
> >>> >> Cc: Joel M. Halpern; nsc@ietf.org
> >>> >> Subject: Re: [nsc] Service chaining architecture question
> >>> >>
> >>> >> Ron,
> >>> >> Or alternatively carry the subscriber awareness in metadata
> >>> >> thereby utilizing a single chain.
> >>> >>
> >>> >> Sent from my iPhone
> >>> >>
> >>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >>> >> <Ron_Parker@affirmednetworks.com> wrote:
> >>> >>
> >>> >>> Joel,
> >>> >>>
> >>> >>> IMO, the primary reason for understanding the subscriber
> >>> >>> identity
> >>> at
> >>> >> a network service is to choose from a differentiated set of
> >>>policies.
> >>> >> I think there is utility and efficiency in driving that
> selection
> >>> from
> >>> >> one place -- the network services classifier.     Say there were
> 2
> >>> >> groups of subscribers -- children and adults.   Let's now define
> 2
> >>> >> chains, where the chains have a business-based meaning to the
> >>> operator.
> >>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP=
-
> >>> filter-
> >>> >> adult + Firewall-adult.    The referenced network services are
> >>> logical
> >>> >> and it is possible, but not required, that multiple logical
> network
> >>> >> services be located at the same IP address or FQDN.
> Conveying
> >>> the
> >>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> >>> ID, ...)
> >>> >> allows the IP-addressable server that realizes these service(s)
> >>> >> to
> >>> know
> >>> >> two things -- 1) which logical network function should be
> invoked
> >>> and 2)
> >>> >> which logical network function is next.
> >>> >>>
> >>> >>> Thanks.
> >>> >>> Ron
> >>> >>>
> >>> >>> -----Original Message-----
> >>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> >>> >>> To: Ron Parker
> >>> >>> Cc: nsc@ietf.org
> >>> >>> Subject: Re: [nsc] Service chaining architecture question
> >>> >>>
> >>> >>> Ron,
> >>> >>>      maybe I am missing something, but you seem to lay out very
> >>> nicely
> >>> >> the case for wanting both service chain identification and
> >>> separately
> >>> >> subscriber identification.  Then the HTTP filter can use the
> >>> subscriber
> >>> >> ID to decide which exact content filtering behavior it should
> apply.
> >>> I
> >>> >> would not want to fold that level of detail into the chain
> >>> >> identification.
> >>> >>>
> >>> >>> Yours,
> >>> >>> Joel
> >>> >>>
> >>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >>> >>>> Dave,
> >>> >>>>
> >>> >>>> I agree that the number of chains is unlikely to scale to vast
> >>> >> numbers
> >>> >>>> (i.e., millions).     And I agree that it is bounded from a
> >>> >> practical
> >>> >>>> business perspective, as you point out.
> >>> >>>>
> >>> >>>> You may already be on this page, but I wanted to point out a
> >>> >>>> distinction of coarse-grained definition of a service function
> vs.
> >>> >> finer-grained
> >>> >>>> definition of a service function.   Consider a service
> function to
> >>> >> be
> >>> >>>> logical in such a way that the identity of the logical
> function
> >>> may
> >>> >> also
> >>> >>>> imply some differentiated behavior.   For example, a
> conceptual
> >>> >> function
> >>> >>>> is HTTP content filtering.    This conceptual function can
> then be
> >>> >>>> further instantiated at the logical level based on
> >>> >>>> differentiated policies such as content-filter-children,
> >>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
> >>> >>>> taking
> >>> no
> >>> >> stand on opt-in vs. opt-out, Mr.
> >>> >>>> Cameron).   It may be that the same network element (dedicated
> >>> >> physical
> >>> >>>> box or virtual network function) realizes all 3 of the example
> >>> >>>> policies.   The HTTP content filtering network function is
> really
> >>> 3
> >>> >>>> logical network functions from the perspective of inclusion in
> >>> >>>> a
> >>> >> service
> >>> >>>> chain.   Now extend this to multiple conceptual functions that
> >>> >> utilize
> >>> >>>> differentiated policies and the number of combinations will
> >>> >>>> grow,
> >>> at
> >>> >>>> least modestly.
> >>> >>>>
> >>> >>>> Thanks,
> >>> >>>>
> >>> >>>> Ron
> >>> >>>>
> >>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
> >>> Behalf
> >>> >>>> Of *David Allan I
> >>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
> nsc@ietf.org
> >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>> >>>>
> >>> >>>> Saying functions will have a problem with something that
> exists
> >>> >>>> as
> >>> a
> >>> >>>> potential rationale for defining something new with exactly
> the
> >>> same
> >>> >>>> properties and problems does not quite work for me....
> >>> >>>>
> >>> >>>> VLANs on a vNIC or multiple vNICs (depending on the
> application
> >>> >> stack
> >>> >>>> construction and this being combined with application
> >>> "cooperation"
> >>> >>>> to preserve pairwise mappings of either VID/NIC tuples or
> >>> >>>> simply
> >>> >>>> NICs) currently exist as potential vehicles for preserving
> >>> >>>> chain context and avoiding per hop classification. Anything
> >>> >>>> else will be implemented more or less the same way and have
> >>> >>>> exactly the same
> >>> set
> >>> >>>> of scaling and application design issues...Some extra
> >>> >>>> information available on a single interface, or achieved by
> >>> >>>> mapping chain instances onto one of a plurality of
> interfaces....
> >>> >>>>
> >>> >>>> But to back up... I'm not a carrier employee but I cannot
> >>> >>>> envision
> >>> a
> >>> >>>> carrier offering potentially 1000s of distinct service bundles
> >>> >> ("pick
> >>> >>>> 53 from column A and 49 from column B"). So I suspect a much
> >>> smaller
> >>> >>>> number is realistic for  the number of chains a function
> >>> >>>> instance
> >>> is
> >>> >>>> expected to participate in, even allowing for dynamic
> >>> >>>> reclassification of flows at a chain ingress to "skip a few
> >>> >>>> functions".... These are things that are fully operationalized
> >>> >>>> in OSS, have policy associated with, have been industrialized
> >>> >>>> and demonstrated to work prior to deployment. Going all
> >>> >>>> combinatorial
> >>> on
> >>> >> this will break that big time....
> >>> >>>>
> >>> >>>> So are we really discussing a function participating in more
> >>> >>>> than
> >>> a
> >>> >>>> handful of chain instances? And either a plurality of vNICs or
> >>> VIDs
> >>> >>>> being actually more than sufficient?
> >>> >>>>
> >>> >>>> Thanks
> >>> >>>>
> >>> >>>> Dave
> >>> >>>>
> >>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
> >>> >>>> (Wim)
> >>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> >>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>> >>>>
> >>> >>>> indeed
> >>> >>>>
> >>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >>> >>>> *Date: *Wednesday 24 July 2013 15:54
> >>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> >>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >>> >>>> *Subject: *AW: Service chaining architecture question
> >>> >>>>
> >>> >>>> Hi Wim,
> >>> >>>>
> >>> >>>> I think not only effectivness/scalability might be a problem
> >>> >>>> but
> >>> >> also
> >>> >>>> the fact that not all applications (service bringing
> functions)
> >>> are
> >>> >>>> able to handle packets coming from/going to potentially
> >>> >>>> thousands
> >>> of
> >>> >>>> different VLANs at the same time. VLANs will work in certain
> >>> >>>> environments but not in all. I see the need for an information
> >>> >>>> exchange between the application and a mediation layer as
> well.
> >>> >>>> Ideally this should be as simple as possible without heavy
> >>> >>>> impact
> >>> on
> >>> >>>> the application itself (might be difficult to achieve but from
> >>> >>>> my experience it is not very likely, that there will be big
> >>> >>>> rewrites
> >>> of
> >>> >>>> existing applications in order to support the chaining).
> >>> >>>>
> >>> >>>>    regards
> >>> >>>>
> >>> >>>>       Nic
> >>> >>>>
> >>> >>>> --------------------------------------------------------------
> -
> >>> >>>> -
> >>> >>>> --
> >>> --
> >>> >> -
> >>> >>>> -
> >>> >>>> --
> >>> >>>>
> >>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> >>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
> >>> (Wim)
> >>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >>> >>>> *Betreff:* [nsc] Service chaining architecture question
> >>> >>>>
> >>> >>>> I have a basic question with respect to the
> >>> >>>> architecture/framework
> >>> >> so
> >>> >>>> far mentioned in the drafts in NSC. I understand the meta-data
> >>> >>>> is
> >>> a
> >>> >>>> mechanism to avoid multiple re-classifications when the packet
> >>> >> enters
> >>> >>>> the NSC domain and identifies the chain of service functions.
> >>> >>>> Now
> >>> my
> >>> >>>> understanding is that the services/applications are unaware of
> >>> >>>> the meta-data and that a layer underneath should provide the
> >>> >>>> mediation and that we use a well defined interface to the
> >>> application/service
> >>> >>>> to indicate the chain. In the context of Cloud/enterprise
> >>> >> environment
> >>> >>>> I can see this work given you can use a dedicate VLAN e.g.
> >>> >>>> within
> >>> >> the tenant.
> >>> >>>> However we also try to address residential use cases for
> mobile
> >>> and
> >>> >>>> fixed and here this becomes more tricky afais. In the
> >>> >>>> residential environment we can't expose a VLAN per
> >>> >>>> application/service per
> >>> chain
> >>> >>>> since this would not be very effective. So I am wondering how
> >>> >>>> we envision this to work?
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> nsc mailing list
> >>> >>>> nsc@ietf.org
> >>> >>>>https://www.ietf.org/mailman/listinfo/nsc
> >>> >>> _______________________________________________
> >>> >>> nsc mailing list
> >>> >>> nsc@ietf.org
> >>> >>>https://www.ietf.org/mailman/listinfo/nsc
> >>> >> _______________________________________________
> >>> >> nsc mailing list
> >>> >> nsc@ietf.org
> >>> >>https://www.ietf.org/mailman/listinfo/nsc
> >>> >
> >>
> >>
> >> _______________________________________________
> >> nsc mailing list
> >> nsc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nsc
> >>
> >_______________________________________________
> >nsc mailing list
> >nsc@ietf.org
> >https://www.ietf.org/mailman/listinfo/nsc
> >_______________________________________________
> >nsc mailing list
> >nsc@ietf.org
> >https://www.ietf.org/mailman/listinfo/nsc
>=20
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From david.i.allan@ericsson.com  Thu Jul 25 14:26:10 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DBA21F8468 for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 14:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQJ8MEpyfa4r for <nsc@ietfa.amsl.com>; Thu, 25 Jul 2013 14:26:04 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6121F90DC for <nsc@ietf.org>; Thu, 25 Jul 2013 14:26:01 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-03-51f197e8660a
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 82.F3.13034.8E791F15; Thu, 25 Jul 2013 23:26:01 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 17:26:00 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAASuGAgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAIAAEtIA///E+wAALVdugAAIKR+Q///oCACAAEFzoA==
Date: Thu, 25 Jul 2013 21:25:59 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D6F2C@eusaamb105.ericsson.se>
References: <E6C17D2345AC7A45B7D054D407AA205C115D697E@eusaamb105.ericsson.se> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF3964@xmb-aln-x09.cisco.com> <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01208861@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01208861@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPrO7L6R8DDd5vYrdYOk/d4uOpN0wW d1smMllsnNzGaHF83342iwtPpzJbPP1+nN2B3ePFlWfMHi/75zB6TPm9kdWj5chbVo8lS34y eZyb8p0xgC2KyyYlNSezLLVI3y6BK+PRhW1sBVO2MFas2tLD2MDYP4Gxi5GTQ0LARGLHv+Xs ELaYxIV769m6GLk4hASOMkq8XDaFEcJZzijx+OlnNpAqNgEDiT3/v4B1iwjcYZRY+9wGxGYW CJZ4tfwxWFxYwFLiePNrdogaK4mzm7qh6pcxSlxuCQSxWQRUJeadOskCYvMK+EocXfUHavMS Jokp8x8xgyQ4BaIk7i/ZAFbECHTe91NrmCCWiUvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUl ljzZzwJRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWMHKXF qWW56UYGmxiBUXhMgk13B+Oel5aHGKU5WJTEeVfpnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwLhZZbHU7bUXRFiu9jEsuN9pXchZliT9pvWbs72h0PM2vzN3bE/zOT5Q1pY0MHsmkZyw 76xwbujXfVduty3TWu+1bvrWk1uZrO9+cyoPrhaYtHjmEoZfMy7e85v0rHa13TKBtstWc9vV g3YvnnyfIb6T6UbLtt8XKh90r2SxlqyeP0/CI7Og2UWJpTgj0VCLuag4EQCOfqOqkAIAAA==
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 21:26:10 -0000

So it is going to pass other stuff instead.... ????

Isn't this pretty much the same, make the VF "frame transparent" and you're=
 DONE....  just need to write a BCP!

cheers
Dave

-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of NAPIE=
RALA, MARIA H
Sent: Thursday, July 25, 2013 2:17 PM
To: David Allan I; Surendra Kumar (smkumar); Ron Parker; Joel M. Halpern; L=
inda Dunbar
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Service chaining architecture question

>=20
> Ultimately the notion of subscriber will be uniquely inferable from=20
> information embedded in the customer frame when it arrives at the=20
> ingress to a chain, and that is without any protocol changes, else the=20
> network would already be broken!  So I'm not sure how that can be=20
> improved upon...translating what is in the frame to yet another=20
> identifier would not really have a lot of utility and would add IMO=20
> gratuitous complexity

Right!  Now, the services may want to know what is the subscriber id or app=
lication id. This is where the metadata comes in.
We should handle metadata in such a way that it does not require the entire=
 IP stack on the appliance to be modified to pass this extra data.

Maria
> -----Original Message-----
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20
> Surendra Kumar (smkumar)
> Sent: Thursday, July 25, 2013 11:49 AM
> To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
> Cc: nsc@ietf.org; Jim Guichard (jguichar)
> Subject: Re: [nsc] Service chaining architecture question
>=20
>=20
>=20
> On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:
>=20
> >I would prefer to think what is on the wire facilitates the=20
> >forwarding of frames, e.g. chain ID (analogous to VPN), perhaps an=20
> >entropy shorthand to help both LB and  testabilty....and facilitates=20
> >uniquely identifying the subscriber. (within the bounds of the art of=20
> >the possible, see my last post on NAT). I cannot envision a need for mor=
e.
> >And ideally I should be able to align such an approach with existing
> Cloud technologies.
> SK> For entropy you are better off choosing the right transport and
> relying on that than the chain-id.
> >
> >The individual VF should be able to determine actual subscriber to a=20
> >granularity suitable for it's purposes and obtain the necessary
> profile
> >information via a northbound interface. If you then read between the=20
> >lines,  I'm all for separation of concerns as much as possible ;-)=20
> >and not creating dependencies across chain components beyond the
> networking
> >level.
> SK> Agree but I would add that subscriber identification may require
> policy-plane interaction and if it is done once in the chain, the rest=20
> of the chain can benefit from it.
>=20
> Surendra.
> >
> >I also do not see a huge difference between a service chain, and any=20
> >other flow of information across a string of processing elements.=20
> >Just in one application, the packet is preserved with perhaps a bit=20
> >of fondling, and in others the content may be completely=20
> >deconstructed, and repackaged into a set of transactions....and what=20
> >is on the wire between chain components does not remotely look like=20
> >what went in the
> front end...
> >
> >Cheers
> >Dave
> >
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20
> >Ron Parker
> >Sent: Wednesday, July 24, 2013 5:42 PM
> >To: Joel M. Halpern; Linda Dunbar
> >Cc: nsc@ietf.org; Jim Guichard (jguichar)
> >Subject: Re: [nsc] Service chaining architecture question
> >
> >Thanks, all, for a lively discussion on this topic.
> >
> >One thing that flavors the discussion of network service chaining is
> the
> >definition of "service".   It really means different things to
> different
> >people.   We networking types tend to look at it as a software
> >application or software system composed of multiple software
> applications
> >(i.e., an HTTP content filter).   But when I interact with the
> business
> >folks, especially on the operator side, I hear a different notion of=20
> >"service" -- something subscribers pay for, government mandates, etc.
> >This is why, IMO, it is defensible to say that the=20
> >HTTP-content-filter-children is a distinct service from=20
> >HTTP-content-filter-adult, even if both are realized on the same
> server
> >by the same software application using the same global URL database.
> >
> >It does sound like at least some that have chimed in do feel that=20
> >both the general service type (i.e., HTTP content filter) and the=20
> >policy
> set
> >need to be conveyed in some manner.    How to do this is a set of
> >tradeoffs around control plane protocol and data plane encapsulation.
> >Without any control plane, both types of information need to be on the
> >wire in some form.   I will assume that the policy set identity is
> >distinct at each service instance (i.e, policy set 2 at the HTTP=20
> >content filter does not imply the same set of subscribers as policy
> set 2 at the
> >firewall).   I will also assume that the meaning and interpretation of
> a
> >policy set identity is specific to that type of service and probably
> to
> >the vendor that supplied the service.   This is similar to when a PCRF
> >names a PCC rulebase rather than supplying the full set of explicit
> PCC
> >rules.
> >
> >The advantage of a single chain ID that can be interpreted as a=20
> >sequence of {service-type-instance, policy-set} is that it minimizes=20
> >the per-packet encapsulation requirement (i.e., a single GRE key could
> >suffice).   The disadvantage that has been pointed out is that global
> >coordination of this identity is required and the number of=20
> >combinations could become unwieldy.
> >
> >Another approach could be to have a new encapsulation that represents
> a
> >stack of 2-tuples {service-ip-address, service-specific-policy-id},=20
> >or even 3-tuples {service-ip-address, service-type,=20
> >service-specific-policy-id} where the 3-tuple brings the added=20
> >advantage of allowing for multiple dissimilar services realized by=20
> >the
> same server
> >at the same server ip address.   The advantage of this approach is
> that
> >it avoids the combinatorial explosion problem, but it requires a
> larger
> >and variable length encapsulation.
> >
> >If the global chain id approach is used, a control plane protocol
> could
> >be used to distribute the definitions of each chain (i.e, each chain
> is
> >really a stack of 2-tuples or 3-tuples, per description above).
> >
> >Thanks.
> >
> >    Ron
> >
> >-----Original Message-----
> >From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >Sent: Wednesday, July 24, 2013 7:35 PM
> >To: Linda Dunbar
> >Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
> >Subject: Re: [nsc] Service chaining architecture question
> >
> >I would not be surprised if we want all three of Service Chain,
> Service
> >Policy, and Subscriber / user identity in the packet.
> >If the Chain is in the VLAN / MPLS label, then we can discuss whether=20
> >the other information goes in additional ids of the same type or in a=20
> >carried header.  I can construct arguments for either approach.
> >
> >It may be easier to just carry the subscriber identity, and used the=20
> >same management systems to assign policies to the devices that care.
> I
> >am concerned that it may not be practical to use a single policy=20
> >identifier to specify which HTTP rule set to use, which Firewall rule=20
> >set to use, and then which specific policy for other user selected=20
> >policy applications.
> >
> >Yours,
> >Joel
> >
> >On 7/24/13 7:30 PM, Linda Dunbar wrote:
> >> Joel,
> >>> -----Original Message-----
> >>>
> >>> Yes, having the chain ingress node mark the traffic makes good
> sense.
> >>> Having it mark the subscriber identity and the chain to be
> traversed
> >>> seems quite sensible.
> >>>
> >>> The difference I think I have with Ron is that he proposes to use=20
> >>> one identifier for both entities.
> >> [Linda] I hope you don't mean per subscriber identity, do you? With=20
> >> today's PCRF, subscribers are categorized based on their
> subscription
> >> types. Throughout the network, the "subscription types" dictate=20
> >> what service modules their corresponding traffic need to traverse
> through.
> >> Some service modules might need to examine packets deeper (i.e.=20
> >> look into payload) for their intended functions. They may need to=20
> >> extract the "HTTP header" or HTTP messages from one or multiple packet=
s.
> >> That causes, as Dave said, a
> >>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two=20
> >>> MPLS labels.
> >> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> >> The subscriber identity could be some bits in the payload.
> >>>
> >>> And if the existing boxes don't know how to handle that (as seems
> >>> likely) then we need a proxy / support function to translate the=20
> >>> common protocol into whatever they used before we got something=20
> >>> generally usable out there.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> >>> >
> >>> > Agree with Ron that it is better to have fewer nodes in network
> to
> >>> make subscriber-aware policy decisions.
> >>> >
> >>> > Besides, it is not uncommon for multiple subscribers to share
> same
> >>> sequence of service modules. In this environment, if the network=20
> >>> edge nodes, such as Broadband Network Gateway or Cell Site=20
> >>> Gateway, can use Layer 2 or 3 labels to mark the traffic, the=20
> >>> subsequent network nodes can steer traffic to the needed service=20
> >>> modules without looking into "Mega data" or other higher layer=20
> >>> fields in
> the data frames.
> >>> >
> >>> > This approach can make "service chain" work without making
> changes
> >>> > to
> >>> majority of existing deployed network elements.
> >>> >
> >>> > Linda
> >>> >
> >>> >
> >>> >
> >>> >> -----Original Message-----
> >>> >> Jim,
> >>> >>
> >>> >> Yes, that could work, too, conceptually.   But it does require
> that
> >>> >> each coarsely-defined network service have access to a
> >>> >> subscriber-
> >>> aware
> >>> >> policy resolution mechanism.   IMO, it is better to have fewer
> >>> network
> >>> >> elements making subscriber-aware policy decisions.
> >>> >
> >>> >
> >>> >>
> >>> >>     Ron
> >>> >>
> >>> >>
> >>> >> -----Original Message-----
> >>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >>> >> Sent: Wednesday, July 24, 2013 6:17 PM
> >>> >> To: Ron Parker
> >>> >> Cc: Joel M. Halpern; nsc@ietf.org
> >>> >> Subject: Re: [nsc] Service chaining architecture question
> >>> >>
> >>> >> Ron,
> >>> >> Or alternatively carry the subscriber awareness in metadata=20
> >>> >> thereby utilizing a single chain.
> >>> >>
> >>> >> Sent from my iPhone
> >>> >>
> >>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> >>> >> <Ron_Parker@affirmednetworks.com> wrote:
> >>> >>
> >>> >>> Joel,
> >>> >>>
> >>> >>> IMO, the primary reason for understanding the subscriber=20
> >>> >>> identity
> >>> at
> >>> >> a network service is to choose from a differentiated set of
> >>>policies.
> >>> >> I think there is utility and efficiency in driving that
> selection
> >>> from
> >>> >> one place -- the network services classifier.     Say there were
> 2
> >>> >> groups of subscribers -- children and adults.   Let's now define
> 2
> >>> >> chains, where the chains have a business-based meaning to the
> >>> operator.
> >>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP=
-
> >>> filter-
> >>> >> adult + Firewall-adult.    The referenced network services are
> >>> logical
> >>> >> and it is possible, but not required, that multiple logical
> network
> >>> >> services be located at the same IP address or FQDN.
> Conveying
> >>> the
> >>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> >>> ID, ...)
> >>> >> allows the IP-addressable server that realizes these service(s)=20
> >>> >> to
> >>> know
> >>> >> two things -- 1) which logical network function should be
> invoked
> >>> and 2)
> >>> >> which logical network function is next.
> >>> >>>
> >>> >>> Thanks.
> >>> >>> Ron
> >>> >>>
> >>> >>> -----Original Message-----
> >>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> >>> >>> To: Ron Parker
> >>> >>> Cc: nsc@ietf.org
> >>> >>> Subject: Re: [nsc] Service chaining architecture question
> >>> >>>
> >>> >>> Ron,
> >>> >>>      maybe I am missing something, but you seem to lay out=20
> >>> >>> very
> >>> nicely
> >>> >> the case for wanting both service chain identification and
> >>> separately
> >>> >> subscriber identification.  Then the HTTP filter can use the
> >>> subscriber
> >>> >> ID to decide which exact content filtering behavior it should
> apply.
> >>> I
> >>> >> would not want to fold that level of detail into the chain=20
> >>> >> identification.
> >>> >>>
> >>> >>> Yours,
> >>> >>> Joel
> >>> >>>
> >>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> >>> >>>> Dave,
> >>> >>>>
> >>> >>>> I agree that the number of chains is unlikely to scale to=20
> >>> >>>> vast
> >>> >> numbers
> >>> >>>> (i.e., millions).     And I agree that it is bounded from a
> >>> >> practical
> >>> >>>> business perspective, as you point out.
> >>> >>>>
> >>> >>>> You may already be on this page, but I wanted to point out a=20
> >>> >>>> distinction of coarse-grained definition of a service=20
> >>> >>>> function
> vs.
> >>> >> finer-grained
> >>> >>>> definition of a service function.   Consider a service
> function to
> >>> >> be
> >>> >>>> logical in such a way that the identity of the logical
> function
> >>> may
> >>> >> also
> >>> >>>> imply some differentiated behavior.   For example, a
> conceptual
> >>> >> function
> >>> >>>> is HTTP content filtering.    This conceptual function can
> then be
> >>> >>>> further instantiated at the logical level based on=20
> >>> >>>> differentiated policies such as content-filter-children,=20
> >>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm=20
> >>> >>>> taking
> >>> no
> >>> >> stand on opt-in vs. opt-out, Mr.
> >>> >>>> Cameron).   It may be that the same network element (dedicated
> >>> >> physical
> >>> >>>> box or virtual network function) realizes all 3 of the example
> >>> >>>> policies.   The HTTP content filtering network function is
> really
> >>> 3
> >>> >>>> logical network functions from the perspective of inclusion=20
> >>> >>>> in a
> >>> >> service
> >>> >>>> chain.   Now extend this to multiple conceptual functions that
> >>> >> utilize
> >>> >>>> differentiated policies and the number of combinations will=20
> >>> >>>> grow,
> >>> at
> >>> >>>> least modestly.
> >>> >>>>
> >>> >>>> Thanks,
> >>> >>>>
> >>> >>>> Ron
> >>> >>>>
> >>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
> >>> Behalf
> >>> >>>> Of *David Allan I
> >>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> >>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
> nsc@ietf.org
> >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>> >>>>
> >>> >>>> Saying functions will have a problem with something that
> exists
> >>> >>>> as
> >>> a
> >>> >>>> potential rationale for defining something new with exactly
> the
> >>> same
> >>> >>>> properties and problems does not quite work for me....
> >>> >>>>
> >>> >>>> VLANs on a vNIC or multiple vNICs (depending on the
> application
> >>> >> stack
> >>> >>>> construction and this being combined with application
> >>> "cooperation"
> >>> >>>> to preserve pairwise mappings of either VID/NIC tuples or=20
> >>> >>>> simply
> >>> >>>> NICs) currently exist as potential vehicles for preserving=20
> >>> >>>> chain context and avoiding per hop classification. Anything=20
> >>> >>>> else will be implemented more or less the same way and have=20
> >>> >>>> exactly the same
> >>> set
> >>> >>>> of scaling and application design issues...Some extra=20
> >>> >>>> information available on a single interface, or achieved by=20
> >>> >>>> mapping chain instances onto one of a plurality of
> interfaces....
> >>> >>>>
> >>> >>>> But to back up... I'm not a carrier employee but I cannot=20
> >>> >>>> envision
> >>> a
> >>> >>>> carrier offering potentially 1000s of distinct service=20
> >>> >>>> bundles
> >>> >> ("pick
> >>> >>>> 53 from column A and 49 from column B"). So I suspect a much
> >>> smaller
> >>> >>>> number is realistic for  the number of chains a function=20
> >>> >>>> instance
> >>> is
> >>> >>>> expected to participate in, even allowing for dynamic=20
> >>> >>>> reclassification of flows at a chain ingress to "skip a few=20
> >>> >>>> functions".... These are things that are fully=20
> >>> >>>> operationalized in OSS, have policy associated with, have=20
> >>> >>>> been industrialized and demonstrated to work prior to=20
> >>> >>>> deployment. Going all combinatorial
> >>> on
> >>> >> this will break that big time....
> >>> >>>>
> >>> >>>> So are we really discussing a function participating in more=20
> >>> >>>> than
> >>> a
> >>> >>>> handful of chain instances? And either a plurality of vNICs=20
> >>> >>>> or
> >>> VIDs
> >>> >>>> being actually more than sufficient?
> >>> >>>>
> >>> >>>> Thanks
> >>> >>>>
> >>> >>>> Dave
> >>> >>>>
> >>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> >>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
> >>> >>>> (Wim)
> >>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> >>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
> >>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> >>> >>>>
> >>> >>>> indeed
> >>> >>>>
> >>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> >>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> >>> >>>> *Date: *Wednesday 24 July 2013 15:54
> >>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> >>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
> >>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> >>> >>>> *Subject: *AW: Service chaining architecture question
> >>> >>>>
> >>> >>>> Hi Wim,
> >>> >>>>
> >>> >>>> I think not only effectivness/scalability might be a problem=20
> >>> >>>> but
> >>> >> also
> >>> >>>> the fact that not all applications (service bringing
> functions)
> >>> are
> >>> >>>> able to handle packets coming from/going to potentially=20
> >>> >>>> thousands
> >>> of
> >>> >>>> different VLANs at the same time. VLANs will work in certain=20
> >>> >>>> environments but not in all. I see the need for an=20
> >>> >>>> information exchange between the application and a mediation=20
> >>> >>>> layer as
> well.
> >>> >>>> Ideally this should be as simple as possible without heavy=20
> >>> >>>> impact
> >>> on
> >>> >>>> the application itself (might be difficult to achieve but=20
> >>> >>>> from my experience it is not very likely, that there will be=20
> >>> >>>> big rewrites
> >>> of
> >>> >>>> existing applications in order to support the chaining).
> >>> >>>>
> >>> >>>>    regards
> >>> >>>>
> >>> >>>>       Nic
> >>> >>>>
> >>> >>>> -------------------------------------------------------------
> >>> >>>> -
> -
> >>> >>>> -
> >>> >>>> --
> >>> --
> >>> >> -
> >>> >>>> -
> >>> >>>> --
> >>> >>>>
> >>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> >>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx,=20
> >>> >>>> Wim
> >>> (Wim)
> >>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> >>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> >>> >>>> *Betreff:* [nsc] Service chaining architecture question
> >>> >>>>
> >>> >>>> I have a basic question with respect to the=20
> >>> >>>> architecture/framework
> >>> >> so
> >>> >>>> far mentioned in the drafts in NSC. I understand the=20
> >>> >>>> meta-data is
> >>> a
> >>> >>>> mechanism to avoid multiple re-classifications when the=20
> >>> >>>> packet
> >>> >> enters
> >>> >>>> the NSC domain and identifies the chain of service functions.
> >>> >>>> Now
> >>> my
> >>> >>>> understanding is that the services/applications are unaware=20
> >>> >>>> of the meta-data and that a layer underneath should provide=20
> >>> >>>> the mediation and that we use a well defined interface to the
> >>> application/service
> >>> >>>> to indicate the chain. In the context of Cloud/enterprise
> >>> >> environment
> >>> >>>> I can see this work given you can use a dedicate VLAN e.g.
> >>> >>>> within
> >>> >> the tenant.
> >>> >>>> However we also try to address residential use cases for
> mobile
> >>> and
> >>> >>>> fixed and here this becomes more tricky afais. In the=20
> >>> >>>> residential environment we can't expose a VLAN per=20
> >>> >>>> application/service per
> >>> chain
> >>> >>>> since this would not be very effective. So I am wondering how=20
> >>> >>>> we envision this to work?
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> nsc mailing list
> >>> >>>> nsc@ietf.org
> >>> >>>>https://www.ietf.org/mailman/listinfo/nsc
> >>> >>> _______________________________________________
> >>> >>> nsc mailing list
> >>> >>> nsc@ietf.org
> >>> >>>https://www.ietf.org/mailman/listinfo/nsc
> >>> >> _______________________________________________
> >>> >> nsc mailing list
> >>> >> nsc@ietf.org
> >>> >>https://www.ietf.org/mailman/listinfo/nsc
> >>> >
> >>
> >>
> >> _______________________________________________
> >> nsc mailing list
> >> nsc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nsc
> >>
> >_______________________________________________
> >nsc mailing list
> >nsc@ietf.org
> >https://www.ietf.org/mailman/listinfo/nsc
> >_______________________________________________
> >nsc mailing list
> >nsc@ietf.org
> >https://www.ietf.org/mailman/listinfo/nsc
>=20
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

From mohamed.boucadair@orange.com  Fri Jul 26 04:51:45 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177F21F9339 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 04:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpnTqFNjFGCe for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 04:51:40 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6019321F9360 for <nsc@ietf.org>; Fri, 26 Jul 2013 04:51:37 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8417E2DC4C8; Fri, 26 Jul 2013 13:51:36 +0200 (CEST)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6327C27C046; Fri, 26 Jul 2013 13:51:36 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 26 Jul 2013 13:51:36 +0200
From: <mohamed.boucadair@orange.com>
To: Paul Quinn <paulq@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>
Date: Fri, 26 Jul 2013 13:51:35 +0200
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: Ac6JU8IWd7epOcaqQBOM3/ii/p+23gAoXh0Q
Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <585570A8-704B-452A-97EA-0EDD71449E09@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E2CD@MBX021-W3-CA-2.exch021.domain.local> <4A95BA014132FF49AE685FAB4B9F17F645B4D273@dfweml509-mbx.china.huawei.com> <51F05F5C.5050202@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F645B4D37E@dfweml509-mbx.china.huawei.com> <51F064A2.3060601@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01207D79@MISOUT7MSGUSR9I.ITServices.sbc.com> <26D10EA4-D7F4-4F4C-8AFE-F6EA40BA152E@cisco.com>
In-Reply-To: <26D10EA4-D7F4-4F4C-8AFE-F6EA40BA152E@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.45418
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 11:51:45 -0000

Dear Paul,=20

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De=A0: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Pa=
ul
>Quinn
>Envoy=E9=A0: jeudi 25 juillet 2013 18:26
>=C0=A0: NAPIERALA, MARIA H
>Cc=A0: nsc@ietf.org; Jim Guichard (jguichar); Joel M. Halpern; Ron Parker;
>Linda Dunbar
>Objet=A0: Re: [nsc] Service chaining architecture question
>
>Hi Maria,
>
>
>On Jul 24, 2013, at 4:47 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:
>
>> I would add the following:
>>
>>> I would not be surprised if we want all three of
>>> Service Chain,
>>> Service Policy, and
>>> Subscriber / user identity
>>> in the packet.
>>
>>> If the Chain is in the VLAN / MPLS label,
>>
>> Yes. We should separate signaling of network connectivity from metadata
>associated with the payload. These are two separate problems. In a data
>center, some VMs will be participating in service chains, some not, at a
>given time. We don't want to end up with two different forwarding paradigm=
s
>for both types of those VMs.
>>
>
>IMHO, you want to separate both chaining information and metadata.  The
>chain information is used to provide a form of indirection into the
>existing forward models.
>
>
>
>>> then we can discuss whether the other information goes in additional id=
s
>of the same type or in a
>>> carried header.  I can construct arguments for either approach.
>>
>> We should avoid introducing a new header for carrying metadata (such as
>subscriber-id). The same result can be achieved by using the IP header of
>the payload packet (such as IP option or flow label).
>>
>
>Adding data to existing IP headers might not prove viable, most fields are
>either spoken for, or have significant technical limitations.  For example=
,
>IP options are usually filtered/dropped

[Med] This is not a valid argument for the chaining case. This limitation w=
ould be a no starting point if the chaining procedure is to be activated at=
 the level of Internet...which is not the case here. The solution will be e=
nabled in a controlled environment, and as such, introducing a new IP optio=
n, IPv6 extension header, should be part of the viable solutions. It is too=
 early at this stage to exclude any candidate channel to convey the marking=
 bits.=20


From jguichar@cisco.com  Fri Jul 26 05:48:48 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB9721F93B9 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 05:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKwKZU5CL-yb for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 05:48:42 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF621F91F4 for <nsc@ietf.org>; Fri, 26 Jul 2013 05:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1035; q=dns/txt; s=iport; t=1374842922; x=1376052522; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yizbucTW5XrT8kBYQMGWKnrEso8eWmH8+MQ2LyD+TaM=; b=AbicGO+2zhMm/C9q8cFyOX1/nOoiFPvB6zvETf/m3CeT+in/Vtva3c9N 8Ar8CgbhxjWdvxyI3X1jsoGmoEJv8jPled8pFVA1fxXIEMBL6WA+IcJ7b +/jqpDRV1V9s/4fHzYNsZiA7gNQJr6ayTsVg4YKnOqvXh0iPAeY24Nb/s g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAFdv8lGtJXG+/2dsb2JhbABagwaBBb1DgRcWdIImAQQ6OgUSAQgSEBRCFw4CBAENBQgTh3W5Jo9MMQeDFm8DohGHGoMUgio
X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208";a="239851565"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2013 12:48:38 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6QCmc1e026159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 12:48:38 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 07:48:38 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Paul Quinn (paulq)" <paulq@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A
Date: Fri, 26 Jul 2013 12:48:37 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.211]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2D05C61E8E07EB46B72BCF2546642447@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 12:48:48 -0000

Hi Med,

On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
<mohamed.boucadair@orange.com> wrote:

>>
>>Adding data to existing IP headers might not prove viable, most fields
>>are
>>either spoken for, or have significant technical limitations.  For
>>example,
>>IP options are usually filtered/dropped
>
>[Med] This is not a valid argument for the chaining case. This limitation
>would be a no starting point if the chaining procedure is to be activated
>at the level of Internet...which is not the case here. The solution will
>be enabled in a controlled environment, and as such, introducing a new IP
>option, IPv6 extension header, should be part of the viable solutions. It
>is too early at this stage to exclude any candidate channel to convey the
>marking bits.=20

Jim> even in a controlled environment by using IP options you may prevent
cross-domain chaining and at the very least prevent firewalls being part
of the chain; every firewall I know about will drop packets containing IP
options.=20

>


From smkumar@cisco.com  Fri Jul 26 05:53:45 2013
Return-Path: <smkumar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7453221F9339 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 05:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWwcCNLydvqR for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 05:53:40 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6921F89D8 for <nsc@ietf.org>; Fri, 26 Jul 2013 05:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22437; q=dns/txt; s=iport; t=1374843220; x=1376052820; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=apkL7qLHeqxCYyyn9Rs35PSMgUcUM7IX2kf+S84TE84=; b=C4qp/rCHl+sWLBVCp+Bjvjwx40mgoXvdUUzpJrAGh7Zurqs5mmXpqI1T gI8jcjXRQ8tt9ck6AoWpRNzIg0XQcXw5GVY9ZXaksX2drxfnfNd5fjiGM d1Np6G3t5+CSc+v+wwynRIWwW0NKQR+vquKGVfUEUGYY6D4rsO8UUpTbj o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAIRw8lGtJV2a/2dsb2JhbABRCYMGNVC9Q4EXFnSCJAEBAQQBAQEXIC0HCwwGAQgRAQIBAQEBCgMRCS4LFAMGCAIEAQ0FCBOHdQy5BgSORYEHBisHAgSDEG8DlAiOCYcagxSCKg
X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208";a="239853138"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2013 12:53:39 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6QCrctl014709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 12:53:38 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 07:53:38 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: David Allan I <david.i.allan@ericsson.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAEtIAgAAMH4CAAX/IgP//tqIAgAF4ToA=
Date: Fri, 26 Jul 2013 12:53:38 +0000
Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF405A@xmb-aln-x09.cisco.com>
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.21.124.124]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C21FD297345E5747835F3743F41079F9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 12:53:45 -0000

Dave,

If I understand you correctly, you are not disputing that some meta-data
is needed for correctness of steering packets around (apart from the chain
Id itself) but just that a service can derive some kind of metadata
independently, every time.

Deriving meta-data (from the packet,) independently by a service has its
downsides:
* It loads the north-bound interface, if every service does this ...
* You made a case for NAT already and I would think, if you need a service
after a NAT in the chain, source-ip is not going to help
* In some solutions, I could potentially have the network determine which
policy to use while the service simply executes that policy - in this
scenario, the service itself depends on the policy-input from the network
(an external classifier); we do not want to preclude such use-cases
* In some other cases I can imagine deriving policies not only based the
packet contents but also on various other attributes including
environmental at the network or one of the services which may not be
available at another service


IOW, there is a lot of value that meta-data can bring to enhanced service
delivery.
Surendra

On 7/26/13 1:26 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:

>Hi Surendra:
>
>Unless the intent is to embed RADIUS records or similar in the meta data,
>all that is going to be carried is a subscriber ID itself, which implies
>a policy lookup for each function that is subscriber stateful and needs
>subscriber specific policies.
>
>Ultimately the notion of subscriber will be uniquely inferable from
>information embedded in the customer frame when it arrives at the ingress
>to a chain, and that is without any protocol changes, else the network
>would already be broken!  So I'm not sure how that can be improved
>upon...translating what is in the frame to yet another identifier would
>not really have a lot of utility and would add IMO gratuitous complexity
>
>Dave
>
>-----Original Message-----
>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of
>Surendra Kumar (smkumar)
>Sent: Thursday, July 25, 2013 11:49 AM
>To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
>Cc: nsc@ietf.org; Jim Guichard (jguichar)
>Subject: Re: [nsc] Service chaining architecture question
>
>
>
>On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:
>
>>I would prefer to think what is on the wire facilitates the forwarding
>>of frames, e.g. chain ID (analogous to VPN), perhaps an entropy
>>shorthand to help both LB and  testabilty....and facilitates uniquely
>>identifying the subscriber. (within the bounds of the art of the
>>possible, see my last post on NAT). I cannot envision a need for more.
>>And ideally I should be able to align such an approach with existing
>>Cloud technologies.
>SK> For entropy you are better off choosing the right transport and
>relying on that than the chain-id.
>>
>>The individual VF should be able to determine actual subscriber to a
>>granularity suitable for it's purposes and obtain the necessary profile
>>information via a northbound interface. If you then read between the
>>lines,  I'm all for separation of concerns as much as possible ;-) and
>>not creating dependencies across chain components beyond the networking
>>level.
>SK> Agree but I would add that subscriber identification may require
>policy-plane interaction and if it is done once in the chain, the rest of
>the chain can benefit from it.
>
>Surendra.
>>
>>I also do not see a huge difference between a service chain, and any
>>other flow of information across a string of processing elements. Just
>>in one application, the packet is preserved with perhaps a bit of
>>fondling, and in others the content may be completely deconstructed,
>>and repackaged into a set of transactions....and what is on the wire
>>between chain components does not remotely look like what went in the
>>front end...
>>
>>Cheers
>>Dave
>>
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of
>>Ron Parker
>>Sent: Wednesday, July 24, 2013 5:42 PM
>>To: Joel M. Halpern; Linda Dunbar
>>Cc: nsc@ietf.org; Jim Guichard (jguichar)
>>Subject: Re: [nsc] Service chaining architecture question
>>
>>Thanks, all, for a lively discussion on this topic.
>>
>>One thing that flavors the discussion of network service chaining is the
>>definition of "service".   It really means different things to different
>>people.   We networking types tend to look at it as a software
>>application or software system composed of multiple software applications
>>(i.e., an HTTP content filter).   But when I interact with the business
>>folks, especially on the operator side, I hear a different notion of
>>"service" -- something subscribers pay for, government mandates, etc.
>>This is why, IMO, it is defensible to say that the
>>HTTP-content-filter-children is a distinct service from
>>HTTP-content-filter-adult, even if both are realized on the same server
>>by the same software application using the same global URL database.
>>
>>It does sound like at least some that have chimed in do feel that both
>>the general service type (i.e., HTTP content filter) and the policy set
>>need to be conveyed in some manner.    How to do this is a set of
>>tradeoffs around control plane protocol and data plane encapsulation.
>>Without any control plane, both types of information need to be on the
>>wire in some form.   I will assume that the policy set identity is
>>distinct at each service instance (i.e, policy set 2 at the HTTP
>>content filter does not imply the same set of subscribers as policy set
>>2 at the
>>firewall).   I will also assume that the meaning and interpretation of a
>>policy set identity is specific to that type of service and probably to
>>the vendor that supplied the service.   This is similar to when a PCRF
>>names a PCC rulebase rather than supplying the full set of explicit PCC
>>rules.    =20
>>
>>The advantage of a single chain ID that can be interpreted as a
>>sequence of {service-type-instance, policy-set} is that it minimizes
>>the per-packet encapsulation requirement (i.e., a single GRE key could
>>suffice).   The disadvantage that has been pointed out is that global
>>coordination of this identity is required and the number of
>>combinations could become unwieldy.
>>
>>Another approach could be to have a new encapsulation that represents a
>>stack of 2-tuples {service-ip-address, service-specific-policy-id}, or
>>even 3-tuples {service-ip-address, service-type,
>>service-specific-policy-id} where the 3-tuple brings the added
>>advantage of allowing for multiple dissimilar services realized by the
>>same server
>>at the same server ip address.   The advantage of this approach is that
>>it avoids the combinatorial explosion problem, but it requires a larger
>>and variable length encapsulation.
>>
>>If the global chain id approach is used, a control plane protocol could
>>be used to distribute the definitions of each chain (i.e, each chain is
>>really a stack of 2-tuples or 3-tuples, per description above).
>>
>>Thanks.
>>
>>    Ron
>>
>>-----Original Message-----
>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>Sent: Wednesday, July 24, 2013 7:35 PM
>>To: Linda Dunbar
>>Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
>>Subject: Re: [nsc] Service chaining architecture question
>>
>>I would not be surprised if we want all three of Service Chain, Service
>>Policy, and Subscriber / user identity in the packet.
>>If the Chain is in the VLAN / MPLS label, then we can discuss whether
>>the other information goes in additional ids of the same type or in a
>>carried header.  I can construct arguments for either approach.
>>
>>It may be easier to just carry the subscriber identity, and used the
>>same management systems to assign policies to the devices that care.  I
>>am concerned that it may not be practical to use a single policy
>>identifier to specify which HTTP rule set to use, which Firewall rule
>>set to use, and then which specific policy for other user selected
>>policy applications.
>>
>>Yours,
>>Joel
>>
>>On 7/24/13 7:30 PM, Linda Dunbar wrote:
>>> Joel,
>>>> -----Original Message-----
>>>>
>>>> Yes, having the chain ingress node mark the traffic makes good sense.
>>>> Having it mark the subscriber identity and the chain to be traversed
>>>> seems quite sensible.
>>>>
>>>> The difference I think I have with Ron is that he proposes to use
>>>> one identifier for both entities.
>>> [Linda] I hope you don't mean per subscriber identity, do you? With
>>> today's PCRF, subscribers are categorized based on their subscription
>>> types. Throughout the network, the "subscription types" dictate what
>>> service modules their corresponding traffic need to traverse through.
>>> Some service modules might need to examine packets deeper (i.e. look
>>> into payload) for their intended functions. They may need to extract
>>> the "HTTP header" or HTTP messages from one or multiple packets.
>>> That causes, as Dave said, a
>>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two
>>>> MPLS labels.
>>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>>> The subscriber identity could be some bits in the payload.
>>>>
>>>> And if the existing boxes don't know how to handle that (as seems
>>>> likely) then we need a proxy / support function to translate the
>>>> common protocol into whatever they used before we got something
>>>> generally usable out there.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>>>> >
>>>> > Agree with Ron that it is better to have fewer nodes in network to
>>>> make subscriber-aware policy decisions.
>>>> >
>>>> > Besides, it is not uncommon for multiple subscribers to share same
>>>> sequence of service modules. In this environment, if the network
>>>> edge nodes, such as Broadband Network Gateway or Cell Site Gateway,
>>>> can use Layer 2 or 3 labels to mark the traffic, the subsequent
>>>> network nodes can steer traffic to the needed service modules
>>>> without looking into "Mega data" or other higher layer fields in the
>>>>data frames.
>>>> >
>>>> > This approach can make "service chain" work without making changes
>>>> > to
>>>> majority of existing deployed network elements.
>>>> >
>>>> > Linda
>>>> >
>>>> >
>>>> >
>>>> >> -----Original Message-----
>>>> >> Jim,
>>>> >>
>>>> >> Yes, that could work, too, conceptually.   But it does require that
>>>> >> each coarsely-defined network service have access to a
>>>> >> subscriber-
>>>> aware
>>>> >> policy resolution mechanism.   IMO, it is better to have fewer
>>>> network
>>>> >> elements making subscriber-aware policy decisions.
>>>> >
>>>> >
>>>> >>
>>>> >>     Ron
>>>> >>
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>>>> >> To: Ron Parker
>>>> >> Cc: Joel M. Halpern; nsc@ietf.org
>>>> >> Subject: Re: [nsc] Service chaining architecture question
>>>> >>
>>>> >> Ron,
>>>> >> Or alternatively carry the subscriber awareness in metadata
>>>> >> thereby utilizing a single chain.
>>>> >>
>>>> >> Sent from my iPhone
>>>> >>
>>>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>>>> >> <Ron_Parker@affirmednetworks.com> wrote:
>>>> >>
>>>> >>> Joel,
>>>> >>>
>>>> >>> IMO, the primary reason for understanding the subscriber
>>>> >>> identity
>>>> at
>>>> >> a network service is to choose from a differentiated set of
>>>>policies.
>>>> >> I think there is utility and efficiency in driving that selection
>>>> from
>>>> >> one place -- the network services classifier.     Say there were 2
>>>> >> groups of subscribers -- children and adults.   Let's now define 2
>>>> >> chains, where the chains have a business-based meaning to the
>>>> operator.
>>>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>>>> filter-
>>>> >> adult + Firewall-adult.    The referenced network services are
>>>> logical
>>>> >> and it is possible, but not required, that multiple logical network
>>>> >> services be located at the same IP address or FQDN.     Conveying
>>>> the
>>>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>>>> ID, ...)
>>>> >> allows the IP-addressable server that realizes these service(s)
>>>> >> to
>>>> know
>>>> >> two things -- 1) which logical network function should be invoked
>>>> and 2)
>>>> >> which logical network function is next.
>>>> >>>
>>>> >>> Thanks.
>>>> >>> Ron
>>>> >>>
>>>> >>> -----Original Message-----
>>>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>>>> >>> To: Ron Parker
>>>> >>> Cc: nsc@ietf.org
>>>> >>> Subject: Re: [nsc] Service chaining architecture question
>>>> >>>
>>>> >>> Ron,
>>>> >>>      maybe I am missing something, but you seem to lay out very
>>>> nicely
>>>> >> the case for wanting both service chain identification and
>>>> separately
>>>> >> subscriber identification.  Then the HTTP filter can use the
>>>> subscriber
>>>> >> ID to decide which exact content filtering behavior it should
>>>>apply.
>>>> I
>>>> >> would not want to fold that level of detail into the chain
>>>> >> identification.
>>>> >>>
>>>> >>> Yours,
>>>> >>> Joel
>>>> >>>
>>>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>>> >>>> Dave,
>>>> >>>>
>>>> >>>> I agree that the number of chains is unlikely to scale to vast
>>>> >> numbers
>>>> >>>> (i.e., millions).     And I agree that it is bounded from a
>>>> >> practical
>>>> >>>> business perspective, as you point out.
>>>> >>>>
>>>> >>>> You may already be on this page, but I wanted to point out a
>>>> >>>> distinction of coarse-grained definition of a service function
>>>>vs.
>>>> >> finer-grained
>>>> >>>> definition of a service function.   Consider a service function
>>>>to
>>>> >> be
>>>> >>>> logical in such a way that the identity of the logical function
>>>> may
>>>> >> also
>>>> >>>> imply some differentiated behavior.   For example, a conceptual
>>>> >> function
>>>> >>>> is HTTP content filtering.    This conceptual function can then
>>>>be
>>>> >>>> further instantiated at the logical level based on
>>>> >>>> differentiated policies such as content-filter-children,
>>>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
>>>> >>>> taking
>>>> no
>>>> >> stand on opt-in vs. opt-out, Mr.
>>>> >>>> Cameron).   It may be that the same network element (dedicated
>>>> >> physical
>>>> >>>> box or virtual network function) realizes all 3 of the example
>>>> >>>> policies.   The HTTP content filtering network function is really
>>>> 3
>>>> >>>> logical network functions from the perspective of inclusion in
>>>> >>>> a
>>>> >> service
>>>> >>>> chain.   Now extend this to multiple conceptual functions that
>>>> >> utilize
>>>> >>>> differentiated policies and the number of combinations will
>>>> >>>> grow,
>>>> at
>>>> >>>> least modestly.
>>>> >>>>
>>>> >>>> Thanks,
>>>> >>>>
>>>> >>>> Ron
>>>> >>>>
>>>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>>>> Behalf
>>>> >>>> Of *David Allan I
>>>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>> >>>>
>>>> >>>> Saying functions will have a problem with something that exists
>>>> >>>> as
>>>> a
>>>> >>>> potential rationale for defining something new with exactly the
>>>> same
>>>> >>>> properties and problems does not quite work for me....
>>>> >>>>
>>>> >>>> VLANs on a vNIC or multiple vNICs (depending on the application
>>>> >> stack
>>>> >>>> construction and this being combined with application
>>>> "cooperation"
>>>> >>>> to preserve pairwise mappings of either VID/NIC tuples or
>>>> >>>> simply
>>>> >>>> NICs) currently exist as potential vehicles for preserving
>>>> >>>> chain context and avoiding per hop classification. Anything
>>>> >>>> else will be implemented more or less the same way and have
>>>> >>>> exactly the same
>>>> set
>>>> >>>> of scaling and application design issues...Some extra
>>>> >>>> information available on a single interface, or achieved by
>>>> >>>> mapping chain instances onto one of a plurality of interfaces....
>>>> >>>>
>>>> >>>> But to back up... I'm not a carrier employee but I cannot
>>>> >>>> envision
>>>> a
>>>> >>>> carrier offering potentially 1000s of distinct service bundles
>>>> >> ("pick
>>>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>>>> smaller
>>>> >>>> number is realistic for  the number of chains a function
>>>> >>>> instance
>>>> is
>>>> >>>> expected to participate in, even allowing for dynamic
>>>> >>>> reclassification of flows at a chain ingress to "skip a few
>>>> >>>> functions".... These are things that are fully operationalized
>>>> >>>> in OSS, have policy associated with, have been industrialized
>>>> >>>> and demonstrated to work prior to deployment. Going all
>>>> >>>> combinatorial
>>>> on
>>>> >> this will break that big time....
>>>> >>>>
>>>> >>>> So are we really discussing a function participating in more
>>>> >>>> than
>>>> a
>>>> >>>> handful of chain instances? And either a plurality of vNICs or
>>>> VIDs
>>>> >>>> being actually more than sufficient?
>>>> >>>>
>>>> >>>> Thanks
>>>> >>>>
>>>> >>>> Dave
>>>> >>>>
>>>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>>>> >>>> (Wim)
>>>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
>>>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>> >>>>
>>>> >>>> indeed
>>>> >>>>
>>>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>>> >>>> *Date: *Wednesday 24 July 2013 15:54
>>>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>>>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>>> >>>> *Subject: *AW: Service chaining architecture question
>>>> >>>>
>>>> >>>> Hi Wim,
>>>> >>>>
>>>> >>>> I think not only effectivness/scalability might be a problem
>>>> >>>> but
>>>> >> also
>>>> >>>> the fact that not all applications (service bringing functions)
>>>> are
>>>> >>>> able to handle packets coming from/going to potentially
>>>> >>>> thousands
>>>> of
>>>> >>>> different VLANs at the same time. VLANs will work in certain
>>>> >>>> environments but not in all. I see the need for an information
>>>> >>>> exchange between the application and a mediation layer as well.
>>>> >>>> Ideally this should be as simple as possible without heavy
>>>> >>>> impact
>>>> on
>>>> >>>> the application itself (might be difficult to achieve but from
>>>> >>>> my experience it is not very likely, that there will be big
>>>> >>>> rewrites
>>>> of
>>>> >>>> existing applications in order to support the chaining).
>>>> >>>>
>>>> >>>>    regards
>>>> >>>>
>>>> >>>>       Nic
>>>> >>>>
>>>> >>>> ---------------------------------------------------------------
>>>> >>>> -
>>>> >>>> --
>>>> --
>>>> >> -
>>>> >>>> -
>>>> >>>> --
>>>> >>>>
>>>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>>>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>>>> (Wim)
>>>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>>> >>>> *Betreff:* [nsc] Service chaining architecture question
>>>> >>>>
>>>> >>>> I have a basic question with respect to the
>>>> >>>> architecture/framework
>>>> >> so
>>>> >>>> far mentioned in the drafts in NSC. I understand the meta-data
>>>> >>>> is
>>>> a
>>>> >>>> mechanism to avoid multiple re-classifications when the packet
>>>> >> enters
>>>> >>>> the NSC domain and identifies the chain of service functions.
>>>> >>>> Now
>>>> my
>>>> >>>> understanding is that the services/applications are unaware of
>>>> >>>> the meta-data and that a layer underneath should provide the
>>>> >>>> mediation and that we use a well defined interface to the
>>>> application/service
>>>> >>>> to indicate the chain. In the context of Cloud/enterprise
>>>> >> environment
>>>> >>>> I can see this work given you can use a dedicate VLAN e.g.
>>>> >>>> within
>>>> >> the tenant.
>>>> >>>> However we also try to address residential use cases for mobile
>>>> and
>>>> >>>> fixed and here this becomes more tricky afais. In the
>>>> >>>> residential environment we can't expose a VLAN per
>>>> >>>> application/service per
>>>> chain
>>>> >>>> since this would not be very effective. So I am wondering how
>>>> >>>> we envision this to work?
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> nsc mailing list
>>>> >>>> nsc@ietf.org
>>>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>>>> >>> _______________________________________________
>>>> >>> nsc mailing list
>>>> >>> nsc@ietf.org
>>>> >>>https://www.ietf.org/mailman/listinfo/nsc
>>>> >> _______________________________________________
>>>> >> nsc mailing list
>>>> >> nsc@ietf.org
>>>> >>https://www.ietf.org/mailman/listinfo/nsc
>>>> >
>>>
>>>
>>> _______________________________________________
>>> nsc mailing list
>>> nsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nsc
>>>
>>_______________________________________________
>>nsc mailing list
>>nsc@ietf.org
>>https://www.ietf.org/mailman/listinfo/nsc
>>_______________________________________________
>>nsc mailing list
>>nsc@ietf.org
>>https://www.ietf.org/mailman/listinfo/nsc
>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From mohamed.boucadair@orange.com  Fri Jul 26 06:05:43 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E4A21F992E for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 06:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfJlwWQByZYU for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 06:05:39 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1621F9928 for <nsc@ietf.org>; Fri, 26 Jul 2013 06:05:36 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id AB2262DCDE3; Fri, 26 Jul 2013 15:05:35 +0200 (CEST)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8A2E94C05D; Fri, 26 Jul 2013 15:05:35 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 26 Jul 2013 15:05:35 +0200
From: <mohamed.boucadair@orange.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "Paul Quinn (paulq)" <paulq@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>
Date: Fri, 26 Jul 2013 15:05:34 +0200
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A///xbrA=
Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com>
In-Reply-To: <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.26.110332
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 13:05:44 -0000

Re-,

I guess you are talking about unknown IP options in general. If a new optio=
n is to be defined for what we are discussing here, these firewalls will ne=
ed to be updated. This is not a problem at all.

Unlike the proposals for which the new IP option is to be carried over inte=
rnet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2), the chaining=
 case is restricted to a network segment managed by the same administrative=
 entity.

I'm not trying to advocate for the use an IP option but the point is it is =
early to decide which channel is viable or not.

Cheers,
Med

>-----Message d'origine-----
>De=A0: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>Envoy=E9=A0: vendredi 26 juillet 2013 14:49
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, MARIA H
>Cc=A0: nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>Objet=A0: Re: [nsc] Service chaining architecture question
>
>Hi Med,
>
>On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
><mohamed.boucadair@orange.com> wrote:
>
>>>
>>>Adding data to existing IP headers might not prove viable, most fields
>>>are
>>>either spoken for, or have significant technical limitations.  For
>>>example,
>>>IP options are usually filtered/dropped
>>
>>[Med] This is not a valid argument for the chaining case. This limitation
>>would be a no starting point if the chaining procedure is to be activated
>>at the level of Internet...which is not the case here. The solution will
>>be enabled in a controlled environment, and as such, introducing a new IP
>>option, IPv6 extension header, should be part of the viable solutions. It
>>is too early at this stage to exclude any candidate channel to convey the
>>marking bits.
>
>Jim> even in a controlled environment by using IP options you may prevent
>cross-domain chaining and at the very least prevent firewalls being part
>of the chain; every firewall I know about will drop packets containing IP
>options.
>
>>


From cpignata@cisco.com  Fri Jul 26 06:29:24 2013
Return-Path: <cpignata@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2648921F967F for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 06:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL3H9iFsWGeU for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 06:29:19 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4035F21F9546 for <nsc@ietf.org>; Fri, 26 Jul 2013 06:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3682; q=dns/txt; s=iport; t=1374845359; x=1376054959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ES6B3A3cIG5W+xwkKCeCiSB9/fFTtQWLibtn/6Pq0rM=; b=U6eSwElmx3DlBgLi/Kha+pG0o87GS4P2OboSwyMYt97uP0GW7wxEzhUD aQ89Eei2mO6CeTHft5dethSBHRdFbzZr7FRa+23/LIbTft3IdZb/zdwvC noEpZVHDaQmu8WfrU68g7C0GOhkIua5VokJzw5YUfWETdq3c2DfEIsbPa A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAOt48lGtJXG//2dsb2JhbABagwY1UL1DgRgWdIIkAQEBAwEBAQFkBwYFBQsCAQgSBgodBycLFAMOAgQOBQgBEodvBgy5HI5JBXwCMQIFgxZvA4hykBaJCYcagxSBaQgXIg
X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208";a="239853822"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2013 13:29:17 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6QDTGbE023460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 13:29:16 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 08:29:16 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "<mohamed.boucadair@orange.com> " <mohamed.boucadair@orange.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A///xbrAAC5+oAA==
Date: Fri, 26 Jul 2013 13:29:15 +0000
Message-ID: <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.115.56]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7FB3A6928C635E4991BB8AB54D44A339@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 13:29:24 -0000

Hi, Med,

I absolutely agree with your point of not deciding early and not jumping to=
 solutions early.

However, without trying to drive an early decision, I think that it's fair =
to say that the shortcomings of IP options are more pervasive than just con=
strained to unknown options in the Internet.

I remember an experiment that Dan Wing started http://www.ietf.org/mail-arc=
hive/web/int-area/current/msg02360.html in which using known options in the=
 Internet had basically the same effect. In fact, we used something like ju=
st a NOOP end EOO only, and just having known options triggered drops. Narr=
owing the use-case, options seem to severely limit the ability to perform c=
ross-domain service chains. This is in a way a consequence of tying the met=
adata to the IP layer, instead of providing a way that is independent from =
it (and works equally in IPv4, IPv6, MPLS). Even within a controlled domain=
, there is performance in addition to just connectivity issues; there are a=
lso limitations in terms of processing (slow path) of optioned packets, pot=
ential inability to be deterministic with ECMP, and like Jim said firewalls=
. If for example dataplane performance, load-balancing and cross-domain cha=
ins are requirements, certainly these need to be considered.

Thanks,

-- Carlos.

On Jul 26, 2013, at 9:05 AM, <mohamed.boucadair@orange.com>
 wrote:

> Re-,
>=20
> I guess you are talking about unknown IP options in general. If a new opt=
ion is to be defined for what we are discussing here, these firewalls will =
need to be updated. This is not a problem at all.
>=20
> Unlike the proposals for which the new IP option is to be carried over in=
ternet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2), the chaini=
ng case is restricted to a network segment managed by the same administrati=
ve entity.
>=20
> I'm not trying to advocate for the use an IP option but the point is it i=
s early to decide which channel is viable or not.
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> Envoy=E9 : vendredi 26 juillet 2013 14:49
>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, MARIA H
>> Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>> Objet : Re: [nsc] Service chaining architecture question
>>=20
>> Hi Med,
>>=20
>> On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>> <mohamed.boucadair@orange.com> wrote:
>>=20
>>>>=20
>>>> Adding data to existing IP headers might not prove viable, most fields
>>>> are
>>>> either spoken for, or have significant technical limitations.  For
>>>> example,
>>>> IP options are usually filtered/dropped
>>>=20
>>> [Med] This is not a valid argument for the chaining case. This limitati=
on
>>> would be a no starting point if the chaining procedure is to be activat=
ed
>>> at the level of Internet...which is not the case here. The solution wil=
l
>>> be enabled in a controlled environment, and as such, introducing a new =
IP
>>> option, IPv6 extension header, should be part of the viable solutions. =
It
>>> is too early at this stage to exclude any candidate channel to convey t=
he
>>> marking bits.
>>=20
>> Jim> even in a controlled environment by using IP options you may preven=
t
>> cross-domain chaining and at the very least prevent firewalls being part
>> of the chain; every firewall I know about will drop packets containing I=
P
>> options.
>>=20
>>>=20
>=20
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc


From mohamed.boucadair@orange.com  Fri Jul 26 06:50:49 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2149121F9684 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 06:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ndqh-7P95eT for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 06:50:45 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B8EE321F967C for <nsc@ietf.org>; Fri, 26 Jul 2013 06:50:44 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3195B265092; Fri, 26 Jul 2013 15:50:43 +0200 (CEST)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 078B235C048; Fri, 26 Jul 2013 15:50:43 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 26 Jul 2013 15:50:43 +0200
From: <mohamed.boucadair@orange.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Date: Fri, 26 Jul 2013 15:50:41 +0200
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A///xbrAAC5+oAAAKRlFQ
Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com>
In-Reply-To: <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.26.63617
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 13:50:49 -0000

Dear Carlos,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De=A0: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
>Envoy=E9=A0: vendredi 26 juillet 2013 15:29
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Jim Guichard (jguichar); Paul Quinn (paulq); NAPIERALA, MARIA H;
>nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>Objet=A0: Re: [nsc] Service chaining architecture question
>
>Hi, Med,
>
>I absolutely agree with your point of not deciding early and not jumping t=
o
>solutions early.
>
>However, without trying to drive an early decision, I think that it's fair
>to say that the shortcomings of IP options are more pervasive than just
>constrained to unknown options in the Internet.

[Med] The experiments I'm aware span multiple domain and are not restricted=
 to a managed network.

>
>I remember an experiment that Dan Wing started http://www.ietf.org/mail-
>archive/web/int-area/current/msg02360.html

[Med] I'm aware of Dan's work in this space and also of many other experime=
nt results in this space. Actually, we used some of that work when writing =
RFC6967.

 in which using known options in
>the Internet had basically the same effect.

[Med] You said the magic word "Internet". This is not the scope of the work=
 we are discussing here.=20


 In fact, we used something like
>just a NOOP end EOO only, and just having known options triggered drops.

[Med] Isn't this caused by the option not being explicitly configured to pa=
ss in?

>Narrowing the use-case, options seem to severely limit the ability to
>perform cross-domain service chains.

[Med] Do you mean inter-domain? For whom this is a requirement? What is the=
 use case for that? At least for our side, we don't see inter-domain as a r=
equirement for this work.


 This is in a way a consequence of
>tying the metadata to the IP layer, instead of providing a way that is
>independent from it (and works equally in IPv4, IPv6, MPLS). Even within a
>controlled domain, there is performance in addition to just connectivity
>issues; there are also limitations in terms of processing (slow path) of
>optioned packets, potential inability to be deterministic with ECMP, and
>like Jim said firewalls. If for example dataplane performance, load-
>balancing and cross-domain chains are requirements, certainly these need t=
o
>be considered.
>
>Thanks,
>
>-- Carlos.
>
>On Jul 26, 2013, at 9:05 AM, <mohamed.boucadair@orange.com>
> wrote:
>
>> Re-,
>>
>> I guess you are talking about unknown IP options in general. If a new
>option is to be defined for what we are discussing here, these firewalls
>will need to be updated. This is not a problem at all.
>>
>> Unlike the proposals for which the new IP option is to be carried over
>internet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2), the
>chaining case is restricted to a network segment managed by the same
>administrative entity.
>>
>> I'm not trying to advocate for the use an IP option but the point is it
>is early to decide which channel is viable or not.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>> Envoy=E9 : vendredi 26 juillet 2013 14:49
>>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, MARIA =
H
>>> Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>>> Objet : Re: [nsc] Service chaining architecture question
>>>
>>> Hi Med,
>>>
>>> On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>>> <mohamed.boucadair@orange.com> wrote:
>>>
>>>>>
>>>>> Adding data to existing IP headers might not prove viable, most field=
s
>>>>> are
>>>>> either spoken for, or have significant technical limitations.  For
>>>>> example,
>>>>> IP options are usually filtered/dropped
>>>>
>>>> [Med] This is not a valid argument for the chaining case. This
>limitation
>>>> would be a no starting point if the chaining procedure is to be
>activated
>>>> at the level of Internet...which is not the case here. The solution
>will
>>>> be enabled in a controlled environment, and as such, introducing a new
>IP
>>>> option, IPv6 extension header, should be part of the viable solutions.
>It
>>>> is too early at this stage to exclude any candidate channel to convey
>the
>>>> marking bits.
>>>
>>> Jim> even in a controlled environment by using IP options you may
>prevent
>>> cross-domain chaining and at the very least prevent firewalls being par=
t
>>> of the chain; every firewall I know about will drop packets containing
>IP
>>> options.
>>>
>>>>
>>
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc


From diego@tid.es  Fri Jul 26 07:01:46 2013
Return-Path: <diego@tid.es>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831B21F9991 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 07:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.392
X-Spam-Level: 
X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3aR7pgWyIhr for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 07:01:42 -0700 (PDT)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A49621F9984 for <nsc@ietf.org>; Fri, 26 Jul 2013 07:01:41 -0700 (PDT)
Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MQJ00ISAQYRD9@tid.hi.inet> for nsc@ietf.org; Fri, 26 Jul 2013 16:01:40 +0200 (MEST)
Received: from tid (tid.hi.inet [10.95.64.10])	by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 94.85.03142.34182F15; Fri, 26 Jul 2013 16:01:39 +0200 (CEST)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MQJ00IRVQYRD9@tid.hi.inet> for nsc@ietf.org; Fri, 26 Jul 2013 16:01:39 +0200 (MEST)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.83]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 16:00:08 +0200
Date: Fri, 26 Jul 2013 14:00:08 +0000
From: "Diego R. Lopez" <diego@tid.es>
In-reply-to: <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr>
X-Originating-IP: [10.95.64.115]
To: "<mohamed.boucadair@orange.com> " <mohamed.boucadair@orange.com>
Message-id: <E6D8B95470ED0845B3376F61DCAB1A049D201A1B@EX10-MB2-MAD.hi.inet>
Content-id: <2EF41A10FFB97042B1AE87E8F42C4831@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-language: en-US
Content-transfer-encoding: quoted-printable
Accept-Language: en-US, es-ES
Thread-topic: [nsc] Service chaining architecture question
Thread-index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYP//56KAgAALhACAABT2gIAABDyAgAAA/ACAAAlhAIAABS0AgAAE8YCAAAFZAIAAA3AAgAEXJwCAAUWNgIAAD++AgAAEvACAAAaegIAABf2AgAADEYA=
X-AuditID: 0a5f4068-b7f128e000000c46-14-51f281435dbb
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42Lhinfg0nVp/BRoYG1xfN9+NgdGjyVLfjIF MEZx2aSk5mSWpRbp2yVwZXyYO5+14ANXxcrvXYwNjO85uhg5OSQETCTOPbjNCGGLSVy4t56t i5GLQ0hgI6PEo2UNLBDON0aJ9/t+MkE40xglHty5xwTSwiKgKtF2dDE7iM0GZD9q/g1mCwtY Sty41M0GYnMKxEn83bKdGWKFgsSfc4+BpnJwiAi4SBzZFAsyk1ngLpPErKOdLCA1vALeEl/O LgKbwyxgJnGs8TgTRFxQ4sfkeywQcR2J3u/fmCFscYnm1ptQcW2JJ+8usILYjAKyEu/mzwez RQSsJM68vsoOskxEYAujxMPu9VA/C0gs2XMe6jhRiZeP/7FCfNnOLNE38THLBEaJWUgOmYXk kFlIDpmF5JBZSA5ZwMi6ilGsOKkoMz2jJDcxMyfdwFAvI1MvMy+1ZBMjJPIydjAu36lyiFGA g1GJh1fB6WOgEGtiWXFl7iFGCQ5mJRHe696fAoV4UxIrq1KL8uOLSnNSiw8xMnFwSjUwuvTG FdS+EpUUjS4PNii2zf5qwp/fZH4q9O+ro888+3QfLVl+hCPwakVfaa3F2W9pvIEV105fvVfy kOFOzp64j43bLVgM/6zawsvReP3PrdtnfiRtmXZ2ytWSCdsbm744RKTbGkT7C93KM9yrX6/I 66wZo/96Vntpi0jRd2n119JmgSfXxmcqsRRnJBpqMRcVJwIAzb0ddZoCAAA=
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr>
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Carlos Pignataro \(cpignata\)" <cpignata@cisco.com>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 14:01:46 -0000

Hi,

Just a quick reflection while I try to recover from the enormous backlog ca=
used by the NFV meeting

On 26 Jul 2013, at 15:50 , <mohamed.boucadair@orange.com> wrote:
>
>> Narrowing the use-case, options seem to severely limit the ability to
>> perform cross-domain service chains.
>
> [Med] Do you mean inter-domain? For whom this is a requirement? What is t=
he use case for that? At least for our side, we don't see inter-domain as a=
 requirement for this work.

Precisely in NFV we are considering the possibility of such arrangements, w=
here you could use NS-as-a-Service. With an appropriate "NSC/NLF/... contro=
l plane" we could support several labeling mechanisms, adapted intra- and i=
nter-domain scenarios.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

From cpignata@cisco.com  Fri Jul 26 07:10:57 2013
Return-Path: <cpignata@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13A711E80EA for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 07:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98w2f056joOc for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 07:10:51 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9637211E80E9 for <nsc@ietf.org>; Fri, 26 Jul 2013 07:10:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5755; q=dns/txt; s=iport; t=1374847851; x=1376057451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x6rm/LlTq4RfemXNTf4litljL/vn7GfYmq8Xd1A3KPg=; b=kM0ouB7WITn9XLOnrnmmlezWMFTMFGaAwO79Y8IlN1WzJq5eOikvxlJY H/OIxJ8xV1DWbR2M9qICbNmx/0myAqObpMuDx7yaqMieTCPF1UZhxW8xC XeLg1+PYtCgPeMCWWJ/rx2hFAqUCc4QW2D1yPQ0bv1wkpj0sU8zIB9g9u M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFABqC8lGtJV2c/2dsb2JhbABbgwY1Sga9Q4EXFnSCJAEBAQMBAQEBZAcGBQULAgEIEgYKHQcnCxQDDgIEDgUIARKHbwYHBbkKjkgBBXwCMQeDFm8DiHKQFokJgXeFI4MUgWgBCBci
X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208";a="239870030"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2013 14:10:50 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6QEAn1b010577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 14:10:50 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 09:10:49 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "<mohamed.boucadair@orange.com> " <mohamed.boucadair@orange.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A///xbrAAC5+oAAAKRlFQ//+5a4A=
Date: Fri, 26 Jul 2013 14:10:49 +0000
Message-ID: <95067C434CE250468B77282634C96ED322D564B9@xmb-aln-x02.cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.115.56]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C11E442AAC8CC048A5BF64FFE323F7C7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 14:10:57 -0000

Hello, Med,

Thanks for the follow-up -- please see inline.

On Jul 26, 2013, at 9:50 AM, <mohamed.boucadair@orange.com>
 wrote:

> Dear Carlos,
>=20
> Please see inline.
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
>> Envoy=E9 : vendredi 26 juillet 2013 15:29
>> =C0 : BOUCADAIR Mohamed OLNC/OLN
>> Cc : Jim Guichard (jguichar); Paul Quinn (paulq); NAPIERALA, MARIA H;
>> nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>> Objet : Re: [nsc] Service chaining architecture question
>>=20
>> Hi, Med,
>>=20
>> I absolutely agree with your point of not deciding early and not jumping=
 to
>> solutions early.
>>=20
>> However, without trying to drive an early decision, I think that it's fa=
ir
>> to say that the shortcomings of IP options are more pervasive than just
>> constrained to unknown options in the Internet.
>=20
> [Med] The experiments I'm aware span multiple domain and are not restrict=
ed to a managed network.
>=20
>>=20
>> I remember an experiment that Dan Wing started http://www.ietf.org/mail-
>> archive/web/int-area/current/msg02360.html
>=20
> [Med] I'm aware of Dan's work in this space and also of many other experi=
ment results in this space. Actually, we used some of that work when writin=
g RFC6967.
>=20
> in which using known options in
>> the Internet had basically the same effect.
>=20
> [Med] You said the magic word "Internet". This is not the scope of the wo=
rk we are discussing here.=20
>=20
>=20

Yes, the first part of my response was only to add that both unknown (as yo=
u said) as well as known options have issues in the broad Internet. Comment=
s on narrowscoped use cases were included below.

> In fact, we used something like
>> just a NOOP end EOO only, and just having known options triggered drops.
>=20
> [Med] Isn't this caused by the option not being explicitly configured to =
pass in?
>=20
>> Narrowing the use-case, options seem to severely limit the ability to
>> perform cross-domain service chains.
>=20
> [Med] Do you mean inter-domain? For whom this is a requirement? What is t=
he use case for that? At least for our side, we don't see inter-domain as a=
 requirement for this work.
>=20

Yes, but only by way of example -- basically any use case that is not limit=
ed to IP only single management domain only.

That said, the main point is what follows:

>=20
> This is in a way a consequence of
>> tying the metadata to the IP layer, instead of providing a way that is
>> independent from it (and works equally in IPv4, IPv6, MPLS). Even within=
 a
>> controlled domain, there is performance in addition to just connectivity
>> issues; there are also limitations in terms of processing (slow path) of
>> optioned packets, potential inability to be deterministic with ECMP, and
>> like Jim said firewalls. If for example dataplane performance, load-
>> balancing and cross-domain chains are requirements, certainly these need=
 to
>> be considered.
>>=20

Additionally, draft-ietf-opsec-ip-options-filtering might be of some intere=
st, in particular the Intro.

Thanks,

-- Carlos.

>> Thanks,
>>=20
>> -- Carlos.
>>=20
>> On Jul 26, 2013, at 9:05 AM, <mohamed.boucadair@orange.com>
>> wrote:
>>=20
>>> Re-,
>>>=20
>>> I guess you are talking about unknown IP options in general. If a new
>> option is to be defined for what we are discussing here, these firewalls
>> will need to be updated. This is not a problem at all.
>>>=20
>>> Unlike the proposals for which the new IP option is to be carried over
>> internet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2), the
>> chaining case is restricted to a network segment managed by the same
>> administrative entity.
>>>=20
>>> I'm not trying to advocate for the use an IP option but the point is it
>> is early to decide which channel is viable or not.
>>>=20
>>> Cheers,
>>> Med
>>>=20
>>>> -----Message d'origine-----
>>>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>>> Envoy=E9 : vendredi 26 juillet 2013 14:49
>>>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, MARIA=
 H
>>>> Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>>>> Objet : Re: [nsc] Service chaining architecture question
>>>>=20
>>>> Hi Med,
>>>>=20
>>>> On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>>>> <mohamed.boucadair@orange.com> wrote:
>>>>=20
>>>>>>=20
>>>>>> Adding data to existing IP headers might not prove viable, most fiel=
ds
>>>>>> are
>>>>>> either spoken for, or have significant technical limitations.  For
>>>>>> example,
>>>>>> IP options are usually filtered/dropped
>>>>>=20
>>>>> [Med] This is not a valid argument for the chaining case. This
>> limitation
>>>>> would be a no starting point if the chaining procedure is to be
>> activated
>>>>> at the level of Internet...which is not the case here. The solution
>> will
>>>>> be enabled in a controlled environment, and as such, introducing a ne=
w
>> IP
>>>>> option, IPv6 extension header, should be part of the viable solutions=
.
>> It
>>>>> is too early at this stage to exclude any candidate channel to convey
>> the
>>>>> marking bits.
>>>>=20
>>>> Jim> even in a controlled environment by using IP options you may
>> prevent
>>>> cross-domain chaining and at the very least prevent firewalls being pa=
rt
>>>> of the chain; every firewall I know about will drop packets containing
>> IP
>>>> options.
>>>>=20
>>>>>=20
>>>=20
>>> _______________________________________________
>>> nsc mailing list
>>> nsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nsc
>=20


From mn1921@att.com  Fri Jul 26 08:16:37 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E494021F999A for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 08:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8gsQ34Deojb for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 08:16:31 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E09F521F99A1 for <nsc@ietf.org>; Fri, 26 Jul 2013 08:16:30 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id ec292f15.5248d940.3730060.00-573.10219568.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 15:16:30 +0000 (UTC)
X-MXL-Hash: 51f292ce74678460-5785f4989b4e00c8bbcb00aa6734bf8680e535f9
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ab292f15.0.3729879.00-182.10219031.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 15:16:11 +0000 (UTC)
X-MXL-Hash: 51f292bb3242ef0a-256270ffaf0a7823a3b5a955c133db60908989a1
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QFG9V6009707; Fri, 26 Jul 2013 11:16:10 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QFFx2q009579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 11:16:00 -0400
Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 26 Jul 2013 15:15:52 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Fri, 26 Jul 2013 11:15:52 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeAgAALhACAABT2gIAABD2AgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAP//vmwQgAFcKwCAAUWNgIAAD++AgAAEvAD//98Y4A==
Date: Fri, 26 Jul 2013 15:15:51 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01208E09@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.91.76.193]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=WbS7nTdX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=-s3I2kwCOWQA:10 a=2DTnKp0c6ewA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=QNNNeoGkA4wA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=z9tbli-vAAAA:8 a=uB_ciAHzLmC83Y3bpnwA:9 a=wPNLvfGTeEIA:]
X-AnalysisOut: [10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10]
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 15:16:38 -0000

> Re-,
>=20
> I guess you are talking about unknown IP options in general. If a new
> option is to be defined for what we are discussing here, these
> firewalls will need to be updated. This is not a problem at all.
>=20
Absolutely agree.
Whichever way metadata will be carried will require some changes on the app=
liance (especially, when adding NSH in front of IP packet).
The point is to do it in the least disruptive way, i.e., without modifying =
the entire IP stack in the appliance. IP option is a realistic proposal. Th=
e "service chain" infrastructure doesn't need to change in order to accompl=
ish this goal.


Maria

>=20
> Cheers,
> Med
>=20
> >-----Message d'origine-----
> >De=A0: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >Envoy=E9=A0: vendredi 26 juillet 2013 14:49
> >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, MARIA=
 H
> >Cc=A0: nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
> >Objet=A0: Re: [nsc] Service chaining architecture question
> >
> >Hi Med,
> >
> >On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
> ><mohamed.boucadair@orange.com> wrote:
> >
> >>>
> >>>Adding data to existing IP headers might not prove viable, most
> fields
> >>>are
> >>>either spoken for, or have significant technical limitations.  For
> >>>example,
> >>>IP options are usually filtered/dropped
> >>
> >>[Med] This is not a valid argument for the chaining case. This
> limitation
> >>would be a no starting point if the chaining procedure is to be
> activated
> >>at the level of Internet...which is not the case here. The solution
> will
> >>be enabled in a controlled environment, and as such, introducing a
> new IP
> >>option, IPv6 extension header, should be part of the viable
> solutions. It
> >>is too early at this stage to exclude any candidate channel to convey
> the
> >>marking bits.
> >
> >Jim> even in a controlled environment by using IP options you may
> prevent
> >cross-domain chaining and at the very least prevent firewalls being
> part
> >of the chain; every firewall I know about will drop packets containing
> IP
> >options.
> >
> >>


From mn1921@att.com  Fri Jul 26 08:30:03 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7632E21F918C for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 08:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ptuO4IfxVYt for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 08:29:57 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 20CBC21F99F2 for <nsc@ietf.org>; Fri, 26 Jul 2013 08:29:56 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 5f592f15.2aaad380b940.3738774.00-573.10244467.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 15:29:57 +0000 (UTC)
X-MXL-Hash: 51f295f532b24334-34dcda130a1a36ee0f06828de411423d1f80ccff
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ee592f15.0.3738764.00-134.10244283.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 15:29:51 +0000 (UTC)
X-MXL-Hash: 51f295ef003fb3e4-6961c595dc5b7fb24e6cc48fd901d4ce44f50ac2
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QFTo8j025040; Fri, 26 Jul 2013 11:29:50 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QFTkX1024939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 11:29:46 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 26 Jul 2013 15:29:34 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Fri, 26 Jul 2013 11:29:34 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: David Allan I <david.i.allan@ericsson.com>, "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeAgAALhACAABT2gIAABD2AgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAIAAEtIAgAAMH4CAASOXgIAAEtQA///R/PCAAEbzgIAA6avA
Date: Fri, 26 Jul 2013 15:29:33 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01208E91@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <E6C17D2345AC7A45B7D054D407AA205C115D697E@eusaamb105.ericsson.se> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF3964@xmb-aln-x09.cisco.com> <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01208861@MISOUT7MSGUSR9I.ITServices.sbc.com> <E6C17D2345AC7A45B7D054D407AA205C115D6F2C@eusaamb105.ericsson.se>
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C115D6F2C@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.91.76.193]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=WbS7nTdX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=-s3I2kwCOWQA:10 a=2DTnKp0c6ewA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=QNNNeoGkA4wA:10 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=ABeY7kuGAAAA:8 a=AUd_NHdVAAAA:8 a=qN95wPeSAAAA:8 a=gxZv]
X-AnalysisOut: [rgisAAAA:8 a=tKx2hKk9YD_vy8rYEtkA:9 a=CjuIK1q_8ugA:10 a=f7]
X-AnalysisOut: [GxY0FH8QIA:10 a=lZB815dzVvQA:10 a=chC_agHSu74A:10 a=JfD0Fc]
X-AnalysisOut: [h1gWkA:10 a=paC5pjApGzsA:10 a=p3EP0m9KMXkA:10 a=Asw5JLZBwx]
X-AnalysisOut: [XThml3:21 a=u5qoozYfSuzLBwnK:21]
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 15:30:03 -0000

Dave,

There might be cases (e.g., when offering IP services to mobile subscribers=
) where the metadata (e.g., subscriber-id, application-id) could be of valu=
e. Some services might operate on subscriber-id information (e.g., MSISDN i=
n mobility). Or, after a DPI, a downstream service might need to know the a=
pp-id.=20

Maria

> -----Original Message-----
> From: David Allan I [mailto:david.i.allan@ericsson.com]
> Sent: Thursday, July 25, 2013 5:26 PM
> To: NAPIERALA, MARIA H; Surendra Kumar (smkumar); Ron Parker; Joel M.
> Halpern; Linda Dunbar
> Cc: nsc@ietf.org; Jim Guichard (jguichar)
> Subject: RE: [nsc] Service chaining architecture question
>=20
> So it is going to pass other stuff instead.... ????
>=20
> Isn't this pretty much the same, make the VF "frame transparent" and
> you're DONE....  just need to write a BCP!
>=20
> cheers
> Dave
>=20
> -----Original Message-----
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of
> NAPIERALA, MARIA H
> Sent: Thursday, July 25, 2013 2:17 PM
> To: David Allan I; Surendra Kumar (smkumar); Ron Parker; Joel M.
> Halpern; Linda Dunbar
> Cc: nsc@ietf.org; Jim Guichard (jguichar)
> Subject: Re: [nsc] Service chaining architecture question
>=20
> >
> > Ultimately the notion of subscriber will be uniquely inferable from
> > information embedded in the customer frame when it arrives at the
> > ingress to a chain, and that is without any protocol changes, else
> the
> > network would already be broken!  So I'm not sure how that can be
> > improved upon...translating what is in the frame to yet another
> > identifier would not really have a lot of utility and would add IMO
> > gratuitous complexity
>=20
> Right!  Now, the services may want to know what is the subscriber id or
> application id. This is where the metadata comes in.
> We should handle metadata in such a way that it does not require the
> entire IP stack on the appliance to be modified to pass this extra
> data.
>=20
> Maria
> > -----Original Message-----
> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of
> > Surendra Kumar (smkumar)
> > Sent: Thursday, July 25, 2013 11:49 AM
> > To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
> > Cc: nsc@ietf.org; Jim Guichard (jguichar)
> > Subject: Re: [nsc] Service chaining architecture question
> >
> >
> >
> > On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com>
> wrote:
> >
> > >I would prefer to think what is on the wire facilitates the
> > >forwarding of frames, e.g. chain ID (analogous to VPN), perhaps an
> > >entropy shorthand to help both LB and  testabilty....and facilitates
> > >uniquely identifying the subscriber. (within the bounds of the art
> of
> > >the possible, see my last post on NAT). I cannot envision a need for
> more.
> > >And ideally I should be able to align such an approach with existing
> > Cloud technologies.
> > SK> For entropy you are better off choosing the right transport and
> > relying on that than the chain-id.
> > >
> > >The individual VF should be able to determine actual subscriber to a
> > >granularity suitable for it's purposes and obtain the necessary
> > profile
> > >information via a northbound interface. If you then read between the
> > >lines,  I'm all for separation of concerns as much as possible ;-)
> > >and not creating dependencies across chain components beyond the
> > networking
> > >level.
> > SK> Agree but I would add that subscriber identification may require
> > policy-plane interaction and if it is done once in the chain, the
> rest
> > of the chain can benefit from it.
> >
> > Surendra.
> > >
> > >I also do not see a huge difference between a service chain, and any
> > >other flow of information across a string of processing elements.
> > >Just in one application, the packet is preserved with perhaps a bit
> > >of fondling, and in others the content may be completely
> > >deconstructed, and repackaged into a set of transactions....and what
> > >is on the wire between chain components does not remotely look like
> > >what went in the
> > front end...
> > >
> > >Cheers
> > >Dave
> > >
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf
> Of
> > >Ron Parker
> > >Sent: Wednesday, July 24, 2013 5:42 PM
> > >To: Joel M. Halpern; Linda Dunbar
> > >Cc: nsc@ietf.org; Jim Guichard (jguichar)
> > >Subject: Re: [nsc] Service chaining architecture question
> > >
> > >Thanks, all, for a lively discussion on this topic.
> > >
> > >One thing that flavors the discussion of network service chaining is
> > the
> > >definition of "service".   It really means different things to
> > different
> > >people.   We networking types tend to look at it as a software
> > >application or software system composed of multiple software
> > applications
> > >(i.e., an HTTP content filter).   But when I interact with the
> > business
> > >folks, especially on the operator side, I hear a different notion of
> > >"service" -- something subscribers pay for, government mandates,
> etc.
> > >This is why, IMO, it is defensible to say that the
> > >HTTP-content-filter-children is a distinct service from
> > >HTTP-content-filter-adult, even if both are realized on the same
> > server
> > >by the same software application using the same global URL database.
> > >
> > >It does sound like at least some that have chimed in do feel that
> > >both the general service type (i.e., HTTP content filter) and the
> > >policy
> > set
> > >need to be conveyed in some manner.    How to do this is a set of
> > >tradeoffs around control plane protocol and data plane
> encapsulation.
> > >Without any control plane, both types of information need to be on
> the
> > >wire in some form.   I will assume that the policy set identity is
> > >distinct at each service instance (i.e, policy set 2 at the HTTP
> > >content filter does not imply the same set of subscribers as policy
> > set 2 at the
> > >firewall).   I will also assume that the meaning and interpretation
> of
> > a
> > >policy set identity is specific to that type of service and probably
> > to
> > >the vendor that supplied the service.   This is similar to when a
> PCRF
> > >names a PCC rulebase rather than supplying the full set of explicit
> > PCC
> > >rules.
> > >
> > >The advantage of a single chain ID that can be interpreted as a
> > >sequence of {service-type-instance, policy-set} is that it minimizes
> > >the per-packet encapsulation requirement (i.e., a single GRE key
> could
> > >suffice).   The disadvantage that has been pointed out is that
> global
> > >coordination of this identity is required and the number of
> > >combinations could become unwieldy.
> > >
> > >Another approach could be to have a new encapsulation that
> represents
> > a
> > >stack of 2-tuples {service-ip-address, service-specific-policy-id},
> > >or even 3-tuples {service-ip-address, service-type,
> > >service-specific-policy-id} where the 3-tuple brings the added
> > >advantage of allowing for multiple dissimilar services realized by
> > >the
> > same server
> > >at the same server ip address.   The advantage of this approach is
> > that
> > >it avoids the combinatorial explosion problem, but it requires a
> > larger
> > >and variable length encapsulation.
> > >
> > >If the global chain id approach is used, a control plane protocol
> > could
> > >be used to distribute the definitions of each chain (i.e, each chain
> > is
> > >really a stack of 2-tuples or 3-tuples, per description above).
> > >
> > >Thanks.
> > >
> > >    Ron
> > >
> > >-----Original Message-----
> > >From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > >Sent: Wednesday, July 24, 2013 7:35 PM
> > >To: Linda Dunbar
> > >Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
> > >Subject: Re: [nsc] Service chaining architecture question
> > >
> > >I would not be surprised if we want all three of Service Chain,
> > Service
> > >Policy, and Subscriber / user identity in the packet.
> > >If the Chain is in the VLAN / MPLS label, then we can discuss
> whether
> > >the other information goes in additional ids of the same type or in
> a
> > >carried header.  I can construct arguments for either approach.
> > >
> > >It may be easier to just carry the subscriber identity, and used the
> > >same management systems to assign policies to the devices that care.
> > I
> > >am concerned that it may not be practical to use a single policy
> > >identifier to specify which HTTP rule set to use, which Firewall
> rule
> > >set to use, and then which specific policy for other user selected
> > >policy applications.
> > >
> > >Yours,
> > >Joel
> > >
> > >On 7/24/13 7:30 PM, Linda Dunbar wrote:
> > >> Joel,
> > >>> -----Original Message-----
> > >>>
> > >>> Yes, having the chain ingress node mark the traffic makes good
> > sense.
> > >>> Having it mark the subscriber identity and the chain to be
> > traversed
> > >>> seems quite sensible.
> > >>>
> > >>> The difference I think I have with Ron is that he proposes to use
> > >>> one identifier for both entities.
> > >> [Linda] I hope you don't mean per subscriber identity, do you?
> With
> > >> today's PCRF, subscribers are categorized based on their
> > subscription
> > >> types. Throughout the network, the "subscription types" dictate
> > >> what service modules their corresponding traffic need to traverse
> > through.
> > >> Some service modules might need to examine packets deeper (i.e.
> > >> look into payload) for their intended functions. They may need to
> > >> extract the "HTTP header" or HTTP messages from one or multiple
> packets.
> > >> That causes, as Dave said, a
> > >>> combinatorial explosion.  Rather, use two fields.  Two VLANs.
> Two
> > >>> MPLS labels.
> > >> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> > >> The subscriber identity could be some bits in the payload.
> > >>>
> > >>> And if the existing boxes don't know how to handle that (as seems
> > >>> likely) then we need a proxy / support function to translate the
> > >>> common protocol into whatever they used before we got something
> > >>> generally usable out there.
> > >>>
> > >>> Yours,
> > >>> Joel
> > >>>
> > >>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> > >>> >
> > >>> > Agree with Ron that it is better to have fewer nodes in network
> > to
> > >>> make subscriber-aware policy decisions.
> > >>> >
> > >>> > Besides, it is not uncommon for multiple subscribers to share
> > same
> > >>> sequence of service modules. In this environment, if the network
> > >>> edge nodes, such as Broadband Network Gateway or Cell Site
> > >>> Gateway, can use Layer 2 or 3 labels to mark the traffic, the
> > >>> subsequent network nodes can steer traffic to the needed service
> > >>> modules without looking into "Mega data" or other higher layer
> > >>> fields in
> > the data frames.
> > >>> >
> > >>> > This approach can make "service chain" work without making
> > changes
> > >>> > to
> > >>> majority of existing deployed network elements.
> > >>> >
> > >>> > Linda
> > >>> >
> > >>> >
> > >>> >
> > >>> >> -----Original Message-----
> > >>> >> Jim,
> > >>> >>
> > >>> >> Yes, that could work, too, conceptually.   But it does require
> > that
> > >>> >> each coarsely-defined network service have access to a
> > >>> >> subscriber-
> > >>> aware
> > >>> >> policy resolution mechanism.   IMO, it is better to have fewer
> > >>> network
> > >>> >> elements making subscriber-aware policy decisions.
> > >>> >
> > >>> >
> > >>> >>
> > >>> >>     Ron
> > >>> >>
> > >>> >>
> > >>> >> -----Original Message-----
> > >>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> > >>> >> Sent: Wednesday, July 24, 2013 6:17 PM
> > >>> >> To: Ron Parker
> > >>> >> Cc: Joel M. Halpern; nsc@ietf.org
> > >>> >> Subject: Re: [nsc] Service chaining architecture question
> > >>> >>
> > >>> >> Ron,
> > >>> >> Or alternatively carry the subscriber awareness in metadata
> > >>> >> thereby utilizing a single chain.
> > >>> >>
> > >>> >> Sent from my iPhone
> > >>> >>
> > >>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> > >>> >> <Ron_Parker@affirmednetworks.com> wrote:
> > >>> >>
> > >>> >>> Joel,
> > >>> >>>
> > >>> >>> IMO, the primary reason for understanding the subscriber
> > >>> >>> identity
> > >>> at
> > >>> >> a network service is to choose from a differentiated set of
> > >>>policies.
> > >>> >> I think there is utility and efficiency in driving that
> > selection
> > >>> from
> > >>> >> one place -- the network services classifier.     Say there
> were
> > 2
> > >>> >> groups of subscribers -- children and adults.   Let's now
> define
> > 2
> > >>> >> chains, where the chains have a business-based meaning to the
> > >>> operator.
> > >>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D
> HTTP-
> > >>> filter-
> > >>> >> adult + Firewall-adult.    The referenced network services are
> > >>> logical
> > >>> >> and it is possible, but not required, that multiple logical
> > network
> > >>> >> services be located at the same IP address or FQDN.
> > Conveying
> > >>> the
> > >>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
> > >>> ID, ...)
> > >>> >> allows the IP-addressable server that realizes these
> service(s)
> > >>> >> to
> > >>> know
> > >>> >> two things -- 1) which logical network function should be
> > invoked
> > >>> and 2)
> > >>> >> which logical network function is next.
> > >>> >>>
> > >>> >>> Thanks.
> > >>> >>> Ron
> > >>> >>>
> > >>> >>> -----Original Message-----
> > >>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > >>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> > >>> >>> To: Ron Parker
> > >>> >>> Cc: nsc@ietf.org
> > >>> >>> Subject: Re: [nsc] Service chaining architecture question
> > >>> >>>
> > >>> >>> Ron,
> > >>> >>>      maybe I am missing something, but you seem to lay out
> > >>> >>> very
> > >>> nicely
> > >>> >> the case for wanting both service chain identification and
> > >>> separately
> > >>> >> subscriber identification.  Then the HTTP filter can use the
> > >>> subscriber
> > >>> >> ID to decide which exact content filtering behavior it should
> > apply.
> > >>> I
> > >>> >> would not want to fold that level of detail into the chain
> > >>> >> identification.
> > >>> >>>
> > >>> >>> Yours,
> > >>> >>> Joel
> > >>> >>>
> > >>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> > >>> >>>> Dave,
> > >>> >>>>
> > >>> >>>> I agree that the number of chains is unlikely to scale to
> > >>> >>>> vast
> > >>> >> numbers
> > >>> >>>> (i.e., millions).     And I agree that it is bounded from a
> > >>> >> practical
> > >>> >>>> business perspective, as you point out.
> > >>> >>>>
> > >>> >>>> You may already be on this page, but I wanted to point out a
> > >>> >>>> distinction of coarse-grained definition of a service
> > >>> >>>> function
> > vs.
> > >>> >> finer-grained
> > >>> >>>> definition of a service function.   Consider a service
> > function to
> > >>> >> be
> > >>> >>>> logical in such a way that the identity of the logical
> > function
> > >>> may
> > >>> >> also
> > >>> >>>> imply some differentiated behavior.   For example, a
> > conceptual
> > >>> >> function
> > >>> >>>> is HTTP content filtering.    This conceptual function can
> > then be
> > >>> >>>> further instantiated at the logical level based on
> > >>> >>>> differentiated policies such as content-filter-children,
> > >>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm
> > >>> >>>> taking
> > >>> no
> > >>> >> stand on opt-in vs. opt-out, Mr.
> > >>> >>>> Cameron).   It may be that the same network element
> (dedicated
> > >>> >> physical
> > >>> >>>> box or virtual network function) realizes all 3 of the
> example
> > >>> >>>> policies.   The HTTP content filtering network function is
> > really
> > >>> 3
> > >>> >>>> logical network functions from the perspective of inclusion
> > >>> >>>> in a
> > >>> >> service
> > >>> >>>> chain.   Now extend this to multiple conceptual functions
> that
> > >>> >> utilize
> > >>> >>>> differentiated policies and the number of combinations will
> > >>> >>>> grow,
> > >>> at
> > >>> >>>> least modestly.
> > >>> >>>>
> > >>> >>>> Thanks,
> > >>> >>>>
> > >>> >>>> Ron
> > >>> >>>>
> > >>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]
> *On
> > >>> Behalf
> > >>> >>>> Of *David Allan I
> > >>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> > >>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
> > nsc@ietf.org
> > >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> > >>> >>>>
> > >>> >>>> Saying functions will have a problem with something that
> > exists
> > >>> >>>> as
> > >>> a
> > >>> >>>> potential rationale for defining something new with exactly
> > the
> > >>> same
> > >>> >>>> properties and problems does not quite work for me....
> > >>> >>>>
> > >>> >>>> VLANs on a vNIC or multiple vNICs (depending on the
> > application
> > >>> >> stack
> > >>> >>>> construction and this being combined with application
> > >>> "cooperation"
> > >>> >>>> to preserve pairwise mappings of either VID/NIC tuples or
> > >>> >>>> simply
> > >>> >>>> NICs) currently exist as potential vehicles for preserving
> > >>> >>>> chain context and avoiding per hop classification. Anything
> > >>> >>>> else will be implemented more or less the same way and have
> > >>> >>>> exactly the same
> > >>> set
> > >>> >>>> of scaling and application design issues...Some extra
> > >>> >>>> information available on a single interface, or achieved by
> > >>> >>>> mapping chain instances onto one of a plurality of
> > interfaces....
> > >>> >>>>
> > >>> >>>> But to back up... I'm not a carrier employee but I cannot
> > >>> >>>> envision
> > >>> a
> > >>> >>>> carrier offering potentially 1000s of distinct service
> > >>> >>>> bundles
> > >>> >> ("pick
> > >>> >>>> 53 from column A and 49 from column B"). So I suspect a much
> > >>> smaller
> > >>> >>>> number is realistic for  the number of chains a function
> > >>> >>>> instance
> > >>> is
> > >>> >>>> expected to participate in, even allowing for dynamic
> > >>> >>>> reclassification of flows at a chain ingress to "skip a few
> > >>> >>>> functions".... These are things that are fully
> > >>> >>>> operationalized in OSS, have policy associated with, have
> > >>> >>>> been industrialized and demonstrated to work prior to
> > >>> >>>> deployment. Going all combinatorial
> > >>> on
> > >>> >> this will break that big time....
> > >>> >>>>
> > >>> >>>> So are we really discussing a function participating in more
> > >>> >>>> than
> > >>> a
> > >>> >>>> handful of chain instances? And either a plurality of vNICs
> > >>> >>>> or
> > >>> VIDs
> > >>> >>>> being actually more than sufficient?
> > >>> >>>>
> > >>> >>>> Thanks
> > >>> >>>>
> > >>> >>>> Dave
> > >>> >>>>
> > >>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> > >>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
> > >>> >>>> (Wim)
> > >>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> > >>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;
> > >>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> > >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> > >>> >>>>
> > >>> >>>> indeed
> > >>> >>>>
> > >>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> > >>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> > >>> >>>> *Date: *Wednesday 24 July 2013 15:54
> > >>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> > >>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
> > >>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> > >>> >>>> *Subject: *AW: Service chaining architecture question
> > >>> >>>>
> > >>> >>>> Hi Wim,
> > >>> >>>>
> > >>> >>>> I think not only effectivness/scalability might be a problem
> > >>> >>>> but
> > >>> >> also
> > >>> >>>> the fact that not all applications (service bringing
> > functions)
> > >>> are
> > >>> >>>> able to handle packets coming from/going to potentially
> > >>> >>>> thousands
> > >>> of
> > >>> >>>> different VLANs at the same time. VLANs will work in certain
> > >>> >>>> environments but not in all. I see the need for an
> > >>> >>>> information exchange between the application and a mediation
> > >>> >>>> layer as
> > well.
> > >>> >>>> Ideally this should be as simple as possible without heavy
> > >>> >>>> impact
> > >>> on
> > >>> >>>> the application itself (might be difficult to achieve but
> > >>> >>>> from my experience it is not very likely, that there will be
> > >>> >>>> big rewrites
> > >>> of
> > >>> >>>> existing applications in order to support the chaining).
> > >>> >>>>
> > >>> >>>>    regards
> > >>> >>>>
> > >>> >>>>       Nic
> > >>> >>>>
> > >>> >>>> ------------------------------------------------------------
> -
> > >>> >>>> -
> > -
> > >>> >>>> -
> > >>> >>>> --
> > >>> --
> > >>> >> -
> > >>> >>>> -
> > >>> >>>> --
> > >>> >>>>
> > >>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
> > >>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx,
> > >>> >>>> Wim
> > >>> (Wim)
> > >>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> > >>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> > >>> >>>> *Betreff:* [nsc] Service chaining architecture question
> > >>> >>>>
> > >>> >>>> I have a basic question with respect to the
> > >>> >>>> architecture/framework
> > >>> >> so
> > >>> >>>> far mentioned in the drafts in NSC. I understand the
> > >>> >>>> meta-data is
> > >>> a
> > >>> >>>> mechanism to avoid multiple re-classifications when the
> > >>> >>>> packet
> > >>> >> enters
> > >>> >>>> the NSC domain and identifies the chain of service
> functions.
> > >>> >>>> Now
> > >>> my
> > >>> >>>> understanding is that the services/applications are unaware
> > >>> >>>> of the meta-data and that a layer underneath should provide
> > >>> >>>> the mediation and that we use a well defined interface to
> the
> > >>> application/service
> > >>> >>>> to indicate the chain. In the context of Cloud/enterprise
> > >>> >> environment
> > >>> >>>> I can see this work given you can use a dedicate VLAN e.g.
> > >>> >>>> within
> > >>> >> the tenant.
> > >>> >>>> However we also try to address residential use cases for
> > mobile
> > >>> and
> > >>> >>>> fixed and here this becomes more tricky afais. In the
> > >>> >>>> residential environment we can't expose a VLAN per
> > >>> >>>> application/service per
> > >>> chain
> > >>> >>>> since this would not be very effective. So I am wondering
> how
> > >>> >>>> we envision this to work?
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> _______________________________________________
> > >>> >>>> nsc mailing list
> > >>> >>>> nsc@ietf.org
> > >>> >>>>https://www.ietf.org/mailman/listinfo/nsc
> > >>> >>> _______________________________________________
> > >>> >>> nsc mailing list
> > >>> >>> nsc@ietf.org
> > >>> >>>https://www.ietf.org/mailman/listinfo/nsc
> > >>> >> _______________________________________________
> > >>> >> nsc mailing list
> > >>> >> nsc@ietf.org
> > >>> >>https://www.ietf.org/mailman/listinfo/nsc
> > >>> >
> > >>
> > >>
> > >> _______________________________________________
> > >> nsc mailing list
> > >> nsc@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/nsc
> > >>
> > >_______________________________________________
> > >nsc mailing list
> > >nsc@ietf.org
> > >https://www.ietf.org/mailman/listinfo/nsc
> > >_______________________________________________
> > >nsc mailing list
> > >nsc@ietf.org
> > >https://www.ietf.org/mailman/listinfo/nsc
> >
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From jguichar@cisco.com  Fri Jul 26 09:02:39 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CA621F9A57 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psDXYKyRvRcu for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:02:33 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A381521F9993 for <nsc@ietf.org>; Fri, 26 Jul 2013 09:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3445; q=dns/txt; s=iport; t=1374854553; x=1376064153; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+6D8MVbGzOraX/U0+4EBAWIn52XA4FLu9GSS5+KdVpM=; b=YTdsJMVf1ck6Ic/sfzcUns6SDtvxqvJlxPFEhk66Sjr0vGT9uelYhNBZ KEgIQo4AZr8LSDUJ3LaKAlRVTB4dPaeDCaw0V0qm0GkqBAV98TyBjmwbv r92vQzQ2ru1k3iibEZNTxO5I/zoXx4IWA63cYqeD+CdozAJ4vwM8cA6B2 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAFqc8lGtJXG+/2dsb2JhbABbgwaBBb1KgRgWdIIkAQEBAwFnDQUSAQgSBgodORQDDgIEAQ0FCBOHbwa4SY9KAjEHgxZvA4hyixaOCYcagxSCKg
X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="239733284"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2013 16:02:33 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6QG2W7U031937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 16:02:32 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 11:02:32 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A///xbrAAD1jjgP//yfoA
Date: Fri, 26 Jul 2013 16:02:32 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5C799F@xmb-rcd-x01.cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01208E09@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.211]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <EEC29859CE4CA8469184D3C3878C04CC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 16:02:39 -0000

On 7/26/13 11:15 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

>> Re-,
>>=20
>> I guess you are talking about unknown IP options in general. If a new
>> option is to be defined for what we are discussing here, these
>> firewalls will need to be updated. This is not a problem at all.
>>=20
>Absolutely agree.
>Whichever way metadata will be carried will require some changes on the
>appliance (especially, when adding NSH in front of IP packet).
>The point is to do it in the least disruptive way, i.e., without
>modifying the entire IP stack in the appliance. IP option is a realistic
>proposal. The "service chain" infrastructure doesn't need to change in
>order to accomplish this goal.

Let's be careful before painting ourselves into a corner. It is my opinion
that virtualization in general allows us the opportunity of unprecedented
service mobility that will by its very nature lead to much stronger
inter-domain dependencies. Even a basic WAN-DC service chain can be
thought of as "inter-domain", at the very least from an administrative and
operational control standpoint. If this is in fact true then using any
technology that is (i) transport-dependent (noting that engraining
metadata in the transport is not extensible to other transports), and (ii)
proven to have numerous inter-domain issues, is a dead-end street and we
should avoid placing such restrictions on ourselves. Further, one might
argue that the higher up the stack metadata is placed then the least
amount of changes are necessary down the stack; I see no realistic
evidence that the "entire" IP stack needs to be modified and even less so
if we move up the stack. It is my hope that our upcoming BoF use case
presentations will make the above statements much clearer and show that
the number and diversity of use cases is unbounded.




>
>
>Maria
>
>>=20
>> Cheers,
>> Med
>>=20
>> >-----Message d'origine-----
>> >De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >Envoy=E9 : vendredi 26 juillet 2013 14:49
>> >=C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, MARIA =
H
>> >Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>> >Objet : Re: [nsc] Service chaining architecture question
>> >
>> >Hi Med,
>> >
>> >On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>> ><mohamed.boucadair@orange.com> wrote:
>> >
>> >>>
>> >>>Adding data to existing IP headers might not prove viable, most
>> fields
>> >>>are
>> >>>either spoken for, or have significant technical limitations.  For
>> >>>example,
>> >>>IP options are usually filtered/dropped
>> >>
>> >>[Med] This is not a valid argument for the chaining case. This
>> limitation
>> >>would be a no starting point if the chaining procedure is to be
>> activated
>> >>at the level of Internet...which is not the case here. The solution
>> will
>> >>be enabled in a controlled environment, and as such, introducing a
>> new IP
>> >>option, IPv6 extension header, should be part of the viable
>> solutions. It
>> >>is too early at this stage to exclude any candidate channel to convey
>> the
>> >>marking bits.
>> >
>> >Jim> even in a controlled environment by using IP options you may
>> prevent
>> >cross-domain chaining and at the very least prevent firewalls being
>> part
>> >of the chain; every firewall I know about will drop packets containing
>> IP
>> >options.
>> >
>> >>
>


From Ron_Parker@affirmednetworks.com  Fri Jul 26 09:14:12 2013
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A7D11E810C for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RjYWw9+ET1j for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:14:06 -0700 (PDT)
Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8AD11E8105 for <nsc@ietf.org>; Fri, 26 Jul 2013 09:14:06 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0123.003; Fri, 26 Jul 2013 09:14:05 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAPrusAAA6WcXD//5GVAIAAA3AAgAEXKACAAUWMgIAAD++AgAAEvQCAACRmgIAADQsAgAB0IUA=
Date: Fri, 26 Jul 2013 16:14:05 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A68170C@MBX021-W3-CA-2.exch021.domain.local>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01208E09@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F5C799F@xmb-rcd-x01.cisco.com>
In-Reply-To: <68B171751455884590F8E38E96416F363F5C799F@xmb-rcd-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 16:14:12 -0000

Jim,

I agree that transport-dependent mechanisms should be avoided.   In my mind=
, IP connectivity between the midboxes is both necessary and sufficient.   =
Mechanisms to transport metadata follow from that.

   Ron


-----Original Message-----
From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20
Sent: Friday, July 26, 2013 12:03 PM
To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Paul Quinn (paulq)
Cc: nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
Subject: Re: [nsc] Service chaining architecture question



On 7/26/13 11:15 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

>> Re-,
>>=20
>> I guess you are talking about unknown IP options in general. If a new=20
>> option is to be defined for what we are discussing here, these=20
>> firewalls will need to be updated. This is not a problem at all.
>>=20
>Absolutely agree.
>Whichever way metadata will be carried will require some changes on the=20
>appliance (especially, when adding NSH in front of IP packet).
>The point is to do it in the least disruptive way, i.e., without=20
>modifying the entire IP stack in the appliance. IP option is a=20
>realistic proposal. The "service chain" infrastructure doesn't need to=20
>change in order to accomplish this goal.

Let's be careful before painting ourselves into a corner. It is my opinion =
that virtualization in general allows us the opportunity of unprecedented s=
ervice mobility that will by its very nature lead to much stronger inter-do=
main dependencies. Even a basic WAN-DC service chain can be thought of as "=
inter-domain", at the very least from an administrative and operational con=
trol standpoint. If this is in fact true then using any technology that is =
(i) transport-dependent (noting that engraining metadata in the transport i=
s not extensible to other transports), and (ii) proven to have numerous int=
er-domain issues, is a dead-end street and we should avoid placing such res=
trictions on ourselves. Further, one might argue that the higher up the sta=
ck metadata is placed then the least amount of changes are necessary down t=
he stack; I see no realistic evidence that the "entire" IP stack needs to b=
e modified and even less so if we move up the stack. It is my hope that our=
 upcoming BoF use case presentations will make the above statements much cl=
earer and show that the number and diversity of use cases is unbounded.




>
>
>Maria
>
>>=20
>> Cheers,
>> Med
>>=20
>> >-----Message d'origine-----
>> >De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 :=20
>> >vendredi 26 juillet 2013 14:49 =C0 : BOUCADAIR Mohamed OLNC/OLN; Paul=20
>> >Quinn (paulq); NAPIERALA, MARIA H Cc : nsc@ietf.org; Joel M.=20
>> >Halpern; Ron Parker; Linda Dunbar Objet : Re: [nsc] Service chaining=20
>> >architecture question
>> >
>> >Hi Med,
>> >
>> >On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>> ><mohamed.boucadair@orange.com> wrote:
>> >
>> >>>
>> >>>Adding data to existing IP headers might not prove viable, most
>> fields
>> >>>are
>> >>>either spoken for, or have significant technical limitations.  For=20
>> >>>example, IP options are usually filtered/dropped
>> >>
>> >>[Med] This is not a valid argument for the chaining case. This
>> limitation
>> >>would be a no starting point if the chaining procedure is to be
>> activated
>> >>at the level of Internet...which is not the case here. The solution
>> will
>> >>be enabled in a controlled environment, and as such, introducing a
>> new IP
>> >>option, IPv6 extension header, should be part of the viable
>> solutions. It
>> >>is too early at this stage to exclude any candidate channel to=20
>> >>convey
>> the
>> >>marking bits.
>> >
>> >Jim> even in a controlled environment by using IP options you may
>> prevent
>> >cross-domain chaining and at the very least prevent firewalls being
>> part
>> >of the chain; every firewall I know about will drop packets=20
>> >containing
>> IP
>> >options.
>> >
>> >>
>


From paulq@cisco.com  Fri Jul 26 09:14:42 2013
Return-Path: <paulq@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C4E11E810E for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzuS03qVBzMb for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:14:37 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDDD11E80F6 for <nsc@ietf.org>; Fri, 26 Jul 2013 09:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2477; q=dns/txt; s=iport; t=1374855277; x=1376064877; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UpZb40ky4F0vEHXtlhF2cQOAdT2azo0x2fIi8R1y4A0=; b=dp9yg4F4is3rbbHj9YDRtCzQyLR8+h20HQ6XbDairZUYGA1eFdt30cFl vSmSNasmPH/M2P2EEa//DB2VMwZjA3A6tlzXmyIOru7asieFYKvna+9IB 9VLKdkUhWw0Tgm8pJ5SWplIHQQW25B0msJ+46wwwdu8renwwg3I32kj/j A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFANyf8lGrRDoH/2dsb2JhbABbgwY1vhyBGBZ0giQBAQEDAWcNBQULCxIGJwdGAw4GExuHbwUNuDyPSjMHFoMAbwOJKo41gSmJCYcagzQc
X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="87383029"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 26 Jul 2013 16:14:36 +0000
Received: from sjc-paquinn-8714.cisco.com (sjc-paquinn-8714.cisco.com [10.19.172.245]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6QGEYIV025260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Jul 2013 16:14:35 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Paul Quinn <paulq@cisco.com>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr>
Date: Fri, 26 Jul 2013 09:14:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A766E8F5-65A7-4A63-A1BF-D6431255B212@cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr>
To: <mohamed.boucadair@orange.com>
X-Mailer: Apple Mail (2.1508)
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 16:14:42 -0000

Hi Med,


On Jul 26, 2013, at 6:05 AM, <mohamed.boucadair@orange.com> wrote:

> Re-,
>=20
> I guess you are talking about unknown IP options in general. If a new =
option is to be defined for what we are discussing here, these firewalls =
will need to be updated. This is not a problem at all.
>=20

Exactly, regardless of where metadata is carried, the services will be =
to be updated to support that metadata.  Since this seems well =
understood, the question becomes: how to best carry metadata, in way =
that is broadly applicable.


> Unlike the proposals for which the new IP option is to be carried over =
internet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2), the =
chaining case is restricted to a network segment managed by the same =
administrative entity.
>=20
> I'm not trying to advocate for the use an IP option but the point is =
it is early to decide which channel is viable or not.
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> Envoy=E9 : vendredi 26 juillet 2013 14:49
>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA, =
MARIA H
>> Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>> Objet : Re: [nsc] Service chaining architecture question
>>=20
>> Hi Med,
>>=20
>> On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>> <mohamed.boucadair@orange.com> wrote:
>>=20
>>>>=20
>>>> Adding data to existing IP headers might not prove viable, most =
fields
>>>> are
>>>> either spoken for, or have significant technical limitations.  For
>>>> example,
>>>> IP options are usually filtered/dropped
>>>=20
>>> [Med] This is not a valid argument for the chaining case. This =
limitation
>>> would be a no starting point if the chaining procedure is to be =
activated
>>> at the level of Internet...which is not the case here. The solution =
will
>>> be enabled in a controlled environment, and as such, introducing a =
new IP
>>> option, IPv6 extension header, should be part of the viable =
solutions. It
>>> is too early at this stage to exclude any candidate channel to =
convey the
>>> marking bits.
>>=20
>> Jim> even in a controlled environment by using IP options you may =
prevent
>> cross-domain chaining and at the very least prevent firewalls being =
part
>> of the chain; every firewall I know about will drop packets =
containing IP
>> options.
>>=20
>>>=20
>=20


From david.i.allan@ericsson.com  Fri Jul 26 09:33:45 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7F421F9A81 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTB5Ir5X3CWo for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:33:40 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 291A721F99C7 for <nsc@ietf.org>; Fri, 26 Jul 2013 09:33:40 -0700 (PDT)
X-AuditID: c6180641-b7f986d000007a82-46-51f2a4e30188
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8C.01.31362.3E4A2F15; Fri, 26 Jul 2013 18:33:39 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 12:33:38 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>,  Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAASuGAgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAIAAEtIA///E+wAALVdugAAIKR+QAB21IAAAAy1SoA==
Date: Fri, 26 Jul 2013 16:33:37 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D71C2@eusaamb105.ericsson.se>
References: <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF405A@xmb-aln-x09.cisco.com>
In-Reply-To: <8E86B6E7C6FB9F40A00B0E269045A7C91DDF405A@xmb-aln-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPlO7jJZ8CDY72alksnadu8fHUGyaL uy0TmSyO79vPZnHh6VRmi6ffj7M7sHm8uPKM2WPK742sHi1H3rJ6LFnyk8nj3JTvjAGsUVw2 Kak5mWWpRfp2CVwZS78bFMw7yFix501mA+PkeYxdjBwcEgImEt/n5HUxcgKZYhIX7q1nA7GF BI4ySqzZndnFyAVkL2eUmL+inx0kwSZgILHn/xdGkISIwFZGiY2tM8ESzALBEq+WP2YEsYUF LCWON78Gi4sIWEmc3dQN1bCMUWL7vRssIAkWAVWJqaf/MYPYvAK+EgfOtDBDrJvAKLHk8xWw bk6gxNe/x1hBbEag+76fWsMEsU1c4taT+UwQdwtILNlznhnCFpV4+fgfK4StLLHkyX4WiHod iQW7P7FB2NoSyxa+hlosKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQI jLZjEmyOOxgXfLI8xCjNwaIkzrtB70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsa+9Nob SpNqBThYvzGFSc2IyjzXuy21Usi3eNUBnfBPHX3x6+tfbtiZ4HV+xss5CzzX/2aQfJebw35C tWDnR7fNKzv5tOcfYQgzO1qppvv2OdeX05d/72d7w+514pUde3Hz1Ad2G+686lbSb2s6uWV9 Q+OjI4V/N2+zqdNv+ZDSrLYhiItdy1qJpTgj0VCLuag4EQA49Wn6hAIAAA==
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 16:33:46 -0000

Hi Surendra:


If I understand you correctly, you are not disputing that some meta-data is=
 needed for correctness of steering packets around (apart from the chain Id=
 itself) but just that a service can derive some kind of metadata independe=
ntly, every time.

DA> Effectively yes.  Conflating every packet with any significant amount o=
f information makes no sense to me. And I'm assuming that is what you actua=
lly mean.....

DA> If services could use a common schema and multiple services had common =
elements in that schema that applied to a given subscriber, I would design =
the service implementation around a multi-core shared memory architecture s=
o a single fetch of subscriber information could be shared by a number of s=
ervice instances , not try to imbed it in the frame.=20

Deriving meta-data (from the packet,) independently by a service has its
downsides:
* It loads the north-bound interface, if every service does this ...
DA> Yes, if an implementation goes and re-fetches the same stuff for every =
packet. Otherwise a PPP login could pre-position this stuff....

* You made a case for NAT already and I would think, if you need a service =
after a NAT in the chain, source-ip is not going to help
DA> NAT I see as a special case, it is lossy of information, is mapping sub=
scribers flows onto a scarce resources (IPv4 ports and addresses), has logg=
ing requirements etc. I see lots of reasons for putting services in front  =
of a NAT (e.g. content caching, parental controls etc) so the amount of tra=
ffic that actually reaches the NAT is minimized. I have trouble envisioning=
 use cases for a service I want to put after a NAT.=20

* In some solutions, I could potentially have the network determine which p=
olicy to use while the service simply executes that policy - in this scenar=
io, the service itself depends on the policy-input from the network (an ext=
ernal classifier); we do not want to preclude such use-cases

DA> I don't see the classifier as "the network" . The network is simply int=
erconnect.  IMO casting the network or the classifier as a PDP and the serv=
ices as a PEP does not really work for me either. I see the classifier simp=
ly as a flow subsetting mechanism permitting a degree of specialization in =
PEPs and deployment of policy "profiles" that map to identified subsets...

* In some other cases I can imagine deriving policies not only based the pa=
cket contents but also on various other attributes including environmental =
at the network or one of the services which may not be available at another=
 service
DA> You're going to have to clarify that sentence...at 50000 feet it looks =
like you mean what a PDP does...=20

IOW, there is a lot of value that meta-data can bring to enhanced service d=
elivery.
Surendra
DA> Beyond very simple tokens or apriori information in the frame, I don't =
see it. That's the view from here....

Cheers
D

On 7/26/13 1:26 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:

>Hi Surendra:
>
>Unless the intent is to embed RADIUS records or similar in the meta=20
>data, all that is going to be carried is a subscriber ID itself, which=20
>implies a policy lookup for each function that is subscriber stateful=20
>and needs subscriber specific policies.
>
>Ultimately the notion of subscriber will be uniquely inferable from=20
>information embedded in the customer frame when it arrives at the=20
>ingress to a chain, and that is without any protocol changes, else the=20
>network would already be broken!  So I'm not sure how that can be=20
>improved upon...translating what is in the frame to yet another=20
>identifier would not really have a lot of utility and would add IMO=20
>gratuitous complexity
>
>Dave
>
>-----Original Message-----
>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20
>Surendra Kumar (smkumar)
>Sent: Thursday, July 25, 2013 11:49 AM
>To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
>Cc: nsc@ietf.org; Jim Guichard (jguichar)
>Subject: Re: [nsc] Service chaining architecture question
>
>
>
>On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com> wrote:
>
>>I would prefer to think what is on the wire facilitates the forwarding=20
>>of frames, e.g. chain ID (analogous to VPN), perhaps an entropy=20
>>shorthand to help both LB and  testabilty....and facilitates uniquely=20
>>identifying the subscriber. (within the bounds of the art of the=20
>>possible, see my last post on NAT). I cannot envision a need for more.
>>And ideally I should be able to align such an approach with existing=20
>>Cloud technologies.
>SK> For entropy you are better off choosing the right transport and
>relying on that than the chain-id.
>>
>>The individual VF should be able to determine actual subscriber to a=20
>>granularity suitable for it's purposes and obtain the necessary=20
>>profile information via a northbound interface. If you then read=20
>>between the lines,  I'm all for separation of concerns as much as=20
>>possible ;-) and not creating dependencies across chain components=20
>>beyond the networking level.
>SK> Agree but I would add that subscriber identification may require
>policy-plane interaction and if it is done once in the chain, the rest=20
>of the chain can benefit from it.
>
>Surendra.
>>
>>I also do not see a huge difference between a service chain, and any=20
>>other flow of information across a string of processing elements. Just=20
>>in one application, the packet is preserved with perhaps a bit of=20
>>fondling, and in others the content may be completely deconstructed,=20
>>and repackaged into a set of transactions....and what is on the wire=20
>>between chain components does not remotely look like what went in the=20
>>front end...
>>
>>Cheers
>>Dave
>>
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20
>>Ron Parker
>>Sent: Wednesday, July 24, 2013 5:42 PM
>>To: Joel M. Halpern; Linda Dunbar
>>Cc: nsc@ietf.org; Jim Guichard (jguichar)
>>Subject: Re: [nsc] Service chaining architecture question
>>
>>Thanks, all, for a lively discussion on this topic.
>>
>>One thing that flavors the discussion of network service chaining is the
>>definition of "service".   It really means different things to different
>>people.   We networking types tend to look at it as a software
>>application or software system composed of multiple software applications
>>(i.e., an HTTP content filter).   But when I interact with the business
>>folks, especially on the operator side, I hear a different notion of=20
>>"service" -- something subscribers pay for, government mandates, etc.
>>This is why, IMO, it is defensible to say that the=20
>>HTTP-content-filter-children is a distinct service from=20
>>HTTP-content-filter-adult, even if both are realized on the same=20
>>server by the same software application using the same global URL databas=
e.
>>
>>It does sound like at least some that have chimed in do feel that both=20
>>the general service type (i.e., HTTP content filter) and the policy set
>>need to be conveyed in some manner.    How to do this is a set of
>>tradeoffs around control plane protocol and data plane encapsulation.
>>Without any control plane, both types of information need to be on the
>>wire in some form.   I will assume that the policy set identity is
>>distinct at each service instance (i.e, policy set 2 at the HTTP=20
>>content filter does not imply the same set of subscribers as policy=20
>>set
>>2 at the
>>firewall).   I will also assume that the meaning and interpretation of a
>>policy set identity is specific to that type of service and probably to
>>the vendor that supplied the service.   This is similar to when a PCRF
>>names a PCC rulebase rather than supplying the full set of explicit PCC
>>rules.    =20
>>
>>The advantage of a single chain ID that can be interpreted as a=20
>>sequence of {service-type-instance, policy-set} is that it minimizes=20
>>the per-packet encapsulation requirement (i.e., a single GRE key could
>>suffice).   The disadvantage that has been pointed out is that global
>>coordination of this identity is required and the number of=20
>>combinations could become unwieldy.
>>
>>Another approach could be to have a new encapsulation that represents=20
>>a stack of 2-tuples {service-ip-address, service-specific-policy-id},=20
>>or even 3-tuples {service-ip-address, service-type,=20
>>service-specific-policy-id} where the 3-tuple brings the added=20
>>advantage of allowing for multiple dissimilar services realized by the=20
>>same server
>>at the same server ip address.   The advantage of this approach is that
>>it avoids the combinatorial explosion problem, but it requires a=20
>>larger and variable length encapsulation.
>>
>>If the global chain id approach is used, a control plane protocol=20
>>could be used to distribute the definitions of each chain (i.e, each=20
>>chain is really a stack of 2-tuples or 3-tuples, per description above).
>>
>>Thanks.
>>
>>    Ron
>>
>>-----Original Message-----
>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>Sent: Wednesday, July 24, 2013 7:35 PM
>>To: Linda Dunbar
>>Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
>>Subject: Re: [nsc] Service chaining architecture question
>>
>>I would not be surprised if we want all three of Service Chain,=20
>>Service Policy, and Subscriber / user identity in the packet.
>>If the Chain is in the VLAN / MPLS label, then we can discuss whether=20
>>the other information goes in additional ids of the same type or in a=20
>>carried header.  I can construct arguments for either approach.
>>
>>It may be easier to just carry the subscriber identity, and used the=20
>>same management systems to assign policies to the devices that care. =20
>>I am concerned that it may not be practical to use a single policy=20
>>identifier to specify which HTTP rule set to use, which Firewall rule=20
>>set to use, and then which specific policy for other user selected=20
>>policy applications.
>>
>>Yours,
>>Joel
>>
>>On 7/24/13 7:30 PM, Linda Dunbar wrote:
>>> Joel,
>>>> -----Original Message-----
>>>>
>>>> Yes, having the chain ingress node mark the traffic makes good sense.
>>>> Having it mark the subscriber identity and the chain to be=20
>>>> traversed seems quite sensible.
>>>>
>>>> The difference I think I have with Ron is that he proposes to use=20
>>>> one identifier for both entities.
>>> [Linda] I hope you don't mean per subscriber identity, do you? With=20
>>> today's PCRF, subscribers are categorized based on their=20
>>> subscription types. Throughout the network, the "subscription types"=20
>>> dictate what service modules their corresponding traffic need to traver=
se through.
>>> Some service modules might need to examine packets deeper (i.e. look=20
>>> into payload) for their intended functions. They may need to extract=20
>>> the "HTTP header" or HTTP messages from one or multiple packets.
>>> That causes, as Dave said, a
>>>> combinatorial explosion.  Rather, use two fields.  Two VLANs.  Two=20
>>>> MPLS labels.
>>> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
>>> The subscriber identity could be some bits in the payload.
>>>>
>>>> And if the existing boxes don't know how to handle that (as seems
>>>> likely) then we need a proxy / support function to translate the=20
>>>> common protocol into whatever they used before we got something=20
>>>> generally usable out there.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
>>>> >
>>>> > Agree with Ron that it is better to have fewer nodes in network=20
>>>> > to
>>>> make subscriber-aware policy decisions.
>>>> >
>>>> > Besides, it is not uncommon for multiple subscribers to share=20
>>>> > same
>>>> sequence of service modules. In this environment, if the network =20
>>>>edge nodes, such as Broadband Network Gateway or Cell Site Gateway, =20
>>>>can use Layer 2 or 3 labels to mark the traffic, the subsequent =20
>>>>network nodes can steer traffic to the needed service modules =20
>>>>without looking into "Mega data" or other higher layer fields in the=20
>>>>data frames.
>>>> >
>>>> > This approach can make "service chain" work without making=20
>>>> > changes to
>>>> majority of existing deployed network elements.
>>>> >
>>>> > Linda
>>>> >
>>>> >
>>>> >
>>>> >> -----Original Message-----
>>>> >> Jim,
>>>> >>
>>>> >> Yes, that could work, too, conceptually.   But it does require that
>>>> >> each coarsely-defined network service have access to a
>>>> >> subscriber-
>>>> aware
>>>> >> policy resolution mechanism.   IMO, it is better to have fewer
>>>> network
>>>> >> elements making subscriber-aware policy decisions.
>>>> >
>>>> >
>>>> >>
>>>> >>     Ron
>>>> >>
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>>> >> Sent: Wednesday, July 24, 2013 6:17 PM
>>>> >> To: Ron Parker
>>>> >> Cc: Joel M. Halpern; nsc@ietf.org
>>>> >> Subject: Re: [nsc] Service chaining architecture question
>>>> >>
>>>> >> Ron,
>>>> >> Or alternatively carry the subscriber awareness in metadata=20
>>>> >> thereby utilizing a single chain.
>>>> >>
>>>> >> Sent from my iPhone
>>>> >>
>>>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
>>>> >> <Ron_Parker@affirmednetworks.com> wrote:
>>>> >>
>>>> >>> Joel,
>>>> >>>
>>>> >>> IMO, the primary reason for understanding the subscriber=20
>>>> >>> identity
>>>> at
>>>> >> a network service is to choose from a differentiated set of
>>>>policies.
>>>> >> I think there is utility and efficiency in driving that=20
>>>> >> selection
>>>> from
>>>> >> one place -- the network services classifier.     Say there were 2
>>>> >> groups of subscribers -- children and adults.   Let's now define 2
>>>> >> chains, where the chains have a business-based meaning to the
>>>> operator.
>>>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D HTTP-
>>>> filter-
>>>> >> adult + Firewall-adult.    The referenced network services are
>>>> logical
>>>> >> and it is possible, but not required, that multiple logical network
>>>> >> services be located at the same IP address or FQDN.     Conveying
>>>> the
>>>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain
>>>> ID, ...)
>>>> >> allows the IP-addressable server that realizes these service(s)=20
>>>> >> to
>>>> know
>>>> >> two things -- 1) which logical network function should be=20
>>>> >> invoked
>>>> and 2)
>>>> >> which logical network function is next.
>>>> >>>
>>>> >>> Thanks.
>>>> >>> Ron
>>>> >>>
>>>> >>> -----Original Message-----
>>>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
>>>> >>> To: Ron Parker
>>>> >>> Cc: nsc@ietf.org
>>>> >>> Subject: Re: [nsc] Service chaining architecture question
>>>> >>>
>>>> >>> Ron,
>>>> >>>      maybe I am missing something, but you seem to lay out very
>>>> nicely
>>>> >> the case for wanting both service chain identification and
>>>> separately
>>>> >> subscriber identification.  Then the HTTP filter can use the
>>>> subscriber
>>>> >> ID to decide which exact content filtering behavior it should
>>>>apply.
>>>> I
>>>> >> would not want to fold that level of detail into the chain=20
>>>> >> identification.
>>>> >>>
>>>> >>> Yours,
>>>> >>> Joel
>>>> >>>
>>>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
>>>> >>>> Dave,
>>>> >>>>
>>>> >>>> I agree that the number of chains is unlikely to scale to vast
>>>> >> numbers
>>>> >>>> (i.e., millions).     And I agree that it is bounded from a
>>>> >> practical
>>>> >>>> business perspective, as you point out.
>>>> >>>>
>>>> >>>> You may already be on this page, but I wanted to point out a=20
>>>> >>>> distinction of coarse-grained definition of a service function
>>>>vs.
>>>> >> finer-grained
>>>> >>>> definition of a service function.   Consider a service function
>>>>to
>>>> >> be
>>>> >>>> logical in such a way that the identity of the logical=20
>>>> >>>> function
>>>> may
>>>> >> also
>>>> >>>> imply some differentiated behavior.   For example, a conceptual
>>>> >> function
>>>> >>>> is HTTP content filtering.    This conceptual function can then
>>>>be
>>>> >>>> further instantiated at the logical level based on=20
>>>> >>>> differentiated policies such as content-filter-children,=20
>>>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm=20
>>>> >>>> taking
>>>> no
>>>> >> stand on opt-in vs. opt-out, Mr.
>>>> >>>> Cameron).   It may be that the same network element (dedicated
>>>> >> physical
>>>> >>>> box or virtual network function) realizes all 3 of the example
>>>> >>>> policies.   The HTTP content filtering network function is really
>>>> 3
>>>> >>>> logical network functions from the perspective of inclusion in=20
>>>> >>>> a
>>>> >> service
>>>> >>>> chain.   Now extend this to multiple conceptual functions that
>>>> >> utilize
>>>> >>>> differentiated policies and the number of combinations will=20
>>>> >>>> grow,
>>>> at
>>>> >>>> least modestly.
>>>> >>>>
>>>> >>>> Thanks,
>>>> >>>>
>>>> >>>> Ron
>>>> >>>>
>>>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On
>>>> Behalf
>>>> >>>> Of *David Allan I
>>>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>>>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;=20
>>>> >>>> nsc@ietf.org
>>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>> >>>>
>>>> >>>> Saying functions will have a problem with something that=20
>>>> >>>> exists as
>>>> a
>>>> >>>> potential rationale for defining something new with exactly=20
>>>> >>>> the
>>>> same
>>>> >>>> properties and problems does not quite work for me....
>>>> >>>>
>>>> >>>> VLANs on a vNIC or multiple vNICs (depending on the=20
>>>> >>>> application
>>>> >> stack
>>>> >>>> construction and this being combined with application
>>>> "cooperation"
>>>> >>>> to preserve pairwise mappings of either VID/NIC tuples or=20
>>>> >>>> simply
>>>> >>>> NICs) currently exist as potential vehicles for preserving=20
>>>> >>>> chain context and avoiding per hop classification. Anything=20
>>>> >>>> else will be implemented more or less the same way and have=20
>>>> >>>> exactly the same
>>>> set
>>>> >>>> of scaling and application design issues...Some extra=20
>>>> >>>> information available on a single interface, or achieved by=20
>>>> >>>> mapping chain instances onto one of a plurality of interfaces....
>>>> >>>>
>>>> >>>> But to back up... I'm not a carrier employee but I cannot=20
>>>> >>>> envision
>>>> a
>>>> >>>> carrier offering potentially 1000s of distinct service bundles
>>>> >> ("pick
>>>> >>>> 53 from column A and 49 from column B"). So I suspect a much
>>>> smaller
>>>> >>>> number is realistic for  the number of chains a function=20
>>>> >>>> instance
>>>> is
>>>> >>>> expected to participate in, even allowing for dynamic=20
>>>> >>>> reclassification of flows at a chain ingress to "skip a few=20
>>>> >>>> functions".... These are things that are fully operationalized=20
>>>> >>>> in OSS, have policy associated with, have been industrialized=20
>>>> >>>> and demonstrated to work prior to deployment. Going all=20
>>>> >>>> combinatorial
>>>> on
>>>> >> this will break that big time....
>>>> >>>>
>>>> >>>> So are we really discussing a function participating in more=20
>>>> >>>> than
>>>> a
>>>> >>>> handful of chain instances? And either a plurality of vNICs or
>>>> VIDs
>>>> >>>> being actually more than sufficient?
>>>> >>>>
>>>> >>>> Thanks
>>>> >>>>
>>>> >>>> Dave
>>>> >>>>
>>>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>>>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim
>>>> >>>> (Wim)
>>>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>>>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
>>>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
>>>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
>>>> >>>>
>>>> >>>> indeed
>>>> >>>>
>>>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>>>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>>>> >>>> *Date: *Wednesday 24 July 2013 15:54
>>>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>>>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
>>>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>>>> >>>> *Subject: *AW: Service chaining architecture question
>>>> >>>>
>>>> >>>> Hi Wim,
>>>> >>>>
>>>> >>>> I think not only effectivness/scalability might be a problem=20
>>>> >>>> but
>>>> >> also
>>>> >>>> the fact that not all applications (service bringing=20
>>>> >>>> functions)
>>>> are
>>>> >>>> able to handle packets coming from/going to potentially=20
>>>> >>>> thousands
>>>> of
>>>> >>>> different VLANs at the same time. VLANs will work in certain=20
>>>> >>>> environments but not in all. I see the need for an information=20
>>>> >>>> exchange between the application and a mediation layer as well.
>>>> >>>> Ideally this should be as simple as possible without heavy=20
>>>> >>>> impact
>>>> on
>>>> >>>> the application itself (might be difficult to achieve but from=20
>>>> >>>> my experience it is not very likely, that there will be big=20
>>>> >>>> rewrites
>>>> of
>>>> >>>> existing applications in order to support the chaining).
>>>> >>>>
>>>> >>>>    regards
>>>> >>>>
>>>> >>>>       Nic
>>>> >>>>
>>>> >>>> --------------------------------------------------------------
>>>> >>>> -
>>>> >>>> -
>>>> >>>> --
>>>> --
>>>> >> -
>>>> >>>> -
>>>> >>>> --
>>>> >>>>
>>>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
>>>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim
>>>> (Wim)
>>>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>>>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>>>> >>>> *Betreff:* [nsc] Service chaining architecture question
>>>> >>>>
>>>> >>>> I have a basic question with respect to the=20
>>>> >>>> architecture/framework
>>>> >> so
>>>> >>>> far mentioned in the drafts in NSC. I understand the meta-data=20
>>>> >>>> is
>>>> a
>>>> >>>> mechanism to avoid multiple re-classifications when the packet
>>>> >> enters
>>>> >>>> the NSC domain and identifies the chain of service functions.
>>>> >>>> Now
>>>> my
>>>> >>>> understanding is that the services/applications are unaware of=20
>>>> >>>> the meta-data and that a layer underneath should provide the=20
>>>> >>>> mediation and that we use a well defined interface to the
>>>> application/service
>>>> >>>> to indicate the chain. In the context of Cloud/enterprise
>>>> >> environment
>>>> >>>> I can see this work given you can use a dedicate VLAN e.g.
>>>> >>>> within
>>>> >> the tenant.
>>>> >>>> However we also try to address residential use cases for=20
>>>> >>>> mobile
>>>> and
>>>> >>>> fixed and here this becomes more tricky afais. In the=20
>>>> >>>> residential environment we can't expose a VLAN per=20
>>>> >>>> application/service per
>>>> chain
>>>> >>>> since this would not be very effective. So I am wondering how=20
>>>> >>>> we envision this to work?
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> nsc mailing list
>>>> >>>> nsc@ietf.org
>>>> >>>>https://www.ietf.org/mailman/listinfo/nsc
>>>> >>> _______________________________________________
>>>> >>> nsc mailing list
>>>> >>> nsc@ietf.org
>>>> >>>https://www.ietf.org/mailman/listinfo/nsc
>>>> >> _______________________________________________
>>>> >> nsc mailing list
>>>> >> nsc@ietf.org
>>>> >>https://www.ietf.org/mailman/listinfo/nsc
>>>> >
>>>
>>>
>>> _______________________________________________
>>> nsc mailing list
>>> nsc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nsc
>>>
>>_______________________________________________
>>nsc mailing list
>>nsc@ietf.org
>>https://www.ietf.org/mailman/listinfo/nsc
>>_______________________________________________
>>nsc mailing list
>>nsc@ietf.org
>>https://www.ietf.org/mailman/listinfo/nsc
>
>_______________________________________________
>nsc mailing list
>nsc@ietf.org
>https://www.ietf.org/mailman/listinfo/nsc


From mn1921@att.com  Fri Jul 26 09:45:15 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F7F21F9AE9 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se9M0MxG7IBv for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:45:09 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB721F873C for <nsc@ietf.org>; Fri, 26 Jul 2013 09:45:08 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 497a2f15.2aaabbeca940.3788342.00-541.10385279.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 16:45:08 +0000 (UTC)
X-MXL-Hash: 51f2a79462703348-ab5d6ec268ceba96f948632f76a17e31165fdf27
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f87a2f15.0.3788335.00-416.10385148.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 16:45:04 +0000 (UTC)
X-MXL-Hash: 51f2a790652554a9-a8ed5850a8bb65309e7862f8755ec8acf395b8aa
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QGj01E011834; Fri, 26 Jul 2013 12:45:01 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QGintJ011670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 12:44:50 -0400
Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 26 Jul 2013 16:44:36 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0342.003; Fri, 26 Jul 2013 12:44:35 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeAgAALhACAABT2gIAABD2AgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAP//vmwQgAFcKwCAAUWNgIAAD++AgAAEvAD//98Y4AAKS1MAAAfsxWA=
Date: Fri, 26 Jul 2013 16:44:35 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01208F68@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <1D70D757A2C9D54D83B4CBD7625FA80E01208E09@MISOUT7MSGUSR9I.ITServices.sbc.com> <68B171751455884590F8E38E96416F363F5C799F@xmb-rcd-x01.cisco.com>
In-Reply-To: <68B171751455884590F8E38E96416F363F5C799F@xmb-rcd-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.91.76.193]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=WbS7nTdX c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=-s3I2kwCOWQA:10 a=2DTnKp0c6ewA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=QNNNeoGkA4wA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=z9tbli-vAAAA:8 a=V2NuAAntbzX3U83RVyYA:9 a=wPNLvfGTeEIA:]
X-AnalysisOut: [10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10]
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 16:45:16 -0000

Jim,

> >> I guess you are talking about unknown IP options in general. If a
> new
> >> option is to be defined for what we are discussing here, these
> >> firewalls will need to be updated. This is not a problem at all.
> >>
> >Absolutely agree.
> >Whichever way metadata will be carried will require some changes on
> the
> >appliance (especially, when adding NSH in front of IP packet).
> >The point is to do it in the least disruptive way, i.e., without
> >modifying the entire IP stack in the appliance. IP option is a
> realistic
> >proposal. The "service chain" infrastructure doesn't need to change in
> >order to accomplish this goal.
>=20
> Let's be careful before painting ourselves into a corner. It is my
> opinion
> that virtualization in general allows us the opportunity of
> unprecedented
> service mobility that will by its very nature lead to much stronger
> inter-domain dependencies. Even a basic WAN-DC service chain can be
> thought of as "inter-domain", at the very least from an administrative
> and
> operational control standpoint. If this is in fact true then using any
> technology that is (i) transport-dependent (noting that engraining
> metadata in the transport is not extensible to other transports), and
> (ii)
> proven to have numerous inter-domain issues, is a dead-end street and
> we
> should avoid placing such restrictions on ourselves. Further, one might

You are making certain assumptions about how WAN-DC connectivity is done, i=
.e., that it is done at the IP level. It might not be. It may be at MPLS le=
vel.
But even if it is done at the IP level, the DC-WAN gateway connectivity is =
in a managed environment.
Using the proposed new NSH header, the DC-WAN gateway has to able to unders=
tand this header, and it doesn't today. So, you consider it less impacting =
than ability to pass an IPv4 option or IPv6 flow label in a managed environ=
ment.=20

> argue that the higher up the stack metadata is placed then the least
> amount of changes are necessary down the stack; I see no realistic
> evidence that the "entire" IP stack needs to be modified and even less
> so

What is the realistic evidence that it is not?

> if we move up the stack. It is my hope that our upcoming BoF use case
> presentations will make the above statements much clearer and show that
> the number and diversity of use cases is unbounded.


Maria

> >
> >>
> >> Cheers,
> >> Med
> >>
> >> >-----Message d'origine-----
> >> >De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >> >Envoy=E9 : vendredi 26 juillet 2013 14:49
> >> >=C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA,
> MARIA H
> >> >Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
> >> >Objet : Re: [nsc] Service chaining architecture question
> >> >
> >> >Hi Med,
> >> >
> >> >On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
> >> ><mohamed.boucadair@orange.com> wrote:
> >> >
> >> >>>
> >> >>>Adding data to existing IP headers might not prove viable, most
> >> fields
> >> >>>are
> >> >>>either spoken for, or have significant technical limitations.
> For
> >> >>>example,
> >> >>>IP options are usually filtered/dropped
> >> >>
> >> >>[Med] This is not a valid argument for the chaining case. This
> >> limitation
> >> >>would be a no starting point if the chaining procedure is to be
> >> activated
> >> >>at the level of Internet...which is not the case here. The
> solution
> >> will
> >> >>be enabled in a controlled environment, and as such, introducing a
> >> new IP
> >> >>option, IPv6 extension header, should be part of the viable
> >> solutions. It
> >> >>is too early at this stage to exclude any candidate channel to
> convey
> >> the
> >> >>marking bits.
> >> >
> >> >Jim> even in a controlled environment by using IP options you may
> >> prevent
> >> >cross-domain chaining and at the very least prevent firewalls being
> >> part
> >> >of the chain; every firewall I know about will drop packets
> containing
> >> IP
> >> >options.
> >> >
> >> >>
> >


From jguichar@cisco.com  Fri Jul 26 09:58:37 2013
Return-Path: <jguichar@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AF521F977A for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzHsynVBkYut for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 09:58:32 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2814021F991F for <nsc@ietf.org>; Fri, 26 Jul 2013 09:58:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3197; q=dns/txt; s=iport; t=1374857908; x=1376067508; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i9ABLAEJ8OOwKIf1hqXjDU1OqOYVhbfbkzKtRYh+Mas=; b=ea9RUBr3uHOyFhG+JZgcoF0DtNeG0C4XFV8rmAgGpjaoTU+LpgSMhJC+ 5E6KPLJFM0hdh6Cjxlo6utfz2aMz4wKL1LJsoEWkxNlInhdxBekIWr2B1 X+hF0+eKhp54htbbeubZXxPLP/W9A9yCb/jL4hg+oMVopIG9PG2NtJLJW M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFALWp8lGtJXHB/2dsb2JhbABbgwaBBb1cgRgWdIIkAQEBAwF0BRIBCBIGCh05FAMOAgQBDQUIE4dvBrhTj0wxB4MWbwOIcpkfhxqDFIIq
X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="239925294"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jul 2013 16:58:27 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6QGwRP0011146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 16:58:27 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.94]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 11:58:27 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A///xbrAAD1jjgP//yfoAgABO0ID//8DOAA==
Date: Fri, 26 Jul 2013 16:58:27 +0000
Message-ID: <68B171751455884590F8E38E96416F363F5C7C92@xmb-rcd-x01.cisco.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01208F68@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.130.211]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <75503E4FF37069418A675B2B530F6F10@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 16:58:37 -0000

Hi Maria,

>
>You are making certain assumptions about how WAN-DC connectivity is done,
>i.e., that it is done at the IP level. It might not be. It may be at MPLS
>level.
>But even if it is done at the IP level, the DC-WAN gateway connectivity
>is in a managed environment.
>Using the proposed new NSH header, the DC-WAN gateway has to able to
>understand this header, and it doesn't today. So, you consider it less
>impacting than ability to pass an IPv4 option or IPv6 flow label in a
>managed environment.

To the contrary, I make no assumptions to the type of WAN-DC connectivity,
but simply make a statement that all are in scope. Further, by pushing the
metadata up the stack then the WAN-DC gateway need not be forced to
understand the header which is precisely why you want to make this whole
thing independent from the transport.

>=20
>
>> argue that the higher up the stack metadata is placed then the least
>> amount of changes are necessary down the stack; I see no realistic
>> evidence that the "entire" IP stack needs to be modified and even less
>> so
>
>What is the realistic evidence that it is not?

Because one of the goals is to make the service plane independent from the
transport.=20

>
>> if we move up the stack. It is my hope that our upcoming BoF use case
>> presentations will make the above statements much clearer and show that
>> the number and diversity of use cases is unbounded.
>
>
>Maria
>
>> >
>> >>
>> >> Cheers,
>> >> Med
>> >>
>> >> >-----Message d'origine-----
>> >> >De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>> >> >Envoy=E9 : vendredi 26 juillet 2013 14:49
>> >> >=C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA,
>> MARIA H
>> >> >Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>> >> >Objet : Re: [nsc] Service chaining architecture question
>> >> >
>> >> >Hi Med,
>> >> >
>> >> >On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>> >> ><mohamed.boucadair@orange.com> wrote:
>> >> >
>> >> >>>
>> >> >>>Adding data to existing IP headers might not prove viable, most
>> >> fields
>> >> >>>are
>> >> >>>either spoken for, or have significant technical limitations.
>> For
>> >> >>>example,
>> >> >>>IP options are usually filtered/dropped
>> >> >>
>> >> >>[Med] This is not a valid argument for the chaining case. This
>> >> limitation
>> >> >>would be a no starting point if the chaining procedure is to be
>> >> activated
>> >> >>at the level of Internet...which is not the case here. The
>> solution
>> >> will
>> >> >>be enabled in a controlled environment, and as such, introducing a
>> >> new IP
>> >> >>option, IPv6 extension header, should be part of the viable
>> >> solutions. It
>> >> >>is too early at this stage to exclude any candidate channel to
>> convey
>> >> the
>> >> >>marking bits.
>> >> >
>> >> >Jim> even in a controlled environment by using IP options you may
>> >> prevent
>> >> >cross-domain chaining and at the very least prevent firewalls being
>> >> part
>> >> >of the chain; every firewall I know about will drop packets
>> containing
>> >> IP
>> >> >options.
>> >> >
>> >> >>
>> >
>


From david.i.allan@ericsson.com  Fri Jul 26 10:03:40 2013
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD37321F918C for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 10:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoNwMqVRsQLX for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 10:03:23 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 65F5221F8B35 for <nsc@ietf.org>; Fri, 26 Jul 2013 10:03:23 -0700 (PDT)
X-AuditID: c6180641-b7f986d000007a82-b5-51f2abd96e04
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 33.F2.31362.9DBA2F15; Fri, 26 Jul 2013 19:03:22 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 13:03:21 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAASuGAgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAIAAEtIA///E+wAALVdugAAIKR+Q///oCACAAEFzoIAA776AgAArl3A=
Date: Fri, 26 Jul 2013 17:03:20 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C115D7221@eusaamb105.ericsson.se>
References: <E6C17D2345AC7A45B7D054D407AA205C115D697E@eusaamb105.ericsson.se> <8E86B6E7C6FB9F40A00B0E269045A7C91DDF3964@xmb-aln-x09.cisco.com> <E6C17D2345AC7A45B7D054D407AA205C115D6E9C@eusaamb105.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01208861@MISOUT7MSGUSR9I.ITServices.sbc.com> <E6C17D2345AC7A45B7D054D407AA205C115D6F2C@eusaamb105.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01208E91@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01208E91@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyuXSPn+6t1Z8CDXbP5rFYOk/d4uOpN0wW d1smMllsnNzGaHF83342iwtPpzJbPP1+nN2B3ePFlWfMHi/75zB6TPm9kdWj5chbVo8lS34y eZyb8p0xgC2KyyYlNSezLLVI3y6BK2PqwzvMBa/PMFasnnqdvYHx5gLGLkZODgkBE4mta3cz QdhiEhfurWfrYuTiEBI4yijRf3UHE4SznFFib8cZdpAqNgEDiT3/v4B1iwjcYZRY+9wGxGYW CJZ4tfwxWFxYwFLiePNrdogaK4mzm7oZQQaJCGxilPj4YgszSIJFQFWis7uJFcTmFfCVWDnp AyvEth3MEpsnTwS7iVMgSuLo/0lsIDYj0H3fT61hgtgmLnHryXyouwUkluw5zwxhi0q8fPyP FcJWlljyZD8LRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlW MXKUFqeW5aYbGW5iBMbhMQk2xx2MCz5ZHmKU5mBREufdoHcmUEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAOjAu/5X4ErJ836eGfphBmGaxkfSymuM/X6HnKfg/XWrV/3Jvu5Hzqdc7F5yZqv HbKHp86/XxH+V+pX2KHm1qgDk2um3/oSUcfX8154Svf2FUrG//l9JdzLFh/dqSLZpxp7rGeO e8pHcc65y/pf+ZbOCJ6s7MCuFuNwIiNNe+uflaF6s0/NktQJVmIpzkg01GIuKk4EAH/3WBqR AgAA
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 17:03:41 -0000

HI Maria:

Ultimately we have a very restricted set of use cases....

We require flow subsetting to the point where a specific class of service f=
unction sees the smallest useful aggregate of traffic it can operate upon. =
 I see a chain identifier as the "subset ID"....which I would like to think=
 could subsume the concept of "application ID",  as it combined with "chain=
 ID" is simply two layers of flow subsetting.

That service function may implement subscriber specific policies, so the su=
bscriber ID needs to be in the frame, to date I've argued that it is alread=
y there.

Whatever else is required would be there to facilitate OAM, scale out etc.

So I think our mental models are conceptually close!

Dave



-----Original Message-----
From: NAPIERALA, MARIA H [mailto:mn1921@att.com]=20
Sent: Friday, July 26, 2013 8:30 AM
To: David Allan I; Surendra Kumar (smkumar); Ron Parker; Joel M. Halpern; L=
inda Dunbar
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: RE: [nsc] Service chaining architecture question

Dave,

There might be cases (e.g., when offering IP services to mobile subscribers=
) where the metadata (e.g., subscriber-id, application-id) could be of valu=
e. Some services might operate on subscriber-id information (e.g., MSISDN i=
n mobility). Or, after a DPI, a downstream service might need to know the a=
pp-id.=20

Maria

> -----Original Message-----
> From: David Allan I [mailto:david.i.allan@ericsson.com]
> Sent: Thursday, July 25, 2013 5:26 PM
> To: NAPIERALA, MARIA H; Surendra Kumar (smkumar); Ron Parker; Joel M.
> Halpern; Linda Dunbar
> Cc: nsc@ietf.org; Jim Guichard (jguichar)
> Subject: RE: [nsc] Service chaining architecture question
>=20
> So it is going to pass other stuff instead.... ????
>=20
> Isn't this pretty much the same, make the VF "frame transparent" and=20
> you're DONE....  just need to write a BCP!
>=20
> cheers
> Dave
>=20
> -----Original Message-----
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20
> NAPIERALA, MARIA H
> Sent: Thursday, July 25, 2013 2:17 PM
> To: David Allan I; Surendra Kumar (smkumar); Ron Parker; Joel M.
> Halpern; Linda Dunbar
> Cc: nsc@ietf.org; Jim Guichard (jguichar)
> Subject: Re: [nsc] Service chaining architecture question
>=20
> >
> > Ultimately the notion of subscriber will be uniquely inferable from=20
> > information embedded in the customer frame when it arrives at the=20
> > ingress to a chain, and that is without any protocol changes, else
> the
> > network would already be broken!  So I'm not sure how that can be=20
> > improved upon...translating what is in the frame to yet another=20
> > identifier would not really have a lot of utility and would add IMO=20
> > gratuitous complexity
>=20
> Right!  Now, the services may want to know what is the subscriber id=20
> or application id. This is where the metadata comes in.
> We should handle metadata in such a way that it does not require the=20
> entire IP stack on the appliance to be modified to pass this extra=20
> data.
>=20
> Maria
> > -----Original Message-----
> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20
> > Of Surendra Kumar (smkumar)
> > Sent: Thursday, July 25, 2013 11:49 AM
> > To: David Allan I; Ron Parker; Joel M. Halpern; Linda Dunbar
> > Cc: nsc@ietf.org; Jim Guichard (jguichar)
> > Subject: Re: [nsc] Service chaining architecture question
> >
> >
> >
> > On 7/25/13 6:55 AM, "David Allan I" <david.i.allan@ericsson.com>
> wrote:
> >
> > >I would prefer to think what is on the wire facilitates the=20
> > >forwarding of frames, e.g. chain ID (analogous to VPN), perhaps an=20
> > >entropy shorthand to help both LB and  testabilty....and=20
> > >facilitates uniquely identifying the subscriber. (within the bounds=20
> > >of the art
> of
> > >the possible, see my last post on NAT). I cannot envision a need=20
> > >for
> more.
> > >And ideally I should be able to align such an approach with=20
> > >existing
> > Cloud technologies.
> > SK> For entropy you are better off choosing the right transport and
> > relying on that than the chain-id.
> > >
> > >The individual VF should be able to determine actual subscriber to=20
> > >a granularity suitable for it's purposes and obtain the necessary
> > profile
> > >information via a northbound interface. If you then read between=20
> > >the lines,  I'm all for separation of concerns as much as possible=20
> > >;-) and not creating dependencies across chain components beyond=20
> > >the
> > networking
> > >level.
> > SK> Agree but I would add that subscriber identification may require
> > policy-plane interaction and if it is done once in the chain, the
> rest
> > of the chain can benefit from it.
> >
> > Surendra.
> > >
> > >I also do not see a huge difference between a service chain, and=20
> > >any other flow of information across a string of processing elements.
> > >Just in one application, the packet is preserved with perhaps a bit=20
> > >of fondling, and in others the content may be completely=20
> > >deconstructed, and repackaged into a set of transactions....and=20
> > >what is on the wire between chain components does not remotely look=20
> > >like what went in the
> > front end...
> > >
> > >Cheers
> > >Dave
> > >
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf
> Of
> > >Ron Parker
> > >Sent: Wednesday, July 24, 2013 5:42 PM
> > >To: Joel M. Halpern; Linda Dunbar
> > >Cc: nsc@ietf.org; Jim Guichard (jguichar)
> > >Subject: Re: [nsc] Service chaining architecture question
> > >
> > >Thanks, all, for a lively discussion on this topic.
> > >
> > >One thing that flavors the discussion of network service chaining=20
> > >is
> > the
> > >definition of "service".   It really means different things to
> > different
> > >people.   We networking types tend to look at it as a software
> > >application or software system composed of multiple software
> > applications
> > >(i.e., an HTTP content filter).   But when I interact with the
> > business
> > >folks, especially on the operator side, I hear a different notion=20
> > >of "service" -- something subscribers pay for, government mandates,
> etc.
> > >This is why, IMO, it is defensible to say that the=20
> > >HTTP-content-filter-children is a distinct service from=20
> > >HTTP-content-filter-adult, even if both are realized on the same
> > server
> > >by the same software application using the same global URL database.
> > >
> > >It does sound like at least some that have chimed in do feel that=20
> > >both the general service type (i.e., HTTP content filter) and the=20
> > >policy
> > set
> > >need to be conveyed in some manner.    How to do this is a set of
> > >tradeoffs around control plane protocol and data plane
> encapsulation.
> > >Without any control plane, both types of information need to be on
> the
> > >wire in some form.   I will assume that the policy set identity is
> > >distinct at each service instance (i.e, policy set 2 at the HTTP=20
> > >content filter does not imply the same set of subscribers as policy
> > set 2 at the
> > >firewall).   I will also assume that the meaning and interpretation
> of
> > a
> > >policy set identity is specific to that type of service and=20
> > >probably
> > to
> > >the vendor that supplied the service.   This is similar to when a
> PCRF
> > >names a PCC rulebase rather than supplying the full set of explicit
> > PCC
> > >rules.
> > >
> > >The advantage of a single chain ID that can be interpreted as a=20
> > >sequence of {service-type-instance, policy-set} is that it=20
> > >minimizes the per-packet encapsulation requirement (i.e., a single=20
> > >GRE key
> could
> > >suffice).   The disadvantage that has been pointed out is that
> global
> > >coordination of this identity is required and the number of=20
> > >combinations could become unwieldy.
> > >
> > >Another approach could be to have a new encapsulation that
> represents
> > a
> > >stack of 2-tuples {service-ip-address, service-specific-policy-id},=20
> > >or even 3-tuples {service-ip-address, service-type,=20
> > >service-specific-policy-id} where the 3-tuple brings the added=20
> > >advantage of allowing for multiple dissimilar services realized by=20
> > >the
> > same server
> > >at the same server ip address.   The advantage of this approach is
> > that
> > >it avoids the combinatorial explosion problem, but it requires a
> > larger
> > >and variable length encapsulation.
> > >
> > >If the global chain id approach is used, a control plane protocol
> > could
> > >be used to distribute the definitions of each chain (i.e, each=20
> > >chain
> > is
> > >really a stack of 2-tuples or 3-tuples, per description above).
> > >
> > >Thanks.
> > >
> > >    Ron
> > >
> > >-----Original Message-----
> > >From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > >Sent: Wednesday, July 24, 2013 7:35 PM
> > >To: Linda Dunbar
> > >Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker
> > >Subject: Re: [nsc] Service chaining architecture question
> > >
> > >I would not be surprised if we want all three of Service Chain,
> > Service
> > >Policy, and Subscriber / user identity in the packet.
> > >If the Chain is in the VLAN / MPLS label, then we can discuss
> whether
> > >the other information goes in additional ids of the same type or in
> a
> > >carried header.  I can construct arguments for either approach.
> > >
> > >It may be easier to just carry the subscriber identity, and used=20
> > >the same management systems to assign policies to the devices that car=
e.
> > I
> > >am concerned that it may not be practical to use a single policy=20
> > >identifier to specify which HTTP rule set to use, which Firewall
> rule
> > >set to use, and then which specific policy for other user selected=20
> > >policy applications.
> > >
> > >Yours,
> > >Joel
> > >
> > >On 7/24/13 7:30 PM, Linda Dunbar wrote:
> > >> Joel,
> > >>> -----Original Message-----
> > >>>
> > >>> Yes, having the chain ingress node mark the traffic makes good
> > sense.
> > >>> Having it mark the subscriber identity and the chain to be
> > traversed
> > >>> seems quite sensible.
> > >>>
> > >>> The difference I think I have with Ron is that he proposes to=20
> > >>> use one identifier for both entities.
> > >> [Linda] I hope you don't mean per subscriber identity, do you?
> With
> > >> today's PCRF, subscribers are categorized based on their
> > subscription
> > >> types. Throughout the network, the "subscription types" dictate=20
> > >> what service modules their corresponding traffic need to traverse
> > through.
> > >> Some service modules might need to examine packets deeper (i.e.
> > >> look into payload) for their intended functions. They may need to=20
> > >> extract the "HTTP header" or HTTP messages from one or multiple
> packets.
> > >> That causes, as Dave said, a
> > >>> combinatorial explosion.  Rather, use two fields.  Two VLANs.
> Two
> > >>> MPLS labels.
> > >> [Linda] It doesn't have to be two "VLANs" or two MPLS, right?
> > >> The subscriber identity could be some bits in the payload.
> > >>>
> > >>> And if the existing boxes don't know how to handle that (as=20
> > >>> seems
> > >>> likely) then we need a proxy / support function to translate the=20
> > >>> common protocol into whatever they used before we got something=20
> > >>> generally usable out there.
> > >>>
> > >>> Yours,
> > >>> Joel
> > >>>
> > >>> On 7/24/13 6:53 PM, Linda Dunbar wrote:
> > >>> >
> > >>> > Agree with Ron that it is better to have fewer nodes in=20
> > >>> > network
> > to
> > >>> make subscriber-aware policy decisions.
> > >>> >
> > >>> > Besides, it is not uncommon for multiple subscribers to share
> > same
> > >>> sequence of service modules. In this environment, if the network=20
> > >>> edge nodes, such as Broadband Network Gateway or Cell Site=20
> > >>> Gateway, can use Layer 2 or 3 labels to mark the traffic, the=20
> > >>> subsequent network nodes can steer traffic to the needed service=20
> > >>> modules without looking into "Mega data" or other higher layer=20
> > >>> fields in
> > the data frames.
> > >>> >
> > >>> > This approach can make "service chain" work without making
> > changes
> > >>> > to
> > >>> majority of existing deployed network elements.
> > >>> >
> > >>> > Linda
> > >>> >
> > >>> >
> > >>> >
> > >>> >> -----Original Message-----
> > >>> >> Jim,
> > >>> >>
> > >>> >> Yes, that could work, too, conceptually.   But it does require
> > that
> > >>> >> each coarsely-defined network service have access to a
> > >>> >> subscriber-
> > >>> aware
> > >>> >> policy resolution mechanism.   IMO, it is better to have fewer
> > >>> network
> > >>> >> elements making subscriber-aware policy decisions.
> > >>> >
> > >>> >
> > >>> >>
> > >>> >>     Ron
> > >>> >>
> > >>> >>
> > >>> >> -----Original Message-----
> > >>> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> > >>> >> Sent: Wednesday, July 24, 2013 6:17 PM
> > >>> >> To: Ron Parker
> > >>> >> Cc: Joel M. Halpern; nsc@ietf.org
> > >>> >> Subject: Re: [nsc] Service chaining architecture question
> > >>> >>
> > >>> >> Ron,
> > >>> >> Or alternatively carry the subscriber awareness in metadata=20
> > >>> >> thereby utilizing a single chain.
> > >>> >>
> > >>> >> Sent from my iPhone
> > >>> >>
> > >>> >> On Jul 24, 2013, at 6:02 PM, "Ron Parker"
> > >>> >> <Ron_Parker@affirmednetworks.com> wrote:
> > >>> >>
> > >>> >>> Joel,
> > >>> >>>
> > >>> >>> IMO, the primary reason for understanding the subscriber=20
> > >>> >>> identity
> > >>> at
> > >>> >> a network service is to choose from a differentiated set of
> > >>>policies.
> > >>> >> I think there is utility and efficiency in driving that
> > selection
> > >>> from
> > >>> >> one place -- the network services classifier.     Say there
> were
> > 2
> > >>> >> groups of subscribers -- children and adults.   Let's now
> define
> > 2
> > >>> >> chains, where the chains have a business-based meaning to the
> > >>> operator.
> > >>> >> Chain 1 =3D HTTP-filter-child + Firewall-child.   Chain 2 =3D
> HTTP-
> > >>> filter-
> > >>> >> adult + Firewall-adult.    The referenced network services are
> > >>> logical
> > >>> >> and it is possible, but not required, that multiple logical
> > network
> > >>> >> services be located at the same IP address or FQDN.
> > Conveying
> > >>> the
> > >>> >> actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH=20
> > >>> >> chain
> > >>> ID, ...)
> > >>> >> allows the IP-addressable server that realizes these
> service(s)
> > >>> >> to
> > >>> know
> > >>> >> two things -- 1) which logical network function should be
> > invoked
> > >>> and 2)
> > >>> >> which logical network function is next.
> > >>> >>>
> > >>> >>> Thanks.
> > >>> >>> Ron
> > >>> >>>
> > >>> >>> -----Original Message-----
> > >>> >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > >>> >>> Sent: Wednesday, July 24, 2013 4:47 PM
> > >>> >>> To: Ron Parker
> > >>> >>> Cc: nsc@ietf.org
> > >>> >>> Subject: Re: [nsc] Service chaining architecture question
> > >>> >>>
> > >>> >>> Ron,
> > >>> >>>      maybe I am missing something, but you seem to lay out=20
> > >>> >>> very
> > >>> nicely
> > >>> >> the case for wanting both service chain identification and
> > >>> separately
> > >>> >> subscriber identification.  Then the HTTP filter can use the
> > >>> subscriber
> > >>> >> ID to decide which exact content filtering behavior it should
> > apply.
> > >>> I
> > >>> >> would not want to fold that level of detail into the chain=20
> > >>> >> identification.
> > >>> >>>
> > >>> >>> Yours,
> > >>> >>> Joel
> > >>> >>>
> > >>> >>> On 7/24/13 4:05 PM, Ron Parker wrote:
> > >>> >>>> Dave,
> > >>> >>>>
> > >>> >>>> I agree that the number of chains is unlikely to scale to=20
> > >>> >>>> vast
> > >>> >> numbers
> > >>> >>>> (i.e., millions).     And I agree that it is bounded from a
> > >>> >> practical
> > >>> >>>> business perspective, as you point out.
> > >>> >>>>
> > >>> >>>> You may already be on this page, but I wanted to point out=20
> > >>> >>>> a distinction of coarse-grained definition of a service=20
> > >>> >>>> function
> > vs.
> > >>> >> finer-grained
> > >>> >>>> definition of a service function.   Consider a service
> > function to
> > >>> >> be
> > >>> >>>> logical in such a way that the identity of the logical
> > function
> > >>> may
> > >>> >> also
> > >>> >>>> imply some differentiated behavior.   For example, a
> > conceptual
> > >>> >> function
> > >>> >>>> is HTTP content filtering.    This conceptual function can
> > then be
> > >>> >>>> further instantiated at the logical level based on=20
> > >>> >>>> differentiated policies such as content-filter-children,=20
> > >>> >>>> content-filter-adults-no-porn, content-filter-adults (I'm=20
> > >>> >>>> taking
> > >>> no
> > >>> >> stand on opt-in vs. opt-out, Mr.
> > >>> >>>> Cameron).   It may be that the same network element
> (dedicated
> > >>> >> physical
> > >>> >>>> box or virtual network function) realizes all 3 of the
> example
> > >>> >>>> policies.   The HTTP content filtering network function is
> > really
> > >>> 3
> > >>> >>>> logical network functions from the perspective of inclusion=20
> > >>> >>>> in a
> > >>> >> service
> > >>> >>>> chain.   Now extend this to multiple conceptual functions
> that
> > >>> >> utilize
> > >>> >>>> differentiated policies and the number of combinations will=20
> > >>> >>>> grow,
> > >>> at
> > >>> >>>> least modestly.
> > >>> >>>>
> > >>> >>>> Thanks,
> > >>> >>>>
> > >>> >>>> Ron
> > >>> >>>>
> > >>> >>>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]
> *On
> > >>> Behalf
> > >>> >>>> Of *David Allan I
> > >>> >>>> *Sent:* Wednesday, July 24, 2013 3:52 PM
> > >>> >>>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de;
> > nsc@ietf.org
> > >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> > >>> >>>>
> > >>> >>>> Saying functions will have a problem with something that
> > exists
> > >>> >>>> as
> > >>> a
> > >>> >>>> potential rationale for defining something new with exactly
> > the
> > >>> same
> > >>> >>>> properties and problems does not quite work for me....
> > >>> >>>>
> > >>> >>>> VLANs on a vNIC or multiple vNICs (depending on the
> > application
> > >>> >> stack
> > >>> >>>> construction and this being combined with application
> > >>> "cooperation"
> > >>> >>>> to preserve pairwise mappings of either VID/NIC tuples or=20
> > >>> >>>> simply
> > >>> >>>> NICs) currently exist as potential vehicles for preserving=20
> > >>> >>>> chain context and avoiding per hop classification. Anything=20
> > >>> >>>> else will be implemented more or less the same way and have=20
> > >>> >>>> exactly the same
> > >>> set
> > >>> >>>> of scaling and application design issues...Some extra=20
> > >>> >>>> information available on a single interface, or achieved by=20
> > >>> >>>> mapping chain instances onto one of a plurality of
> > interfaces....
> > >>> >>>>
> > >>> >>>> But to back up... I'm not a carrier employee but I cannot=20
> > >>> >>>> envision
> > >>> a
> > >>> >>>> carrier offering potentially 1000s of distinct service=20
> > >>> >>>> bundles
> > >>> >> ("pick
> > >>> >>>> 53 from column A and 49 from column B"). So I suspect a=20
> > >>> >>>> much
> > >>> smaller
> > >>> >>>> number is realistic for  the number of chains a function=20
> > >>> >>>> instance
> > >>> is
> > >>> >>>> expected to participate in, even allowing for dynamic=20
> > >>> >>>> reclassification of flows at a chain ingress to "skip a few=20
> > >>> >>>> functions".... These are things that are fully=20
> > >>> >>>> operationalized in OSS, have policy associated with, have=20
> > >>> >>>> been industrialized and demonstrated to work prior to=20
> > >>> >>>> deployment. Going all combinatorial
> > >>> on
> > >>> >> this will break that big time....
> > >>> >>>>
> > >>> >>>> So are we really discussing a function participating in=20
> > >>> >>>> more than
> > >>> a
> > >>> >>>> handful of chain instances? And either a plurality of vNICs=20
> > >>> >>>> or
> > >>> VIDs
> > >>> >>>> being actually more than sufficient?
> > >>> >>>>
> > >>> >>>> Thanks
> > >>> >>>>
> > >>> >>>> Dave
> > >>> >>>>
> > >>> >>>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> > >>> >>>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx,=20
> > >>> >>>> Wim
> > >>> >>>> (Wim)
> > >>> >>>> *Sent:* Wednesday, July 24, 2013 9:30 AM
> > >>> >>>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>;=20
> > >>> >>>> nsc@ietf.org <mailto:nsc@ietf.org>
> > >>> >>>> *Subject:* Re: [nsc] Service chaining architecture question
> > >>> >>>>
> > >>> >>>> indeed
> > >>> >>>>
> > >>> >>>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> > >>> >>>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> > >>> >>>> *Date: *Wednesday 24 July 2013 15:54
> > >>> >>>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> > >>> >>>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
> > >>> >>>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> > >>> >>>> *Subject: *AW: Service chaining architecture question
> > >>> >>>>
> > >>> >>>> Hi Wim,
> > >>> >>>>
> > >>> >>>> I think not only effectivness/scalability might be a=20
> > >>> >>>> problem but
> > >>> >> also
> > >>> >>>> the fact that not all applications (service bringing
> > functions)
> > >>> are
> > >>> >>>> able to handle packets coming from/going to potentially=20
> > >>> >>>> thousands
> > >>> of
> > >>> >>>> different VLANs at the same time. VLANs will work in=20
> > >>> >>>> certain environments but not in all. I see the need for an=20
> > >>> >>>> information exchange between the application and a=20
> > >>> >>>> mediation layer as
> > well.
> > >>> >>>> Ideally this should be as simple as possible without heavy=20
> > >>> >>>> impact
> > >>> on
> > >>> >>>> the application itself (might be difficult to achieve but=20
> > >>> >>>> from my experience it is not very likely, that there will=20
> > >>> >>>> be big rewrites
> > >>> of
> > >>> >>>> existing applications in order to support the chaining).
> > >>> >>>>
> > >>> >>>>    regards
> > >>> >>>>
> > >>> >>>>       Nic
> > >>> >>>>
> > >>> >>>> -----------------------------------------------------------
> > >>> >>>> -
> -
> > >>> >>>> -
> > -
> > >>> >>>> -
> > >>> >>>> --
> > >>> --
> > >>> >> -
> > >>> >>>> -
> > >>> >>>> --
> > >>> >>>>
> > >>> >>>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> > >>> >>>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx,=20
> > >>> >>>> Wim
> > >>> (Wim)
> > >>> >>>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> > >>> >>>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> > >>> >>>> *Betreff:* [nsc] Service chaining architecture question
> > >>> >>>>
> > >>> >>>> I have a basic question with respect to the=20
> > >>> >>>> architecture/framework
> > >>> >> so
> > >>> >>>> far mentioned in the drafts in NSC. I understand the=20
> > >>> >>>> meta-data is
> > >>> a
> > >>> >>>> mechanism to avoid multiple re-classifications when the=20
> > >>> >>>> packet
> > >>> >> enters
> > >>> >>>> the NSC domain and identifies the chain of service
> functions.
> > >>> >>>> Now
> > >>> my
> > >>> >>>> understanding is that the services/applications are unaware=20
> > >>> >>>> of the meta-data and that a layer underneath should provide=20
> > >>> >>>> the mediation and that we use a well defined interface to
> the
> > >>> application/service
> > >>> >>>> to indicate the chain. In the context of Cloud/enterprise
> > >>> >> environment
> > >>> >>>> I can see this work given you can use a dedicate VLAN e.g.
> > >>> >>>> within
> > >>> >> the tenant.
> > >>> >>>> However we also try to address residential use cases for
> > mobile
> > >>> and
> > >>> >>>> fixed and here this becomes more tricky afais. In the=20
> > >>> >>>> residential environment we can't expose a VLAN per=20
> > >>> >>>> application/service per
> > >>> chain
> > >>> >>>> since this would not be very effective. So I am wondering
> how
> > >>> >>>> we envision this to work?
> > >>> >>>>
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> _______________________________________________
> > >>> >>>> nsc mailing list
> > >>> >>>> nsc@ietf.org
> > >>> >>>>https://www.ietf.org/mailman/listinfo/nsc
> > >>> >>> _______________________________________________
> > >>> >>> nsc mailing list
> > >>> >>> nsc@ietf.org
> > >>> >>>https://www.ietf.org/mailman/listinfo/nsc
> > >>> >> _______________________________________________
> > >>> >> nsc mailing list
> > >>> >> nsc@ietf.org
> > >>> >>https://www.ietf.org/mailman/listinfo/nsc
> > >>> >
> > >>
> > >>
> > >> _______________________________________________
> > >> nsc mailing list
> > >> nsc@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/nsc
> > >>
> > >_______________________________________________
> > >nsc mailing list
> > >nsc@ietf.org
> > >https://www.ietf.org/mailman/listinfo/nsc
> > >_______________________________________________
> > >nsc mailing list
> > >nsc@ietf.org
> > >https://www.ietf.org/mailman/listinfo/nsc
> >
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc
> > _______________________________________________
> > nsc mailing list
> > nsc@ietf.org
> > https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc

From mn1921@att.com  Fri Jul 26 10:05:31 2013
Return-Path: <mn1921@att.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D1511E8119 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 10:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level: 
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BiEdHjv3vqo for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 10:05:25 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB9711E810E for <nsc@ietf.org>; Fri, 26 Jul 2013 10:05:24 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 45ca2f15.2aaaea636940.3699479.00-533.10179869.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 17:05:24 +0000 (UTC)
X-MXL-Hash: 51f2ac54474349d0-d9afa4996c2d8db43033661d16b6a125e7e3f3b2
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 05ca2f15.0.3699452.00-119.10179644.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>);  Fri, 26 Jul 2013 17:05:21 +0000 (UTC)
X-MXL-Hash: 51f2ac51195b32c7-31e74b8e291645d78fba52c82e11dd5c7ee5a00d
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QH5JPV023643; Fri, 26 Jul 2013 13:05:20 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6QH5EPY023558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 13:05:15 -0400
Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 26 Jul 2013 17:04:53 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0342.003; Fri, 26 Jul 2013 13:04:53 -0400
From: "NAPIERALA, MARIA H" <mn1921@att.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "<mohamed.boucadair@orange.com> " <mohamed.boucadair@orange.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgACwqwD//+/oYIAATDeAgAALhACAABT2gIAABD2AgAAA+wCAAAlhAIAABS4AgAAE8YCAAAFYAP//vmwQgAFcKwCAAUWNgIAAD++AgAAEvACAAAaegIAABf2AgAAFoYD//+sWUA==
Date: Fri, 26 Jul 2013 17:04:52 +0000
Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01208FD9@MISOUT7MSGUSR9I.ITServices.sbc.com>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D564B9@xmb-aln-x02.cisco.com>
In-Reply-To: <95067C434CE250468B77282634C96ED322D564B9@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.91.76.193]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <mn1921@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=-s3I2kwCOWQA:10 a=2DTnKp0c6ewA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=QNNNeoGkA4wA:10 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=AUd_NHdVAAAA:8 a=H6Ol4iAe9zAMzQEvsksA:9 a=wPNLvfGTeEIA:]
X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10]
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 17:05:31 -0000

Hi Carlos,

> That said, the main point is what follows:
>=20
> >
> > This is in a way a consequence of
> >> tying the metadata to the IP layer, instead of providing a way that
> is
> >> independent from it (and works equally in IPv4, IPv6, MPLS). Even
> within a
> >> controlled domain, there is performance in addition to just
> connectivity
> >> issues; there are also limitations in terms of processing (slow
> path) of

I am not sure what is the scope of the problem you are trying to solve.
Why do you mention MPLS in the context? What is the use case for this?
The immediate (and realistic) problem to be solved is chaining of "middlebo=
x" functions.
And it is needed "tomorrow" not 5 years from now ;-)
The only examples (in the e-mails sent) were firewall, ADC, HTTP
proxy.. These functions operate on IP packets.



> >> optioned packets, potential inability to be deterministic with ECMP,
> and
> >> like Jim said firewalls. If for example dataplane performance, load-
> >> balancing and cross-domain chains are requirements, certainly these
> need to
> >> be considered.

The service/middlebox functions operate in software today. I am not
sure why you worry about "slow path"..=20
In fact, DC-WAN GW also operates at the edge of a network and maybe very we=
ll implemented in software.


> Additionally, draft-ietf-opsec-ip-options-filtering might be of some
> interest, in particular the Intro.
>=20
> Thanks,
>=20
> -- Carlos.
>=20
> >> Thanks,
> >>
> >> -- Carlos.
> >>
> >> On Jul 26, 2013, at 9:05 AM, <mohamed.boucadair@orange.com>
> >> wrote:
> >>
> >>> Re-,
> >>>
> >>> I guess you are talking about unknown IP options in general. If a
> new
> >> option is to be defined for what we are discussing here, these
> firewalls
> >> will need to be updated. This is not a problem at all.
> >>>
> >>> Unlike the proposals for which the new IP option is to be carried
> over
> >> internet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2),
> the
> >> chaining case is restricted to a network segment managed by the same
> >> administrative entity.
> >>>
> >>> I'm not trying to advocate for the use an IP option but the point
> is it
> >> is early to decide which channel is viable or not.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
> >>>> Envoy=E9 : vendredi 26 juillet 2013 14:49
> >>>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA,
> MARIA H
> >>>> Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
> >>>> Objet : Re: [nsc] Service chaining architecture question
> >>>>
> >>>> Hi Med,
> >>>>
> >>>> On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
> >>>> <mohamed.boucadair@orange.com> wrote:
> >>>>
> >>>>>>
> >>>>>> Adding data to existing IP headers might not prove viable, most
> fields
> >>>>>> are
> >>>>>> either spoken for, or have significant technical limitations.
> For
> >>>>>> example,
> >>>>>> IP options are usually filtered/dropped
> >>>>>
> >>>>> [Med] This is not a valid argument for the chaining case. This
> >> limitation
> >>>>> would be a no starting point if the chaining procedure is to be
> >> activated
> >>>>> at the level of Internet...which is not the case here. The
> solution
> >> will
> >>>>> be enabled in a controlled environment, and as such, introducing
> a new
> >> IP
> >>>>> option, IPv6 extension header, should be part of the viable
> solutions.
> >> It
> >>>>> is too early at this stage to exclude any candidate channel to
> convey
> >> the
> >>>>> marking bits.
> >>>>
> >>>> Jim> even in a controlled environment by using IP options you may
> >> prevent
> >>>> cross-domain chaining and at the very least prevent firewalls
> being part
> >>>> of the chain; every firewall I know about will drop packets
> containing
> >> IP
> >>>> options.
> >>>>
> >>>>>
> >>>
> >>> _______________________________________________
> >>> nsc mailing list
> >>> nsc@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/nsc
> >


From cpignata@cisco.com  Fri Jul 26 11:10:46 2013
Return-Path: <cpignata@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661BC11E812F for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 11:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxKJK2BIXP3k for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 11:10:41 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 394BF11E812C for <nsc@ietf.org>; Fri, 26 Jul 2013 11:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5561; q=dns/txt; s=iport; t=1374862241; x=1376071841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iP5mGl9GmTZw4UsehfYsAnnkShm1uKu41cWOoAQRT4Y=; b=dhPIp9Oo/SSlJFnoXTf5fAT9W+Vcsi7guUiMHnShe3e3vCfBogD+ldg7 ycNX88Obu8W4mIWEoUigrQr93A+6WywBKafecl94jnqQsTyfErFUb+Gmu nIvXypTbu2aFmIfnYN08gSLp8+wksp1tQCf2N25ZavQOSbqWgZBlYtTip Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAFa68lGtJV2Z/2dsb2JhbABbgwY1UL1egRkWdIIkAQEBAwEBAQELVwIHBgUFCwIBCBIGCh0HJwsUAw4CBA4FCBOHbwYMuF2PSgIxB4MWbwOIcpAWiQmHGoMUgio
X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="236978015"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jul 2013 18:10:40 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6QIAewt029083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 18:10:40 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 13:10:40 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADBbwCAADh1AIAAA6qAgAALhACAABT1gP//sGyCgABUzQCAAAlhAIAABS0AgAAE8YCAAAFZAIAAA28AgAEXKACAAUWMgP//zN4A///xbrAAC5+oAAAKRlFQ//+5a4CAADChAIAAEmGA
Date: Fri, 26 Jul 2013 18:10:39 +0000
Message-ID: <95067C434CE250468B77282634C96ED322D58471@xmb-aln-x02.cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D564B9@xmb-aln-x02.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01208FD9@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01208FD9@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.115.56]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B927836D2225744BAB44915F4FE3BA69@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "<mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2013 18:10:46 -0000

Hi, Maria,

On Jul 26, 2013, at 1:04 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

> Hi Carlos,
>=20
>> That said, the main point is what follows:
>>=20
>>>=20
>>> This is in a way a consequence of
>>>> tying the metadata to the IP layer, instead of providing a way that
>> is
>>>> independent from it (and works equally in IPv4, IPv6, MPLS). Even
>> within a
>>>> controlled domain, there is performance in addition to just
>> connectivity
>>>> issues; there are also limitations in terms of processing (slow
>> path) of
>=20
> I am not sure what is the scope of the problem you are trying to solve.
> Why do you mention MPLS in the context? What is the use case for this?
> The immediate (and realistic) problem to be solved is chaining of "middle=
box" functions.
> And it is needed "tomorrow" not 5 years from now ;-)
> The only examples (in the e-mails sent) were firewall, ADC, HTTP
> proxy.. These functions operate on IP packets.
>=20

My comments are in the context of the same problem space and scope, trying =
to also balance the least intrusive way with transport independence, and fu=
ture extensibility.

Apologies if I was not clear before, let me try to further clarify:

The service function chaining creates a service overlay logical topology. T=
his service overlay is, as a goal, independent of the network topology -- t=
his independence allows for versatility in selecting the underlay technolog=
y. Using IP options essentially leaks the metadata into the transport, tyin=
g them together. Given that the service is metadata aware, a corollary goal=
 is to not ripple this down to the transport.


>=20
>=20
>>>> optioned packets, potential inability to be deterministic with ECMP,
>> and
>>>> like Jim said firewalls. If for example dataplane performance, load-
>>>> balancing and cross-domain chains are requirements, certainly these
>> need to
>>>> be considered.
>=20
> The service/middlebox functions operate in software today. I am not
> sure why you worry about "slow path"..=20
> In fact, DC-WAN GW also operates at the edge of a network and maybe very =
well implemented in software.
>=20
>=20

The challenge is what happens in the forwarding between service functions i=
n a chain. One of the goals of having the service overlay topologically ind=
ependent from the transport is that the forwarding does not change in the n=
etwork topology. One of the problems is that utilizing options changes the =
forwarding in nodes that are not service-aware. In other words, the network=
 does not only forward unchanged encapsulated packets between service nodes=
.

Thanks,

-- Carlos.

>> Additionally, draft-ietf-opsec-ip-options-filtering might be of some
>> interest, in particular the Intro.
>>=20
>> Thanks,
>>=20
>> -- Carlos.
>>=20
>>>> Thanks,
>>>>=20
>>>> -- Carlos.
>>>>=20
>>>> On Jul 26, 2013, at 9:05 AM, <mohamed.boucadair@orange.com>
>>>> wrote:
>>>>=20
>>>>> Re-,
>>>>>=20
>>>>> I guess you are talking about unknown IP options in general. If a
>> new
>>>> option is to be defined for what we are discussing here, these
>> firewalls
>>>> will need to be updated. This is not a problem at all.
>>>>>=20
>>>>> Unlike the proposals for which the new IP option is to be carried
>> over
>>>> internet (e.g., http://tools.ietf.org/html/rfc6967#section-4.2.2),
>> the
>>>> chaining case is restricted to a network segment managed by the same
>>>> administrative entity.
>>>>>=20
>>>>> I'm not trying to advocate for the use an IP option but the point
>> is it
>>>> is early to decide which channel is viable or not.
>>>>>=20
>>>>> Cheers,
>>>>> Med
>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>>>>> Envoy=E9 : vendredi 26 juillet 2013 14:49
>>>>>> =C0 : BOUCADAIR Mohamed OLNC/OLN; Paul Quinn (paulq); NAPIERALA,
>> MARIA H
>>>>>> Cc : nsc@ietf.org; Joel M. Halpern; Ron Parker; Linda Dunbar
>>>>>> Objet : Re: [nsc] Service chaining architecture question
>>>>>>=20
>>>>>> Hi Med,
>>>>>>=20
>>>>>> On 7/26/13 7:51 AM, "mohamed.boucadair@orange.com"
>>>>>> <mohamed.boucadair@orange.com> wrote:
>>>>>>=20
>>>>>>>>=20
>>>>>>>> Adding data to existing IP headers might not prove viable, most
>> fields
>>>>>>>> are
>>>>>>>> either spoken for, or have significant technical limitations.
>> For
>>>>>>>> example,
>>>>>>>> IP options are usually filtered/dropped
>>>>>>>=20
>>>>>>> [Med] This is not a valid argument for the chaining case. This
>>>> limitation
>>>>>>> would be a no starting point if the chaining procedure is to be
>>>> activated
>>>>>>> at the level of Internet...which is not the case here. The
>> solution
>>>> will
>>>>>>> be enabled in a controlled environment, and as such, introducing
>> a new
>>>> IP
>>>>>>> option, IPv6 extension header, should be part of the viable
>> solutions.
>>>> It
>>>>>>> is too early at this stage to exclude any candidate channel to
>> convey
>>>> the
>>>>>>> marking bits.
>>>>>>=20
>>>>>> Jim> even in a controlled environment by using IP options you may
>>>> prevent
>>>>>> cross-domain chaining and at the very least prevent firewalls
>> being part
>>>>>> of the chain; every firewall I know about will drop packets
>> containing
>>>> IP
>>>>>> options.
>>>>>>=20
>>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> nsc mailing list
>>>>> nsc@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/nsc
>>>=20
>=20


From jiangyuanlong@huawei.com  Fri Jul 26 23:30:36 2013
Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8EA21F90FB for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 23:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gne61SpqtgK8 for <nsc@ietfa.amsl.com>; Fri, 26 Jul 2013 23:30:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C44F21F9034 for <nsc@ietf.org>; Fri, 26 Jul 2013 23:30:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATV37911; Sat, 27 Jul 2013 06:30:27 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 27 Jul 2013 07:30:24 +0100
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 27 Jul 2013 07:30:24 +0100
Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.53]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Sat, 27 Jul 2013 14:30:13 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "N.Leymann@telekom.de" <N.Leymann@telekom.de>, "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TA///ngQCAADh1AIAAA6qAgARTWCA=
Date: Sat, 27 Jul 2013 06:30:12 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D4E@szxeml546-mbx.china.huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.76.118]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D4Eszxeml546mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jul 2013 06:30:36 -0000

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D4Eszxeml546mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ron and all,

I agree that HTTP content filtering is a very valid use case. Though I have=
 a different opinion on the following statement "The HTTP content filtering=
 network function is really 3 logical network functions from the perspectiv=
e of inclusion in a service chain." Actually a subscriber cannot be applied=
 with all these 3 functions at the same time - he may be either a child or =
an adult, but not both :)
IMHO, HTTP content filtering network function (NF) can be implemented as on=
e single logical network function with different profiles ( maybe each acco=
mmodated with a different filtering database), and 3 different service chai=
ns may share this NF, thus service chain ID  is enough for this NF to apply=
 different profiles on packets on different service chains.
Section 3.4 of draft-liu-service-chaining-use-cases-00 covers this kind of =
multiplexing on NFs, maybe you can have a look at it.

My 2 cents,
Best regards,
Yuanlong

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P=
arker
Sent: Thursday, July 25, 2013 4:05 AM
To: David Allan I; Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.or=
g
Subject: Re: [nsc] Service chaining architecture question

Dave,

I agree that the number of chains is unlikely to scale to vast numbers (i.e=
., millions).     And I agree that it is bounded from a practical business =
perspective, as you point out.

You may already be on this page, but I wanted to point out a distinction of=
 coarse-grained definition of a service function vs. finer-grained definiti=
on of a service function.   Consider a service function to be logical in su=
ch a way that the identity of the logical function may also imply some diff=
erentiated behavior.   For example, a conceptual function is HTTP content f=
iltering.    This conceptual function can then be further instantiated at t=
he logical level based on differentiated policies such as content-filter-ch=
ildren, content-filter-adults-no-porn, content-filter-adults (I'm taking no=
 stand on opt-in vs. opt-out, Mr. Cameron).   It may be that the same netwo=
rk element (dedicated physical box or virtual network function) realizes al=
l 3 of the example policies.   The HTTP content filtering network function =
is really 3 logical network functions from the perspective of inclusion in =
a service chain.   Now extend this to multiple conceptual functions that ut=
ilize differentiated policies and the number of combinations will grow, at =
least modestly.

Thanks,
Ron


From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David=
 Allan I
Sent: Wednesday, July 24, 2013 3:52 PM
To: Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Saying functions will have a problem with something that exists as a potent=
ial rationale for defining something new with exactly the same properties a=
nd problems does not quite work for me....

VLANs on a vNIC or multiple vNICs (depending on the application stack const=
ruction and this being combined with application "cooperation" to preserve =
pairwise mappings of either VID/NIC tuples or simply NICs) currently exist =
as potential vehicles for preserving chain context and avoiding per hop cla=
ssification. Anything else will be implemented more or less the same way an=
d have exactly the same set of scaling and application design issues...Some=
 extra information available on a single interface, or achieved by mapping =
chain instances onto one of a plurality of interfaces....

But to back up... I'm not a carrier employee but I cannot envision a carrie=
r offering potentially 1000s of distinct service bundles ("pick 53 from col=
umn A and 49 from column B"). So I suspect a much smaller number is realist=
ic for  the number of chains a function instance is expected to participate=
 in, even allowing for dynamic reclassification of flows at a chain ingress=
 to "skip a few functions".... These are things that are fully operationali=
zed in OSS, have policy associated with, have been industrialized and demon=
strated to work prior to deployment. Going all combinatorial on this will b=
reak that big time....

So are we really discussing a function participating in more than a handful=
 of chain instances? And either a plurality of vNICs or VIDs being actually=
 more than sufficient?

Thanks
Dave

From: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces=
@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 24, 2013 9:30 AM
To: N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>; nsc@ietf.org<mailto:=
nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question

indeed

From: "N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>" <N.Leymann@teleko=
m.de<mailto:N.Leymann@telekom.de>>
Date: Wednesday 24 July 2013 15:54
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx=
@alcatel-lucent.com>>, "nsc@ietf.org<mailto:nsc@ietf.org>" <nsc@ietf.org<ma=
ilto:nsc@ietf.org>>
Subject: AW: Service chaining architecture question

Hi Wim,

I think not only effectivness/scalability might be a problem but also the f=
act that not all applications (service bringing functions) are able to hand=
le packets coming from/going to potentially thousands of different VLANs at=
 the same time. VLANs will work in certain environments but not in all. I s=
ee the need for an information exchange between the application and a media=
tion layer as well. Ideally this should be as simple as possible without he=
avy impact on the application itself (might be difficult to achieve but fro=
m my experience it is not very likely, that there will be big rewrites of e=
xisting applications in order to support the chaining).

  regards

     Nic

________________________________
Von: nsc-bounces@ietf.org<mailto:nsc-bounces@ietf.org> [mailto:nsc-bounces@=
ietf.org] Im Auftrag von Henderickx, Wim (Wim)
Gesendet: Mittwoch, 24. Juli 2013 11:52
An: nsc@ietf.org<mailto:nsc@ietf.org>
Betreff: [nsc] Service chaining architecture question
I have a basic question with respect to the architecture/framework so far m=
entioned in the drafts in NSC. I understand the meta-data is a mechanism to=
 avoid multiple re-classifications when the packet enters the NSC domain an=
d identifies the chain of service functions. Now my understanding is that t=
he services/applications are unaware of the meta-data and that a layer unde=
rneath should provide the mediation and that we use a well defined interfac=
e to the application/service to indicate the chain. In the context of Cloud=
/enterprise environment I can see this work given you can use a dedicate VL=
AN e.g. within the tenant. However we also try to address residential use c=
ases for mobile and fixed and here this becomes more tricky afais. In the r=
esidential environment we can't expose a VLAN per application/service per c=
hain since this would not be very effective. So I am wondering how we envis=
ion this to work?

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D4Eszxeml546mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"\6279\6CE8\6846\6587\672C Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.Char
	{mso-style-name:"\6279\6CE8\6846\6587\672C Char";
	mso-style-priority:99;
	mso-style-link:\6279\6CE8\6846\6587\672C;
	font-family:SimSun;}
p.BalloonText, li.BalloonText, div.BalloonText
	{mso-style-name:"Balloon Text";
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Ron and=
 all,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree th=
at
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">HTTP content filtering is =
a very valid use case. Though I have a different opinion on the following s=
tatement &#8220;The HTTP content filtering network function is
 really 3 logical network functions from the perspective of inclusion in a =
service chain.&#8221; Actually a subscriber cannot be applied with all thes=
e 3 functions at the same time &#8211; he may be either a child or an adult=
, but not both
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:Wingdings=
;color:#1F497D">J</span><span lang=3D"EN-US" style=3D"font-size:11.0pt;font=
-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">IMHO, HTTP=
 content filtering network function (NF) can be implemented as one single l=
ogical network function with different profiles ( maybe each
 accommodated with a different filtering database), and 3 different service=
 chains may share this NF, thus service chain ID&nbsp; is enough for this N=
F to apply different profiles on packets on different service chains.<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Section 3.=
4 of draft-liu-service-chaining-use-cases-00 covers this kind of multiplexi=
ng on NFs, maybe you can have a look at it.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">My 2 cents=
,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regar=
ds,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yuanlong<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>Ron Parker<br>
<b>Sent:</b> Thursday, July 25, 2013 4:05 AM<br>
<b>To:</b> David Allan I; Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@=
ietf.org<br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave,<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree th=
at the number of chains is unlikely to scale to vast numbers (i.e., million=
s).&nbsp;&nbsp; &nbsp;&nbsp;And I agree that it is bounded from a practical=
 business
 perspective, as you point out.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">You may al=
ready be on this page, but I wanted to point out a distinction of coarse-gr=
ained definition of a service function vs. finer-grained definition
 of a service function. &nbsp;&nbsp;Consider a service function to be logic=
al in such a way that the identity of the logical function may also imply s=
ome differentiated behavior.&nbsp;&nbsp; For example, a conceptual function=
 is HTTP content filtering.&nbsp;&nbsp; &nbsp;This conceptual function
 can then be further instantiated at the logical level based on differentia=
ted policies such as content-filter-children, content-filter-adults-no-porn=
, content-filter-adults (I&#8217;m taking no stand on opt-in vs. opt-out, M=
r. Cameron).&nbsp;&nbsp; It may be that the same
 network element (dedicated physical box or virtual network function) reali=
zes all 3 of the example policies.&nbsp;&nbsp; The HTTP content filtering n=
etwork function is really 3 logical network functions from the perspective =
of inclusion in a service chain.&nbsp;&nbsp; Now extend
 this to multiple conceptual functions that utilize differentiated policies=
 and the number of combinations will grow, at least modestly.<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ron<o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]
<b>On Behalf Of </b>David Allan I<br>
<b>Sent:</b> Wednesday, July 24, 2013 3:52 PM<br>
<b>To:</b> Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org<br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Saying fun=
ctions will have a problem with something that exists as a potential ration=
ale for defining something new with exactly the same properties
 and problems does not quite work for me&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">VLANs on a=
 vNIC or multiple vNICs (depending on the application stack construction an=
d this being combined with application &#8220;cooperation&#8221; to preserv=
e
 pairwise mappings of either VID/NIC tuples or simply NICs) currently exist=
 as potential vehicles for preserving chain context and avoiding per hop cl=
assification. Anything else will be implemented more or less the same way a=
nd have exactly the same set of
 scaling and application design issues&#8230;Some extra information availab=
le on a single interface, or achieved by mapping chain instances onto one o=
f a plurality of interfaces&#8230;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">But to bac=
k up&#8230; I&#8217;m not a carrier employee but I cannot envision a carrie=
r offering potentially 1000s of distinct service bundles (&#8220;pick 53 fr=
om
 column A and 49 from column B&#8221;). So I suspect a much smaller number =
is realistic for &nbsp;the number of chains a function instance is expected=
 to participate in, even allowing for dynamic reclassification of flows at =
a chain ingress to &#8220;skip a few functions&#8221;&#8230;.
 These are things that are fully operationalized in OSS, have policy associ=
ated with, have been industrialized and demonstrated to work prior to deplo=
yment. Going all combinatorial on this will break that big time&#8230;.<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">So are we =
really discussing a function participating in more than a handful of chain =
instances? And either a plurality of vNICs or VIDs being actually
 more than sufficient?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dave<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Henderickx, Wim (Wim)<br>
<b>Sent:</b> Wednesday, July 24, 2013 9:30 AM<br>
<b>To:</b> <a href=3D"mailto:N.Leymann@telekom.de">N.Leymann@telekom.de</a>=
; <a href=3D"mailto:nsc@ietf.org">
nsc@ietf.org</a><br>
<b>Subject:</b> Re: [nsc] Service chaining architecture question<o:p></o:p>=
</span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">indeed<o:p><=
/o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;<=
/o:p></span></p>
</div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo=
nt-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:black">&quot;<a href=3D"mailto:=
N.Leymann@telekom.de">N.Leymann@telekom.de</a>&quot; &lt;<a href=3D"mailto:=
N.Leymann@telekom.de">N.Leymann@telekom.de</a>&gt;<br>
<b>Date: </b>Wednesday 24 July 2013 15:54<br>
<b>To: </b>Wim Henderickx &lt;<a href=3D"mailto:wim.henderickx@alcatel-luce=
nt.com">wim.henderickx@alcatel-lucent.com</a>&gt;, &quot;<a href=3D"mailto:=
nsc@ietf.org">nsc@ietf.org</a>&quot; &lt;<a href=3D"mailto:nsc@ietf.org">ns=
c@ietf.org</a>&gt;<br>
<b>Subject: </b>AW: Service chaining architecture question<o:p></o:p></span=
></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;<=
/o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Hi Wim,</spa=
n><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calibri&=
quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">I think not =
only effectivness/scalability might be a problem but also the fact that not=
 all applications (service bringing functions) are able to
 handle packets coming from/going to&nbsp;potentially thousands of differen=
t VLANs at the same time. VLANs will work in certain environments but not i=
n all. I see the need for an information exchange between the application a=
nd a mediation layer as well. Ideally
 this should be as simple as possible without heavy impact on the applicati=
on itself (might be difficult to achieve but from my experience it is not v=
ery likely, that there will be big rewrites of existing applications in ord=
er to support the chaining).</span><span lang=3D"EN-US" style=3D"font-size:=
10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp; regar=
ds</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;=
&nbsp;&nbsp; Nic</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;<o:p><=
/o:p></span></p>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span=
 lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;;color:black">
<hr size=3D"2" width=3D"100%" align=3D"center">
</span></div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span lang=3D"EN-U=
S" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-seri=
f&quot;;color:black">Von:</span></b><span lang=3D"EN-US" style=3D"font-size=
:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black">
<a href=3D"mailto:nsc-bounces@ietf.org">nsc-bounces@ietf.org</a> [<a href=
=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org</a>]
<b>Im Auftrag von </b>Henderickx, Wim (Wim)<br>
<b>Gesendet:</b> Mittwoch, 24. Juli 2013 11:52<br>
<b>An:</b> <a href=3D"mailto:nsc@ietf.org">nsc@ietf.org</a><br>
<b>Betreff:</b> [nsc] Service chaining architecture question</span><span la=
ng=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">I have a bas=
ic question with respect to the architecture/framework so far mentioned in =
the drafts in NSC. I understand the meta-data is a mechanism
 to avoid multiple re-classifications when the packet enters the NSC domain=
 and identifies the chain of service functions. Now my understanding is tha=
t the services/applications are unaware of the meta-data and that a layer u=
nderneath should provide the mediation
 and that we use a well defined interface to the application/service to ind=
icate the chain. In the context of Cloud/enterprise environment I can see t=
his work given you can use a dedicate VLAN e.g. within the tenant. However =
we also try to address residential
 use cases for mobile and fixed and here this becomes more tricky afais.&nb=
sp;In the residential environment we can't expose a VLAN per application/se=
rvice per chain since this would not be very effective. So I am wondering h=
ow we envision this to work?<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D4Eszxeml546mbxchi_--

From jiangyuanlong@huawei.com  Sat Jul 27 00:08:02 2013
Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A379E11E80D3 for <nsc@ietfa.amsl.com>; Sat, 27 Jul 2013 00:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJMLyB3oqyMj for <nsc@ietfa.amsl.com>; Sat, 27 Jul 2013 00:07:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F98C11E80AD for <nsc@ietf.org>; Sat, 27 Jul 2013 00:07:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVL86764; Sat, 27 Jul 2013 07:07:55 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 27 Jul 2013 08:07:52 +0100
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 27 Jul 2013 08:07:51 +0100
Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.53]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Sat, 27 Jul 2013 15:07:42 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TA///ngQCAADh1AIAAA6qAgAALhACAABT1gIAEOmCA
Date: Sat, 27 Jul 2013 07:07:41 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D86@szxeml546-mbx.china.huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local>
In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.76.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jul 2013 07:08:02 -0000

Hi Ron & Joel,

Implementing HTTP-filter with multiple logical NFs is definitely another op=
tion and I agree that service chain ID is enough to work this way.
But I noticed that you restricted it to "IP-addressable server", is router/=
switches intended to be out of your consideration?

Regards,
Yuanlong


-----Original Message-----
From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P=
arker
Sent: Thursday, July 25, 2013 6:02 AM
To: Joel M. Halpern
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Joel,

IMO, the primary reason for understanding the subscriber identity at a netw=
ork service is to choose from a differentiated set of policies.    I think =
there is utility and efficiency in driving that selection from one place --=
 the network services classifier.     Say there were 2 groups of subscriber=
s -- children and adults.   Let's now define 2 chains, where the chains hav=
e a business-based meaning to the operator.    Chain 1 =3D HTTP-filter-chil=
d + Firewall-child.   Chain 2 =3D HTTP-filter-adult + Firewall-adult.    Th=
e referenced network services are logical and it is possible, but not requi=
red, that multiple logical network services be located at the same IP addre=
ss or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID, G=
RE key, NSH chain ID, ...) allows the IP-addressable server that realizes t=
hese service(s) to know two things -- 1) which logical network function sho=
uld be invoked and 2) which logical network function is next.=20

Thanks.
Ron

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20
Sent: Wednesday, July 24, 2013 4:47 PM
To: Ron Parker
Cc: nsc@ietf.org
Subject: Re: [nsc] Service chaining architecture question

Ron,
     maybe I am missing something, but you seem to lay out very nicely the =
case for wanting both service chain identification and separately subscribe=
r identification.  Then the HTTP filter can use the subscriber ID to decide=
 which exact content filtering behavior it should apply.  I would not want =
to fold that level of detail into the chain identification.

Yours,
Joel

On 7/24/13 4:05 PM, Ron Parker wrote:
> Dave,
>
> I agree that the number of chains is unlikely to scale to vast numbers
> (i.e., millions).     And I agree that it is bounded from a practical
> business perspective, as you point out.
>
> You may already be on this page, but I wanted to point out a=20
> distinction of coarse-grained definition of a service function vs. finer-=
grained
> definition of a service function.   Consider a service function to be
> logical in such a way that the identity of the logical function may also
> imply some differentiated behavior.   For example, a conceptual function
> is HTTP content filtering.    This conceptual function can then be
> further instantiated at the logical level based on differentiated=20
> policies such as content-filter-children,=20
> content-filter-adults-no-porn, content-filter-adults (I'm taking no stand=
 on opt-in vs. opt-out, Mr.
> Cameron).   It may be that the same network element (dedicated physical
> box or virtual network function) realizes all 3 of the example
> policies.   The HTTP content filtering network function is really 3
> logical network functions from the perspective of inclusion in a service
> chain.   Now extend this to multiple conceptual functions that utilize
> differentiated policies and the number of combinations will grow, at=20
> least modestly.
>
> Thanks,
>
> Ron
>
> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf=20
> Of *David Allan I
> *Sent:* Wednesday, July 24, 2013 3:52 PM
> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
> *Subject:* Re: [nsc] Service chaining architecture question
>
> Saying functions will have a problem with something that exists as a=20
> potential rationale for defining something new with exactly the same=20
> properties and problems does not quite work for me....
>
> VLANs on a vNIC or multiple vNICs (depending on the application stack=20
> construction and this being combined with application "cooperation" to=20
> preserve pairwise mappings of either VID/NIC tuples or simply NICs)=20
> currently exist as potential vehicles for preserving chain context and=20
> avoiding per hop classification. Anything else will be implemented=20
> more or less the same way and have exactly the same set of scaling and=20
> application design issues...Some extra information available on a single=
=20
> interface, or achieved by mapping chain instances onto one of a=20
> plurality of interfaces....
>
> But to back up... I'm not a carrier employee but I cannot envision a=20
> carrier offering potentially 1000s of distinct service bundles ("pick=20
> 53 from column A and 49 from column B"). So I suspect a much smaller=20
> number is realistic for  the number of chains a function instance is=20
> expected to participate in, even allowing for dynamic reclassification=20
> of flows at a chain ingress to "skip a few functions".... These are=20
> things that are fully operationalized in OSS, have policy associated=20
> with, have been industrialized and demonstrated to work prior to=20
> deployment. Going all combinatorial on this will break that big time....
>
> So are we really discussing a function participating in more than a=20
> handful of chain instances? And either a plurality of vNICs or VIDs=20
> being actually more than sufficient?
>
> Thanks
>
> Dave
>
> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
> *Sent:* Wednesday, July 24, 2013 9:30 AM
> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>; nsc@ietf.org=20
> <mailto:nsc@ietf.org>
> *Subject:* Re: [nsc] Service chaining architecture question
>
> indeed
>
> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
> *Date: *Wednesday 24 July 2013 15:54
> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org=20
> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
> *Subject: *AW: Service chaining architecture question
>
> Hi Wim,
>
> I think not only effectivness/scalability might be a problem but also=20
> the fact that not all applications (service bringing functions) are=20
> able to handle packets coming from/going to potentially thousands of=20
> different VLANs at the same time. VLANs will work in certain=20
> environments but not in all. I see the need for an information=20
> exchange between the application and a mediation layer as well.=20
> Ideally this should be as simple as possible without heavy impact on=20
> the application itself (might be difficult to achieve but from my=20
> experience it is not very likely, that there will be big rewrites of=20
> existing applications in order to support the chaining).
>
>    regards
>
>       Nic
>
> ----------------------------------------------------------------------
> --
>
> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>=20
> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
> *Betreff:* [nsc] Service chaining architecture question
>
> I have a basic question with respect to the architecture/framework so=20
> far mentioned in the drafts in NSC. I understand the meta-data is a=20
> mechanism to avoid multiple re-classifications when the packet enters=20
> the NSC domain and identifies the chain of service functions. Now my=20
> understanding is that the services/applications are unaware of the=20
> meta-data and that a layer underneath should provide the mediation and=20
> that we use a well defined interface to the application/service to=20
> indicate the chain. In the context of Cloud/enterprise environment I=20
> can see this work given you can use a dedicate VLAN e.g. within the tenan=
t.
> However we also try to address residential use cases for mobile and=20
> fixed and here this becomes more tricky afais. In the residential=20
> environment we can't expose a VLAN per application/service per chain=20
> since this would not be very effective. So I am wondering how we=20
> envision this to work?
>
>
>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

From jmh@joelhalpern.com  Sat Jul 27 01:21:59 2013
Return-Path: <jmh@joelhalpern.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF1121F9DB0 for <nsc@ietfa.amsl.com>; Sat, 27 Jul 2013 01:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZcpOEDSNW4B for <nsc@ietfa.amsl.com>; Sat, 27 Jul 2013 01:21:54 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA0321F9D65 for <nsc@ietf.org>; Sat, 27 Jul 2013 01:21:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 88D4C1C5B76; Sat, 27 Jul 2013 01:21:49 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from dhcp-427a.meeting.ietf.org (dhcp-427a.meeting.ietf.org [130.129.66.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8CAB61C056C; Sat, 27 Jul 2013 01:21:48 -0700 (PDT)
Message-ID: <51F3831A.7010607@joelhalpern.com>
Date: Sat, 27 Jul 2013 04:21:46 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Jiangyuanlong <jiangyuanlong@huawei.com>
References: <9762ACF04FA26B4388476841256BDE02011ADFB8CDBE@HE111543.emea1.cds.t-internal.com> <CE15CDAA.6A243%wim.henderickx@alcatel-lucent.com> <E6C17D2345AC7A45B7D054D407AA205C115D649B@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E167@MBX021-W3-CA-2.exch021.domain.local> <51F03D30.4020401@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A67E250@MBX021-W3-CA-2.exch021.domain.local> <3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D86@szxeml546-mbx.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B4FFF5D86@szxeml546-mbx.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "nsc@ietf.org" <nsc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jul 2013 08:21:59 -0000

In order to have flexible service chaining, it seems necessary that one 
have network infrastructure supporting the network service delivery agents.

One could argue that we only need ethernet switches for that.  As has 
been pointed out several times in this discussion, there are clearly 
cases where one will want IP forwarding in support of service chains.

Thus, I expect to treat forwarding, at both the IP and Ethernet layers, 
as a capability the network delivers to the service chaining, rather 
than as a network resident value added service.

Yours,
Joel:

PS: Note that this aspect is about the structure of the data plane. 
Network Service Chaining should function whether the network elements 
are devices with integrated control or split architecture (OpeNflow, 
ForCES, GSMP, ...) components.  It shoudl also work whether the policies 
are expressed to the network with conventional network management, with 
I2RS protocols, or with other means.

On 7/27/13 3:07 AM, Jiangyuanlong wrote:
> Hi Ron & Joel,
>
> Implementing HTTP-filter with multiple logical NFs is definitely another option and I agree that service chain ID is enough to work this way.
> But I noticed that you restricted it to "IP-addressable server", is router/switches intended to be out of your consideration?
>
> Regards,
> Yuanlong
>
>
> -----Original Message-----
> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker
> Sent: Thursday, July 25, 2013 6:02 AM
> To: Joel M. Halpern
> Cc: nsc@ietf.org
> Subject: Re: [nsc] Service chaining architecture question
>
> Joel,
>
> IMO, the primary reason for understanding the subscriber identity at a network service is to choose from a differentiated set of policies.    I think there is utility and efficiency in driving that selection from one place -- the network services classifier.     Say there were 2 groups of subscribers -- children and adults.   Let's now define 2 chains, where the chains have a business-based meaning to the operator.    Chain 1 = HTTP-filter-child + Firewall-child.   Chain 2 = HTTP-filter-adult + Firewall-adult.    The referenced network services are logical and it is possible, but not required, that multiple logical network services be located at the same IP address or FQDN.     Conveying the actual chain ID on the wire (i.e., VLAN ID, GRE key, NSH chain ID, ...) allows the IP-addressable server that realizes these service(s) to know two things -- 1) which logical network function should be invoked and 2) which logical network function is next.
>
> Thanks.
> Ron
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Wednesday, July 24, 2013 4:47 PM
> To: Ron Parker
> Cc: nsc@ietf.org
> Subject: Re: [nsc] Service chaining architecture question
>
> Ron,
>       maybe I am missing something, but you seem to lay out very nicely the case for wanting both service chain identification and separately subscriber identification.  Then the HTTP filter can use the subscriber ID to decide which exact content filtering behavior it should apply.  I would not want to fold that level of detail into the chain identification.
>
> Yours,
> Joel
>
> On 7/24/13 4:05 PM, Ron Parker wrote:
>> Dave,
>>
>> I agree that the number of chains is unlikely to scale to vast numbers
>> (i.e., millions).     And I agree that it is bounded from a practical
>> business perspective, as you point out.
>>
>> You may already be on this page, but I wanted to point out a
>> distinction of coarse-grained definition of a service function vs. finer-grained
>> definition of a service function.   Consider a service function to be
>> logical in such a way that the identity of the logical function may also
>> imply some differentiated behavior.   For example, a conceptual function
>> is HTTP content filtering.    This conceptual function can then be
>> further instantiated at the logical level based on differentiated
>> policies such as content-filter-children,
>> content-filter-adults-no-porn, content-filter-adults (I'm taking no stand on opt-in vs. opt-out, Mr.
>> Cameron).   It may be that the same network element (dedicated physical
>> box or virtual network function) realizes all 3 of the example
>> policies.   The HTTP content filtering network function is really 3
>> logical network functions from the perspective of inclusion in a service
>> chain.   Now extend this to multiple conceptual functions that utilize
>> differentiated policies and the number of combinations will grow, at
>> least modestly.
>>
>> Thanks,
>>
>> Ron
>>
>> *From:*nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *On Behalf
>> Of *David Allan I
>> *Sent:* Wednesday, July 24, 2013 3:52 PM
>> *To:* Henderickx, Wim (Wim); N.Leymann@telekom.de; nsc@ietf.org
>> *Subject:* Re: [nsc] Service chaining architecture question
>>
>> Saying functions will have a problem with something that exists as a
>> potential rationale for defining something new with exactly the same
>> properties and problems does not quite work for me....
>>
>> VLANs on a vNIC or multiple vNICs (depending on the application stack
>> construction and this being combined with application "cooperation" to
>> preserve pairwise mappings of either VID/NIC tuples or simply NICs)
>> currently exist as potential vehicles for preserving chain context and
>> avoiding per hop classification. Anything else will be implemented
>> more or less the same way and have exactly the same set of scaling and
>> application design issues...Some extra information available on a single
>> interface, or achieved by mapping chain instances onto one of a
>> plurality of interfaces....
>>
>> But to back up... I'm not a carrier employee but I cannot envision a
>> carrier offering potentially 1000s of distinct service bundles ("pick
>> 53 from column A and 49 from column B"). So I suspect a much smaller
>> number is realistic for  the number of chains a function instance is
>> expected to participate in, even allowing for dynamic reclassification
>> of flows at a chain ingress to "skip a few functions".... These are
>> things that are fully operationalized in OSS, have policy associated
>> with, have been industrialized and demonstrated to work prior to
>> deployment. Going all combinatorial on this will break that big time....
>>
>> So are we really discussing a function participating in more than a
>> handful of chain instances? And either a plurality of vNICs or VIDs
>> being actually more than sufficient?
>>
>> Thanks
>>
>> Dave
>>
>> *From:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> [mailto:nsc-bounces@ietf.org] *On Behalf Of *Henderickx, Wim (Wim)
>> *Sent:* Wednesday, July 24, 2013 9:30 AM
>> *To:* N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>; nsc@ietf.org
>> <mailto:nsc@ietf.org>
>> *Subject:* Re: [nsc] Service chaining architecture question
>>
>> indeed
>>
>> *From: *"N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>"
>> <N.Leymann@telekom.de <mailto:N.Leymann@telekom.de>>
>> *Date: *Wednesday 24 July 2013 15:54
>> *To: *Wim Henderickx <wim.henderickx@alcatel-lucent.com
>> <mailto:wim.henderickx@alcatel-lucent.com>>, "nsc@ietf.org
>> <mailto:nsc@ietf.org>" <nsc@ietf.org <mailto:nsc@ietf.org>>
>> *Subject: *AW: Service chaining architecture question
>>
>> Hi Wim,
>>
>> I think not only effectivness/scalability might be a problem but also
>> the fact that not all applications (service bringing functions) are
>> able to handle packets coming from/going to potentially thousands of
>> different VLANs at the same time. VLANs will work in certain
>> environments but not in all. I see the need for an information
>> exchange between the application and a mediation layer as well.
>> Ideally this should be as simple as possible without heavy impact on
>> the application itself (might be difficult to achieve but from my
>> experience it is not very likely, that there will be big rewrites of
>> existing applications in order to support the chaining).
>>
>>     regards
>>
>>        Nic
>>
>> ----------------------------------------------------------------------
>> --
>>
>> *Von:*nsc-bounces@ietf.org <mailto:nsc-bounces@ietf.org>
>> [mailto:nsc-bounces@ietf.org] *Im Auftrag von *Henderickx, Wim (Wim)
>> *Gesendet:* Mittwoch, 24. Juli 2013 11:52
>> *An:* nsc@ietf.org <mailto:nsc@ietf.org>
>> *Betreff:* [nsc] Service chaining architecture question
>>
>> I have a basic question with respect to the architecture/framework so
>> far mentioned in the drafts in NSC. I understand the meta-data is a
>> mechanism to avoid multiple re-classifications when the packet enters
>> the NSC domain and identifies the chain of service functions. Now my
>> understanding is that the services/applications are unaware of the
>> meta-data and that a layer underneath should provide the mediation and
>> that we use a well defined interface to the application/service to
>> indicate the chain. In the context of Cloud/enterprise environment I
>> can see this work given you can use a dedicate VLAN e.g. within the tenant.
>> However we also try to address residential use cases for mobile and
>> fixed and here this becomes more tricky afais. In the residential
>> environment we can't expose a VLAN per application/service per chain
>> since this would not be very effective. So I am wondering how we
>> envision this to work?
>>
>>
>>
>> _______________________________________________
>> nsc mailing list
>> nsc@ietf.org
>> https://www.ietf.org/mailman/listinfo/nsc
>>
> _______________________________________________
> nsc mailing list
> nsc@ietf.org
> https://www.ietf.org/mailman/listinfo/nsc
>

From linda.dunbar@huawei.com  Sat Jul 27 22:44:10 2013
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31DC21F9C10 for <nsc@ietfa.amsl.com>; Sat, 27 Jul 2013 22:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M2af8KlhJUi for <nsc@ietfa.amsl.com>; Sat, 27 Jul 2013 22:44:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 80CC321F8AD5 for <nsc@ietf.org>; Sat, 27 Jul 2013 22:43:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVM38183; Sun, 28 Jul 2013 05:43:51 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 28 Jul 2013 06:43:48 +0100
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 28 Jul 2013 06:43:49 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Sat, 27 Jul 2013 22:43:37 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "NAPIERALA, MARIA H" <mn1921@att.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "<mohamed.boucadair@orange.com> " <mohamed.boucadair@orange.com>
Thread-Topic: [nsc] Service chaining architecture question
Thread-Index: AQHOiFNnRTrQ/qzqf0CnngyQ6PY9P5lzl+TAgADi9gCAADh1AP//i+0ggACDQQD//5wHwIAAfSuA//+LCTAAAOFOkAAPrusAAA6WcXD//5GVAIAAA3AAgAEXKACAAUWMgIAAD++AgAAEvQCAAAaegIAABf2AgAAFoICAADChAP/+k7PA
Date: Sun, 28 Jul 2013 05:43:36 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B4E269@dfweml509-mbx.china.huawei.com>
References: <94C682931C08B048B7A8645303FDC9F36EE6E832AC@PUEXCB1B.nanterre.francetelecom.fr> <68B171751455884590F8E38E96416F363F5C67F6@xmb-rcd-x01.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E832FC@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D56079@xmb-aln-x02.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE6E8332E@PUEXCB1B.nanterre.francetelecom.fr> <95067C434CE250468B77282634C96ED322D564B9@xmb-aln-x02.cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01208FD9@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01208FD9@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.137.47]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [nsc] Service chaining architecture question
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2013 05:44:11 -0000

> -----Original Message-----
> The immediate (and realistic) problem to be solved is chaining of
> "middlebox" functions.
> And it is needed "tomorrow" not 5 years from now ;-)
> The only examples (in the e-mails sent) were firewall, ADC, HTTP
> proxy.. These functions operate on IP packets.
>=20
>=20
[Linda] 100% agree with what Maria has said above.=20
Several drafts and some emails seem to advocate for including chaining of t=
raditional Layer 2-3 network functions.=20
There are already many IETF WG groups working on various aspects of chainin=
g traditional Layer 2-3 forwarding functions.=20


Linda=20


From mohamed.boucadair@orange.com  Mon Jul 29 01:35:49 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FB621F99AE for <nsc@ietfa.amsl.com>; Mon, 29 Jul 2013 01:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.503
X-Spam-Level: 
X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZFMlxdTZvoU for <nsc@ietfa.amsl.com>; Mon, 29 Jul 2013 01:35:45 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 07DF521F9D8A for <nsc@ietf.org>; Mon, 29 Jul 2013 01:35:44 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id C6B9E2DD2CE; Mon, 29 Jul 2013 10:35:43 +0200 (CEST)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9E44C238048; Mon, 29 Jul 2013 10:35:43 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 29 Jul 2013 10:35:43 +0200
From: <mohamed.boucadair@orange.com>
To: "Diego R. Lopez" <diego@tid.es>
Date: Mon, 29 Jul 2013 10:35:41 +0200
Thread-Topic: inter-domain case (was RE: [nsc] Service chaining architecture question)
Thread-Index: Ac6MNppeZnTEQQ6wR1W9crOC8t9qJA==
Message-ID: <94C682931C08B048B7A8645303FDC9F36EE6E834EC@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Cc: "nsc@ietf.org" <nsc@ietf.org>, "Carlos Pignataro \(cpignata\)" <cpignata@cisco.com>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA,  MARIA H" <mn1921@att.com>, Linda Dunbar <linda.dunbar@huawei.com>, "Paul Quinn \(paulq\)" <paulq@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: [nsc] inter-domain case (was RE: Service chaining architecture question)
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 08:35:49 -0000

Hi Diego,

Thank you for the answer. I still don't understand well the inter-domain us=
e case you are referring to and why this is a requirements. In order to und=
erstand better the case and to make sure there is no terminology confusion,=
 below some questions for you: =20

* Do you have two administrative entities involved in your case?
* Are both domains managed by one single administrative entity?
* Who decide on the inter-domain function chains?
* Who is responsible for ensuring the overall consistency?
* Why the chaining policies are to be exposed to an external domain? Why ea=
ch domain need to reveal its intra policies with regards to the way a netwo=
rk is engineered?
* Why not each of the domain enforces its policies without requiring any in=
volvement of functions located in another external domain?
* Why chaining will modify the way networks managed by two distinct adminis=
trative entities will be interconnected?

Thanks.
Cheers,
Med

>-----Message d'origine-----
>De=A0: Diego R. Lopez [mailto:diego@tid.es]
>Envoy=E9=A0: vendredi 26 juillet 2013 16:00
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Carlos Pignataro (cpignata); nsc@ietf.org; Jim Guichard (jguichar);
>NAPIERALA, MARIA H; Linda Dunbar; Paul Quinn (paulq); Ron Parker; Joel M.
>Halpern
>Objet=A0: Re: [nsc] Service chaining architecture question
>
>Hi,
>
>Just a quick reflection while I try to recover from the enormous backlog
>caused by the NFV meeting
>
>On 26 Jul 2013, at 15:50 , <mohamed.boucadair@orange.com> wrote:
>>
>>> Narrowing the use-case, options seem to severely limit the ability to
>>> perform cross-domain service chains.
>>
>> [Med] Do you mean inter-domain? For whom this is a requirement? What is
>the use case for that? At least for our side, we don't see inter-domain as
>a requirement for this work.
>
>Precisely in NFV we are considering the possibility of such arrangements,
>where you could use NS-as-a-Service. With an appropriate "NSC/NLF/...
>control plane" we could support several labeling mechanisms, adapted intra=
-
>and inter-domain scenarios.
>
>Be goode,
>
>--
>"Esta vez no fallaremos, Doctor Infierno"
>
>Dr Diego R. Lopez
>Telefonica I+D
>http://people.tid.es/diego.lopez/
>
>e-mail: diego@tid.es
>Tel:    +34 913 129 041
>Mobile: +34 682 051 091
>-----------------------------------------
>
>
>________________________________
>
>Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el =
enlace
>situado m=E1s 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 cpignata@cisco.com  Mon Jul 29 07:13:08 2013
Return-Path: <cpignata@cisco.com>
X-Original-To: nsc@ietfa.amsl.com
Delivered-To: nsc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6403421F9DCE for <nsc@ietfa.amsl.com>; Mon, 29 Jul 2013 07:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.021
X-Spam-Level: 
X-Spam-Status: No, score=-110.021 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guWt0DZfo4xA for <nsc@ietfa.amsl.com>; Mon, 29 Jul 2013 07:12:58 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E0C0D21F997B for <nsc@ietf.org>; Mon, 29 Jul 2013 07:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17412; q=dns/txt; s=iport; t=1375107178; x=1376316778; h=from:to:subject:date:message-id:mime-version; bh=KM0hjUzKKZWVIX6bKhbZG9IjRrfj2YFajNtlV0hDC3w=; b=MNEO6cLxyo3F3Gnz5ui7KfpX6V/f+HvdorSqivfzhyeYDatL38erLbYd 0fp3U5PFcDw0wXhKVDSppM0ZVwM79EoBqePXJHjpTMB0w8wmC70gWbJRM 5cQu3RdE1CDqt4+WOxqTAvh/oBGlLF5Yfzv9g2grogM37D2s6lcqMBSxt M=;
X-Files: ietf87-nscbof-minutes.html, signature.asc : 15843, 203
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAE939lGtJXG+/2dsb2JhbABZAoMGNVC1Hog6gRcWdIImAQRlCQYXARoQDApAFxAEEwgGDYd1DJdkoDSOSAx4MxcLAYJ6bwOQEoEth0mQI4MUgWgBCBci
X-IronPort-AV: E=Sophos;i="4.89,769,1367971200";  d="asc'?html'217?scan'217,208,217";a="240818970"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2013 14:12:56 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6TECuIc027167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <nsc@ietf.org>; Mon, 29 Jul 2013 14:12:56 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 09:12:56 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "nsc@ietf.org" <nsc@ietf.org>
Thread-Topic: Minutes for IETF87, NSC BOF meeting 
Thread-Index: AQHOjGW4dJSio5ZF7E6i3mj8QHPPsQ==
Date: Mon, 29 Jul 2013 14:12:55 +0000
Message-ID: <95067C434CE250468B77282634C96ED322D624B2@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.106.13]
Content-Type: multipart/signed; boundary="Apple-Mail=_D34E298B-E0EF-47E2-888A-EB76CFFAEC44"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Subject: [nsc] Minutes for IETF87, NSC BOF meeting
X-BeenThere: nsc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Service Chaining <nsc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsc>, <mailto:nsc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsc>
List-Post: <mailto:nsc@ietf.org>
List-Help: <mailto:nsc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsc>, <mailto:nsc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 14:13:08 -0000

--Apple-Mail=_D34E298B-E0EF-47E2-888A-EB76CFFAEC44
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_712F730C-221E-48E8-98FC-5F98BC79FFE0"


--Apple-Mail=_712F730C-221E-48E8-98FC-5F98BC79FFE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi, NSC,

Please find the minutes from today's NSC BOF meeting attached. Comments =
and corrections are most welcome!

Thanks,

-- Carlos.


--Apple-Mail=_712F730C-221E-48E8-98FC-5F98BC79FFE0
Content-Disposition: attachment;
	filename=ietf87-nscbof-minutes.html
Content-Type: text/html;
	x-unix-mode=0644;
	name="ietf87-nscbof-minutes.html"
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="en-us" />
<title>/ietf87-nscbof</title>
</head>
<body><br
/>Agenda: <a href="http://tools.ietf.org/agenda/87/agenda-87-nsc.html">http://tools.ietf.org/agenda/87/agenda-87-nsc.html</a><br
/><br
/>Scribe: Carlos Pignataro<br
/><br
/><br
/><b><u>Network Service Chaining (nsc) BoF Agenda</u></b><br
/><br
/><b><u>Bof Chairs: Jim Guichard (jguichar@cisco.com) &amp; Thomas Narten (narten@us.ibm.com)</u></b><br
/><br
/><br
/><b>Introduction: (5)</b><br
/><b>- BoF Chairs</b><br
/><ul><li>Thomas: Let's get started, we have only an hour and then a short break.</li
><li>... you all know the Note Well. Jim will share some context on the problem, then some presentations and a bit of discussion time at the end.</li
><li>... given our short session, we will be ruthless with the mike and allowing only a short set of questions.</li
><li>The objective is to see if there is interest. Operators will be explaining the problems they have and use cases. Also, this is not a WG forming BOF, so we will not get into whether we form a WG. It is premature to discuss that; down the road (around Vancouver time) we might want to form a WG.</li
><li>These are the three broad questions for the end:<ul><li>1. Is this an important problem area?</li
><li>2. Should IETF work towards a WG?</li
><li>3. Are people interested in doing the work?</li></ul
></li
><li>The Problem Statement comes from a document. For people that work on this space it is obvious but not for others. You might have many elements (firewall, etc) cooperating a certain way to perform a service. For example, no matter where the firewall migh be, the traffic should go through it and requirements be met. Today, these is done with layer 2 or layer 3 forwarding. Therefore, the service chain is tied to the underlying network. Once it is set up, it is really difficult to change that configuration of the deployed system.</li
><li>Additionally, there is no way to share context between elements.</li
><li>With that let me turn it over to our first presenter.<br/><br
/><br/><br
/></li></ul
><b>Network Based Services in Mobile Networks: (10)</b><br
/><b>- Walter Haeffner (walter.haeffner@vodafone.com</b>)<br
/><ul><li>Walter: First of all I want to talk about network services in mobile networks. Those first slides are for those that do not know mobile networks. In this case it's an LTE cell, terminating in a service wateway, a mobile management entity, and takes care of connectivity and mobility. Behind there is a packet gatewat and together with a policy function takes care of policing. Then we have an SGI interface. It's existent is defined but not its content. What is it supporting? Connectivity to the Internet, or to operator based services (like LTE services).&nbsp;</li
><li>We concentrate on Network Services (SG-LAN). These are performance enhancement boxes, firewalls, DPIs, etc.</li
><li>Here we have out packet gateway, and a vlan connecting to the other end a service environment. It could be operator based IMS or MPLS VPNs (fixed networks of enterprises), or connectivity to the Internet. Some services have proxies, firewalls, NAT devices, optimizers, load-balancers, etc. These are chained services to fullfil the requirement.</li
><li>How does this look in reality? A lot of boxes are attached to this router. Boxes have single service, other boxes multiple services. This is a very static environment, but in mobile networks we see our services are more and more complex.</li
><li>In these environments people use static routes, policy routing, and this makes the network very static and inflexible. Our requirements are of simplicitly. An operator should be able to click and choose services from a catalog and insert into the network. We are asking for much more automatism.</li
><li>We have many sources for metadata in these networks. Information in the P-GW has policy and other information including QoS and others. OTOH, it would be hard to single out a single metadata.</li
><li>Another open issue in such environment is that there is no coupling between the service itself and the network. The service does not know about network conditions. Is the network loaded or free? Someone is asking for HD-video, for example.</li
><li>This is my summary:<ul><li>First, simplicity and speed is key in a mobile network.</li
><li>Second, we need ways to provision these service chains easier.</li
><li>Third: We should use metadata -- the question is which metadata and how. Future research.</li></ul
></li></ul
><u>Questions:</u><br
/><ul><li>&lt;no questions&gt;<br/><br
/><br/><br
/></li></ul
><b>Network Function Virtualization (NFV): (10)</b><br
/><b>- Diego Lopez (diego@tid.es)</b><br
/><ul><li>Essencially this is talking about NfV again, and how we see NfV relating to this NSC idea.</li
><li>First two slides are about NFV. I talked about this in the SDNRG session so we might skik.</li
><li>This is the essencial part. We are taking about Network Service Chainging, and in NfV we talk about Virtual Network Function for building graphs. But we are talking about this. This is what the network operator can provide to customers. We forsee forwarding graphs not limited.</li
><li>NFV Forwarding graphs virtualized will provide efficiency in space and time, resiliency, recovery proedures, agility by shortening innovation cycles. Also, provide flexibility of things being virtualized. Much more choices, and we call that expressiveness. And of course flexibility.</li
><li>We believe these are very important business models. Operators can have mutual deployments or with 3rd parties.</li
><li>This is the general architecture. Services running on top of the infrastructure. VNF providers will provide the software and requirements for connecting the components inside VNFs. The orchestration will take care of storage, compute, and networking. The network service provider can install the forwarding graph by attaching the endpoints for the service.</li
><li>Know that here we are also talking about physical networks. We acknowledge that there will be time (very long time) of co-existence. Most likely forwarding graphs will combine both physical and virtual networks.</li
><li>Challenges we see are migration and co-existence. Make free arrangements of different network functions. We would like to see a mechanism for how a network forwarding graph will be built. And we also need ways of measure and verify.</li
><li>In the mailing list there's also been discussion about whether to include multiple domains. I agree this is a requirement from the beginning. If we want to foster new collaboration that we foresee it's a requirement.</li
><li>I was asked by the chairs to prepare 3 take-aways.<ul><li>NFV intends to bring virtualization into network functions</li
><li>Network Service Chaining (VNFG in BFV jargon) is key in the NFV service model.</li
><li>NFV does not intend to build standards on its own.</li></ul
></li
><li>We would like that the IETF takes a role here and progresses in this direction.</li></ul
><u>Questions:</u><br
/><ul><li>&lt;no questions&gt;<br/><br
/><br/><br
/></li></ul
><b>Enterprise use case: (10)</b><br
/><b>- Mudassir Tufail (mudass</b>ir.tufail@citi.com)<br
/><ul><li>I represent Ciri Group, one of the largets.</li
><li>The way we define services are:<ul><li>Firewall -- today we use HW appliances. We will use distributed ones.</li
><li>Load-balancer -- we use in two phases: external and internal.&nbsp;</li
><li>Third one is WAN acceleration. We use these in our branches.</li
><li>Last: Traffic Monitoring and SPAN/TAP. This is really important for compliance.</li></ul
></li
><li>One of our biggest problems today is that the path to the appliance is too rigid and static.</li
><li>We are creating a software defined data center. We will have a ton of HW appliances with virtual appliances. You can imagine how hard it will be to manage a virtual appliance. This is why we want to make it easy for us to manage network services.</li
><li>Now, this is what we want to see. A WAN network at the top, but most importantly how we connect externally. Both externally and internally we will be using a number of services. These appliances do not talk to each other, so we need a standard on how these services talk to each other.</li
><li>My take-aways are:<ul><li>Asset optimization -- we are moving towards virtual appliances and we want to see benefits</li
><li>Static to flexible service enablement.</li
><li>Complexity to simplicity. Today we are talking to all these service independently which is very complex. We hope that all of these talk to each other seamlessly.</li
><li>Multi-vendor interop.&nbsp;</li></ul
></li></ul
><u>Questions:</u><br
/><ul><li>&lt;no questions&gt;<br/><br
/><br/><br
/></li></ul
><b>Data Center use case: (10)</b><br
/><b>- Brad McConnell (bmcconne</b>@rackspace.com)<br
/><ul><li>Good afternoon, I am _not_ Brad, I am Paul and I proxy for Brad.</li
><li>This is about the need to simplify and exchange information about the service chain</li
><li>Rack space provides a set of suite of services, managed hypervisor, etc. We have to deal with a number of topologies and overlays and underlays.</li
><li>Challenges:<ul><li>First point: when you have a lot of vendors in hypervisor, the lowest common denominator is pretty low, and it is VLANs -- and we know the issues with that.</li
><li>vertically integrated solutions</li
><li>Need consistency, and I won't discuss the "SDN" piece since we all know that.</li></ul
></li
><li>Changing VLANs is not viable. Changing encaps in the datacenter is not viable. Prevalent technologies requires decap and encap, and we want to avod that. VXLAN to VLAN, etc., is an exercise of mapping.</li
><li>When we want STT to another not common overlay, and&nbsp; more importantly we want to interoperate datacenters, we have context and we need to move metadata for that context.</li
><li>What context? There is a lot of different context to be shared: userid, OAM, Direction, pipeline stage index (visibility into the pipeline and vertical scale), version, compliance.</li
><li>You see, there is a ton of information that we pass along but we do not have a way of doing that.</li
><li>Service chaining isn;t about the encap. We would like to pass context along those pipelines to allow each Service in the chain to get that context and not have to derive it on their own their own way. For example, that a service chain receives user id. And last, let's stay focused.</li></ul
><u>Questions:</u><br
/><ul><li>&lt;no questions&gt;<br/><br
/><br/><br
/></li></ul
><b>Q&amp;A/Closing: (15)</b><br
/><b>- BoF Chairs</b><br
/><ul><li>Thomas: At this point I'd like to open to questions and comments.</li
><li>Someone: there seems there are at least two use cases -- the graph, and the -- they should probably be divided in the same WG or in different WGs.</li
><li>Thomas: I've been to a lot of BOFs and a single comment is amazing.</li
><li>Adrian: Thank you for saying that Thomas. That was worrying me. Either means nobody cares, or everyone agrees and there is nothing to say. I would like to ask people to ask if people aling on what a service chain is.</li
><li>Thomas: I think in the alias you see that peeling the onion there is not a lot of agreement. We cannot answer that here.</li
><li>Linda: I have many questions. I see network services, and that's been used in many contexts. VPN services, etc. Citigroup has L2 to L7 services. In datacenter, we see those chained together. I see here presentations about sending traffic to another domain because you do not know how to route it. So net-net: what are those services?</li
><li>Diego: Adrian probably was right in the disagreement about what service chain is. I see the need for having mechanisms of passing packet context to build a service chain or mesh or routing or whatever you call it. How this context is derived and what is the purpose of this content is a disagreement. But the need to pass this context is a common need.</li
><li>Someone: I think there is a need for this group. Citi highlighted what I see in the security area. It's not about flexibility of passing, but about avoiding duplicate work for not classify twice. I am very supportive of this work.</li
><li>Steven, AT&amp;T: Open Forum has the same -- I do not have the liaison.</li
><li>Someone Else: All the devices need to implement service a certain way. And there are various control planes we can use for that. We also have a lot of dataplane encapsulations. So I am not very clear on what we need to do to implement a higher level management doing the service chain. In which plane are we trying to standardize work? dataplane? control? management?</li
><li>Thomas: Maybe we do not know. What encapsulations do we have today to end context and service chain? We don't</li
><li>Same someone: We have bits in VXLAN, we have MPLS Label. I am trying to understand what is our focus. Service chain across these encaps? uniform control plane?</li
><li>Jim: These are things we need to work out if we have a WG. The purpose of today is to show that there is a problem. Seems there's a lot of interest and people to work on them. As Thomas said, we do not have all the answers.</li
><li>China Mobile: Thank you for separating use cases in mobile and fixed. We also have a draft on mobile use cases. The one comment is about linkage about network service chain to other work in IETF.</li
><li>Yet another someone: There is a desire to cross various encaps, VXLAN, VLAN, MPLS, and here is a scenario where there is a lot of opportunity to standardization. So we are loosing information when moving form one to the other encap.</li
><li>A The ForCES WG charter is to interconnect packet plus pass metadata. There is a draft and presentation tomorrow.</li
><li>Thomas: I think we need to see what other work exists.</li
><li>A: We have an opportunity to take what ForCES did.</li
><li>Thomas: I do not know, but we need to go voer cataloging what work exists.</li
><li>B: Another is how to do per-subscribed acocunting.</li
><li>C: I build middle-boxes. Content inspection. I am very supportive. You can only count on what oyu see. There is a disconnect between how we encap and move traffic versus teh services we try to apply to it. That is a very high level concern to me, from SDN, or wherever, how we put the pieces together for a solution.</li
><li>D: I guess the reason we are here is t ocollectively explore the posibility of implementation, systems and services, and protocol machinery for IETF to create tools to address this issue. I do not think that individually we need to say if it is good or bad. Collectively we should -- where do we redirect the discussion for those 3 elements?</li
><li>Thomas: Thank you. Last couple of minutes, let me ask aloud. Answers are yes/no/no opinion</li
><li>Thomas: is this important? Yes: a lot. No: none.</li
><li>Thomas: should the IETF work towards creating a WG? Yes: slightly fewer but still a lot. No: a couple.</li
><li>Lou Berger: Clarification question. You just recast the question (you said no want WG). The question is unclear because I do not know what "towards creating a WG" means.</li
><li>Thomas: I do not want to ask create a WG because we still need to figure out what this means, scope, charter, etc.</li
><li>Thomas: How many people are willing to work on docs? &lt;hands raise&gt; good number.</li
><li>Thomas: Those were last closing comments -- we are done. Thanks everyone.<br/><br
/></li></ul
>EOF.<br
/><br
/></body>
</html>

--Apple-Mail=_712F730C-221E-48E8-98FC-5F98BC79FFE0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii





--Apple-Mail=_712F730C-221E-48E8-98FC-5F98BC79FFE0--

--Apple-Mail=_D34E298B-E0EF-47E2-888A-EB76CFFAEC44
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlH2eGcACgkQtfDPGTp3USwFzQCbBoqjH31+6RaUPopE6c6G3ZoU
1UAAoK2uc842BIsB0z0CXzcJ2U9fFNNj
=DNJ1
-----END PGP SIGNATURE-----

--Apple-Mail=_D34E298B-E0EF-47E2-888A-EB76CFFAEC44--