From nobody Tue Jun  3 02:06:08 2014
Return-Path: <janl@tail-f.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660AA1A0188 for <sfc@ietfa.amsl.com>; Tue,  3 Jun 2014 02:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk8Vw-KgoQKk for <sfc@ietfa.amsl.com>; Tue,  3 Jun 2014 02:06:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 407761A0183 for <sfc@ietf.org>; Tue,  3 Jun 2014 02:06:04 -0700 (PDT)
Received: from [10.197.171.137] (unknown [78.100.132.186]) by mail.tail-f.com (Postfix) with ESMTPSA id 7D09812807E1; Tue,  3 Jun 2014 11:05:07 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_0082E197-6426-4A9A-B330-E80F8B4232C5"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Jan Lindblad <janl@tail-f.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B8FFDED@xmb-rcd-x04.cisco.com>
Date: Tue, 3 Jun 2014 11:05:52 +0200
Message-Id: <026B7D91-E5E2-4A5A-90E2-0D16D725811C@tail-f.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040B8FFDED@xmb-rcd-x04.cisco.com>
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DsUN1rRWHQS5LEccQKu8o-z4FHQ
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jun 2014 09:06:07 -0000

--Apple-Mail=_0082E197-6426-4A9A-B330-E80F8B4232C5
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4428581E-DD53-4A8C-A682-E56B607EBDC9"


--Apple-Mail=_4428581E-DD53-4A8C-A682-E56B607EBDC9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Reinaldo,

Good work! I made a quick review of your proposed SFC YANG module. I =
have been monitoring this list for a couple of weeks only, so please =
bear with any misconceptions on my part. I'm a YANG Doctor, however, so =
I was hoping I could contribute with a few YANG-level suggestions or =
options for you.



module vxlan-gpe:

The namespace declaration in each of the modules starts with =
urn:cisco:... Namespaces on this form are supposed to be registered with =
IANA. =
http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

I suggest either changing this to an IETF reserved name, or move it to a =
proper cisco-namespace, e.g.:
namespace "http://cisco.com/ns/ietf/wg/sfc";
or, perhaps better, an IETF registered name:
namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC =
number and remove this note.
This applies to all modules in the submission, but I will not keep =
repeating this comment for the others.

There are a number of reserved bits and fields in the module. I think it =
may be wise to think this through a bit more before publishing. =
According to the YANG RFC 6020 section 10, IETF does not allow itself to =
ever remove a published configurable item from a module, so those =
reserved names will have to stick forever. To make it worse, the bit =
positions must be unique, so the bit names will have to remain r1, r2, =
r3, ... indefinitely, even if a proper meaning and name is invented at a =
later stage. I suggest simply not listing them in the specification in =
this version, only adding them when they have a well defined meaning.

The leaf-list vni will not behave as intended. A leaf list will =
automatically sort itself into the natural (ascending) order (unless =
ordered-by user is specified), and can never contain repeated values =
(such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or =
possibly a list (not leaf list) with a position key. Or three separate =
8-bit leafs (vni-low, vni-med, vni-high).



module service-function:

Revision dates are YYYY-MM-DD

Identity+identityref seems like a good way to handle this extensible =
set. It does require YANG modeling to define new types however, so if =
operators should be able to invent new types "on the fly", another =
option would be to have one more config table with the operator =
specified types, and then use a leafref to point to one of them.

Mandatory true on a key element is not necessary, so this can be removed =
for improved readability and brevity. This also applies to several other =
lists, but I will not keep repeating this comment.

There is no mandatory true on the type and ip-host-address leafs. What =
would it mean if a sfc entry exists and has no type nor ip-host-address? =
Should one or both be mandatory, or have a default? Note that if we =
specify a default, that default value can never ever be changed to =
something else according to the YANG RFC 6020, sec 10.



module service-function-chain:

As noted by Ron Parker, this allows only a single instance of each =
service type in each chain. With the current model, an operator has no =
way of defining additional service types to say clone a dpi service into =
an dpi-early and dpi-late. If this was modeled as a list with a string =
name and a service-function-type leaf instead, the same function could =
appear multiple times in a chain.



module service-node:

The leafs type, transport, ip-host-address and failmode are not =
mandatory and have no defaults. Will it be entirely clear to operators =
what the system will do if some or all of them have no values? This is =
not obvious to me (but that could be only me).

As noted by Ron Parker, type can hold only a single value. Could a =
service node be of multiple types simultaneously?



module service-function-path:

The service-function-path is modeled as a container. So there can be =
only one of these in the whole system. I might be missing something, but =
I think you want a list here, in some way.



module service-function-forwarder:

Once again, the leafs ip and port are not mandatory. Is that ok? Should =
each service function have a single ip/port pair?



In general, I think these modules are very small. Typically I recommend =
to make separate modules for things that need to be versioned =
separately, i.e. corresponding to software components. To me, these =
modules feel very closely related, so even a single module for all of =
this would be fine. Factoring things out into separate modules may make =
it harder to get a full grasp of what SFC is about, repeating things in =
module descriptions, making creation of new revisions harder.

/Jan Lindblad


On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com> =
wrote:

> A new version of I-D, draft-penno-sfc-yang-02.txt
> has been successfully submitted by Reinaldo Penno and posted to the
> IETF repository.
>=20
> Name:           draft-penno-sfc-yang
> Revision:       02
> Title:          Yang Data Model for Service Function Chaining
> Document date:  2014-05-29
> Group:          Individual Submission
> Pages:          20
> URL:            =
http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
> Htmlized:       http://tools.ietf.org/html/draft-penno-sfc-yang-02
> Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>=20


--Apple-Mail=_4428581E-DD53-4A8C-A682-E56B607EBDC9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<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-line-break: =
after-white-space;"><div>Reinaldo,</div><div><br></div><div>Good work! I =
made a quick review of your proposed SFC YANG module. I have been =
monitoring this list for a couple of weeks only, so please bear with any =
misconceptions on my part. I'm a YANG Doctor, however, so I was hoping I =
could contribute with a few YANG-level suggestions or options for =
you.</div><div><br></div><div><br></div><div><br></div><div>module =
vxlan-gpe:</div><div><br></div><div>The namespace declaration in each of =
the modules starts with urn:cisco:... Namespaces on this form are =
supposed to be registered with IANA.&nbsp;<a =
href=3D"http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtm=
l">http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml</a>=
</div><div><br></div><div>I suggest either changing this to an IETF =
reserved name, or move it to a proper cisco-namespace, =
e.g.:</div><div>namespace "<a =
href=3D"http://cisco.com/ns/ietf/wg/sfc">http://cisco.com/ns/ietf/wg/sfc</=
a>";</div><div>or, perhaps better, an IETF registered =
name:</div><div>namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX =
with actual RFC number and remove this note.</div><div>This applies to =
all modules in the submission, but I will not keep repeating this =
comment for the others.</div><div><br></div><div>There are a number of =
reserved bits and fields in the module. I think it may be wise to think =
this through a bit more before publishing. According to the YANG RFC =
6020 section 10, IETF does not allow itself to ever remove a published =
configurable item from a module, so those reserved names will have to =
stick forever. To make it worse, the bit positions must be unique, so =
the bit names will have to remain r1, r2, r3, ... indefinitely, even if =
a proper meaning and name is invented at a later stage. I suggest simply =
not listing them in the specification in this version, only adding them =
when they have a well defined meaning.</div><div><br></div><div>The =
leaf-list vni will not behave as intended. A leaf list will =
automatically sort itself into the natural (ascending) order (unless =
ordered-by user is specified), and can never contain repeated values =
(such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or =
possibly a list (not leaf list) with a position key. Or three separate =
8-bit leafs (vni-low, vni-med, =
vni-high).</div><div><br></div><div><br></div><div><br></div><div>module =
service-function:</div><div><br></div><div>Revision dates are =
YYYY-MM-DD</div><div><br></div><div>Identity+identityref seems like a =
good way to handle this extensible set. It does require YANG modeling to =
define new types however, so if operators should be able to invent new =
types "on the fly", another option would be to have one more config =
table with the operator specified types, and then use a leafref to point =
to one of them.</div><div><br></div><div>Mandatory true on a key element =
is not necessary, so this can be removed for improved readability and =
brevity. This also applies to several other lists, but I will not keep =
repeating this comment.</div><div><br></div><div>There is no mandatory =
true on the type and ip-host-address leafs. What would it mean if a sfc =
entry exists and has no type nor ip-host-address? Should one or both be =
mandatory, or have a default? Note that if we specify a default, that =
default value can never ever be changed to something else according to =
the YANG RFC 6020, sec =
10.</div><div><br></div><div><br></div><div><br></div><div>module =
service-function-chain:</div><div><br></div><div>As noted by Ron Parker, =
this allows only a single instance of each service type in each chain. =
With the current model, an operator has no way of defining additional =
service types to say clone a dpi service into an dpi-early and dpi-late. =
If this was modeled as a list with a string name and a =
service-function-type leaf instead, the same function could appear =
multiple times in a =
chain.</div><div><br></div><div><br></div><div><br></div><div>module =
service-node:</div><div><br></div><div>The leafs type, transport, =
ip-host-address and failmode are not mandatory and have no defaults. =
Will it be entirely clear to operators what the system will do if some =
or all of them have no values? This is not obvious to me (but that could =
be only me).</div><div><br></div><div>As noted by Ron Parker, type can =
hold only a single value. Could a service node be of multiple types =
simultaneously?</div><div><br></div><div><br></div><div><br></div><div>mod=
ule service-function-path:</div><div><br></div><div>The =
service-function-path is modeled as a container. So there can be only =
one of these in the whole system. I might be missing something, but I =
think you want a list here, in some =
way.</div><div><br></div><div><br></div><div><br></div><div>module =
service-function-forwarder:</div><div><br></div><div>Once again, the =
leafs ip and port are not mandatory. Is that ok? Should each service =
function have a single ip/port =
pair?</div><div><br></div><div><br></div><div><br></div><div>In general, =
I think these modules are very small. Typically I recommend to make =
separate modules for things that need to be versioned separately, i.e. =
corresponding to software components. To me, these modules feel very =
closely related, so even a single module for all of this would be fine. =
Factoring things out into separate modules may make it harder to get a =
full grasp of what SFC is about, repeating things in module =
descriptions, making creation of new revisions =
harder.</div><div><br></div><div>/Jan Lindblad</div><div =
apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px;"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px; color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; =
"><div><br></div></span></div></span></div></span>
</div>
<br><div><div>On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) &lt;<a =
href=3D"mailto:repenno@cisco.com">repenno@cisco.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">A new version of I-D, draft-penno-sfc-yang-02.txt<br>has =
been successfully submitted by Reinaldo Penno and posted to the<br>IETF =
repository.<br><br>Name: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;draft-penno-sf=
c-yang<br>Revision: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;02<br>Title: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Yang Data Model =
for Service Function Chaining<br>Document date: =
&nbsp;2014-05-29<br>Group: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Individual =
Submission<br>Pages: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;20<br>URL: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt">h=
ttp://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt</a><br>Stat=
us: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"https://datatracker.ietf.org/doc/draft-penno-sfc-yang/">https://da=
tatracker.ietf.org/doc/draft-penno-sfc-yang/</a><br>Htmlized: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://tools.ietf.org/html/draft-penno-sfc-yang-02">http://tools.i=
etf.org/html/draft-penno-sfc-yang-02</a><br>Diff: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02">http:/=
/www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02</a><br>______________=
_________________________________<br>sfc mailing list<br><a =
href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>https://www.ietf.org/mail=
man/listinfo/sfc<br><br></blockquote></div><br></body></html>=

--Apple-Mail=_4428581E-DD53-4A8C-A682-E56B607EBDC9--

--Apple-Mail=_0082E197-6426-4A9A-B330-E80F8B4232C5
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 - https://gpgtools.org

iQEcBAEBCgAGBQJTjY/wAAoJEBSCnbqufIisVt4H/1oy2xS4CcL/oJZ8tyPtz4rW
niotXfIe9DjFyvFHr5+MyQmXhqScJXIfPFKySfT/h3Q/wfJKmdO+KkPQ6mWdX41v
COfaDXqpBOd6uqIy2mFMab8DRVnLdA4ke9kxkm6SCvHiZnoZZXuRmNpKOF9x0zgg
gLz6AWAPTjxRyWTIcReC+AaRE/02lveefki2Pg0u9VEl4YxYmhAzvT0hpGibcogD
bAtherVF5ILZTNPcErqATnJe9VQ/0B1Hl7U7lx3o0CqJ0yiHEZRJ5Gf5Y6VloCll
tDr6YTrYCllwCZLsEnAcDSdXEmZxidhf8RlN1hYjOBwJXx8lAPOtz8DH2lYJweI=
=pQ9S
-----END PGP SIGNATURE-----

--Apple-Mail=_0082E197-6426-4A9A-B330-E80F8B4232C5--


From nobody Wed Jun  4 05:22:25 2014
Return-Path: <jguichar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1F11A0301 for <sfc@ietfa.amsl.com>; Wed,  4 Jun 2014 05:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3FHj6G0HVvS for <sfc@ietfa.amsl.com>; Wed,  4 Jun 2014 05:22:19 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD471A02CA for <sfc@ietf.org>; Wed,  4 Jun 2014 05:22:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1496; q=dns/txt; s=iport; t=1401884531; x=1403094131; h=from:to:subject:date:message-id:mime-version; bh=OBZOXyTpsecHOJrSm8kJyM1yXpcQUACkqZN/QEyxBns=; b=QKTxTW7tUUc0leAFoyxCaxfzuiHDohJT8/Fe2S1SVY+zw5RKlxya/Jw7 qfNvnF3bhgRqIp8EC2eqm/SXw7vmTSQwpjE3FHjz6+2X2JQ5dkOoI4cQC SJWVgaON1XWIxETAbdwyZ6mszpfdli0h6DmzapVWCpLlvw2mPHXItbEAh Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0LADMPj1OtJA2N/2dsb2JhbABZgkJFgSqqQgEEBQEFmS0WdIIcEB1uAQsBdCcEiFWdAbUOF4VVjUQEmg+TNoM4gi8
X-IronPort-AV: E=Sophos; i="4.98,973,1392163200"; d="scan'208,217"; a="50094557"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 04 Jun 2014 12:22:01 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s54CM1kp002704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Wed, 4 Jun 2014 12:22:01 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.85]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 07:22:01 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: WG acceptance of draft-krishnan-sfc-long-lived-flow-use-cases-02
Thread-Index: AQHPf++VNfFXctHebk2CzksjEUdfig==
Date: Wed, 4 Jun 2014 12:22:00 +0000
Message-ID: <CFB487BE.219DB%jguichar@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.98.43.180]
Content-Type: multipart/alternative; boundary="_000_CFB487BE219DBjguicharciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/S9XgncZuqFDJrw0fn24BJ9sUG14
Subject: [sfc] WG acceptance of draft-krishnan-sfc-long-lived-flow-use-cases-02
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jun 2014 12:22:23 -0000

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

Greetings:

Thank you for your responses on the call for adoption of draft-krishnan-sfc=
-long-lived-flow-use-cases. Overall there seems to be general consensus tha=
t the document provides relevant content and should therefore be adopted as=
 a WG document.

Authors, please post a new version as draft-ietf-sfc-long-lived-flow-use-ca=
ses-00.

Jim

--_000_CFB487BE219DBjguicharciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <FB5F342A6081334BBEF16923C8A52130@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>Greetings:</div>
<div><br>
</div>
<div>Thank you for your responses on the call for adoption of draft-krishna=
n-sfc-long-lived-flow-use-cases. Overall there seems to be general consensu=
s that the document provides relevant content and should therefore be adopt=
ed as a WG document.</div>
<div><br>
</div>
<div>Authors, please post a new version as draft-ietf-sfc-long-lived-flow-u=
se-cases-00.</div>
<div><br>
</div>
<div>Jim</div>
</body>
</html>

--_000_CFB487BE219DBjguicharciscocom_--


From nobody Wed Jun  4 16:03:44 2014
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24E11A0394 for <sfc@ietfa.amsl.com>; Wed,  4 Jun 2014 16:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level: 
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-1-iPPgoyAQ for <sfc@ietfa.amsl.com>; Wed,  4 Jun 2014 16:03:37 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17931A0362 for <sfc@ietf.org>; Wed,  4 Jun 2014 16:03:35 -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.7-GA FastPath queued) with ESMTP id BEW52939; Wed, 04 Jun 2014 23:03:28 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 00:02:34 +0100
Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 00:03:26 +0100
Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Wed, 4 Jun 2014 16:03:19 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "christian.jacquenet@orange.com" <christian.jacquenet@orange.com>, Jiangyuanlong <jiangyuanlong@huawei.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: Suggestions to "draft-boucadair-sfc-requirements-04"
Thread-Index: Ac+ASSw6EqtHtNzASnqrgNUnvnRaZQ==
Date: Wed, 4 Jun 2014 23:03:17 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2E2D7@dfweml701-chm.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.155.225]
Content-Type: multipart/mixed; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F645D2E2D7dfweml701chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/i6PLeQGE7YmTmmkbNBkzIlKlsYw
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04"
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jun 2014 23:03:41 -0000

--_004_4A95BA014132FF49AE685FAB4B9F17F645D2E2D7dfweml701chmchi_
Content-Type: multipart/alternative;
	boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D2E2D7dfweml701chmchi_"

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

Mohamed, et al,

The draft-boucadair-sfc-requirements-04 has all the requirements lumped tog=
ether, making it difficult for people to validate and provide comments.

I think that it is beneficial to create multiple categories of requirements=
. So each category can be reviewed and validated more intensively.

With this in mind, I took the first stab of breaking the requirements in th=
e draft to multiple categories.  I didn't change the order of your original=
 ones, but shuffled them around, so that similar ones are put under one sub=
-section. I also added some comments for the requirements that I don't thin=
k make sense.

I only added a few new requirements, however, I didn't add any new requirem=
ent numbers.

I suggest each sub-section has its own numbering scheme, such as "OAM-1, 2,=
 ..", so that any addition or deletion within one sub-section won't affect =
other sections.

Please see the attached with the changes marked.

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F645D2E2D7dfweml701chmchi_
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: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">Mohamed, et al, <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The draft-boucadair-sfc-requirements-04 has all the =
requirements lumped together, making it difficult for people to validate an=
d provide comments.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I think that it is beneficial to create multiple cat=
egories of requirements. So each category can be reviewed and validated mor=
e intensively.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">With this in mind, I took the first stab of breaking=
 the requirements in the draft to multiple categories.&nbsp; I didn&#8217;t=
 change the order of your original ones, but shuffled them around, so that =
similar ones are put under one sub-section. I
 also added some comments for the requirements that I don&#8217;t think mak=
e sense. <o:p>
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I only added a few new requirements, however, I didn=
&#8217;t add any new requirement numbers.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I suggest each sub-section has its own numbering sch=
eme, such as &#8220;OAM-1, 2, ..&#8221;, so that any addition or deletion w=
ithin one sub-section won&#8217;t affect other sections.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Please see the attached with the changes marked. <o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Linda <o:p></o:p></p>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F645D2E2D7dfweml701chmchi_--

--_004_4A95BA014132FF49AE685FAB4B9F17F645D2E2D7dfweml701chmchi_
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
	name="draft-boucadair-sfc-requirements-04- Linda Suggested Changes.docx"
Content-Description: draft-boucadair-sfc-requirements-04- Linda Suggested
 Changes.docx
Content-Disposition: attachment; filename=
	"draft-boucadair-sfc-requirements-04- Linda Suggested Changes.docx";
	size=40330; creation-date="Wed, 04 Jun 2014 20:43:15 GMT";
	modification-date="Wed, 04 Jun 2014 22:53:14 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQBjgxjKjgEAAKUGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0
ldtOg0AQhu9NfAeytwa29cIYA/TCw6WaWB9guwwtkT1kZ+nh7R2gJUYttcXekBB2vvn/fydDPFmr
MliCw8LohI2jEQtAS5MVep6w9+lTeMsC9EJnojQaErYBZJP08iKebixgQNUaE7bw3t5xjnIBSmBk
LGj6khunhKdXN+dWyA8xB349Gt1wabQH7UNfM1gav5AAV2QQvArnn4WiPnxlXEYHlaKDGBGNBfdt
Wd05YcLaspDCk26+1Nm3nqHJ80JCZmRVA6KaZp2RgEjOVBntyFc1mafxA+SiKn3wuCZlbRgOSjyu
6dZkRJWNMFwUFns69LvaKtsbTmeuH3NCOB1ZiULv9O/VoSs1A0ex/v8tdeiDItBvSjjDnLTcvvYU
1qszFjlN5OAEoB6/DLKQhtWC8wV087M3fwTvKf1zmN+S/2RfVuiNGpxAiznGv6elA7x5jge3bzB9
fpu9lNMmmopZCYP7/VhMHfqgiBXM3s529V/gfUK64ZfGnRDGbmHW1b9cOW9+MuknAAAA//8DAFBL
AwQUAAYACAAAACEAmVV+BQQBAADhAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz0rDQBDG74Lv
sMy9mbSKiDTpRYTeROIDDLvTJJj9w+5U27d3LYgGatKDx5355pvffOx6c7CDeueYeu8qWBYlKHba
m961Fbw2T4t7UEnIGRq84wqOnGBTX1+tX3ggyUOp60NS2cWlCjqR8ICYdMeWUuEDu9zZ+WhJ8jO2
GEi/Ucu4Kss7jL89oB55qq2pIG7NDajmGPLmeW+/2/WaH73eW3ZyZgXyQdgZNosQM1uUPl+jGoot
SwXG6+dcTkghFBkb8DzR6nKiv69Fy0KGhFD7yNM8X4opoOXlQPMRjRU/6Xz4aDBHdMp2iub2P2n0
Pom3M/GcNN9IOPqY9ScAAAD//wMAUEsDBBQABgAIAAAAIQBBQiNEGAEAADkEAAAcAAgBd29yZC9f
cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AKyTTU7DMBCF90jcwZo9cVKgIFSnG4TULYQDOMnkR8R2ZE+B3B4TKU0qqrDxxtI8y+99nrF3+2/V
sU+0rjVaQBLFwFAXpmx1LeA9e7l5BOZI6lJ2RqOAAR3s0+ur3St2kvwh17S9Y95FOwENUf/EuSsa
VNJFpkftdypjlSRf2pr3sviQNfJNHG+5XXpAeubJDqUAeyhvgWVD75P/9zZV1Rb4bIqjQk0XIrhD
In8z5z2lrZEETErkOYFfRngIiUC+NTjnjyUf12SNYROSwdHQ+TnOTRjrtfgkZLw+qhytn8NMcJLW
ILYhISqjKZN5t5jFSVqDuA8JURj1+1QXo5iUNYS7kAhfmL/9+RULcQLhZx8+/QEAAP//AwBQSwME
FAAGAAgAAAAhACKKmsFxZgAA3RIHABEAAAB3b3JkL2RvY3VtZW50LnhtbOx923LbSpbl+0TMP2Ro
ImbsCUmmrrZ1yuyQJWtK3b6oJXkiqk6chxSQJDEGkTy4iNZ56t+Yt/mW+ZT5klk7AZBIkJAAyxIz
6azuKkskJSEv+7722n/7l+/jkN2KOAlk9G5jZ7u3wUTkST+Ihu82vl6fbb3ZYEnKI5+HMhLvNu5E
svEv/f/8n/42PfKll41FlDL8iig5usW7ozSdHL16lXgjMebJtpyICG8OZDzmKb6Nh6/GPP6WTbY8
OZ7wNLgJwiC9e7Xb6x1uFL9GvtvI4uio+BVb48CLZSIHKf3IkRwMAk8U/5Q/Ebf5u/lPnhaPrP7i
q1iEeAYZJaNgkpS/bfyjvw1LHJW/5Pa+RdyOw/Jz00mbv+bHfIrzGIf5Y09l7E9i6Ykkwaun+Zuz
37jTu+9vFxtIv2L2E20eQf+b5ZOMeRDNfg3djtr5zw5vG4f3Kv/br+hXzReCvejjLt1I/47+nbDp
Ee6if/luo9c77r0+Pny/Ub50KgY8C9PKO+onLmL6J5lwD7uBz/JBKnAlcJGnR2FAT7W7P/vmMgvx
As9SufGKfizOfzo+k1Ga0A8nXhC82ziRWRyImH0WU/o1gifpcRLwhTdGx1Gy+HEv0T+o/lLyF37R
LQ/xOD3626+KP45/J/QQ9K/bAbcDbgc67MCHg8P3xztKgyghWgM9ALVAG7B6xTQ9UpZdaVbozEks
EhHfio3+1dkJ+9H/fNpmpOnSXP+pk46lHHyIY2jH9G6CP5RMRBhepTxOCxVtzHb038vM4z4P4lZr
+BD5haLvotjdlX46W9t4pc8j+AyRSLfgTQ3Sbpf7xOor/a/c+zMTWLq70oW/18pbM19L05WOfOFT
9JZmyVFd7/oihMoN/MJThks8knCbP77eO+jtk9Pr85R8597O/lbvcKu3f73z+uhg76jX+6eyt6Sw
yVM/FXBpe73TN6/fnB3k76zcp8bDi/BafG8wYOdRHpEi9OPhfcJOMlH8ptJg5a+QSQoiChhoA3do
u354A1WoY9j2pX0YYMT8sZ+wNObet5p2KA/fyGenRMKi1/LQOc9cEpwwjlY5HeZ4HmcxjzzBrkUo
EEprp4Hndf6FOSf14fskgKt8xL54qbyBTTncZKRE77t/1ff+sc3+NeDR0J2xCoHodhf2xJgz7q5g
qgeMr/+e8akIIM3eKJKhHAYiYSdye5N9TP1td/Dre/C1e6C+vdxmF0iKCz2odFrdfBd72Wm2eO0Y
RYx4DM/8s0iRDP+WOIn/hSQe6YKLYBhxJLikO/hf4eBPgsST7OouScU42WTnkedsfJ7fXkvnbqkF
+Ldt9pkHqZP4X+3g1W34fH3tVP2voOrVaR9P4iBkvf087n/MwRcACAp816W82TGucTvg6oErqAdW
bfil+DNDRo+QbglD4YBdoQwOFBo7yyKP4GPsZAQcFIGPXqA0/vIxAu8Oe8WHnR+8doTQvXWIwjDm
YzMRCoAKAip5U+IUtpKBtxVXLjDqeG0W92PQBaesnfw+qfz2j28SKkfqYAXnUnTcAXdLn/SWNpaH
rkdBwmao+cCHRxEMqPaTjgSramnlZtCLdVdD093u1K0oEWhnZpUzofu1etKyYSHOcShCdSecJgln
XwviPgJekfGh0CSz44E5X9d5EavyIgT7Ju4Y9VElbOPT16vrjc38X/b5i/r68sO/fz2//HBKr1/9
/fjjx9kX+Scec/Hdsa/m2HGQX75+LI6Uvpof9smXT58+fD7Nz/vT8T9w2gBvso0vF9fnXz4ff9xg
QQQfM3BAAwurT5qsNnhdhuaiimbbNiso/EaTfIaGMI7HgqWS3QgIFZpG0BaVAsrDEdiJxIuDG3wD
abtEj9Tuzs5b9ju+oi/+0N1n52103AFndp7U7BDeH10iTA6YylJ8EuNHYRWce+wu7JNe2AbtzPLr
W+vnQ9otyW7GQUqqGtp5kIUh82TeBkR9FdMgHVEWTjNVTkNZYI5Zva/NomIdHvU2IOIV3TFvcPLs
cZFgRN6fXLDXb1QYor5869wfPfZwysUK5aIbkoSR90+YfUJ7lJUc5TVRtab8MPsQDUE8I2J8ylkU
+3B/1zz5xs5kDMfgxfmH67OX24x9linivhFPmcRRx2wYy2ySsDG/YzxMJPMDVKaDmyx1PoSu6KwQ
c01KG+yvmUmWQhm1WYA9DsRcsyKvUmrVnJsjgSxeQ9eGkDeKVr0sjomDbvYpbSeclXXi92TMbURj
pPhiElZLrTdoEHsEEGauoPIDCwhXDBAi3g5EOlAkjgplmLwqZO+V8+11k+e0jhVaZ2YyCiEm317d
7IpnD8LGwFdwLA5f73swzsZkdZLgOxuDMnKkR+7u4K04eM1FaNDVZnp7KOu2eXh7DA3FTyilZRPY
GeFvAgU5CblHX6HR4qGlGswUKG8SGVJlsNUa7Dmvm7si/q246CnSfHfaOp0edHrwSd3uNBjreZYG
LW6gYPURwJ6niBhQiOITlADQLQrdR5iCLJnnEItol4AFsRgIxLievmInY07GnlTGwGePDDYPNc1u
j5w1FIjhVkDSvEBlcwWceZXNRWI3IlHboHQaVYghl0OwuCXbG9ryOwqdQ0E4FIQ5KIhpANSDUPSE
DF3LNX5Cl8R5VBLHibrbAbcDbgfcDrgdWEunZwFXV8++LXzAXJaMH5rjYVK42d9kAmm3UHfarA/O
CtqdgkK77qFWSXno698v0MPJdv54TIS2lqJqzAChEHPTLgWmUMTCp8N6Hwv+Tc3XaJjMoKf8XbTd
cQfcbX7SaLuvV4x1fURTsbQuc/1tfJfzAtIsgMdoLOdeuR1wcv60cn4iJ3dxMBylBPsF1Z+TVw3E
7aySSbFAQ6GDYaJIeYtfeC/zGTSEZmfXcQbsLDEEUNPCBLOf0YHEZnRUqpkZ7zzm0jsF9aQKqvHI
tTNrCAfNRDaVeJI2KzCwqt9wIvlQOMKsH6P2okwK1fPVINXHTfpxTpDTMavRMTUWQ9Va/b+El1Jd
vdL2SbZlbm7+W8I+imENTOD8CCv8iItZmzIC3JCn1PuIs1aHe1pwvDgctF49tuJgXxQ9Hik5hELM
+ztCxDxRIrYCMCS8JDiMGAxIwoEaILEmrC5Q8JqpdrJsxZFrZ2aVgzjJbnAtoX1k1GYR9viIaCch
brZZ0wmcxYtQcGBBY3EbiCmJHL4pHWSnaS3UtG1urJlxmYeuKKLL0QH+DZrDQKFDpRS4TojQ3Yyg
jd3JLC6DMUqDICBD776a5YGR3kQFhFcmMHjasTkL5yzckwKua9Ph7JGxhuRH3aqdSF8gKTmeyEjN
0hHfqbGYKLkGsRzrRpCN4ZI68dPS7k78nlT8gsgLM19Pe1svg1fBeBLSkAmfvb86ZR/zwI6lkL0F
ztIrWDwaZ7W/7aI7Uj1O+MBz9FlMN9j0CPHIkwofHDRN21sveHmRTeU8WSWBRu4m8QwALHmLipuv
3E2ZpWzK45hHKdikXIDnJC94Psmb0Vavl/whaUmpyuX2T4fNdgzsXOXNVd6e1hhe85uQXDAES6CY
x9hRTTTdde24A+66Pul1bYj+GdshpoMojaWf5YEF2+74f4ztPubqu4NfzcHv4uCvRTwOIhnK4V3H
Q6dL4g7eyvhzDyd3KlIehIhsNDD8R6LrbHERGNtzEm9f4mEfB08NEKcBH0YyQTXzv/Lx5DdATSXK
tiIZSeCoARu53wAw9tYdvn2Hf4DDPz/+fEzuaoKkRqyK9MkDh129Cmyn5w7evoM/JKkXYIENkLf6
ocN3B2+lnX+Ng6fYVBHeyzhpY9mr8o4f39lxEm+fxL/ByR173yI5hYc3FGNVx+2g6N3B9+na23fw
b3FylyUP4Q/Iuzt4Sw8ePvm2rqobSnNmwtdw7z7LGFSGwe2aFRi7SqOzuFYqXpI/PQlqm/yd52MW
f3UJfKT8uaqjy+Y/aTa/Xy/XPCY+c7fV3dYnva2NRcdad6qPCJXgj6oFALD+P7MgLsLWAVFBE0RE
xLeARbKzLFJlysfce3fqqzl17cyscpBORjyIqDTyAvWTlzowqWEhBnbZNInjOZjUeQwKnSzk8ZF2
SvDGJ/2/4X+ALo1RNrh8t9HrFXajfOlUDHgWppV31E9cKIK7ZMI92rjpER+AqR4fIqBqiMGr7zZ2
92ffXGYhXgARg9xQzHMq94I/eYb8Jbp9jnjiBcG7jRP0BD0T6o5WTkvouANOt6xGt5Bf9D9EhFkI
nm5ACMdLYyhR6wbasETP7+ky3PGQnePkrvlqrjmBdqiE7+clfOjsxduOIcdeliT6hd93F15P6HcU
eXfhV3PhCaxUVq+3qN0XccKSO7+o4Q/dhXcXXt8B+JPkma7et8RM4iZfXI3NlreA54CKDP1HwGWN
GTnRgoaRzdpA4Ms8xk932mw12kw7s4bA0cwS3e/nWw89fH3UgDnC1j9VrEmtFmBg3N7fSgbeVqEM
thKM+lbJsT90C9dwnYr1dHR3XITjVOSTqsh+rf1Ak013WTvugLusT3pZ73XWMC0DaGoG9HwW+jQm
e8DHQRjwOCcpouIFEp9jct4GSHtSGuoxl90d9WqOWjuzBlvrXLdKcn50jD6DhZS9l+gvqWx/8hdS
/Lc8REmgR/l/aL8iSEud60a74WowbgfcDrgd6LIDa+koIAiWgw8xfKuj9G6CknE96bDwATffMOC6
ycXe/STb7OYblvMNd918Q2Nz7W6+4ZynqpP7TY6ng8DkOCaDktluvuH8Pv8EQ/aDt9xlyNfSwTRH
zu9NOpZzBtiYfwNsOsPoATWhANlHGYZyqqa/UNbRwTl1v6RjMsXdcZdt1VDHD+YrpQLotckWG1lp
FhHRGvoYZDIG5P0IRYtIptAwnEUincr4G3uBjgwO1OGQWKhR3YiFHLzEF9wxweuqxgq4EUjc2txV
MysbRJue9wm1WYOB8tZg44Hw1bEdHa2W802d3XZ2u7vdznsM10uXlA2T7KOUkyN2PoDxrjdTMtXf
RgBTjFgCDWwWC1/bhY76x0nfaqTPamO+boOV4DcD6nMrvy02LycYnBSmAZwXlgZjkWD6GQshniSB
8Kid6NlHvWW16Ik4lrF26xoATva40BSPMumB9hLtwyORz5lI+HhRGEnocjl1Ns8FsM/XYA4EQz8R
qtNnzUSPTFoudCNMUkKv/5CGUXN2IzMMVsJQciWcdSdU2wTncLrs0VNPM1NBj55nsd7sYZQHk5SU
ZcjV+nPHcpbGxZR4Mva5CFbtI3fy57zOZ2NXIeOHptZvQi8aWC9/yuChfHKDEYELaZZNFGdjjBCk
iYIyoi9IQCPndjq383ndTkyxBNOuPrDMetGTEXrk+RBVS4bQb6mLCacUQ2/wHoV8CUOGxhk9Z/Se
1eiB1kFOa9l160UP1o7aHOsRXVlWQB40mQV/usPdMc5zhU1XWllNaUUzFA0CayZIggBJa13YvJoE
YMupQpWaFFFEDoA30s6yowZy8rca+bO6vkLZT+3SNSgQe8orMOgu1NUcxx/qrHFJ3qdO8v6qoa5z
s/WkkjPzTtc8ta757zTGKtXhO9ZbepVIS+QS4ATQgtlkIuOU3WRBmG4h8TYopjMAxiQ1h8eJny3i
Z7WjzT1PjscS/vaaSWGiYtzkN8qzodcvyQP6OSHyXPDG/M5JnpVJbaslrxjao1299bB9lNlW8KVY
eAJlMzVHgoOTmbJOJe2fHwwGAF1Q7UnbAmf3nN0D385Te57TmtJfD8mbBuBAj0UCrLySLEy9ICnD
sDBiRvdEkihoIWYCJHkvKo+c8DnTp/V9PYPwwUBo18564ZNxMAwiGDcye5i/oU/r8yXQvdTcQtQT
CAFdPQUmrqRJMo0sqKHBGK6m+k+be2tmVZMnSTaepND7bdZgYGGl7zK0utg4V9kWV7mNxJmpNZCh
PW7z9AbqiwZN3gB1QBZINbWFtyCGivDfmI0lJiEuQ4I4wbNF8GCzZ+38OeolcVbEWRF9B2y5zG30
sLFW5GsUBt/WLOxbMCVESbBZJDrBAAbzQWGfJzHXARNPkAjleguBMyS2yB4Mib3ipxoY9ZtnT8rF
hX2QkWq2xCkNk5RGn+btnoqUo0/KZ5fizyyIc4Y99hFD1DWl0fHkXO+Gw46vBjt+jQrunBY5ESCG
GcygSkhzF7XrMQpLwDTN5rhVHB307T7m6ruDX83Ba2fW4COYGWKsXU0Jk6uDIbgpBvd0ClI1N5Fh
Rll9x1vewk0q9ApqnDFCsstTMeColb/b6PV+tsYJIjD6HAU+JvRt4AuepSMZv9v4+HrvoLdPrxDk
jsb37exv9Q63evvXOwdH+2+Per1/0kA/POCZJO2KH028YHEs4FMCJMhPyety81XsdV6FWoTh4+P3
tnf0uA5Lx5rpqedLV8fV7gAP9tQBmrX0fpmnKDGPSHQnKY/SgC+UA5et/2Atj77qq2tmr9wCkgI6
yAlkUGmLipooX3pCBWKA/C/dgSIq+TV2wKRIs6Gexdjlh3//LztHyFCR2166A+zT16tr9vnLdY46
4RH4dWYIAFS4iG4OPlPsClzaAF268pZBUio1roS9uDp7qRLPvpiE8g4pCR/5CC8N7+jMJ6O7JPAQ
wI1ApQQ6JbFZ13yLGs/J+ypcMNB9Nco7Djz/j3Z4uLj1UZ/mTvKs1UEant0eUEEVMfA/gzjNIGOf
uDfC+Ppkk7AEpH/RaXMDlCD5XBTT0RgYV4xuEbQ5DWSaBiKPY9d5HD9lLLDtHoeAmqOeA1S4ycVA
n4+Y8BjJDcZ9H68nNB6Lfc5nYWkWy4UXVoQXpbfBPuSjo3J7RgPOtNOcHlEnKSoClzwaCpUkRoxI
CbDDIqFleC4I+bngL+TcYLoT+MiUW0Xy9Z41wj25Z4VX6R3u/fToloc0TTzfGqG6cTxBO4Lrr+q6
840r363+VvqUoemkElmnPBxtn5xkl6dWxJKry+WueyARrxmmzJNbuTFFzx41xzJq2YMiWWJMqwrZ
iZ+GkXHiJ6aUtX/KKhExkiOs1W6e9YG8i9GPkr9Kr2V3aWrUGXe7tAv8dyJZOmLkhGYR8r+UgQK/
MEIygTlPsDihxIvIFZeFwplnpwm3O3jrDl47vwblbCaeB8WJNg9vT4q4Ao6bTWFWkjjjJFKN4yAr
0tbdUegcZtTtgNuBnw3mMgCLsUR5JxMRhhXtbVH9773MPO7zQAcJN63RQCXf32RARfNQL+AtWQDV
YA18/vuLyx++g6sLpCVfvFTeACNyuMkIqDjLBBdf/H7Bh4Lt/fEYg7WWoppnbA3O/T3mxJx5cXf2
SbsT+udRKuJIpFunMR+kuta5OjupIjcT/V367ngSB6HSV+6Wa0lRF0p03AEn508q5/f7IIVgazLc
4F9VfGBzLG+/DPjzdFubddjjJyI7k0PY0OcH2EemGgQTT07wTdGwdHaiLdmJnksexoABPUtZCpGx
FwyKTLd2DRs0iD2SJwYQuVQPOzvKlnPgnWFfjWEn3OheM260aCtXYOnz48/HgBUOwaEQ39EY6LI4
pYlzx5vvzn015z4L0rTDa9DFZnpzs5Kornob1lDYk6XXs7iEKLI/dQ+yAWnrpTtQGKBiB04FAJK9
3unJ7u571Wr6C2zL9Ggsb8VZLMcLaNnXbbttD496+6rbGPsY8TGayel37r15e3i4s7v7OgfdNmFy
3+Rvl0+BX0FI3bed/7aCpi49SMPRvlBJZI32m62RapcE8A6dOxNwt4kBmnl89PKAyY2CnAZi0HJH
Fb73oW66X/vqF5dup/dL3bqZLZxbFMbO0ZvJ4zTwspDHm4rxY7GRt+IeaXYUOtbdugdAa/MtKm/d
zq9563S/OpUsSSmFk95NVGNwHQGWT6RfJM1dvHBVSwP3p9jmws5oHArO/C/extYkMTOr387yPr4L
RZ0gVAwyq07RTB9Exy4ebWvmnI5Ha2ZPCTlVB6VThZ5AsMyUiTjymubMM0vgpoWyccZtPidbUUE9
hMhevHOtKYvW4s7NXCoMWScoc4hhqkz1pXJ/HESUQkIRBsT+vhzzIPqNBeitSdhEhoF3t3XDE+G7
O/foO9eaJmq97hyHr5OTrVDz6xzM+/CNKn0olQKYu0xF5H6Py1TlrXPJfJfUXU1Slyz9YWnp9WiV
h6GcsjGoFYMJehdzo4/xg+QBcDaEKo7q4vFQqqR6592Jr+bEZ3Z2IUrUTrMhJ25mXv8FC7b1jouG
x7emRLy9WSctmFNZ7hx2yHpUuCyLDO9lJVFveH5X0zna9UQUizfV4xuzhj4v88nzeUUej9Cjx8T4
Rvj+oofqFKYxp/cwkE27gA0Kxkz9GOiWuuHZrVGO96jGLoU3q1Uj0dGlKWibkIJBoKzdTSOV48yR
LFikSuKL5OV2/eG7aEUXOjlHesWO9HE5LBrpqAxpKAV0CiX3kZUKeeSB+2UTKS18n4CyVX2Xysfc
eXfiKz5xiqG0A2ywqGZ6A5RNHQd/rVfApMrt6MnnXj7nBqOcMup+fCG2hwimbu7YWHAQZqjkxUg+
aqaTkz8nf8APFTh4LyFqwJaZd+Jbqk1VatAd9njjngx9IBCQQ4eUoX89BVU50SPnw29eAgkjGfcI
WiBpXoqmOOGqdvH2nOQ5yXuE5E3gjgH/p91A68WPqqGpiOBoom9rIqhKCmYoojbwXGTlmMn1HbCr
f+09Iqu/owgFov1EzEtRvrgNqBBFDYxBdCvDWwRd4NnEx0BcHdObmoiv2MhUMvdvOmTuDwwbI2ZO
V+7DqVq7AzRfhKiuxmvGyonsSBuIxaI72NxUor9zUStsFTOAEsSExAOO+QsDUFLgQySEoAanyX37
s28usxAvYEKcLJjO68Pzdro0VpglvEsVoL551dK8/s4Tbyv4SeloWoxWBOTIrG2tzhfc7QJFz5dh
WPVyb3t3sX55MoJ3WR0VXDesqgr7Y/eL1v+TZXS3CwTbrMu04j00tc1Q10XPrKUM2JQcFnwtF1oM
d7tD0qFnO/cY7u7PmwyvJX6Dmob7gzBR84v9T9ZOeC37pDoN824MuuDl1eoCbspbZ82yow8HJ5oJ
bUg/mVk5mnc7tlmDPRnsn9K66SQcg9DJWEDNaZR1pQkrJbwLRsdJeKWyhA186lkgP7GzlOShQbsV
mqG0h8u7TkvPQ+uhcO4gNZzMHbEuCcUGWXp8d2l+UiT2SvjzJ3TuTitl2CWp1HCAv1QPqbOy7azs
Xpe0mlUXa9bA0sYHNdOPDpI2z26P//wT+3WdfLeU7y75Ziffz+tFAwq1XgLepnBXd/vy72t90cha
KjYEzanXuWSqOV6H7neIt9Ug3igR/Pq+xmhiM531tJS9tKpclhDg8cYoCIoReV6bACRt1LeZvmUS
0K3kkZBZEq4ZhEREkDoPYK9pkI5osDL+fxk5zLZ2fGWaydmcljvgbM7qbM6b+2yOAjiCJXYRpwGL
o935KjRlrwsoAiCb3j83VEkN6WbF4luDVancPt4yMO2UxoKnIOH0vok00TcESsA8woAbEcpo2Hxw
XUr8lhxcH1A8bcHlwXTU0k5HrUZHrUH2rdZ8e3+NShU18D8GzwFciELKMn0T7+siCMVF4M074DTN
ajQNReBvyRvSzMX0qFotViFYgSvYK5Bq5oSZ/WtqSJFhptohP329umZJNplg9I9qVeE3QRikd5Qt
yPNrs3yCtmJnGC3QwTOzuHBdLRrojLGcW2gkvAkRYecsq0kZac8ijxbx9v0GtbzOVTFGpasmxC0j
1QIOooAmuYV+XLfHCoMa2pfCyVDRV/H149EZuV7Er8/RGV2MvzN9qzN9Oz3YvkUDAjI5ElDVU58k
0gvQUZ83PlJeADlpH0zJQeQ5gos6CNEcv+BhiHBZT6h58opZSHFi+xjtnrMsvAiiG5lF/ivnNNRQ
p8YceMiT9FJEmDkk/As+FO+RpvqmyqDpw1dBO9YG02pmJQITZdXNbLMCA7Eu/ZdEFkSOD5jnB5h/
wECukKIdjppJ4bNzVk4oLZvOH1V2cLZ2NbZ25rnXxjdlUTBTshhG0KCRwSwVbGkXvPRvW3qw7thX
fOza4VmlXyvXs80iDFSxDdavUdaI9BST/BA63gSR4rnRFu5Ez2VKnmc2ObyCWMiBdvsadIc9YqcS
lIgvixyl8B/lzzjonjPtKzbtcO0+g42wNopznCUpy4ebwIsv+KNmaROGJKgm1s6o2GVUFgtGFmXg
31Mmh8d3uLdgz1TpnmyCyWeCj+H5UFZ+GuXf6rrZetvDPpVzhpz8Uaqesv+keZZUBAzEXc1i6PyL
2i0e8zuagZLXOO8Bbzq1a/exa+fXoJHMzFTmxc42z2+gN9/XTUFHf8W56W4H3A64HXA7sJbh+kLs
g5pVGFas8MIHhjEfV943poia9uFWetznQfyQoVZrNNFSEyk7Ug+6wW7wlAx8/oZ0feH9f/g+ASgh
YV+8VN6ApP9wk+32dvZrsQH7nSrgbP8P7RA7Oi1rKarmSFrDOT/mxJx5cXf2SbPB/XMMwYgjkW6d
Aq2R6loHOSV2Kf7MoJ9ovnuiv0vfHU/iIFT6yt1yLQvRUTM7OXdy/qRy3mCbGKN2kZ2dhzCz/h0Y
kAMP5Z87VnSTl9Cexwi+O/TVHPpMkdeAspgbU4NzqQYGrRWnKAGOHFGHzeUGTWobQikzw9lssjAN
r+H57QkFAdAiQSN6Dj/mU+AmAaEV31VLwrBUtKwUVu3sOjoaTuOuWOPmVEc5tsIXA8CiVZejmq8a
ienCYefNyOrz7tw1F9sufIV2eA0Ky0yFy31f3dE2K7BI5Q7YMnHLOzfRgsFG/JY6Fgg4m89H1tbv
1K4Tv+fBzMpIu3gNqsMiwSMQcLNzg1HjMZPqMwWeXVu+kzu75K70WR2nylJae3edrbjOKkm2uzRJ
hkLwbeBjyq7gkWIw9WSUxjJUAd3V2VYQDUSMBlanxZzzHgTvNk6el1Ib10/G48WeL+vdCPQgABwb
oiMc0Fj46wkJIYhNF8lYVFLTiZ8TvxWI34THaeBlIX8QfEP4IQOd+P4mCVWNvQi1YCLgKhvfSmKV
SSxu8ZYTNSdqKxA1hIzazbPewonvE5lkMdiJcjqN5e3dlKMK5RA0G9ToFKT6iBwXX1gRX8zqsW1u
sJlZ4liEoNTSwxzrRXAiw8ALAM4sHUyq0tWMYd4Eo2NTO4rdz0b/gLG75AXsMHEaKBDiMFcESwYQ
+i3dw/eHu8fHavafolg/FQOOBkhiWi/eWS9Kw8pBdpjvXBykokOsciKutAOyv7cgIgWxfGWRHUbc
7uzOGfcNWqSmwHGFF9fYYfSokQfZgCT7dP2VxXOs6NJ9WCrSH45f71VE+iImaa69WJHzAsBQDFm4
qHy4IvqBIkYNxQCq4XU+XRl+QN4UXLlurYeIvj7qoBxHx1GymOjxEj33o9RscJKof5O/sJ5bHr4r
hthNj5K/TkiHV17D5tkXV6jE6R4Sp9p9qE7Z2O8wcPMgt1BK3IsLcKl0//Heh9OdDWPUQIOIaHuw
TDfstx5OOLuQC3tRkxxNnNpv0BPf4elRA4PjGTGx8pTPhpEMpaINHMUyG47AHUiQ9NzjUpAYREcc
/02nkoX8TsTw1ACcijw+SZB0UcgawBeQIUS6kHy36u8+asDasBf4Iy/ZSHAwT6qoCvD4qYy/sTSL
IhEW72yDZVYm+d/W/iJVAYZCVTCBIRBsAi4VJEwA6sJDeDyjn8GjkMIsIrsJT0flE4ohmoGKUWio
knpC4PG3dfkp785Sffo+F4ZSPvILsN877O0db5QvVvWppn4fpU/3OwzMKUR5Vc5mOwU7NxX7rUfK
LJdMy8TwQo0CYoOYD6nxIxckD4lApNxvBXhWkJsQsHK43RgnRjIpotsglhF9mk2J5Wv2wxC+crKQ
Eoc8cQ9qliQRY8WZfiNQowB/loj8giNUcfVenTEZKVHxRqAP3WbnKQsS9AEmkkEcITKRBGUzSEVH
mF50fnF7OGMcpUeVEbDqeN5yEXiOGwwNgOTh77DkLknFONn+v/+ng2gVcdoyKTo4fH+cW6CCe2Td
CNVXGzxc49hmEyGu/v7l68dTNgZ2chz8NT9hdU1/oxs5T7sjfV03u47Jvb0fAClNj5OA674rBKCD
g1B3bktHttEJmGXD8IV2eA35JDMTYup68rDNAgys+zS4sAkaseG0UJF1xuJcKTGzZCSzEIpWgGw0
uhV3tYTgUofFadXpEU+85y+ZNJxxRfzaXF4zpS9YM9Qk+S2V4EXPpWnx9D55+TxLRxKZlI+v9w56
6hX8sKD0ws7+Vu9wq7d/vQNPtZJDK52aSkKlfOnpnde6ibjPPW82G7XbGpfPX1lSe8v3CAP3wNOr
8VbkMxcRZqEz+a0MfIbJViJWbZZh0f1DJ48YlqJCFCJeCKV31SeUyzt7a0a7n4j4NvDgFmUYZxJI
1ALgEYF1v/Yyy71qbdPuDSyb9fTPrl+YWn1o3gHXVrViP/EYKK/rYt4Eoskpj1UsiQAyzxnd8ASx
Y4lYyWioSAromG4lnHtiV7WcPBVNf1kVIFC3J+rKbRZgT4AAGMAd5WQgeMhbgjEAmADUhRKgXj2Y
L0rD0rBpbdFO7JzYIdP++Xn6qcp8oA6UatAcBgpef5Gk4QvaFRGVy5gKFrP1KWvnBM2+omklALfZ
vt2sGR6zcCthz5RXialmWxTF5Z5lYcxh6mb2D53DTvpMlb5HzRa02+9MUM+zVTQdaXcNBeR8Z7t8
5/fw3r4MUB3J4gQTdhKJ6cNXZ5TX2x5ub7LPx9cvGQ1+KKB08yDKmRJTTUkDlEnz4qxOVMzCd+0O
2hMxNdS5CpGbrY6SE0lKSJQyhJpDV15qS3dK1y6la7e/Jm3tHW2QOxS07pSN476cgNd9Pg/6RhDp
EiCgLzRxW6Jp6nT85pCA92HIWz29iamlTdQfx0FKKDltDU7hOYX3fBnaNBjr12+JAjC0Xb5B5QVE
so5eDnIxuOcJqL3Sx0heUuWyCm+kIqWTPsu9/c9frgG7wKmD/ScndsV8YG/EJjEHKAOlMB3B01HB
/mzARQXo7hpGCT41wMkBNkRQqjCICDiV9ynRN5dZiBeAsJJFr2y9r2y/S69mDsFaVR8E7l1N0CpX
oUs3ZqUzqz3G6onRxW1aTve7tGNW4HLGLHK5xdnXcRE4ZpwrPXPleFt3Px4e7Rya2Gz7lVA8aPsC
kWvenyVCNaekbjwXln7QoeewipE0/NDLpKFqwlm6CUvNzC/VU790BxyuzzQEuuob3l9KuEie1RjQ
PXRm3jE0kWXjSc6gHrGRnLLL8/c6ssOduF2x64tLgOIIQnY+py5k7znAzy9VM+4ZDpi9QKNwifGs
fK6u9Fyrl+kmq1IlKc8Y8dJETqh9mxqf2cWMQi+8Uz3f80ZAXwJSiCZQd+w1J96cdOhy97Ry6rqj
2pDpMbPHiKyQdvUant7ATG/DsSyaVNAbp9KTIfqu0TU9FmgaiYJknDDQGBCrgrZ+Z2rtMrXa4TVc
XjNF7yYLQr/N49sje6i5EDMIkamalRx03VgG7IAVikVFbQdLozZ0hKcxGPInIO5AYtwX4A/xQRZi
VBrcgHN2JtSKmz5zYFXfIap3zeS8RXuvBF4cEQ1ydEP0JkLHuyxFvfRgU9RiOaRosHa+06wIMDcz
KkQpOJ900l5t9U7l2qVy7RY9ogJM9caghsjLwNBlSe8hwpZ5Qq6giCPBcyJmcU7ObhGbgg8Qk0jW
DzbLErQZeiPFeYhMXCRp8ANS4IimQgmuLSJ6cdBN2HMneqthFOtnCpJBDBCa/rfHwjUkxudOJdju
YpAixpmXYjaLS1/osuZ8abt8aWpHvCZTEvyZwZAoiCoHT9LFxytFrB0JkNQA+V20I/qotupm1R24
XQdut2cHPvQwA6+QpcbFda/XXLOO2uNnw97ty/e7HXA74HZgLdk2gbSRgw8xsdamdxN0mNR7XBc+
QD1wZsIz3svM4z4PdF9xSRSo1mhionOTgemch3p8t2QBdvUhkveH/3z4PglAe8C+eKm8gXd/uMmI
GDp/c/6/v1/woWAHf2jeVkeTvZaianyh8jEn5syLu7NPSubcP6e+WPRsbZ2CsDmd6xv6ihj1Ludj
BBP9XfrueBIHodJX7pZree6OmtnJuZPzJ5XzhlQ6YwomeLgUJoi5BujhAtNmPp2AKl1quDlmYaqh
YkF0K8PbWgKo48V3x76aY5+p8jpWDr0F6PlBHw8jFtW8hskSDmY8NdPR4g6RPWTUb2DpNEtlTxTh
8pWPy1c6TbMaTaMMzOulBoa6h4sqwgJmt5y6mmshTWZXbGLmrA0HrUcEHx7t9hRrgzncIsbHzTMT
ZTPveh0BZI+9afAYlStwflHYUvbiRpRTlDHSB/+fw5+I9WI2lPClnrhbKr6nJwdnB4oEJU4C/7Iy
E7l4h3qnf8o014r4dhiRbJj4rngPDajVVdlzDloPhJ7pYdWKb0w/PsiRDmYTs05Ah58EAxrXg4Fx
1QRM3QoqLp2lV6HIJ5RD9yri5DINzhFcoSP4ptERvIdGhmDtAP0NIBN1EXCkIsYosQaHYS3cuEBv
ELTeiwP1KZqAbyQgwooGlQ2DWxHN83wTGQbeHfCI5xGTCnQ4xUCrZNOJn5bltwtuqB1ewxU2E8Lg
aS5Rm3UYCGNo0I8xGEzzpOuS0EkRveTCuKUtu6PX53ye1fg8M+OnHZ5VsncDtjd7Mb6MgZwOrVhJ
yiMPM350TcKoR5KmxOVT5FAfSIA0knpDthM1Z+aeZxrq2iUL0Z8l43Gex/B4HAd5WySHzHkCHqfP
Jtz7BpEre10OttJsEupEbk7+nPw9j/zpxqGNyTbQzexvUmhHpsyLAwBKtzi4WWH58KIfqyiPWDhc
NgWVOGgWF84FwbuNE0xADJ5vpoyIhhjdIOK160z2ZITqFXFLIXOfbGIIuCLG9uT4JohyM0jJFCEH
LUpiLoffvAMunl1xPFtSrSUyBEE4ylRXf//y9eMpDVSS47H0iV2tZkArhdd9muWCoS0jicEuH1/v
HfTUK/RTmO6C7oet3uFWb/8aoy52D+bTLspyFobB9CplYaXDocrPZJQCm7gatoXl2Z1bDr2aIrwc
6LsBy6OKd9Mj2i4Uyy95NBQq+YYFBP67jYODYqCNMfn9PgcEMEYTSpSNqVGlFibrS4FjVF/IA6d3
ld6FGM50hMlcZJDyXRE0sQmBO+1Faa3nf6h8V/tL9DH14VWWhip3vcP8oeKuO4wQdIB+4ms/1nct
Qo/lOhADBFBMajYGHSZb2WIM+iCC0hY81/e+CEt11WHa1ZKFnwroSePsIJZ3Lb6n/TsGowbbp7ah
fFGpcKWb8QrZtYqa7DAAa8lmXBq4FQ06a7PJE5hvxmGHkVh7Oa5UeQlVC3twsHO4e7xhjPewXDcE
EXGIUGfJTZbm827VJINNdqBv05KSSb0lm5q1FXiQ7oJpy+8v5jWbljTPKZm8oOXnyUaCI/5lqmiU
K37ogM1Zmjf4C6gDKihV3oO6QAci5rEqO6E+jri5QX1WhKQD+HqvMhHR5E3tU7wgs4SBn3qcpSpj
8PBGdICx2q0t7gmjKveiAxjUmnuBSBnzKHgKkwpF2cK5OHxciG22c6GSZw1OBTytxcDv+dDlK0xC
0Mpp+u2P7UChFi9qjtRPgdybuikuv2hUsmwGlsEXxIVI2MOYvAmgFWPhZ56owzdCKb9tZRNGQ+o3
MRALM03cGCzIv8VVLboEmsuzxE02l2tJYvzpGE5umxXM/XzDgzSisWYJue5IY9PXerIqH5PFXojt
4bYDCDvZW5FN6fPhkOb5UDXKUvHrvyzLaArBMaH5XAiVi6kpJwUIWsTK/02Vp9fk7zW7NsU7pHOc
c7cuO6BqXoXdxz8GVkJh1hUTwNulDWBJpi57iUuqWRhNnJeGN83X3SEFVowU0A7PKmfO4xN+E4RB
Wq/mNKzCHoeOUBqxSrsjtCKPrs4CxE5GHCk17eyc4FmhZSmAUv/RDq/hyprZ7lVYA2vbThpqIxVC
LWJW9OUYMmaUL1fJoh+0h2jt5RAtU2ArS/XU6eHrs94ZrWmBXyR/56f5w5U97AD92Ts0ih5oxXu4
QgeWVt6YRXdu5oqC+waNmscU4ObB4BzKUZVg1E9fr64ZsYsVo3IYTaC7W/RyVBu8ZieXXnx37KYd
e+njWJwq9uRWKMHxs45eDuOKO3qesfoNUUbOD8arDGFO9Cyu1GiHZ1d8MREeEWy1WYE9Qb2PRSVI
fhsVUThPzoAdsCtvsdBa9On4H5j+QlzkRdsq3LqtWg2Sp5TH0gTauXJ2nTv5dNoBWmVTQoQYYZvH
t8egoNpfzwsn7EWwLbY3ycET8W0ASM5ZFnmqAxBcKtr6nfw5+Xu+nnIeJlK7fg3awx7xAwZgHiOq
aQyQutLsifglTQt2Jg8yVqbr6F8ncs8ncmA7GATDLGc7WC/Zg+krJa2gYc5p+jAPRVEVYekp+la0
RTt754Tv+YQPnD7a7bPe3BEMAXMwJ0SholAXijWBXuX+OIiCBMFfCv4iaiwNQKmQjriTP2f8VlSZ
6Eu06CF5r0Nk1kIIgU3YEhG/CQE9NRuj0IE5YG/P/Pr6zu7O2Znq26tjFPR3VI9W8dJTwBY68BLs
vTVqW6uMAocdGAWKZZgVPvQJL6vZeHiYQJfQU85BJq87cAXsV9qg1VqLiGmlcOH+bu/hRXbp9c6v
pFlnuRy/8P/+438f1VOeeQxrwsHwG4XoaqCxQOqhVuOl6U8zBw5UTmpwaN6zcEcMD2XyPu//B2VY
2e9fDB/goIzC5BvpBUQeRo7fJCYrO8s0KkwqO/fJARwQXWEBXs05ZBMwXNKfKeM24W/re7tUejr0
zu9XmDbMkR46hxnuBSlY3KmUtjHDxE5ykZeVRRaVSJeeeXvkq35BH9YzHbrmzbwO0yDUqxBLb30X
cKdFxz3iCA9JcQyyMGTfIjmFDwvCOsrmyDF4paFXEswzJ0Y5ejEpShiDooShZk5CTQEsBrYF0l/0
ywq9hXTr0vuzNO2jO2zVcXZP57e97gI3NctvW7qHBYXPEshuhdznpzRwVbypDiFF4U2ZAnvWnMIu
LnweGdngL2m2bpwlMHQKFhAgGRuPha8ch0j6mKfy4ursbJN9xn8hxVdnL8lXWCq+2rZ1CBmqvnR5
RYk7oyLfBvOSorb04G686RJZ7C5naTVtN/plzQK5jRe4GZMsGQn/5cN70SEAsftmtLgXXXzminIx
WUr61Jvz8C3o4CZbfgvI8Xl4P7q4y5bchOWRui9SHlBC9OE96eBb23JH+osMrsvCijcdHNB9WwxG
vfd36cK7e43K3TJZIy6XA5qT9bAIdPA+9y1RC/3pKPBGjDo2Ho6v3/wyfuQDIfSDV+XtOvqYlDgo
cpIPb8Cv41jOcruYDABvi3kihlEFoKbIwnhEOcAwPqVI7y70MSykLd+uoSfaoHe10PfhW9XFUd23
JHSrBPw5HWqS5jOE5oUE1c/JsgkNEgFvEieiYVgsX4xRXHh4134Zd7ZFZeRtFz/WEmeuQbYevhgd
HNsCaGBDOm25J7c0F7uKfPbbLl61BfQJe7s7xyfvl1FQFO/QnfnJ+ey3HVzxvdwQmJLPXnoPV7KH
Xbz518biYXZ6XXztXJ5s0GJ724fLFVk1s7/Ta+1nvz46qBT6qyH627PXbw5PNtSmmADQ6J/ylLOL
kEc6FHhZimKn18VXtuf02SXquUEsaIYa42MJAEi9Me1B877T6+Iu5xJulmT0E3JzKWergqilK16q
T5trrD/bJhnRBj0v9O7kEwfbzSDct0ge2p+9Y7VZEXa8IQwpyIx2lpIZoWBLiGwqYyO9hInOfolL
AewtnQoB8Z/qDZBLBd4dummHPqMyqtst6rWObmV4iyQGEmOk3RMOVF/9c3WJXxx/4g7d2ENXmNaX
KiEqMQEtFqHCymZog1InDixLWo6O5r4PfG3CgH0NkdcauIO3uPVXO7yGviEz2VmhiNo8vD2N9qAk
o0AqL9ksVB26qNNC0f60RI4BTrPzIqzoaqZeod3dpa5jjpEs0cxlFY5mtgMCDUYJ18qOlCeuuTMm
QUCT1zOM7Y3ZZzGlVLXgTzo+YBF312AK7bEm5KdX7EmSDzKb8DgNvCzk8ZFmPDuqV2dg3DyPJxXI
xtzELExdpOcjsuXZABfc/nxoBhgaJOLWW/lNdxc73nh33is+b7tp+fxgMBAxQYrWj2k5ESny/oM5
/IV8vEVivsfYGyd9BkjfC+0EGxwkM3MFRJbV5untce8WhA5ETAygYGoOuIjlAF0CCVHzHVP3On2n
Ld8ZPyui6ZmzY7nxE5FcO4oiDsBwqpm9Sk8fXE6eg/TLMsljxM9FW24H3A6spQ8I4ywHH+IYKa70
biLebSQTEYYVJ2rhA+YOHX8vM4/7PIg1XbfET1RrNNDV6m8yqHQe6rWXJQugMzDw+e9Pmnz4PgFA
LWFfvFTeILN6uMl2ezv7mo+Bb36/4KAqOfxDO0TnL1rgLz7mxJx5WUvzYg6LW/+cyFEikW6dxnyQ
6lqHxpBWALSJ/i59dzyJg1DpK3fLtQJhR83s5NzJuQGpxNmwlhdie4gxLqr4H6VbSFRBS2x5oyD0
F159jOS7Uzfg1LUDbHCrK6GPQcaL+1mos7w3PL6BUUH/pR7POIvRcQec7nC6Y45E8hIdnKT6VJO/
kMC55eG7jd3eRgXGhaxOn6MKcyambZSfgdqjIadQFJUSloxkBhQ49YUosl+fVamSSzuvLd6JnwXJ
hMUQTO9ubbB/ZprvVO9Ianh2e6SPe+ARHkuiF1HdGZFA1ZdQFwkqwKo/q6TiTpzt1wG1TvnYp3w0
69EgvGYqnhtCYLR5fHt0zyCI4AyhAhIRipgmYBH0q0CcsDG/I19gXgrXFu+Ezz7hI0dAO0SrBNBH
yctLw7s2K7BHBgEvERw0kPUW3N/IGwAODBNQgsiHU6At20mfk77n7aqJ1szvVn42hE9iMkcoObgP
qMlGJMFQNbHVxdEk6atSjrSm1Ht9VFBDm0LG5QT4eQVY0QIkOU/qbEwW/L1QTrdCcSvCqiOoh5oN
bkJhZJfaot7xwfG+4jisDx4s3ln7huYHd6DgAVOjF9dwU6ZHY+jWa3nJo6FQIR0WHPjvNnZ6rbkv
obRy4jT8aASikncb9Dv33rw9PDx8+2aX0rPln5n98tYUj7NfbhbxVkOWtqDyeYN+7LptSspQLSZP
UuWMsoTm1p1f3O4z0NS+QjoJXx/qUg25zU+oT8ZtkZPAXeB8e2Y3qzXxpW03a5YgvqZWS300dj6u
t5yQ/YkaM6lAUBBH+YJyCHTH6g6Su1pLakgkZznNY+1qteYDtfZqafejwaEwM/Enov/P3pfuRm5k
6b5KQAPcrhqkZKV26d5KWGtbdi1qSUZjxjAaFBmppMUk01ykkn/1a8zrzZPc7wTJFCNJlpJWqTIi
fQy0S1u1FRFn+c72HaTjXX3oquUA9qQdpghQ8ebH8hb0b/muQmUCClYoZ+wHauj6Rj8+uw44hQ76
3Z+bJ5f1Wy/J455fmy8kA6X/PNbJHuV+GIG7UfEkEAqsj28zDix6QL7Y8FE6awbHlS6Y8lLK2KEE
x/0OZNhGrjluDbum4JhYSg5rwZdQeZUyAqOdwJFaETJU0ZdmV9hrdvSac/OLW+s17a7IFeyhMtHE
3B5sjCFBSosg5FV4VyZqta8jxv5nqoTfRFgpVeZQtCOyJnfU5LnZ8K3WZF2YGGUxyvqTvcatKGvu
dWLW6tERUNYHTGj4E1DT1zPdrhNS/nE2043iLRvonGFzrpimBt+71JEru2xU6cSExTXPw3e7oRbR
9GsSbg/Kanma84sSd0HjT6kFCpALepw0qb2vQ0zGXx3xV/eKqyVF0Wl0brd6Z6hu3/i3WZQly9bg
ON2+W+zoracjNbtmtGpXOq/6XfoM+oat8NOrj/3lL2zbbR3O2xdYl2X2L8MBiifIoE/gNlQ/1ruV
9fW/en9HeSn5Fao2JZR4cENlk5JC0tqVFZQb5S2eyKGDUIUus7LIsajwJ1j+QeUX7AkagggBP0Tk
9wHaJTBZujX95DIL8AUsjYvybibFCKLtmex3aA7YNs3SVCwmxmnpMjJs2sZtvN/d3M4X5tHoGw3b
9rdW13dW17eu+9iXmZ/DLBAywF7Q//33/4hjrLeIoyBfk4lQdLotctaR4fAtvVWFuHxbQdroUKPZ
yIM8pQKmrozZWu8f7x+SUM32mBbfUSYvj05fpo0G3IBmEjY6VEaKlzRLlZpjws21XfHp8EOVP0qf
V4LJbtepduPMrA+LYX1QG4Q2n9kg9AkkA06K3UGovhxWeg+jsNfUV1jHMfzuxq4i/OD4oIoLndCV
4g00+60YSifNiLryl8uz452N/f6vyP6ch9iUVi6z6VESaNaT8qsr+21HplV7vJbAxMxWz5JqYZ4T
2NMORk3bvCKKuSP0G7Br/o6ar66yySSKUzGWTqh6lTG66Q/Rn4yWZWq8CiTBiKKMUO60RgiuaXMZ
9c8Z1zN0XAx0XJK8vuMqZKtJYItHtMefZFh9FSitI7Lfoyj2qM0h8hRZgarMg8LoTSIZxdlsce1O
mV+BKoScweba1lqfXALFG9u76zu/zlBoflkbO3oLpmRmf7lgf0n9UzWgJMMEQTdAElHKhKlwAzA8
+kPfVYkXEaMGUWuw4JDbopDbbmONfXfLhZCQpE7z/X1+SElMjE+rGVKQqz5iKU0Ono4LJZQxrdzU
LqCj22Gju2Cja7f6zeZbvwyJLMgbUFiS8xbUevC7eDVGc2xYFmxYjpvQnBvFsQyIMHgGx2lD/exQ
tOU6FpgtLedlM1NndJPI+H7ZpuqB4B7AkqFG6vO0HnsXPcHFsNUuK3NS8S5+uHpDkUrggwoQTYpJ
ogKXYRYqWXcCood2R9K944oK5Jx9y4GTuL7/zdlaxhIUd6GfjPWElfUxC618oEKmSh2gwAJ459Xm
H3OyCf3kbHTtMrp25wpmmf6s1zvSufqYcTpyUswZBxEa+EESjR/CWCIMD7STQZ/u/Nj+WGF/VC/u
VmMv7iQG/TOqQn4IMk8faYVZfRDvo2jCgj+D+ljwrRD8aVZFtZAhL+GjGblcZpeID4f/RYQSii0P
iGtcUk+k/hhdyijfzGbH+dntena78dby8T7UnEtOoPcGM64RxTxOIq7OxNXEj53gbU/cZPqy3gWr
HwAg5s3UhOhGB1KrzX3DJsDNWcjcPAo2tdrFB1o1oyXoMHOmYNZ/tPzy9rR/lkMSQpHB18BjJU0e
zAkbn51EX6ZBzkYD9uwNFEOuf71lIRsdKM8KK4u7qi0LgbFWs8w688VGB9qr4v/chjla2EwV7u02
hnvJ7BiFJ1N0y6rsYyX7X29JKrkmWIIhSriEmRrAjGh1oFyyS7SmrnkWyVEbG4pGgG/Hqxj6xIoQ
r2zDmZ3x1Nw5rpJFq8M2gY0O1EOWipYmHy2IieGe+CgfiP5idBgm9Uqcm+jFOeX/kj/w8w2y9nCQ
tgBxHe7VnMcb7xHOFp3kQfD4FgsUC1fi1KI2VvGGaydX2rQQaKMDJZeJKo7W5vRSYm9tLL0L51Ye
YSzsTglgm5hNvYrNjU/OPHbLnkhv1sEXxWnkT7GVOMpS8vdJkVGl3hEkcIp5XO0e2L8329xW5e9A
+GWi8i+1iqPzVt47oe7eWhCKPZqOQ41RAkTPl4vuYupxxN6vNxcn4OiFXlcmVXo0V8/aHSvo9UVE
1abdmx1o8Fi7j7/tkuQotHUSbTAz19zgdHMEPkt0iQSbkuM5CTG+9lBMpaCy2YWf0CyiS1J2laSG
p38iWO1vn50278DOv/PV0trVS+xCDWjWJWoUh5sdqmsbJrKFNofTm2t7zZSG+uE7JL23dlRpUeWl
q9K3d7q5sX+2or5uLm/YpXSx0TvGVCxwxvvI8cSREyi+uAqvavONGaRzHcoIGxtGVYIXfIkGEKs2
3gBzSprGKakKWtuNBS2kHqMHiktEAAOCMRYyILNTKrp97VCc2chbN2r2df3Jhxec3QsU5vb0rTOm
HuZpWxuQQkrmVdVqqPeZGoymSZxy2mc2wMPfUuc3xpkMuAtbLz+yFbOrK5GaUQnuPFmrcoXsJI7u
sTNFUYUE2MvuguAQM09hFES3PultLf1SjzzYfZnmvirlDZsLHBDONHKjQB9Bsz79+Uau3a71oIF3
UmAdPNU1KlACBD1vZz1iF5372imTBeIMcjMUTLK7scvdECtci7sB8TrJO2HB2XrfS4SeqWMWTB1D
Hkd7wBYrbWYbjZ8mMtBJ0Vp+fwOLbBydzDRHsruwy10Q7VTFXYDeeew80picizUtCE7Q1UNzOs+v
cuwCk9hjsMf4k/vSkf4aFC0M87g8dhnlKsKW7YP2RRgcY/EN8A3wDSwliEDWLRqexjHK++njBMtS
k4kMgkrgVvuB29gZV75vzrTv4CjKXMdzfD2L3RDbqTOa6Kl7QqYg8dYrUA0HoDcw8Pdv7ksp89On
nzF4jyrDJzeNboDGdnqCNvOW3y7//IWa+sXurxra4ijPgijvJS/G7mUp3YtB3uEc60LjUKarJzG2
ppfWJv+TWN0vn5ZtJ/p36bPDSYzFVGSvWMq14eSOlpn1nPV8wbkooiY+kq5TVGOpOjWJsLMIQ+X5
rsdid9FsIbraCd1lTDrvyqw3eR1uH27tmN5Ei2V7mTuijKz8jHXL1DxC9GWiaKH19DoQjEHRz1W9
rC4Dp9vNHccFiYk5TWIgNIzi8WwnYPP5u8zc2S0ss76xLgxbXUaU1luEwYr2SMIU5RINRDshLbGc
4346DKpsVmYTqu35xikLzfKmWM6uOkPLqd6yIXQ6+avb20ZV2uowgbK52SI9htndQa0BqNAag7Bz
T/UsiTnan7c6zNZsbtnxQi1pDRd8NKhbejHWGuCjx3m0u8PwzeauHbcz8CmwGkuPeOXnMHAdBlos
FxAy+ck8UtFhZMAWqWjWmTf+mlyb50a64Os9O/Sk+UZCLBImpPA0B6+QQvJ2nlvqAqyttrWKM38O
29IBaW+1zN6YNts4wAZT6o0JwaM3s/aqESJtdwHYVgsFbU94Xia2uwBqW6LPWeLXZknoApbtloQ5
xKALLrVEDJo9CqKHOcbwWrwwBIn76ozJMjU/8GxxQhP+hwM3GhPfjuLiuEqpBR9JOe/dSn+7YOPw
ZDD9UhcwXo+nT2TwbmV93bB8A853jWTl4OqHTz+/PxEfP13rYZoaR9AgF91g+bfoY0Te+VdIEqr3
iZr79OqK26TOiSdajnpu4Sp9RF65IEY8Lt5GDtHnilFZokeh/15OolD+l8rv6v+p/PcyqQxsVi96
JeO83SGg2srDbMVTY2pvYoFJS0k7kUMHu0RI9SpotSB7TCYODajjZ1HllDF+qGzIfLeykWdfaQdj
S3dm9RI7xGCGXaI2kL/dIUoqzqEcgOFeAKQFG9v/++//OdAxsEn2wblRWtXC2XdNDAFRkKU+QmCy
gmluC9W/ixRoVRy7xHaVlIAxzzhIRlEWeM+fdKdDBGeRwIqS33eOG+gQs20Z+dY0zIyAHaI9x2k7
xGk2vXed5b+u1TsdwjIjX7oFos8VoO90qAbY9PBDxyd+fpDmEP/WHArQIQoxUggGq3McsjsmNQuG
DOCpA/+PeXKQO12go4n2u0Wr20vXa4LgzJPVF9Nd0qIoEwYReOxBYu/6CQGenDuJQtG8SjRnhnun
C5itZLjNQUEd09k7tsO+FlFC7vomStFYBZBwL7+jlJ2HEvIXJOx5E7PbBTiaKBwtdzXHybsAxkpd
3Ri16HJyhEr1HO1CUgS73ZEr51nytp6ziCjRF0ElReLDPDsFba3pBqDYtrbTSE6ZyIkTo+kGDQSr
GGlz/aHvopU58MHrBihyr5AGcoE1dFo3H0VbfkOGkdvVF9yurnm/lllAVefJudYN6hrEPgtIp57x
ajmAPcOMDmkaTPcwjsaK2QoILgOyHwHAIbF+S4RXSMHfybTWz8pqZ765nRZX39ird37oBhktWpnn
CPZoXmX7bxlGJ/XNFF2U7K85jKZX7f8qLp82lJzBZtf7InY75KCLrTm4tC+uAab/EH5GtV3sdsjy
VpfyFA+jv5b5BvS1tgPTlarS4HMKrl/YX028p1LXIae+BFI3dduzPKNq5OjPLw5mqXt2s6hm6zoU
OZZJ6iiPP+1l+PDz1fW02D2WTphQp3KnZbYsdt3ErkO9aZnErk6SOR2m/FNrVFnsuoldh2LcMold
uadUvHy1J0tcN4nrUA1dJonD7sx6pF9GdE9RQfmV2T2UiPBU3WlBeyhNbSvWk/5/7bipnhbY61JN
z5kqEHzV0gJ7G7nslbJZBmh7XUrWdSIM/bUsSQvsoYxVD9AK/u9YOu7IIRKeLKE8+vnF/RatbvwO
fWT4eGdNy2aiilne6JP+f0G/9fv6q2YFIIw4upOlowiTAe93N7fXVXbKQ50G4wFgN1td31ld37ru
7x5s2S9006wANWc5Huh6/CRFxRQdN8KLxo4fCkxK+emjUDEbyByU/CFa8+QQQxIkfix1WewX3OnK
iSZ/QIQ6oZa9DgnWZZI6SRxRLrGLoSRP+9UefHR8xVi8FnsqJ0BpA8fzQIqKeqIz9gPsY0NfWI1F
gy1dd5nrkHVfJpkDqR1GFEcgpPHD++iOHGk9S/DKrpTLaioNqqZCK7N6S9lJU5qmKaztUHdYJr2j
pZuHNXArjkcEMqYbbsYgmqTJiKFCtwwtXg4tOhQclkncCNkWyEEmPRUfVT9HyOSIsf+ZJE21mZfB
FIvcy0WuQ7Fh2USO4vAnOWMYEXWUpsbWfU7DPeVypjCiQ2llmZSMlql+ALeDP0EerJ4qK2bJZlNl
iCPZsHdUxQaZ61BcWSaZIyyROOD0Pr8obTuk8BTZ2GJ5L7ZW10XRr7U3l6EA52ORSaWkP6y9tiqh
LnL73WsMKtUPM0nRpZ7UNr8IQJI2/SdDqeTGv82iLEHeC5s/kYkd+pS9oCxZPWnxIgt3+YpxeIWk
ZL9LUSdn7zZlIK5BOP+ixQKS0PNSHOOuIHdvb3f7WHmSuoYWalsVxuLHSXe/CoGTAbVmjX1pv0vu
v8Jnb7gx21zbF++RyMek3axrFFfZZBKBdq+yUKiZ36iMBkrHOdu2gAo0ty081+5dVaalzLCaM9DX
MqRezKjuN86oOkEQPQjUwQR2Fno0KOfJSRA9EkUlShQiUEo069v50Q23f1MUhw+0x2uZ7zRzQBVL
fGIHHQEZRjhRhJ3nIAaOyw161KdAs6ixhKIRW7j8jEaHHEizgjVGYhZY1amOzSOXZioYOPBGYRRE
t+h+mOcUBmpXi9NTfE1Ix4VROp31wB6HJx4G15k4NyDMSnH0nnb2EvZ9oVuNQU3RcYSIScJCHya+
827luJJuxzdGh2Hi177qJvqXFIJu61kC6WjL+06Vz2b/Rqv7NNFr8c72qB32ENbirbzGrrYQTWKJ
PWOKX63eucegkkHl69uTAZh3XDT02Uu/MED2nxpm9YHGSnPsQxTfUezmFE20molh72YSBfcyezeC
YJroWe/dij4xsHqlKIlgHcS0XSyaOL9ncjpw1xO0SI1h5Wx9jaM6mu94ZcQ8KMc+l0v5VETnReDj
nSOiq1WFuoDLr90fXS1Adml7z3d+mVKAbAQOejWtGhYvfeGsSyN1ZXub4Rh/c62/rmeM8e7FXgAg
52h4GtNGpfRxgoE0UO0FQSWzVRX0Do2/2/VJtktanrN/tru3c7xizI0N/hFdaTb1uauZxu3Vi+nS
nmqP3MxfTeW0WsFtuziK4S+l1YgfbHO9sVZYCTEVfa2HKU1/qFalpeLq/WEi3hTJn1kt6eJ9uUi8
4Hzqe3mPDYSHt7GUVAXm7HitTdCmMOaXc51euiEIn3Xj5hxvcLJ2E2Wu4zm+vqem7RRTj2vQGVaL
7dD+PSbZVzXib3wyxC6eX99qBrPhcGjOGFeAlkGnQzLyPJzn1y+epjGM0EcsqmEEe4MFe4N5ntZM
yaQ0ne9mgfOs6SDtMtFyvCiB+LWzGAZ0rrLtsKt2QUPX9UrVU8vhU/QQEOZUXLCJjO99tzYvxRGE
MWmQ52tW1Jxhr99Io3l+dwP9RcvDIGwvwnVPNfo+aR24loa0kwYtltIZI3yXa7dctbI63LNb9RAp
DTFyFuvmvyUeskcDjwMnScAvBbaHsjvq2fUlBgflx9HV8+2i6vc38IkGb+tMpV3ABcNqDskXHJIT
CUEdVley86oBDD5/ImP0qdC8LnWDaaiGQym7Qql5/Pqsy4AE6PVac7OIJ6gjUeSnyWiD3zfVq7RA
74LE9JfLs+ONrd3tX/W2lIbzVTJRHTWU/RLfAN8A38BSorOaJ7PY1R1ZX9DsCZkKJ+jizOwBW6ef
Jz5mjcUnN41uMOW20xPEu074q/rPLxfOrRR7v2qApaPLXkpVNac03YLJXvJi7F5YZl81+B+ch6mM
Q5muniA3n1YtDlZznB1X2ywT/bv02eEk9gNlr1jKNWq3jpaZ9Zz1/FX1vMU3VTT6eDbJd/XDp5/f
n0zJDEAnItKHSIwjD2gl34fiYerzJYrPj77gR6f3V8mi/b3NmWQRW7CON8DCvBhhVgMEfQwQnB5/
xDKd1bET05qTXr71JJa/Z4ivvN50pROKFGBFGoNY1HHdKPZmB/P52e0Jnsl+aQ6oJcVtZsPosjX+
kCfZWd9aZ08y09LDJsUkkzLYAtSl2PbEd27DKPET8X+c8eT/ius4yrBvMhlFUfpCr8ABHcOhxcCh
6xHkOZGuYr0KQPuIzYJE3oMUOtrBCjik5uxUcyZ9r0EXNKfK5ssk89Uays+YL2rCdaWH5kbxBuzl
UQrES5SgSPOhzADitBUlF1GQkaiscJcaO+2ZG7BC6k/OD//+L4oBKQS8rtGU5cMf2KKqOmILWwhO
wEx1x0ID2NJpiWsr3pzCvso/2hNaFQEWw0c5MezjPOcwsMO5xSEBbdSXtog3iqiMIIl2WoYYNipe
OVxwloU53lScWcAd91jfU+JONV73JnkrfBD866zP/Oo2vrqmuFaZ2+m4jzfPGewxtchnM3yHKhHR
EdmU8k8aYWX6JwPonzCPll7K0EP46VEj2xHC0DtFNNjOtz4F9huNwP7jp2tkMzBuEoXqX7St8Dmt
nu3iNKd3bFCs8KQFAc/iQMuGEmbKHOz02enH/jfb5zDIA//nTENlEMaC53kYSURQtNS9BsGR/c0m
agFQnIUhyhh623RH7eM6BtcxFlPHmLr/zUb3n+f15tFqU2v/4LJU5Uc9EdIST9kTi8AuCefe8YMi
qYWqk/ZKHQ0Qq99i1K+SXqUPtSdskVEzFU0fQ2/51e1Rr5q/V9uO2Mdz8K/fgAUgVoipj99q9PFJ
sTiZXAo6NRHt57u8bmT6ICUzTMCVaikvK958xrE027NygSladFPaEYwE54OjWnXFxEn1HXYMKGx8
d3sBxTCiFdZyyUoIN49IJkwc9w59YmMndcHgc4sqrQOi/bNjhhe6oWWTY4XJmcKL7UZ4wSkEvKKJ
S0E4hdC2n5gMT1HOs4yel1MIfn039Ssv5mtpzErkLfV/Uzt4Q/1A5ROKfZL4fpLdoHVcQ2vs/azw
fjOBlvaELWkwMzN4Mwnklt/dnhRekjPOi2HRNUeNcsDZNzKICHNH+byG43vCHTl+yOCbwbd+A1aY
nyn43mkE39XcXhZitbjv+jShgjkVHxTxKtGnmSz2OlY8O3sdQ4OqxL8NHaw8weCXI8bSCeF21HJj
f/ioPM7FyUWiOBOwGiUWSTTWC9Osf6x/37JtC1KIXZCaC7Ae+UWum8XiDaoZQn7GyHkge6SMTlBC
QUq6FvBQOzkrHyvft1S+Uh41IbRe/bAVO3VCV/KsBLSpnJEo/+RZCQyLqFvBHyZmxSvtEruNIdXT
nrsgclE0L/oLsZPyiQpAd6jsVtitfEu3gsEVl6L75XIrCKOk445qrficuGMvo98AW5tvaW3+s+Om
cAte52nFdC+vEhTsPTm55ZTrZOzcSZElnMCxX/2s7r1ftsrdF3B1scsWI8m3tQ3wDLMtMK0zhQv1
6Tw41cyauTuS7p0e7FmfvskSSo9enYmbzA/SVayYbIxw31K3uPZyrH+sf8dR9i2xJ1FqFtKJgexJ
Fk8iLGTWI8IvK2RHoeVBbZ4UXcyk6LTRY++ZrKSbJWk09v9AlwfXuFbAfgMV19LwNlppzdG2WDQz
IdITeJjnDAa2Fw50d8IOg2+Ab4BvgG+Ab6DjDSwldOYdzgcG8RvyDmds2lM7nPd5h7N1YY8WIXQ0
rpyZWUr3YpBt5R3OT2yio8MwqQ/ausm7lWoGWFEPPzdkzXre8QZYzxeTgZ0pXWrOyqqUHDp2zmZq
dy2/v4HpuJZp++mgB7FaYM5RbdsS2DGYBR5mfoWDjYOYxNIejfXOxlS41a06tzKUsZPqLWPWK58j
UpmkJa8VRh+x/BkTV3klSsZ/S9RCRPwIq5/1lSir1e9hpHsA6zVv7DyKkXMvRQT+mPiear6YKC4L
v8KTINz31JQ/V7H0dAg7f5Oc/2Aby6LPDz8eiuMIkSU22Cih1VvrOj4ZZ4Q4UlxMpKiWQ3uRmykC
MC/Ckj4QrpRbocG6CxbQfJPfMI7GSu7ZPLN51m/AKPO8A/N8JUGrgL1ZbKIP7p3g3crGelN3WUcn
xSZ6MSb6CDRwD8LB1vbAT4gRq8DNuYivKhJ8fDWWv2d+LMmOKyIfZJJSTH2Fwg85mQQLVdIaWMOW
qmUgWsI/MxspHdeNslBPobQcwJ60LTasYb5EEmtWzoQua/PdQlGlKsqeIq0LX0QIS3tKNrsm4YWW
JL3N7MRga0v8KNSEznr1m4YmbkRsdFQ7UWvF6aSkcfByMh46rhpz9ojJToYY+3L1/DXrHuteepj4
jl79Fw8HX6FN4OEgHUwUb6nULb71ykcQUqncMfY2JyBsoaJJ6NUc4Mw8W0dt4ywYh1iLCbGuTo//
dXn6j//oNw6sKT/jySeO1EmsuCgpO6Y52Y7yzq/9mq/9ZzbMV/tmtJdtseBmhl8+AR+sbFo6DBhI
5y6PvcCO/1D2y4DWxstJjLGiKiXkd5vJRPfArJlW4L5l0T+EIqDWnseC2JP/kOGtH0oZkwJOYioK
uSgWvZFrt2s9EWIBZxTfQfkAgKPbx552dtY+1r5YfJQPKwi0XnnF0aCJSaDFfdujfHDpsZOkcYbt
pygETNVMkMtLRBSq6EyG1Duq76Fk3WPd+2a6N5ZYUBT6yVhHX9arHzAlgsBUummeZ4Rznzau6aqZ
sOezsNS2HLhTpq4Gu+xRu8EaM/DDTVVL1Oy3rfPbsCLX1ZGeDz9fXWNd5mQSxVihXS5YKh0JVbBA
CqdpLD+6jY+uPWGL0TUzU+hFY+yTnOf3tydUUuvMMD2BITrnFqfDtI+TpthjX2zVzPOGSCVSkVg7
Omsfa9+3pASFB9Dkr8V02KN6np+o7oxH2iR9VSy1PZsutS3SEwihMHHHrg/mRkN8rHzfUvmsdn1M
9DijO+y6bbQe5yEGsWMUkmhBAvaXFMUjJLU9qjLlIZOKotDMXgRSnN6eEX0bH34e2GNmxDQTMlgP
2Zz7yEcghFyE/AxGeiouAbsVuYnVErE1OEu2uKx43xKvlc5hHtNhT8T0xg/dIFPejnQukWmpfkUZ
WzQu3mXlY+X7lsqHqi4SaculelM8KR78FG0Uyunljk71ts9mZ1jnWOe+qc5FcSyTSRSSd1gu1aun
BtMROnpvMOiMsC8fNeFdlVC3akGYte+bap/NHm/A3RQzysPO2wrzUc5hbTTOYT3XSrGqeUl+ciue
fEla7xo6r63PDZbBUNlFAS4wjF95lKHwZOg7wWo0XC3zFBgHZvWzG7Bp79civYZm5UdyuGR0M1Cy
UrWKGSs/COStn/qY7ERrk4vpK8XzxHkKeHpWPCdx/fqaCx62Omhb6kFsHW+L1kCmtNQ1iLGzddgZ
OBqbMlDFdcaTQPbQYYe5+LhcK0GcruihAMU2aJIwLV96D83l86vb+OraE1qF2twoDDFS59+DqXWe
U9hT1i2QWyJG8rsEdV3P98K/pWhhuknc2IcizrSRsObZqHlv5hFaMwOmadvBPEewR+88EOBiRnfq
3nKq3Kuz5C0cIqhhoIqxn9whg6Gdm9XPRvXTntAqx5cTii1dWbclQVFyw6CaHWUg5GSSQGhbtbLL
5scK81MWpzYbi1MfP10XHLQSPbTUUiSeM1DJRAaBmfjg/CKRz5IJqN/fHnDwy+XZ8dbmev9Xga5L
7W1YAa1QwOUoFT5NvGgy2AJg7FGv507D1k5bOP3VKKdbCOyJD/1W7cBxRxLD79wS9DLUxeTUfAN8
A3wDS0najYRENDyNYzil9HEi363MOuvaD6CSNDYzdDmKMheLZP14LkBiIL4a9ATGwJxAL0pbjw8L
9H76eYIkbSI+uWl0gwLlTk9srPe3qtgeH/9y4dxK0V//VXtEjtMsiNNe8mLsXpbSvcSD/1eAb/xx
FhFj8cPBYhqWzmlNFDLSqyexM0x1qwNKInFZ3aKofxufHU5iP1D2iqX8JSls1nPW89fc/ZIOdrF5
EfvZU3RbZGkU67PLHXEESytL66tKa0sKL6eTHUYB9v8SHxJmL9Ar5WVOkAj0TuWyjW6+VH5Gb0O+
oK1c5X7ADuolDooFfjECD4z1A2bAHzPx3n+JBPP7Le79MudB+uIaqyBC2gXkI9g/jrAj6H3q6SmN
jm6Y33Rhb6qpYkMmajZdaFDAd4SOd9/R6/1tJzAwGdgMDXo295a8h4G/dZ7nNLGsvQTkx0Bkrj6G
yCbOgoylSvNcjWT4B/4ntvt7/Y19XuOj9yja8ozHYPJyNHfVUQU52GecxTjrwE3eae1K31EK/0uj
tKcfHP/ZjaemuvTBgRipsHMt8PMPvh+pMGbNjcZsTTiTot2ALb7wR38s/p75IO+MmZvFUjhDG1XE
1WOSynHSE+ehyykUO1/y56tDdiSaGe0IzBmWviYsDbBd+lKGHoaXPOq9Ooqlc6dAX9qcgsp7IzSR
bkurmdknaDtg/e02d+3fu+QjGKiSKLJ90W7AFqB64WSB+Efmh3qanh2ELQ94zDD1D7Q03jvBu5WN
9RX4zVljZMtLMkydfTm2QrbI7imWGQcHWCmXBb8zKmoxRCzOJonzYA99qofuXRg9BNK7lWOJ5ngt
qOr4Xly+4jzBa+YJ2rMBHxzwg2OPS0iL1iPx05r4e+w89sTHNXHt3DmPTk/8sGZz38pPfoq5Qk05
2zIeBjYSYaoQ1/9T9Bv4o3viZE2cREEShdznoCcNTHIOrYm3o+f1yNz53H/G/u0o1eWuQY/oAAaq
UcubYPuB+HFN/OAEE4yXiSGYeEE26Mfo0x8rn/6isg07dXbqr+rUB/uAoZdyiOx/CII+zccxAO14
Ayyrry2rfU1AW5yHmVUn6NnHKMYKD/9eznMKe1wgmw/OuLTcgBWgmughN/r9/V+FzUHqUex4obSZ
++YKo2IrP8lH8RDFXqKgNDZZYPhV4IFUauEcc7AuliBp9pOdtBValreNqH9XqDbEe3kvg2SlJ46O
L0R/q0dvLUgbe+KDE7sj0d/f3+UYSs9VsMibJPKIoTY0i2QbLj0PkbZgZLp7uHO0gmJ+nPje5Ykc
opqYvltZX+ckDAe2rxrYtqQWQYZ3rm82bjAsBg9gn6zdWM/IuFpdVbWq1nckfhSClIU+GfqBZKJC
HZuY5JlbFasCRp/z3AYrmPWEp83vA+SPSNDid/nRcX/PJLgG5zqDgYk+lIyP8QRU20IR/5+gbEBk
DlK15qV9HI3YZvMu4ujeL/yYwCfkx8Sb44uLtwjEPeLHtBl3LBvq0KwIK5ttyqY9XwOCN7dhownu
rq5vznMgA51aM9gQb5BtvqMkM057C35y2hiZZx6JnZwzjzq6Z/NjhfmxPXHgy1Rf1NpgN42lFFlN
hi5lB24COV5NUtSrqBGM8wS6JbFCjyp5AjWl2BMXayosul4THx1POhkCoysZ3/uuFGdZiJ3mUSiO
R45PKSLNUbLltO3FERiRCgv0E+UqPA2OyDw1a/ksPOJXt+3VLd7tTkhWszkNXtOu7modlj8t4WBY
rjvTjmaGK5p8A3wDS1nVRtzBC/2MWTrFC/3KhX59jn91l20BLtawJEOMjjewlO7FoP0OvNAPS1Q/
ygdqWRwdhomv8zbjq52onEm6L/C8HaWcYSTr+YKaI2lsZ2t3e46xHXNLrEeBcyd7gkZf8KF7RwQN
aL5xYkXRoBqhTpx7bFLqiVN8I2/F+e+1LkP0HRWaxXkx4lwpNWi4qyWHZ+aQKzrG5vnl7ekO+Cfa
36SfQP1WDkNxiIEkP5VumsVSzaed+EM1Oo9FU6nUj85qZ0GEU1E6IYo6Hg2jqSE0+BaYY+nKMa2r
xxzaHqed9RiWZdwKGVcDzvt7m0BKFZCxohuvqfjn9e0Mzb5qLhOqoJl0fnMr3rxi2Tbw9D3xyU0j
smMb6+vrbMfYjuk3YIVMkx3b2lzvw479hI4qCpuUsQLjoGaiGiCzwVM8VzKa67c3EDQPVPeTm8V+
+lgHx+BB0w7GnsMKLat4jjLFSjMiaeRGQQGNSQkr0BguZZtdim5QWditEHZyKdu76ztwKT84cYym
zRTUqCoJt4INap4M/BBrzInWEfNvIAaQ9DPiE8geweSFr5ADYitn5fKR0tCBvxh7j6hHW0RDqqhM
zZ163eln4vRzKiEDePXcDvK7W/3upPdgqY7u8wQPvNg+ezH2YvoNWOPFdta31inBE9NGHpSUjlAu
WtEslF1h0bXKQMH96mMUbYcwMDpqGTiEjzn9PAl8108JU9zKhICE9lIMHq1QuxJA4M+PUeoPiZsQ
T1kESaSQmnvpc94Nz1r2mJR/0nrxScm6VaHbKr9UIeLi0vRiStMUJO1s7FPe7ZAWhSYJxUjv4WDu
ndDm1NsPMriPothanpZmD0P7PuD/wVLlYuHHJT7WnEubBzWzo+AyGjuJ64TZXGcwEAUM9F4ddu22
uXZqyCImJBQbkClIhr4MPEDrmewQkt3iZ7AVA93RhyufDj/o6Jsf3raHP3TjKHwcEzcIPen56fUZ
oJ3iKd5B+htOUZBX7Ikfs1Cirtrvc/qA8Z1+AybJ/OAwS0dRnPxNHHoeMd3wvheOR2ZuwCR5bUa3
CLY/RCNnLD2bYe2fou5kCGGFeJ7FDnZpiWsZSCyB0+IWfkErXlB7s4Z42dx5kkuJvs1EiM1ttPnN
c4wiYmbBtEIwc9OivWvHl+N5Pc4iLyaLrEltg1E1uEXz9IPjB3P9/iYmIA/EOAfMT/sYvo+AUW7l
2gvxCRsTvgE2p4sxp8cjdHpg7tDqAtyf2pTQEfGwgC5GQDkMvneCdzYvRn0O8XAYvL1zdNhfUS0s
1M/ycJBMHJcaxB8OsERDxuhnIXoWaiKHJGxNP7nMAnzBydJo5Tv6a6orBn+cRWGa0F9OXL/O5yKd
19NkMqr5Ecyh+GlNAHMYDKnBi3EzlXYDVqRwnjOqHAZj0xQmCr8qudXDQTo4EG4Jmdd+Kzd0cSDc
hlA6omwOhDnOeD10Av1tBQMWG9T/ypwwwAjAXEcwMLXY8iY/Iiuhn6mjMWFVWowq/ZA5D9JH5dod
hVEQ3YJ3DiMq6H98n3ov6m3jB13Mg85lWMxs/D5yQspuznUCa0yj1a347+Gpbmcte1shz5onER7S
6LHv6kMg7LCsCKavRjL8A/8T2/29/sY+j1roKSEr3vB45IeOZuY7Kh+HngyvGF7p7O+qqpD8gVJC
QxGKsmG2t7T8RjHmYxE/fz9SgQu3s5AZ1VLibEr5BvgG+AY63sBSAgpejXZgTm1/wKvRytVoG7wa
TQctFoStHK++BGYupXsxyLaWvL2rJzHa0Co0VfjwCrQFl/L3zI8V5SVmxWb/OZzEfkB8Blss5S+R
cs5LsZ4vJi91GYXiwonvZPwSDebXW8zrHQ6Hfkz8Bh9l+hDFdwk/omaGLYCHIMrDupVni9fmNtD3
wLJxqMldQ6GXfv2izsv5BSuk8ucr/VE7PhsjGvaJi/GJz5ki7pp/ta55gMl/5WDye6dAJmEBTLjg
RnKpgRO2qB1vgC3qYiwq7ZiOEnHh34ZO6sT6DjJ+Qyvg3DHtehBXj0kqx1hRfB663KWtm2MrnpFR
+Qu9KPuQxfgQRuULmNQvZlknueP+3iUfwECcgfhLb4CNKBvRjk3E2MJ8qwcODVlilZqxZxzoo+On
+pk4GDIIRQfgwAHJLbYQSe8CazuPYuncqW739gnxj9fXGlLhBzXoQduf7YPvRbG/ejyKxObq/mq/
z4+opRqteETtzdq8g5kTyB+yxEkwnBat4t9zncNAL4c+2+vo7jES/b311b3tvW3tIGwJrVCiH53J
zCR8x4fjwi1HNxzddIxubB+RDCmSWbujGO37wLlZC9MUeaK13yYvcQFsSfgG+Ab4BvgG+Ab4BvgG
+Ab4BvgG+Ab4BvgG+Ab4Bpb6Bv6/AAAAAP//7FhNT+MwEP0rVs4I0tKGD9FKKRROLBU9rvbgOk5q
yY2j8YTC/npmnJQt6iK4LVo5F8fz4Rm/xJbe216CN8XjJEnTPD3Ls1kietONLmVrcc8zvdpeNgvg
wTdSmbqiWFmiBgriPGtqPUmGo7fJY2vJIFt0yQmnQZcNt65Gz8leGTNJrl0LRoP4obe8jJYec2/k
gWOd1/4wXPn3gaGS/00LPUlL7aRc+6QvTmPYAo9hPxQWEYgIRAQiAhGBiEBEICIQEYgIRAS+gMB8
nM3yQfI/8QKiBeBcOQcgYoAvDdEX32hrlygBOxJzEFCB3Oz5A0H690yH2p/OXKtkIQ0w/8GOBYWv
9dc9zuuip2nfg6txy0dCo5D2+LMN8Df4hv2L540NZJn+owa01/Ckk6non/lzY8goHhS6FfHf7EgM
08Fo5+7HnwtZaTE4/fUOg0hgdwh4rXDBx/WDG2tJflYxxhfZ7OK8u62qJesD20kyGPZyxZrex+ck
XQT5oKnuZbgBXEP2UadogKnWtNJuunKIbvNnbnW5511rWbAwckb6A5UqnQs6ST+tWuxlk1BOOcty
CKsq9KNwTDAXTt2BKcjDysrCoKIuT7OdoNFtPJzqlStewgultBtd4/QVAAD//wMAUEsDBBQABgAI
AAAAIQC8RAlz2AMAAIMPAAARAAAAd29yZC9jb21tZW50cy54bWzcV91u2zYUvh+wdyB0XVuyYzmr
ENtI7QQbULRFnGLA7mjpyCJKkRpJyXGv+hoFupfrk/SQkhw7NVx1yLqgV7ZJnv/vnPP5YnaXc1KB
0kyKiTfoBx4BEcuEifXEe3t73fvNI9pQkVAuBUy8LWhvNv31l4tNFMs8B2E0QRVCRxXeZsYUke/r
OIOc6r4sQOBlKlVODf5Uaz+n6l1Z9FC2oIatGGdm6w+DYOw1auTEK5WIGhW9nMVKapkaKxLJNGUx
NB+thOpit5ZcyLi0PjuLvgKOPkihM1boVlv+b7VhiFmrpDoVRJXz9t2m6GItUXSD9ch57fZGqqRQ
Mgat8XRRX+40DoJTtpsEWhU7iS4uHNpsPckpEzs1Fh0P6r8rXh+L59e2favqPhDMxfQeS2QTsWTi
IRg2ES1NJrG2L8/PwmBkTxJq0MYwGIx6wbgXjG4HYRQOoyD4y94ywQyjXKOEU1ngGcI6uZl4QXAV
jl9cDuwzd7SAlJbc7N1YJ4o3yn0szZYDPq0on3jzGuW3cGc8f3rh7565t6oWUcdEbiAFhc0EjVzz
lgohjcMdPqg11qqsbWO7INIFjTHSQoEGVYE3/TOjhjBNPn/4hDlh76UwlBMdU44IIDIl9h12BklL
ETtIf/7wz4xYb43zGS1Yz114bRL2om+PHi0vZrqQoAkzJAcqrN9feUhWYJ1HJFcsgYSstvWgIW7S
kARsQNrGcSQMDAYhZVvZhtR8xSgsenBidUPPOArCnwY9bQltVRfz4fBF6J0A1DIr05Rj1o0kJgMS
Y2utEVlYM0TTskHTPMMGJzfwd8kU2GT3/w9I/Rjg1lZO4WrohlCXsYTAGnUCVlOotnZ77Xd48+ZB
VZ/4pEps75sMB5a6x46bBDM7Clp4xRZe2OB2stGVLA3RBcQMVzzBHYGc5Ohk64LBw+zd/Cd5PQrL
H2f4FFLPvgep54+DVLdansACnc5m37swwrD7xjjrxjcW8/A6fH6MbzQ3TyZd2I8H+xVZgpIyvVIK
p5LZFshD1ormS0OVI0DIoNpxZYdSGA7Gw8t61UxpF01XIrGE6ISe4xzocPWg+In1xqlaAxFlvgJl
B0xMcc58NEg5CN2fSd1mySOX8tubZhB2buDz6KxbAweX4eXIEeuHDLi5eSqIPF79Pxz/NVKSjCqd
Wd6i6dZtk99fv325IK9e32Kl+4RcS0W0zAH/x1ZMSWF5yzPLRHHLFBL/M62Q3ONfUsd7ltdzEnOK
pykDRYRM7OaSJFGsAveCS4rclHKKRP4ZAbehKOfbnbiC3kMNR2G1P7Dvv+vpFwAAAP//AwBQSwME
FAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/Y
dyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Q
r7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY
8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablW
W12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+
8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpB
zwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQ
xTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY
80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r5
96+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDS
ZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF
/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJS
xu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtN
MqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErI
wVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpj
P5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxc
XDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJXZTP
Zy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ4Ooj
qqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmj
FU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe
3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRLeQTP
vKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXcJKjD
NYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFt
O/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3KrUzTP
ZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE/b6A
xsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWETESV
xJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXWYdPQ
5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGiIUrhvgfp
P7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ02atk7ZavllfcKdb8D1h
bC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAlTTDB
NyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAhAD8/R9xvAwAARAgAABEAAAB3b3Jk
L3NldHRpbmdzLnhtbJxV247bNhB9L9B/MPRcry62ZFtYbyDLVptiNy3i5AMoibaIJUWCpK11vr5D
SYx2EyYI+mTqnJnDITlzfP/uhdHZFUtFeLv1wrvAm+G24jVpz1vv86divvZmSqO2RpS3eOvdsPLe
Pfz+232XKqw1hKkZSLQq5VvvIttUVQ1mSM0ZqSRX/KTnFWcpP51Ihccfb8yQW6/RWqS+PybdcYFb
UDtxyZBWd1ye/SFzz6sLw632oyBIfIkp0lCwaohQVo39XzXYqrEi158d4sqojevC4GeR43E7Luuv
Gb9SnkkQkldYKbhZRofjMkRaK6Por+gM9/lISonk7ZXIAzzbF87ZrEsFlhVcKLx5EHi+IWBjfjpq
pDHQSmBK+yaoKEawfZeeJWIMwaMNSJ+jJaqeP+IrMf2jeqjGJ3Sh+hMqj5oLyLsiqHkVjbtUDYIc
jeVRoAo2yHmrJac2ruYfuM45ExLuYKgL+kcgbSq8KFwcHtGNXzRs5XfpREED18rEmMVHzrUVDIIs
WGXJbtAy7MQEYVwcEieTxdnSyYRRWBRLV064jPf7g4tZRGGWOytYBmG+yVw5cRwmkZvZJLvN2pWz
Xq/ifONkDotoU7iYTbFaJ7mL+fG97aCyzLnPLlsc9qFLbZ+sisBZwX69WhexMyePot0PmLiInRUc
4mSXOSs4ZKvFUDV0ztgvLDXT/698uB9WBXTjjA0tmyNWSoJmT8YfoN9YWsrnHWktX2LwKfyaOV5K
S87nA6EYorSAjrcEWMPA1ESJPT71wvQJyfOk3I8KS6UThfn6+6uaGWEs/5T8IgbVTiLxvq0BthuG
y+WoR1r9SJjF1aU82qwWbOIVdWnrf67SCPrTBXWpBmfH5oYeUXu2U4Tb+eejsQeMlM4UQVvvSzPP
P5hsGFAqj+YPAT8hIWDaIa48h1uPknOjQ5Om4atG8rn/KM/RyEU9B1+G6z9QZQ4L0ePCBAxLiBoX
E7aw2GLClhZbTlhssXjCEoslBmtuYJVghc9gvHZp8BOnlHe4/suCW+87aLgE1SCB4amNLYJH8bQH
Rp9Us2uKX8CHcU00/NcKUjP0svWWwTDjYzTtXe9NrFEyweINOquRhjfoJ8B/k9w75je1dGmNKwI9
eryxcnLhu6FwSpQ+YgGGrbmEI/dO/kffF9Pf/8N/AAAA//8DAFBLAwQUAAYACAAAACEAIRTVgisB
AACOAgAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1slFJNT8MwDL0j8R+q3FkKE1/V2knTxIkTjB+Q
JekaKYmr2GsZvx6vHTA+DuyUF/s959nObP4afNbZhA5iKS4nuchs1GBc3JTiZfVwcScyJBWN8hBt
KXYWxbw6P5v1RW/Xz5aImZhxlYhFKkVD1BZSom5sUDiB1kbO1ZCCIr6mjYS6dtouQW+DjSSv8vxG
JusVsQNsXIviUK3/T7UekmkTaIvIRoIf6wXloqjYo3EdHs6sL5zhFu+meX4/vb6dDoQ1mN3SdZzs
lOeskHt6UOnR1vQRzT+jT27T/BFeQfubuwAiCD/ibGhh0v4N+tJEHq1gIr6VghfAoFWahz1gDR54
sGpLMNrwR85OU66/OTpNm447P0Uqhy0MTY+wmo0nL4bB0S+q3gEAAP//AwBQSwMEFAAGAAgAAAAh
AOirO/OqCQAA7EcAAA8AAAB3b3JkL3N0eWxlcy54bWzEXNty2zgSfd+q/QeW3jPWXVZqlClbiTeu
yngykV37TFGQxTVFaEkqtvP122hAEEQKRMOka59skkCfvuE0aKP5+x8v2yT4ybI85ums0/ut2wlY
GvFVnD7OOg/3Nx8uO0FehOkqTHjKZp1Xlnf++PTPf/z+/DEvXhOWByAgzT9ms86mKHYfLy7yaMO2
Yf4b37EUnq15tg0LuMweL/h6HUfsM4/2W5YWF/1ud3yRsSQsADzfxLu8o6Q9U6Q982y1y3jE8hy0
3SZS3jaM084nUG/Fo89sHe6TIheX2fdMXaor/HHD0yIPnj+GeRTH96A4mLiNU559vUrzuANPWJgX
V3kcmg+/qHvi+UYMNB/qmVFeGAKv41XcuRCg+S+Y9jNMZp1+/3BnLpQ4uZeE6ePhHks/PCxMZWad
X5sP8ztxawlyZ50w+7C4EsIu0NLDT8Pi3Yn9cIWq7MIIfAdiwnXBIIYQEiE0iUWs+5Px4eLHPoEb
4b7gCgQFAJgpFi5LTofQQqAXMlHgKVt/49ETWy0KeDDrIBbcfLj9nsU8i4vXWWc6FZhwc8G28dd4
tWIiL9W9h3QTr9i/Nyx9yNnqeP/vG8wyJTHi+7QA9ccTTIQkX315idhOZBmITkMR5DsxIRFicwMH
FdrHR23kjRIq3vzvAbInY3gWZcNCsZIC1L8WCK3eNwbqC4tMA1Cul66D5iKGzUWMmovA5G3mi0lz
LYA/m0ZE5oaRlfSgFjySyWf6YTCtSVkxo5JFzhmVpHHOqOSIc0YlJZwzKhngnFEJuHNGJb7OGZVw
1s6IQiSuchYN0BukhX0fFwkT82sJqNeQ6lSpCb6HWfiYhbtNIGprWe06slzslwVNVaTTt5Plosh4
+uj0CFRnsXTfzMlftrtNmMewqXG4vt/Q9ffhMmHBv7J45YQayeSr2IQbk7Ml7HsSRmzDkxXLgnv2
IiPqMf+OBwu5y3Aq1zCs3+LHTREsNlhynWBji9PtnpDyv8U5+qB2MY0tpriEk2I4tuSlXfifbBXv
twfXEHYjY8nnHmEuQaCK9S4aihBVV5fTChEAigmyXPibgPIJ+svi4i9fxJiivyxFb5RP0F8WrjfK
x/yoj68303wOs6eAtLwm3mt3zhOerffJYQ046WHivYI1BM0E70Ws5ZNIYuK9gk/oM7iKInhzo+Sp
dyyOPOqB4h0OiYKLjW6Ld1BKtNfzsMg7QCWsvgdWM671APIm3R/sZyz+9uRbDJCl9V7TuZwHFg9A
CSLtof/e88K9h+5bOI+KcpvCn0tyFtDQBpaVR0VT+STrnUeMmxU+D6BmFdADqFkp9ACy5Id9z6Nr
Ih2keXH0wPKmZV3FMO3IzDzxZmYN5FcCWqqbhP2XZfXac6FaNwko3gGq1k0Cind0SrVM100CVmt1
k4BlqRr2GJmc6mOUd900gfROgGBRO+RNAGqHvAlA7ZA3Aag5ebtB2iNvApY3N2hONcmbAIRDfF71
NZBJ3gQgb26QbKf+ZnSoeyil/uW2BfImoHgHqEreBBTv6NjIm4CFQ3wyoYSlqY6A1Q55E4DaIW8C
UDvkTQBqh7wJQO2QNwGoOXm7QdojbwKWNzdoTjXJmwDkTQ8ayCRvAhAO8eGGs+SNq/7dyZuA4h2g
KnkTULyjUyJUvUklYHkHqISlyZuAhUN8kkFhYXL7GNUOeRMsaoe8CUDtkDcBqB3yJgA1J283SHvk
TcDy5gbNqSZ5E4C86UEDmeRNAPLmhrPkjYvx3cmbgOIdoCp5E1C8o1MiVM1zBCzvAJWwNHkTsDBf
GpM3AQiHvBXIx6J2yJtgUTvkTQBqh7wJQM3J2w3SHnkTsLy5QXOqSd4EIG960EAmeROAvLnhLHnj
Gnl38iageAeoSt4EFO/olAhVkzcByztAJSxNdQSsdsibAISJ2Zi8CUA45A1AuIp8wtQOeRMsaoe8
CUDNydsN0h55E7C8uUFzqkneBCBvetBAJnkTgLy5QZyzhfOi5OOpPUsSUM8ZHE41kAH7liBRAZWB
P9iaZdDMxNynQxoCHiz0QLSkB9XEa86fAtrB7oElQchQ8TKJOR7pfsVTOkYjwmBS00lw/9c8+Cob
YCrzMKVOT95A95DZLoTtSaJxCPQsXnfQsrM7nCwX0qBBSLR2qRYgbEW7hYYg1dYjJos+HxiITVXq
Nv7fVqHi79D2tjqM6XZH0/H19FI1OKHIqhLRBrSIoFeqRgl1FF6fTsKD8GWVLOflUa1js8ZBOXVu
/ri7kuNOTm/CLfChRe9CnBGv0RnPkNd6L8AhMt5VBaFtC1VyaajPW+HoYpnIRjT45TYVoYDOP/zf
mgz56iWUYuH5nCXJnyG2rRV8Zx+asHUhn/a6WCdLopa8KPjWPj/DY+SoyTkB4GJTGXkpjLD7Pt1v
lyyDPrAa/99xUV+wX+00ceWJWBluvfJAe8xrqtftup3ks15Gc74VHZpHPitnb5imHHr4REddpmkW
lVyG0Jn3l2i0Qw3ProWG1kCL48m6/TIaX1+pFQJtnrhodY9lb6wS89exx1LeA6fgaLtzThin7Bxs
hqjxSyGaJc65xCQjaLR8OrhKOV3InQPLyLlNVprdS5X2T9XwOcS1Jy7ON3wqjwHLaP9C8woamRv+
lffc/j1Jvmifw7pcCMovs3rZM2Wvq+fYnxIcfUdORUsUPCNgd3clKZs4rTYpYevzHxZVecRYr7ka
ci41DUdL41NIxjP5KR+ecZvCP8bgffJXOXQpbZjn8LP1bDNNsSWcGmPPOcOhR5/Y/dZ2xvk56Hxm
XYdJwnl6lu7UM9kYdi6hbFxnCD365X1ypcJ1qtVdUx10ipN5Lzv5YMCscx9u+DYUdR2/A2DeiHJ9
hZ45UmaTkhSZ+88ayiw7uJzBZuTs6Wuv3mYOG1htJ/D/3d8na6LG3z9u5mIDd71PElalX3iK+7hA
PXctldNS8nk+uoHGTZyksvmJsd03KNOC+eBVZ7+V2x745Va/0OCOCGhRP4V3APwUBvw8cLrYLIvs
3XHI1uFAfY/CNqDXn6rdlHXEpI8vULBJtoD0e9B5iVpbR4ymDj0G3f6wXsZgOHJoOri8dGgK7nBo
OpyMHJqOepcOTUfjAx3Y/DHuDh2ajoeXDk3H055D08lg6NB0MoHvgdRG7rIPb1z1I8ZAtbUjpl04
618/YtR1aDqdDlBTSH5wKuZ8XvnSyZHzzxQA9gIv+UINEKGWnNpzlBlpzvdZDL3Rd+xZLKTD52Jm
nesQPpuDr3yqNJRGivpg3kKbj0XikOEn+2plt/o2zBFLfiBGqlt6pwED8M0l//Q/AAAA//8DAFBL
AwQUAAYACAAAACEAjrhPwRUDAABtBQAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lF2PokgUhu8nmf9guNqNcar4EuhoT/gQFEVRQRtv
DAIiSAFShYib/e9rZ3ac9EXf7GYuK6fy1HnfJ6nB9xvKOteowkmRDyn6G6Q6UR4UYZLHQ8p19J5I
dTDx89DPijwaUm2Eqe+vX78M7Kooo4okEe48EDkeUidCyhcAcHCKkI+/Pcb5Y3IsKuSTx7GKQXE8
JkGkFUGNopwABsI+CGpMCtQrnzjqB+/lSv4rMiyC9+3wxmnLx7qvg3/hbeeISBIOqb80XtU0HvI9
ZiSpPRrSSk9iJaEHRQgZhVF1SR79TXXK98sM1cl99Ii+z6Nmj/C+nGh7geE59kG+kpesbDCpXv9g
/5TA0W7VfESWZfeNphuuUs+Etkpj4WBbvkn3XUvYviom0UlMtSTo1g5j0P50ZkTsW7wS1hcE9StX
728QwnD/9cu9Xk+tYuc3WO6renvazBydrqLVkub0273bX4V3bRKoW/u29kSZCeepV9Lmaqw3cXhz
jPMox0K+Nq5PoMeDzIyjwz3OSNq1xcQT0VwxzsWbGZajieNxVhCNA43FtscUkskRxq+mts+HB/YQ
4ZLrzyvs5vMncJY6/EaXT9taauBkid82A/CrkwH42fz/dMB+6oD+IKE2zjusHC+NTHauUrqlINw9
xVLCVppOztqJRbucrLylsXmLZ2OCQcbK2uKZZgmDbEkUGfn2BMHxyLZY7XJJ3YXlHdZytUJkpLro
MplCdgEu4gXQiaD318BP5ts1J8yumDHDovafwMxywUIqMzOreWeqQKIdANhtJ2WtVYBYbYiQl7om
4R3UYFAX/HGJDHVmnngBgYA7jjkOdbfRr76XiTJyLYtJGJCSJC+4mIGb2oOLOAsEsxbrprn9FgPc
pwaYDwakYjte+fo64qf+Nh3fNakMd6UoKwlMCNvNxOvZeNbjd80cqvx9vB658mnCuZaW89bZTtnN
zPPZzVaapwcjcpZu1bSqZPaD3O7e3WIODXqtRm3s+6MDEi5P4G+Jzv+Mjo+ZH39IS3OQlhiGFeBn
L4P3n+jHP/n6DwAAAP//AwBQSwMEFAAGAAgAAAAhAE/m6cJDAQAAWwIAABEACAFkb2NQcm9wcy9j
b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySXUvDMBSG7wX/Q8l9
l/Rjc4Q2A5VdbSA4UbwLydkWbNKQxHX797ZdVyd64WV43/Pw5CTF4qir6ADOq9qUKJkQFIERtVRm
V6KXzTKeo8gHbiSvagMlOoFHC3Z7UwhLRe3gydUWXFDgo5ZkPBW2RPsQLMXYiz1o7idtw7Thtnaa
h/bodthy8cF3gFNCZlhD4JIHjjtgbEciGpBSjEj76aoeIAWGCjSY4HEySfB3N4DT/s+BPrlqahVO
tr3ToHvNluIcju2jV2OxaZpJk/UarX+C39ar5/6qsTLdrgQg1u2n4j6s21VuFcj7E1vdZVOSF/h3
0pUdHFT3CCxJ+8p4LqToxalwwAPIqFWhZ/FL8po9PG6WiKUkyWMyi0m+SQnN55SQ9wJfWsM8G4F6
cPsnMaXT7CfxAmC98c/vwL4AAAD//wMAUEsDBBQABgAIAAAAIQAMSkw/LwMAAH0PAAASAAAAd29y
ZC9udW1iZXJpbmcueG1szJdLbtswEED3BXoHQ/tEki1/akQJ8jOQIg2KJkXXskTHRPkRSMqOt71M
jtBj9QodkqIi24EQK27hjWlxhjPDx+GQPDl7oqSzQEJizmIvPA68DmIpzzB7jL3vD5OjkdeRKmFZ
QjhDsbdC0js7/fjhZDlmBZ0iAYodsMHkeAHiuVL52PdlOkc0kcc8RwyEMy5oouBTPPo0ET+L/Cjl
NE8UnmKC1crvBsHAK83w2CsEG5cmjihOBZd8pvSQMZ/NcIrKxo0Qb/FrR17xtKCIKePRF4hADJzJ
Oc6ls0bbWoMpzp2RRdMkFpQ4vWX+Fm+ZSJbAmRIb9pKLLBc8RVJC75UVVhbDoMl3CVCbqEa8JYR1
ny4SmmBWmdHpsbH+1eIdw+L51revTb1MBFicQjIlU6lEkqq7gnbWvm6y2AuMCpM4A9kiIdDTC0fD
8OLS8/VgWhCFb9ECkYdVjpzOfDUVOPuiZUTLrK6iOXEa3eEkCvrRtZWQhRZgaLRH+Ktyksbe5fn5
dTeMBiYG2ApCueGhHQf7YEKrzmlBCFJWkt+rFani+Ta5vMVSXdQUwNcDeqrG8iqQz6lzQtDMWfsq
9GQVoCpbpwMR6HhzLmNvNIi0Ff9FETONTduxUviYJ+zR7PCo1y21c2tdlM2EMyVBM5EpxgCBFwIj
0blDS+1pfg6Lsd2LGbjI0CwB5qVZYw+CgZnqoOuMwxfGQRR8CoKg14LxP0AYRlHQwNCI6xB7A6e+
B4gprOEm7d24dre49k0PlD2odrpKh+/n/OfXs0ZkVrR9snbDCp1L63q2GnEb0j8gufURBkW9Stb1
vt2Q9raQ2uTdM9Lf+0A6GrlsfBWpFrdBer+iUw7nVsWz1rEbzGgLpsW7V5j7KKWwr5tQGnEblJvb
+9Vi+v46YHe9OcPK+nqwdQCOoSbSRtyG9Pqet5zX+3ZLXbikumtBifRg60AfAmw4xIy4DdLatrc8
ax27wRxuwTzQOtAfNp5SRtwG5X+qA/CC20jag60Dg6jx8DLiNqTX93ybOgBX2NoTRV984NINocCv
fqHYG1VN40bfue1TpdyFoGmu5dDaZ/PpXwAAAP//AwBQSwMEFAAGAAgAAAAhACLsxLLNAgAAgwoA
ABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzEls9u2jAcx++T9g6R72vsECig0qqwcuxhZdrZBAOWYjuy
A5Tzjjtue41pL9C32U7T3mE/2wm0kKxE2h8iiPg6dpyPv7+vc3F1L9JgzbThSg4QOcMoYDJRMy4X
A/R2Mn7VRYHJqZzRVEk2QFtm0NXlyxcXm/5cydwE0F+avh6gZZ5n/TA0yZIJas5UxiS0zZUWNIe/
ehGq+Zwn7LVKVoLJPIww7oSapTSHe5slzwwqRtucMtpG6VmmVcKMgcmK1I8nKJfosphdsOlLKmDW
I7XSnOnglm1cY0alMoxA+5qmA4QjfI5buAfnCLfhG+MYhXaUZEm1YfnuQuzlORU83ZaqUDOmpW/J
eJ4sy4Y5v2czrxu+AHVlpniAbjDG0fV4jLxCYH6gnHfjVqFEMCX/6RVKa6fAAsG03DjuEuLHAQXG
KXq5WYZ+hY5YTLhgxpII3ihBPaxjHhHuAJE2kLA8Wo14aDeu4/cEx5pqTqcpa0CE/Asi78A/1vCm
0hvtEur+7B/g0BuRl596g65y5fUTUZR3KR4cFpUU0hEKZwWwVKU5uo96nW6Ou62YqrSGQxsT8AKB
Wum4OjlvwKG5J/4viBFN+VTzShIRHruqsGkRQ23AbzWJyrQwG25MI0vYvMDR47yIQbge7ZR9XpT1
UmkJR5T0XO40sAQXdysfEzTNbyFPy3j7/uXDt4ePxaMcJSoBl2CgQ8qjklG34+U/UzVlgELVRN3u
2D7wYdWQTqHUIbJsHcbTEU3oEiKvxitD4GBdYrM0/vtegbSIbnbOKPaWDm4PD0FEz+0tsHBN95Yh
hVeFhQNx4JUfXz/9fP+5zist5xXgXh7VXiG/94pU+USv2GSbsePNp2YvthaBT1k3dg/t+ckc8iKl
leqM4xLX9jrdOCMqIGTqnGP3Xu8buxc3S5nmeVudMjjeeWmfMs+RAJ7PpkzxemIufwEAAP//AwBQ
SwMEFAAGAAgAAAAhAPLkWAoBAgAAAwQAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFNdb9MwFH1H4j9EeWZxErpuVK4n1An1YbBKzbZn49wk
Fo5t2W5Z+fVcJ2ubAk/k6X7l+PjcY3r32qtkD85Lo5dpkeVpAlqYWup2mT5VX65u08QHrmuujIZl
egCf3rH37+jGGQsuSPAJQmi/TLsQ7IIQLzrouc+wrbHTGNfzgKlriWkaKeDeiF0POpAyz+cEXgPo
GuorewJMR8TFPvwvaG1E5Oefq4NFwoxW0FvFA7BvkY7KahN6Sk5VWpnAVSV7YEVZYOOU0g1vwbPi
mpIxoi/G1Z7Nrj/dUDLGdNVxx0VAFVk5L3OcnVToZ2uVFDygwuyrFM5404TkcdAiiQiUTEco6rMF
sXMyHFhOyTSlD1Ijm7K4pWQMkZ/jreO282yOzCcp3QquYIU6sIYrD5ScC3QNPO54wyWSpvuw2IMI
xiVe/sItl2nynXuI6i3TPXeS64AqxrExGWJlfXCskkEhNvbGfAinY9NYzhiSxFkMLgdjceSAjUt2
wwn+scG7hX+QLaZkBw4j1QmdSXg64w/Ulekt1we23vGfIJMKRKeNMm00+MpkHx5CneFe36biIn74
J1uZ++iqN30vixNbvMjQbS0XuLuP+c0MJTgbZNKjWzQS1LjxI+K5QNe4DKfisfivbqE+zvzdiJZ7
Ht80+jnL8Rs8dqyhTU6Pjf0GAAD//wMAUEsBAi0AFAAGAAgAAAAhAGODGMqOAQAApQYAABMAAAAA
AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAmVV+BQQBAADh
AgAACwAAAAAAAAAAAAAAAADHAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAQUIjRBgBAAA5
BAAAHAAAAAAAAAAAAAAAAAD8BgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQA
BgAIAAAAIQAiiprBcWYAAN0SBwARAAAAAAAAAAAAAAAAAFYJAAB3b3JkL2RvY3VtZW50LnhtbFBL
AQItABQABgAIAAAAIQC8RAlz2AMAAIMPAAARAAAAAAAAAAAAAAAAAPZvAAB3b3JkL2NvbW1lbnRz
LnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAAP1zAAB3b3JkL3Ro
ZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAPz9H3G8DAABECAAAEQAAAAAAAAAAAAAAAADG
egAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAIRTVgisBAACOAgAAFAAAAAAAAAAA
AAAAAABkfgAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA6Ks786oJAADsRwAA
DwAAAAAAAAAAAAAAAADBfwAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAI64T8EVAwAA
bQUAABMAAAAAAAAAAAAAAAAAmIkAAGRvY1Byb3BzL2N1c3RvbS54bWxQSwECLQAUAAYACAAAACEA
T+bpwkMBAABbAgAAEQAAAAAAAAAAAAAAAADmjQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA
CAAAACEADEpMPy8DAAB9DwAAEgAAAAAAAAAAAAAAAABgkAAAd29yZC9udW1iZXJpbmcueG1sUEsB
Ai0AFAAGAAgAAAAhACLsxLLNAgAAgwoAABIAAAAAAAAAAAAAAAAAv5MAAHdvcmQvZm9udFRhYmxl
LnhtbFBLAQItABQABgAIAAAAIQDy5FgKAQIAAAMEAAAQAAAAAAAAAAAAAAAAALyWAABkb2NQcm9w
cy9hcHAueG1sUEsFBgAAAAAOAA4AgQMAAPOZAAAAAA==

--_004_4A95BA014132FF49AE685FAB4B9F17F645D2E2D7dfweml701chmchi_--


From nobody Thu Jun  5 00:13:31 2014
Return-Path: <sevil.mehraghdam@uni-paderborn.de>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A765D1A006B for <sfc@ietfa.amsl.com>; Thu,  5 Jun 2014 00:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.5
X-Spam-Level: 
X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qnvYOth6iDx for <sfc@ietfa.amsl.com>; Thu,  5 Jun 2014 00:13:24 -0700 (PDT)
Received: from mail.uni-paderborn.de (mail.uni-paderborn.de [131.234.142.9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6E01A00E9 for <sfc@ietf.org>; Thu,  5 Jun 2014 00:13:23 -0700 (PDT)
Received: from eeyore.cs.uni-paderborn.de ([131.234.40.154]) by mail.uni-paderborn.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80 spheron) id 1WsRrO-0002g3-Ir for sfc@ietf.org; Thu, 05 Jun 2014 09:13:15 +0200
Message-ID: <5390188A.8030000@uni-paderborn.de>
Date: Thu, 05 Jun 2014 09:13:14 +0200
From: Sevil Mehraghdam <sevil.mehraghdam@uni-paderborn.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: sfc@ietf.org
References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se>
In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se>
Content-Type: multipart/alternative; boundary="------------050900050009070405030006"
X-IMT-Spam-Score: 0.0 ()
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.5.70618
X-IMT-Authenticated-Sender: uid=sevilmeh,ou=People,o=upb,c=de
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/GN7nGkLnDbVmG7hvDdOvOkkwvck
Subject: [sfc] Specifying chains of network functions [Re: Figures in draft-quinn-sfc-arch-05]
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 07:13:29 -0000

This is a multi-part message in MIME format.
--------------050900050009070405030006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

I am new to this mailing list, and regarding the discussion about 
representing the chained functions, I would like to draw your attention 
to our work:

"Specifying and Placing Chains of Virtual Network Functions" 
(http://arxiv.org/abs/1406.1058)

We have defined a language for specifying the chaining among network 
functions. We use it for describing an optimization problem for 
placement of chained functions in a geographically distributed network 
based on given deployment requests. The paper is currently under review, 
and we are working on extending our model and language as new 
requirements and details about virtual network functions and the chains 
become available. Comments and suggestions are welcome!

Best regards,
Sevil Mehraghdam



On 05/30/2014 05:03 PM, Eric Gray wrote:
>
> Linda,
>
> It may be a mathematically correct expression (depending on interpretation
>
> of the notation used), but networking is not necessarily (possibly 
> even usually) a
>
> mathematical operation.
>
> There is nothing "intuitively obvious" in this expression that makes 
> it clear
>
> that "load sharing" is taking place between the sets of sf2 and sf4 
> instances, or how
>
> the "or" operation takes place.
>
> One literal way to interpret this notation (as a mathematical 
> expression) is
>
> that each the functions sf2, sf2' and sf2" are "visited" sequentially 
> and passed on
>
> to sf3 ­*/as soon as it succeeds in any of the functions/*. With this 
> interpretation, since
>
> the service function performed at each sf2 instance is presumed to be 
> identical,
>
> what the expression means is that either the service function will 
> succeed at sf2
>
> (and always skip sf2' and sf2"), or that it will fail at each sf2 
> instance.
>
> An equally legitimate "parallel computing" (not exactly mathematical, but
>
> possibly viewed as more closely analogous to networking) 
> interpretation would
>
> be that processing passes (on success at sf1) to */each/* of sf2, sf2' 
> and sf2" in parallel
>
> and then proceeds to sf3 on success at any of the sf2 instances.
>
> None of these interpretations corresponds to  "load sharing" -- yet 
> all are
>
> perfectly legitimate interpretation of your suggested expression/notation.
>
> And yet, these are actually more common interpretation of the usage of
>
> an "or" operation to computing folks (which many of us are), depending 
> on their
>
> specific background in computing.
>
> As I said before, I have no objection to the suggested notation you and
>
> Lucy proposed -- provided that the notation is explained.  I am 
> unclear as to what
>
> value this usage -- and included explanation may have -- but this is 
> largely a style
>
> issue, and best left up to the draft editors at this point.
>
> And, as I also said, there may be others who would prefer not to have too
>
> much textual explanation necessary in order to understand a figure.
>
> Finally, you must realize that there are a fairly large number of 
> folks who
>
> read-over mathematical expressions as if they were written in a 
> foreign language.
>
> For this reason, even if it were a perfectly useful/correct 
> mathematical expression,
>
> a number of folks would */still/* need a picture.
>
> --
>
> Eric
>
> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com]
> *Sent:* Thursday, May 29, 2014 5:42 PM
> *To:* Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul 
> Quinn (paulq)
> *Cc:* sfc@ietf.org
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
> *Importance:* High
>
> Eric,
>
> How about this shorter one?
>
> ->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}->
>
> The intent is pretty simple: If a service function on a chain has 
> multiple instances, one of the service function's instances is 
> selected to treat packets belonging to the service chain.
>
> This is a correct mathematics expression.
>
> There is really no need draw all those boxes.
>
> Linda
>
> *From:*Eric Gray [mailto:eric.gray@ericsson.com]
> *Sent:* Thursday, May 29, 2014 4:23 PM
> *To:* Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; 
> Paul Quinn (paulq)
> *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
>
> Linda,
>
> By the way, your proposal for Figure 5 would require a column width of 
> at least 80
>
> characters (more than you are supposed to have in an ID), and the 
> situation would
>
> be worse if it were applied to figure 6.
>
> For figure 5, you can improve the width slightly by fixing up a few of 
> your arrows,
>
> and even more by wrapping the figure.  Wrapping  might detract from 
> simplicity,
>
> however.
>
> --
>
> Eric
>
> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com]
> *Sent:* Thursday, May 29, 2014 4:49 PM
> *To:* Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul 
> Quinn (paulq)
> *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
> *Importance:* High
>
> I like the Figures drawn by Lucy.
>
> Actually why can't Figure 5 be simplified as
>
> enter 
> -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5}--> exit
>
> ??
>
> Linda
>
> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Lucy yong
> *Sent:* Thursday, May 29, 2014 1:12 PM
> *To:* Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
> *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
> *Subject:* Re: [sfc] Figures in draft-quinn-sfc-arch-05
>
> For readability on these figures, propose:
>
> Figure 5:
>
> +-sf2-+       +-sf4-+
>
> |     |       |     |
>
> enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit
>
> |     |       |     |
>
> +-sf2-+       +-sf4-+
>
> Figure 6:
>
> +-sf2-+              +-sf4-+
>
> |     |              |     |
>
> enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit
>
> |     |              |     |
>
> +-sf2-+              +-sf4-+
>
> lucy
>
> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric Gray
> *Sent:* Thursday, May 29, 2014 12:54 PM
> *To:* Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
> *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
> *Subject:* Re: [sfc] Figures in draft-quinn-sfc-arch-05
>
> HaHa, funny man. J
>
> *From:*Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
> *Sent:* Thursday, May 29, 2014 1:43 PM
> *To:* Eric Gray; Joel Halpern; Paul Quinn (paulq)
> *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
> *Importance:* High
>
> You could turn the whole picture right by 90 degrees.
>
> If you don't like top to bottom instead of left to right, make a note 
> that it's in landscape.
>
> --Jakob
>
> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric Gray
> *Sent:* Thursday, May 29, 2014 8:31 AM
> *To:* Joel Halpern; Paul Quinn (paulq)
> *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
> *Subject:* [sfc] Figures in draft-quinn-sfc-arch-05
>
> Paul/Joel,
>
>                 Pretty sure that Figures 5 and 6 don't actually fit 
> the width expected for an
>
> Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 
> is wider still).
>
>                 Depending on how a reader tries to read the draft, 
> this can turn complicated
>
> illustrations into a _/real/_ fun time. J
>
>                 Also, I am unsure what the figures are trying to 
> convey with some of "dotted
>
> lines" crossing the service functions.  If the intent is to show that 
> a service function is
>
> a virtual instance hosted by some network device, perhaps this will be 
> better shown
>
> in a separate figure and this aspect of Figures 5 and 6 can be eliminated?
>
> I would suggest replacing Figure 5 with a figure along the lines of:
>
> source             +-----+       +-----+
>
>   |            +-->| sf2 +--+   +-->| sf4 +--+
>
>   |            |   |     |  |            |   | |  |
>
>   |  +------+--+   +-----+  +-->+-----+--+ +-----+  +->+-----+
>
>   |  | sf1  |      +-----+      | sf3 | +-----+     | sf5 |
>
>   +->|      +----->| sf2 +----->| |----->| sf4 +---->|     |-+
>
>      |      |      |     |      |     |      | |     |     | |
>
>      +------+--+   +-----+  +-->+-----+--+ +-----+  +->+-----+ |
>
>                |   +-----+  |            | +-----+  |          |
>
>                +-->| sf2 +--+   +-->| sf4 +--+     +----+
>
>                    |     |                   | |        |
>
>                    +-----+       +-----+        V
>
>                                           destination
>
>                    Figure 5: Load Balancing
>
> (67 characters?)
>
>                 Similarly, I would suggest replacing Figure 6 with a 
> figure along the
>
> lines of:
>
>     source
>       |               +-----+-+                   +-----+-+
>   +---+           +-->| sf2 |-|+              +-->| sf4 |-|+
>   |           +---|-->|     | ||          +------>|     | ||
>   |   +------+|---+   +-----+ |+-->+-----+|---+   +-----+ |+-->+-----+
>   |   | sf1  ||       +-----+ +--->| sf3 ||       +-----+ +--->| sf5 |
>   +-->|      +|------>| sf2 |+---->|     ||------>| sf4 |+---->|     |--+
>   |   |      || +---->|     |-+    |     || +---->|     |-+    |     |  |
>   |   +------+|-|-+   +-----+ |+-->+-----+|-|-+   +-----+ |+-->+-----+  |
>   |           | | |   +-----+ ||          | | |   +-----+ ||            |
>   |   +------++ | +-->| sf2 |-|+   +-----++ | +-->| sf4 |-|+   +-----+  |
>   |   | sf1' |  | +-->|     | +--->| sf3'|  | +-->|     | +--->| sf5'|  |
>   +-->|      +--+ |   +-----+----->|     |--+ |   +-----+----->|     |--+
>       |      |    |                |     |    |                |     |  |
>       +------+----+                +-----+----+                +-----+  |
>                                                                         |
>                                                                +--------+
>                                                                |
>                                                                V
>                                                           destination
>   
>                      Figure 6: Load Balancing and HA
>
> (72 characters?)
>
>                 In both cases, the figure has all the same connection 
> complexity (fixed up in a few
>
> places), but seems to be less busy.
>
> --
>
> Eric
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

-- 
Sevil Mehraghdam
University of Paderborn
Computer Networks group -- http://wwwcs.upb.de/cs/ag-karl
Tel.: +49 5251 / 601755
Room: O3.161


--------------050900050009070405030006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hello,<br>
    <br>
    I am new to this mailing list, and regarding the discussion about
    representing the chained functions, I would like to draw your
    attention to our work:<br>
    <br>
    "Specifying and Placing Chains of Virtual Network Functions"
    (<a class="moz-txt-link-freetext" href="http://arxiv.org/abs/1406.1058">http://arxiv.org/abs/1406.1058</a>) <br>
    <br>
    We have defined a language for specifying the chaining among network
    functions. We use it for describing an optimization problem for
    placement of chained functions in a geographically distributed
    network based on given deployment requests. The paper is currently
    under review, and we are working on extending our model and language
    as new requirements and details about virtual network functions and
    the chains become available. Comments and suggestions are welcome!<br>
    <br>
    Best regards,<br>
    Sevil Mehraghdam<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/30/2014 05:03 PM, Eric Gray
      wrote:<br>
    </div>
    <blockquote
cite="mid:48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (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:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:"Lucida Console";
	panose-1:2 11 6 9 4 5 4 2 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;}
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";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.grey
	{mso-style-name:grey;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Lucida Console";
	color:#7030A0;}
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="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">Linda,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            It may be a mathematically correct expression (depending on
            interpretation<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">of the notation
            used), but networking is not necessarily (possibly even
            usually) a
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">mathematical
            operation.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            There is nothing &#8220;intuitively obvious&#8221; in this expression
            that makes it clear<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">that &#8220;load
            sharing&#8221; is taking place between the sets of sf2 and sf4
            instances, or how<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">the &#8220;or&#8221;
            operation takes place.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            One literal way to interpret this notation (as a
            mathematical expression) is<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">that each the
            functions sf2, sf2&#8217; and sf2&#8221; are &#8220;visited&#8221; sequentially and
            passed on
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">to sf3 &shy;<b><i>as
                soon as it succeeds in any of the functions</i></b>.&nbsp;
            With this interpretation, since
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">the service
            function performed at each sf2 instance is presumed to be
            identical,
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">what the
            expression means is that either the service function will
            succeed at sf2
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">(and always
            skip sf2&#8217; and sf2&#8221;), or that it will fail at each sf2
            instance.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            An equally legitimate &#8220;parallel computing&#8221; (not exactly
            mathematical, but<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">possibly viewed
            as more closely analogous to networking) interpretation
            would
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">be that
            processing passes (on success at sf1) to
            <b><i>each</i></b> of sf2, sf2&#8217; and sf2&#8221; in parallel<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">and then
            proceeds to sf3 on success at any of the sf2 instances.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            None of these interpretations corresponds to &nbsp;&#8220;load sharing&#8221;
            &#8211; yet all are
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">perfectly
            legitimate interpretation of your suggested
            expression/notation.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            And yet, these are actually more common interpretation of
            the usage of<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">an &#8220;or&#8221;
            operation to computing folks (which many of us are),
            depending on their<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">specific
            background in computing.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            As I said before, I have no objection to the suggested
            notation you and<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Lucy proposed &#8211;
            provided that the notation is explained.&nbsp; I am unclear as to
            what<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">value this
            usage &#8211; and included explanation may have &#8211; but this is
            largely a style<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">issue, and best
            left up to the draft editors at this point.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            And, as I also said, there may be others who would prefer
            not to have too<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">much textual
            explanation necessary in order to understand a figure.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            Finally, you must realize that there are a fairly large
            number of folks who<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">read-over
            mathematical expressions as if they were written in a
            foreign language.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">For this
            reason, even if it were a perfectly useful/correct
            mathematical expression,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">a number of
            folks would <b><i>still</i></b> need a picture.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">--<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Eric<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                Linda Dunbar [<a class="moz-txt-link-freetext" href="mailto:linda.dunbar@huawei.com">mailto:linda.dunbar@huawei.com</a>]
                <br>
                <b>Sent:</b> Thursday, May 29, 2014 5:42 PM<br>
                <b>To:</b> Eric Gray; Lucy yong; Jakob Heitz (jheitz);
                Joel Halpern; Paul Quinn (paulq)<br>
                <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
                <b>Importance:</b> High<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><span style="color:#1F497D">Eric, <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">How about this
            shorter one?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">-&gt;{sf1}-&gt;{sf2|sf2&#8217;|sf2&#8217;&#8217;}-&gt;{sf3}-&gt;{sf4|sf4&#8217;|sf4&#8217;&#8217;}-&gt;{sf5}-&gt;<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">The intent is
            pretty simple: If a service function on a chain has multiple
            instances, one of the service function&#8217;s instances is
            selected to treat packets belonging to the service chain. &nbsp;<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">This is a
            correct mathematics expression.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">There is really
            no need draw all those boxes.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Linda &nbsp;<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                Eric Gray [<a moz-do-not-send="true"
                  href="mailto:eric.gray@ericsson.com">mailto:eric.gray@ericsson.com</a>]
                <br>
                <b>Sent:</b> Thursday, May 29, 2014 4:23 PM<br>
                <b>To:</b> Linda Dunbar; Lucy yong; Jakob Heitz
                (jheitz); Joel Halpern; Paul Quinn (paulq)<br>
                <b>Cc:</b> <a moz-do-not-send="true"
                  href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><span style="color:#1F497D">Linda,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">By the way,
            your proposal for Figure 5 would require a column width of
            at least 80<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">characters
            (more than you are supposed to have in an ID), and the
            situation would<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">be worse if it
            were applied to figure 6.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">For figure 5,
            you can improve the width slightly by fixing up a few of
            your arrows,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">and even more
            by wrapping the figure.&nbsp; Wrapping &nbsp;might detract from
            simplicity,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">however.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">--<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Eric<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                Linda Dunbar [<a moz-do-not-send="true"
                  href="mailto:linda.dunbar@huawei.com">mailto:linda.dunbar@huawei.com</a>]
                <br>
                <b>Sent:</b> Thursday, May 29, 2014 4:49 PM<br>
                <b>To:</b> Lucy yong; Eric Gray; Jakob Heitz (jheitz);
                Joel Halpern; Paul Quinn (paulq)<br>
                <b>Cc:</b> <a moz-do-not-send="true"
                  href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
                <b>Importance:</b> High<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><span style="color:#1F497D">I like the
            Figures drawn by Lucy.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Actually why
            can&#8217;t Figure 5 be simplified as
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;
            enter
            --&gt;{sf1}--&gt;-{sf2|sf2&#8217;|sf2&#8217;&#8217;}-&gt;--{sf3}--&gt;-{sf4|sf4&#8217;|sf4&#8217;&#8217;}-&gt;--{sf5}--&gt;
            exit<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">??<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Linda<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                sfc [<a moz-do-not-send="true"
                  href="mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
                <b>On Behalf Of </b>Lucy yong<br>
                <b>Sent:</b> Thursday, May 29, 2014 1:12 PM<br>
                <b>To:</b> Eric Gray; Jakob Heitz (jheitz); Joel
                Halpern; Paul Quinn (paulq)<br>
                <b>Cc:</b> <a moz-do-not-send="true"
                  href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> Re: [sfc] Figures in
                draft-quinn-sfc-arch-05<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><span style="color:#1F497D">For readability
            on these figures, propose:<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Courier
            New&quot;;color:#1F497D">Figure 5:<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf4-+<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            enter
            --&gt;sf1--&gt;-sf2-&gt;--sf3--&gt;-sf4-&gt;--sf5--&gt; exit<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf4-+<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">Figure
            6:<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf4-+<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;
            enter
            --&gt;{sf1|sf1'}--&gt;-sf2-&gt;--{sf3|sf3'}--&gt;-sf4-&gt;--{sf5}--&gt;
            exit<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf4-+<span style="color:#1F497D"><o:p></o:p></span></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">lucy<o:p></o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                sfc [<a moz-do-not-send="true"
                  href="mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
                <b>On Behalf Of </b>Eric Gray<br>
                <b>Sent:</b> Thursday, May 29, 2014 12:54 PM<br>
                <b>To:</b> Jakob Heitz (jheitz); Joel Halpern; Paul
                Quinn (paulq)<br>
                <b>Cc:</b> <a moz-do-not-send="true"
                  href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> Re: [sfc] Figures in
                draft-quinn-sfc-arch-05<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><span style="color:#1F497D">HaHa, funny
            man.&nbsp; </span><span
            style="font-family:Wingdings;color:#1F497D">J</span><span
            style="color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                Jakob Heitz (jheitz) [<a moz-do-not-send="true"
                  href="mailto:jheitz@cisco.com">mailto:jheitz@cisco.com</a>]
                <br>
                <b>Sent:</b> Thursday, May 29, 2014 1:43 PM<br>
                <b>To:</b> Eric Gray; Joel Halpern; Paul Quinn (paulq)<br>
                <b>Cc:</b> <a moz-do-not-send="true"
                  href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
                <b>Importance:</b> High<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Lucida
            Console&quot;;color:#7030A0">You could turn the whole
            picture right by 90 degrees.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Lucida
            Console&quot;;color:#7030A0">If you don&#8217;t like top to bottom
            instead of left to right, make a note that it&#8217;s in
            landscape.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Lucida
            Console&quot;;color:#7030A0"><o:p>&nbsp;</o:p></span></p>
        <div>
          <p class="MsoNormal"><span style="color:#7030A0">--Jakob<o:p></o:p></span></p>
        </div>
        <p class="MsoNormal"><span
            style="font-size:8.0pt;font-family:&quot;Lucida
            Console&quot;;color:#7030A0"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                sfc [<a moz-do-not-send="true"
                  href="mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
                <b>On Behalf Of </b>Eric Gray<br>
                <b>Sent:</b> Thursday, May 29, 2014 8:31 AM<br>
                <b>To:</b> Joel Halpern; Paul Quinn (paulq)<br>
                <b>Cc:</b> <a moz-do-not-send="true"
                  href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> [sfc] Figures in draft-quinn-sfc-arch-05<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Paul/Joel,<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pretty sure that Figures 5
          and 6 don&#8217;t actually fit the width expected for an
          <o:p></o:p></p>
        <p class="MsoNormal">Internet Draft (Figure 5 is more than 80
          characters wide and Figure 6 is wider still).<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Depending on how a reader
          tries to read the draft, this can turn complicated
          <o:p></o:p></p>
        <p class="MsoNormal">illustrations into a _<i>real</i>_ fun
          time.&nbsp; <span style="font-family:Wingdings">
            J</span><o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Also, I am unsure what the
          figures are trying to convey with some of &#8220;dotted
          <o:p></o:p></p>
        <p class="MsoNormal">lines&#8221; crossing the service functions.&nbsp; If
          the intent is to show that a service function is
          <o:p></o:p></p>
        <p class="MsoNormal">a virtual instance hosted by some network
          device, perhaps this will be better shown<o:p></o:p></p>
        <p class="MsoNormal">in a separate figure and this aspect of
          Figures 5 and 6 can be eliminated?<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal" style="text-indent:.5in">I would suggest
          replacing Figure 5 with a figure along the lines of:<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">source &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;|&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+--&gt;| sf2 +--+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            &nbsp;&nbsp;+--&gt;| sf4 +--+<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
            |&nbsp; |<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;| &nbsp;+------+--+&nbsp;&nbsp; +-----+&nbsp; +--&gt;+-----+--+&nbsp;&nbsp;
            +-----+&nbsp; +-&gt;+-----+<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;| &nbsp;| sf1&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | sf3 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            +-----+&nbsp;&nbsp;&nbsp; &nbsp;| sf5 |<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;+-&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----&gt;| sf2 +-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp;
            |-----&gt;| sf4 +----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-+<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp; &nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; | |<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+------+--+&nbsp;&nbsp; +-----+&nbsp; +--&gt;+-----+--+&nbsp;&nbsp;
            +-----+&nbsp; +-&gt;+-----+ |<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp; +-----+&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;|&nbsp;&nbsp;
            +-----+&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+--&gt;| sf2 +--+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            &nbsp;&nbsp;+--&gt;| sf4 +--+ &nbsp;&nbsp;&nbsp;&nbsp;+----+<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;|<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;V<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;destination<o:p></o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal" style="page-break-before:always"><span
            style="font-size:10.0pt;font-family:&quot;Courier New&quot;"
            lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Figure 5: Load Balancing<o:p></o:p></span></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">(67 characters?)<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Similarly, I would suggest
          replacing Figure 6 with a figure along the
          <o:p></o:p></p>
        <p class="MsoNormal">lines of:<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp; source<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+-+<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> +---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--&gt;| sf2 |-|+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--&gt;| sf4 |-|+<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---|--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | ||<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; +------+|---+&nbsp;&nbsp; +-----+ |+--&gt;+-----+|---+&nbsp;&nbsp; +-----+ |+--&gt;+-----+<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; | sf1&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+ +---&gt;| sf3 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+ +---&gt;| sf5 |<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +|------&gt;| sf2 |+----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; ||------&gt;| sf4 |+----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--+<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || +----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; || +----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; +------+|-|-+&nbsp;&nbsp; +-----+ |+--&gt;+-----+|-|-+&nbsp;&nbsp; +-----+ |+--&gt;+-----+ &nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | |&nbsp;&nbsp; +-----+ ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | |&nbsp;&nbsp; +-----+ ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; +------++ | +--&gt;| sf2 |-|+&nbsp;&nbsp; +-----++ | +--&gt;| sf4 |-|+&nbsp;&nbsp; +-----+ &nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; | sf1' |&nbsp; | +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | +---&gt;| sf3'|&nbsp; | +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | +---&gt;| sf5'| &nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--+ |&nbsp;&nbsp; +-----+-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--+ |&nbsp;&nbsp; +-----+-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--+<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp; +------+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+ &nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;destination<o:p></o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"><o:p>&nbsp;</o:p></span></pre>
        <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 6: Load Balancing and HA<o:p></o:p></span></pre>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">(72 characters?)<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In both cases, the figure
          has all the same connection complexity (fixed up in a few<o:p></o:p></p>
        <p class="MsoNormal">places), but seems to be less busy.<o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">--<o:p></o:p></p>
        <p class="MsoNormal">Eric<o:p></o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
sfc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sfc@ietf.org">sfc@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Sevil Mehraghdam 
University of Paderborn 
Computer Networks group &#8211; <a class="moz-txt-link-freetext" href="http://wwwcs.upb.de/cs/ag-karl">http://wwwcs.upb.de/cs/ag-karl</a>
Tel.: +49 5251 / 601755
Room: O3.161</pre>
  </body>
</html>

--------------050900050009070405030006--


From nobody Thu Jun  5 03:05:53 2014
Return-Path: <k.pentikousis@eict.de>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0041A0164 for <sfc@ietfa.amsl.com>; Thu,  5 Jun 2014 03:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EAYGJjyqEj7 for <sfc@ietfa.amsl.com>; Thu,  5 Jun 2014 03:05:47 -0700 (PDT)
Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 949EE1A014D for <sfc@ietf.org>; Thu,  5 Jun 2014 03:05:47 -0700 (PDT)
Received: by mx2.eict.de (Postfix, from userid 481) id BEBB51FF5F; Thu,  5 Jun 2014 12:05:40 +0200 (CEST)
Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 07E1C1FF58; Thu,  5 Jun 2014 12:05:40 +0200 (CEST)
Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id AEE6637825F; Thu,  5 Jun 2014 12:05:39 +0200 (CEST)
Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 5 Jun 2014 12:05:39 +0200
From: Kostas Pentikousis <k.pentikousis@eict.de>
To: SDN IRTF list <sdn@irtf.org>
Date: Thu, 5 Jun 2014 12:05:38 +0200
Thread-Topic: Feature topic on Network and Service Virtualization
Thread-Index: Ac+ApbNIasquQR2NTQKeJfkLNtERdw==
Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1642@SBS2008.eict.local>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HR9iYN5lWi2ZSdYQ_VKXKRPte6E
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: [sfc] Feature topic on Network and Service Virtualization
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 10:05:49 -0000

Dear all,

This is a kind reminder for those interested in submitting a paper to the I=
EEE Communications Magazine special issue on "Network and Service Virtualiz=
ation": http://www.comsoc.org/files/Publications/Magazines/ci/cfp/cfpcommag=
0215.html. The deadline is in 10 days (15 June 2014).

Papers from industry labs, which address a wider audience and conform to th=
e Magazine submission guidelines, are particularly solicited.=20

Best regards,

Kostas


From nobody Thu Jun  5 05:39:28 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0031A00D4; Thu,  5 Jun 2014 05:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-hv37OKjG9G; Thu,  5 Jun 2014 05:39:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 921861A00B5; Thu,  5 Jun 2014 05:39:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140605123922.808.30146.idtracker@ietfa.amsl.com>
Date: Thu, 05 Jun 2014 05:39:22 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TgFliK2IED1UIT3GJq4JhGg9zBY
Cc: sfc@ietf.org
Subject: [sfc] I-D Action: draft-ietf-sfc-long-lived-flow-use-cases-00.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 12:39:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : SFC Long-lived Flow Use Cases
        Authors         : Ram Krishnan
                          Anoop Ghanwani
                          Joel Halpern
                          Sriganesh Kini
                          Diego Lopez
	Filename        : draft-ietf-sfc-long-lived-flow-use-cases-00.txt
	Pages           : 10
	Date            : 2014-06-04

Abstract:
   Long-lived flows such as file transfers, video streams are common in
   today's networks. In the context of service function chaining, this
   draft suggests use cases for dynamic bypass of certain service nodes
   for such flows. The benefit of this approach would be to avoid
   expensive Layer 7 service node processing for such flows based on
   dynamic decisions and improve overall performance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sfc-long-lived-flow-use-cases-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Thu Jun  5 06:49:19 2014
Return-Path: <ddolson@sandvine.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E961A017E for <sfc@ietfa.amsl.com>; Thu,  5 Jun 2014 06:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn_J_ewKFOus for <sfc@ietfa.amsl.com>; Thu,  5 Jun 2014 06:49:11 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id CB08E1A0179 for <sfc@ietf.org>; Thu,  5 Jun 2014 06:49:10 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::c8c4:1c2a:2ea3:e874%14]) with mapi id 14.01.0438.000; Thu, 5 Jun 2014 09:49:04 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: Sevil Mehraghdam <sevil.mehraghdam@uni-paderborn.de>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Specifying chains of network functions [Re: Figures in draft-quinn-sfc-arch-05]
Thread-Index: AQHPgI2oT4IwXzeGhUysDZihsLuYJptigcug
Date: Thu, 5 Jun 2014 13:49:03 +0000
Message-ID: <E8355113905631478EFF04F5AA706E9830A0F891@wtl-exchp-2.sandvine.com>
References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se> <5390188A.8030000@uni-paderborn.de>
In-Reply-To: <5390188A.8030000@uni-paderborn.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.40]
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830A0F891wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/d2ALWs01NnIoE7SPH-wYl-5C1CE
Subject: Re: [sfc] Specifying chains of network functions [Re: Figures in draft-quinn-sfc-arch-05]
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 13:49:17 -0000

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

Sevil,
I only skimmed your work, so apologies if I've missed the point. I believe =
you are providing algorithms for converting high-level service requests int=
o concrete service chains, without using any specific implementation.

It seems to me this work is favorably complementary to the IETF's SFC work =
of determining the protocols of service chaining.
(IETF determines implementation of services chains, and your work decides w=
hich chains *should* be created.)

My question to you is, what assumptions do you need to make about the imple=
mentation of the chains that the SFC working group needs to consider in for=
ming requirements?

For example, it looks like your algorithm requires some inputs about maximu=
m numbers of functions and chains supported by each VNF.
Therefore we might see a need for a VNF to be able to expose that informati=
on in the protocol.

Looked at another way, which of the proposals (e.g., in http://tools.ietf.o=
rg/html/draft-boucadair-sfc-design-analysis-02) work with your approach and=
 which do not?

Something else you could look at, is the orchestration template proposal of=
 http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00 rigorous=
 enough to be solved?


David Dolson
Senior Software Architect, Sandvine Inc.




From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sevil Mehraghdam
Sent: Thursday, June 05, 2014 3:13 AM
To: sfc@ietf.org
Subject: [sfc] Specifying chains of network functions [Re: Figures in draft=
-quinn-sfc-arch-05]

Hello,

I am new to this mailing list, and regarding the discussion about represent=
ing the chained functions, I would like to draw your attention to our work:

"Specifying and Placing Chains of Virtual Network Functions" (http://arxiv.=
org/abs/1406.1058)

We have defined a language for specifying the chaining among network functi=
ons. We use it for describing an optimization problem for placement of chai=
ned functions in a geographically distributed network based on given deploy=
ment requests. The paper is currently under review, and we are working on e=
xtending our model and language as new requirements and details about virtu=
al network functions and the chains become available. Comments and suggesti=
ons are welcome!

Best regards,
Sevil Mehraghdam


On 05/30/2014 05:03 PM, Eric Gray wrote:
Linda,

                It may be a mathematically correct expression (depending on=
 interpretation
of the notation used), but networking is not necessarily (possibly even usu=
ally) a
mathematical operation.

                There is nothing "intuitively obvious" in this expression t=
hat makes it clear
that "load sharing" is taking place between the sets of sf2 and sf4 instanc=
es, or how
the "or" operation takes place.

                One literal way to interpret this notation (as a mathematic=
al expression) is
that each the functions sf2, sf2' and sf2" are "visited" sequentially and p=
assed on
to sf3 as soon as it succeeds in any of the functions.  With this interpret=
ation, since
the service function performed at each sf2 instance is presumed to be ident=
ical,
what the expression means is that either the service function will succeed =
at sf2
(and always skip sf2' and sf2"), or that it will fail at each sf2 instance.

                An equally legitimate "parallel computing" (not exactly mat=
hematical, but
possibly viewed as more closely analogous to networking) interpretation wou=
ld
be that processing passes (on success at sf1) to each of sf2, sf2' and sf2"=
 in parallel
and then proceeds to sf3 on success at any of the sf2 instances.

                None of these interpretations corresponds to  "load sharing=
" - yet all are
perfectly legitimate interpretation of your suggested expression/notation.

                And yet, these are actually more common interpretation of t=
he usage of
an "or" operation to computing folks (which many of us are), depending on t=
heir
specific background in computing.

                As I said before, I have no objection to the suggested nota=
tion you and
Lucy proposed - provided that the notation is explained.  I am unclear as t=
o what
value this usage - and included explanation may have - but this is largely =
a style
issue, and best left up to the draft editors at this point.

                And, as I also said, there may be others who would prefer n=
ot to have too
much textual explanation necessary in order to understand a figure.

                Finally, you must realize that there are a fairly large num=
ber of folks who
read-over mathematical expressions as if they were written in a foreign lan=
guage.
For this reason, even if it were a perfectly useful/correct mathematical ex=
pression,
a number of folks would still need a picture.

--
Eric

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: Thursday, May 29, 2014 5:42 PM
To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p=
aulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: Figures in draft-quinn-sfc-arch-05
Importance: High

Eric,

How about this shorter one?

->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}->

The intent is pretty simple: If a service function on a chain has multiple =
instances, one of the service function's instances is selected to treat pac=
kets belonging to the service chain.

This is a correct mathematics expression.
There is really no need draw all those boxes.

Linda

From: Eric Gray [mailto:eric.gray@ericsson.com]
Sent: Thursday, May 29, 2014 4:23 PM
To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn=
 (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: Figures in draft-quinn-sfc-arch-05

Linda,

By the way, your proposal for Figure 5 would require a column width of at l=
east 80
characters (more than you are supposed to have in an ID), and the situation=
 would
be worse if it were applied to figure 6.

For figure 5, you can improve the width slightly by fixing up a few of your=
 arrows,
and even more by wrapping the figure.  Wrapping  might detract from simplic=
ity,
however.

--
Eric

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: Thursday, May 29, 2014 4:49 PM
To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (p=
aulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: Figures in draft-quinn-sfc-arch-05
Importance: High

I like the Figures drawn by Lucy.

Actually why can't Figure 5 be simplified as

    enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5=
}--> exit

??

Linda

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 1:12 PM
To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

For readability on these figures, propose:

Figure 5:
                     +-sf2-+       +-sf4-+
                     |     |       |     |
       enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit
                     |     |       |     |
                     +-sf2-+       +-sf4-+
Figure 6:

                         +-sf2-+              +-sf4-+
                         |     |              |     |
    enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit
                         |     |              |     |
                         +-sf2-+              +-sf4-+

lucy
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
Sent: Thursday, May 29, 2014 12:54 PM
To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

HaHa, funny man.  :)

From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
Sent: Thursday, May 29, 2014 1:43 PM
To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: Figures in draft-quinn-sfc-arch-05
Importance: High

You could turn the whole picture right by 90 degrees.
If you don't like top to bottom instead of left to right, make a note that =
it's in landscape.

--Jakob

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
Sent: Thursday, May 29, 2014 8:31 AM
To: Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: [sfc] Figures in draft-quinn-sfc-arch-05

Paul/Joel,

                Pretty sure that Figures 5 and 6 don't actually fit the wid=
th expected for an
Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wi=
der still).

                Depending on how a reader tries to read the draft, this can=
 turn complicated
illustrations into a _real_ fun time.  :)

                Also, I am unsure what the figures are trying to convey wit=
h some of "dotted
lines" crossing the service functions.  If the intent is to show that a ser=
vice function is
a virtual instance hosted by some network device, perhaps this will be bett=
er shown
in a separate figure and this aspect of Figures 5 and 6 can be eliminated?

I would suggest replacing Figure 5 with a figure along the lines of:

source             +-----+                   +-----+
  |            +-->| sf2 +--+            +-->| sf4 +--+
  |            |   |     |  |            |   |     |  |
  |  +------+--+   +-----+  +-->+-----+--+   +-----+  +->+-----+
  |  | sf1  |      +-----+      | sf3 |      +-----+     | sf5 |
  +->|      +----->| sf2 +----->|     |----->| sf4 +---->|     |-+
     |      |      |     |      |     |      |     |     |     | |
     +------+--+   +-----+  +-->+-----+--+   +-----+  +->+-----+ |
               |   +-----+  |            |   +-----+  |          |
               +-->| sf2 +--+            +-->| sf4 +--+     +----+
                   |     |                   |     |        |
                   +-----+                   +-----+        V
                                                          destination

                   Figure 5: Load Balancing

(67 characters?)

                Similarly, I would suggest replacing Figure 6 with a figure=
 along the
lines of:


   source

     |               +-----+-+                   +-----+-+

 +---+           +-->| sf2 |-|+              +-->| sf4 |-|+

 |           +---|-->|     | ||          +------>|     | ||

 |   +------+|---+   +-----+ |+-->+-----+|---+   +-----+ |+-->+-----+

 |   | sf1  ||       +-----+ +--->| sf3 ||       +-----+ +--->| sf5 |

 +-->|      +|------>| sf2 |+---->|     ||------>| sf4 |+---->|     |--+

 |   |      || +---->|     |-+    |     || +---->|     |-+    |     |  |

 |   +------+|-|-+   +-----+ |+-->+-----+|-|-+   +-----+ |+-->+-----+  |

 |           | | |   +-----+ ||          | | |   +-----+ ||            |

 |   +------++ | +-->| sf2 |-|+   +-----++ | +-->| sf4 |-|+   +-----+  |

 |   | sf1' |  | +-->|     | +--->| sf3'|  | +-->|     | +--->| sf5'|  |

 +-->|      +--+ |   +-----+----->|     |--+ |   +-----+----->|     |--+

     |      |    |                |     |    |                |     |  |

     +------+----+                +-----+----+                +-----+  |

                                                                       |

                                                              +--------+

                                                              |

                                                              V

                                                         destination



                    Figure 6: Load Balancing and HA

(72 characters?)

                In both cases, the figure has all the same connection compl=
exity (fixed up in a few
places), but seems to be less busy.

--
Eric




_______________________________________________

sfc mailing list

sfc@ietf.org<mailto:sfc@ietf.org>

https://www.ietf.org/mailman/listinfo/sfc



--

Sevil Mehraghdam

University of Paderborn

Computer Networks group - http://wwwcs.upb.de/cs/ag-karl

Tel.: +49 5251 / 601755

Room: O3.161

--_000_E8355113905631478EFF04F5AA706E9830A0F891wtlexchp2sandvi_
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: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;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Lucida Console";
	panose-1:2 11 6 9 4 5 4 2 2 4;}
@font-face
	{font-family:"Courier New \;color\:\#1F497D";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Lucida Console \;color\:\#7030A0";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
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";
	color:black;}
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";
	color:black;}
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";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.grey
	{mso-style-name:grey;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Lucida Console";
	color:#7030A0;}
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 bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Sevil,<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I only skimmed your wo=
rk, so apologies if I&#8217;ve missed the point. I believe you are providin=
g algorithms for converting high-level service requests into concrete servi=
ce chains, without using any specific implementation.
<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">It seems to me this wo=
rk is favorably complementary to the IETF&#8217;s SFC work of determining t=
he protocols of service chaining.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">(IETF determines imple=
mentation of services chains, and your work decides which chains *<b>should=
</b>* be created.)<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">My question to you is,=
 what assumptions do you need to make about the implementation of the chain=
s that the SFC working group needs to consider in forming requirements?<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">For example, it looks =
like your algorithm requires some inputs about maximum numbers of functions=
 and chains supported by each VNF.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Therefore we might see=
 a need for a VNF to be able to expose that information in the protocol.<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">Looked at another way,=
 which of the proposals (e.g., in
<a href=3D"http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-0=
2">http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02</a>) w=
ork with your approach and which do not?<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">Something else you cou=
ld look at, is the orchestration template proposal of
<a href=3D"http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-0=
0">http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00</a> ri=
gorous enough to be solved?<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"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">David Dolson<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Senior Software Archit=
ect, Sandvine Inc.<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"><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"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></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:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> sfc [mailto:sfc-bounces@ietf.org]
<b>On Behalf Of </b>Sevil Mehraghdam<br>
<b>Sent:</b> Thursday, June 05, 2014 3:13 AM<br>
<b>To:</b> sfc@ietf.org<br>
<b>Subject:</b> [sfc] Specifying chains of network functions [Re: Figures i=
n draft-quinn-sfc-arch-05]<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hello,<br>
<br>
I am new to this mailing list, and regarding the discussion about represent=
ing the chained functions, I would like to draw your attention to our work:=
<br>
<br>
&quot;Specifying and Placing Chains of Virtual Network Functions&quot; (<a =
href=3D"http://arxiv.org/abs/1406.1058">http://arxiv.org/abs/1406.1058</a>)
<br>
<br>
We have defined a language for specifying the chaining among network functi=
ons. We use it for describing an optimization problem for placement of chai=
ned functions in a geographically distributed network based on given deploy=
ment requests. The paper is currently
 under review, and we are working on extending our model and language as ne=
w requirements and details about virtual network functions and the chains b=
ecome available. Comments and suggestions are welcome!<br>
<br>
Best regards,<br>
Sevil Mehraghdam<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On 05/30/2014 05:03 PM, Eric Gray wrote:<o:p></o:p><=
/p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Linda,</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It may=
 be a mathematically correct expression (depending on interpretation</span>=
<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">of the notation used),=
 but networking is not necessarily (possibly even usually) a
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">mathematical operation=
.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There =
is nothing &#8220;intuitively obvious&#8221; in this expression that makes =
it clear</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">that &#8220;load shari=
ng&#8221; is taking place between the sets of sf2 and sf4 instances, or how=
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">the &#8220;or&#8221; o=
peration takes place.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; One li=
teral way to interpret this notation (as a mathematical expression) is</spa=
n><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">that each the function=
s sf2, sf2&#8217; and sf2&#8221; are &#8220;visited&#8221; sequentially and=
 passed on
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">to sf3 &shy;<b><i>as s=
oon as it succeeds in any of the functions</i></b>.&nbsp; With this interpr=
etation, since
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">the service function p=
erformed at each sf2 instance is presumed to be identical,
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">what the expression me=
ans is that either the service function will succeed at sf2
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">(and always skip sf2&#=
8217; and sf2&#8221;), or that it will fail at each sf2 instance.</span><o:=
p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An equ=
ally legitimate &#8220;parallel computing&#8221; (not exactly mathematical,=
 but</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">possibly viewed as mor=
e closely analogous to networking) interpretation would
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">be that processing pas=
ses (on success at sf1) to
<b><i>each</i></b> of sf2, sf2&#8217; and sf2&#8221; in parallel</span><o:p=
></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">and then proceeds to s=
f3 on success at any of the sf2 instances.
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; None o=
f these interpretations corresponds to &nbsp;&#8220;load sharing&#8221; &#8=
211; yet all are
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">perfectly legitimate i=
nterpretation of your suggested expression/notation.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; And ye=
t, these are actually more common interpretation of the usage of</span><o:p=
></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">an &#8220;or&#8221; op=
eration to computing folks (which many of us are), depending on their</span=
><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">specific background in=
 computing.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As I s=
aid before, I have no objection to the suggested notation you and</span><o:=
p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Lucy proposed &#8211; =
provided that the notation is explained.&nbsp; I am unclear as to what</spa=
n><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">value this usage &#821=
1; and included explanation may have &#8211; but this is largely a style</s=
pan><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">issue, and best left u=
p to the draft editors at this point.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; And, a=
s I also said, there may be others who would prefer not to have too</span><=
o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">much textual explanati=
on necessary in order to understand a figure.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Finall=
y, you must realize that there are a fairly large number of folks who</span=
><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">read-over mathematical=
 expressions as if they were written in a foreign language.</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">For this reason, even =
if it were a perfectly useful/correct mathematical expression,</span><o:p><=
/o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">a number of folks woul=
d <b><i>still</i></b> need a picture.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">--</span><o:p></o:p></=
p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Eric</span><o:p></o:p>=
</p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></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;"> Linda Du=
nbar [<a href=3D"mailto:linda.dunbar@huawei.com">mailto:linda.dunbar@huawei=
.com</a>]
<br>
<b>Sent:</b> Thursday, May 29, 2014 5:42 PM<br>
<b>To:</b> Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Q=
uinn (paulq)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
<b>Importance:</b> High</span><o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Eric, </span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">How about this shorter=
 one?</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Cou=
rier New&quot;">-&gt;{sf1}-&gt;{sf2|sf2&#8217;|sf2&#8217;&#8217;}-&gt;{sf3}=
-&gt;{sf4|sf4&#8217;|sf4&#8217;&#8217;}-&gt;{sf5}-&gt;</span><o:p></o:p></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Cou=
rier New&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">The intent is pretty s=
imple: If a service function on a chain has multiple instances, one of the =
service function&#8217;s instances is selected to treat packets belonging t=
o the service chain. &nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">This is a correct math=
ematics expression.
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">There is really no nee=
d draw all those boxes.
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Linda &nbsp;</span><o:=
p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></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;"> Eric Gra=
y [<a href=3D"mailto:eric.gray@ericsson.com">mailto:eric.gray@ericsson.com<=
/a>]
<br>
<b>Sent:</b> Thursday, May 29, 2014 4:23 PM<br>
<b>To:</b> Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Pau=
l Quinn (paulq)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05</span><o:p></o:p></p=
>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Linda,</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">By the way, your propo=
sal for Figure 5 would require a column width of at least 80</span><o:p></o=
:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">characters (more than =
you are supposed to have in an ID), and the situation would</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">be worse if it were ap=
plied to figure 6.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">For figure 5, you can =
improve the width slightly by fixing up a few of your arrows,</span><o:p></=
o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">and even more by wrapp=
ing the figure.&nbsp; Wrapping &nbsp;might detract from simplicity,</span><=
o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">however.</span><o:p></=
o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">--</span><o:p></o:p></=
p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Eric</span><o:p></o:p>=
</p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></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;"> Linda Du=
nbar [<a href=3D"mailto:linda.dunbar@huawei.com">mailto:linda.dunbar@huawei=
.com</a>]
<br>
<b>Sent:</b> Thursday, May 29, 2014 4:49 PM<br>
<b>To:</b> Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Q=
uinn (paulq)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
<b>Importance:</b> High</span><o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I like the Figures dra=
wn by Lucy.
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Actually why can&#8217=
;t Figure 5 be simplified as
</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp; enter --&g=
t;{sf1}--&gt;-{sf2|sf2&#8217;|sf2&#8217;&#8217;}-&gt;--{sf3}--&gt;-{sf4|sf4=
&#8217;|sf4&#8217;&#8217;}-&gt;--{sf5}--&gt; exit</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">??</span><o:p></o:p></=
p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Linda</span><o:p></o:p=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></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;"> sfc [<a =
href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Lucy yong<br>
<b>Sent:</b> Thursday, May 29, 2014 1:12 PM<br>
<b>To:</b> Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq=
)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> Re: [sfc] Figures in draft-quinn-sfc-arch-05</span><o:p></o=
:p></p>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">For readability on the=
se figures, propose:</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Cou=
rier New ;color:#1F497D&quot;,&quot;serif&quot;">Figure 5:</span><o:p></o:p=
></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; &#43;-sf2-&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-=
sf4-&#43;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; enter --&gt;sf1--&gt;-sf2-&gt;--sf3--&gt;-sf4-&gt;--sf5--&gt; exit<=
/span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; &#43;-sf2-&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-=
sf4-&#43;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">Figure 6:</span><o:p></o:p></=
p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-sf2-&#43;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-sf4-&#43;=
</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&n=
bsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp; enter --&g=
t;{sf1|sf1'}--&gt;-sf2-&gt;--{sf3|sf3'}--&gt;-sf4-&gt;--{sf5}--&gt; exit</s=
pan><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:8.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&n=
bsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Cou=
rier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; &#43;-sf2-&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-sf4-&#43;</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">lucy</span><o:p></o:p>=
</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;"> sfc [<a =
href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Eric Gray<br>
<b>Sent:</b> Thursday, May 29, 2014 12:54 PM<br>
<b>To:</b> Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> Re: [sfc] Figures in draft-quinn-sfc-arch-05</span><o:p></o=
:p></p>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">HaHa, funny man.&nbsp;=
 </span><span style=3D"font-family:Wingdings;color:#1F497D">J</span><o:p></=
o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;</span><o:p></o:=
p></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;"> Jakob He=
itz (jheitz) [<a href=3D"mailto:jheitz@cisco.com">mailto:jheitz@cisco.com</=
a>]
<br>
<b>Sent:</b> Thursday, May 29, 2014 1:43 PM<br>
<b>To:</b> Eric Gray; Joel Halpern; Paul Quinn (paulq)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
<b>Importance:</b> High</span><o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Luc=
ida Console ;color:#7030A0&quot;,&quot;serif&quot;">You could turn the whol=
e picture right by 90 degrees.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Luc=
ida Console ;color:#7030A0&quot;,&quot;serif&quot;">If you don&#8217;t like=
 top to bottom instead of left to right, make a note that it&#8217;s in lan=
dscape.</span><o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Luc=
ida Console ;color:#7030A0&quot;,&quot;serif&quot;">&nbsp;</span><o:p></o:p=
></p>
<div>
<p class=3D"MsoNormal"><span style=3D"color:#7030A0">--Jakob</span><o:p></o=
:p></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Luc=
ida Console ;color:#7030A0&quot;,&quot;serif&quot;">&nbsp;</span><o:p></o:p=
></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;"> sfc [<a =
href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Eric Gray<br>
<b>Sent:</b> Thursday, May 29, 2014 8:31 AM<br>
<b>To:</b> Joel Halpern; Paul Quinn (paulq)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> [sfc] Figures in draft-quinn-sfc-arch-05</span><o:p></o:p><=
/p>
</div>
</div>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">Paul/Joel,<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pretty sure that Figures 5 and 6 don=
&#8217;t actually fit the width expected for an
<o:p></o:p></p>
<p class=3D"MsoNormal">Internet Draft (Figure 5 is more than 80 characters =
wide and Figure 6 is wider still).<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Depending on how a reader tries to r=
ead the draft, this can turn complicated
<o:p></o:p></p>
<p class=3D"MsoNormal">illustrations into a _<i>real</i>_ fun time.&nbsp; <=
span style=3D"font-family:Wingdings">
J</span><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Also, I am unsure what the figures a=
re trying to convey with some of &#8220;dotted
<o:p></o:p></p>
<p class=3D"MsoNormal">lines&#8221; crossing the service functions.&nbsp; I=
f the intent is to show that a service function is
<o:p></o:p></p>
<p class=3D"MsoNormal">a virtual instance hosted by some network device, pe=
rhaps this will be better shown<o:p></o:p></p>
<p class=3D"MsoNormal">in a separate figure and this aspect of Figures 5 an=
d 6 can be eliminated?<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"text-indent:.5in">I would suggest replacing=
 Figure 5 with a figure along the lines of:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">source &nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;--=
---&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;-----&#43;</span><o:p></o:p>=
</p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;|&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;-=
-&gt;| sf2 &#43;--&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; &nbsp;&nbsp;&#43;--&gt;| sf4 &#43;--&#43;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp=
;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp; |</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;| &nbsp;&#43;------&#43;--&#43;&nbsp;&nbsp; &#43;-----&#43;&nbsp; &#43;--&=
gt;&#43;-----&#43;--&#43;&nbsp;&nbsp; &#43;-----&#43;&nbsp; &#43;-&gt;&#43;=
-----&#43;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;| &nbsp;| sf1&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;-----&#43;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; | sf3 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-----&#4=
3;&nbsp;&nbsp;&nbsp; &nbsp;| sf5 |</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&#43;-&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-----&gt;| sf2 &#43;-----&g=
t;|&nbsp;&nbsp;&nbsp;&nbsp; |-----&gt;| sf4 &#43;----&gt;|&nbsp;&nbsp;&nbsp=
;&nbsp; |-&#43;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&n=
bsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp; &nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; | |</span><o:p></o:p></=
p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&#43;------&#43;--&#43;&nbsp;&nbsp; &#43;-----&#43;&nbsp=
; &#43;--&gt;&#43;-----&#43;--&#43;&nbsp;&nbsp; &#43;-----&#43;&nbsp; &#43;=
-&gt;&#43;-----&#43; |</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;|&nbsp;&nbsp; &#43;-----&#43;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;|&nbsp;&nbsp; &#43;-----&#43;&nbsp; | &nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&#43;--&gt;| sf2 &#43;--&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; &nbsp;&nbsp;&#43;--&gt;| sf4 &#43;--&#43; &nbsp;&nbsp;&nbsp;&n=
bsp;&#43;----&#43;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nb=
sp;&nbsp;|</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;-----&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&#43;-----&#43;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;V</span><o:p></=
o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;destination</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;</spa=
n><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;Figure 5: Load Balancing</span><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">(67 characters?)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Similarly, I would suggest replacing=
 Figure 6 with a figure along the
<o:p></o:p></p>
<p class=3D"MsoNormal">lines of:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp; source</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#43;-----&#43;-&#43;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-----&#43;-&#43;</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> &#43;---&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; &#43;--&gt;| sf2 |-|&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;--&gt;| sf4 |-|&#43;</span><o:p=
></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#=
43;---|--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; &#43;------&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | ||</span>=
<o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp; &#43;------&#43;|---&#43;&nbsp;&nbsp; &#43;-----&#=
43; |&#43;--&gt;&#43;-----&#43;|---&#43;&nbsp;&nbsp; &#43;-----&#43; |&#43;=
--&gt;&#43;-----&#43;</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp; | sf1&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 &#43;-----&#43; &#43;---&gt;| sf3 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &=
#43;-----&#43; &#43;---&gt;| sf5 |</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> &#43;--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;|------&gt;| sf2=
 |&#43;----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; ||------&gt;| sf4 |&#43;----&gt;|&=
nbsp;&nbsp;&nbsp;&nbsp; |--&#43;</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || &#43;----&gt;|&=
nbsp;&nbsp;&nbsp;&nbsp; |-&#43;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 || &#43;----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-&#43;&nbsp;&nbsp;&nbsp; |&nbsp=
;&nbsp;&nbsp;&nbsp; | &nbsp;|</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp; &#43;------&#43;|-|-&#43;&nbsp;&nbsp; &#43;-----&#=
43; |&#43;--&gt;&#43;-----&#43;|-|-&#43;&nbsp;&nbsp; &#43;-----&#43; |&#43;=
--&gt;&#43;-----&#43; &nbsp;|</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
| |&nbsp;&nbsp; &#43;-----&#43; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; | | |&nbsp;&nbsp; &#43;-----&#43; ||&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;|</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp; &#43;------&#43;&#43; | &#43;--&gt;| sf2 |-|&#43;&=
nbsp;&nbsp; &#43;-----&#43;&#43; | &#43;--&gt;| sf4 |-|&#43;&nbsp;&nbsp; &#=
43;-----&#43; &nbsp;|</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> |&nbsp;&nbsp; | sf1' |&nbsp; | &#43;--&gt;|&nbsp;&nbsp;&nbsp;&nb=
sp; | &#43;---&gt;| sf3'|&nbsp; | &#43;--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | &#=
43;---&gt;| sf5'| &nbsp;|</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt"> &#43;--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;--&#43; |&nbsp;&=
nbsp; &#43;-----&#43;-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--&#43; |&nbsp;&nb=
sp; &#43;-----&#43;-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--&#43;</span><o:p><=
/o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&=
nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;|</span><o:p></o:p></pre=
>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp; &#43;------&#43;----&#43;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 &#43;-----&#43;----&#43;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#43;-----&#43; &nbsp;|</span><o:p=
></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|</span><o:p></o:p>=
</pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &#43;--------&#43;</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;V</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;destination</span><o:p></o:p=
></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;</span><o:p></o:p></pre>
<pre style=3D"page-break-before:always"><span lang=3D"EN" style=3D"font-siz=
e:10.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 6: Load Balancing =
and HA</span><o:p></o:p></pre>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">(72 characters?)<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In both cases, the figure has all th=
e same connection complexity (fixed up in a few<o:p></o:p></p>
<p class=3D"MsoNormal">places), but seems to be less busy.<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal">--<o:p></o:p></p>
<p class=3D"MsoNormal">Eric<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>sfc mailing list<o:p></o:p></pre>
<pre><a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><o:p></o:p></pre>
<pre><a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf=
.org/mailman/listinfo/sfc</a><o:p></o:p></pre>
</blockquote>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><br>
<br>
<o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Sevil Mehraghdam <o:p></o:p></pre>
<pre>University of Paderborn <o:p></o:p></pre>
<pre>Computer Networks group &#8211; <a href=3D"http://wwwcs.upb.de/cs/ag-k=
arl">http://wwwcs.upb.de/cs/ag-karl</a><o:p></o:p></pre>
<pre>Tel.: &#43;49 5251 / 601755<o:p></o:p></pre>
<pre>Room: O3.161<o:p></o:p></pre>
</div>
</body>
</html>

--_000_E8355113905631478EFF04F5AA706E9830A0F891wtlexchp2sandvi_--


From nobody Fri Jun  6 00:49:00 2014
Return-Path: <sevil.mehraghdam@uni-paderborn.de>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A771A03D8 for <sfc@ietfa.amsl.com>; Fri,  6 Jun 2014 00:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.5
X-Spam-Level: 
X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEANbPT7iZ57 for <sfc@ietfa.amsl.com>; Fri,  6 Jun 2014 00:48:49 -0700 (PDT)
Received: from mail.uni-paderborn.de (mail.uni-paderborn.de [131.234.142.9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0B31A0376 for <sfc@ietf.org>; Fri,  6 Jun 2014 00:48:48 -0700 (PDT)
Received: from eeyore.cs.uni-paderborn.de ([131.234.40.154]) by mail.uni-paderborn.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80 spheron) id 1WsotD-0001vP-HZ; Fri, 06 Jun 2014 09:48:39 +0200
Message-ID: <53917257.9000305@uni-paderborn.de>
Date: Fri, 06 Jun 2014 09:48:39 +0200
From: Sevil Mehraghdam <sevil.mehraghdam@uni-paderborn.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Dave Dolson <ddolson@sandvine.com>, "sfc@ietf.org" <sfc@ietf.org>
References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se> <5390188A.8030000@uni-paderborn.de> <E8355113905631478EFF04F5AA706E9830A0F891@wtl-exchp-2.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E9830A0F891@wtl-exchp-2.sandvine.com>
Content-Type: multipart/alternative; boundary="------------080903080400090402000806"
X-IMT-Spam-Score: 0.0 ()
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.6.73920
X-IMT-Authenticated-Sender: uid=sevilmeh,ou=People,o=upb,c=de
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/g4b64S0XuUElS-nk1bF2y-Ojymg
Subject: Re: [sfc] Specifying chains of network functions [Re: Figures in draft-quinn-sfc-arch-05]
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jun 2014 07:48:55 -0000

This is a multi-part message in MIME format.
--------------080903080400090402000806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

David,

you are right, currently our model does not make any assumptions about 
the implementation of the chains. What we provide is a context-free 
language for compact representation of different ways a set of functions 
can be chained together and letting the network operator decide about 
the most desirable chaining based on requests for using a set of chained 
functions, and eventually deploying these chains in the network.

We assume the operator maintains some information about the network 
functions that it "offers", e.g., how many licenses it has to implement 
different instances of a certain function, and computational 
requirements of the functions. We also need the chaining/deployment 
request to include some information like the desired order of traversing 
the requested functions.

The documents you pointed to are good examples of what we are trying to 
integrate in our work: how the chains can actually be implemented and 
what assumptions about the available information is realistic and so on. 
We are trying to keep track of the work in SFC working group and keep 
our work in line with the approaches that are likely to be standardized. 
Therefore, in the current state it doesn't make too much sense for me to 
say which approach does or does not work with our model.

Best regards,
Sevil



On 06/05/2014 03:49 PM, Dave Dolson wrote:
>
> Sevil,
>
> I only skimmed your work, so apologies if I've missed the point. I 
> believe you are providing algorithms for converting high-level service 
> requests into concrete service chains, without using any specific 
> implementation.
>
> It seems to me this work is favorably complementary to the IETF's SFC 
> work of determining the protocols of service chaining.
>
> (IETF determines implementation of services chains, and your work 
> decides which chains **should** be created.)
>
> My question to you is, what assumptions do you need to make about the 
> implementation of the chains that the SFC working group needs to 
> consider in forming requirements?
>
> For example, it looks like your algorithm requires some inputs about 
> maximum numbers of functions and chains supported by each VNF.
>
> Therefore we might see a need for a VNF to be able to expose that 
> information in the protocol.
>
> Looked at another way, which of the proposals (e.g., in 
> http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02) 
> work with your approach and which do not?
>
> Something else you could look at, is the orchestration template 
> proposal of 
> http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00 
> rigorous enough to be solved?
>
> David Dolson
>
> Senior Software Architect, Sandvine Inc.
>
> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Sevil Mehraghdam
> *Sent:* Thursday, June 05, 2014 3:13 AM
> *To:* sfc@ietf.org
> *Subject:* [sfc] Specifying chains of network functions [Re: Figures 
> in draft-quinn-sfc-arch-05]
>
> Hello,
>
> I am new to this mailing list, and regarding the discussion about 
> representing the chained functions, I would like to draw your 
> attention to our work:
>
> "Specifying and Placing Chains of Virtual Network Functions" 
> (http://arxiv.org/abs/1406.1058)
>
> We have defined a language for specifying the chaining among network 
> functions. We use it for describing an optimization problem for 
> placement of chained functions in a geographically distributed network 
> based on given deployment requests. The paper is currently under 
> review, and we are working on extending our model and language as new 
> requirements and details about virtual network functions and the 
> chains become available. Comments and suggestions are welcome!
>
> Best regards,
> Sevil Mehraghdam
>
>
> On 05/30/2014 05:03 PM, Eric Gray wrote:
>
>     Linda,
>
>     It may be a mathematically correct expression (depending on
>     interpretation
>
>     of the notation used), but networking is not necessarily (possibly
>     even usually) a
>
>     mathematical operation.
>
>     There is nothing "intuitively obvious" in this expression that
>     makes it clear
>
>     that "load sharing" is taking place between the sets of sf2 and
>     sf4 instances, or how
>
>     the "or" operation takes place.
>
>     One literal way to interpret this notation (as a mathematical
>     expression) is
>
>     that each the functions sf2, sf2' and sf2" are "visited"
>     sequentially and passed on
>
>     to sf3 ­*/as soon as it succeeds in any of the functions/*. With
>     this interpretation, since
>
>     the service function performed at each sf2 instance is presumed to
>     be identical,
>
>     what the expression means is that either the service function will
>     succeed at sf2
>
>     (and always skip sf2' and sf2"), or that it will fail at each sf2
>     instance.
>
>     An equally legitimate "parallel computing" (not exactly
>     mathematical, but
>
>     possibly viewed as more closely analogous to networking)
>     interpretation would
>
>     be that processing passes (on success at sf1) to */each/* of sf2,
>     sf2' and sf2" in parallel
>
>     and then proceeds to sf3 on success at any of the sf2 instances.
>
>     None of these interpretations corresponds to  "load sharing" --
>     yet all are
>
>     perfectly legitimate interpretation of your suggested
>     expression/notation.
>
>     And yet, these are actually more common interpretation of the usage of
>
>     an "or" operation to computing folks (which many of us are),
>     depending on their
>
>     specific background in computing.
>
>     As I said before, I have no objection to the suggested notation
>     you and
>
>     Lucy proposed -- provided that the notation is explained.  I am
>     unclear as to what
>
>     value this usage -- and included explanation may have -- but this
>     is largely a style
>
>     issue, and best left up to the draft editors at this point.
>
>     And, as I also said, there may be others who would prefer not to
>     have too
>
>     much textual explanation necessary in order to understand a figure.
>
>     Finally, you must realize that there are a fairly large number of
>     folks who
>
>     read-over mathematical expressions as if they were written in a
>     foreign language.
>
>     For this reason, even if it were a perfectly useful/correct
>     mathematical expression,
>
>     a number of folks would */still/* need a picture.
>
>     --
>
>     Eric
>
>     *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com]
>     *Sent:* Thursday, May 29, 2014 5:42 PM
>     *To:* Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern;
>     Paul Quinn (paulq)
>     *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>     *Subject:* RE: Figures in draft-quinn-sfc-arch-05
>     *Importance:* High
>
>     Eric,
>
>     How about this shorter one?
>
>     ->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}->
>
>     The intent is pretty simple: If a service function on a chain has
>     multiple instances, one of the service function's instances is
>     selected to treat packets belonging to the service chain.
>
>     This is a correct mathematics expression.
>
>     There is really no need draw all those boxes.
>
>     Linda
>
>     *From:*Eric Gray [mailto:eric.gray@ericsson.com]
>     *Sent:* Thursday, May 29, 2014 4:23 PM
>     *To:* Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern;
>     Paul Quinn (paulq)
>     *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>     *Subject:* RE: Figures in draft-quinn-sfc-arch-05
>
>     Linda,
>
>     By the way, your proposal for Figure 5 would require a column
>     width of at least 80
>
>     characters (more than you are supposed to have in an ID), and the
>     situation would
>
>     be worse if it were applied to figure 6.
>
>     For figure 5, you can improve the width slightly by fixing up a
>     few of your arrows,
>
>     and even more by wrapping the figure.  Wrapping  might detract
>     from simplicity,
>
>     however.
>
>     --
>
>     Eric
>
>     *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com]
>     *Sent:* Thursday, May 29, 2014 4:49 PM
>     *To:* Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern;
>     Paul Quinn (paulq)
>     *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>     *Subject:* RE: Figures in draft-quinn-sfc-arch-05
>     *Importance:* High
>
>     I like the Figures drawn by Lucy.
>
>     Actually why can't Figure 5 be simplified as
>
>         enter
>     -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5}-->
>     exit
>
>     ??
>
>     Linda
>
>     *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Lucy yong
>     *Sent:* Thursday, May 29, 2014 1:12 PM
>     *To:* Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn
>     (paulq)
>     *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>     *Subject:* Re: [sfc] Figures in draft-quinn-sfc-arch-05
>
>     For readability on these figures, propose:
>
>     Figure 5:
>
>                          +-sf2-+       +-sf4-+
>
>                          |     |       |     |
>
>            enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit
>
>                          |     |       |     |
>
>                          +-sf2-+       +-sf4-+
>
>     Figure 6:
>
>                              +-sf2-+ +-sf4-+
>
>                              |     | |     |
>
>         enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit
>
>                              |     | |     |
>
>                              +-sf2-+ +-sf4-+
>
>     lucy
>
>     *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric Gray
>     *Sent:* Thursday, May 29, 2014 12:54 PM
>     *To:* Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
>     *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>     *Subject:* Re: [sfc] Figures in draft-quinn-sfc-arch-05
>
>     HaHa, funny man. J
>
>     *From:*Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
>     *Sent:* Thursday, May 29, 2014 1:43 PM
>     *To:* Eric Gray; Joel Halpern; Paul Quinn (paulq)
>     *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>     *Subject:* RE: Figures in draft-quinn-sfc-arch-05
>     *Importance:* High
>
>     You could turn the whole picture right by 90 degrees.
>
>     If you don't like top to bottom instead of left to right, make a
>     note that it's in landscape.
>
>     --Jakob
>
>     *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Eric Gray
>     *Sent:* Thursday, May 29, 2014 8:31 AM
>     *To:* Joel Halpern; Paul Quinn (paulq)
>     *Cc:* sfc@ietf.org <mailto:sfc@ietf.org>
>     *Subject:* [sfc] Figures in draft-quinn-sfc-arch-05
>
>     Paul/Joel,
>
>                     Pretty sure that Figures 5 and 6 don't actually
>     fit the width expected for an
>
>     Internet Draft (Figure 5 is more than 80 characters wide and
>     Figure 6 is wider still).
>
>                     Depending on how a reader tries to read the draft,
>     this can turn complicated
>
>     illustrations into a _/real/_ fun time. J
>
>                     Also, I am unsure what the figures are trying to
>     convey with some of "dotted
>
>     lines" crossing the service functions. If the intent is to show
>     that a service function is
>
>     a virtual instance hosted by some network device, perhaps this
>     will be better shown
>
>     in a separate figure and this aspect of Figures 5 and 6 can be
>     eliminated?
>
>     I would suggest replacing Figure 5 with a figure along the lines of:
>
>     source             +-----+                   +-----+
>
>       |            +-->| sf2 +--+            +-->| sf4 +--+
>
>       |            |   |     | |            |   |     |  |
>
>       |  +------+--+   +-----+ +-->+-----+--+   +-----+  +->+-----+
>
>       |  | sf1  |      +-----+      | sf3 |      +-----+     | sf5 |
>
>       +->|      +----->| sf2 +----->|     |----->| sf4 +---->|     |-+
>
>          |      |      |     |      | |      |     |     |     | |
>
>          +------+--+   +-----+ +-->+-----+--+   +-----+  +->+-----+ |
>
>                    |   +-----+ |            |   +-----+  |          |
>
>                    +-->| sf2 +--+            +-->| sf4 +--+     +----+
>
>                        | |                   |     |        |
>
>                        +-----+       +-----+        V
>
>                                               destination
>
>                        Figure 5: Load Balancing
>
>     (67 characters?)
>
>                     Similarly, I would suggest replacing Figure 6 with
>     a figure along the
>
>     lines of:
>
>         source
>
>           |               +-----+-+                   +-----+-+
>
>       +---+           +-->| sf2 |-|+              +-->| sf4 |-|+
>
>       |           +---|-->|     | ||          +------>|     | ||
>
>       |   +------+|---+   +-----+ |+-->+-----+|---+   +-----+ |+-->+-----+
>
>       |   | sf1  ||       +-----+ +--->| sf3 ||       +-----+ +--->| sf5 |
>
>       +-->|      +|------>| sf2 |+---->|     ||------>| sf4 |+---->|     |--+
>
>       |   |      || +---->|     |-+    |     || +---->|     |-+    |     |  |
>
>       |   +------+|-|-+   +-----+ |+-->+-----+|-|-+   +-----+ |+-->+-----+  |
>
>       |           | | |   +-----+ ||          | | |   +-----+ ||            |
>
>       |   +------++ | +-->| sf2 |-|+   +-----++ | +-->| sf4 |-|+   +-----+  |
>
>       |   | sf1' |  | +-->|     | +--->| sf3'|  | +-->|     | +--->| sf5'|  |
>
>       +-->|      +--+ |   +-----+----->|     |--+ |   +-----+----->|     |--+
>
>           |      |    |                |     |    |                |     |  |
>
>           +------+----+                +-----+----+                +-----+  |
>
>                                                                             |
>
>                                                                    +--------+
>
>                                                                    |
>
>                                                                    V
>
>                                                               destination
>
>       
>
>                          Figure 6: Load Balancing and HA
>
>     (72 characters?)
>
>                     In both cases, the figure has all the same
>     connection complexity (fixed up in a few
>
>     places), but seems to be less busy.
>
>     --
>
>     Eric
>
>
>
>
>     _______________________________________________
>
>     sfc mailing list
>
>     sfc@ietf.org  <mailto:sfc@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/sfc
>
>
>
> -- 
> Sevil Mehraghdam
> University of Paderborn
> Computer Networks group --http://wwwcs.upb.de/cs/ag-karl
> Tel.: +49 5251 / 601755
> Room: O3.161

-- 
Sevil Mehraghdam
University of Paderborn
Computer Networks group -- http://wwwcs.upb.de/cs/ag-karl
Tel.: +49 5251 / 601755
Room: O3.161


--------------080903080400090402000806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    David,<br>
    <br>
    you are right, currently our model does not make any assumptions
    about the implementation of the chains. What we provide is a
    context-free language for compact representation of different ways a
    set of functions can be chained together and letting the network
    operator decide about the most desirable chaining based on requests
    for using a set of chained functions, and eventually deploying these
    chains in the network.<br>
    <br>
    We assume the operator maintains some information about the network
    functions that it "offers", e.g., how many licenses it has to
    implement different instances of a certain function, and
    computational requirements of the functions. We also need the
    chaining/deployment request to include some information like the
    desired order of traversing the requested functions.<br>
    <br>
    The documents you pointed to are good examples of what we are trying
    to integrate in our work: how the chains can actually be implemented
    and what assumptions about the available information is realistic
    and so on. We are trying to keep track of the work in SFC working
    group and keep our work in line with the approaches that are likely
    to be standardized. Therefore, in the current state it doesn't make
    too much sense for me to say which approach does or does not work
    with our model.<br>
    <br>
    Best regards, <br>
    Sevil<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 06/05/2014 03:49 PM, Dave Dolson
      wrote:<br>
    </div>
    <blockquote
cite="mid:E8355113905631478EFF04F5AA706E9830A0F891@wtl-exchp-2.sandvine.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="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:"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:"Lucida Console";
	panose-1:2 11 6 9 4 5 4 2 2 4;}
@font-face
	{font-family:"Courier New \;color\:\#1F497D";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Lucida Console \;color\:\#7030A0";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
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";
	color:black;}
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";
	color:black;}
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";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.grey
	{mso-style-name:grey;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Lucida Console";
	color:#7030A0;}
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="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">Sevil,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">I only skimmed
            your work, so apologies if I&#8217;ve missed the point. I believe
            you are providing algorithms for converting high-level
            service requests into concrete service chains, without using
            any specific implementation.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">It seems to me
            this work is favorably complementary to the IETF&#8217;s SFC work
            of determining the protocols of service chaining.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">(IETF
            determines implementation of services chains, and your work
            decides which chains *<b>should</b>* be created.)<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">My question to
            you is, what assumptions do you need to make about the
            implementation of the chains that the SFC working group
            needs to consider in forming requirements?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">For example, it
            looks like your algorithm requires some inputs about maximum
            numbers of functions and chains supported by each VNF.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Therefore we
            might see a need for a VNF to be able to expose that
            information in the protocol.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Looked at
            another way, which of the proposals (e.g., in
            <a moz-do-not-send="true"
              href="http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02">http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02</a>)
            work with your approach and which do not?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Something else
            you could look at, is the orchestration template proposal of
            <a moz-do-not-send="true"
              href="http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00">http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00</a>
            rigorous enough to be solved?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">David Dolson<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Senior Software
            Architect, Sandvine Inc.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">
                sfc [<a class="moz-txt-link-freetext" href="mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
                <b>On Behalf Of </b>Sevil Mehraghdam<br>
                <b>Sent:</b> Thursday, June 05, 2014 3:13 AM<br>
                <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                <b>Subject:</b> [sfc] Specifying chains of network
                functions [Re: Figures in draft-quinn-sfc-arch-05]<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal" style="margin-bottom:12.0pt">Hello,<br>
          <br>
          I am new to this mailing list, and regarding the discussion
          about representing the chained functions, I would like to draw
          your attention to our work:<br>
          <br>
          "Specifying and Placing Chains of Virtual Network Functions" (<a
            moz-do-not-send="true" href="http://arxiv.org/abs/1406.1058">http://arxiv.org/abs/1406.1058</a>)
          <br>
          <br>
          We have defined a language for specifying the chaining among
          network functions. We use it for describing an optimization
          problem for placement of chained functions in a geographically
          distributed network based on given deployment requests. The
          paper is currently under review, and we are working on
          extending our model and language as new requirements and
          details about virtual network functions and the chains become
          available. Comments and suggestions are welcome!<br>
          <br>
          Best regards,<br>
          Sevil Mehraghdam<br>
          <br>
          <br>
          <o:p></o:p></p>
        <div>
          <p class="MsoNormal">On 05/30/2014 05:03 PM, Eric Gray wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"><span style="color:#1F497D">Linda,</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              It may be a mathematically correct expression (depending
              on interpretation</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">of the
              notation used), but networking is not necessarily
              (possibly even usually) a
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">mathematical
              operation.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              There is nothing &#8220;intuitively obvious&#8221; in this expression
              that makes it clear</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">that &#8220;load
              sharing&#8221; is taking place between the sets of sf2 and sf4
              instances, or how</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">the &#8220;or&#8221;
              operation takes place.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              One literal way to interpret this notation (as a
              mathematical expression) is</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">that each the
              functions sf2, sf2&#8217; and sf2&#8221; are &#8220;visited&#8221; sequentially
              and passed on
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">to sf3 &shy;<b><i>as
                  soon as it succeeds in any of the functions</i></b>.&nbsp;
              With this interpretation, since
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">the service
              function performed at each sf2 instance is presumed to be
              identical,
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">what the
              expression means is that either the service function will
              succeed at sf2
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">(and always
              skip sf2&#8217; and sf2&#8221;), or that it will fail at each sf2
              instance.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              An equally legitimate &#8220;parallel computing&#8221; (not exactly
              mathematical, but</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">possibly
              viewed as more closely analogous to networking)
              interpretation would
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">be that
              processing passes (on success at sf1) to
              <b><i>each</i></b> of sf2, sf2&#8217; and sf2&#8221; in parallel</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">and then
              proceeds to sf3 on success at any of the sf2 instances.
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              None of these interpretations corresponds to &nbsp;&#8220;load
              sharing&#8221; &#8211; yet all are
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">perfectly
              legitimate interpretation of your suggested
              expression/notation.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              And yet, these are actually more common interpretation of
              the usage of</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">an &#8220;or&#8221;
              operation to computing folks (which many of us are),
              depending on their</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">specific
              background in computing.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              As I said before, I have no objection to the suggested
              notation you and</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Lucy proposed
              &#8211; provided that the notation is explained.&nbsp; I am unclear
              as to what</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">value this
              usage &#8211; and included explanation may have &#8211; but this is
              largely a style</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">issue, and
              best left up to the draft editors at this point.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              And, as I also said, there may be others who would prefer
              not to have too</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">much textual
              explanation necessary in order to understand a figure.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              Finally, you must realize that there are a fairly large
              number of folks who</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">read-over
              mathematical expressions as if they were written in a
              foreign language.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">For this
              reason, even if it were a perfectly useful/correct
              mathematical expression,</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">a number of
              folks would <b><i>still</i></b> need a picture.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">--</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Eric</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  Linda Dunbar [<a moz-do-not-send="true"
                    href="mailto:linda.dunbar@huawei.com">mailto:linda.dunbar@huawei.com</a>]
                  <br>
                  <b>Sent:</b> Thursday, May 29, 2014 5:42 PM<br>
                  <b>To:</b> Eric Gray; Lucy yong; Jakob Heitz (jheitz);
                  Joel Halpern; Paul Quinn (paulq)<br>
                  <b>Cc:</b> <a moz-do-not-send="true"
                    href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                  <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
                  <b>Importance:</b> High</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Eric, </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">How about
              this shorter one?</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">-&gt;{sf1}-&gt;{sf2|sf2&#8217;|sf2&#8217;&#8217;}-&gt;{sf3}-&gt;{sf4|sf4&#8217;|sf4&#8217;&#8217;}-&gt;{sf5}-&gt;</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">The intent is
              pretty simple: If a service function on a chain has
              multiple instances, one of the service function&#8217;s
              instances is selected to treat packets belonging to the
              service chain. &nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">This is a
              correct mathematics expression.
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">There is
              really no need draw all those boxes.
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Linda &nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  Eric Gray [<a moz-do-not-send="true"
                    href="mailto:eric.gray@ericsson.com">mailto:eric.gray@ericsson.com</a>]
                  <br>
                  <b>Sent:</b> Thursday, May 29, 2014 4:23 PM<br>
                  <b>To:</b> Linda Dunbar; Lucy yong; Jakob Heitz
                  (jheitz); Joel Halpern; Paul Quinn (paulq)<br>
                  <b>Cc:</b> <a moz-do-not-send="true"
                    href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                  <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Linda,</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">By the way,
              your proposal for Figure 5 would require a column width of
              at least 80</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">characters
              (more than you are supposed to have in an ID), and the
              situation would</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">be worse if
              it were applied to figure 6.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">For figure 5,
              you can improve the width slightly by fixing up a few of
              your arrows,</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">and even more
              by wrapping the figure.&nbsp; Wrapping &nbsp;might detract from
              simplicity,</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">however.</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">--</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Eric</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  Linda Dunbar [<a moz-do-not-send="true"
                    href="mailto:linda.dunbar@huawei.com">mailto:linda.dunbar@huawei.com</a>]
                  <br>
                  <b>Sent:</b> Thursday, May 29, 2014 4:49 PM<br>
                  <b>To:</b> Lucy yong; Eric Gray; Jakob Heitz (jheitz);
                  Joel Halpern; Paul Quinn (paulq)<br>
                  <b>Cc:</b> <a moz-do-not-send="true"
                    href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                  <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
                  <b>Importance:</b> High</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">I like the
              Figures drawn by Lucy.
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Actually why
              can&#8217;t Figure 5 be simplified as
            </span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp; enter
              --&gt;{sf1}--&gt;-{sf2|sf2&#8217;|sf2&#8217;&#8217;}-&gt;--{sf3}--&gt;-{sf4|sf4&#8217;|sf4&#8217;&#8217;}-&gt;--{sf5}--&gt;
              exit</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">??</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">Linda</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  sfc [<a moz-do-not-send="true"
                    href="mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
                  <b>On Behalf Of </b>Lucy yong<br>
                  <b>Sent:</b> Thursday, May 29, 2014 1:12 PM<br>
                  <b>To:</b> Eric Gray; Jakob Heitz (jheitz); Joel
                  Halpern; Paul Quinn (paulq)<br>
                  <b>Cc:</b> <a moz-do-not-send="true"
                    href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                  <b>Subject:</b> Re: [sfc] Figures in
                  draft-quinn-sfc-arch-05</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">For
              readability on these figures, propose:</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Courier New
              ;color:#1F497D&quot;,&quot;serif&quot;">Figure 5:</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf4-+</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enter
              --&gt;sf1--&gt;-sf2-&gt;--sf3--&gt;-sf4-&gt;--sf5--&gt;
              exit</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf4-+</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">Figure 6:</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              +-sf4-+</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              |&nbsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp; enter
              --&gt;{sf1|sf1'}--&gt;-sf2-&gt;--{sf3|sf3'}--&gt;-sf4-&gt;--{sf5}--&gt;
              exit</span><o:p></o:p></p>
          <p class="MsoNormal" style="text-autospace:none"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              |&nbsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Courier
              New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-sf2-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              +-sf4-+</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">lucy</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  sfc [<a moz-do-not-send="true"
                    href="mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
                  <b>On Behalf Of </b>Eric Gray<br>
                  <b>Sent:</b> Thursday, May 29, 2014 12:54 PM<br>
                  <b>To:</b> Jakob Heitz (jheitz); Joel Halpern; Paul
                  Quinn (paulq)<br>
                  <b>Cc:</b> <a moz-do-not-send="true"
                    href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                  <b>Subject:</b> Re: [sfc] Figures in
                  draft-quinn-sfc-arch-05</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">HaHa, funny
              man.&nbsp; </span><span
              style="font-family:Wingdings;color:#1F497D">J</span><o:p></o:p></p>
          <p class="MsoNormal"><span style="color:#1F497D">&nbsp;</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  Jakob Heitz (jheitz) [<a moz-do-not-send="true"
                    href="mailto:jheitz@cisco.com">mailto:jheitz@cisco.com</a>]
                  <br>
                  <b>Sent:</b> Thursday, May 29, 2014 1:43 PM<br>
                  <b>To:</b> Eric Gray; Joel Halpern; Paul Quinn (paulq)<br>
                  <b>Cc:</b> <a moz-do-not-send="true"
                    href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                  <b>Subject:</b> RE: Figures in draft-quinn-sfc-arch-05<br>
                  <b>Importance:</b> High</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Lucida Console
              ;color:#7030A0&quot;,&quot;serif&quot;">You could turn the
              whole picture right by 90 degrees.</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Lucida Console
              ;color:#7030A0&quot;,&quot;serif&quot;">If you don&#8217;t like
              top to bottom instead of left to right, make a note that
              it&#8217;s in landscape.</span><o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Lucida Console
              ;color:#7030A0&quot;,&quot;serif&quot;">&nbsp;</span><o:p></o:p></p>
          <div>
            <p class="MsoNormal"><span style="color:#7030A0">--Jakob</span><o:p></o:p></p>
          </div>
          <p class="MsoNormal"><span
              style="font-size:8.0pt;font-family:&quot;Lucida Console
              ;color:#7030A0&quot;,&quot;serif&quot;">&nbsp;</span><o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  sfc [<a moz-do-not-send="true"
                    href="mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
                  <b>On Behalf Of </b>Eric Gray<br>
                  <b>Sent:</b> Thursday, May 29, 2014 8:31 AM<br>
                  <b>To:</b> Joel Halpern; Paul Quinn (paulq)<br>
                  <b>Cc:</b> <a moz-do-not-send="true"
                    href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
                  <b>Subject:</b> [sfc] Figures in
                  draft-quinn-sfc-arch-05</span><o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">Paul/Joel,<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pretty sure that Figures
            5 and 6 don&#8217;t actually fit the width expected for an
            <o:p></o:p></p>
          <p class="MsoNormal">Internet Draft (Figure 5 is more than 80
            characters wide and Figure 6 is wider still).<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Depending on how a reader
            tries to read the draft, this can turn complicated
            <o:p></o:p></p>
          <p class="MsoNormal">illustrations into a _<i>real</i>_ fun
            time.&nbsp; <span style="font-family:Wingdings">
              J</span><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Also, I am unsure what
            the figures are trying to convey with some of &#8220;dotted
            <o:p></o:p></p>
          <p class="MsoNormal">lines&#8221; crossing the service functions.&nbsp;
            If the intent is to show that a service function is
            <o:p></o:p></p>
          <p class="MsoNormal">a virtual instance hosted by some network
            device, perhaps this will be better shown<o:p></o:p></p>
          <p class="MsoNormal">in a separate figure and this aspect of
            Figures 5 and 6 can be eliminated?<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal" style="text-indent:.5in">I would suggest
            replacing Figure 5 with a figure along the lines of:<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">source
              &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;|&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+--&gt;| sf2
              +--+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;+--&gt;| sf4 +--+</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
              |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;| &nbsp;+------+--+&nbsp;&nbsp; +-----+&nbsp;
              +--&gt;+-----+--+&nbsp;&nbsp; +-----+&nbsp; +-&gt;+-----+</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;| &nbsp;| sf1&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | sf3
              |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+&nbsp;&nbsp;&nbsp; &nbsp;| sf5 |</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;+-&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----&gt;| sf2
              +-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-----&gt;| sf4 +----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-+</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
              |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; &nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; | |</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+------+--+&nbsp;&nbsp; +-----+&nbsp;
              +--&gt;+-----+--+&nbsp;&nbsp; +-----+&nbsp; +-&gt;+-----+ |</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp; +-----+&nbsp;
              |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;|&nbsp;&nbsp; +-----+&nbsp; | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+--&gt;| sf2
              +--+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;+--&gt;| sf4 +--+ &nbsp;&nbsp;&nbsp;&nbsp;+----+</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;
              |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;|</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;V</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;destination</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;</span><o:p></o:p></p>
          <p class="MsoNormal" style="page-break-before:always"><span
              style="font-size:10.0pt;font-family:&quot;Courier
              New&quot;" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Figure 5: Load
              Balancing</span><o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">(67 characters?)<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Similarly, I would
            suggest replacing Figure 6 with a figure along the
            <o:p></o:p></p>
          <p class="MsoNormal">lines of:<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp; source</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+-----+-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+-+</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> +---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--&gt;| sf2 |-|+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--&gt;| sf4 |-|+</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---|--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | ||</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; +------+|---+&nbsp;&nbsp; +-----+ |+--&gt;+-----+|---+&nbsp;&nbsp; +-----+ |+--&gt;+-----+</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; | sf1&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+ +---&gt;| sf3 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+ +---&gt;| sf5 |</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +|------&gt;| sf2 |+----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; ||------&gt;| sf4 |+----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--+</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || +----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; || +----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |-+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; +------+|-|-+&nbsp;&nbsp; +-----+ |+--&gt;+-----+|-|-+&nbsp;&nbsp; +-----+ |+--&gt;+-----+ &nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | |&nbsp;&nbsp; +-----+ ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | |&nbsp;&nbsp; +-----+ ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; +------++ | +--&gt;| sf2 |-|+&nbsp;&nbsp; +-----++ | +--&gt;| sf4 |-|+&nbsp;&nbsp; +-----+ &nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> |&nbsp;&nbsp; | sf1' |&nbsp; | +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | +---&gt;| sf3'|&nbsp; | +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp; | +---&gt;| sf5'| &nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN"> +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--+ |&nbsp;&nbsp; +-----+-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--+ |&nbsp;&nbsp; +-----+-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp; |--+</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; | &nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp; +------+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----+ &nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;V</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;destination</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;</span><o:p></o:p></pre>
          <pre style="page-break-before:always"><span style="font-size:10.0pt" lang="EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 6: Load Balancing and HA</span><o:p></o:p></pre>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">(72 characters?)<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In both cases, the figure
            has all the same connection complexity (fixed up in a few<o:p></o:p></p>
          <p class="MsoNormal">places), but seems to be less busy.<o:p></o:p></p>
          <p class="MsoNormal">&nbsp;<o:p></o:p></p>
          <p class="MsoNormal">--<o:p></o:p></p>
          <p class="MsoNormal">Eric<o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:12.0pt;font-family:&quot;Times New
              Roman&quot;,&quot;serif&quot;"><br>
              <br>
              <br>
              <o:p></o:p></span></p>
          <pre>_______________________________________________<o:p></o:p></pre>
          <pre>sfc mailing list<o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="mailto:sfc@ietf.org">sfc@ietf.org</a><o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a><o:p></o:p></pre>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:&quot;Times New
            Roman&quot;,&quot;serif&quot;"><br>
            <br>
            <o:p></o:p></span></p>
        <pre>-- <o:p></o:p></pre>
        <pre>Sevil Mehraghdam <o:p></o:p></pre>
        <pre>University of Paderborn <o:p></o:p></pre>
        <pre>Computer Networks group &#8211; <a moz-do-not-send="true" href="http://wwwcs.upb.de/cs/ag-karl">http://wwwcs.upb.de/cs/ag-karl</a><o:p></o:p></pre>
        <pre>Tel.: +49 5251 / 601755<o:p></o:p></pre>
        <pre>Room: O3.161<o:p></o:p></pre>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Sevil Mehraghdam 
University of Paderborn 
Computer Networks group &#8211; <a class="moz-txt-link-freetext" href="http://wwwcs.upb.de/cs/ag-karl">http://wwwcs.upb.de/cs/ag-karl</a>
Tel.: +49 5251 / 601755
Room: O3.161</pre>
  </body>
</html>

--------------080903080400090402000806--


From nobody Fri Jun  6 19:28:40 2014
Return-Path: <repenno@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A51A02F3 for <sfc@ietfa.amsl.com>; Fri,  6 Jun 2014 19:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wnDiDs1sU10 for <sfc@ietfa.amsl.com>; Fri,  6 Jun 2014 19:28:33 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB181A02F1 for <sfc@ietf.org>; Fri,  6 Jun 2014 19:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23680; q=dns/txt; s=iport; t=1402108106; x=1403317706; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=5rfb+LMQ30hS/lgR6FAZkWy8YlI6g+fjR5RprJWu0aY=; b=P1dJUgSHoWLq0gmuTHaX1hGU1dK5yzKMVf1nXyHMnjjIjoud4GQztAas WZdSbwBbeA18uIzJ2xFrjEmSvZUHciIs8yTA8VvGmtwGIGBveigwN9CQL tb8669dnnhyVQrP9eWKMEBSVhECxlMSEQM2vPCjwE/Tw+G2HAJtHpa3Ok A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgILAER4klOtJA2M/2dsb2JhbABQCYJGR1JSB7p/gVEBhzsBgQQWdYQDAQEBBAEBAWsGBRIBCBEDAQIoLgsUCQgCBA4FCYg5CAXNPReJPoRQSg0EB4RBBJYThAqBQol3iAuDPGyBQw
X-IronPort-AV: E=Sophos; i="4.98,992,1392163200"; d="scan'208,217"; a="51025700"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 07 Jun 2014 02:28:25 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s572SPdE001865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Jun 2014 02:28:25 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 21:28:26 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: Jan Lindblad <janl@tail-f.com>
Thread-Topic: [sfc] Yang Data Model for Service Function Chaining (02)
Thread-Index: AQHPe9y+1dcKReUMXUuPJ+epenpTWJtfciEAgAVk8oA=
Date: Sat, 7 Jun 2014 02:28:25 +0000
Message-ID: <CFB79726.C0D1%repenno@cisco.com>
In-Reply-To: <026B7D91-E5E2-4A5A-90E2-0D16D725811C@tail-f.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.21.115.13]
Content-Type: multipart/alternative; boundary="_000_CFB79726C0D1repennociscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FOR_lKxzCcfwr_DMyBGPSOk9-kM
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jun 2014 02:28:37 -0000

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

Hello Jan,

Thanks for the review, I will submit a new version shortly.

Inline with [RP]

From: Jan Lindblad <janl@tail-f.com<mailto:janl@tail-f.com>>
Date: Tuesday, June 3, 2014 at 2:05 AM
To: Cisco Employee <repenno@cisco.com<mailto:repenno@cisco.com>>
Cc: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)

Reinaldo,

Good work! I made a quick review of your proposed SFC YANG module. I have b=
een monitoring this list for a couple of weeks only, so please bear with an=
y misconceptions on my part. I'm a YANG Doctor, however, so I was hoping I =
could contribute with a few YANG-level suggestions or options for you.



module vxlan-gpe:

The namespace declaration in each of the modules starts with urn:cisco:... =
Namespaces on this form are supposed to be registered with IANA. http://www=
.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

I suggest either changing this to an IETF reserved name, or move it to a pr=
oper cisco-namespace, e.g.:
namespace "http://cisco.com/ns/ietf/wg/sfc";
or, perhaps better, an IETF registered name:
namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC num=
ber and remove this note.
This applies to all modules in the submission, but I will not keep repeatin=
g this comment for the others.

[RP] changed throughput to urn:TBD:...

There are a number of reserved bits and fields in the module. I think it ma=
y be wise to think this through a bit more before publishing. According to =
the YANG RFC 6020 section 10, IETF does not allow itself to ever remove a p=
ublished configurable item from a module, so those reserved names will have=
 to stick forever. To make it worse, the bit positions must be unique, so t=
he bit names will have to remain r1, r2, r3, ... indefinitely, even if a pr=
oper meaning and name is invented at a later stage. I suggest simply not li=
sting them in the specification in this version, only adding them when they=
 have a well defined meaning.

[RP] okay.

The leaf-list vni will not behave as intended. A leaf list will automatical=
ly sort itself into the natural (ascending) order (unless ordered-by user i=
s specified), and can never contain repeated values (such as [1,1,1]). I'd =
suggest you use a 24-bit integer instead. Or possibly a list (not leaf list=
) with a position key. Or three separate 8-bit leafs (vni-low, vni-med, vni=
-high).

[RP] Used 3 separate 8-bit leafs for now.



module service-function:

Revision dates are YYYY-MM-DD

[RP] Done

Identity+identityref seems like a good way to handle this extensible set. I=
t does require YANG modeling to define new types however, so if operators s=
hould be able to invent new types "on the fly", another option would be to =
have one more config table with the operator specified types, and then use =
a leafref to point to one of them.

Mandatory true on a key element is not necessary, so this can be removed fo=
r improved readability and brevity. This also applies to several other list=
s, but I will not keep repeating this comment.

[RP] Done

There is no mandatory true on the type and ip-host-address leafs. What woul=
d it mean if a sfc entry exists and has no type nor ip-host-address? Should=
 one or both be mandatory, or have a default? Note that if we specify a def=
ault, that default value can never ever be changed to something else accord=
ing to the YANG RFC 6020, sec 10.

[RP] This can be modified later.



module service-function-chain:

As noted by Ron Parker, this allows only a single instance of each service =
type in each chain. With the current model, an operator has no way of defin=
ing additional service types to say clone a dpi service into an dpi-early a=
nd dpi-late. If this was modeled as a list with a string name and a service=
-function-type leaf instead, the same function could appear multiple times =
in a chain.

[RP] I=92ve made this change but in order to avoid confusion I=92m relying =
on the description to clear things up. Meaning, in the best case where you =
have a chain where there is only one of each type the leaf =93name"  is red=
undant and in the worst case it might cause confusion, for example,  if you=
 can have a name =93dpi-early=94 and a type =93firewall=94. I guess we need=
ed a list in Yang where indexes are assigned and you can have repeated valu=
es, otherwise it feels I created a leaf name for no purpose.


   list service-function {
      key "name";
      leaf name {
        type string;
        description
            "The name of the service function. This could be the
            same as the type or in the case where multiple service
            functions or the same type are used in chain, something
            like ingress-firewall and egress-firewall";
      }
      leaf type {
        type sfc-sf:service-function-type;
        description
            "The type of the service function.";
      }
      ordered-by user;
      description
        "A list of service functions that compose the service chain";
    }

module service-node:

The leafs type, transport, ip-host-address and failmode are not mandatory a=
nd have no defaults. Will it be entirely clear to operators what the system=
 will do if some or all of them have no values? This is not obvious to me (=
but that could be only me).

[RP] I think the idea here is that at the time of creation the operator cou=
ld not (or might not) want to specify all these things.

As noted by Ron Parker, type can hold only a single value. Could a service =
node be of multiple types simultaneously?

[RP] As I said in my reply to Ron this might be something to think about. I=
t is a trade-off of complexity vs. flexibility.

module service-function-path:

The service-function-path is modeled as a container. So there can be only o=
ne of these in the whole system. I might be missing something, but I think =
you want a list here, in some way.

[RP] Good catch.  Changed.

module service-function-forwarder:

Once again, the leafs ip and port are not mandatory. Is that ok? Should eac=
h service function have a single ip/port pair?



In general, I think these modules are very small. Typically I recommend to =
make separate modules for things that need to be versioned separately, i.e.=
 corresponding to software components. To me, these modules feel very close=
ly related, so even a single module for all of this would be fine. Factorin=
g things out into separate modules may make it harder to get a full grasp o=
f what SFC is about, repeating things in module descriptions, making creati=
on of new revisions harder.

[RP] They were even smaller and based on opendaylight testing and feedback =
from folks like you they have been growing in order to accommodate the use-=
cases.  Therefore we should and decide later to consolidate or keep them ap=
art.

/Jan Lindblad


On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com<mailt=
o:repenno@cisco.com>> wrote:

A new version of I-D, draft-penno-sfc-yang-02.txt
has been successfully submitted by Reinaldo Penno and posted to the
IETF repository.

Name:           draft-penno-sfc-yang
Revision:       02
Title:          Yang Data Model for Service Function Chaining
Document date:  2014-05-29
Group:          Individual Submission
Pages:          20
URL:            http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02=
.txt
Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
Htmlized:       http://tools.ietf.org/html/draft-penno-sfc-yang-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02
_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc



--_000_CFB79726C0D1repennociscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <6E5D117773D74A4BA4238F0A59752C42@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>Hello Jan,</div>
<div><br>
</div>
<div>Thanks for the review, I will submit a new version shortly.&nbsp;</div=
>
<div><br>
</div>
<div>Inline with [RP]</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>Jan Lindblad &lt;<a href=3D"m=
ailto:janl@tail-f.com">janl@tail-f.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Tuesday, June 3, 2014 at 2:05=
 AM<br>
<span style=3D"font-weight:bold">To: </span>Cisco Employee &lt;<a href=3D"m=
ailto:repenno@cisco.com">repenno@cisco.com</a>&gt;<br>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:sfc@iet=
f.org">sfc@ietf.org</a>&quot; &lt;<a href=3D"mailto:sfc@ietf.org">sfc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [sfc] Yang Data Model =
for Service Function Chaining (02)<br>
</div>
<div><br>
</div>
<div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space;">
<div>Reinaldo,</div>
<div><br>
</div>
<div>Good work! I made a quick review of your proposed SFC YANG module. I h=
ave been monitoring this list for a couple of weeks only, so please bear wi=
th any misconceptions on my part. I'm a YANG Doctor, however, so I was hopi=
ng I could contribute with a few
 YANG-level suggestions or options for you.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>module vxlan-gpe:</div>
<div><br>
</div>
<div>The namespace declaration in each of the modules starts with urn:cisco=
:... Namespaces on this form are supposed to be registered with IANA.&nbsp;=
<a href=3D"http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xh=
tml">http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml</a=
></div>
<div><br>
</div>
<div>I suggest either changing this to an IETF reserved name, or move it to=
 a proper cisco-namespace, e.g.:</div>
<div>namespace &quot;<a href=3D"http://cisco.com/ns/ietf/wg/sfc">http://cis=
co.com/ns/ietf/wg/sfc</a>&quot;;</div>
<div>or, perhaps better, an IETF registered name:</div>
<div>namespace &quot;urn:ietf:rfc:XXXX&quot;; // RFC Ed.: Replace XXXX with=
 actual RFC number and remove this note.</div>
<div>This applies to all modules in the submission, but I will not keep rep=
eating this comment for the others.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] changed throughput to urn:TBD:...</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;">
<div><br>
</div>
<div>There are a number of reserved bits and fields in the module. I think =
it may be wise to think this through a bit more before publishing. Accordin=
g to the YANG RFC 6020 section 10, IETF does not allow itself to ever remov=
e a published configurable item
 from a module, so those reserved names will have to stick forever. To make=
 it worse, the bit positions must be unique, so the bit names will have to =
remain r1, r2, r3, ... indefinitely, even if a proper meaning and name is i=
nvented at a later stage. I suggest
 simply not listing them in the specification in this version, only adding =
them when they have a well defined meaning.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] okay.</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;">
<div><br>
</div>
<div>The leaf-list vni will not behave as intended. A leaf list will automa=
tically sort itself into the natural (ascending) order (unless ordered-by u=
ser is specified), and can never contain repeated values (such as [1,1,1]).=
 I'd suggest you use a 24-bit integer
 instead. Or possibly a list (not leaf list) with a position key. Or three =
separate 8-bit leafs (vni-low, vni-med, vni-high).</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] Used 3 separate 8-bit leafs for now.</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;">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>module service-function:</div>
<div><br>
</div>
<div>Revision dates are YYYY-MM-DD</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] Done</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;">
<div><br>
</div>
<div>Identity&#43;identityref seems like a good way to handle this extensib=
le set. It does require YANG modeling to define new types however, so if op=
erators should be able to invent new types &quot;on the fly&quot;, another =
option would be to have one more config table
 with the operator specified types, and then use a leafref to point to one =
of them.</div>
<div><br>
</div>
<div>Mandatory true on a key element is not necessary, so this can be remov=
ed for improved readability and brevity. This also applies to several other=
 lists, but I will not keep repeating this comment.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] Done</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;">
<div><br>
</div>
<div>There is no mandatory true on the type and ip-host-address leafs. What=
 would it mean if a sfc entry exists and has no type nor ip-host-address? S=
hould one or both be mandatory, or have a default? Note that if we specify =
a default, that default value can
 never ever be changed to something else according to the YANG RFC 6020, se=
c 10.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] This can be modified later.</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;">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>module service-function-chain:</div>
<div><br>
</div>
<div>As noted by Ron Parker, this allows only a single instance of each ser=
vice type in each chain. With the current model, an operator has no way of =
defining additional service types to say clone a dpi service into an dpi-ea=
rly and dpi-late. If this was modeled
 as a list with a string name and a service-function-type leaf instead, the=
 same function could appear multiple times in a chain.</div>
<div><br>
</div>
<div>[RP] I=92ve made this change but in order to avoid confusion I=92m rel=
ying on the description to clear things up. Meaning, in the best case where=
 you have a chain where there is only one of each type the leaf =93name&quo=
t; &nbsp;is redundant and in the worst case it might
 cause confusion, for example, &nbsp;if you can have a name =93dpi-early=94=
 and a type =93firewall=94. I guess we needed a list in Yang where indexes =
are assigned and you can have repeated values, otherwise it feels I created=
 a leaf name for no purpose. &nbsp;</div>
</div>
</div>
</span>
<div><br>
</div>
<div><br>
</div>
<div>
<div>&nbsp; &nbsp;list service-function {</div>
<div>&nbsp; &nbsp; &nbsp; key &quot;name&quot;;</div>
<div>&nbsp; &nbsp; &nbsp; leaf name {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; type string;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; description</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;The name of the servic=
e function. This could be the</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; same as the type or in the c=
ase where multiple service</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; functions or the same type a=
re used in chain, something</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like ingress-firewall and eg=
ress-firewall&quot;;</div>
<div>&nbsp; &nbsp; &nbsp; }</div>
<div>&nbsp; &nbsp; &nbsp; leaf type {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; type sfc-sf:service-function-type;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; description</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;The type of the servic=
e function.&quot;;</div>
<div>&nbsp; &nbsp; &nbsp; }</div>
<div>&nbsp; &nbsp; &nbsp; ordered-by user;</div>
<div>&nbsp; &nbsp; &nbsp; description</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &quot;A list of service functions that com=
pose the service chain&quot;;</div>
<div>&nbsp; &nbsp; }</div>
</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;">
<div><br>
</div>
<div>module service-node:</div>
<div><br>
</div>
<div>The leafs type, transport, ip-host-address and failmode are not mandat=
ory and have no defaults. Will it be entirely clear to operators what the s=
ystem will do if some or all of them have no values? This is not obvious to=
 me (but that could be only me).</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] I think the idea here is that at the time of creation the operato=
r could not (or might not) want to specify all these things.&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;">
<div><br>
</div>
<div>As noted by Ron Parker, type can hold only a single value. Could a ser=
vice node be of multiple types simultaneously?</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] As I said in my reply to Ron this might be something to think abo=
ut. It is a trade-off of complexity vs. flexibility.&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;">
<div><br>
</div>
<div>module service-function-path:</div>
<div><br>
</div>
<div>The service-function-path is modeled as a container. So there can be o=
nly one of these in the whole system. I might be missing something, but I t=
hink you want a list here, in some way.</div>
<div><br>
</div>
<div>[RP] Good catch. &nbsp;Changed.</div>
<div><br>
</div>
<div>module service-function-forwarder:</div>
<div><br>
</div>
<div>Once again, the leafs ip and port are not mandatory. Is that ok? Shoul=
d each service function have a single ip/port pair?</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>In general, I think these modules are very small. Typically I recommen=
d to make separate modules for things that need to be versioned separately,=
 i.e. corresponding to software components. To me, these modules feel very =
closely related, so even a single
 module for all of this would be fine. Factoring things out into separate m=
odules may make it harder to get a full grasp of what SFC is about, repeati=
ng things in module descriptions, making creation of new revisions harder.<=
/div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] They were even smaller and based on opendaylight testing and feed=
back from folks like you they have been growing in order to accommodate the=
 use-cases. &nbsp;Therefore we should and decide later to consolidate or ke=
ep them apart.&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;">
<div><br>
</div>
<div>/Jan Lindblad</div>
<div apple-content-edited=3D"true"><span class=3D"Apple-style-span" style=
=3D"border-collapse: separate; border-spacing: 0px;">
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; ">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; border=
-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; -webkit-text-decorations-in-effect: none=
; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; o=
rphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line=
-break: after-white-space; ">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; border=
-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; -webkit-text-decorations-in-effect: none=
; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; o=
rphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">
<div><br>
</div>
</span></div>
</span></div>
</span></div>
<br>
<div>
<div>On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) &lt;<a href=3D"mail=
to:repenno@cisco.com">repenno@cisco.com</a>&gt; wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">A new version of I-D, draft-penno-sfc-yang-02.txt=
<br>
has been successfully submitted by Reinaldo Penno and posted to the<br>
IETF repository.<br>
<br>
Name: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;draft-pen=
no-sfc-yang<br>
Revision: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;02<br>
Title: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Yang Data Mode=
l for Service Function Chaining<br>
Document date: &nbsp;2014-05-29<br>
Group: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Individual Sub=
mission<br>
Pages: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;20<br>
URL: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a h=
ref=3D"http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt">htt=
p://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt</a><br>
Status: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"https://=
datatracker.ietf.org/doc/draft-penno-sfc-yang/">https://datatracker.ietf.or=
g/doc/draft-penno-sfc-yang/</a><br>
Htmlized: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"http://tools.ietf.=
org/html/draft-penno-sfc-yang-02">http://tools.ietf.org/html/draft-penno-sf=
c-yang-02</a><br>
Diff: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=
=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02">http://www.=
ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02</a><br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf.org/=
mailman/listinfo/sfc</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</span>
</body>
</html>

--_000_CFB79726C0D1repennociscocom_--


From nobody Sun Jun  8 12:46:48 2014
Return-Path: <repenno@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A11A037B for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 12:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xTiC9HESwLM for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 12:46:44 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEFC1A036E for <sfc@ietf.org>; Sun,  8 Jun 2014 12:46:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26522; q=dns/txt; s=iport; t=1402256804; x=1403466404; h=from:to:subject:date:message-id:mime-version; bh=Yu7LO6xAupHXXWfl2yTNkfx3Uf2na9CFM9cfNvYIJDs=; b=P0YZD5Q59x438FaZCZ3QIMe/dWtIX9i89cmHQm4qrwEXjHrxvIqOAPCj 3RXCHzxjfJzIszPl9hedglDkXHP4wrLB5XbBM0+IQd8TMMAjpGokzc+bZ B8s8+/BtYKuLYkFsCeSy01lP0/TnOkzFsS24/wTItN8V95PgwvVP2PREF o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsbAIq8lFOtJV2S/2dsb2JhbABOCYJGR1JSBAOqfwEBAQEBAQYCkAGBUQGHOwGBAxZ1hAMBAQEEAQEBawYXARkDAQEBCxYHLgsUCQoEEwgBiDkIBZ0zrh0XhV2DY4RRKiANCoMsgRYElheFTIl3iAyDPGyBQw
X-IronPort-AV: E=Sophos;i="4.98,999,1392163200";  d="scan'208,217";a="331520254"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jun 2014 19:46:42 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s58JkgVA011309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Sun, 8 Jun 2014 19:46:42 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 8 Jun 2014 14:46:42 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Yang Data Model for Service Function Chaining (03)
Thread-Index: AQHPg1JeYWsdvBdCA0uU83jgVhKRwA==
Date: Sun, 8 Jun 2014 19:46:41 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040BE2C8E8@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.95.61]
Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040BE2C8E8xmbrcdx04ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uOGC5vqfABzAsaLpue5ESLVHPSg
Subject: [sfc] Yang Data Model for Service Function Chaining (03)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Jun 2014 19:46:47 -0000

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

New version of SFC Yang data models.

thanks to Jan Lindblad, Ron Parker and other reviewers.


A new version of I-D, draft-penno-sfc-yang-03.txt
has been successfully submitted by Reinaldo Penno and posted to the
IETF repository.

Name:           draft-penno-sfc-yang
Revision:       03
Title:          Yang Data Model for Service Function Chaining
Document date:  2014-06-06
Group:          Individual Submission
Pages:          21
URL:            http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03=
.txt
Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
Htmlized:       http://tools.ietf.org/html/draft-penno-sfc-yang-03
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-03

Abstract:
   This document defines a YANG data model that can be used to configure
   and manage Service Function Chains.
________________________________
From: sfc [sfc-bounces@ietf.org] on behalf of Reinaldo Penno (repenno)
Sent: Friday, June 06, 2014 7:28 PM
To: Jan Lindblad
Cc: sfc@ietf.org
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)

Hello Jan,

Thanks for the review, I will submit a new version shortly.

Inline with [RP]

From: Jan Lindblad <janl@tail-f.com<mailto:janl@tail-f.com>>
Date: Tuesday, June 3, 2014 at 2:05 AM
To: Cisco Employee <repenno@cisco.com<mailto:repenno@cisco.com>>
Cc: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)

Reinaldo,

Good work! I made a quick review of your proposed SFC YANG module. I have b=
een monitoring this list for a couple of weeks only, so please bear with an=
y misconceptions on my part. I'm a YANG Doctor, however, so I was hoping I =
could contribute with a few YANG-level suggestions or options for you.



module vxlan-gpe:

The namespace declaration in each of the modules starts with urn:cisco:... =
Namespaces on this form are supposed to be registered with IANA. http://www=
.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

I suggest either changing this to an IETF reserved name, or move it to a pr=
oper cisco-namespace, e.g.:
namespace "http://cisco.com/ns/ietf/wg/sfc";
or, perhaps better, an IETF registered name:
namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC num=
ber and remove this note.
This applies to all modules in the submission, but I will not keep repeatin=
g this comment for the others.

[RP] changed throughput to urn:TBD:...

There are a number of reserved bits and fields in the module. I think it ma=
y be wise to think this through a bit more before publishing. According to =
the YANG RFC 6020 section 10, IETF does not allow itself to ever remove a p=
ublished configurable item from a module, so those reserved names will have=
 to stick forever. To make it worse, the bit positions must be unique, so t=
he bit names will have to remain r1, r2, r3, ... indefinitely, even if a pr=
oper meaning and name is invented at a later stage. I suggest simply not li=
sting them in the specification in this version, only adding them when they=
 have a well defined meaning.

[RP] okay.

The leaf-list vni will not behave as intended. A leaf list will automatical=
ly sort itself into the natural (ascending) order (unless ordered-by user i=
s specified), and can never contain repeated values (such as [1,1,1]). I'd =
suggest you use a 24-bit integer instead. Or possibly a list (not leaf list=
) with a position key. Or three separate 8-bit leafs (vni-low, vni-med, vni=
-high).

[RP] Used 3 separate 8-bit leafs for now.



module service-function:

Revision dates are YYYY-MM-DD

[RP] Done

Identity+identityref seems like a good way to handle this extensible set. I=
t does require YANG modeling to define new types however, so if operators s=
hould be able to invent new types "on the fly", another option would be to =
have one more config table with the operator specified types, and then use =
a leafref to point to one of them.

Mandatory true on a key element is not necessary, so this can be removed fo=
r improved readability and brevity. This also applies to several other list=
s, but I will not keep repeating this comment.

[RP] Done

There is no mandatory true on the type and ip-host-address leafs. What woul=
d it mean if a sfc entry exists and has no type nor ip-host-address? Should=
 one or both be mandatory, or have a default? Note that if we specify a def=
ault, that default value can never ever be changed to something else accord=
ing to the YANG RFC 6020, sec 10.

[RP] This can be modified later.



module service-function-chain:

As noted by Ron Parker, this allows only a single instance of each service =
type in each chain. With the current model, an operator has no way of defin=
ing additional service types to say clone a dpi service into an dpi-early a=
nd dpi-late. If this was modeled as a list with a string name and a service=
-function-type leaf instead, the same function could appear multiple times =
in a chain.

[RP] I=92ve made this change but in order to avoid confusion I=92m relying =
on the description to clear things up. Meaning, in the best case where you =
have a chain where there is only one of each type the leaf =93name"  is red=
undant and in the worst case it might cause confusion, for example,  if you=
 can have a name =93dpi-early=94 and a type =93firewall=94. I guess we need=
ed a list in Yang where indexes are assigned and you can have repeated valu=
es, otherwise it feels I created a leaf name for no purpose.


   list service-function {
      key "name";
      leaf name {
        type string;
        description
            "The name of the service function. This could be the
            same as the type or in the case where multiple service
            functions or the same type are used in chain, something
            like ingress-firewall and egress-firewall";
      }
      leaf type {
        type sfc-sf:service-function-type;
        description
            "The type of the service function.";
      }
      ordered-by user;
      description
        "A list of service functions that compose the service chain";
    }

module service-node:

The leafs type, transport, ip-host-address and failmode are not mandatory a=
nd have no defaults. Will it be entirely clear to operators what the system=
 will do if some or all of them have no values? This is not obvious to me (=
but that could be only me).

[RP] I think the idea here is that at the time of creation the operator cou=
ld not (or might not) want to specify all these things.

As noted by Ron Parker, type can hold only a single value. Could a service =
node be of multiple types simultaneously?

[RP] As I said in my reply to Ron this might be something to think about. I=
t is a trade-off of complexity vs. flexibility.

module service-function-path:

The service-function-path is modeled as a container. So there can be only o=
ne of these in the whole system. I might be missing something, but I think =
you want a list here, in some way.

[RP] Good catch.  Changed.

module service-function-forwarder:

Once again, the leafs ip and port are not mandatory. Is that ok? Should eac=
h service function have a single ip/port pair?



In general, I think these modules are very small. Typically I recommend to =
make separate modules for things that need to be versioned separately, i.e.=
 corresponding to software components. To me, these modules feel very close=
ly related, so even a single module for all of this would be fine. Factorin=
g things out into separate modules may make it harder to get a full grasp o=
f what SFC is about, repeating things in module descriptions, making creati=
on of new revisions harder.

[RP] They were even smaller and based on opendaylight testing and feedback =
from folks like you they have been growing in order to accommodate the use-=
cases.  Therefore we should and decide later to consolidate or keep them ap=
art.

/Jan Lindblad


On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com<mailt=
o:repenno@cisco.com>> wrote:

A new version of I-D, draft-penno-sfc-yang-02.txt
has been successfully submitted by Reinaldo Penno and posted to the
IETF repository.

Name:           draft-penno-sfc-yang
Revision:       02
Title:          Yang Data Model for Service Function Chaining
Document date:  2014-05-29
Group:          Individual Submission
Pages:          20
URL:            http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02=
.txt
Status:         https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
Htmlized:       http://tools.ietf.org/html/draft-penno-sfc-yang-02
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02
_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc



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

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin-bottom:=
0;}</style>
</head>
<body ocsi=3D"0" fpstyle=3D"1" style=3D"word-wrap:break-word; color:rgb(0,0=
,0); font-size:14px; font-family:Calibri,sans-serif">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">New version of SFC Yang data models.<br>
<br>
thanks to <font color=3D"#000000" face=3D"Tahoma" size=3D"2">Jan Lindblad, =
Ron Parker and other reviewers.<br>
<br>
</font><br>
<font size=3D"2"><span style=3D"font-size:10pt;">A new version of I-D, draf=
t-penno-sfc-yang-03.txt<br>
has been successfully submitted by Reinaldo Penno and posted to the<br>
IETF repository.<br>
<br>
Name:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-pen=
no-sfc-yang<br>
Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 03<br>
Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yang Data Mode=
l for Service Function Chaining<br>
Document date:&nbsp; 2014-06-06<br>
Group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Sub=
mission<br>
Pages:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 21<br>
URL:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a h=
ref=3D"http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt" tar=
get=3D"_blank">
http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt</a><br>
Status:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://=
datatracker.ietf.org/doc/draft-penno-sfc-yang/" target=3D"_blank">
https://datatracker.ietf.org/doc/draft-penno-sfc-yang/</a><br>
Htmlized:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"http://tools.ietf.=
org/html/draft-penno-sfc-yang-03" target=3D"_blank">
http://tools.ietf.org/html/draft-penno-sfc-yang-03</a><br>
Diff:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=
=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-03" target=3D"_=
blank">
http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-03</a><br>
<br>
Abstract:<br>
&nbsp;&nbsp; This document defines a YANG data model that can be used to co=
nfigure<br>
&nbsp;&nbsp; and manage Service Function Chains.<br>
</span></font>
<div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px=
">
<hr tabindex=3D"-1">
<div style=3D"direction: ltr;" id=3D"divRpF775188"><font color=3D"#000000" =
face=3D"Tahoma" size=3D"2"><b>From:</b> sfc [sfc-bounces@ietf.org] on behal=
f of Reinaldo Penno (repenno)<br>
<b>Sent:</b> Friday, June 06, 2014 7:28 PM<br>
<b>To:</b> Jan Lindblad<br>
<b>Cc:</b> sfc@ietf.org<br>
<b>Subject:</b> Re: [sfc] Yang Data Model for Service Function Chaining (02=
)<br>
</font><br>
</div>
<div></div>
<div>
<div>Hello Jan,</div>
<div><br>
</div>
<div>Thanks for the review, I will submit a new version shortly.&nbsp;</div=
>
<div><br>
</div>
<div>Inline with [RP]</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:0i=
n; padding-left:0in; padding-right:0in; border-top:#b5c4df 1pt solid; borde=
r-right:medium none; padding-top:3pt">
<span style=3D"font-weight:bold">From: </span>Jan Lindblad &lt;<a href=3D"m=
ailto:janl@tail-f.com" target=3D"_blank">janl@tail-f.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Tuesday, June 3, 2014 at 2:05=
 AM<br>
<span style=3D"font-weight:bold">To: </span>Cisco Employee &lt;<a href=3D"m=
ailto:repenno@cisco.com" target=3D"_blank">repenno@cisco.com</a>&gt;<br>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:sfc@iet=
f.org" target=3D"_blank">sfc@ietf.org</a>&quot; &lt;<a href=3D"mailto:sfc@i=
etf.org" target=3D"_blank">sfc@ietf.org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [sfc] Yang Data Model =
for Service Function Chaining (02)<br>
</div>
<div><br>
</div>
<div>
<div style=3D"word-wrap:break-word">
<div>Reinaldo,</div>
<div><br>
</div>
<div>Good work! I made a quick review of your proposed SFC YANG module. I h=
ave been monitoring this list for a couple of weeks only, so please bear wi=
th any misconceptions on my part. I'm a YANG Doctor, however, so I was hopi=
ng I could contribute with a few
 YANG-level suggestions or options for you.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>module vxlan-gpe:</div>
<div><br>
</div>
<div>The namespace declaration in each of the modules starts with urn:cisco=
:... Namespaces on this form are supposed to be registered with IANA.&nbsp;=
<a href=3D"http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xh=
tml" target=3D"_blank">http://www.iana.org/assignments/urn-namespaces/urn-n=
amespaces.xhtml</a></div>
<div><br>
</div>
<div>I suggest either changing this to an IETF reserved name, or move it to=
 a proper cisco-namespace, e.g.:</div>
<div>namespace &quot;<a href=3D"http://cisco.com/ns/ietf/wg/sfc" target=3D"=
_blank">http://cisco.com/ns/ietf/wg/sfc</a>&quot;;</div>
<div>or, perhaps better, an IETF registered name:</div>
<div>namespace &quot;urn:ietf:rfc:XXXX&quot;; // RFC Ed.: Replace XXXX with=
 actual RFC number and remove this note.</div>
<div>This applies to all modules in the submission, but I will not keep rep=
eating this comment for the others.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] changed throughput to urn:TBD:...</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>There are a number of reserved bits and fields in the module. I think =
it may be wise to think this through a bit more before publishing. Accordin=
g to the YANG RFC 6020 section 10, IETF does not allow itself to ever remov=
e a published configurable item
 from a module, so those reserved names will have to stick forever. To make=
 it worse, the bit positions must be unique, so the bit names will have to =
remain r1, r2, r3, ... indefinitely, even if a proper meaning and name is i=
nvented at a later stage. I suggest
 simply not listing them in the specification in this version, only adding =
them when they have a well defined meaning.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] okay.</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>The leaf-list vni will not behave as intended. A leaf list will automa=
tically sort itself into the natural (ascending) order (unless ordered-by u=
ser is specified), and can never contain repeated values (such as [1,1,1]).=
 I'd suggest you use a 24-bit integer
 instead. Or possibly a list (not leaf list) with a position key. Or three =
separate 8-bit leafs (vni-low, vni-med, vni-high).</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] Used 3 separate 8-bit leafs for now.</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>module service-function:</div>
<div><br>
</div>
<div>Revision dates are YYYY-MM-DD</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] Done</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>Identity&#43;identityref seems like a good way to handle this extensib=
le set. It does require YANG modeling to define new types however, so if op=
erators should be able to invent new types &quot;on the fly&quot;, another =
option would be to have one more config table
 with the operator specified types, and then use a leafref to point to one =
of them.</div>
<div><br>
</div>
<div>Mandatory true on a key element is not necessary, so this can be remov=
ed for improved readability and brevity. This also applies to several other=
 lists, but I will not keep repeating this comment.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] Done</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>There is no mandatory true on the type and ip-host-address leafs. What=
 would it mean if a sfc entry exists and has no type nor ip-host-address? S=
hould one or both be mandatory, or have a default? Note that if we specify =
a default, that default value can
 never ever be changed to something else according to the YANG RFC 6020, se=
c 10.</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] This can be modified later.</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>module service-function-chain:</div>
<div><br>
</div>
<div>As noted by Ron Parker, this allows only a single instance of each ser=
vice type in each chain. With the current model, an operator has no way of =
defining additional service types to say clone a dpi service into an dpi-ea=
rly and dpi-late. If this was modeled
 as a list with a string name and a service-function-type leaf instead, the=
 same function could appear multiple times in a chain.</div>
<div><br>
</div>
<div>[RP] I=92ve made this change but in order to avoid confusion I=92m rel=
ying on the description to clear things up. Meaning, in the best case where=
 you have a chain where there is only one of each type the leaf =93name&quo=
t; &nbsp;is redundant and in the worst case it might
 cause confusion, for example, &nbsp;if you can have a name =93dpi-early=94=
 and a type =93firewall=94. I guess we needed a list in Yang where indexes =
are assigned and you can have repeated values, otherwise it feels I created=
 a leaf name for no purpose. &nbsp;</div>
</div>
</div>
</span>
<div><br>
</div>
<div><br>
</div>
<div>
<div>&nbsp; &nbsp;list service-function {</div>
<div>&nbsp; &nbsp; &nbsp; key &quot;name&quot;;</div>
<div>&nbsp; &nbsp; &nbsp; leaf name {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; type string;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; description</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;The name of the servic=
e function. This could be the</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; same as the type or in the c=
ase where multiple service</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; functions or the same type a=
re used in chain, something</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like ingress-firewall and eg=
ress-firewall&quot;;</div>
<div>&nbsp; &nbsp; &nbsp; }</div>
<div>&nbsp; &nbsp; &nbsp; leaf type {</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; type sfc-sf:service-function-type;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; description</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;The type of the servic=
e function.&quot;;</div>
<div>&nbsp; &nbsp; &nbsp; }</div>
<div>&nbsp; &nbsp; &nbsp; ordered-by user;</div>
<div>&nbsp; &nbsp; &nbsp; description</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &quot;A list of service functions that com=
pose the service chain&quot;;</div>
<div>&nbsp; &nbsp; }</div>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>module service-node:</div>
<div><br>
</div>
<div>The leafs type, transport, ip-host-address and failmode are not mandat=
ory and have no defaults. Will it be entirely clear to operators what the s=
ystem will do if some or all of them have no values? This is not obvious to=
 me (but that could be only me).</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] I think the idea here is that at the time of creation the operato=
r could not (or might not) want to specify all these things.&nbsp;</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>As noted by Ron Parker, type can hold only a single value. Could a ser=
vice node be of multiple types simultaneously?</div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] As I said in my reply to Ron this might be something to think abo=
ut. It is a trade-off of complexity vs. flexibility.&nbsp;</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>module service-function-path:</div>
<div><br>
</div>
<div>The service-function-path is modeled as a container. So there can be o=
nly one of these in the whole system. I might be missing something, but I t=
hink you want a list here, in some way.</div>
<div><br>
</div>
<div>[RP] Good catch. &nbsp;Changed.</div>
<div><br>
</div>
<div>module service-function-forwarder:</div>
<div><br>
</div>
<div>Once again, the leafs ip and port are not mandatory. Is that ok? Shoul=
d each service function have a single ip/port pair?</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>In general, I think these modules are very small. Typically I recommen=
d to make separate modules for things that need to be versioned separately,=
 i.e. corresponding to software components. To me, these modules feel very =
closely related, so even a single
 module for all of this would be fine. Factoring things out into separate m=
odules may make it harder to get a full grasp of what SFC is about, repeati=
ng things in module descriptions, making creation of new revisions harder.<=
/div>
</div>
</div>
</span>
<div><br>
</div>
<div>[RP] They were even smaller and based on opendaylight testing and feed=
back from folks like you they have been growing in order to accommodate the=
 use-cases. &nbsp;Therefore we should and decide later to consolidate or ke=
ep them apart.&nbsp;</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div>
<div style=3D"word-wrap:break-word">
<div><br>
</div>
<div>/Jan Lindblad</div>
<div><span class=3D"Apple-style-span" style=3D"border-collapse:separate; bo=
rder-spacing:0px">
<div style=3D"word-wrap:break-word"><span class=3D"Apple-style-span" style=
=3D"border-collapse:separate; border-spacing:0px; color:rgb(0,0,0); font-fa=
mily:Helvetica; font-size:12px; font-style:normal; font-variant:normal; fon=
t-weight:normal; letter-spacing:normal; line-height:normal; text-indent:0px=
; text-transform:none; orphans:2; white-space:normal; widows:2; word-spacin=
g:0px">
<div style=3D"word-wrap:break-word"><span class=3D"Apple-style-span" style=
=3D"border-collapse:separate; border-spacing:0px; color:rgb(0,0,0); font-fa=
mily:Helvetica; font-size:12px; font-style:normal; font-variant:normal; fon=
t-weight:normal; letter-spacing:normal; line-height:normal; text-indent:0px=
; text-transform:none; orphans:2; white-space:normal; widows:2; word-spacin=
g:0px">
<div><br>
</div>
</span></div>
</span></div>
</span></div>
<br>
<div>
<div>On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) &lt;<a href=3D"mail=
to:repenno@cisco.com" target=3D"_blank">repenno@cisco.com</a>&gt; wrote:</d=
iv>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">A new version of I-D, draft-penno-sfc-yang-02.txt=
<br>
has been successfully submitted by Reinaldo Penno and posted to the<br>
IETF repository.<br>
<br>
Name: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;draft-pen=
no-sfc-yang<br>
Revision: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;02<br>
Title: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Yang Data Mode=
l for Service Function Chaining<br>
Document date: &nbsp;2014-05-29<br>
Group: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Individual Sub=
mission<br>
Pages: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;20<br>
URL: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a h=
ref=3D"http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt" tar=
get=3D"_blank">http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.=
txt</a><br>
Status: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"https://=
datatracker.ietf.org/doc/draft-penno-sfc-yang/" target=3D"_blank">https://d=
atatracker.ietf.org/doc/draft-penno-sfc-yang/</a><br>
Htmlized: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"http://tools.ietf.=
org/html/draft-penno-sfc-yang-02" target=3D"_blank">http://tools.ietf.org/h=
tml/draft-penno-sfc-yang-02</a><br>
Diff: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=
=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02" target=3D"_=
blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02</a><br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</span></div>
</div>
</div>
</body>
</html>

--_000_45A697A8FFD7CF48BCF2BE7E106F06040BE2C8E8xmbrcdx04ciscoc_--


From nobody Sun Jun  8 13:04:57 2014
Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AA21A03EA for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 13:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRExDz3_DLDA for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 13:04:50 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775081A03E2 for <sfc@ietf.org>; Sun,  8 Jun 2014 13:04:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 56E98240E12; Sun,  8 Jun 2014 13:04:50 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 40697240AE4; Sun,  8 Jun 2014 13:04:49 -0700 (PDT)
Message-ID: <5394C1E4.9070602@joelhalpern.com>
Date: Sun, 08 Jun 2014 16:04:52 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>,  "sfc@ietf.org" <sfc@ietf.org>
References: <45A697A8FFD7CF48BCF2BE7E106F06040BE2C8E8@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040BE2C8E8@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4e2t0vcqRjPsu3uXkFy_CPy6qqE
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Jun 2014 20:04:52 -0000

The definition of service function forwarder here seems MUCH too 
specific.  I would think we would want a generalized definition, and 
then an extension for the ase where the forwarder reachs the service 
functions based on IP address and port number.

Yours,
Joel

On 6/8/14, 3:46 PM, Reinaldo Penno (repenno) wrote:
> New version of SFC Yang data models.
>
> thanks to Jan Lindblad, Ron Parker and other reviewers.
>
>
> A new version of I-D, draft-penno-sfc-yang-03.txt
> has been successfully submitted by Reinaldo Penno and posted to the
> IETF repository.
>
> Name:           draft-penno-sfc-yang
> Revision:       03
> Title:          Yang Data Model for Service Function Chaining
> Document date:  2014-06-06
> Group:          Individual Submission
> Pages:          21
> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt
> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-03
> Diff: http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-03
>
> Abstract:
>     This document defines a YANG data model that can be used to configure
>     and manage Service Function Chains.
> ------------------------------------------------------------------------
> *From:* sfc [sfc-bounces@ietf.org] on behalf of Reinaldo Penno (repenno)
> *Sent:* Friday, June 06, 2014 7:28 PM
> *To:* Jan Lindblad
> *Cc:* sfc@ietf.org
> *Subject:* Re: [sfc] Yang Data Model for Service Function Chaining (02)
>
> Hello Jan,
>
> Thanks for the review, I will submit a new version shortly.
>
> Inline with [RP]
>
> From: Jan Lindblad <janl@tail-f.com <mailto:janl@tail-f.com>>
> Date: Tuesday, June 3, 2014 at 2:05 AM
> To: Cisco Employee <repenno@cisco.com <mailto:repenno@cisco.com>>
> Cc: "sfc@ietf.org <mailto:sfc@ietf.org>" <sfc@ietf.org
> <mailto:sfc@ietf.org>>
> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)
>
> Reinaldo,
>
> Good work! I made a quick review of your proposed SFC YANG module. I
> have been monitoring this list for a couple of weeks only, so please
> bear with any misconceptions on my part. I'm a YANG Doctor, however, so
> I was hoping I could contribute with a few YANG-level suggestions or
> options for you.
>
>
>
> module vxlan-gpe:
>
> The namespace declaration in each of the modules starts with
> urn:cisco:... Namespaces on this form are supposed to be registered with
> IANA. http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>
> I suggest either changing this to an IETF reserved name, or move it to a
> proper cisco-namespace, e.g.:
> namespace "http://cisco.com/ns/ietf/wg/sfc";
> or, perhaps better, an IETF registered name:
> namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC
> number and remove this note.
> This applies to all modules in the submission, but I will not keep
> repeating this comment for the others.
>
> [RP] changed throughput to urn:TBD:...
>
> There are a number of reserved bits and fields in the module. I think it
> may be wise to think this through a bit more before publishing.
> According to the YANG RFC 6020 section 10, IETF does not allow itself to
> ever remove a published configurable item from a module, so those
> reserved names will have to stick forever. To make it worse, the bit
> positions must be unique, so the bit names will have to remain r1, r2,
> r3, ... indefinitely, even if a proper meaning and name is invented at a
> later stage. I suggest simply not listing them in the specification in
> this version, only adding them when they have a well defined meaning.
>
> [RP] okay.
>
> The leaf-list vni will not behave as intended. A leaf list will
> automatically sort itself into the natural (ascending) order (unless
> ordered-by user is specified), and can never contain repeated values
> (such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or
> possibly a list (not leaf list) with a position key. Or three separate
> 8-bit leafs (vni-low, vni-med, vni-high).
>
> [RP] Used 3 separate 8-bit leafs for now.
>
>
>
> module service-function:
>
> Revision dates are YYYY-MM-DD
>
> [RP] Done
>
> Identity+identityref seems like a good way to handle this extensible
> set. It does require YANG modeling to define new types however, so if
> operators should be able to invent new types "on the fly", another
> option would be to have one more config table with the operator
> specified types, and then use a leafref to point to one of them.
>
> Mandatory true on a key element is not necessary, so this can be removed
> for improved readability and brevity. This also applies to several other
> lists, but I will not keep repeating this comment.
>
> [RP] Done
>
> There is no mandatory true on the type and ip-host-address leafs. What
> would it mean if a sfc entry exists and has no type nor ip-host-address?
> Should one or both be mandatory, or have a default? Note that if we
> specify a default, that default value can never ever be changed to
> something else according to the YANG RFC 6020, sec 10.
>
> [RP] This can be modified later.
>
>
>
> module service-function-chain:
>
> As noted by Ron Parker, this allows only a single instance of each
> service type in each chain. With the current model, an operator has no
> way of defining additional service types to say clone a dpi service into
> an dpi-early and dpi-late. If this was modeled as a list with a string
> name and a service-function-type leaf instead, the same function could
> appear multiple times in a chain.
>
> [RP] I’ve made this change but in order to avoid confusion I’m relying
> on the description to clear things up. Meaning, in the best case where
> you have a chain where there is only one of each type the leaf “name"
>   is redundant and in the worst case it might cause confusion, for
> example,  if you can have a name “dpi-early” and a type “firewall”. I
> guess we needed a list in Yang where indexes are assigned and you can
> have repeated values, otherwise it feels I created a leaf name for no
> purpose.
>
>
>     list service-function {
>        key "name";
>        leaf name {
>          type string;
>          description
>              "The name of the service function. This could be the
>              same as the type or in the case where multiple service
>              functions or the same type are used in chain, something
>              like ingress-firewall and egress-firewall";
>        }
>        leaf type {
>          type sfc-sf:service-function-type;
>          description
>              "The type of the service function.";
>        }
>        ordered-by user;
>        description
>          "A list of service functions that compose the service chain";
>      }
>
> module service-node:
>
> The leafs type, transport, ip-host-address and failmode are not
> mandatory and have no defaults. Will it be entirely clear to operators
> what the system will do if some or all of them have no values? This is
> not obvious to me (but that could be only me).
>
> [RP] I think the idea here is that at the time of creation the operator
> could not (or might not) want to specify all these things.
>
> As noted by Ron Parker, type can hold only a single value. Could a
> service node be of multiple types simultaneously?
>
> [RP] As I said in my reply to Ron this might be something to think
> about. It is a trade-off of complexity vs. flexibility.
>
> module service-function-path:
>
> The service-function-path is modeled as a container. So there can be
> only one of these in the whole system. I might be missing something, but
> I think you want a list here, in some way.
>
> [RP] Good catch.  Changed.
>
> module service-function-forwarder:
>
> Once again, the leafs ip and port are not mandatory. Is that ok? Should
> each service function have a single ip/port pair?
>
>
>
> In general, I think these modules are very small. Typically I recommend
> to make separate modules for things that need to be versioned
> separately, i.e. corresponding to software components. To me, these
> modules feel very closely related, so even a single module for all of
> this would be fine. Factoring things out into separate modules may make
> it harder to get a full grasp of what SFC is about, repeating things in
> module descriptions, making creation of new revisions harder.
>
> [RP] They were even smaller and based on opendaylight testing and
> feedback from folks like you they have been growing in order to
> accommodate the use-cases.  Therefore we should and decide later to
> consolidate or keep them apart.
>
> /Jan Lindblad
>
>
> On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com
> <mailto:repenno@cisco.com>> wrote:
>
>> A new version of I-D, draft-penno-sfc-yang-02.txt
>> has been successfully submitted by Reinaldo Penno and posted to the
>> IETF repository.
>>
>> Name:           draft-penno-sfc-yang
>> Revision:       02
>> Title:          Yang Data Model for Service Function Chaining
>> Document date:  2014-05-29
>> Group:          Individual Submission
>> Pages:          20
>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt
>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02
>> Diff: http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-02
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org <mailto:sfc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>


From nobody Sun Jun  8 20:04:59 2014
Return-Path: <repenno@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E2A1B27C2 for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 20:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UMvcs6VUJ3w for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 20:04:54 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047CD1B27BE for <sfc@ietf.org>; Sun,  8 Jun 2014 20:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11378; q=dns/txt; s=iport; t=1402283094; x=1403492694; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/aPCDU6vhdnCu9rUyWSidQK5yYbLJ3jzir4dePdKZFk=; b=hejwzbANVMhGZI1UIAOnSEeZle2paXWnJ0UAd9XaqtIDDMXR9sSOIgHP VqdEct4iQLzXzpwZoS1L9YQETRnci26iFSI8C42Uc0zCRLu54d0p2BECF Dx1knF+LiPB4iJCFkcm0VaiQt5VCbpiiDnioM6Ra2RS9NRmlzzWe2b5Ta s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtoUAAMjlVOtJA2M/2dsb2JhbABQCYMNUlIEA6sKAQUBkVSHPAGBDBZ1hAMBAQEDAQEBAWsGFQIBCBEDAQEBAQodBycLFAkIAgQBEggBiDEICAWvTJksF4Vdg2OEUSo4gyuBFgSWF4VMiXeIDIM8bIFD
X-IronPort-AV: E=Sophos;i="4.98,1000,1392163200"; d="scan'208";a="51288782"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 09 Jun 2014 03:04:52 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5934qBj028761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jun 2014 03:04:52 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Sun, 8 Jun 2014 22:04:52 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Yang Data Model for Service Function Chaining (03)
Thread-Index: AQHPg1JeYWsdvBdCA0uU83jgVhKRwJtn9v4AgAAhS3M=
Date: Mon, 9 Jun 2014 03:04:52 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040BE2C949@xmb-rcd-x04.cisco.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040BE2C8E8@xmb-rcd-x04.cisco.com>,  <5394C1E4.9070602@joelhalpern.com>
In-Reply-To: <5394C1E4.9070602@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.95.61]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Cwgj3mosTbaav5mBnjYO-ZY5-dQ
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2014 03:04:57 -0000

Sure, let's work on it.=0A=
=0A=
Do you want to propose something that matches your expectations and then we=
 can refine it?=0A=
=0A=
thanks,=0A=
=0A=
Reinaldo=0A=
=0A=
________________________________________=0A=
From: Joel M. Halpern [jmh@joelhalpern.com]=0A=
Sent: Sunday, June 08, 2014 1:04 PM=0A=
To: Reinaldo Penno (repenno); sfc@ietf.org=0A=
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)=0A=
=0A=
The definition of service function forwarder here seems MUCH too=0A=
specific.  I would think we would want a generalized definition, and=0A=
then an extension for the ase where the forwarder reachs the service=0A=
functions based on IP address and port number.=0A=
=0A=
Yours,=0A=
Joel=0A=
=0A=
On 6/8/14, 3:46 PM, Reinaldo Penno (repenno) wrote:=0A=
> New version of SFC Yang data models.=0A=
>=0A=
> thanks to Jan Lindblad, Ron Parker and other reviewers.=0A=
>=0A=
>=0A=
> A new version of I-D, draft-penno-sfc-yang-03.txt=0A=
> has been successfully submitted by Reinaldo Penno and posted to the=0A=
> IETF repository.=0A=
>=0A=
> Name:           draft-penno-sfc-yang=0A=
> Revision:       03=0A=
> Title:          Yang Data Model for Service Function Chaining=0A=
> Document date:  2014-06-06=0A=
> Group:          Individual Submission=0A=
> Pages:          21=0A=
> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt=0A=
> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/=0A=
> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-03=0A=
> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-03=0A=
>=0A=
> Abstract:=0A=
>     This document defines a YANG data model that can be used to configure=
=0A=
>     and manage Service Function Chains.=0A=
> ------------------------------------------------------------------------=
=0A=
> *From:* sfc [sfc-bounces@ietf.org] on behalf of Reinaldo Penno (repenno)=
=0A=
> *Sent:* Friday, June 06, 2014 7:28 PM=0A=
> *To:* Jan Lindblad=0A=
> *Cc:* sfc@ietf.org=0A=
> *Subject:* Re: [sfc] Yang Data Model for Service Function Chaining (02)=
=0A=
>=0A=
> Hello Jan,=0A=
>=0A=
> Thanks for the review, I will submit a new version shortly.=0A=
>=0A=
> Inline with [RP]=0A=
>=0A=
> From: Jan Lindblad <janl@tail-f.com <mailto:janl@tail-f.com>>=0A=
> Date: Tuesday, June 3, 2014 at 2:05 AM=0A=
> To: Cisco Employee <repenno@cisco.com <mailto:repenno@cisco.com>>=0A=
> Cc: "sfc@ietf.org <mailto:sfc@ietf.org>" <sfc@ietf.org=0A=
> <mailto:sfc@ietf.org>>=0A=
> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)=0A=
>=0A=
> Reinaldo,=0A=
>=0A=
> Good work! I made a quick review of your proposed SFC YANG module. I=0A=
> have been monitoring this list for a couple of weeks only, so please=0A=
> bear with any misconceptions on my part. I'm a YANG Doctor, however, so=
=0A=
> I was hoping I could contribute with a few YANG-level suggestions or=0A=
> options for you.=0A=
>=0A=
>=0A=
>=0A=
> module vxlan-gpe:=0A=
>=0A=
> The namespace declaration in each of the modules starts with=0A=
> urn:cisco:... Namespaces on this form are supposed to be registered with=
=0A=
> IANA. http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml=
=0A=
>=0A=
> I suggest either changing this to an IETF reserved name, or move it to a=
=0A=
> proper cisco-namespace, e.g.:=0A=
> namespace "http://cisco.com/ns/ietf/wg/sfc";=0A=
> or, perhaps better, an IETF registered name:=0A=
> namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC=
=0A=
> number and remove this note.=0A=
> This applies to all modules in the submission, but I will not keep=0A=
> repeating this comment for the others.=0A=
>=0A=
> [RP] changed throughput to urn:TBD:...=0A=
>=0A=
> There are a number of reserved bits and fields in the module. I think it=
=0A=
> may be wise to think this through a bit more before publishing.=0A=
> According to the YANG RFC 6020 section 10, IETF does not allow itself to=
=0A=
> ever remove a published configurable item from a module, so those=0A=
> reserved names will have to stick forever. To make it worse, the bit=0A=
> positions must be unique, so the bit names will have to remain r1, r2,=0A=
> r3, ... indefinitely, even if a proper meaning and name is invented at a=
=0A=
> later stage. I suggest simply not listing them in the specification in=0A=
> this version, only adding them when they have a well defined meaning.=0A=
>=0A=
> [RP] okay.=0A=
>=0A=
> The leaf-list vni will not behave as intended. A leaf list will=0A=
> automatically sort itself into the natural (ascending) order (unless=0A=
> ordered-by user is specified), and can never contain repeated values=0A=
> (such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or=0A=
> possibly a list (not leaf list) with a position key. Or three separate=0A=
> 8-bit leafs (vni-low, vni-med, vni-high).=0A=
>=0A=
> [RP] Used 3 separate 8-bit leafs for now.=0A=
>=0A=
>=0A=
>=0A=
> module service-function:=0A=
>=0A=
> Revision dates are YYYY-MM-DD=0A=
>=0A=
> [RP] Done=0A=
>=0A=
> Identity+identityref seems like a good way to handle this extensible=0A=
> set. It does require YANG modeling to define new types however, so if=0A=
> operators should be able to invent new types "on the fly", another=0A=
> option would be to have one more config table with the operator=0A=
> specified types, and then use a leafref to point to one of them.=0A=
>=0A=
> Mandatory true on a key element is not necessary, so this can be removed=
=0A=
> for improved readability and brevity. This also applies to several other=
=0A=
> lists, but I will not keep repeating this comment.=0A=
>=0A=
> [RP] Done=0A=
>=0A=
> There is no mandatory true on the type and ip-host-address leafs. What=0A=
> would it mean if a sfc entry exists and has no type nor ip-host-address?=
=0A=
> Should one or both be mandatory, or have a default? Note that if we=0A=
> specify a default, that default value can never ever be changed to=0A=
> something else according to the YANG RFC 6020, sec 10.=0A=
>=0A=
> [RP] This can be modified later.=0A=
>=0A=
>=0A=
>=0A=
> module service-function-chain:=0A=
>=0A=
> As noted by Ron Parker, this allows only a single instance of each=0A=
> service type in each chain. With the current model, an operator has no=0A=
> way of defining additional service types to say clone a dpi service into=
=0A=
> an dpi-early and dpi-late. If this was modeled as a list with a string=0A=
> name and a service-function-type leaf instead, the same function could=0A=
> appear multiple times in a chain.=0A=
>=0A=
> [RP] I=92ve made this change but in order to avoid confusion I=92m relyin=
g=0A=
> on the description to clear things up. Meaning, in the best case where=0A=
> you have a chain where there is only one of each type the leaf =93name"=
=0A=
>   is redundant and in the worst case it might cause confusion, for=0A=
> example,  if you can have a name =93dpi-early=94 and a type =93firewall=
=94. I=0A=
> guess we needed a list in Yang where indexes are assigned and you can=0A=
> have repeated values, otherwise it feels I created a leaf name for no=0A=
> purpose.=0A=
>=0A=
>=0A=
>     list service-function {=0A=
>        key "name";=0A=
>        leaf name {=0A=
>          type string;=0A=
>          description=0A=
>              "The name of the service function. This could be the=0A=
>              same as the type or in the case where multiple service=0A=
>              functions or the same type are used in chain, something=0A=
>              like ingress-firewall and egress-firewall";=0A=
>        }=0A=
>        leaf type {=0A=
>          type sfc-sf:service-function-type;=0A=
>          description=0A=
>              "The type of the service function.";=0A=
>        }=0A=
>        ordered-by user;=0A=
>        description=0A=
>          "A list of service functions that compose the service chain";=0A=
>      }=0A=
>=0A=
> module service-node:=0A=
>=0A=
> The leafs type, transport, ip-host-address and failmode are not=0A=
> mandatory and have no defaults. Will it be entirely clear to operators=0A=
> what the system will do if some or all of them have no values? This is=0A=
> not obvious to me (but that could be only me).=0A=
>=0A=
> [RP] I think the idea here is that at the time of creation the operator=
=0A=
> could not (or might not) want to specify all these things.=0A=
>=0A=
> As noted by Ron Parker, type can hold only a single value. Could a=0A=
> service node be of multiple types simultaneously?=0A=
>=0A=
> [RP] As I said in my reply to Ron this might be something to think=0A=
> about. It is a trade-off of complexity vs. flexibility.=0A=
>=0A=
> module service-function-path:=0A=
>=0A=
> The service-function-path is modeled as a container. So there can be=0A=
> only one of these in the whole system. I might be missing something, but=
=0A=
> I think you want a list here, in some way.=0A=
>=0A=
> [RP] Good catch.  Changed.=0A=
>=0A=
> module service-function-forwarder:=0A=
>=0A=
> Once again, the leafs ip and port are not mandatory. Is that ok? Should=
=0A=
> each service function have a single ip/port pair?=0A=
>=0A=
>=0A=
>=0A=
> In general, I think these modules are very small. Typically I recommend=
=0A=
> to make separate modules for things that need to be versioned=0A=
> separately, i.e. corresponding to software components. To me, these=0A=
> modules feel very closely related, so even a single module for all of=0A=
> this would be fine. Factoring things out into separate modules may make=
=0A=
> it harder to get a full grasp of what SFC is about, repeating things in=
=0A=
> module descriptions, making creation of new revisions harder.=0A=
>=0A=
> [RP] They were even smaller and based on opendaylight testing and=0A=
> feedback from folks like you they have been growing in order to=0A=
> accommodate the use-cases.  Therefore we should and decide later to=0A=
> consolidate or keep them apart.=0A=
>=0A=
> /Jan Lindblad=0A=
>=0A=
>=0A=
> On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com=0A=
> <mailto:repenno@cisco.com>> wrote:=0A=
>=0A=
>> A new version of I-D, draft-penno-sfc-yang-02.txt=0A=
>> has been successfully submitted by Reinaldo Penno and posted to the=0A=
>> IETF repository.=0A=
>>=0A=
>> Name:           draft-penno-sfc-yang=0A=
>> Revision:       02=0A=
>> Title:          Yang Data Model for Service Function Chaining=0A=
>> Document date:  2014-05-29=0A=
>> Group:          Individual Submission=0A=
>> Pages:          20=0A=
>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt=0A=
>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/=0A=
>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02=0A=
>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02=0A=
>> _______________________________________________=0A=
>> sfc mailing list=0A=
>> sfc@ietf.org <mailto:sfc@ietf.org>=0A=
>> https://www.ietf.org/mailman/listinfo/sfc=0A=
>>=0A=
>=0A=
>=0A=
>=0A=
> _______________________________________________=0A=
> sfc mailing list=0A=
> sfc@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/sfc=0A=
>=0A=


From nobody Sun Jun  8 21:27:45 2014
Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194C21B27D0 for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 21:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKjUodEVXKRl for <sfc@ietfa.amsl.com>; Sun,  8 Jun 2014 21:27:42 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237BE1A04AE for <sfc@ietf.org>; Sun,  8 Jun 2014 21:27:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E29DB1C0C95; Sun,  8 Jun 2014 21:27:41 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 063E21C05C6; Sun,  8 Jun 2014 21:27:28 -0700 (PDT)
Message-ID: <539537A5.8090405@joelhalpern.com>
Date: Mon, 09 Jun 2014 00:27:17 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>,  "sfc@ietf.org" <sfc@ietf.org>
References: <45A697A8FFD7CF48BCF2BE7E106F06040BE2C8E8@xmb-rcd-x04.cisco.com>,  <5394C1E4.9070602@joelhalpern.com> <45A697A8FFD7CF48BCF2BE7E106F06040BE2C949@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040BE2C949@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-KqXXjiV3CNwYhwDdvgryqfIy4E
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2014 04:27:44 -0000

It would seem that a starting point would be to replace the address and 
port with a reference to a service functiuon?

Also, should we have a distinction between a kind of service function as 
it appears in a service chian, and a location we can direct packets to 
for a service function, as it appears in the service path.  (I hesitate 
to use the word instance since while the thing appears as an isntance to 
the path, it may actually be a cluster, etc...)

Yours,
Joel

On 6/8/14, 11:04 PM, Reinaldo Penno (repenno) wrote:
> Sure, let's work on it.
>
> Do you want to propose something that matches your expectations and then we can refine it?
>
> thanks,
>
> Reinaldo
>
> ________________________________________
> From: Joel M. Halpern [jmh@joelhalpern.com]
> Sent: Sunday, June 08, 2014 1:04 PM
> To: Reinaldo Penno (repenno); sfc@ietf.org
> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
>
> The definition of service function forwarder here seems MUCH too
> specific.  I would think we would want a generalized definition, and
> then an extension for the ase where the forwarder reachs the service
> functions based on IP address and port number.
>
> Yours,
> Joel
>
> On 6/8/14, 3:46 PM, Reinaldo Penno (repenno) wrote:
>> New version of SFC Yang data models.
>>
>> thanks to Jan Lindblad, Ron Parker and other reviewers.
>>
>>
>> A new version of I-D, draft-penno-sfc-yang-03.txt
>> has been successfully submitted by Reinaldo Penno and posted to the
>> IETF repository.
>>
>> Name:           draft-penno-sfc-yang
>> Revision:       03
>> Title:          Yang Data Model for Service Function Chaining
>> Document date:  2014-06-06
>> Group:          Individual Submission
>> Pages:          21
>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt
>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-03
>> Diff: http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-03
>>
>> Abstract:
>>      This document defines a YANG data model that can be used to configure
>>      and manage Service Function Chains.
>> ------------------------------------------------------------------------
>> *From:* sfc [sfc-bounces@ietf.org] on behalf of Reinaldo Penno (repenno)
>> *Sent:* Friday, June 06, 2014 7:28 PM
>> *To:* Jan Lindblad
>> *Cc:* sfc@ietf.org
>> *Subject:* Re: [sfc] Yang Data Model for Service Function Chaining (02)
>>
>> Hello Jan,
>>
>> Thanks for the review, I will submit a new version shortly.
>>
>> Inline with [RP]
>>
>> From: Jan Lindblad <janl@tail-f.com <mailto:janl@tail-f.com>>
>> Date: Tuesday, June 3, 2014 at 2:05 AM
>> To: Cisco Employee <repenno@cisco.com <mailto:repenno@cisco.com>>
>> Cc: "sfc@ietf.org <mailto:sfc@ietf.org>" <sfc@ietf.org
>> <mailto:sfc@ietf.org>>
>> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)
>>
>> Reinaldo,
>>
>> Good work! I made a quick review of your proposed SFC YANG module. I
>> have been monitoring this list for a couple of weeks only, so please
>> bear with any misconceptions on my part. I'm a YANG Doctor, however, so
>> I was hoping I could contribute with a few YANG-level suggestions or
>> options for you.
>>
>>
>>
>> module vxlan-gpe:
>>
>> The namespace declaration in each of the modules starts with
>> urn:cisco:... Namespaces on this form are supposed to be registered with
>> IANA. http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>>
>> I suggest either changing this to an IETF reserved name, or move it to a
>> proper cisco-namespace, e.g.:
>> namespace "http://cisco.com/ns/ietf/wg/sfc";
>> or, perhaps better, an IETF registered name:
>> namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC
>> number and remove this note.
>> This applies to all modules in the submission, but I will not keep
>> repeating this comment for the others.
>>
>> [RP] changed throughput to urn:TBD:...
>>
>> There are a number of reserved bits and fields in the module. I think it
>> may be wise to think this through a bit more before publishing.
>> According to the YANG RFC 6020 section 10, IETF does not allow itself to
>> ever remove a published configurable item from a module, so those
>> reserved names will have to stick forever. To make it worse, the bit
>> positions must be unique, so the bit names will have to remain r1, r2,
>> r3, ... indefinitely, even if a proper meaning and name is invented at a
>> later stage. I suggest simply not listing them in the specification in
>> this version, only adding them when they have a well defined meaning.
>>
>> [RP] okay.
>>
>> The leaf-list vni will not behave as intended. A leaf list will
>> automatically sort itself into the natural (ascending) order (unless
>> ordered-by user is specified), and can never contain repeated values
>> (such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or
>> possibly a list (not leaf list) with a position key. Or three separate
>> 8-bit leafs (vni-low, vni-med, vni-high).
>>
>> [RP] Used 3 separate 8-bit leafs for now.
>>
>>
>>
>> module service-function:
>>
>> Revision dates are YYYY-MM-DD
>>
>> [RP] Done
>>
>> Identity+identityref seems like a good way to handle this extensible
>> set. It does require YANG modeling to define new types however, so if
>> operators should be able to invent new types "on the fly", another
>> option would be to have one more config table with the operator
>> specified types, and then use a leafref to point to one of them.
>>
>> Mandatory true on a key element is not necessary, so this can be removed
>> for improved readability and brevity. This also applies to several other
>> lists, but I will not keep repeating this comment.
>>
>> [RP] Done
>>
>> There is no mandatory true on the type and ip-host-address leafs. What
>> would it mean if a sfc entry exists and has no type nor ip-host-address?
>> Should one or both be mandatory, or have a default? Note that if we
>> specify a default, that default value can never ever be changed to
>> something else according to the YANG RFC 6020, sec 10.
>>
>> [RP] This can be modified later.
>>
>>
>>
>> module service-function-chain:
>>
>> As noted by Ron Parker, this allows only a single instance of each
>> service type in each chain. With the current model, an operator has no
>> way of defining additional service types to say clone a dpi service into
>> an dpi-early and dpi-late. If this was modeled as a list with a string
>> name and a service-function-type leaf instead, the same function could
>> appear multiple times in a chain.
>>
>> [RP] I’ve made this change but in order to avoid confusion I’m relying
>> on the description to clear things up. Meaning, in the best case where
>> you have a chain where there is only one of each type the leaf “name"
>>    is redundant and in the worst case it might cause confusion, for
>> example,  if you can have a name “dpi-early” and a type “firewall”. I
>> guess we needed a list in Yang where indexes are assigned and you can
>> have repeated values, otherwise it feels I created a leaf name for no
>> purpose.
>>
>>
>>      list service-function {
>>         key "name";
>>         leaf name {
>>           type string;
>>           description
>>               "The name of the service function. This could be the
>>               same as the type or in the case where multiple service
>>               functions or the same type are used in chain, something
>>               like ingress-firewall and egress-firewall";
>>         }
>>         leaf type {
>>           type sfc-sf:service-function-type;
>>           description
>>               "The type of the service function.";
>>         }
>>         ordered-by user;
>>         description
>>           "A list of service functions that compose the service chain";
>>       }
>>
>> module service-node:
>>
>> The leafs type, transport, ip-host-address and failmode are not
>> mandatory and have no defaults. Will it be entirely clear to operators
>> what the system will do if some or all of them have no values? This is
>> not obvious to me (but that could be only me).
>>
>> [RP] I think the idea here is that at the time of creation the operator
>> could not (or might not) want to specify all these things.
>>
>> As noted by Ron Parker, type can hold only a single value. Could a
>> service node be of multiple types simultaneously?
>>
>> [RP] As I said in my reply to Ron this might be something to think
>> about. It is a trade-off of complexity vs. flexibility.
>>
>> module service-function-path:
>>
>> The service-function-path is modeled as a container. So there can be
>> only one of these in the whole system. I might be missing something, but
>> I think you want a list here, in some way.
>>
>> [RP] Good catch.  Changed.
>>
>> module service-function-forwarder:
>>
>> Once again, the leafs ip and port are not mandatory. Is that ok? Should
>> each service function have a single ip/port pair?
>>
>>
>>
>> In general, I think these modules are very small. Typically I recommend
>> to make separate modules for things that need to be versioned
>> separately, i.e. corresponding to software components. To me, these
>> modules feel very closely related, so even a single module for all of
>> this would be fine. Factoring things out into separate modules may make
>> it harder to get a full grasp of what SFC is about, repeating things in
>> module descriptions, making creation of new revisions harder.
>>
>> [RP] They were even smaller and based on opendaylight testing and
>> feedback from folks like you they have been growing in order to
>> accommodate the use-cases.  Therefore we should and decide later to
>> consolidate or keep them apart.
>>
>> /Jan Lindblad
>>
>>
>> On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com
>> <mailto:repenno@cisco.com>> wrote:
>>
>>> A new version of I-D, draft-penno-sfc-yang-02.txt
>>> has been successfully submitted by Reinaldo Penno and posted to the
>>> IETF repository.
>>>
>>> Name:           draft-penno-sfc-yang
>>> Revision:       02
>>> Title:          Yang Data Model for Service Function Chaining
>>> Document date:  2014-05-29
>>> Group:          Individual Submission
>>> Pages:          20
>>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt
>>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02
>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-02
>>> _______________________________________________
>>> sfc mailing list
>>> sfc@ietf.org <mailto:sfc@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>


From nobody Mon Jun  9 06:06:27 2014
Return-Path: <hannu.flinck@nsn.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F16C1A00AF for <sfc@ietfa.amsl.com>; Mon,  9 Jun 2014 06:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3ygoumPXIDt for <sfc@ietfa.amsl.com>; Mon,  9 Jun 2014 06:06:19 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124D11A006E for <sfc@ietf.org>; Mon,  9 Jun 2014 06:06:18 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s59D6HZ9032464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <sfc@ietf.org>; Mon, 9 Jun 2014 13:06:17 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s59D6Hca005275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Mon, 9 Jun 2014 15:06:17 +0200
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 9 Jun 2014 15:06:15 +0200
Received: from DEMUMBX011.nsn-intra.net ([169.254.11.51]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0181.006; Mon, 9 Jun 2014 15:06:15 +0200
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Network and service platforms
Thread-Index: Ac+D45ehlYgy0O+ZSWCMJbtLAeDFSA==
Date: Mon, 9 Jun 2014 13:06:15 +0000
Message-ID: <29264E37AFF9384FAEBBC9C6CD32643415D9DC2E@DEMUMBX011.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_29264E37AFF9384FAEBBC9C6CD32643415D9DC2EDEMUMBX011nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2840
X-purgate-ID: 151667::1402319177-00001564-91143611/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qGzgjsZvDsCmEY0YHCFDLigK5Ro
Subject: [sfc] Network and service platforms
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2014 13:06:22 -0000

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

Reading through network service header draft and SFC architecture draft I a=
m wondering about the meanings network and service platforms.

The architecture document mentions that "the collection of SFFs creates a s=
ervice plane... " where SFs reside. The nsh draft defines network platform =
context and service platform context. Obviously service plane equates with =
service plane? That is, the service platform context is consumed by SFF,  S=
FC and the SFC-proxy.

Network platform context is then left for SFC NFs?

If that is the case, maybe you state that in the nsh document and define th=
e mentioned platforms in the arch doc?


One more question. How does a SF communicate its changed  state to the clas=
sifier or a SF that precedes it in the chain. This would useful to LB SF bu=
t also others may benefit from it.


Best regards
Hannu




--_000_29264E37AFF9384FAEBBC9C6CD32643415D9DC2EDEMUMBX011nsnin_
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"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Reading through network service header draft and SFC architecture draf=
t I am wondering about the meanings network and service platforms.</div>
<div>&nbsp;</div>
<div>The architecture document mentions that &#8220;the collection of SFFs =
creates a service plane&#8230; &#8220; where SFs reside. The nsh draft defi=
nes network platform context and service platform context. Obviously servic=
e plane equates with service plane? That is, the service
platform context is consumed by SFF,&nbsp; SFC and the SFC-proxy. </div>
<div>&nbsp;</div>
<div>Network platform context is then left for SFC NFs? </div>
<div>&nbsp;</div>
<div>If that is the case, maybe you state that in the nsh document and defi=
ne the mentioned platforms in the arch doc?</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>One more question. How does a SF communicate its changed&nbsp; state t=
o the classifier or a SF that precedes it in the chain. This would useful t=
o LB SF but also others may benefit from it.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Best regards</div>
<div>Hannu</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_29264E37AFF9384FAEBBC9C6CD32643415D9DC2EDEMUMBX011nsnin_--


From nobody Mon Jun  9 10:41:44 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461711A028D; Mon,  9 Jun 2014 10:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYra5ysDGzUg; Mon,  9 Jun 2014 10:41:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6711A0291; Mon,  9 Jun 2014 10:41:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140609174140.12815.53636.idtracker@ietfa.amsl.com>
Date: Mon, 09 Jun 2014 10:41:40 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HCayUWp9CG5fhStBX01U1MfjUdU
Cc: sfc@ietf.org
Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-06.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2014 17:41:41 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Service Function Chaining Problem Statement
        Authors         : Paul Quinn
                          Thomas Nadeau
	Filename        : draft-ietf-sfc-problem-statement-06.txt
	Pages           : 19
	Date            : 2014-06-09

Abstract:
   This document provides an overview of the issues associated with the
   deployment of service functions (such as firewalls, load balancers)
   in large-scale environments.  The term service function chaining is
   used to describe the definition and instantiation of an ordered set
   of instances of such service functions, and the subsequent "steering"
   of traffic flows through those service functions.

   The set of enabled service function chains reflect operator service
   offerings and is designed in conjunction with application delivery
   and service and network policy.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Mon Jun  9 15:37:43 2014
Return-Path: <repenno@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD531A0263 for <sfc@ietfa.amsl.com>; Mon,  9 Jun 2014 15:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5ULeFlBQiEG for <sfc@ietfa.amsl.com>; Mon,  9 Jun 2014 15:37:38 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3F71A021D for <sfc@ietf.org>; Mon,  9 Jun 2014 15:37:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12081; q=dns/txt; s=iport; t=1402353458; x=1403563058; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=+dYU0AnCHNjMpsKUZ1dVdFh82N23tDK9KvBkTYlPurg=; b=Q9PXH76oxcUma+Yn4yDJRsTMe5by/cb5ceFYh0TPlLivjWWMxBenmR0Z Ts+Wkhs6COxSe4p66915yUAt1XMNm9F7BMKA+gBolD8XyGYM785A3R14L g1nOoL+94qi9Ez06o9Uc4MOmKcfx8SzUG4bqV0JeCwWbwuX1NYe8/k+Gq E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: An8UAOM2llOtJV2T/2dsb2JhbABQCYMNUlIHqmEBAQEBAQEFAZFUhzwBgRIWdYQDAQEBBAEBAWsGFwEIEQMBAQEBJy4LFAkIAgQBEgmIOQgFsBiZSxeFXYNjhFEoOoRBBIl4jB+ECoFCiXeIDIM8bIFD
X-IronPort-AV: E=Sophos;i="4.98,1005,1392163200"; d="scan'208";a="51624868"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 09 Jun 2014 22:37:30 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s59MbUtM017790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jun 2014 22:37:30 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 9 Jun 2014 17:37:30 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Yang Data Model for Service Function Chaining (03)
Thread-Index: AQHPg1JeYWsdvBdCA0uU83jgVhKRwJtn9v4AgAAhS3OAAGsUgIAAu1aA
Date: Mon, 9 Jun 2014 22:37:30 +0000
Message-ID: <CFBB83F4.C18D%repenno@cisco.com>
In-Reply-To: <539537A5.8090405@joelhalpern.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.21.114.200]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <D3B8AAA1A4E68D47A081CE1E04377E48@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IcRlZkyvrK-4ltP3jNvo5Rkc-2c
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2014 22:37:41 -0000

Inline with [RP]

On 6/8/14, 9:27 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

>It would seem that a starting point would be to replace the address and
>port with a reference to a service functiuon?


[RP] Then the service function needs to have the locator. We should
provide for augmentation (read, Yang list) so that many types of locators
are possible.

>
>Also, should we have a distinction between a kind of service function as
>it appears in a service chian, and a location we can direct packets to
>for a service function, as it appears in the service path.  (I hesitate
>to use the word instance since while the thing appears as an isntance to
>the path, it may actually be a cluster, etc...)


[RP] I=B9ve been wrestling with this issue for some time that=B9s why I put
the locator inside SFF originally. In my mind the locator means =B3if you
send packets to this locator, it will reach this service function. It
might not reach it directly, but it will get there=B2. Therefore SFF does
not need to bother about the specifics of load-blanacers, proxy services,
etc

>
>Yours,
>Joel
>
>On 6/8/14, 11:04 PM, Reinaldo Penno (repenno) wrote:
>> Sure, let's work on it.
>>
>> Do you want to propose something that matches your expectations and
>>then we can refine it?
>>
>> thanks,
>>
>> Reinaldo
>>
>> ________________________________________
>> From: Joel M. Halpern [jmh@joelhalpern.com]
>> Sent: Sunday, June 08, 2014 1:04 PM
>> To: Reinaldo Penno (repenno); sfc@ietf.org
>> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
>>
>> The definition of service function forwarder here seems MUCH too
>> specific.  I would think we would want a generalized definition, and
>> then an extension for the ase where the forwarder reachs the service
>> functions based on IP address and port number.
>>
>> Yours,
>> Joel
>>
>> On 6/8/14, 3:46 PM, Reinaldo Penno (repenno) wrote:
>>> New version of SFC Yang data models.
>>>
>>> thanks to Jan Lindblad, Ron Parker and other reviewers.
>>>
>>>
>>> A new version of I-D, draft-penno-sfc-yang-03.txt
>>> has been successfully submitted by Reinaldo Penno and posted to the
>>> IETF repository.
>>>
>>> Name:           draft-penno-sfc-yang
>>> Revision:       03
>>> Title:          Yang Data Model for Service Function Chaining
>>> Document date:  2014-06-06
>>> Group:          Individual Submission
>>> Pages:          21
>>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt
>>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-03
>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-03
>>>
>>> Abstract:
>>>      This document defines a YANG data model that can be used to
>>>configure
>>>      and manage Service Function Chains.
>>>=20
>>>------------------------------------------------------------------------
>>> *From:* sfc [sfc-bounces@ietf.org] on behalf of Reinaldo Penno
>>>(repenno)
>>> *Sent:* Friday, June 06, 2014 7:28 PM
>>> *To:* Jan Lindblad
>>> *Cc:* sfc@ietf.org
>>> *Subject:* Re: [sfc] Yang Data Model for Service Function Chaining (02)
>>>
>>> Hello Jan,
>>>
>>> Thanks for the review, I will submit a new version shortly.
>>>
>>> Inline with [RP]
>>>
>>> From: Jan Lindblad <janl@tail-f.com <mailto:janl@tail-f.com>>
>>> Date: Tuesday, June 3, 2014 at 2:05 AM
>>> To: Cisco Employee <repenno@cisco.com <mailto:repenno@cisco.com>>
>>> Cc: "sfc@ietf.org <mailto:sfc@ietf.org>" <sfc@ietf.org
>>> <mailto:sfc@ietf.org>>
>>> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)
>>>
>>> Reinaldo,
>>>
>>> Good work! I made a quick review of your proposed SFC YANG module. I
>>> have been monitoring this list for a couple of weeks only, so please
>>> bear with any misconceptions on my part. I'm a YANG Doctor, however, so
>>> I was hoping I could contribute with a few YANG-level suggestions or
>>> options for you.
>>>
>>>
>>>
>>> module vxlan-gpe:
>>>
>>> The namespace declaration in each of the modules starts with
>>> urn:cisco:... Namespaces on this form are supposed to be registered
>>>with
>>> IANA.=20
>>>http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>>>
>>> I suggest either changing this to an IETF reserved name, or move it to
>>>a
>>> proper cisco-namespace, e.g.:
>>> namespace "http://cisco.com/ns/ietf/wg/sfc";
>>> or, perhaps better, an IETF registered name:
>>> namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC
>>> number and remove this note.
>>> This applies to all modules in the submission, but I will not keep
>>> repeating this comment for the others.
>>>
>>> [RP] changed throughput to urn:TBD:...
>>>
>>> There are a number of reserved bits and fields in the module. I think
>>>it
>>> may be wise to think this through a bit more before publishing.
>>> According to the YANG RFC 6020 section 10, IETF does not allow itself
>>>to
>>> ever remove a published configurable item from a module, so those
>>> reserved names will have to stick forever. To make it worse, the bit
>>> positions must be unique, so the bit names will have to remain r1, r2,
>>> r3, ... indefinitely, even if a proper meaning and name is invented at
>>>a
>>> later stage. I suggest simply not listing them in the specification in
>>> this version, only adding them when they have a well defined meaning.
>>>
>>> [RP] okay.
>>>
>>> The leaf-list vni will not behave as intended. A leaf list will
>>> automatically sort itself into the natural (ascending) order (unless
>>> ordered-by user is specified), and can never contain repeated values
>>> (such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or
>>> possibly a list (not leaf list) with a position key. Or three separate
>>> 8-bit leafs (vni-low, vni-med, vni-high).
>>>
>>> [RP] Used 3 separate 8-bit leafs for now.
>>>
>>>
>>>
>>> module service-function:
>>>
>>> Revision dates are YYYY-MM-DD
>>>
>>> [RP] Done
>>>
>>> Identity+identityref seems like a good way to handle this extensible
>>> set. It does require YANG modeling to define new types however, so if
>>> operators should be able to invent new types "on the fly", another
>>> option would be to have one more config table with the operator
>>> specified types, and then use a leafref to point to one of them.
>>>
>>> Mandatory true on a key element is not necessary, so this can be
>>>removed
>>> for improved readability and brevity. This also applies to several
>>>other
>>> lists, but I will not keep repeating this comment.
>>>
>>> [RP] Done
>>>
>>> There is no mandatory true on the type and ip-host-address leafs. What
>>> would it mean if a sfc entry exists and has no type nor
>>>ip-host-address?
>>> Should one or both be mandatory, or have a default? Note that if we
>>> specify a default, that default value can never ever be changed to
>>> something else according to the YANG RFC 6020, sec 10.
>>>
>>> [RP] This can be modified later.
>>>
>>>
>>>
>>> module service-function-chain:
>>>
>>> As noted by Ron Parker, this allows only a single instance of each
>>> service type in each chain. With the current model, an operator has no
>>> way of defining additional service types to say clone a dpi service
>>>into
>>> an dpi-early and dpi-late. If this was modeled as a list with a string
>>> name and a service-function-type leaf instead, the same function could
>>> appear multiple times in a chain.
>>>
>>> [RP] I=B9ve made this change but in order to avoid confusion I=B9m rely=
ing
>>> on the description to clear things up. Meaning, in the best case where
>>> you have a chain where there is only one of each type the leaf =B3name"
>>>    is redundant and in the worst case it might cause confusion, for
>>> example,  if you can have a name =B3dpi-early=B2 and a type =B3firewall=
=B2. I
>>> guess we needed a list in Yang where indexes are assigned and you can
>>> have repeated values, otherwise it feels I created a leaf name for no
>>> purpose.
>>>
>>>
>>>      list service-function {
>>>         key "name";
>>>         leaf name {
>>>           type string;
>>>           description
>>>               "The name of the service function. This could be the
>>>               same as the type or in the case where multiple service
>>>               functions or the same type are used in chain, something
>>>               like ingress-firewall and egress-firewall";
>>>         }
>>>         leaf type {
>>>           type sfc-sf:service-function-type;
>>>           description
>>>               "The type of the service function.";
>>>         }
>>>         ordered-by user;
>>>         description
>>>           "A list of service functions that compose the service chain";
>>>       }
>>>
>>> module service-node:
>>>
>>> The leafs type, transport, ip-host-address and failmode are not
>>> mandatory and have no defaults. Will it be entirely clear to operators
>>> what the system will do if some or all of them have no values? This is
>>> not obvious to me (but that could be only me).
>>>
>>> [RP] I think the idea here is that at the time of creation the operator
>>> could not (or might not) want to specify all these things.
>>>
>>> As noted by Ron Parker, type can hold only a single value. Could a
>>> service node be of multiple types simultaneously?
>>>
>>> [RP] As I said in my reply to Ron this might be something to think
>>> about. It is a trade-off of complexity vs. flexibility.
>>>
>>> module service-function-path:
>>>
>>> The service-function-path is modeled as a container. So there can be
>>> only one of these in the whole system. I might be missing something,
>>>but
>>> I think you want a list here, in some way.
>>>
>>> [RP] Good catch.  Changed.
>>>
>>> module service-function-forwarder:
>>>
>>> Once again, the leafs ip and port are not mandatory. Is that ok? Should
>>> each service function have a single ip/port pair?
>>>
>>>
>>>
>>> In general, I think these modules are very small. Typically I recommend
>>> to make separate modules for things that need to be versioned
>>> separately, i.e. corresponding to software components. To me, these
>>> modules feel very closely related, so even a single module for all of
>>> this would be fine. Factoring things out into separate modules may make
>>> it harder to get a full grasp of what SFC is about, repeating things in
>>> module descriptions, making creation of new revisions harder.
>>>
>>> [RP] They were even smaller and based on opendaylight testing and
>>> feedback from folks like you they have been growing in order to
>>> accommodate the use-cases.  Therefore we should and decide later to
>>> consolidate or keep them apart.
>>>
>>> /Jan Lindblad
>>>
>>>
>>> On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com
>>> <mailto:repenno@cisco.com>> wrote:
>>>
>>>> A new version of I-D, draft-penno-sfc-yang-02.txt
>>>> has been successfully submitted by Reinaldo Penno and posted to the
>>>> IETF repository.
>>>>
>>>> Name:           draft-penno-sfc-yang
>>>> Revision:       02
>>>> Title:          Yang Data Model for Service Function Chaining
>>>> Document date:  2014-05-29
>>>> Group:          Individual Submission
>>>> Pages:          20
>>>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt
>>>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>>>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02
>>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-02
>>>> _______________________________________________
>>>> sfc mailing list
>>>> sfc@ietf.org <mailto:sfc@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> sfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>


From nobody Mon Jun  9 15:51:47 2014
Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBA01A01DD for <sfc@ietfa.amsl.com>; Mon,  9 Jun 2014 15:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO4OGGlG7tIW for <sfc@ietfa.amsl.com>; Mon,  9 Jun 2014 15:51:42 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8081A02B2 for <sfc@ietf.org>; Mon,  9 Jun 2014 15:51:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1FF362407A1; Mon,  9 Jun 2014 15:51:42 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DAC3924073D; Mon,  9 Jun 2014 15:51:40 -0700 (PDT)
Message-ID: <53963A80.8050809@joelhalpern.com>
Date: Mon, 09 Jun 2014 18:51:44 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>,  "sfc@ietf.org" <sfc@ietf.org>
References: <CFBB83F4.C18D%repenno@cisco.com>
In-Reply-To: <CFBB83F4.C18D%repenno@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8cizspLX0JbWXXC_PyRtvN8oMLg
Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2014 22:51:44 -0000

I see your point.  In fact, since the relevant forwarding information 
for an SFF may be a physical port id (possibly with a MAC address) or 
even a logical port ID, it does seem that attaching the information, as 
an extensible list of alternatives, to the SFF may be the right way to 
do it.

Yours,
Joel

On 6/9/14, 6:37 PM, Reinaldo Penno (repenno) wrote:
> Inline with [RP]
>
> On 6/8/14, 9:27 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:
>
>> It would seem that a starting point would be to replace the address and
>> port with a reference to a service functiuon?
>
>
> [RP] Then the service function needs to have the locator. We should
> provide for augmentation (read, Yang list) so that many types of locators
> are possible.
>
>>
>> Also, should we have a distinction between a kind of service function as
>> it appears in a service chian, and a location we can direct packets to
>> for a service function, as it appears in the service path.  (I hesitate
>> to use the word instance since while the thing appears as an isntance to
>> the path, it may actually be a cluster, etc...)
>
>
> [RP] I¹ve been wrestling with this issue for some time that¹s why I put
> the locator inside SFF originally. In my mind the locator means ³if you
> send packets to this locator, it will reach this service function. It
> might not reach it directly, but it will get there². Therefore SFF does
> not need to bother about the specifics of load-blanacers, proxy services,
> etc
>
>>
>> Yours,
>> Joel
>>
>> On 6/8/14, 11:04 PM, Reinaldo Penno (repenno) wrote:
>>> Sure, let's work on it.
>>>
>>> Do you want to propose something that matches your expectations and
>>> then we can refine it?
>>>
>>> thanks,
>>>
>>> Reinaldo
>>>
>>> ________________________________________
>>> From: Joel M. Halpern [jmh@joelhalpern.com]
>>> Sent: Sunday, June 08, 2014 1:04 PM
>>> To: Reinaldo Penno (repenno); sfc@ietf.org
>>> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (03)
>>>
>>> The definition of service function forwarder here seems MUCH too
>>> specific.  I would think we would want a generalized definition, and
>>> then an extension for the ase where the forwarder reachs the service
>>> functions based on IP address and port number.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 6/8/14, 3:46 PM, Reinaldo Penno (repenno) wrote:
>>>> New version of SFC Yang data models.
>>>>
>>>> thanks to Jan Lindblad, Ron Parker and other reviewers.
>>>>
>>>>
>>>> A new version of I-D, draft-penno-sfc-yang-03.txt
>>>> has been successfully submitted by Reinaldo Penno and posted to the
>>>> IETF repository.
>>>>
>>>> Name:           draft-penno-sfc-yang
>>>> Revision:       03
>>>> Title:          Yang Data Model for Service Function Chaining
>>>> Document date:  2014-06-06
>>>> Group:          Individual Submission
>>>> Pages:          21
>>>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-03.txt
>>>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>>>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-03
>>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-03
>>>>
>>>> Abstract:
>>>>       This document defines a YANG data model that can be used to
>>>> configure
>>>>       and manage Service Function Chains.
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* sfc [sfc-bounces@ietf.org] on behalf of Reinaldo Penno
>>>> (repenno)
>>>> *Sent:* Friday, June 06, 2014 7:28 PM
>>>> *To:* Jan Lindblad
>>>> *Cc:* sfc@ietf.org
>>>> *Subject:* Re: [sfc] Yang Data Model for Service Function Chaining (02)
>>>>
>>>> Hello Jan,
>>>>
>>>> Thanks for the review, I will submit a new version shortly.
>>>>
>>>> Inline with [RP]
>>>>
>>>> From: Jan Lindblad <janl@tail-f.com <mailto:janl@tail-f.com>>
>>>> Date: Tuesday, June 3, 2014 at 2:05 AM
>>>> To: Cisco Employee <repenno@cisco.com <mailto:repenno@cisco.com>>
>>>> Cc: "sfc@ietf.org <mailto:sfc@ietf.org>" <sfc@ietf.org
>>>> <mailto:sfc@ietf.org>>
>>>> Subject: Re: [sfc] Yang Data Model for Service Function Chaining (02)
>>>>
>>>> Reinaldo,
>>>>
>>>> Good work! I made a quick review of your proposed SFC YANG module. I
>>>> have been monitoring this list for a couple of weeks only, so please
>>>> bear with any misconceptions on my part. I'm a YANG Doctor, however, so
>>>> I was hoping I could contribute with a few YANG-level suggestions or
>>>> options for you.
>>>>
>>>>
>>>>
>>>> module vxlan-gpe:
>>>>
>>>> The namespace declaration in each of the modules starts with
>>>> urn:cisco:... Namespaces on this form are supposed to be registered
>>>> with
>>>> IANA.
>>>> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>>>>
>>>> I suggest either changing this to an IETF reserved name, or move it to
>>>> a
>>>> proper cisco-namespace, e.g.:
>>>> namespace "http://cisco.com/ns/ietf/wg/sfc";
>>>> or, perhaps better, an IETF registered name:
>>>> namespace "urn:ietf:rfc:XXXX"; // RFC Ed.: Replace XXXX with actual RFC
>>>> number and remove this note.
>>>> This applies to all modules in the submission, but I will not keep
>>>> repeating this comment for the others.
>>>>
>>>> [RP] changed throughput to urn:TBD:...
>>>>
>>>> There are a number of reserved bits and fields in the module. I think
>>>> it
>>>> may be wise to think this through a bit more before publishing.
>>>> According to the YANG RFC 6020 section 10, IETF does not allow itself
>>>> to
>>>> ever remove a published configurable item from a module, so those
>>>> reserved names will have to stick forever. To make it worse, the bit
>>>> positions must be unique, so the bit names will have to remain r1, r2,
>>>> r3, ... indefinitely, even if a proper meaning and name is invented at
>>>> a
>>>> later stage. I suggest simply not listing them in the specification in
>>>> this version, only adding them when they have a well defined meaning.
>>>>
>>>> [RP] okay.
>>>>
>>>> The leaf-list vni will not behave as intended. A leaf list will
>>>> automatically sort itself into the natural (ascending) order (unless
>>>> ordered-by user is specified), and can never contain repeated values
>>>> (such as [1,1,1]). I'd suggest you use a 24-bit integer instead. Or
>>>> possibly a list (not leaf list) with a position key. Or three separate
>>>> 8-bit leafs (vni-low, vni-med, vni-high).
>>>>
>>>> [RP] Used 3 separate 8-bit leafs for now.
>>>>
>>>>
>>>>
>>>> module service-function:
>>>>
>>>> Revision dates are YYYY-MM-DD
>>>>
>>>> [RP] Done
>>>>
>>>> Identity+identityref seems like a good way to handle this extensible
>>>> set. It does require YANG modeling to define new types however, so if
>>>> operators should be able to invent new types "on the fly", another
>>>> option would be to have one more config table with the operator
>>>> specified types, and then use a leafref to point to one of them.
>>>>
>>>> Mandatory true on a key element is not necessary, so this can be
>>>> removed
>>>> for improved readability and brevity. This also applies to several
>>>> other
>>>> lists, but I will not keep repeating this comment.
>>>>
>>>> [RP] Done
>>>>
>>>> There is no mandatory true on the type and ip-host-address leafs. What
>>>> would it mean if a sfc entry exists and has no type nor
>>>> ip-host-address?
>>>> Should one or both be mandatory, or have a default? Note that if we
>>>> specify a default, that default value can never ever be changed to
>>>> something else according to the YANG RFC 6020, sec 10.
>>>>
>>>> [RP] This can be modified later.
>>>>
>>>>
>>>>
>>>> module service-function-chain:
>>>>
>>>> As noted by Ron Parker, this allows only a single instance of each
>>>> service type in each chain. With the current model, an operator has no
>>>> way of defining additional service types to say clone a dpi service
>>>> into
>>>> an dpi-early and dpi-late. If this was modeled as a list with a string
>>>> name and a service-function-type leaf instead, the same function could
>>>> appear multiple times in a chain.
>>>>
>>>> [RP] I¹ve made this change but in order to avoid confusion I¹m relying
>>>> on the description to clear things up. Meaning, in the best case where
>>>> you have a chain where there is only one of each type the leaf ³name"
>>>>     is redundant and in the worst case it might cause confusion, for
>>>> example,  if you can have a name ³dpi-early² and a type ³firewall². I
>>>> guess we needed a list in Yang where indexes are assigned and you can
>>>> have repeated values, otherwise it feels I created a leaf name for no
>>>> purpose.
>>>>
>>>>
>>>>       list service-function {
>>>>          key "name";
>>>>          leaf name {
>>>>            type string;
>>>>            description
>>>>                "The name of the service function. This could be the
>>>>                same as the type or in the case where multiple service
>>>>                functions or the same type are used in chain, something
>>>>                like ingress-firewall and egress-firewall";
>>>>          }
>>>>          leaf type {
>>>>            type sfc-sf:service-function-type;
>>>>            description
>>>>                "The type of the service function.";
>>>>          }
>>>>          ordered-by user;
>>>>          description
>>>>            "A list of service functions that compose the service chain";
>>>>        }
>>>>
>>>> module service-node:
>>>>
>>>> The leafs type, transport, ip-host-address and failmode are not
>>>> mandatory and have no defaults. Will it be entirely clear to operators
>>>> what the system will do if some or all of them have no values? This is
>>>> not obvious to me (but that could be only me).
>>>>
>>>> [RP] I think the idea here is that at the time of creation the operator
>>>> could not (or might not) want to specify all these things.
>>>>
>>>> As noted by Ron Parker, type can hold only a single value. Could a
>>>> service node be of multiple types simultaneously?
>>>>
>>>> [RP] As I said in my reply to Ron this might be something to think
>>>> about. It is a trade-off of complexity vs. flexibility.
>>>>
>>>> module service-function-path:
>>>>
>>>> The service-function-path is modeled as a container. So there can be
>>>> only one of these in the whole system. I might be missing something,
>>>> but
>>>> I think you want a list here, in some way.
>>>>
>>>> [RP] Good catch.  Changed.
>>>>
>>>> module service-function-forwarder:
>>>>
>>>> Once again, the leafs ip and port are not mandatory. Is that ok? Should
>>>> each service function have a single ip/port pair?
>>>>
>>>>
>>>>
>>>> In general, I think these modules are very small. Typically I recommend
>>>> to make separate modules for things that need to be versioned
>>>> separately, i.e. corresponding to software components. To me, these
>>>> modules feel very closely related, so even a single module for all of
>>>> this would be fine. Factoring things out into separate modules may make
>>>> it harder to get a full grasp of what SFC is about, repeating things in
>>>> module descriptions, making creation of new revisions harder.
>>>>
>>>> [RP] They were even smaller and based on opendaylight testing and
>>>> feedback from folks like you they have been growing in order to
>>>> accommodate the use-cases.  Therefore we should and decide later to
>>>> consolidate or keep them apart.
>>>>
>>>> /Jan Lindblad
>>>>
>>>>
>>>> On 30 maj 2014, at 09:57, Reinaldo Penno (repenno) <repenno@cisco.com
>>>> <mailto:repenno@cisco.com>> wrote:
>>>>
>>>>> A new version of I-D, draft-penno-sfc-yang-02.txt
>>>>> has been successfully submitted by Reinaldo Penno and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:           draft-penno-sfc-yang
>>>>> Revision:       02
>>>>> Title:          Yang Data Model for Service Function Chaining
>>>>> Document date:  2014-05-29
>>>>> Group:          Individual Submission
>>>>> Pages:          20
>>>>> URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-02.txt
>>>>> Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/
>>>>> Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-02
>>>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-02
>>>>> _______________________________________________
>>>>> sfc mailing list
>>>>> sfc@ietf.org <mailto:sfc@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> sfc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>
>
>


From nobody Tue Jun 10 03:22:10 2014
Return-Path: <bill.wu@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FF61A0037; Tue, 10 Jun 2014 03:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4aHLatOpmvz; Tue, 10 Jun 2014 03:22:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A255D1A0035; Tue, 10 Jun 2014 03:22:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG49607; Tue, 10 Jun 2014 10:22:05 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 11:22:04 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 18:21:59 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "nvo3@ietf.org" <nvo3@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Thread-Topic: Introduction to TIME Mailing List
Thread-Index: Ac+Ed/EqiWfsJ33vSgy5XLhDzjJJGgAHZNhA
Date: Tue, 10 Jun 2014 10:21:57 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA84549706@nkgeml501-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.180]
Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ppg_H_A75TvJrY99rf60ojj8A0Q
Subject: Re: [sfc] Introduction to TIME Mailing List
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jun 2014 10:22:09 -0000

--_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_
Content-Type: multipart/alternative;
	boundary="_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_"

--_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

RllJLg0Kt6K8/sjLOiBUaW1lIFttYWlsdG86dGltZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFFp
biBXdQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjEwyNUgMTQ6NDgNCsrVvP7IyzogdGltZUBpZXRmLm9y
Zw0Ks63LzTogUm9tYXNjYW51LCBEYW4gKERhbik7IE1pc2hhZWwgV2V4bGVyDQrW98ziOiBbVGlt
ZV0gSW50cm9kdWN0aW9uIHRvIFRJTUUgTWFpbGluZyBMaXN0DQoNCkRlYXIgYWxsLA0KDQoNClRo
aXMgaXMgdG8gaW50cm9kdWNlIHRoZSBUSU1FIG1haWxpbmcgbGlzdC4gVElNRSBzdGFuZHMgZm9y
IKGwVHJhbnNwb3J0IEluZGVwZW5kZW50IE9BTSBpbiBNdWx0aS1MYXllciBOZXR3b3JrIEVudGl0
eaGxIC4NCg0KDQpUaGlzIG1haWxpbmcgbGlzdCBpcyBuZXdseSBjcmVhdGVkIGFzIGEgcmVzdWx0
IG9mIGEgQk9GIHJlcXVlc3QgcHJvcG9zYWwgdG8gT1BTIEFyZWEgcmVjZW50bHkuIEhlcmUgaXMg
YW4gaW5pdGlhbCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbSBpbg0KDQpodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dy1vcHNhd2ctbXVsdGktbGF5ZXItb2FtLTAwDQph
bmQgd2UgYXJlIGxvb2tpbmcgZm9yIGRpc2N1c3Npb24gYW5kIGZlZWRiYWNrIG9uIHRoaXMgbGlz
dCwgYXMgd2VsbCBhcyBleHBlY3RpbmcgdG8gaGFtbWVyIG91dCBhIGNvbmNyZXRlIHNjb3BlIGFu
ZCBnZXQgdGhlIGZpcnN0IHZlcnNpb24gb2YgZHJhZnQNCmNoYXJ0ZXIgY29taW5nIG91dCB0aHJv
dWdoIHRoaXMgZGlzY3Vzc2lvbiAuDQoNCkJhY2tncm91bmQ6DQoNCiAgVGhlIGJhc2ljIGNvbmNl
cHRzIG9mIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFuY2UgKE9BTSkg
YW5kIHRoZQ0KICAgZnVuY3Rpb25hbCByb2xlcyBpbiBtb25pdG9yaW5nIGFuZCBkaWFnbm9zaW5n
IHRoZSBiZWhhdmlvciBvZiB0ZWxlY29tbXVuaWNhdGlvbnMgbmV0d29ya3MNCiAgIGhhdmUgYmVl
biBsb25nIHRlcm0gc3R1ZGllZCBhdCB0aGUgTGF5ZXIgMSYyICYgTGF5ZXIgMyBsZXZlbHMuICBU
aGUgY3VycmVudCBwcmFjdGljZSBpcyB0aGF0DQogICBtYW55IHRlY2hub2xvZ2llcyBhbmQgbGF5
ZXJzIGhhdmUgdGhlaXIgb3duIE9BTSBwcm90b2NvbHMuICAgVGhlcmUgaXMgbGl0dGxlIG9yIG5v
DQogICByZS11c2Ugb2Ygc29mdHdhcmUgYW5kIGhhcmR3YXJlIGZvciBlYWNoIGV4aXN0aW5nIE9B
TSBwcm90b2NvbC4gVmVuZG9ycyBhbmQgb3BlcmF0b3JzIHdhc3RlDQphIGxvdCB0aHJvdWdoIHRo
ZSB3aG9sZSBPQU0gbGlmZS1jeWNsZSB3aGVuIGEgbmV3IHRlY2hub2xvZ3kgaXMgaW50cm9kdWNl
ZC4gSW50ZWdyYXRpb24gb2YgT0FNDQphY3Jvc3MgbXVsdGlwbGUgdGVjaG5vbG9naWVzIGlzIGV4
dHJlbWVseSBkaWZmaWN1bHQuIFdoZW4gaGF2aW5nIG5ldHdvcmtzIHdpdGggbW9yZSB0aGFuIG9u
ZSB0ZWNobm9sb2d5LA0KbWFpbnRlbmFuY2UgYW5kIHRyb3VibGVzaG9vdGluZyBhcmUgZG9uZSBw
ZXIgdGVjaG5vbG9neQ0KICAgYW5kIGxheWVyLCBvcGVyYXRpb24gcHJvY2VzcyBjYW4gYmUgdmVy
eSBjdW1iZXJzb21lLiBJbiBtYW55IGNhc2VzIGl0IGlzIGRlc2lyYWJsZSB0byBoYXZlIGENCiAg
IGdlbmVyaWMgT0FNIHRvIGNvdmVyIGhldGVyb2dlbmVvdXMgbmV0d29ya2luZyB0ZWNobm9sb2dp
ZXMuIEdlbmVyaWMgT0FNIHRvb2xzIHNob3VsZCBiZQ0KICAgZGVwbG95ZWQgb3ZlciB2YXJpb3Vz
IGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLCBhbmQgaW4gdmFyaW91cyBtZWRpdW0gdHlwZXMuDQoN
CiAgIEFuIGV4YW1wbGUgb2YgYW4gZW52aXJvbm1lbnQgaW4gd2hpY2ggYSBnZW5lcmljIGFuZCBp
bnRlZ3JhdGVkIE9BTSBwcm90b2NvbCB3b3VsZCBiZQ0KICAgdmFsdWFibGUgaXMgU2VydmljZSBG
dW5jdGlvbiBDaGFpbmluZy4gQSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIGlzIGNvbXBvc2Vk
IGJ5IGEgc2VyaWVzIG9mDQogICBzZXJ2aWNlIEZ1bmN0aW9ucywgdGhhdCBjYW4gYWN0IGluIGRp
ZmZlcmVudCBsYXllcnMgYnV0IHByb3ZpZGluZyBhbiBlbmQtdG8tZW5kIGNoYWluIG9yIHBhdGgN
CiAgIGZyb20gYSBzb3VyY2UgdG8gZGVzdGluYXRpb24gaW4gYSBnaXZlbiBvcmRlci4gIEluIHNl
cnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgRW52aXJvbm1lbnQsIGl0IGlzDQogICBuZWNlc3Nhcnkg
dG8gcHJvdmlkZSBlbmQgdG8gZW5kIE9BTSBhY3Jvc3MgY2VydGFpbiBvciBhbGwgZW50aXRpZXMg
YW5kIGludm9sdmluZyBtYW55IGxheWVycy4NCiAgIE9BTSBpbmZvcm1hdGlvbiBzaG91bGQgYmUg
ZXhjaGFuZ2VkIGJldHdlZW4gc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IGxheWVycyB3
aGlsZQ0KICAgdXNpbmcgdmFyaW91cyBlbmNhcHN1bGF0aW5nIHByb3RvY29scy4gIEluIHNvbWUg
Y2FzZXMgT0FNIHNob3VsZCBjcm9zcyBkaWZmZXJlbnQNCiAgIGFkbWluaXN0cmF0aW9uIGFuZC9v
ciBtYWludGVuYW5jZSBkb21haW5zLg0KDQpUaGUgcHVycG9zZSBvZiB0aGUgbGlzdDoNCg0KICAg
MS51bmRlcnN0YW5kaW5nIGFuZCBkaXNjdXNzaW5nIHRoZSB0aW1lcyB3aGVuIGFuIE9BTQ0KICAg
cHJvdG9jb2wgY2FuIGJlIHR1bmVkIGFuZCBvcHRpbWlzZWQgZm9yIGEgc3BlY2lmaWMgZGF0YSBw
bGFuZSAoZm9yIGV4YW1wbGUsIE9BTSBpbiBhIHBhY2tldA0KICAgbmV0d29yayBjYW4gYmUgdmVy
eSBkaWZmZXJlbnQgZnJvbSBPQU0gaW4gYSBjaXJjdWl0IHN3aXRjaGVkIG5ldHdvcmsgYmVjYXVz
ZSBvZiB0aGUNCiAgIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIG5ldHdvcmspDQoN
CjIuYW5kIHNlZWtpbmcgdGhlIGJlc3Qgd2F5czoNCg0KICAgICAgICBPIEV4Y2hhbmdlIE9BTSBp
bmZvcm1hdGlvbiBhdCB0aGUgc2VydmljZSBsYXllciBhdG9wIG9mIGxheWVyIDMNCg0KTyBBYnN0
cmFjdCBPQU0gaW5mb3JtYXRpb24gY29tbW9uIHRvIGRpZmZlcmVudCBsYXllcg0KDQpPIFByb3Zp
ZGUgdGhlbSB2aWEgdW5pZmllZCBpbnRlcmZhY2UgdG8gbWFuYWdlbWVudCBlbnRpdGllcy4NCg0K
TyBTZXQgdXAgTWFpbnRlbmFuY2UgRG9tYWlucyAoTUQpIGFuZCBNYWludGVuYW5jZSBJbnRlcm1l
ZGlhdGUgUG9pbnRzIChNSVApDQoNCk8gRW5hYmxlIE9BTSBmdW5jdGlvbiBhdCBkaWZmZXJlbnQg
bGF5ZXIgaW4gdGhlIG11bHRpLWxheWVyIG5ldHdvcmsNCg0KTyBBY3RpdmF0ZSBPQU0gZnVuY3Rp
b24gYSBkaWZmZXJlbnQgbGF5ZXIgYW5kIHByb3ZpZGUgcmVzdWx0cyB0byBtYW5hZ2VtZW50IGVu
dGl0eQ0KDQpUaGlzIG1haWxpbmcgbGlzdCBpcyBpbnRlbmRlZCB0byBlbmFibGUgZGlzY3Vzc2lv
biBvZiB0aGUgYXJjaGl0ZWN0dXJlLCB1c2UtY2FzZXMvYXBwbGljYWJpbGl0eSwgYW5kDQpyZXF1
aXJlbWVudHMgdGhhdCBwcm92aWRlIGdlbmVyaWMgYW5kIGludGVncmF0ZWQgT0FNIGNvdmVyaW5n
IHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIHRlY2hub2xvZ2llcy4NCg0KTyBBbmFseXNl
IGFuZCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbnQgbW90aXZhdGlvbnMgYW5kIG9wcG9ydHVuaXRp
ZXMgZm9yIG9wdGltaXNhdGlvbiBvZiBPQU0gaW4gZGlmZmVyZW50DQp0ZWNobm9sb2d5IG5ldHdv
cmtzLCBhbmQgdGhlIHRyYWRlLW9mZnMgYmV0d2VlbiB0aG9zZSBvcHRpbWlzYXRpb25zIGFuZCB0
aGUNCiBvdmVyYWxsIGFkdmFudGFnZSBvZiBhIGdlbmVyaWMgT0FNIG1lY2hhbmlzbS4NCg0KTyBT
ZXQgb3V0IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgYXJjaGl0ZWN0dXJlIGZvciB0aGUNCiAg
ICAgVHJhbnNwb3J0IEluZGVwZW5kZW50IE9BTSBpbiB0aGUgbXVsdGktbGF5ZXIgbmV0d29yayBh
bmQgb3V0bGluZXMgdGhlIHByb2JsZW1zDQogICAgIGVuY291bnRlcmVkIHdpdGggZXhpc3Rpbmcg
T0FNIHByb3RvY29sIHZhcmlldHkgYW5kIHRoZWlyIGltcGFjdCBvbiBpbnRyb2R1Y3Rpb24gb2Yg
bmV3IHRlY2hub2xvZ2llcy4NCg0KWW91IGNhbiBzdWJzY3JpYmUgdG8gdGhlIGxpc3QgYXQ6IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGltZS4NCg0KDQpUbyBwb3N0IGEg
bWVzc2FnZSB0byBhbGwgdGhlIGxpc3QgbWVtYmVycywgc2VuZCBlbWFpbCB0byB0aW1lIGF0IGll
dGYub3JnLg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KUWluJkRhbg0K

--_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<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:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"\7EAF\6587\672C Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
span.Char
	{mso-style-name:"\7EAF\6587\672C Char";
	mso-style-priority:99;
	mso-style-link:\7EAF\6587\672C;
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
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:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.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" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D">FYI.<o:=
p></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" align=3D"left" style=3D"text-align:left"><b><span st=
yle=3D"font-size:10.0pt;font-family:SimSun">=B7=A2=BC=FE=C8=CB<span lang=3D=
"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;f=
ont-family:SimSun"> Time [mailto:time-bounces@ietf.org]
</span><b><span style=3D"font-size:10.0pt;font-family:SimSun">=B4=FA=B1=ED =
</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:SimSu=
n">Qin Wu<br>
</span><b><span style=3D"font-size:10.0pt;font-family:SimSun">=B7=A2=CB=CD=
=CA=B1=BC=E4<span lang=3D"EN-US">:</span></span></b><span lang=3D"EN-US" st=
yle=3D"font-size:10.0pt;font-family:SimSun"> 2014</span><span style=3D"font=
-size:10.0pt;font-family:SimSun">=C4=EA<span lang=3D"EN-US">6</span>=D4=C2<=
span lang=3D"EN-US">10</span>=C8=D5<span lang=3D"EN-US">
 14:48<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> time@ietf.org<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Romascanu, Dan (Dan); Mishael Wexler<br>
</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> [Time] Introduction to TIME Mailing List<o:p></o:p></span></span></p>
</div>
</div>
<p class=3D"MsoNormal" align=3D"left" style=3D"text-align:left"><span lang=
=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Dear all,<o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">This is to introduce the TIME m=
ailing list. TIME stands for =A1=B0Transport Independent OAM in Multi-Layer=
 Network Entity=A1=B1 .<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">This mailing list is newly c=
reated as a result of a BOF request proposal to OPS Area recently. Here is =
an initial description of the problem in
<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><a href=3D"https://datatrack=
er.ietf.org/doc/draft-ww-opsawg-multi-layer-oam-00">https://datatracker.iet=
f.org/doc/draft-ww-opsawg-multi-layer-oam-00</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">and we are looking for discussi=
on and feedback on this list, as well as expecting to hammer out a concrete=
 scope and get the first version of draft
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">charter coming out through this=
 discussion .<o:p></o:p></span></p>
<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">Background:<o:p></o:p></span></=
p>
<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">&nbsp; The basic concepts of Op=
erations, Administration, and Maintenance (OAM) and the<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; functional roles i=
n monitoring and diagnosing the behavior of telecommunications networks
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;have been lon=
g term studied at the Layer 1&amp;2 &amp; Layer 3 levels.&nbsp; The current=
 practice is that
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;many technolo=
gies and layers have their own OAM protocols.&nbsp;&nbsp; There is little o=
r no<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; re-use of software=
 and hardware for each existing OAM protocol. Vendors and operators waste
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:15.75pt"><span lang=3D"EN-US">a=
 lot through the whole OAM life-cycle when a new technology is introduced. =
Integration of OAM
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:15.75pt"><span lang=3D"EN-US">a=
cross multiple technologies is extremely difficult. When having networks wi=
th more than one technology,
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:15.75pt"><span lang=3D"EN-US">m=
aintenance and troubleshooting are done per technology<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; and layer, operati=
on process can be very cumbersome. In many cases it is desirable to have a
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;generic OAM t=
o cover heterogeneous networking technologies. Generic OAM tools should be<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; deployed over vari=
ous encapsulating protocols, and in various medium types.<o:p></o:p></span>=
</p>
<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">&nbsp;&nbsp; An example of an e=
nvironment in which a generic and integrated OAM protocol would be
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;valuable is S=
ervice Function Chaining. A Service Function Chaining is composed by a seri=
es of<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; service Functions,=
 that can act in different layers but providing an end-to-end chain or path=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; from a source to d=
estination in a given order.&nbsp; In service function chaining Environment=
, it is<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; necessary to provi=
de end to end OAM across certain or all entities and involving many layers.=
&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;OAM informati=
on should be exchanged between service functions in different layers while
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;using various=
 encapsulating protocols.&nbsp; In some cases OAM should cross different
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;administratio=
n and/or maintenance domains.<o:p></o:p></span></p>
<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">The purpose of the list:<o:p></=
o:p></span></p>
<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">&nbsp;&nbsp; 1.understanding an=
d discussing the times when an OAM
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;protocol can =
be tuned and optimised for a specific data plane (for example, OAM in a pac=
ket
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;network can b=
e very different from OAM in a circuit switched network because of the
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;different cha=
racteristics of the network)
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:15.75pt"><span lang=3D"EN-US">2=
.and seeking the best ways:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:15.75pt"><span lang=3D"EN-US"><=
o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;O Exchange OAM information at the service layer atop of layer 3
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US">O =
Abstract OAM information common to different layer
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US"><o=
:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US">O =
Provide them via unified interface to management entities.
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US"><o=
:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US">O =
Set up Maintenance Domains (MD) and Maintenance Intermediate Points (MIP)
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US"><o=
:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US">O =
Enable OAM function at different layer in the multi-layer network
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US"><o=
:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:42.0pt"><span lang=3D"EN-US">O =
Activate OAM function a different layer and provide results to management e=
ntity<o:p></o:p></span></p>
<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">This mailing list is intended t=
o enable discussion of the architecture, use-cases/applicability, and
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">requirements that provide gener=
ic and integrated OAM covering various heterogeneous network technologies.<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:10.5pt"><span lang=3D"EN-US">O =
Analyse and understand the different motivations and opportunities for opti=
misation of OAM in different
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:21.0pt"><span lang=3D"EN-US">te=
chnology networks, and the trade-offs between those optimisations and the<o=
:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:10.5pt"><span lang=3D"EN-US">&n=
bsp;overall advantage of a generic OAM mechanism.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:10.5pt"><span lang=3D"EN-US"><o=
:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:10.5pt"><span lang=3D"EN-US">O =
Set out the problem statement and architecture for the<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; &nbsp;&nbsp;Transp=
ort Independent OAM in the multi-layer network and outlines the problems<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp; &nbsp;&nbsp;encoun=
tered with existing OAM protocol variety and their impact on introduction o=
f new technologies.
<o:p></o:p></span></p>
<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">You can subscribe to the list a=
t: <a href=3D"https://www.ietf.org/mailman/listinfo/time">
https://www.ietf.org/mailman/listinfo/time</a>.<o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">To post a message to all the li=
st members, send email to time at ietf.org.
<o:p></o:p></span></p>
<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"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Best Regards,<o:p></o:p></span>=
</p>
<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">Qin&amp;Dan<o:p></o:p></span></=
p>
</div>
</body>
</html>

--_000_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_--

--_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=127;
	creation-date="Tue, 10 Jun 2014 07:00:08 GMT";
	modification-date="Tue, 10 Jun 2014 07:00:08 GMT"
Content-ID: <EEBD70CD98945F48989A5C0B825FA110@huawei.com>
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRpbWUgbWFp
bGluZyBsaXN0DQpUaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3RpbWUNCg==

--_004_B8F9A780D330094D99AF023C5877DABA84549706nkgeml501mbschi_--


From nobody Fri Jun 13 08:13:49 2014
Return-Path: <k.pentikousis@eict.de>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B851B2952 for <sfc@ietfa.amsl.com>; Fri, 13 Jun 2014 08:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG9bIVahEfDA for <sfc@ietfa.amsl.com>; Fri, 13 Jun 2014 08:13:17 -0700 (PDT)
Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 1F62D1B28ED for <sfc@ietf.org>; Fri, 13 Jun 2014 08:13:11 -0700 (PDT)
Received: by mx2.eict.de (Postfix, from userid 481) id 0DD831FF4B; Fri, 13 Jun 2014 17:13:10 +0200 (CEST)
Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id E216C1FF46; Fri, 13 Jun 2014 17:13:06 +0200 (CEST)
Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 6FB2C378233; Fri, 13 Jun 2014 17:13:06 +0200 (CEST)
Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Fri, 13 Jun 2014 17:13:06 +0200
From: Kostas Pentikousis <k.pentikousis@eict.de>
To: SDN IRTF list <sdn@irtf.org>
Date: Fri, 13 Jun 2014 17:13:05 +0200
Thread-Topic: [Sdn] Feature topic on Network and Service Virtualization
Thread-Index: Ac+A8HKmoPQSgZDfRdOTRJSmkkVJ9gGKFhqQ
Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1A95@SBS2008.eict.local>
References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1642@SBS2008.eict.local>
In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1642@SBS2008.eict.local>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8YJGme2eFP_FAxmCtaNCO2muhU4
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] [Sdn] Feature topic on Network and Service Virtualization
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jun 2014 15:13:26 -0000

Dear all,

We have received several requests for an extension to the original FT CfP d=
eadline. As a result, the extended deadlines are as follows:

Manuscript Submission Due: June 25, 2014

Acceptance Notification: September 10, 2014

The URI below will be updated shortly. Many thanks for your interest in thi=
s feature topic.=20

Best regards,

Kostas

| -----Urspr=FCngliche Nachricht-----
| Von: Kostas Pentikousis [mailto:k.pentikousis@eict.de]
| Gesendet: Donnerstag, 5. Juni 2014 12:06
| An: SDN IRTF list
| Cc: sfc@ietf.org
| Betreff: [Sdn] Feature topic on Network and Service Virtualization
|=20
| Dear all,
|=20
| This is a kind reminder for those interested in submitting a paper to
| the IEEE Communications Magazine special issue on "Network and Service
| Virtualization":
| http://www.comsoc.org/files/Publications/Magazines/ci/cfp/cfpcommag0215.h=
tml.
| The deadline is in 10 days (15 June 2014).
|=20
| Papers from industry labs, which address a wider audience and conform
| to the Magazine submission guidelines, are particularly solicited.
|=20
| Best regards,
|=20
| Kostas
|=20


From nobody Wed Jun 18 03:08:05 2014
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF17B1A014D for <sfc@ietfa.amsl.com>; Wed, 18 Jun 2014 03:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOWsLCygcp2P for <sfc@ietfa.amsl.com>; Wed, 18 Jun 2014 03:08:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F057D1A0129 for <sfc@ietf.org>; Wed, 18 Jun 2014 03:08:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIO20822; Wed, 18 Jun 2014 10:08:01 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 11:08:00 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 18:07:58 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Questions about draft-quinn-sfc-arch-05
Thread-Index: Ac+K3S127YmDPWQNScaOnWZ/UqobUw==
Date: Wed, 18 Jun 2014 10:07:58 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283162@NKGEML512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/R1K7kf82RlK71-Xw5ShMcskFtGA
Subject: [sfc] Questions about draft-quinn-sfc-arch-05
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jun 2014 10:08:04 -0000

Hi all,

I have two questions about draft-quinn-sfc-arch-05:

1. According to the following figure quoted from the above draft, it seems =
each SFF Table entry (I,e., SFP) only contains an ordered list of SF IDs. I=
f so, for a given SFID in the list, how does the SFF know on which particul=
ar service node that SF should be performed (assume there are multiple serv=
ice nodes which can provide the SF of that SF ID)?


                +------+----------------------------------+
                | SFP  |   Ordered Service Functions      |
                |------+----------------------------------+
                | ID   | order1 | order2 | order3 | ...   |
                +------+--------+--------+--------+-------+
                | SFP1 | SFID1  | SFID5  | SFID20 |       |
                +------+--------+--------+--------+-------+
                | SFP4 | SFID100| SFID3  | SFID4  | SFID9 |
                +------+--------+--------+--------+-------+
                | ...  |        |        |        |       |
                +------+--------+--------+--------+-------+

                            Figure 3: SFF Table

2. Does the Transport Derived SFF concept mean the SFP could also be repres=
ented by some information contained in the transport layer, instead of the =
service path id contained in the SFC encapsulation header? For instance, an=
 ordered list of service node locators and service function instance identi=
ties (see http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-01)?

Best regards,
Xiaohu


From nobody Wed Jun 18 07:01:12 2014
Return-Path: <repenno@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F491A025F for <sfc@ietfa.amsl.com>; Wed, 18 Jun 2014 07:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1SIcSTCW5wy for <sfc@ietfa.amsl.com>; Wed, 18 Jun 2014 07:00:46 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2951A0266 for <sfc@ietf.org>; Wed, 18 Jun 2014 07:00:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2355; q=dns/txt; s=iport; t=1403100046; x=1404309646; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=W5Xt58Qre/RUHUjMorBEJ6X3ci9t44w8t3TzGm4GmgE=; b=k9n4OO7Aucx8f+8H0zfBGNqScIyo6hV5lERGbCILIyTMWAH/GpkDu0aO kTD1sLbr/nQnc8pQrN4OTCKeb4hH2oU1W3u04JvA3oo8kr+YxEkgHDMYV o/hQushh6z8jts0rmLAR/dTa0Vj7L2FtpLSsDe2rpQYSWV1z+jMrCFK1Y U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8IADiboVOtJV2R/2dsb2JhbABagw1SWqoTAQEBAQEBBQGRaYc/AYEJFnWEAwEBAQQBAQE3NBsCAQgRBAEBCxQQJwsdCAEBBAESCIg6DcxZF4ViiGI4gy2BFgEDnAaSFYNCgjA
X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="330893381"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jun 2014 14:00:45 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5IE0jjv011277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 14:00:45 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 09:00:45 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Questions about draft-quinn-sfc-arch-05
Thread-Index: Ac+K3S127YmDPWQNScaOnWZ/UqobUwAIEFG0
Date: Wed, 18 Jun 2014 14:00:44 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040BE3F74E@xmb-rcd-x04.cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283162@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283162@NKGEML512-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.65.87]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PQN2aEGllsyMn0oDZ1an-4dzyKU
Subject: Re: [sfc] Questions about draft-quinn-sfc-arch-05
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jun 2014 14:00:51 -0000

When you create a Service Path you define the actual service functions (SFs=
 + locator) that will provide service. When you create a service function c=
hain you only define the type of the service function (dpi, firewall, nat).=
=0A=
=0A=
thanks,=0A=
=0A=
Reinaldo=0A=
________________________________________=0A=
From: sfc [sfc-bounces@ietf.org] on behalf of Xuxiaohu [xuxiaohu@huawei.com=
]=0A=
Sent: Wednesday, June 18, 2014 3:07 AM=0A=
To: sfc@ietf.org=0A=
Subject: [sfc] Questions about draft-quinn-sfc-arch-05=0A=
=0A=
Hi all,=0A=
=0A=
I have two questions about draft-quinn-sfc-arch-05:=0A=
=0A=
1. According to the following figure quoted from the above draft, it seems =
each SFF Table entry (I,e., SFP) only contains an ordered list of SF IDs. I=
f so, for a given SFID in the list, how does the SFF know on which particul=
ar service node that SF should be performed (assume there are multiple serv=
ice nodes which can provide the SF of that SF ID)?=0A=
=0A=
=0A=
                +------+----------------------------------+=0A=
                | SFP  |   Ordered Service Functions      |=0A=
                |------+----------------------------------+=0A=
                | ID   | order1 | order2 | order3 | ...   |=0A=
                +------+--------+--------+--------+-------+=0A=
                | SFP1 | SFID1  | SFID5  | SFID20 |       |=0A=
                +------+--------+--------+--------+-------+=0A=
                | SFP4 | SFID100| SFID3  | SFID4  | SFID9 |=0A=
                +------+--------+--------+--------+-------+=0A=
                | ...  |        |        |        |       |=0A=
                +------+--------+--------+--------+-------+=0A=
=0A=
                            Figure 3: SFF Table=0A=
=0A=
2. Does the Transport Derived SFF concept mean the SFP could also be repres=
ented by some information contained in the transport layer, instead of the =
service path id contained in the SFC encapsulation header? For instance, an=
 ordered list of service node locators and service function instance identi=
ties (see http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-01)?=0A=
=0A=
Best regards,=0A=
Xiaohu=0A=
=0A=
_______________________________________________=0A=
sfc mailing list=0A=
sfc@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/sfc=0A=


From nobody Wed Jun 18 18:27:35 2014
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186701A025C for <sfc@ietfa.amsl.com>; Wed, 18 Jun 2014 18:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s43cxnWXDNQ2 for <sfc@ietfa.amsl.com>; Wed, 18 Jun 2014 18:27:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0E61A0087 for <sfc@ietf.org>; Wed, 18 Jun 2014 18:27:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO73129; Thu, 19 Jun 2014 01:27:30 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 02:27:27 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 19 Jun 2014 09:27:22 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Questions about draft-quinn-sfc-arch-05
Thread-Index: Ac+K3S127YmDPWQNScaOnWZ/UqobUwAIEFG0ABflwnA=
Date: Thu, 19 Jun 2014 01:27:21 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828340C@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08283162@NKGEML512-MBS.china.huawei.com> <45A697A8FFD7CF48BCF2BE7E106F06040BE3F74E@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040BE3F74E@xmb-rcd-x04.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yBSc8Nj2PcHnEjf6KeWS0dValIA
Subject: Re: [sfc] Questions about draft-quinn-sfc-arch-05
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jun 2014 01:27:34 -0000

> -----Original Message-----
> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
> Sent: Wednesday, June 18, 2014 10:01 PM
> To: Xuxiaohu; sfc@ietf.org
> Subject: RE: Questions about draft-quinn-sfc-arch-05
>=20
> When you create a Service Path you define the actual service functions (S=
Fs +
> locator) that will provide service. When you create a service function ch=
ain you
> only define the type of the service function (dpi, firewall, nat).

Sure. The SFP should be represented by an ordered list of SF IDs and SN loc=
ators. However, it seems that the SFF table entry (an ordered list of SF ID=
s) as described in draft-quinn-sfc-arch-05 is about an SFC, rather than an =
SFP.

Best regards,
Xiaohu
=20
> thanks,
>=20
> Reinaldo
> ________________________________________
> From: sfc [sfc-bounces@ietf.org] on behalf of Xuxiaohu
> [xuxiaohu@huawei.com]
> Sent: Wednesday, June 18, 2014 3:07 AM
> To: sfc@ietf.org
> Subject: [sfc] Questions about draft-quinn-sfc-arch-05
>=20
> Hi all,
>=20
> I have two questions about draft-quinn-sfc-arch-05:
>=20
> 1. According to the following figure quoted from the above draft, it seem=
s each
> SFF Table entry (I,e., SFP) only contains an ordered list of SF IDs. If s=
o, for a given
> SFID in the list, how does the SFF know on which particular service node =
that SF
> should be performed (assume there are multiple service nodes which can
> provide the SF of that SF ID)?
>=20
>=20
>                 +------+----------------------------------+
>                 | SFP  |   Ordered Service Functions      |
>                 |------+----------------------------------+
>                 | ID   | order1 | order2 | order3 | ...   |
>                 +------+--------+--------+--------+-------+
>                 | SFP1 | SFID1  | SFID5  | SFID20 |       |
>                 +------+--------+--------+--------+-------+
>                 | SFP4 | SFID100| SFID3  | SFID4  | SFID9 |
>                 +------+--------+--------+--------+-------+
>                 | ...  |        |        |        |       |
>                 +------+--------+--------+--------+-------+
>=20
>                             Figure 3: SFF Table
>=20
> 2. Does the Transport Derived SFF concept mean the SFP could also be
> represented by some information contained in the transport layer, instead=
 of the
> service path id contained in the SFC encapsulation header? For instance, =
an
> ordered list of service node locators and service function instance ident=
ities (see
> http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-01)?
>=20
> Best regards,
> Xiaohu
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


From nobody Fri Jun 20 07:59:20 2014
Return-Path: <narten@us.ibm.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5A01B2804 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 07:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level: 
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r57rbZHvDo4X for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 07:59:13 -0700 (PDT)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BA21B281E for <sfc@ietf.org>; Fri, 20 Jun 2014 07:59:08 -0700 (PDT)
Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <sfc@ietf.org> from <narten@us.ibm.com>; Fri, 20 Jun 2014 08:59:07 -0600
Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Fri, 20 Jun 2014 08:59:05 -0600
Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 68F8F1FF001A for <sfc@ietf.org>; Fri, 20 Jun 2014 08:59:04 -0600 (MDT)
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by b03cxnp07029.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s5KCtZNt2097614 for <sfc@ietf.org>; Fri, 20 Jun 2014 14:55:35 +0200
Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id s5KF31AD008918 for <sfc@ietf.org>; Fri, 20 Jun 2014 09:03:01 -0600
Received: from cichlid.raleigh.ibm.com ([9.80.102.25]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id s5KF2xRW008774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sfc@ietf.org>; Fri, 20 Jun 2014 09:03:00 -0600
Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s5KEx1w8024052 for <sfc@ietf.org>; Fri, 20 Jun 2014 10:59:01 -0400
Date: Fri, 20 Jun 2014 10:59:01 -0400
Message-ID: <m3ionvsk3u.wl%narten@us.ibm.com>
From: Thomas Narten <narten@us.ibm.com>
To: sfc@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14062014-6688-0000-0000-000002B39170
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yCjCq9Z_xskJ2bwQLIvmY4bfPaA
Subject: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 14:59:19 -0000

WG:

As has been noted before, an IPR disclosure has been made on the SFC
problem statement document
(draft-ietf-sfc-problem-statement-06.txt). Per
http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
indicates that their licensing terms would be:

    Reasonable and Non-Discriminatory License to All Implementers with
    Possible Royalty/Fee.

As has been noted, it is unusual to see an IPR declaration on a
problem statement. One doesn't implement a problem statement, raising
the question of what it means to make an IPR disclosure on a problem
statement. While there are several interpretations that could be made,
it was suggested in an earlier thread that the IPR may have broad
applicability, and that it might be difficult for the SFC WG to
develop solutions that are not potentially encumbered.

When IPR disclosures have been made, WGs have the option of taking the
potential IPR into consideration as they do their work. For example,
when selecting between competing approaches to solving a problem, IPR
considerations can be one of the factors used in weighing the pros and
cons of an approach. Some may decide that IPR is a significant issue,
others may consider disclosed IPR to be a minor factor.

The IETF handling of IPR is covered in detail in RFCs 3979 and
2026. There are aspects of IPR that are not appropriate or productive
to discuss within the WG, because at the end of the day, the IETF
cannot and does not make determinations as to whether IPR is valid,
whether it applies to a given technology, whether there is prior art,
etc. Those sorts of issues are resolved outside of the IETF.

In discussing IPR within the IETF, individual IETF participants can
indicate that they have concerns about IPR, and that those concerns
lead them to take certain positions on specific issues. For example,
IPR concerns could lead to a preference for one technical approach
over another, or in extreme cases, that work in a particular area
should not be pursued at all.

As always, WGs act on consensus, and IPR concerns are no different.
While there have been some postings indiciating unhappiness with the
disclosure, the chairs do not see consensus for any action other than
to continue on, keeping in mind that a disclosure has been made.

In summary, SFC participants should be aware of and examine the
disclosure to determine if they have any special concerns. Given the
disclosure was made on the problem statement, we should not be
surprised if a similar disclosure is made on future SFC documents.  If
folk have concerns with the disclosure and its potential impact on the
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
a good time to raise the issue.

Thomas (chair hat on)


From nobody Fri Jun 20 08:57:45 2014
Return-Path: <stbryant@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB921B27EC for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 08:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level: 
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ8Ot0XWvlc0 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 08:57:43 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D411A038B for <sfc@ietf.org>; Fri, 20 Jun 2014 08:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95; q=dns/txt; s=iport; t=1403279863; x=1404489463; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=RxrEf8AXKsAxNAecTsK4ukGfsFBGK38hPom9m1Df3Wk=; b=I98z7sVgLhp48KPML4Og+/qau/3TbjgfR6Boe4sul3mioUWsHDIBUl3S DkEGDfCfLCga0B1sPzALdomTGoE2OeyjRsb8wnbS5czTWlPEm72EzeHSD zemCDOD95IcGXslfh6R3YzY+h8T6/C24Zdgjoi7Gst45xZdPZ71ZzE17S o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwFAJNZpFOtJssW/2dsb2JhbABZkUqdDwEBAQEBAQUBmSoBgSB1hAQBAQQ4QBELIRYPCQMCAQIBRQYBDAgBAYg+s0KXJReFYokbhEMBA5pEk1qDQw
X-IronPort-AV: E=Sophos;i="5.01,514,1400025600"; d="scan'208";a="87985613"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 20 Jun 2014 15:57:40 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5KFvePp001538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2014 15:57:40 GMT
Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s5KFvdIa027086; Fri, 20 Jun 2014 16:57:40 +0100 (BST)
Message-ID: <53A459F3.3080908@cisco.com>
Date: Fri, 20 Jun 2014 16:57:39 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>, sfc@ietf.org
References: <m3ionvsk3u.wl%narten@us.ibm.com>
In-Reply-To: <m3ionvsk3u.wl%narten@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-AqmGZu6g6ifDjtHPjF2noYGRiI
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 15:57:44 -0000

I support the continuation of the publication process
of this draft as it stands.

Stewart


From nobody Fri Jun 20 12:21:09 2014
Return-Path: <agmalis@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0A1B28DD for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 12:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5qqhWRqouvv for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 12:21:05 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734E31B28B1 for <sfc@ietf.org>; Fri, 20 Jun 2014 12:21:05 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id f51so3783974qge.36 for <sfc@ietf.org>; Fri, 20 Jun 2014 12:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YpR7MiOBtcBYU9WzBJq2K4czO83gihuJxedBwCUk6Fo=; b=ir+7vkoANxgAPNHKCeB/85BykT33/N4q8yAn/gn1Afs8Y7CLff7lXSBkZDiB8VjPA9 HD422eTnuAWTZBZP7sLngJGNwZNon+u38AJXbQEmQbXTJHjt4tF1+F9L2TdderIUSB5Y ZkoC+1SL4a4jZzT9/V3yrI45EK8To6/zfy+5JcDHJXvv2vaQFSqYcG4G0sZ6RVPM645R Hk0QjMX5oDj8n8G3p9MK0ce3qx8tCr+OWqbB7CJ76BfdBcMw+yx7lIv5Uxc1fdAHNnzl M2ETnPk9xdJHBJ10D6+Pde3zgOR4PeBB+bzZqjY6VrhPwzQDzfcc4lXd5iOs40MeAbSL oF9Q==
X-Received: by 10.224.119.198 with SMTP id a6mr8184570qar.39.1403292064616; Fri, 20 Jun 2014 12:21:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.86.148 with HTTP; Fri, 20 Jun 2014 12:20:44 -0700 (PDT)
In-Reply-To: <m3ionvsk3u.wl%narten@us.ibm.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Fri, 20 Jun 2014 21:20:44 +0200
Message-ID: <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
To: Thomas Narten <narten@us.ibm.com>
Content-Type: multipart/alternative; boundary=001a11c2e6e007159404fc4965fd
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/GrWdxopf7z0_z8ibycqMDpW5_Aw
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 19:21:08 -0000

--001a11c2e6e007159404fc4965fd
Content-Type: text/plain; charset=UTF-8

Thomas,

In the previous discussion, there were several requests for the IPR holder
to give a summary of the scope of the IPR and how it applies to the problem
statement. I would personally feel more comfortable about supporting the
document as it stands if this question was answered. But as it is, we're in
the dark regarding how to proceed.

Cheers,
Andy


On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com> wrote:

> WG:
>
> As has been noted before, an IPR disclosure has been made on the SFC
> problem statement document
> (draft-ietf-sfc-problem-statement-06.txt). Per
> http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
> indicates that their licensing terms would be:
>
>     Reasonable and Non-Discriminatory License to All Implementers with
>     Possible Royalty/Fee.
>
> As has been noted, it is unusual to see an IPR declaration on a
> problem statement. One doesn't implement a problem statement, raising
> the question of what it means to make an IPR disclosure on a problem
> statement. While there are several interpretations that could be made,
> it was suggested in an earlier thread that the IPR may have broad
> applicability, and that it might be difficult for the SFC WG to
> develop solutions that are not potentially encumbered.
>
> When IPR disclosures have been made, WGs have the option of taking the
> potential IPR into consideration as they do their work. For example,
> when selecting between competing approaches to solving a problem, IPR
> considerations can be one of the factors used in weighing the pros and
> cons of an approach. Some may decide that IPR is a significant issue,
> others may consider disclosed IPR to be a minor factor.
>
> The IETF handling of IPR is covered in detail in RFCs 3979 and
> 2026. There are aspects of IPR that are not appropriate or productive
> to discuss within the WG, because at the end of the day, the IETF
> cannot and does not make determinations as to whether IPR is valid,
> whether it applies to a given technology, whether there is prior art,
> etc. Those sorts of issues are resolved outside of the IETF.
>
> In discussing IPR within the IETF, individual IETF participants can
> indicate that they have concerns about IPR, and that those concerns
> lead them to take certain positions on specific issues. For example,
> IPR concerns could lead to a preference for one technical approach
> over another, or in extreme cases, that work in a particular area
> should not be pursued at all.
>
> As always, WGs act on consensus, and IPR concerns are no different.
> While there have been some postings indiciating unhappiness with the
> disclosure, the chairs do not see consensus for any action other than
> to continue on, keeping in mind that a disclosure has been made.
>
> In summary, SFC participants should be aware of and examine the
> disclosure to determine if they have any special concerns. Given the
> disclosure was made on the problem statement, we should not be
> surprised if a similar disclosure is made on future SFC documents.  If
> folk have concerns with the disclosure and its potential impact on the
> work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
> a good time to raise the issue.
>
> Thomas (chair hat on)
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>

--001a11c2e6e007159404fc4965fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thomas,<div><br></div><div>In the previous discussion, the=
re were several requests for the IPR holder to give a summary of the scope =
of the IPR and how it applies to the problem statement. I would personally =
feel more comfortable about supporting the document as it stands if this qu=
estion was answered. But as it is, we&#39;re in the dark regarding how to p=
roceed.</div>

<div><br></div><div>Cheers,</div><div>Andy</div></div><div class=3D"gmail_e=
xtra"><br><br><div class=3D"gmail_quote">On Fri, Jun 20, 2014 at 4:59 PM, T=
homas Narten <span dir=3D"ltr">&lt;<a href=3D"mailto:narten@us.ibm.com" tar=
get=3D"_blank">narten@us.ibm.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" target=3D"_blank">http://=
datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
=C2=A0 =C2=A0 Reasonable and Non-Discriminatory License to All Implementers=
 with<br>
=C2=A0 =C2=A0 Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn&#39;t implement a problem statement, raising<b=
r>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, IPR<br>
considerations can be one of the factors used in weighing the pros and<br>
cons of an approach. Some may decide that IPR is a significant issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. =C2=A0If=
<br>
folk have concerns with the disclosure and its potential impact on the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote></div><br></div>

--001a11c2e6e007159404fc4965fd--


From nobody Fri Jun 20 13:23:18 2014
Return-Path: <andrew.dolganow@alcatel-lucent.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41441B2905 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 13:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nMAEJf1X6eK for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 13:23:12 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C971B28FC for <sfc@ietf.org>; Fri, 20 Jun 2014 13:23:12 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5KKN0Nt023333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jun 2014 15:23:00 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s5KKN032020609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 16:23:00 -0400
Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.234]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 20 Jun 2014 16:23:00 -0400
From: "Dolganow, Andrew (Andrew)" <andrew.dolganow@alcatel-lucent.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Thread-Topic: [sfc] IPR Disclosure on SFC work
Thread-Index: AQHPjLy7JlbqJXlLoUCF8poFGZsP8Jt6cWHD
Date: Fri, 20 Jun 2014 20:22:59 +0000
Message-ID: <41F6EBAC-B6B4-4D89-AC8F-6DD09BCE5B49@alcatel-lucent.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com>, <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
In-Reply-To: <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_41F6EBACB6B44D89AC8F6DD09BCE5B49alcatellucentcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JHQ50YrfQN7gcey6bRr3a12s_ig
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 20:23:15 -0000

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

I would second Andy's position. Considering how licensing terms are worded =
I think we need more details on IPR.

Andrew

Sent from my iPhone

On Jun 20, 2014, at 3:22 PM, "Andrew G. Malis" <agmalis@gmail.com<mailto:ag=
malis@gmail.com>> wrote:

Thomas,

In the previous discussion, there were several requests for the IPR holder =
to give a summary of the scope of the IPR and how it applies to the problem=
 statement. I would personally feel more comfortable about supporting the d=
ocument as it stands if this question was answered. But as it is, we're in =
the dark regarding how to proceed.

Cheers,
Andy


On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com<mailto:na=
rten@us.ibm.com>> wrote:
WG:

As has been noted before, an IPR disclosure has been made on the SFC
problem statement document
(draft-ietf-sfc-problem-statement-06.txt). Per
http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
indicates that their licensing terms would be:

    Reasonable and Non-Discriminatory License to All Implementers with
    Possible Royalty/Fee.

As has been noted, it is unusual to see an IPR declaration on a
problem statement. One doesn't implement a problem statement, raising
the question of what it means to make an IPR disclosure on a problem
statement. While there are several interpretations that could be made,
it was suggested in an earlier thread that the IPR may have broad
applicability, and that it might be difficult for the SFC WG to
develop solutions that are not potentially encumbered.

When IPR disclosures have been made, WGs have the option of taking the
potential IPR into consideration as they do their work. For example,
when selecting between competing approaches to solving a problem, IPR
considerations can be one of the factors used in weighing the pros and
cons of an approach. Some may decide that IPR is a significant issue,
others may consider disclosed IPR to be a minor factor.

The IETF handling of IPR is covered in detail in RFCs 3979 and
2026. There are aspects of IPR that are not appropriate or productive
to discuss within the WG, because at the end of the day, the IETF
cannot and does not make determinations as to whether IPR is valid,
whether it applies to a given technology, whether there is prior art,
etc. Those sorts of issues are resolved outside of the IETF.

In discussing IPR within the IETF, individual IETF participants can
indicate that they have concerns about IPR, and that those concerns
lead them to take certain positions on specific issues. For example,
IPR concerns could lead to a preference for one technical approach
over another, or in extreme cases, that work in a particular area
should not be pursued at all.

As always, WGs act on consensus, and IPR concerns are no different.
While there have been some postings indiciating unhappiness with the
disclosure, the chairs do not see consensus for any action other than
to continue on, keeping in mind that a disclosure has been made.

In summary, SFC participants should be aware of and examine the
disclosure to determine if they have any special concerns. Given the
disclosure was made on the problem statement, we should not be
surprised if a similar disclosure is made on future SFC documents.  If
folk have concerns with the disclosure and its potential impact on the
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
a good time to raise the issue.

Thomas (chair hat on)

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

--_000_41F6EBACB6B44D89AC8F6DD09BCE5B49alcatellucentcom_
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"=
>
</head>
<body dir=3D"auto">
<div>I would second Andy's position. Considering how licensing terms are wo=
rded I think we need more details on IPR.&nbsp;<br>
<br>
Andrew
<div><br>
</div>
<div>Sent from my iPhone</div>
</div>
<div><br>
On Jun 20, 2014, at 3:22 PM, &quot;Andrew G. Malis&quot; &lt;<a href=3D"mai=
lto:agmalis@gmail.com">agmalis@gmail.com</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<div dir=3D"ltr">Thomas,
<div><br>
</div>
<div>In the previous discussion, there were several requests for the IPR ho=
lder to give a summary of the scope of the IPR and how it applies to the pr=
oblem statement. I would personally feel more comfortable about supporting =
the document as it stands if this
 question was answered. But as it is, we're in the dark regarding how to pr=
oceed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Andy</div>
</div>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <=
span dir=3D"ltr">
&lt;<a href=3D"mailto:narten@us.ibm.com" target=3D"_blank">narten@us.ibm.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" target=3D"_blank">http://=
datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
&nbsp; &nbsp; Reasonable and Non-Discriminatory License to All Implementers=
 with<br>
&nbsp; &nbsp; Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn't implement a problem statement, raising<br>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, IPR<br>
considerations can be one of the factors used in weighing the pros and<br>
cons of an approach. Some may decide that IPR is a significant issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. &nbsp;If=
<br>
folk have concerns with the disclosure and its potential impact on the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type=3D"cite">
<div><span>_______________________________________________</span><br>
<span>sfc mailing list</span><br>
<span><a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a></span><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.iet=
f.org/mailman/listinfo/sfc</a></span><br>
</div>
</blockquote>
</body>
</html>

--_000_41F6EBACB6B44D89AC8F6DD09BCE5B49alcatellucentcom_--


From nobody Fri Jun 20 13:28:53 2014
Return-Path: <kegray@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0901B28F3 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 13:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4N9bsMPxi1l for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 13:28:44 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACAC1B28F6 for <sfc@ietf.org>; Fri, 20 Jun 2014 13:28:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10779; q=dns/txt; s=iport; t=1403296125; x=1404505725; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BZQ8V8u59afM24R6ku3fsKjSNQZajfhxVgM5Il/d8vg=; b=E8vWlHD3qOOEinya2LSMkXkZ/5+MWjHleParotqWAkzc8c4Z7pk7Locs L8caTcAghCAwTSyC0v41+YxrHLkfuoElMVGHd4xEBfWj4FVF2izvl49BT EoqRlZsB4Uav5f4YxfIVivpwWEGiftHbPHEd60z6rMnQ8R1MNCRa4E9s+ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0MALGYpFOtJA2J/2dsb2JhbABTBoJGR1JaqiABAQEBAQEFAYMJjQ2BVQGHPgGBDhZ1hAMBAQEEAQEBawsQAgEIEQMBAigHIQYLFAkIAgQBDQUbiBMDEQ3DSg2GSxeFYoZxgWAyDQQHhEMEmEuBeYFDjBWGAoNCgjA
X-IronPort-AV: E=Sophos; i="5.01,516,1400025600"; d="scan'208,217"; a="54822720"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 20 Jun 2014 20:28:44 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5KKShgZ026870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 20:28:43 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.10]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 15:28:43 -0500
From: "Ken Gray (kegray)" <kegray@cisco.com>
To: "Andrew G. Malis" <agmalis@gmail.com>, Thomas Narten <narten@us.ibm.com>
Thread-Topic: [sfc] IPR Disclosure on SFC work
Thread-Index: AQHPjJg7PHo5dWpSxECblzAyoXXQKpt6tBcA///P7oA=
Date: Fri, 20 Jun 2014 20:28:42 +0000
Message-ID: <CFCA09C0.3647E%kegray@cisco.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
In-Reply-To: <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.145.179]
Content-Type: multipart/alternative; boundary="_000_CFCA09C03647Ekegrayciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7SM8YOO7umSS5izCHyz2yft5sZk
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 20:28:48 -0000

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

IMO, I don't think it's incumbent on the WG to stop until Ericsson explains=
 their intent =85 or try their claim even if they did =85 because those act=
ions are leverage-able reactions that will prompt more of the same sorts of=
 filings in the future.

Maybe the idea IS to stop all progress =85 but, I think I'd leave it up to =
my company's lawyers to decide whether such a broad claim is enforceable be=
fore I bow to it OR allow the claimant to dictate the structure of the stan=
dard by making vague/untried claims.

From: "Andrew G. Malis" <agmalis@gmail.com<mailto:agmalis@gmail.com>>
Date: Friday, June 20, 2014 12:20 PM
To: Thomas Narten <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: Re: [sfc] IPR Disclosure on SFC work

Thomas,

In the previous discussion, there were several requests for the IPR holder =
to give a summary of the scope of the IPR and how it applies to the problem=
 statement. I would personally feel more comfortable about supporting the d=
ocument as it stands if this question was answered. But as it is, we're in =
the dark regarding how to proceed.

Cheers,
Andy


On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com<mailto:na=
rten@us.ibm.com>> wrote:
WG:

As has been noted before, an IPR disclosure has been made on the SFC
problem statement document
(draft-ietf-sfc-problem-statement-06.txt). Per
http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
indicates that their licensing terms would be:

    Reasonable and Non-Discriminatory License to All Implementers with
    Possible Royalty/Fee.

As has been noted, it is unusual to see an IPR declaration on a
problem statement. One doesn't implement a problem statement, raising
the question of what it means to make an IPR disclosure on a problem
statement. While there are several interpretations that could be made,
it was suggested in an earlier thread that the IPR may have broad
applicability, and that it might be difficult for the SFC WG to
develop solutions that are not potentially encumbered.

When IPR disclosures have been made, WGs have the option of taking the
potential IPR into consideration as they do their work. For example,
when selecting between competing approaches to solving a problem, IPR
considerations can be one of the factors used in weighing the pros and
cons of an approach. Some may decide that IPR is a significant issue,
others may consider disclosed IPR to be a minor factor.

The IETF handling of IPR is covered in detail in RFCs 3979 and
2026. There are aspects of IPR that are not appropriate or productive
to discuss within the WG, because at the end of the day, the IETF
cannot and does not make determinations as to whether IPR is valid,
whether it applies to a given technology, whether there is prior art,
etc. Those sorts of issues are resolved outside of the IETF.

In discussing IPR within the IETF, individual IETF participants can
indicate that they have concerns about IPR, and that those concerns
lead them to take certain positions on specific issues. For example,
IPR concerns could lead to a preference for one technical approach
over another, or in extreme cases, that work in a particular area
should not be pursued at all.

As always, WGs act on consensus, and IPR concerns are no different.
While there have been some postings indiciating unhappiness with the
disclosure, the chairs do not see consensus for any action other than
to continue on, keeping in mind that a disclosure has been made.

In summary, SFC participants should be aware of and examine the
disclosure to determine if they have any special concerns. Given the
disclosure was made on the problem statement, we should not be
surprised if a similar disclosure is made on future SFC documents.  If
folk have concerns with the disclosure and its potential impact on the
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
a good time to raise the issue.

Thomas (chair hat on)

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc


--_000_CFCA09C03647Ekegrayciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <824FCADB2C99804791D78BB1A5A687F9@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>IMO, I don't think it's incumbent on the WG to stop until Ericsson exp=
lains their intent =85 or try their claim even if they did =85 because thos=
e actions are leverage-able reactions that will prompt more of the same sor=
ts of filings in the future.</div>
<div><br>
</div>
<div>Maybe the idea IS to stop all progress =85 but, I think I'd leave it u=
p to my company's lawyers to decide whether such a broad claim is enforceab=
le before I bow to it OR allow the claimant to dictate the structure of the=
 standard by making vague/untried
 claims.</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;Andrew G. Malis&quot; &=
lt;<a href=3D"mailto:agmalis@gmail.com">agmalis@gmail.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Friday, June 20, 2014 12:20 P=
M<br>
<span style=3D"font-weight:bold">To: </span>Thomas Narten &lt;<a href=3D"ma=
ilto:narten@us.ibm.com">narten@us.ibm.com</a>&gt;<br>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:sfc@iet=
f.org">sfc@ietf.org</a>&quot; &lt;<a href=3D"mailto:sfc@ietf.org">sfc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [sfc] IPR Disclosure o=
n SFC work<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir=3D"ltr">Thomas,
<div><br>
</div>
<div>In the previous discussion, there were several requests for the IPR ho=
lder to give a summary of the scope of the IPR and how it applies to the pr=
oblem statement. I would personally feel more comfortable about supporting =
the document as it stands if this
 question was answered. But as it is, we're in the dark regarding how to pr=
oceed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Andy</div>
</div>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <=
span dir=3D"ltr">
&lt;<a href=3D"mailto:narten@us.ibm.com" target=3D"_blank">narten@us.ibm.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" target=3D"_blank">http://=
datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
&nbsp; &nbsp; Reasonable and Non-Discriminatory License to All Implementers=
 with<br>
&nbsp; &nbsp; Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn't implement a problem statement, raising<br>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, IPR<br>
considerations can be one of the factors used in weighing the pros and<br>
cons of an approach. Some may decide that IPR is a significant issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. &nbsp;If=
<br>
folk have concerns with the disclosure and its potential impact on the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_CFCA09C03647Ekegrayciscocom_--


From nobody Fri Jun 20 13:37:53 2014
Return-Path: <akatlas@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1F61B28AD for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 13:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPgfIlxbgJwu for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 13:37:49 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ADF1A0283 for <sfc@ietf.org>; Fri, 20 Jun 2014 13:37:48 -0700 (PDT)
Received: by mail-yk0-f182.google.com with SMTP id 19so3066604ykq.41 for <sfc@ietf.org>; Fri, 20 Jun 2014 13:37:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LzLrMjbGXBXzskZ1GtQmx2P18UbVcMznej/t86sgutc=; b=qKIy/r3V6a9CmWnwsBElH0ZRxRYTvc81r1W4/oOwlDyIUByMjvr7rIdSpwq9hzsv2R j3Sf/Kf7P80cCIUvQzwE0qfL0woH0VVF7J8nJZlPAMlYuuSvFCJLBuA4yeDMOLFxKC/N 6s1bAx8Sawd6gao+beX+8vaQMXE+/DpkCQi9J0gMvxdkd8PjIuF/0eWGs+DeT/QEzdum TMqdfh6yva7T49+2NHJPPl3xNU0LH7Zq0AkDSr+Roro8emMIh20q61y4qME2Q4v/xncu HpYbFgoz3Q3UjfoIZSbhM1JGFQ+VOewPON537fq9qOT/xXwfmfAMtigITzHMTV9ribCf hYvA==
MIME-Version: 1.0
X-Received: by 10.236.184.137 with SMTP id s9mr7161180yhm.152.1403296668419; Fri, 20 Jun 2014 13:37:48 -0700 (PDT)
Received: by 10.170.58.10 with HTTP; Fri, 20 Jun 2014 13:37:48 -0700 (PDT)
In-Reply-To: <41F6EBAC-B6B4-4D89-AC8F-6DD09BCE5B49@alcatel-lucent.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com> <41F6EBAC-B6B4-4D89-AC8F-6DD09BCE5B49@alcatel-lucent.com>
Date: Fri, 20 Jun 2014 16:37:48 -0400
Message-ID: <CAG4d1rcwD8eQtoS2WRMhAAqVfx-Uvy_X2FiwOimMpU0zQHB2Yw@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Dolganow, Andrew (Andrew)" <andrew.dolganow@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=20cf303f65166f8c1c04fc4a7743
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VODTquDg0pusqkvNiNC7bAat0Ro
Cc: Thomas Narten <narten@us.ibm.com>, "Andrew G. Malis" <agmalis@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 20:37:52 -0000

--20cf303f65166f8c1c04fc4a7743
Content-Type: text/plain; charset=UTF-8

Please recall

"The IETF handling of IPR is covered in detail in RFCs 3979 and
2026. There are aspects of IPR that are not appropriate or productive
to discuss within the WG, because at the end of the day, the IETF
cannot and does not make determinations as to whether IPR is valid,
whether it applies to a given technology, whether there is prior art,
etc. Those sorts of issues are resolved outside of the IETF."

This is up to individual participants...

Alia


On Fri, Jun 20, 2014 at 4:22 PM, Dolganow, Andrew (Andrew) <
andrew.dolganow@alcatel-lucent.com> wrote:

>  I would second Andy's position. Considering how licensing terms are
> worded I think we need more details on IPR.
>
> Andrew
>
>  Sent from my iPhone
>
> On Jun 20, 2014, at 3:22 PM, "Andrew G. Malis" <agmalis@gmail.com> wrote:
>
>   Thomas,
>
>  In the previous discussion, there were several requests for the IPR
> holder to give a summary of the scope of the IPR and how it applies to the
> problem statement. I would personally feel more comfortable about
> supporting the document as it stands if this question was answered. But as
> it is, we're in the dark regarding how to proceed.
>
>  Cheers,
> Andy
>
>
> On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com> wrote:
>
>> WG:
>>
>> As has been noted before, an IPR disclosure has been made on the SFC
>> problem statement document
>> (draft-ietf-sfc-problem-statement-06.txt). Per
>> http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
>> indicates that their licensing terms would be:
>>
>>     Reasonable and Non-Discriminatory License to All Implementers with
>>     Possible Royalty/Fee.
>>
>> As has been noted, it is unusual to see an IPR declaration on a
>> problem statement. One doesn't implement a problem statement, raising
>> the question of what it means to make an IPR disclosure on a problem
>> statement. While there are several interpretations that could be made,
>> it was suggested in an earlier thread that the IPR may have broad
>> applicability, and that it might be difficult for the SFC WG to
>> develop solutions that are not potentially encumbered.
>>
>> When IPR disclosures have been made, WGs have the option of taking the
>> potential IPR into consideration as they do their work. For example,
>> when selecting between competing approaches to solving a problem, IPR
>> considerations can be one of the factors used in weighing the pros and
>> cons of an approach. Some may decide that IPR is a significant issue,
>> others may consider disclosed IPR to be a minor factor.
>>
>> The IETF handling of IPR is covered in detail in RFCs 3979 and
>> 2026. There are aspects of IPR that are not appropriate or productive
>> to discuss within the WG, because at the end of the day, the IETF
>> cannot and does not make determinations as to whether IPR is valid,
>> whether it applies to a given technology, whether there is prior art,
>> etc. Those sorts of issues are resolved outside of the IETF.
>>
>> In discussing IPR within the IETF, individual IETF participants can
>> indicate that they have concerns about IPR, and that those concerns
>> lead them to take certain positions on specific issues. For example,
>> IPR concerns could lead to a preference for one technical approach
>> over another, or in extreme cases, that work in a particular area
>> should not be pursued at all.
>>
>> As always, WGs act on consensus, and IPR concerns are no different.
>> While there have been some postings indiciating unhappiness with the
>> disclosure, the chairs do not see consensus for any action other than
>> to continue on, keeping in mind that a disclosure has been made.
>>
>> In summary, SFC participants should be aware of and examine the
>> disclosure to determine if they have any special concerns. Given the
>> disclosure was made on the problem statement, we should not be
>> surprised if a similar disclosure is made on future SFC documents.  If
>> folk have concerns with the disclosure and its potential impact on the
>> work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
>> a good time to raise the issue.
>>
>> Thomas (chair hat on)
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>
>   _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
>

--20cf303f65166f8c1c04fc4a7743
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Please recall=C2=A0<div><br></div><div>&quot;<span style=
=3D"font-family:arial,sans-serif;font-size:13px">The IETF handling of IPR i=
s covered in detail in RFCs 3979 and</span></div><span style=3D"font-family=
:arial,sans-serif;font-size:13px">2026. There are aspects of IPR that are n=
ot appropriate or productive</span><br style=3D"font-family:arial,sans-seri=
f;font-size:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">to discuss with=
in the WG, because at the end of the day, the IETF</span><br style=3D"font-=
family:arial,sans-serif;font-size:13px"><span style=3D"font-family:arial,sa=
ns-serif;font-size:13px">cannot and does not make determinations as to whet=
her IPR is valid,</span><br style=3D"font-family:arial,sans-serif;font-size=
:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">whether it appl=
ies to a given technology, whether there is prior art,</span><br style=3D"f=
ont-family:arial,sans-serif;font-size:13px"><span style=3D"font-family:aria=
l,sans-serif;font-size:13px">etc. Those sorts of issues are resolved outsid=
e of the IETF.&quot;</span><div>
<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v><div><span style=3D"font-family:arial,sans-serif;font-size:13px">This is =
up to individual participants...</span></div><div><span style=3D"font-famil=
y:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">Alia</span></div></div><div class=3D"gmail_extra"><br><br><div class=3D"=
gmail_quote">On Fri, Jun 20, 2014 at 4:22 PM, Dolganow, Andrew (Andrew) <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:andrew.dolganow@alcatel-lucent.com" ta=
rget=3D"_blank">andrew.dolganow@alcatel-lucent.com</a>&gt;</span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">



<div dir=3D"auto">
<div>I would second Andy&#39;s position. Considering how licensing terms ar=
e worded I think we need more details on IPR.=C2=A0<br>
<br>
Andrew
<div><br>
</div>
<div>Sent from my iPhone</div>
</div><div><div class=3D"h5">
<div><br>
On Jun 20, 2014, at 3:22 PM, &quot;Andrew G. Malis&quot; &lt;<a href=3D"mai=
lto:agmalis@gmail.com" target=3D"_blank">agmalis@gmail.com</a>&gt; wrote:<b=
r>
<br>
</div>
<blockquote type=3D"cite">
<div>
<div dir=3D"ltr">Thomas,
<div><br>
</div>
<div>In the previous discussion, there were several requests for the IPR ho=
lder to give a summary of the scope of the IPR and how it applies to the pr=
oblem statement. I would personally feel more comfortable about supporting =
the document as it stands if this
 question was answered. But as it is, we&#39;re in the dark regarding how t=
o proceed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Andy</div>
</div>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <=
span dir=3D"ltr">
&lt;<a href=3D"mailto:narten@us.ibm.com" target=3D"_blank">narten@us.ibm.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" target=3D"_blank">http://=
datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
=C2=A0 =C2=A0 Reasonable and Non-Discriminatory License to All Implementers=
 with<br>
=C2=A0 =C2=A0 Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn&#39;t implement a problem statement, raising<b=
r>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, IPR<br>
considerations can be one of the factors used in weighing the pros and<br>
cons of an approach. Some may decide that IPR is a significant issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. =C2=A0If=
<br>
folk have concerns with the disclosure and its potential impact on the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type=3D"cite">
<div><span>_______________________________________________</span><br>
<span>sfc mailing list</span><br>
<span><a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a></s=
pan><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/sfc</a></span><br>
</div>
</blockquote>
</div></div></div>

<br>_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
<br></blockquote></div><br></div>

--20cf303f65166f8c1c04fc4a7743--


From nobody Fri Jun 20 14:00:39 2014
Return-Path: <stbryant@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7ED1B2914 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI845EqPJR0o for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:00:35 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB881B2911 for <sfc@ietf.org>; Fri, 20 Jun 2014 14:00:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9733; q=dns/txt; s=iport; t=1403298034; x=1404507634; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5NU3Md7yC0Xhv/aAvTjjV+RAMqMbZSOgWrH6ZLKG0pk=; b=TuHlQFwC+Mp3UJrGOshqwR9PTQ5y7sijdjENbLpZJzazHLaxvWuYSF6r fxtQHa21M/Ll5kJPw5cc1dhqYRfCNgRKY3XuusGjjgdlQ4MpKEWOpaFvS 9Bd6WrGQ7aKqHYn4QvV9MOJAW66qA/jcjfi5rUZdFBsTnoahgd+yr9Fu4 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuELADygpFOtJA2M/2dsb2JhbABTBoMNUqp6AQEBAQEBBQGBAoIHjQ2BVQGHPgGBDhZ1hAQBAQQBAQFrCxACAQg/ByEGCxQRAgQOBRuIEwMRDcNWDYZLF4VihnGBYD8EB4MtgRYEmEuBeYFDjBWGAoNC
X-IronPort-AV: E=Sophos; i="5.01,516,1400025600"; d="scan'208,217"; a="54831566"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 20 Jun 2014 21:00:34 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5KL0Ymb004552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 21:00:34 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 16:00:33 -0500
From: "Stewart Bryant (stbryant)" <stbryant@cisco.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Thread-Topic: [sfc] IPR Disclosure on SFC work
Thread-Index: AQHPjLzN857mszjdbEqPgrvzntbsHJt6e9+y
Date: Fri, 20 Jun 2014 21:00:32 +0000
Message-ID: <434627EA-8C0D-4DE9-99CA-80817885A2DC@cisco.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com>, <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
In-Reply-To: <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_434627EA8C0D4DE999CA80817885A2DCciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/B6dT7GbVcnyXUbVvcgHReRU65Ts
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 21:00:37 -0000

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

Andy

That is surely a hopeless wish. The engineers are unqualified to comment, e=
ven if they were permitted to do so, and I cannot imagine any patent lawyer=
 making any statement on this other than in private to their client, or in =
public in court, since there is surely no advantage to their client to do s=
o.

Stewart

Sent from my iPad

On 20 Jun 2014, at 20:21, "Andrew G. Malis" <agmalis@gmail.com<mailto:agmal=
is@gmail.com>> wrote:

Thomas,

In the previous discussion, there were several requests for the IPR holder =
to give a summary of the scope of the IPR and how it applies to the problem=
 statement. I would personally feel more comfortable about supporting the d=
ocument as it stands if this question was answered. But as it is, we're in =
the dark regarding how to proceed.

Cheers,
Andy


On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com<mailto:na=
rten@us.ibm.com>> wrote:
WG:

As has been noted before, an IPR disclosure has been made on the SFC
problem statement document
(draft-ietf-sfc-problem-statement-06.txt). Per
http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
indicates that their licensing terms would be:

    Reasonable and Non-Discriminatory License to All Implementers with
    Possible Royalty/Fee.

As has been noted, it is unusual to see an IPR declaration on a
problem statement. One doesn't implement a problem statement, raising
the question of what it means to make an IPR disclosure on a problem
statement. While there are several interpretations that could be made,
it was suggested in an earlier thread that the IPR may have broad
applicability, and that it might be difficult for the SFC WG to
develop solutions that are not potentially encumbered.

When IPR disclosures have been made, WGs have the option of taking the
potential IPR into consideration as they do their work. For example,
when selecting between competing approaches to solving a problem, IPR
considerations can be one of the factors used in weighing the pros and
cons of an approach. Some may decide that IPR is a significant issue,
others may consider disclosed IPR to be a minor factor.

The IETF handling of IPR is covered in detail in RFCs 3979 and
2026. There are aspects of IPR that are not appropriate or productive
to discuss within the WG, because at the end of the day, the IETF
cannot and does not make determinations as to whether IPR is valid,
whether it applies to a given technology, whether there is prior art,
etc. Those sorts of issues are resolved outside of the IETF.

In discussing IPR within the IETF, individual IETF participants can
indicate that they have concerns about IPR, and that those concerns
lead them to take certain positions on specific issues. For example,
IPR concerns could lead to a preference for one technical approach
over another, or in extreme cases, that work in a particular area
should not be pursued at all.

As always, WGs act on consensus, and IPR concerns are no different.
While there have been some postings indiciating unhappiness with the
disclosure, the chairs do not see consensus for any action other than
to continue on, keeping in mind that a disclosure has been made.

In summary, SFC participants should be aware of and examine the
disclosure to determine if they have any special concerns. Given the
disclosure was made on the problem statement, we should not be
surprised if a similar disclosure is made on future SFC documents.  If
folk have concerns with the disclosure and its potential impact on the
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
a good time to raise the issue.

Thomas (chair hat on)

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

--_000_434627EA8C0D4DE999CA80817885A2DCciscocom_
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"=
>
</head>
<body dir=3D"auto">
<div>Andy</div>
<div><br>
</div>
<div>That is surely a hopeless wish. The engineers are unqualified to comme=
nt, even if they were permitted to do so, and I cannot imagine any patent l=
awyer making any statement on this other than in private to their client, o=
r in public in court, since there
 is surely no advantage to their client to do so.</div>
<div><br>
</div>
<div>Stewart<br>
<br>
Sent from my iPad</div>
<div><br>
On 20 Jun 2014, at 20:21, &quot;Andrew G. Malis&quot; &lt;<a href=3D"mailto=
:agmalis@gmail.com">agmalis@gmail.com</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div>
<div dir=3D"ltr">Thomas,
<div><br>
</div>
<div>In the previous discussion, there were several requests for the IPR ho=
lder to give a summary of the scope of the IPR and how it applies to the pr=
oblem statement. I would personally feel more comfortable about supporting =
the document as it stands if this
 question was answered. But as it is, we're in the dark regarding how to pr=
oceed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Andy</div>
</div>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <=
span dir=3D"ltr">
&lt;<a href=3D"mailto:narten@us.ibm.com" target=3D"_blank">narten@us.ibm.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" target=3D"_blank">http://=
datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
&nbsp; &nbsp; Reasonable and Non-Discriminatory License to All Implementers=
 with<br>
&nbsp; &nbsp; Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn't implement a problem statement, raising<br>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, IPR<br>
considerations can be one of the factors used in weighing the pros and<br>
cons of an approach. Some may decide that IPR is a significant issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. &nbsp;If=
<br>
folk have concerns with the disclosure and its potential impact on the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type=3D"cite">
<div><span>_______________________________________________</span><br>
<span>sfc mailing list</span><br>
<span><a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a></span><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.iet=
f.org/mailman/listinfo/sfc</a></span><br>
</div>
</blockquote>
</body>
</html>

--_000_434627EA8C0D4DE999CA80817885A2DCciscocom_--


From nobody Fri Jun 20 14:12:16 2014
Return-Path: <tnadeau@lucidvision.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE61B28E8 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7__IloQO-Stg for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:12:11 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80C1A019A for <sfc@ietf.org>; Fri, 20 Jun 2014 14:12:11 -0700 (PDT)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0DA1D27EEA87; Fri, 20 Jun 2014 17:12:11 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_709BDAFC-5C61-4276-A024-FC0C30D5A859"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
In-Reply-To: <CFCA09C0.3647E%kegray@cisco.com>
Date: Fri, 20 Jun 2014 17:12:08 -0400
Message-Id: <84F5ECE8-17F2-4AFB-B1B1-65235E9F1923@lucidvision.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com> <CFCA09C0.3647E%kegray@cisco.com>
To: "Ken Gray (kegray)" <kegray@cisco.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9gVkiIx9Dr1tGZ0DXz5VEtXeBbg
Cc: Thomas Narten <narten@us.ibm.com>, "Andrew G. Malis" <agmalis@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 21:12:14 -0000

--Apple-Mail=_709BDAFC-5C61-4276-A024-FC0C30D5A859
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_91B77A4C-D8F2-49A3-B8B6-A4E010084717"


--Apple-Mail=_91B77A4C-D8F2-49A3-B8B6-A4E010084717
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


	I agree with Ken and others who have commented on this thread. =
Lets move forward.=20

	--Tom


On Jun 20, 2014:4:28 PM, at 4:28 PM, Ken Gray (kegray) =
<kegray@cisco.com> wrote:

> IMO, I don't think it's incumbent on the WG to stop until Ericsson =
explains their intent =85 or try their claim even if they did =85 =
because those actions are leverage-able reactions that will prompt more =
of the same sorts of filings in the future.
>=20
> Maybe the idea IS to stop all progress =85 but, I think I'd leave it =
up to my company's lawyers to decide whether such a broad claim is =
enforceable before I bow to it OR allow the claimant to dictate the =
structure of the standard by making vague/untried claims.
>=20
> From: "Andrew G. Malis" <agmalis@gmail.com>
> Date: Friday, June 20, 2014 12:20 PM
> To: Thomas Narten <narten@us.ibm.com>
> Cc: "sfc@ietf.org" <sfc@ietf.org>
> Subject: Re: [sfc] IPR Disclosure on SFC work
>=20
> Thomas,
>=20
> In the previous discussion, there were several requests for the IPR =
holder to give a summary of the scope of the IPR and how it applies to =
the problem statement. I would personally feel more comfortable about =
supporting the document as it stands if this question was answered. But =
as it is, we're in the dark regarding how to proceed.
>=20
> Cheers,
> Andy
>=20
>=20
> On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com> =
wrote:
> WG:
>=20
> As has been noted before, an IPR disclosure has been made on the SFC
> problem statement document
> (draft-ietf-sfc-problem-statement-06.txt). Per
> http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
> indicates that their licensing terms would be:
>=20
>     Reasonable and Non-Discriminatory License to All Implementers with
>     Possible Royalty/Fee.
>=20
> As has been noted, it is unusual to see an IPR declaration on a
> problem statement. One doesn't implement a problem statement, raising
> the question of what it means to make an IPR disclosure on a problem
> statement. While there are several interpretations that could be made,
> it was suggested in an earlier thread that the IPR may have broad
> applicability, and that it might be difficult for the SFC WG to
> develop solutions that are not potentially encumbered.
>=20
> When IPR disclosures have been made, WGs have the option of taking the
> potential IPR into consideration as they do their work. For example,
> when selecting between competing approaches to solving a problem, IPR
> considerations can be one of the factors used in weighing the pros and
> cons of an approach. Some may decide that IPR is a significant issue,
> others may consider disclosed IPR to be a minor factor.
>=20
> The IETF handling of IPR is covered in detail in RFCs 3979 and
> 2026. There are aspects of IPR that are not appropriate or productive
> to discuss within the WG, because at the end of the day, the IETF
> cannot and does not make determinations as to whether IPR is valid,
> whether it applies to a given technology, whether there is prior art,
> etc. Those sorts of issues are resolved outside of the IETF.
>=20
> In discussing IPR within the IETF, individual IETF participants can
> indicate that they have concerns about IPR, and that those concerns
> lead them to take certain positions on specific issues. For example,
> IPR concerns could lead to a preference for one technical approach
> over another, or in extreme cases, that work in a particular area
> should not be pursued at all.
>=20
> As always, WGs act on consensus, and IPR concerns are no different.
> While there have been some postings indiciating unhappiness with the
> disclosure, the chairs do not see consensus for any action other than
> to continue on, keeping in mind that a disclosure has been made.
>=20
> In summary, SFC participants should be aware of and examine the
> disclosure to determine if they have any special concerns. Given the
> disclosure was made on the problem statement, we should not be
> surprised if a similar disclosure is made on future SFC documents.  If
> folk have concerns with the disclosure and its potential impact on the
> work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
> a good time to raise the issue.
>=20
> Thomas (chair hat on)
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


--Apple-Mail=_91B77A4C-D8F2-49A3-B8B6-A4E010084717
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><br></div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>I agree with Ken and others who =
have commented on this thread. Lets move =
forward.&nbsp;<div><br></div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	=
</span>--Tom</div><div><br></div><div><br><div><div>On Jun 20, 2014:4:28 =
PM, at 4:28 PM, Ken Gray (kegray) &lt;<a =
href=3D"mailto:kegray@cisco.com">kegray@cisco.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">

<meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3DWindows-1252">

<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; font-size: 14px; font-family: =
Calibri, sans-serif;">
<div>IMO, I don't think it's incumbent on the WG to stop until Ericsson =
explains their intent =85 or try their claim even if they did =85 =
because those actions are leverage-able reactions that will prompt more =
of the same sorts of filings in the future.</div>
<div><br>
</div>
<div>Maybe the idea IS to stop all progress =85 but, I think I'd leave =
it up to my company's lawyers to decide whether such a broad claim is =
enforceable before I bow to it OR allow the claimant to dictate the =
structure of the standard by making vague/untried
 claims.</div>
<div><br>
</div>
<span id=3D"OLK_SRC_BODY_SECTION">
<div style=3D"font-family: Calibri; font-size: 11pt; text-align: left; =
border-width: 1pt medium medium; border-style: solid none none; padding: =
3pt 0in 0in; border-top-color: rgb(181, 196, 223);">
<span style=3D"font-weight:bold">From: </span>"Andrew G. Malis" &lt;<a =
href=3D"mailto:agmalis@gmail.com">agmalis@gmail.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Friday, June 20, 2014 =
12:20 PM<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>"<a =
href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>" &lt;<a =
href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [sfc] IPR =
Disclosure on SFC work<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir=3D"ltr">Thomas,
<div><br>
</div>
<div>In the previous discussion, there were several requests for the IPR =
holder to give a summary of the scope of the IPR and how it applies to =
the problem statement. I would personally feel more comfortable about =
supporting the document as it stands if this
 question was answered. But as it is, we're in the dark regarding how to =
proceed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Andy</div>
</div>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Fri, Jun 20, 2014 at 4:59 PM, Thomas =
Narten <span dir=3D"ltr">
&lt;<a href=3D"mailto:narten@us.ibm.com" =
target=3D"_blank">narten@us.ibm.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" =
target=3D"_blank">http://datatracker.ietf.org/ipr/2315/</a> The IPR =
holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
&nbsp; &nbsp; Reasonable and Non-Discriminatory License to All =
Implementers with<br>
&nbsp; &nbsp; Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn't implement a problem statement, =
raising<br>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be =
made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking =
the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, =
IPR<br>
considerations can be one of the factors used in weighing the pros =
and<br>
cons of an approach. Some may decide that IPR is a significant =
issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or =
productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior =
art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other =
than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. =
&nbsp;If<br>
folk have concerns with the disclosure and its potential impact on =
the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would =
be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</div>

_______________________________________________<br>sfc mailing =
list<br><a =
href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>https://www.ietf.org/mail=
man/listinfo/sfc<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_91B77A4C-D8F2-49A3-B8B6-A4E010084717--

--Apple-Mail=_709BDAFC-5C61-4276-A024-FC0C30D5A859
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 - https://gpgtools.org

iQIcBAEBCgAGBQJTpKOoAAoJEPcO+I7eiUJZL28P/3BRGc5G+oCP26hEfdRRBJvu
Ai0eDXqYKFKXoUvFW6OQM7AA+NcSGCnXwRSTydgJzS46vq5yyPWXpfFaCE5mD6B8
XV3IhKd/9H3CsMxyf9kKqPqyEphyFloCsVzXyM+iKh3S0ynKyVI9yB+9rqITmtiP
KYHG+/EFXho2l5m+Mw93Xf46dZNutKidXbO/Euw5THEdcahHNAWMly4d0x4JVc5I
HuUIvxKKtwzltn3+nDQWmgmMfe7nidGvXtuc1ROoSdeU5bN5zVeKD3N6M1tD4yrj
IAZMOkNh15gSONyqkREYfzmPF4uTqLUdkKHkIIqgVrZOpnfllxxnuZaG2P5CDf+b
trLS55xm2h84r1seJDnEjfypgoy08+5PK/xpdcQ0bESrNWa99lpSdJ3+jI9gBOEE
D6F1SNCPDfIFi+tp5Hei1feddz+UaVSNGGjzOsdl16FA8QeugKBaOn9Dc5XCgXcr
H4bBV+9f0xTKaXUd6nqvX3bZ6JARTa0nsMqNWgY7654t2aASuj2xJ3NuI8OWY/ci
SnovOFZL3XQpL03D+RLYF4XjFyzGEYB0iR0hW6c/gYam8m9QhxdvbJNpeLe+8ihf
5YCVGUFlBm9QIywhmEPZnMF62MinCNgPT7VqsP6LBRvu/9XevTMuo+TIjTGtvtmM
5oGCtbdH9K/Dn+/DNCdM
=2sRE
-----END PGP SIGNATURE-----

--Apple-Mail=_709BDAFC-5C61-4276-A024-FC0C30D5A859--


From nobody Fri Jun 20 14:18:00 2014
Return-Path: <jguichar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F83C1A03F7 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY-T9deQlpUk for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:17:56 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB5C1A026A for <sfc@ietf.org>; Fri, 20 Jun 2014 14:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10651; q=dns/txt; s=iport; t=1403299076; x=1404508676; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AS+PgM7YpkXVBRNg9XoR041INaLwT5udTKoa3ovvsow=; b=SLKW0YxReARq7xSvaQfrV/O3lBb1UjAtdUNS+cOcm9BGZOCwuQZm2iZn uQiqnpqWhrdgBWSjUCmx/oWFloR5l0lFu0aO+2X4s8SswsXIBTp6q+wFA l6bRdM6JVtJGWeFZc5JiFfZLIQDLwLbZDEfquvZv7DHRbD5eVf8w1RwSQ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au8bACCkpFOtJV2c/2dsb2JhbABTBoJGR1JaqiABAQEBAQEFAYMJjQ2BVQGHPgFCSxZ1hAMBAQEEAQEBawsQAgEIEQMBAigHIQYLFAkIAgQBDQUbiBMDEQ3DWA2GSxeFYoZxgUERAQ0yDQQHhEMEmEuBeYFDjBWGAoNCgXc5
X-IronPort-AV: E=Sophos;i="5.01,516,1400025600";  d="scan'208,217";a="334658311"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jun 2014 21:17:56 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5KLHtAT031956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 21:17:55 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.12]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 16:17:55 -0500
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "Andrew G. Malis" <agmalis@gmail.com>, Thomas Narten <narten@us.ibm.com>
Thread-Topic: [sfc] IPR Disclosure on SFC work
Thread-Index: AQHPjJg79cDfjvWXLEyrAM0poq9OyJt6tBcA///doYA=
Date: Fri, 20 Jun 2014 21:17:54 +0000
Message-ID: <CFCA1C33.2B16C%jguichar@cisco.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
In-Reply-To: <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.98.43.180]
Content-Type: multipart/alternative; boundary="_000_CFCA1C332B16Cjguicharciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AJLb6Ng-W7wFRfUPRTAhYsYZ4O0
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 21:17:59 -0000

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

Hi Andy,

I think it is appropriate to point out that an IPR holder has no obligation=
 whatsoever to provide a summary of the scope of their IPR and further it i=
s up to any interested party to go read the patent disclosure and make thei=
r own assessment. As Thomas quite rightly pointed out in his email "the IET=
F cannot and does not make determinations as to whether IPR is valid .. Tho=
se sorts of issues are resolved outside of the IETF=94.

From: "Andrew G. Malis" <agmalis@gmail.com<mailto:agmalis@gmail.com>>
Date: Friday, June 20, 2014 at 3:20 PM
To: Thomas Narten <narten@us.ibm.com<mailto:narten@us.ibm.com>>
Cc: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: Re: [sfc] IPR Disclosure on SFC work

Thomas,

In the previous discussion, there were several requests for the IPR holder =
to give a summary of the scope of the IPR and how it applies to the problem=
 statement. I would personally feel more comfortable about supporting the d=
ocument as it stands if this question was answered. But as it is, we're in =
the dark regarding how to proceed.

Cheers,
Andy


On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com<mailto:na=
rten@us.ibm.com>> wrote:
WG:

As has been noted before, an IPR disclosure has been made on the SFC
problem statement document
(draft-ietf-sfc-problem-statement-06.txt). Per
http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
indicates that their licensing terms would be:

    Reasonable and Non-Discriminatory License to All Implementers with
    Possible Royalty/Fee.

As has been noted, it is unusual to see an IPR declaration on a
problem statement. One doesn't implement a problem statement, raising
the question of what it means to make an IPR disclosure on a problem
statement. While there are several interpretations that could be made,
it was suggested in an earlier thread that the IPR may have broad
applicability, and that it might be difficult for the SFC WG to
develop solutions that are not potentially encumbered.

When IPR disclosures have been made, WGs have the option of taking the
potential IPR into consideration as they do their work. For example,
when selecting between competing approaches to solving a problem, IPR
considerations can be one of the factors used in weighing the pros and
cons of an approach. Some may decide that IPR is a significant issue,
others may consider disclosed IPR to be a minor factor.

The IETF handling of IPR is covered in detail in RFCs 3979 and
2026. There are aspects of IPR that are not appropriate or productive
to discuss within the WG, because at the end of the day, the IETF
cannot and does not make determinations as to whether IPR is valid,
whether it applies to a given technology, whether there is prior art,
etc. Those sorts of issues are resolved outside of the IETF.

In discussing IPR within the IETF, individual IETF participants can
indicate that they have concerns about IPR, and that those concerns
lead them to take certain positions on specific issues. For example,
IPR concerns could lead to a preference for one technical approach
over another, or in extreme cases, that work in a particular area
should not be pursued at all.

As always, WGs act on consensus, and IPR concerns are no different.
While there have been some postings indiciating unhappiness with the
disclosure, the chairs do not see consensus for any action other than
to continue on, keeping in mind that a disclosure has been made.

In summary, SFC participants should be aware of and examine the
disclosure to determine if they have any special concerns. Given the
disclosure was made on the problem statement, we should not be
surprised if a similar disclosure is made on future SFC documents.  If
folk have concerns with the disclosure and its potential impact on the
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
a good time to raise the issue.

Thomas (chair hat on)

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc


--_000_CFCA1C332B16Cjguicharciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <F997B97752AB2F459657B58D74D16848@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>Hi Andy,</div>
<div><br>
</div>
<div>I think it is appropriate to point out that an IPR holder has no oblig=
ation whatsoever to provide a summary of the scope of their IPR and further=
 it is up to any interested party to go read the patent disclosure and make=
 their own assessment. As Thomas
 quite rightly pointed out in his email &quot;the IETF cannot and does not =
make determinations as to whether IPR is valid .. Those sorts of issues are=
 resolved outside of the IETF=94.&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>&quot;Andrew G. Malis&quot; &=
lt;<a href=3D"mailto:agmalis@gmail.com">agmalis@gmail.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Friday, June 20, 2014 at 3:20=
 PM<br>
<span style=3D"font-weight:bold">To: </span>Thomas Narten &lt;<a href=3D"ma=
ilto:narten@us.ibm.com">narten@us.ibm.com</a>&gt;<br>
<span style=3D"font-weight:bold">Cc: </span>&quot;<a href=3D"mailto:sfc@iet=
f.org">sfc@ietf.org</a>&quot; &lt;<a href=3D"mailto:sfc@ietf.org">sfc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>Re: [sfc] IPR Disclosure o=
n SFC work<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir=3D"ltr">Thomas,
<div><br>
</div>
<div>In the previous discussion, there were several requests for the IPR ho=
lder to give a summary of the scope of the IPR and how it applies to the pr=
oblem statement. I would personally feel more comfortable about supporting =
the document as it stands if this
 question was answered. But as it is, we're in the dark regarding how to pr=
oceed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Andy</div>
</div>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <=
span dir=3D"ltr">
&lt;<a href=3D"mailto:narten@us.ibm.com" target=3D"_blank">narten@us.ibm.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" target=3D"_blank">http://=
datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
&nbsp; &nbsp; Reasonable and Non-Discriminatory License to All Implementers=
 with<br>
&nbsp; &nbsp; Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn't implement a problem statement, raising<br>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, IPR<br>
considerations can be one of the factors used in weighing the pros and<br>
cons of an approach. Some may decide that IPR is a significant issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. &nbsp;If=
<br>
folk have concerns with the disclosure and its potential impact on the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_CFCA1C332B16Cjguicharciscocom_--


From nobody Fri Jun 20 14:26:05 2014
Return-Path: <bensons@queuefull.net>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C26C1B28E8 for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsfhlhqk0JxM for <sfc@ietfa.amsl.com>; Fri, 20 Jun 2014 14:26:01 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49621A019A for <sfc@ietf.org>; Fri, 20 Jun 2014 14:26:00 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id hw13so3715526qab.31 for <sfc@ietf.org>; Fri, 20 Jun 2014 14:25:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1M/8aGJQGTSG5OhkAOX0uI/3n4Up3AX49UQ5ScheiiQ=; b=B3hAGPXxOm9+PKG1roHFUEOPzGSh25SDpbqoQs0H6O/CvmNqBl+xC/shYVaXqGTtBX 8eydtn9SEsCjljJCrUx0dA4tSCqN7dC5zZFwrysKo5dc5BHn9AzO9cCiY+Zd3J9/qoPG 9MVqF2ZjQ3IMuM+lNYk3jIsKco4rQBRWXFxQZIpKVTMkbgLZ5lR4rKGqJJ19ElMoEEVd HBXSG70L4K0FNkv/VKBCSeSQsusoD9HclIJoynKnVABlZyXTQKw6LuUkXxhFWilJEWJD nPv9+SEbkTDp/M0PaloGjKntsnHj17FiTKp242VyPcJPAHB/ehczeYjuRZFQqk8gkVBY lcvw==
X-Gm-Message-State: ALoCoQnN04yTEVVnOiT7ITCH1dQzae2JKcVQm+psI2qgkojlRMbe5yIt8WCEFP6I6JCcCTHr9szO
MIME-Version: 1.0
X-Received: by 10.140.47.16 with SMTP id l16mr8714091qga.24.1403299559429; Fri, 20 Jun 2014 14:25:59 -0700 (PDT)
Received: by 10.140.24.202 with HTTP; Fri, 20 Jun 2014 14:25:59 -0700 (PDT)
In-Reply-To: <m3ionvsk3u.wl%narten@us.ibm.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com>
Date: Fri, 20 Jun 2014 17:25:59 -0400
Message-ID: <CAP4=VcgetTGaCOCB3nkm6nrSacCpSgfeihhV5C93aSS2Qz6vqw@mail.gmail.com>
From: Benson Schliesser <bensons@queuefull.net>
To: sfc@ietf.org
Content-Type: multipart/alternative; boundary=001a11c14a30c0ff6004fc4b2306
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CCCGFZBgeSv9Xzmg336ZIE7BklQ
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jun 2014 21:26:03 -0000

--001a11c14a30c0ff6004fc4b2306
Content-Type: text/plain; charset=UTF-8

I agree with the chairs' conclusion that the WG should "continue on,
keeping in mind that a disclosure has been made".

I also advise participants to read the patent for themselves (
http://www.google.com/patents/US7200679) and consult with their own
counsel. However amusing the discussion may be, legal questions about the
intellectual property cannot be resolved here on an IETF WG mailing list.

Cheers,
-Benson


On Fri, Jun 20, 2014 at 10:59 AM, Thomas Narten <narten@us.ibm.com> wrote:

> WG:
>
> As has been noted before, an IPR disclosure has been made on the SFC
> problem statement document
> (draft-ietf-sfc-problem-statement-06.txt). Per
> http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
> indicates that their licensing terms would be:
>
>     Reasonable and Non-Discriminatory License to All Implementers with
>     Possible Royalty/Fee.
>
> As has been noted, it is unusual to see an IPR declaration on a
> problem statement. One doesn't implement a problem statement, raising
> the question of what it means to make an IPR disclosure on a problem
> statement. While there are several interpretations that could be made,
> it was suggested in an earlier thread that the IPR may have broad
> applicability, and that it might be difficult for the SFC WG to
> develop solutions that are not potentially encumbered.
>
> When IPR disclosures have been made, WGs have the option of taking the
> potential IPR into consideration as they do their work. For example,
> when selecting between competing approaches to solving a problem, IPR
> considerations can be one of the factors used in weighing the pros and
> cons of an approach. Some may decide that IPR is a significant issue,
> others may consider disclosed IPR to be a minor factor.
>
> The IETF handling of IPR is covered in detail in RFCs 3979 and
> 2026. There are aspects of IPR that are not appropriate or productive
> to discuss within the WG, because at the end of the day, the IETF
> cannot and does not make determinations as to whether IPR is valid,
> whether it applies to a given technology, whether there is prior art,
> etc. Those sorts of issues are resolved outside of the IETF.
>
> In discussing IPR within the IETF, individual IETF participants can
> indicate that they have concerns about IPR, and that those concerns
> lead them to take certain positions on specific issues. For example,
> IPR concerns could lead to a preference for one technical approach
> over another, or in extreme cases, that work in a particular area
> should not be pursued at all.
>
> As always, WGs act on consensus, and IPR concerns are no different.
> While there have been some postings indiciating unhappiness with the
> disclosure, the chairs do not see consensus for any action other than
> to continue on, keeping in mind that a disclosure has been made.
>
> In summary, SFC participants should be aware of and examine the
> disclosure to determine if they have any special concerns. Given the
> disclosure was made on the problem statement, we should not be
> surprised if a similar disclosure is made on future SFC documents.  If
> folk have concerns with the disclosure and its potential impact on the
> work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
> a good time to raise the issue.
>
> Thomas (chair hat on)
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>

--001a11c14a30c0ff6004fc4b2306
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree with the chairs&#39; conclusion that the WG should=
 &quot;<span style=3D"font-family:arial,sans-serif;font-size:13px">continue=
 on, keeping in mind that a disclosure has been made&quot;.</span><div><fon=
t face=3D"arial, sans-serif"><br>
</font></div><div><font face=3D"arial, sans-serif">I also advise participan=
ts to read the patent for themselves (<a href=3D"http://www.google.com/pate=
nts/US7200679">http://www.google.com/patents/US7200679</a>) and consult wit=
h their own counsel. However amusing the discussion may be, legal questions=
 about the intellectual property cannot be resolved here on an IETF WG mail=
ing list.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Cheers,</font></div><div><font face=3D"arial, sans-serif"=
>-Benson<br></font><div><div class=3D"gmail_extra"><br><br><div class=3D"gm=
ail_quote">
On Fri, Jun 20, 2014 at 10:59 AM, Thomas Narten <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:narten@us.ibm.com" target=3D"_blank">narten@us.ibm.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex">
WG:<br>
<br>
As has been noted before, an IPR disclosure has been made on the SFC<br>
problem statement document<br>
(draft-ietf-sfc-problem-statement-06.txt). Per<br>
<a href=3D"http://datatracker.ietf.org/ipr/2315/" target=3D"_blank">http://=
datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
indicates that their licensing terms would be:<br>
<br>
=C2=A0 =C2=A0 Reasonable and Non-Discriminatory License to All Implementers=
 with<br>
=C2=A0 =C2=A0 Possible Royalty/Fee.<br>
<br>
As has been noted, it is unusual to see an IPR declaration on a<br>
problem statement. One doesn&#39;t implement a problem statement, raising<b=
r>
the question of what it means to make an IPR disclosure on a problem<br>
statement. While there are several interpretations that could be made,<br>
it was suggested in an earlier thread that the IPR may have broad<br>
applicability, and that it might be difficult for the SFC WG to<br>
develop solutions that are not potentially encumbered.<br>
<br>
When IPR disclosures have been made, WGs have the option of taking the<br>
potential IPR into consideration as they do their work. For example,<br>
when selecting between competing approaches to solving a problem, IPR<br>
considerations can be one of the factors used in weighing the pros and<br>
cons of an approach. Some may decide that IPR is a significant issue,<br>
others may consider disclosed IPR to be a minor factor.<br>
<br>
The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
2026. There are aspects of IPR that are not appropriate or productive<br>
to discuss within the WG, because at the end of the day, the IETF<br>
cannot and does not make determinations as to whether IPR is valid,<br>
whether it applies to a given technology, whether there is prior art,<br>
etc. Those sorts of issues are resolved outside of the IETF.<br>
<br>
In discussing IPR within the IETF, individual IETF participants can<br>
indicate that they have concerns about IPR, and that those concerns<br>
lead them to take certain positions on specific issues. For example,<br>
IPR concerns could lead to a preference for one technical approach<br>
over another, or in extreme cases, that work in a particular area<br>
should not be pursued at all.<br>
<br>
As always, WGs act on consensus, and IPR concerns are no different.<br>
While there have been some postings indiciating unhappiness with the<br>
disclosure, the chairs do not see consensus for any action other than<br>
to continue on, keeping in mind that a disclosure has been made.<br>
<br>
In summary, SFC participants should be aware of and examine the<br>
disclosure to determine if they have any special concerns. Given the<br>
disclosure was made on the problem statement, we should not be<br>
surprised if a similar disclosure is made on future SFC documents. =C2=A0If=
<br>
folk have concerns with the disclosure and its potential impact on the<br>
work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
a good time to raise the issue.<br>
<br>
Thomas (chair hat on)<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
</blockquote></div><br></div></div></div></div>

--001a11c14a30c0ff6004fc4b2306--


From nobody Mon Jun 23 20:44:07 2014
Return-Path: <youjianjie@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091C41B2822; Mon, 23 Jun 2014 20:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level: 
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU6A_0JG-Zyc; Mon, 23 Jun 2014 20:44:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07211B2820; Mon, 23 Jun 2014 20:43:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJC82429; Tue, 24 Jun 2014 03:43:58 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 04:43:55 +0100
Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.190]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 11:43:49 +0800
From: Youjianjie <youjianjie@huawei.com>
To: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: New Version Notification for draft-xu-spring-pce-based-sfc-arch-01.txt
Thread-Index: AQHPjoXETBvlXj6nGECQlyeYgb9gNZt9+HfAgAGl/QA=
Date: Tue, 24 Jun 2014 03:43:48 +0000
Message-ID: <F6C28B32DA084644BB6C8D0BD65B669D0F8611@nkgeml509-mbs.china.huawei.com>
References: <F6C28B32DA084644BB6C8D0BD65B669D0F8489@nkgeml509-mbs.china.huawei.com>
In-Reply-To: <F6C28B32DA084644BB6C8D0BD65B669D0F8489@nkgeml509-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.173]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KYCa0TzbMj1k2gHl9GT96fudi_s
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: [sfc] =?utf-8?b?562U5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xu-spring-pce-based-sfc-arch-01=2Etxt?=
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 03:44:03 -0000

SGkgYWxsLA0KDQpUaGUgY29ycmVzcG9uZGluZyBleHRlbnNpb25zIHRvIHRoZSBQQ0VQIGluIHRo
aXMgZHJhZnQgKGRyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEpIGFyZSBkZXNj
cmliZWQgaW4gZHJhZnQteHUtcGNlLXNyLXNmYy0wMToNCg0KVVJMOiAgICAgICAgICAgaHR0cDov
L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtcGNlLXNyLXNmYy0wMS50eHQg
DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
eHUtcGNlLXNyLXNmYy8NCg0KQXMgYWx3YXlzLCB5b3VyIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRl
ZCENCg0KSmlhbmppZQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHNwcmlu
ZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggWW91amlhbmppZQ0K5Y+R
6YCB5pe26Ze0OiAyMDE05bm0NuaciDIz5pelIDEwOjMzDQrmlLbku7bkuro6IDxzcHJpbmdAaWV0
Zi5vcmc+DQrkuLvpopg6IFtzcHJpbmddIOi9rOWPkTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u
IGZvciBkcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1hcmNoLTAxLnR4dA0KDQpIaSBhbGws
DQoNClRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgUENFLWJhc2VkIFNGQyBhcmNoaXRlY3R1cmUgaW4g
U1IgbmV0d29ya3MuIEluIHRoaXMgYXJjaGl0ZWN0dXJlLCB0aGUgUENFIGlzIHVzZWQgdG8gY29t
cHV0ZSBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCAoU0ZQKS4NCg0KWW91ciBjb21tZW50cyBhcmUg
YXBwcmVjaWF0ZWQhDQoNCkF1dGhvcnMNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu2
5Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0NuaciDIz5pelIDk6NTINCuaUtuS7tuS6ujog
THVpcyBNLiBDb250cmVyYXM7IFh1eGlhb2h1OyBZb3VqaWFuamllOyBYdXhpYW9odTsgSGltYW5z
aHUgU2hhaDsgSGltYW5zaHUgQy4gU2hhaDsgWW91amlhbmppZTsgTHVpcyBNLiBDb250cmVyYXMN
CuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciB0DQoNCg0KQSBuZXcgdmVyc2lv
biBvZiBJLUQsIGRyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEudHh0DQpoYXMg
YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRo
ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNm
Yy1hcmNoDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJUENFLWJhc2VkIFNGQyBBcmNoaXRlY3R1cmUg
aW4gU1IgTmV0d29ya3MNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMjINCkdyb3VwOgkJSW5kaXZp
ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1hcmNo
LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gvDQpIdG1saXplZDogICAgICAgaHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJj
aC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy
YWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDENCg0KQWJzdHJhY3Q6DQogICBTZXJ2
aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIHByb3ZpZGVzIGEgZmxleGlibGUgd2F5IHRvIGNv
bnN0cnVjdA0KICAgc2VydmljZXMuICBXaGVuIGFwcGx5aW5nIGEgcGFydGljdWxhciBzZXJ2aWNl
IGZ1bmN0aW9uIGNoYWluIHRvIHRoZQ0KICAgdHJhZmZpYywgdGhlIHRyYWZmaWMgbmVlZHMgdG8g
YmUgc3RlZXJlZCB0aHJvdWdoIGFuIG9yZGVyZWQgc2V0IG9mDQogICBzZXJ2aWNlIGZ1bmN0aW9u
cyBpbiB0aGUgbmV0d29yay4gIFRoaXMgb3JkZXJlZCBzZXQgb2Ygc2VydmljZQ0KICAgZnVuY3Rp
b25zIGluIHRoZSBuZXR3b3JrLCByZWZlcnJlZCB0byBhcyBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0
aA0KICAgKFNGUCksIGlzIGFuIGluc3RhbnRpYXRpb24gb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb24g
Y2hhaW4gaW4gdGhlDQogICBuZXR3b3JrLiAgU2VnbWVudCBSb3V0aW5nIChTUikgdGVjaG5pcXVl
IGNhbiBiZSBsZXZlcmFnZWQgdG8gc3RlZXINCiAgIHRoZSB0cmFmZmljIHRocm91Z2ggdGhlIFNG
UCBpbiBTUiBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzDQogICBhIFBDRS1iYXNl
ZCBTRkMgYXJjaGl0ZWN0dXJlIGluIHdoaWNoIHRoZSBQQ0UgaXMgdXNlZCB0byBjb21wdXRlIGEN
CiAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCAoaS5lLiwgaW5zdGFudGlhdGUgYSBzZXJ2aWNlIGZ1
bmN0aW9uIGNoYWluKSBpbg0KICAgU1IgbmV0d29ya3MuDQoNCg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu
dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp
b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYg
U2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg==


From nobody Tue Jun 24 06:06:43 2014
Return-Path: <narten@us.ibm.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665BB1B29AD for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 06:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.653
X-Spam-Level: 
X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PoXy5kjZwL8 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 06:06:33 -0700 (PDT)
Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DAC1B2953 for <sfc@ietf.org>; Tue, 24 Jun 2014 06:06:27 -0700 (PDT)
Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <sfc@ietf.org> from <narten@us.ibm.com>; Tue, 24 Jun 2014 07:06:27 -0600
Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Tue, 24 Jun 2014 07:06:26 -0600
Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 0A8413E4004E for <sfc@ietf.org>; Tue, 24 Jun 2014 07:06:25 -0600 (MDT)
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by b03cxnp07029.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s5OB2sjE10813894 for <sfc@ietf.org>; Tue, 24 Jun 2014 13:02:54 +0200
Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s5OD6O4k023929 for <sfc@ietf.org>; Tue, 24 Jun 2014 07:06:24 -0600
Received: from cichlid.raleigh.ibm.com ([9.80.93.120]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s5OD6Nlo023781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Jun 2014 07:06:24 -0600
Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s5OD6MhZ023337; Tue, 24 Jun 2014 09:06:22 -0400
Date: Tue, 24 Jun 2014 09:06:22 -0400
Message-ID: <m3pphysbht.wl%narten@us.ibm.com>
From: Thomas Narten <narten@us.ibm.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
In-Reply-To: <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14062413-9332-0000-0000-0000012EA07F
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xX8ZzTO_KMEJxphbEB5Y2PzpXc8
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 13:06:38 -0000

Andy,

> In the previous discussion, there were several requests for the IPR holde=
r to
> give a summary of the scope of the IPR and how it applies to the problem
> statement. I would personally feel more comfortable about supporting the
> document as it stands if this question was answered. But as it is, we're =
in
> the dark regarding how to proceed.

You and I have both been IETF participants for a long time. We both
have a lot of experience with IPR disclosures made in other WGs and on
other documents. In how many of those cases has an IPR holder given "a
summary of the scope of the IPR and how it applies"? And in how many
of those cases has such a summary actually made a difference in how a
WG proceeds?

While you (or I) might feel more comfortable with additional
clarification, how would that actually change what the WG can or
should do?=20

Are you suggesting we halt or delay work while we attempt to get more
information? If so, for how long? And what if we don't get more
information? RFC 3979 makes it clear that there is no certainty we
would obtain additional information:

> 6.4.1.  The disclosure must list the numbers of any issued patents or
>    published patent applications or indicate that the claim is based on
>    unpublished patent applications.  The disclosure must also list the
>    specific IETF or RFC Editor Document(s) or activity affected.  If the
>    IETF Document is an Internet-Draft, it must be referenced by specific
>    version number.  In addition, if the IETF Document includes multiple
>    parts and it is not reasonably apparent which part of such IETF
>    Document is alleged to be Covered by the IPR in question, it is
>    helpful if the discloser identifies the sections of the IETF Document
>    that are alleged to be so Covered.

Note that the last sentence only says "it is helpful". There is no
requirement. And if the last ten years worth of existing disclosures
is any indication, few disclosures include such information. (I don't
know of any right off, but maybe there are a few.)

Note also that RFC 3979 says:

>    (C) Where Intellectual Property Rights have been disclosed for IETF
>        Documents as provided in Section 6 of this document, the IETF
>        Executive Director shall request from the discloser of such IPR,
>        a written assurance that upon approval by the IESG for
>        publication as RFCs of the relevant IETF specification(s), all
>        persons will be able to obtain the right to implement, use,
>        distribute and exercise other rights with respect to Implementing
>        Technology under one of the licensing options specified in
>        Section 6.5 below unless such a statement has already been
>        submitted.  The working group proposing the use of the technology
>        with respect to which the Intellectual Property Rights are
>        disclosed may assist the IETF Executive Director in this effort.

Note that the above  has already been done, i.e., the disclosure
itself.

>        The results of this procedure shall not, in themselves, block
>        publication of an IETF Document or advancement of an IETF
>        Document along the standards track.  A working group may take
>        into consideration the results of this procedure in evaluating
>        the technology, and the IESG may defer approval when a delay may
>        facilitate obtaining such assurances.  The results will, however,
>        be recorded by the IETF Executive Director, and be made available
>        online.

The above says nothing about delaying documents once a disclosure
meeting the RFC 3979 requirements has been made.

So please be clear. Do you have a specific proposed action for the WG
to take other than proceed with its work?

Wanting to be more "comfortable" is not actionable.

Thomas

>=20
> On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com> wrote:
>=20
>     WG:
>   =20
>     As has been noted before, an IPR disclosure has been made on the SFC
>     problem statement document
>     (draft-ietf-sfc-problem-statement-06.txt). Per
>     http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
>     indicates that their licensing terms would be:
>   =20
>     =A0 =A0 Reasonable and Non-Discriminatory License to All Implementers=
 with
>     =A0 =A0 Possible Royalty/Fee.
>   =20
>     As has been noted, it is unusual to see an IPR declaration on a
>     problem statement. One doesn't implement a problem statement, raising
>     the question of what it means to make an IPR disclosure on a problem
>     statement. While there are several interpretations that could be made,
>     it was suggested in an earlier thread that the IPR may have broad
>     applicability, and that it might be difficult for the SFC WG to
>     develop solutions that are not potentially encumbered.
>   =20
>     When IPR disclosures have been made, WGs have the option of taking the
>     potential IPR into consideration as they do their work. For example,
>     when selecting between competing approaches to solving a problem, IPR
>     considerations can be one of the factors used in weighing the pros and
>     cons of an approach. Some may decide that IPR is a significant issue,
>     others may consider disclosed IPR to be a minor factor.
>   =20
>     The IETF handling of IPR is covered in detail in RFCs 3979 and
>     2026. There are aspects of IPR that are not appropriate or productive
>     to discuss within the WG, because at the end of the day, the IETF
>     cannot and does not make determinations as to whether IPR is valid,
>     whether it applies to a given technology, whether there is prior art,
>     etc. Those sorts of issues are resolved outside of the IETF.
>   =20
>     In discussing IPR within the IETF, individual IETF participants can
>     indicate that they have concerns about IPR, and that those concerns
>     lead them to take certain positions on specific issues. For example,
>     IPR concerns could lead to a preference for one technical approach
>     over another, or in extreme cases, that work in a particular area
>     should not be pursued at all.
>   =20
>     As always, WGs act on consensus, and IPR concerns are no different.
>     While there have been some postings indiciating unhappiness with the
>     disclosure, the chairs do not see consensus for any action other than
>     to continue on, keeping in mind that a disclosure has been made.
>   =20
>     In summary, SFC participants should be aware of and examine the
>     disclosure to determine if they have any special concerns. Given the
>     disclosure was made on the problem statement, we should not be
>     surprised if a similar disclosure is made on future SFC documents. =
=A0If
>     folk have concerns with the disclosure and its potential impact on the
>     work SFC has been chartered to do, now (i.e, in next 2 weeks) would be
>     a good time to raise the issue.
>   =20
>     Thomas (chair hat on)
>   =20
>     _______________________________________________
>     sfc mailing list
>     sfc@ietf.org
>     https://www.ietf.org/mailman/listinfo/sfc
>=20
>=20


From nobody Tue Jun 24 10:13:37 2014
Return-Path: <agmalis@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF411B2E3C for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 10:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of4EjZTkvCDr for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 10:13:29 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649981B2BAB for <sfc@ietf.org>; Tue, 24 Jun 2014 10:12:57 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id i50so548610qgf.26 for <sfc@ietf.org>; Tue, 24 Jun 2014 10:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ISIYkr7WXivpkQHWV5aTAApXQHVyIgjpNPgPaliA6bM=; b=AYeNjAI1LaPe8SXgzhXQYrsbopJrdE/f7eyO0bEYqA1k15lDrR5lytJE+17EAzuPUd DoCxgQblEiKFilruMPJYViFcLMwCeRsJAGTX0CaJobpijNtSyST3bU7kI9lXsDk2/H6y RyJn1ztsW7JsvUDtJPLHQ8C+PPvbo2U6SHEoP5QKTFGhFneatwz66tWV+2qQJEkv6WW4 pZOfSOJhvl4bnGtNP8xrlvZ/1TqJVsdAtc6+q4ZNW1yP9CF3ckJgIBlCO8DIPm6cVTfE fb2R+214P+fjSHEgsA/IPkksuOa0IfJGthFK1gaGm5/lmbe6UHM7z0QuuKyj4dA7yx/2 +I+A==
X-Received: by 10.224.119.198 with SMTP id a6mr3790554qar.39.1403629976357; Tue, 24 Jun 2014 10:12:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.28.2 with HTTP; Tue, 24 Jun 2014 10:12:36 -0700 (PDT)
In-Reply-To: <m3pphysbht.wl%narten@us.ibm.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com> <m3pphysbht.wl%narten@us.ibm.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Tue, 24 Jun 2014 13:12:36 -0400
Message-ID: <CAA=duU2y-m2OzZzA_PO8p0=M=gYKigPrbqe-J450wN32P8=kTQ@mail.gmail.com>
To: Thomas Narten <narten@us.ibm.com>
Content-Type: multipart/alternative; boundary=001a11c2e6e023138704fc98123a
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/sRvEKHwknv8llE7LTiU_ZxkjzkU
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 17:13:34 -0000

--001a11c2e6e023138704fc98123a
Content-Type: text/plain; charset=UTF-8

Thomas,

Actually, there have been cases where IPR holders have worked with a WG to
clear up questions or concerns regarding IP. We recently had a case in PWE3
where a somewhat late disclosure was worked out with the IP holder by
removing a particular procedure that was covered by the IP. So anything is
possible.

In this case, I think we're all in agreement that it's exceptional to see
an IPR statement against a problem statement document. It would be useful
for the WG to have a reasonable understanding of the IPR holder's thinking
in this matter, since all we can do otherwise is read the IPR and speculate
on our own.  Is ANYTHING the WG does going to be claimed to infringe this
IPR? Are there reasonable technical alternatives? I just think it's better
to be informed than not, and earlier rather than later when we start to
write standards track drafts.

I also realize that the WG can't always expect cooperation on the part of
IPR holders. But in some cases, they do cooperate in good will. It can't
hurt to ask the question.

Cheers,
Andy


On Tue, Jun 24, 2014 at 9:06 AM, Thomas Narten <narten@us.ibm.com> wrote:

> Andy,
>
> > In the previous discussion, there were several requests for the IPR
> holder to
> > give a summary of the scope of the IPR and how it applies to the problem
> > statement. I would personally feel more comfortable about supporting the
> > document as it stands if this question was answered. But as it is, we're
> in
> > the dark regarding how to proceed.
>
> You and I have both been IETF participants for a long time. We both
> have a lot of experience with IPR disclosures made in other WGs and on
> other documents. In how many of those cases has an IPR holder given "a
> summary of the scope of the IPR and how it applies"? And in how many
> of those cases has such a summary actually made a difference in how a
> WG proceeds?
>
> While you (or I) might feel more comfortable with additional
> clarification, how would that actually change what the WG can or
> should do?
>
> Are you suggesting we halt or delay work while we attempt to get more
> information? If so, for how long? And what if we don't get more
> information? RFC 3979 makes it clear that there is no certainty we
> would obtain additional information:
>
> > 6.4.1.  The disclosure must list the numbers of any issued patents or
> >    published patent applications or indicate that the claim is based on
> >    unpublished patent applications.  The disclosure must also list the
> >    specific IETF or RFC Editor Document(s) or activity affected.  If the
> >    IETF Document is an Internet-Draft, it must be referenced by specific
> >    version number.  In addition, if the IETF Document includes multiple
> >    parts and it is not reasonably apparent which part of such IETF
> >    Document is alleged to be Covered by the IPR in question, it is
> >    helpful if the discloser identifies the sections of the IETF Document
> >    that are alleged to be so Covered.
>
> Note that the last sentence only says "it is helpful". There is no
> requirement. And if the last ten years worth of existing disclosures
> is any indication, few disclosures include such information. (I don't
> know of any right off, but maybe there are a few.)
>
> Note also that RFC 3979 says:
>
> >    (C) Where Intellectual Property Rights have been disclosed for IETF
> >        Documents as provided in Section 6 of this document, the IETF
> >        Executive Director shall request from the discloser of such IPR,
> >        a written assurance that upon approval by the IESG for
> >        publication as RFCs of the relevant IETF specification(s), all
> >        persons will be able to obtain the right to implement, use,
> >        distribute and exercise other rights with respect to Implementing
> >        Technology under one of the licensing options specified in
> >        Section 6.5 below unless such a statement has already been
> >        submitted.  The working group proposing the use of the technology
> >        with respect to which the Intellectual Property Rights are
> >        disclosed may assist the IETF Executive Director in this effort.
>
> Note that the above  has already been done, i.e., the disclosure
> itself.
>
> >        The results of this procedure shall not, in themselves, block
> >        publication of an IETF Document or advancement of an IETF
> >        Document along the standards track.  A working group may take
> >        into consideration the results of this procedure in evaluating
> >        the technology, and the IESG may defer approval when a delay may
> >        facilitate obtaining such assurances.  The results will, however,
> >        be recorded by the IETF Executive Director, and be made available
> >        online.
>
> The above says nothing about delaying documents once a disclosure
> meeting the RFC 3979 requirements has been made.
>
> So please be clear. Do you have a specific proposed action for the WG
> to take other than proceed with its work?
>
> Wanting to be more "comfortable" is not actionable.
>
> Thomas
>
> >
> > On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com>
> wrote:
> >
> >     WG:
> >
> >     As has been noted before, an IPR disclosure has been made on the SFC
> >     problem statement document
> >     (draft-ietf-sfc-problem-statement-06.txt). Per
> >     http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
> >     indicates that their licensing terms would be:
> >
> >         Reasonable and Non-Discriminatory License to All Implementers
> with
> >         Possible Royalty/Fee.
> >
> >     As has been noted, it is unusual to see an IPR declaration on a
> >     problem statement. One doesn't implement a problem statement, raising
> >     the question of what it means to make an IPR disclosure on a problem
> >     statement. While there are several interpretations that could be
> made,
> >     it was suggested in an earlier thread that the IPR may have broad
> >     applicability, and that it might be difficult for the SFC WG to
> >     develop solutions that are not potentially encumbered.
> >
> >     When IPR disclosures have been made, WGs have the option of taking
> the
> >     potential IPR into consideration as they do their work. For example,
> >     when selecting between competing approaches to solving a problem, IPR
> >     considerations can be one of the factors used in weighing the pros
> and
> >     cons of an approach. Some may decide that IPR is a significant issue,
> >     others may consider disclosed IPR to be a minor factor.
> >
> >     The IETF handling of IPR is covered in detail in RFCs 3979 and
> >     2026. There are aspects of IPR that are not appropriate or productive
> >     to discuss within the WG, because at the end of the day, the IETF
> >     cannot and does not make determinations as to whether IPR is valid,
> >     whether it applies to a given technology, whether there is prior art,
> >     etc. Those sorts of issues are resolved outside of the IETF.
> >
> >     In discussing IPR within the IETF, individual IETF participants can
> >     indicate that they have concerns about IPR, and that those concerns
> >     lead them to take certain positions on specific issues. For example,
> >     IPR concerns could lead to a preference for one technical approach
> >     over another, or in extreme cases, that work in a particular area
> >     should not be pursued at all.
> >
> >     As always, WGs act on consensus, and IPR concerns are no different.
> >     While there have been some postings indiciating unhappiness with the
> >     disclosure, the chairs do not see consensus for any action other than
> >     to continue on, keeping in mind that a disclosure has been made.
> >
> >     In summary, SFC participants should be aware of and examine the
> >     disclosure to determine if they have any special concerns. Given the
> >     disclosure was made on the problem statement, we should not be
> >     surprised if a similar disclosure is made on future SFC documents.
>  If
> >     folk have concerns with the disclosure and its potential impact on
> the
> >     work SFC has been chartered to do, now (i.e, in next 2 weeks) would
> be
> >     a good time to raise the issue.
> >
> >     Thomas (chair hat on)
> >
> >     _______________________________________________
> >     sfc mailing list
> >     sfc@ietf.org
> >     https://www.ietf.org/mailman/listinfo/sfc
> >
> >
>
>

--001a11c2e6e023138704fc98123a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thomas,<div><br></div><div>Actually, there have been cases=
 where IPR holders have worked with a WG to clear up questions or concerns =
regarding IP. We recently had a case in PWE3 where a somewhat late disclosu=
re was worked out with the IP holder by removing a particular procedure tha=
t was covered by the IP. So anything is possible.</div>

<div><br></div><div>In this case, I think we&#39;re all in agreement that i=
t&#39;s exceptional to see an IPR statement against a problem statement doc=
ument. It would be useful for the WG to have a reasonable understanding of =
the IPR holder&#39;s thinking in this matter, since all we can do otherwise=
 is read the IPR and speculate on our own. =C2=A0Is ANYTHING the WG does go=
ing to be claimed to infringe this IPR? Are there reasonable technical alte=
rnatives? I just think it&#39;s better to be informed than not, and earlier=
 rather than later when we start to write standards track drafts.</div>

<div><br></div><div>I also realize that the WG can&#39;t always expect coop=
eration on the part of IPR holders. But in some cases, they do cooperate in=
 good will. It can&#39;t hurt to ask the question.</div><div><br></div>

<div>Cheers,</div><div>Andy</div></div><div class=3D"gmail_extra"><br><br><=
div class=3D"gmail_quote">On Tue, Jun 24, 2014 at 9:06 AM, Thomas Narten <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:narten@us.ibm.com" target=3D"_blank">=
narten@us.ibm.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Andy,<br>
<div class=3D""><br>
&gt; In the previous discussion, there were several requests for the IPR ho=
lder to<br>
&gt; give a summary of the scope of the IPR and how it applies to the probl=
em<br>
&gt; statement. I would personally feel more comfortable about supporting t=
he<br>
&gt; document as it stands if this question was answered. But as it is, we&=
#39;re in<br>
&gt; the dark regarding how to proceed.<br>
<br>
</div>You and I have both been IETF participants for a long time. We both<b=
r>
have a lot of experience with IPR disclosures made in other WGs and on<br>
other documents. In how many of those cases has an IPR holder given &quot;a=
<br>
summary of the scope of the IPR and how it applies&quot;? And in how many<b=
r>
of those cases has such a summary actually made a difference in how a<br>
WG proceeds?<br>
<br>
While you (or I) might feel more comfortable with additional<br>
clarification, how would that actually change what the WG can or<br>
should do?<br>
<br>
Are you suggesting we halt or delay work while we attempt to get more<br>
information? If so, for how long? And what if we don&#39;t get more<br>
information? RFC 3979 makes it clear that there is no certainty we<br>
would obtain additional information:<br>
<br>
&gt; 6.4.1. =C2=A0The disclosure must list the numbers of any issued patent=
s or<br>
&gt; =C2=A0 =C2=A0published patent applications or indicate that the claim =
is based on<br>
&gt; =C2=A0 =C2=A0unpublished patent applications. =C2=A0The disclosure mus=
t also list the<br>
&gt; =C2=A0 =C2=A0specific IETF or RFC Editor Document(s) or activity affec=
ted. =C2=A0If the<br>
&gt; =C2=A0 =C2=A0IETF Document is an Internet-Draft, it must be referenced=
 by specific<br>
&gt; =C2=A0 =C2=A0version number. =C2=A0In addition, if the IETF Document i=
ncludes multiple<br>
&gt; =C2=A0 =C2=A0parts and it is not reasonably apparent which part of suc=
h IETF<br>
&gt; =C2=A0 =C2=A0Document is alleged to be Covered by the IPR in question,=
 it is<br>
&gt; =C2=A0 =C2=A0helpful if the discloser identifies the sections of the I=
ETF Document<br>
&gt; =C2=A0 =C2=A0that are alleged to be so Covered.<br>
<br>
Note that the last sentence only says &quot;it is helpful&quot;. There is n=
o<br>
requirement. And if the last ten years worth of existing disclosures<br>
is any indication, few disclosures include such information. (I don&#39;t<b=
r>
know of any right off, but maybe there are a few.)<br>
<br>
Note also that RFC 3979 says:<br>
<br>
&gt; =C2=A0 =C2=A0(C) Where Intellectual Property Rights have been disclose=
d for IETF<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Documents as provided in Section 6 of this =
document, the IETF<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Executive Director shall request from the d=
iscloser of such IPR,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0a written assurance that upon approval by t=
he IESG for<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0publication as RFCs of the relevant IETF sp=
ecification(s), all<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0persons will be able to obtain the right to=
 implement, use,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0distribute and exercise other rights with r=
espect to Implementing<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Technology under one of the licensing optio=
ns specified in<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 6.5 below unless such a statement h=
as already been<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0submitted. =C2=A0The working group proposin=
g the use of the technology<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0with respect to which the Intellectual Prop=
erty Rights are<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0disclosed may assist the IETF Executive Dir=
ector in this effort.<br>
<br>
Note that the above =C2=A0has already been done, i.e., the disclosure<br>
itself.<br>
<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0The results of this procedure shall not, in=
 themselves, block<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0publication of an IETF Document or advancem=
ent of an IETF<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Document along the standards track. =C2=A0A=
 working group may take<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0into consideration the results of this proc=
edure in evaluating<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0the technology, and the IESG may defer appr=
oval when a delay may<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0facilitate obtaining such assurances. =C2=
=A0The results will, however,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0be recorded by the IETF Executive Director,=
 and be made available<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0online.<br>
<br>
The above says nothing about delaying documents once a disclosure<br>
meeting the RFC 3979 requirements has been made.<br>
<br>
So please be clear. Do you have a specific proposed action for the WG<br>
to take other than proceed with its work?<br>
<br>
Wanting to be more &quot;comfortable&quot; is not actionable.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Thomas<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt; On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten &lt;<a href=3D"mailto:n=
arten@us.ibm.com">narten@us.ibm.com</a>&gt; wrote:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 WG:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 As has been noted before, an IPR disclosure has been mad=
e on the SFC<br>
&gt; =C2=A0 =C2=A0 problem statement document<br>
&gt; =C2=A0 =C2=A0 (draft-ietf-sfc-problem-statement-06.txt). Per<br>
&gt; =C2=A0 =C2=A0 <a href=3D"http://datatracker.ietf.org/ipr/2315/" target=
=3D"_blank">http://datatracker.ietf.org/ipr/2315/</a> The IPR holder (Erics=
son)<br>
&gt; =C2=A0 =C2=A0 indicates that their licensing terms would be:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reasonable and Non-Discriminatory License =
to All Implementers with<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Possible Royalty/Fee.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 As has been noted, it is unusual to see an IPR declarati=
on on a<br>
&gt; =C2=A0 =C2=A0 problem statement. One doesn&#39;t implement a problem s=
tatement, raising<br>
&gt; =C2=A0 =C2=A0 the question of what it means to make an IPR disclosure =
on a problem<br>
&gt; =C2=A0 =C2=A0 statement. While there are several interpretations that =
could be made,<br>
&gt; =C2=A0 =C2=A0 it was suggested in an earlier thread that the IPR may h=
ave broad<br>
&gt; =C2=A0 =C2=A0 applicability, and that it might be difficult for the SF=
C WG to<br>
&gt; =C2=A0 =C2=A0 develop solutions that are not potentially encumbered.<b=
r>
&gt;<br>
&gt; =C2=A0 =C2=A0 When IPR disclosures have been made, WGs have the option=
 of taking the<br>
&gt; =C2=A0 =C2=A0 potential IPR into consideration as they do their work. =
For example,<br>
&gt; =C2=A0 =C2=A0 when selecting between competing approaches to solving a=
 problem, IPR<br>
&gt; =C2=A0 =C2=A0 considerations can be one of the factors used in weighin=
g the pros and<br>
&gt; =C2=A0 =C2=A0 cons of an approach. Some may decide that IPR is a signi=
ficant issue,<br>
&gt; =C2=A0 =C2=A0 others may consider disclosed IPR to be a minor factor.<=
br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The IETF handling of IPR is covered in detail in RFCs 39=
79 and<br>
&gt; =C2=A0 =C2=A0 2026. There are aspects of IPR that are not appropriate =
or productive<br>
&gt; =C2=A0 =C2=A0 to discuss within the WG, because at the end of the day,=
 the IETF<br>
&gt; =C2=A0 =C2=A0 cannot and does not make determinations as to whether IP=
R is valid,<br>
&gt; =C2=A0 =C2=A0 whether it applies to a given technology, whether there =
is prior art,<br>
&gt; =C2=A0 =C2=A0 etc. Those sorts of issues are resolved outside of the I=
ETF.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 In discussing IPR within the IETF, individual IETF parti=
cipants can<br>
&gt; =C2=A0 =C2=A0 indicate that they have concerns about IPR, and that tho=
se concerns<br>
&gt; =C2=A0 =C2=A0 lead them to take certain positions on specific issues. =
For example,<br>
&gt; =C2=A0 =C2=A0 IPR concerns could lead to a preference for one technica=
l approach<br>
&gt; =C2=A0 =C2=A0 over another, or in extreme cases, that work in a partic=
ular area<br>
&gt; =C2=A0 =C2=A0 should not be pursued at all.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 As always, WGs act on consensus, and IPR concerns are no=
 different.<br>
&gt; =C2=A0 =C2=A0 While there have been some postings indiciating unhappin=
ess with the<br>
&gt; =C2=A0 =C2=A0 disclosure, the chairs do not see consensus for any acti=
on other than<br>
&gt; =C2=A0 =C2=A0 to continue on, keeping in mind that a disclosure has be=
en made.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 In summary, SFC participants should be aware of and exam=
ine the<br>
&gt; =C2=A0 =C2=A0 disclosure to determine if they have any special concern=
s. Given the<br>
&gt; =C2=A0 =C2=A0 disclosure was made on the problem statement, we should =
not be<br>
&gt; =C2=A0 =C2=A0 surprised if a similar disclosure is made on future SFC =
documents. =C2=A0If<br>
&gt; =C2=A0 =C2=A0 folk have concerns with the disclosure and its potential=
 impact on the<br>
&gt; =C2=A0 =C2=A0 work SFC has been chartered to do, now (i.e, in next 2 w=
eeks) would be<br>
&gt; =C2=A0 =C2=A0 a good time to raise the issue.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 Thomas (chair hat on)<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 _______________________________________________<br>
&gt; =C2=A0 =C2=A0 sfc mailing list<br>
&gt; =C2=A0 =C2=A0 <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
&gt; =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" ta=
rget=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br></div>

--001a11c2e6e023138704fc98123a--


From nobody Tue Jun 24 11:32:48 2014
Return-Path: <smkumar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65B51B27C8 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 11:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.451
X-Spam-Level: 
X-Spam-Status: No, score=-12.451 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGhSgfyVY0ar for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 11:32:43 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F461B2B9F for <sfc@ietf.org>; Tue, 24 Jun 2014 11:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15610; q=dns/txt; s=iport; t=1403634764; x=1404844364; h=from:to:subject:date:message-id:mime-version; bh=/QOuJfV+FH1X/jbIHM2OfuPTT19nCQu29WFNmCPAhSY=; b=T/grGZ7WLOyBd9SOyN6c3f3hHPaO7gpM5vjexXhhQH+Sa+fDWJsnyRMV hTLhzSWz7FRqb8KjrkVTo8dQPqOksPKPrDJypXeYJNQHHqHWNvRHzi6Vo 4S74HpdMRVUBTtE4S32zsFKFAuMXrV6r8qb2GDOl9tQEd8GwemXMoKCia E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuMFAHbDqVOtJV2U/2dsb2JhbABZgkZHUlqqQAUBBZk1gQsWdYQDAQIELV4BCBEBAgECKDkUAwYKBAESiELLABeFY4kIhFsFmlGTa4NCgjA
X-IronPort-AV: E=Sophos; i="5.01,539,1400025600"; d="scan'208,217"; a="55622010"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP; 24 Jun 2014 18:32:43 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5OIWgnn016204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jun 2014 18:32:42 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 13:32:42 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: Dave Hood <dave.hood@ericsson.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] EW/NS traffic: comments on draft-ietf-sfc-dc-use-cases-00
Thread-Index: AQHPj9qu/+h7Zrumdk+G8vUUPeeHwQ==
Date: Tue, 24 Jun 2014 18:32:41 +0000
Message-ID: <CFCF05DF.4899B%smkumar@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [10.21.69.198]
Content-Type: multipart/alternative; boundary="_000_CFCF05DF4899Bsmkumarciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PPDTbFZI02shOFSexwsMsW8gV4c
Subject: Re: [sfc] EW/NS traffic: comments on draft-ietf-sfc-dc-use-cases-00
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 18:32:46 -0000

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

Dave,

E-W and N-S are widely used terms in DCs to refer to traffic that is coming=
 into the DC vs. traffic that is flowing within the DC. One may trigger the=
 other.

Some more comments Inline.

Rgds,
Surendra.
PS: Apologies for the really fast response.

From: Dave Hood <dave.hood@ericsson.com<mailto:dave.hood@ericsson.com>>
Date: Friday, May 9, 2014 1:30 PM
To: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: [sfc] EW/NS traffic: comments on draft-ietf-sfc-dc-use-cases-00

Sorry to join the conversation late; despite good intentions wrt its predec=
essors, I only just read this draft.

I am accustomed to think of E-W and N-S dimensions as applicable to control=
 or signaling traffic, but not in the data plane. The ideas are used pretty=
 widely in this draft, so I was interested to understand what they really m=
eant.

NS traffic is initially introduced with the idea that it terminates somewhe=
re outside the DC. Already, this raises my eyebrows:

1.    It forces our view of DCs to be physical rather than virtual. Also tr=
ue of endpoints.

SK> The draft nowhere assumes or implies this. On the contrary, virtual env=
ironment is called out explicitly.


2.    It feels as if it violates layering. At the layer implied by item 1, =
an endpoint will usually be external from the DC, but once the external VPN=
 is properly connected, I would expect that the endpoint would now be insid=
e <some> trust domain.

SK> The reality of traffic originating from outside the DC and the services=
 requirement do not change for such traffic, irrespective.

Then further on, we talk about EW traffic, and the distinction appears to b=
e that NS crosses trust domain boundaries, while EW traffic remains within =
a single trust domain.

3.    By that interpretation, our given user flow is going to change direct=
ion after it gets through the access firewall.

4.    But we also show several FWs in the service chain, which recognizes t=
hat trust domains may be nested. What direction do we assume for flows thro=
ugh intermediate trust domains?

SK> Security policies change from coarse-grain at the lower layers to fine =
grain and application specific at the upper layers. The example noted is th=
at of the three tiered architecture where the web-server interacts with app=
lication server, which in turn may interact with DB server. Each of these t=
iers have their own security and scaling requirements hence the service fun=
ctions depicted.

I see nothing in the text that relies heavily on a distinction. But if the =
distinction between EW and NS is really important to the model, could we ha=
ve a crisp definition, please? And if not, could we consider eliminating th=
e concept?

Thanks,
Dave

--_000_CFCF05DF4899Bsmkumarciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <121946D2301DB04F9DDB3CE4D3F4A49E@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>Dave,</div>
<div><br>
</div>
<div>E-W and N-S are widely used terms in DCs to refer to traffic that is c=
oming into the DC vs. traffic that is flowing within the DC. One may trigge=
r the other.</div>
<div><br>
</div>
<div>Some more comments Inline.</div>
<div><br>
</div>
<div>Rgds,</div>
<div>Surendra.</div>
<div>PS: Apologies for the really fast response.</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>Dave Hood &lt;<a href=3D"mail=
to:dave.hood@ericsson.com">dave.hood@ericsson.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Friday, May 9, 2014 1:30 PM<b=
r>
<span style=3D"font-weight:bold">To: </span>&quot;<a href=3D"mailto:sfc@iet=
f.org">sfc@ietf.org</a>&quot; &lt;<a href=3D"mailto:sfc@ietf.org">sfc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>[sfc] EW/NS traffic: comme=
nts on draft-ietf-sfc-dc-use-cases-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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Bookman Old Style";
	panose-1:2 5 6 4 5 5 5 2 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;}
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:"Bookman Old Style","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;}
/* List Definitions */
@list l0
	{mso-list-id:369260996;
	mso-list-type:hybrid;
	mso-list-template-ids:-1702455478 67698703 67698713 67698715 67698703 6769=
8713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
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: 10pt; font-family: 'Bookma=
n Old Style', serif; ">Sorry to join the conversation late; despite good in=
tentions wrt its predecessors, I only just read this draft.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">I am accustomed to think of E-W and N-S dimensions a=
s applicable to control or signaling traffic, but not in the data plane. Th=
e ideas are used pretty widely in this
 draft, so I was interested to understand what they really meant.<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">NS traffic is initially introduced with the idea tha=
t it terminates somewhere outside the DC. Already, this raises my eyebrows:=
<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><!--[if !supportLists]--><span style=3D"font-size:10.0pt;font-famil=
y:&quot;Bookman Old Style&quot;,&quot;serif&quot;"><span style=3D"mso-list:=
Ignore">1.<span style=3D"font-style: normal; font-variant: normal; font-wei=
ght: normal; font-size: 7pt; line-height: normal; font-family: 'Times New R=
oman'; ">&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; font-fam=
ily: 'Bookman Old Style', serif; ">It forces our view of DCs to be physical=
 rather than virtual. Also true of endpoints.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; The draft nowhere assumes or implies this. On the contrary, vir=
tual environment is called out explicitly.</div>
<div><br>
</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">
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><span style=3D"font-size: 10pt; font-family: 'Bookman Old Style', s=
erif; "><o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><!--[if !supportLists]--><span style=3D"font-size:10.0pt;font-famil=
y:&quot;Bookman Old Style&quot;,&quot;serif&quot;"><span style=3D"mso-list:=
Ignore">2.<span style=3D"font-style: normal; font-variant: normal; font-wei=
ght: normal; font-size: 7pt; line-height: normal; font-family: 'Times New R=
oman'; ">&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; font-fam=
ily: 'Bookman Old Style', serif; ">It feels as if it violates layering. At =
the layer implied by item 1, an endpoint will usually be external from the =
DC, but once the external VPN is properly
 connected, I would expect that the endpoint would now be inside &lt;some&g=
t; trust domain.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; The reality of traffic originating from outside the DC and the =
services requirement do not change for such traffic, irrespective.</div>
<div><br>
</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">
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><span style=3D"font-size: 10pt; font-family: 'Bookman Old Style', s=
erif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">Then further on, we talk about EW traffic, and the d=
istinction appears to be that NS crosses trust domain boundaries, while EW =
traffic remains within a single trust
 domain.<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><!--[if !supportLists]--><span style=3D"font-size:10.0pt;font-famil=
y:&quot;Bookman Old Style&quot;,&quot;serif&quot;"><span style=3D"mso-list:=
Ignore">3.<span style=3D"font-style: normal; font-variant: normal; font-wei=
ght: normal; font-size: 7pt; line-height: normal; font-family: 'Times New R=
oman'; ">&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; font-fam=
ily: 'Bookman Old Style', serif; ">By that interpretation, our given user f=
low is going to change direction after it gets through the access firewall.=
<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><!--[if !supportLists]--><span style=3D"font-size:10.0pt;font-famil=
y:&quot;Bookman Old Style&quot;,&quot;serif&quot;"><span style=3D"mso-list:=
Ignore">4.<span style=3D"font-style: normal; font-variant: normal; font-wei=
ght: normal; font-size: 7pt; line-height: normal; font-family: 'Times New R=
oman'; ">&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 10pt; font-fam=
ily: 'Bookman Old Style', serif; ">But we also show several FWs in the serv=
ice chain, which recognizes that trust domains may be nested. What directio=
n do we assume for flows through intermediate
 trust domains?</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; Security policies change from coarse-grain at the lower layers =
to fine grain and application specific at the upper layers. The example not=
ed is that of the three tiered architecture where the web-server interacts =
with application server, which in turn
 may interact with DB server. Each of these tiers have their own security a=
nd scaling requirements hence the service functions depicted.</div>
<div><br>
</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">
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><span style=3D"font-size: 10pt; font-family: 'Bookman Old Style', s=
erif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">I see nothing in the text that relies heavily on a d=
istinction. But if the distinction between EW and NS is really important to=
 the model, could we have a crisp definition,
 please? And if not, could we consider eliminating the concept?<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">Thanks,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">Dave<o:p></o:p></span></p>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_CFCF05DF4899Bsmkumarciscocom_--


From nobody Tue Jun 24 13:19:00 2014
Return-Path: <tnadeau@lucidvision.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778E91B27C8 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 13:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf3xpi1fGuH5 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 13:18:55 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 676541B27C4 for <sfc@ietf.org>; Tue, 24 Jun 2014 13:18:55 -0700 (PDT)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9FF4727F56FE; Tue, 24 Jun 2014 16:18:54 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_2FE722B0-3166-4C0B-BAE6-5E60C193703F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
In-Reply-To: <CAA=duU2y-m2OzZzA_PO8p0=M=gYKigPrbqe-J450wN32P8=kTQ@mail.gmail.com>
Date: Tue, 24 Jun 2014 16:18:35 -0400
Message-Id: <49DD984C-17BE-402E-B5C1-95148578EEFE@lucidvision.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com> <m3pphysbht.wl%narten@us.ibm.com> <CAA=duU2y-m2OzZzA_PO8p0=M=gYKigPrbqe-J450wN32P8=kTQ@mail.gmail.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JZBSQxXz_yIQUuJ3mkOboOwZPK4
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 20:18:59 -0000

--Apple-Mail=_2FE722B0-3166-4C0B-BAE6-5E60C193703F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C16181D4-01C5-44D0-B9AD-9C3E1CB4C4BA"


--Apple-Mail=_C16181D4-01C5-44D0-B9AD-9C3E1CB4C4BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jun 24, 2014:1:12 PM, at 1:12 PM, Andrew G. Malis <agmalis@gmail.com> =
wrote:

> Thomas,
>=20
> Actually, there have been cases where IPR holders have worked with a =
WG to clear up questions or concerns regarding IP. We recently had a =
case in PWE3 where a somewhat late disclosure was worked out with the IP =
holder by removing a particular procedure that was covered by the IP. So =
anything is possible.
>=20
> In this case, I think we're all in agreement that it's exceptional to =
see an IPR statement against a problem statement document. It would be =
useful for the WG to have a reasonable understanding of the IPR holder's =
thinking in this matter, since all we can do otherwise is read the IPR =
and speculate on our own.  Is ANYTHING the WG does going to be claimed =
to infringe this IPR? Are there reasonable technical alternatives? I =
just think it's better to be informed than not, and earlier rather than =
later when we start to write standards track drafts.
>=20
> I also realize that the WG can't always expect cooperation on the part =
of IPR holders. But in some cases, they do cooperate in good will. It =
can't hurt to ask the question.

	That is a fair point, but IMHO this question should be asked in =
parallel with the WG proceeding forward as there is no benefit for us to =
sit around waiting for the "anything is possible" case.

	--Tom


>=20
> Cheers,
> Andy
>=20
>=20
> On Tue, Jun 24, 2014 at 9:06 AM, Thomas Narten <narten@us.ibm.com> =
wrote:
> Andy,
>=20
> > In the previous discussion, there were several requests for the IPR =
holder to
> > give a summary of the scope of the IPR and how it applies to the =
problem
> > statement. I would personally feel more comfortable about supporting =
the
> > document as it stands if this question was answered. But as it is, =
we're in
> > the dark regarding how to proceed.
>=20
> You and I have both been IETF participants for a long time. We both
> have a lot of experience with IPR disclosures made in other WGs and on
> other documents. In how many of those cases has an IPR holder given "a
> summary of the scope of the IPR and how it applies"? And in how many
> of those cases has such a summary actually made a difference in how a
> WG proceeds?
>=20
> While you (or I) might feel more comfortable with additional
> clarification, how would that actually change what the WG can or
> should do?
>=20
> Are you suggesting we halt or delay work while we attempt to get more
> information? If so, for how long? And what if we don't get more
> information? RFC 3979 makes it clear that there is no certainty we
> would obtain additional information:
>=20
> > 6.4.1.  The disclosure must list the numbers of any issued patents =
or
> >    published patent applications or indicate that the claim is based =
on
> >    unpublished patent applications.  The disclosure must also list =
the
> >    specific IETF or RFC Editor Document(s) or activity affected.  If =
the
> >    IETF Document is an Internet-Draft, it must be referenced by =
specific
> >    version number.  In addition, if the IETF Document includes =
multiple
> >    parts and it is not reasonably apparent which part of such IETF
> >    Document is alleged to be Covered by the IPR in question, it is
> >    helpful if the discloser identifies the sections of the IETF =
Document
> >    that are alleged to be so Covered.
>=20
> Note that the last sentence only says "it is helpful". There is no
> requirement. And if the last ten years worth of existing disclosures
> is any indication, few disclosures include such information. (I don't
> know of any right off, but maybe there are a few.)
>=20
> Note also that RFC 3979 says:
>=20
> >    (C) Where Intellectual Property Rights have been disclosed for =
IETF
> >        Documents as provided in Section 6 of this document, the IETF
> >        Executive Director shall request from the discloser of such =
IPR,
> >        a written assurance that upon approval by the IESG for
> >        publication as RFCs of the relevant IETF specification(s), =
all
> >        persons will be able to obtain the right to implement, use,
> >        distribute and exercise other rights with respect to =
Implementing
> >        Technology under one of the licensing options specified in
> >        Section 6.5 below unless such a statement has already been
> >        submitted.  The working group proposing the use of the =
technology
> >        with respect to which the Intellectual Property Rights are
> >        disclosed may assist the IETF Executive Director in this =
effort.
>=20
> Note that the above  has already been done, i.e., the disclosure
> itself.
>=20
> >        The results of this procedure shall not, in themselves, block
> >        publication of an IETF Document or advancement of an IETF
> >        Document along the standards track.  A working group may take
> >        into consideration the results of this procedure in =
evaluating
> >        the technology, and the IESG may defer approval when a delay =
may
> >        facilitate obtaining such assurances.  The results will, =
however,
> >        be recorded by the IETF Executive Director, and be made =
available
> >        online.
>=20
> The above says nothing about delaying documents once a disclosure
> meeting the RFC 3979 requirements has been made.
>=20
> So please be clear. Do you have a specific proposed action for the WG
> to take other than proceed with its work?
>=20
> Wanting to be more "comfortable" is not actionable.
>=20
> Thomas
>=20
> >
> > On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten <narten@us.ibm.com> =
wrote:
> >
> >     WG:
> >
> >     As has been noted before, an IPR disclosure has been made on the =
SFC
> >     problem statement document
> >     (draft-ietf-sfc-problem-statement-06.txt). Per
> >     http://datatracker.ietf.org/ipr/2315/ The IPR holder (Ericsson)
> >     indicates that their licensing terms would be:
> >
> >         Reasonable and Non-Discriminatory License to All =
Implementers with
> >         Possible Royalty/Fee.
> >
> >     As has been noted, it is unusual to see an IPR declaration on a
> >     problem statement. One doesn't implement a problem statement, =
raising
> >     the question of what it means to make an IPR disclosure on a =
problem
> >     statement. While there are several interpretations that could be =
made,
> >     it was suggested in an earlier thread that the IPR may have =
broad
> >     applicability, and that it might be difficult for the SFC WG to
> >     develop solutions that are not potentially encumbered.
> >
> >     When IPR disclosures have been made, WGs have the option of =
taking the
> >     potential IPR into consideration as they do their work. For =
example,
> >     when selecting between competing approaches to solving a =
problem, IPR
> >     considerations can be one of the factors used in weighing the =
pros and
> >     cons of an approach. Some may decide that IPR is a significant =
issue,
> >     others may consider disclosed IPR to be a minor factor.
> >
> >     The IETF handling of IPR is covered in detail in RFCs 3979 and
> >     2026. There are aspects of IPR that are not appropriate or =
productive
> >     to discuss within the WG, because at the end of the day, the =
IETF
> >     cannot and does not make determinations as to whether IPR is =
valid,
> >     whether it applies to a given technology, whether there is prior =
art,
> >     etc. Those sorts of issues are resolved outside of the IETF.
> >
> >     In discussing IPR within the IETF, individual IETF participants =
can
> >     indicate that they have concerns about IPR, and that those =
concerns
> >     lead them to take certain positions on specific issues. For =
example,
> >     IPR concerns could lead to a preference for one technical =
approach
> >     over another, or in extreme cases, that work in a particular =
area
> >     should not be pursued at all.
> >
> >     As always, WGs act on consensus, and IPR concerns are no =
different.
> >     While there have been some postings indiciating unhappiness with =
the
> >     disclosure, the chairs do not see consensus for any action other =
than
> >     to continue on, keeping in mind that a disclosure has been made.
> >
> >     In summary, SFC participants should be aware of and examine the
> >     disclosure to determine if they have any special concerns. Given =
the
> >     disclosure was made on the problem statement, we should not be
> >     surprised if a similar disclosure is made on future SFC =
documents.  If
> >     folk have concerns with the disclosure and its potential impact =
on the
> >     work SFC has been chartered to do, now (i.e, in next 2 weeks) =
would be
> >     a good time to raise the issue.
> >
> >     Thomas (chair hat on)
> >
> >     _______________________________________________
> >     sfc mailing list
> >     sfc@ietf.org
> >     https://www.ietf.org/mailman/listinfo/sfc
> >
> >
>=20
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


--Apple-Mail=_C16181D4-01C5-44D0-B9AD-9C3E1CB4C4BA
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 24, 2014:1:12 PM, at 1:12 PM, Andrew G. Malis &lt;<a href="mailto:agmalis@gmail.com">agmalis@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Thomas,<div><br></div><div>Actually, there have been cases where IPR holders have worked with a WG to clear up questions or concerns regarding IP. We recently had a case in PWE3 where a somewhat late disclosure was worked out with the IP holder by removing a particular procedure that was covered by the IP. So anything is possible.</div>

<div><br></div><div>In this case, I think we're all in agreement that it's exceptional to see an IPR statement against a problem statement document. It would be useful for the WG to have a reasonable understanding of the IPR holder's thinking in this matter, since all we can do otherwise is read the IPR and speculate on our own. &nbsp;Is ANYTHING the WG does going to be claimed to infringe this IPR? Are there reasonable technical alternatives? I just think it's better to be informed than not, and earlier rather than later when we start to write standards track drafts.</div>

<div><br></div><div>I also realize that the WG can't always expect cooperation on the part of IPR holders. But in some cases, they do cooperate in good will. It can't hurt to ask the question.</div></div></blockquote><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">	</span>That is a fair point, but IMHO this question should be asked in parallel with the WG proceeding forward as there is no benefit for us to sit around waiting for the "anything is possible" case.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">	</span>--Tom</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><br></div>

<div>Cheers,</div><div>Andy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 9:06 AM, Thomas Narten <span dir="ltr">&lt;<a href="mailto:narten@us.ibm.com" target="_blank">narten@us.ibm.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andy,<br>
<div class=""><br>
&gt; In the previous discussion, there were several requests for the IPR holder to<br>
&gt; give a summary of the scope of the IPR and how it applies to the problem<br>
&gt; statement. I would personally feel more comfortable about supporting the<br>
&gt; document as it stands if this question was answered. But as it is, we're in<br>
&gt; the dark regarding how to proceed.<br>
<br>
</div>You and I have both been IETF participants for a long time. We both<br>
have a lot of experience with IPR disclosures made in other WGs and on<br>
other documents. In how many of those cases has an IPR holder given "a<br>
summary of the scope of the IPR and how it applies"? And in how many<br>
of those cases has such a summary actually made a difference in how a<br>
WG proceeds?<br>
<br>
While you (or I) might feel more comfortable with additional<br>
clarification, how would that actually change what the WG can or<br>
should do?<br>
<br>
Are you suggesting we halt or delay work while we attempt to get more<br>
information? If so, for how long? And what if we don't get more<br>
information? RFC 3979 makes it clear that there is no certainty we<br>
would obtain additional information:<br>
<br>
&gt; 6.4.1. &nbsp;The disclosure must list the numbers of any issued patents or<br>
&gt; &nbsp; &nbsp;published patent applications or indicate that the claim is based on<br>
&gt; &nbsp; &nbsp;unpublished patent applications. &nbsp;The disclosure must also list the<br>
&gt; &nbsp; &nbsp;specific IETF or RFC Editor Document(s) or activity affected. &nbsp;If the<br>
&gt; &nbsp; &nbsp;IETF Document is an Internet-Draft, it must be referenced by specific<br>
&gt; &nbsp; &nbsp;version number. &nbsp;In addition, if the IETF Document includes multiple<br>
&gt; &nbsp; &nbsp;parts and it is not reasonably apparent which part of such IETF<br>
&gt; &nbsp; &nbsp;Document is alleged to be Covered by the IPR in question, it is<br>
&gt; &nbsp; &nbsp;helpful if the discloser identifies the sections of the IETF Document<br>
&gt; &nbsp; &nbsp;that are alleged to be so Covered.<br>
<br>
Note that the last sentence only says "it is helpful". There is no<br>
requirement. And if the last ten years worth of existing disclosures<br>
is any indication, few disclosures include such information. (I don't<br>
know of any right off, but maybe there are a few.)<br>
<br>
Note also that RFC 3979 says:<br>
<br>
&gt; &nbsp; &nbsp;(C) Where Intellectual Property Rights have been disclosed for IETF<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;Documents as provided in Section 6 of this document, the IETF<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;Executive Director shall request from the discloser of such IPR,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;a written assurance that upon approval by the IESG for<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;publication as RFCs of the relevant IETF specification(s), all<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;persons will be able to obtain the right to implement, use,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;distribute and exercise other rights with respect to Implementing<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;Technology under one of the licensing options specified in<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;Section 6.5 below unless such a statement has already been<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;submitted. &nbsp;The working group proposing the use of the technology<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;with respect to which the Intellectual Property Rights are<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;disclosed may assist the IETF Executive Director in this effort.<br>
<br>
Note that the above &nbsp;has already been done, i.e., the disclosure<br>
itself.<br>
<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;The results of this procedure shall not, in themselves, block<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;publication of an IETF Document or advancement of an IETF<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;Document along the standards track. &nbsp;A working group may take<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;into consideration the results of this procedure in evaluating<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;the technology, and the IESG may defer approval when a delay may<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;facilitate obtaining such assurances. &nbsp;The results will, however,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;be recorded by the IETF Executive Director, and be made available<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;online.<br>
<br>
The above says nothing about delaying documents once a disclosure<br>
meeting the RFC 3979 requirements has been made.<br>
<br>
So please be clear. Do you have a specific proposed action for the WG<br>
to take other than proceed with its work?<br>
<br>
Wanting to be more "comfortable" is not actionable.<br>
<span class="HOEnZb"><font color="#888888"><br>
Thomas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; On Fri, Jun 20, 2014 at 4:59 PM, Thomas Narten &lt;<a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &nbsp; &nbsp; WG:<br>
&gt;<br>
&gt; &nbsp; &nbsp; As has been noted before, an IPR disclosure has been made on the SFC<br>
&gt; &nbsp; &nbsp; problem statement document<br>
&gt; &nbsp; &nbsp; (draft-ietf-sfc-problem-statement-06.txt). Per<br>
&gt; &nbsp; &nbsp; <a href="http://datatracker.ietf.org/ipr/2315/" target="_blank">http://datatracker.ietf.org/ipr/2315/</a> The IPR holder (Ericsson)<br>
&gt; &nbsp; &nbsp; indicates that their licensing terms would be:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Reasonable and Non-Discriminatory License to All Implementers with<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Possible Royalty/Fee.<br>
&gt;<br>
&gt; &nbsp; &nbsp; As has been noted, it is unusual to see an IPR declaration on a<br>
&gt; &nbsp; &nbsp; problem statement. One doesn't implement a problem statement, raising<br>
&gt; &nbsp; &nbsp; the question of what it means to make an IPR disclosure on a problem<br>
&gt; &nbsp; &nbsp; statement. While there are several interpretations that could be made,<br>
&gt; &nbsp; &nbsp; it was suggested in an earlier thread that the IPR may have broad<br>
&gt; &nbsp; &nbsp; applicability, and that it might be difficult for the SFC WG to<br>
&gt; &nbsp; &nbsp; develop solutions that are not potentially encumbered.<br>
&gt;<br>
&gt; &nbsp; &nbsp; When IPR disclosures have been made, WGs have the option of taking the<br>
&gt; &nbsp; &nbsp; potential IPR into consideration as they do their work. For example,<br>
&gt; &nbsp; &nbsp; when selecting between competing approaches to solving a problem, IPR<br>
&gt; &nbsp; &nbsp; considerations can be one of the factors used in weighing the pros and<br>
&gt; &nbsp; &nbsp; cons of an approach. Some may decide that IPR is a significant issue,<br>
&gt; &nbsp; &nbsp; others may consider disclosed IPR to be a minor factor.<br>
&gt;<br>
&gt; &nbsp; &nbsp; The IETF handling of IPR is covered in detail in RFCs 3979 and<br>
&gt; &nbsp; &nbsp; 2026. There are aspects of IPR that are not appropriate or productive<br>
&gt; &nbsp; &nbsp; to discuss within the WG, because at the end of the day, the IETF<br>
&gt; &nbsp; &nbsp; cannot and does not make determinations as to whether IPR is valid,<br>
&gt; &nbsp; &nbsp; whether it applies to a given technology, whether there is prior art,<br>
&gt; &nbsp; &nbsp; etc. Those sorts of issues are resolved outside of the IETF.<br>
&gt;<br>
&gt; &nbsp; &nbsp; In discussing IPR within the IETF, individual IETF participants can<br>
&gt; &nbsp; &nbsp; indicate that they have concerns about IPR, and that those concerns<br>
&gt; &nbsp; &nbsp; lead them to take certain positions on specific issues. For example,<br>
&gt; &nbsp; &nbsp; IPR concerns could lead to a preference for one technical approach<br>
&gt; &nbsp; &nbsp; over another, or in extreme cases, that work in a particular area<br>
&gt; &nbsp; &nbsp; should not be pursued at all.<br>
&gt;<br>
&gt; &nbsp; &nbsp; As always, WGs act on consensus, and IPR concerns are no different.<br>
&gt; &nbsp; &nbsp; While there have been some postings indiciating unhappiness with the<br>
&gt; &nbsp; &nbsp; disclosure, the chairs do not see consensus for any action other than<br>
&gt; &nbsp; &nbsp; to continue on, keeping in mind that a disclosure has been made.<br>
&gt;<br>
&gt; &nbsp; &nbsp; In summary, SFC participants should be aware of and examine the<br>
&gt; &nbsp; &nbsp; disclosure to determine if they have any special concerns. Given the<br>
&gt; &nbsp; &nbsp; disclosure was made on the problem statement, we should not be<br>
&gt; &nbsp; &nbsp; surprised if a similar disclosure is made on future SFC documents. &nbsp;If<br>
&gt; &nbsp; &nbsp; folk have concerns with the disclosure and its potential impact on the<br>
&gt; &nbsp; &nbsp; work SFC has been chartered to do, now (i.e, in next 2 weeks) would be<br>
&gt; &nbsp; &nbsp; a good time to raise the issue.<br>
&gt;<br>
&gt; &nbsp; &nbsp; Thomas (chair hat on)<br>
&gt;<br>
&gt; &nbsp; &nbsp; _______________________________________________<br>
&gt; &nbsp; &nbsp; sfc mailing list<br>
&gt; &nbsp; &nbsp; <a href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>
&gt; &nbsp; &nbsp; <a href="https://www.ietf.org/mailman/listinfo/sfc" target="_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>sfc mailing list<br><a href="mailto:sfc@ietf.org">sfc@ietf.org</a><br>https://www.ietf.org/mailman/listinfo/sfc<br></blockquote></div><br></body></html>
--Apple-Mail=_C16181D4-01C5-44D0-B9AD-9C3E1CB4C4BA--

--Apple-Mail=_2FE722B0-3166-4C0B-BAE6-5E60C193703F
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 - https://gpgtools.org

iQIcBAEBCgAGBQJTqd0bAAoJEPcO+I7eiUJZ3WIP/154sdzdsW8C6fFjUaOYNwSu
T91/kR8FKgWVvXg2bD/KtR32+uuB+vHgRBRByKNaM3nLpx/5lDaxG+Trmo1MyQBw
6KkPt/p/ngeJaF7uf7JGGH92eM8MJ2F6M2gWFZ/ttvJf9KpJKxfwISOzlwG3DI2A
EeiWHVSaSty6tIkY3FPAkjPT4BagBQpVk6CrujeCkoFu9g0AfPim6aHj2jdJfl9x
pHf5yflTQW5Nb0r5OqIdUp+T4VjcG0sPhce0vSk6qIOb73cuyg+fqk3OVSKcnkhN
24PeuDaQyfGqwjYCWLBSjxqyzHHvuYPegCNkcNj+rHxg2YxCU3crxOcLxfOiFzaO
V7V1HS+rECPZGanhEHFUE4ZX3aqBqIKVtnjYIPjacP1mIzP7KlJ9KmJzbAoLQzfw
pTzcxhj87qouJ3klU8JNToTD1yV2eySikusEN8/KFAsZanFB0ddjA6M3tg8f9/Qg
OA68s5TAM1KhstQUL7HH5Ugg5f6ZpCRBs5GEedwOpVjEeBETqCQCNL8BX0JOuN/u
/QbAx0OGns/eVARmJNtHDLHToYXTy7hYjB86fMiIeHhkIiTj8YizxOIQmoEIWacx
6bMfED4em7kwl/rxFC91YE7aNsyv8ldYC/TDJaBEA7F/9YAsPVOGtwZRQIlifNnk
Q3jTUubOy9HroE2Z7oAC
=SxI1
-----END PGP SIGNATURE-----

--Apple-Mail=_2FE722B0-3166-4C0B-BAE6-5E60C193703F--


From nobody Tue Jun 24 13:51:53 2014
Return-Path: <agmalis@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1031B289B for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 13:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0MhPK_-Y6Uw for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 13:51:47 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20EC01B289C for <sfc@ietf.org>; Tue, 24 Jun 2014 13:51:44 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id x13so851088qcv.33 for <sfc@ietf.org>; Tue, 24 Jun 2014 13:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dKWH8IiM4dIp7HSQc1RgMdIqAbCVEOOLbxaYcxT+B8A=; b=PIfV5u3Asjil/zFGmxcY9C2m3spWre4vvaeiRAf2agp2zL4iti/wN/gZQsf6q4tEoZ S9yvvqnElfh5cKAoZSrTvBrgxtumyLJT4H01oa+D/Q7FzNnjbSyctDSaOUkWJ0gKaDJh sKLqSVOokiZMwMlCfj1Fc3RDlrp2zslAgHj+7T1Sadslw0R/kxN4/mTh30ns30RJlO8y JdbqDLI77psraQmDvuC8f762KguP+CRzbnvJfD/0TzJISqJR8/poJKwTuG4R7Z3Zi5HJ eosjYBG1jsfywP/SYdWe4fyRaYlCH1AZPmX6yQasqXN07MgYFDDE2KwXfE5LRAn/WxR5 lFpw==
X-Received: by 10.140.49.76 with SMTP id p70mr5310834qga.86.1403643103374; Tue, 24 Jun 2014 13:51:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.28.2 with HTTP; Tue, 24 Jun 2014 13:51:21 -0700 (PDT)
In-Reply-To: <49DD984C-17BE-402E-B5C1-95148578EEFE@lucidvision.com>
References: <m3ionvsk3u.wl%narten@us.ibm.com> <CAA=duU0csQA8wbHW3Bt4kjRQ8tjf6-A6Sk5FStemchsyLJ6vgA@mail.gmail.com> <m3pphysbht.wl%narten@us.ibm.com> <CAA=duU2y-m2OzZzA_PO8p0=M=gYKigPrbqe-J450wN32P8=kTQ@mail.gmail.com> <49DD984C-17BE-402E-B5C1-95148578EEFE@lucidvision.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Tue, 24 Jun 2014 16:51:21 -0400
Message-ID: <CAA=duU3UJZPKJwD-qErFZpibgmgsU8Fzz_=DuDQNJt372vrmjQ@mail.gmail.com>
To: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
Content-Type: multipart/alternative; boundary=001a11370a34917fe504fc9b20fd
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/SJyJNABUcwUzVb4q4Uu1gpjkQgY
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] IPR Disclosure on SFC work
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 20:51:50 -0000

--001a11370a34917fe504fc9b20fd
Content-Type: text/plain; charset=UTF-8

On Tue, Jun 24, 2014 at 4:18 PM, Thomas D. Nadeau <tnadeau@lucidvision.com>
wrote:

> That is a fair point, but IMHO this question should be asked in parallel
> with the WG proceeding forward as there is no benefit for us to sit around
> waiting for the "anything is possible" case.
>

I agree if there is a consensus to proceed forward. There is still a week
and a half to go in the two week period you posted for discussion.

Cheers,
Andy

--001a11370a34917fe504fc9b20fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jun 24, 2014 at 4:18 PM, Thomas D. Nadeau <span dir=3D"ltr">&lt;<a =
href=3D"mailto:tnadeau@lucidvision.com" target=3D"_blank">tnadeau@lucidvisi=
on.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>That is a fair point, but IMHO this que=
stion should be asked in parallel with the WG proceeding forward as there i=
s no benefit for us to sit around waiting for the &quot;anything is possibl=
e&quot; case.</div>

<div></div></blockquote></div><br></div><div class=3D"gmail_extra">I agree =
if there is a consensus to proceed forward. There is still a week and a hal=
f to go in the two week period you posted for discussion.</div><div class=
=3D"gmail_extra">

<br></div><div class=3D"gmail_extra">Cheers,</div><div class=3D"gmail_extra=
">Andy</div><div class=3D"gmail_extra"><br></div></div>

--001a11370a34917fe504fc9b20fd--


From nobody Tue Jun 24 14:20:17 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2E01B2885; Tue, 24 Jun 2014 14:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkuFhTbRnue5; Tue, 24 Jun 2014 14:20:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EAF1B2960; Tue, 24 Jun 2014 14:08:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140624210828.12440.24571.idtracker@ietfa.amsl.com>
Date: Tue, 24 Jun 2014 14:08:28 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_k2r67VPUk_U9Z-av20yQpyslis
Cc: sfc@ietf.org
Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-07.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 21:20:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Service Function Chaining Problem Statement
        Authors         : Paul Quinn
                          Thomas Nadeau
	Filename        : draft-ietf-sfc-problem-statement-07.txt
	Pages           : 19
	Date            : 2014-06-24

Abstract:
   This document provides an overview of the issues associated with the
   deployment of service functions (such as firewalls, load balancers)
   in large-scale environments.  The term service function chaining is
   used to describe the definition and instantiation of an ordered set
   of instances of such service functions, and the subsequent "steering"
   of traffic flows through those service functions.

   The set of enabled service function chains reflect operator service
   offerings and is designed in conjunction with application delivery
   and service and network policy.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Tue Jun 24 18:37:08 2014
Return-Path: <smkumar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B297F1B2A22 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 18:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.451
X-Spam-Level: 
X-Spam-Status: No, score=-12.451 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iRIvpf7j8w1 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 18:37:01 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8BE1B2A1E for <sfc@ietf.org>; Tue, 24 Jun 2014 18:37:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33786; q=dns/txt; s=iport; t=1403660222; x=1404869822; h=from:to:subject:date:message-id:mime-version; bh=BBOrUoea3HwRAhwhK66REJGhn6ROOYOTInnAM+UyJok=; b=IG+md1/93cmMavptQoB8SZSBghuZ2yW3clT88LV0VsgspDNhEKw27L6/ ItntcZPLI8LqF+WCOYeNm9yLhiG0K/15kdX07b4gqFvt7BuIeXPMFbefR Ln3qwL+3w8UYAY+tGIoFSJVubXOzCV2K1A+mNR0t9ijIYf3897x7jhakv U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuUFAM4mqlOtJA2M/2dsb2JhbABagkZHUlqqSAUBBZk1AYEQFnWEAwECBC1eAQgRAQIBAiEBBjkUAwYKBAESG4gnyEkXhWODY4RTUheERAWWPYQUk2uDQoFwJBw
X-IronPort-AV: E=Sophos;i="5.01,541,1400025600";  d="scan'208,217";a="335441306"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jun 2014 01:37:01 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5P1b0sU021023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jun 2014 01:37:00 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 20:36:59 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: Dave Hood <dave.hood@ericsson.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Gen rqts comments on draft-ietf-sfc-dc-use-cases-00
Thread-Index: AQHPkBX0ZY1FmKkGBEannvQaGrVnow==
Date: Wed, 25 Jun 2014 01:36:59 +0000
Message-ID: <CFCF48CA.48B78%smkumar@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [10.155.165.219]
Content-Type: multipart/alternative; boundary="_000_CFCF48CA48B78smkumarciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xJbAgGTMnbiTxPM-agOg1WctPLQ
Subject: Re: [sfc] Gen rqts comments on draft-ietf-sfc-dc-use-cases-00
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 01:37:04 -0000

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

Thanks for the detailed comments! . Responses/comments inline.

Surendra.

From: Dave Hood <dave.hood@ericsson.com<mailto:dave.hood@ericsson.com>>
Date: Sunday, May 11, 2014 5:42 PM
To: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: [sfc] Gen rqts comments on draft-ietf-sfc-dc-use-cases-00

A few observations on the proposed requirements:

GR1.   SFC polices MUST be applicable at the edges - network elements as we=
ll as the workloads.

A good requirement specifies that 1) someone must do 2) something and 3) th=
ere should be a way to confirm whether 1 has done 2 or not. How would we te=
st this requirement?
SK> If you have suggested text for this, we will review and update.

GR2.   SFC policies MUST be applicable to either Ingress or Egress traffic.

Ingress and egress are not well-defined. From the viewpoint of an SFC, the =
classifier is always an ingress point, and the conclusion of the service ch=
ain is always an egress point.

Bidirectional flows are important, but if this requirement is meant to intr=
oduce that topic, it is wide of the mark.

SK> This is an extension of GR1. We could include network element and workl=
oad to make the context of ingress/egress specific.

GR3.   SFC MUST support virtual as well as physical SNs.

This is written as if physical SNs were primary, with virtual an afterthoug=
ht. While recognizing the differences, it is probably better to grant them =
logical equivalence. Or if one is to be regarded as primary, surely it woul=
d be the virtual SN?
SK> Our intent is to give them logical equivalence while capturing the chal=
lenges with virtual SNs and the virtual environment, for SFC to address, in=
 order to not diminish all that flexibility and dyanamism.

GR4.   SFC SHOULD support the ability to mix virtual and physical SNs in th=
e same SFC.
Ok

GR5.   SFC SNs MUST be deployable L2 or L3 hop away from each other or from=
 the SFC starting entity.

Not clear what is actually being asked for here. The first sentence in DB-3=
 actually states the requirement more crisply.
SK> Basically, there should not be any assumption about the SNs being L3 ho=
p away to the SFC infra =96 classifier, service function forwarder (borrowi=
ng terms from the arch draft) etc.

GR6.   SFC traffic MUST be allowed to follow paths not constrained by the u=
nderlying static network topology.

We are always tied to underlying topology, just as a zero-G space environme=
nt is still subject to the laws of gravity. Even within a DC, and certainly=
 between DCs, there will always be better ways and worse ways of physically=
 arranging the virtual SNs (ie static network topology constraints).

The problem statement draft describes this better. A reqirement might bette=
r be written something along the lines that SFs [do we need SNs in the inte=
nded abstraction?] should be nodes in a virtual full-mesh topology, maybe a=
ccompanied with a requirement to be able to create new virtual topology nod=
es (ie instantiate new virtual SNs) on demand (see comment on GR11 below). =
Admittedly, this goes beyond the implications of the text describing fig 1,=
 but still seems appropriate.
SK> This is not suggesting how the topology should be or whether there shou=
ld be dynamic instantiation of SNs, which are left to the implementations a=
nd solutions. The key here is that SFCs be constructible on an overlay whil=
e still allowing underlay legacy methods to exist.

GR7.   SFC SNs MUST be able to derive the tenant identification without bei=
ng tied to the underlying topology

SNs, rather than SFs? Derive, rather than being told? And the point about u=
nderlying topology seems to preclude the continued use of physical boxes wi=
th hard wiring that might already be in place.
SK> I agree, 'derive' as used may be misleading. We will update it.
No, it does not preclude physical boxes. Physical boxes could use overlay o=
r underlay and still base tenant identification on the topology. With overl=
ays and the ability to carry metadata, tenant identification can be passed =
to the SN.

GR8.   SFCs MUST support the ability to pass metadata among the SNs or betw=
een the SNs and the network elements.

It doesn=92t say so, but presumably the metadata is associated with a parti=
cular [set of] flows. As written, this could be done with information conve=
yed out of band, at the time of flow allocation or per-packet. Are all of t=
hese options intended to be left open for later resolution?
SK> Good point about in band vs. out of band. This is specifically on the i=
n band communication. Implementations can choose how to use such a mechanis=
m but having such a mechanism enables many use cases.

GR9.   A composite SFC SHOULD be achievable by way of joining sub SFCs, bra=
nching to sub SFCs where necessary.

Is branching the only option? Why not nesting?
SK> Branching seems to address the use cases in a simple fashion. If there =
are nested use cases that cannot be addressed, it would good to bring them =
up in this forum and update the draft as needed.

GR10.  SFCs SHOULD NOT require SNAT inside the SFs to attract traffic back =
to them

This seems like a fine-grained requirement that addresses only one small as=
pect of a larger issue, namely visibility of bidirectional flows. Are we co=
ntent to chip away at the problem without considering it in its entirety?
SK> By virtue of the overlay and steering, this falls right in the SFC arch=
itecture domain. Open to hearing the broader view point.

GR11.  SFCs SHOULD have the ability to choose SN instances dynamically, at =
the time of forwarding traffic to them.

The last phrase is at best redundant but probably incorrect (appears to dem=
and just-in-time; why not *prior to* forwarding traffic?).
Also, although it is not justified by the use cases, one might hope for the=
 ability to instantiate or destroy instances of at least some kinds of SN/S=
F on demand.
SK> Will update to use "prior to". Yes, implementations may grow/shrink the=
 SN pool.

GR12.  An OAM mechanism to easily troublshoot as well as validate the paths=
 traversed by the SFCs SHOULD be supported.

Given the expected intelligent controller, would we regard it as a sufficie=
nt response for the controller to be able to report its choices? Or would w=
e expect some form of traceroute in the data path itself?
SK> Traceroute in the data path is beneficial, as it traverses the same pat=
h as a packet would, in exposing SFC path issues.

And speaking of intelligent controllers, BTW, the drawbacks clause 4 appear=
s to be written with the intent to preclude the use of VLANs. As to scalabi=
lity, VLANs might suffice for small to moderate enterprises. The argument i=
s really based on the assumption of manual configuration. Given intelligenc=
e in the SFC controller, VLANs are one of many ways in which one could cons=
truct a valid solution. If we really intend to preclude VLANs, there needs =
to be a better argument than is presented.
SK> Please not that VLAN stitching is not precluded. With proxy's in SFC, V=
LAN stitching is still valuable to support the legacy SNs. With overlay bas=
ed method and metadata passing, there is obvious value to be had in SFC.

Dave

--_000_CFCF48CA48B78smkumarciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <5A76C6D1F1769943B316F41D5AE7851E@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>Thanks for the detailed comments! .&nbsp;Responses/comments inline.</d=
iv>
<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>Dave Hood &lt;<a href=3D"mail=
to:dave.hood@ericsson.com">dave.hood@ericsson.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Sunday, May 11, 2014 5:42 PM<=
br>
<span style=3D"font-weight:bold">To: </span>&quot;<a href=3D"mailto:sfc@iet=
f.org">sfc@ietf.org</a>&quot; &lt;<a href=3D"mailto:sfc@ietf.org">sfc@ietf.=
org</a>&gt;<br>
<span style=3D"font-weight:bold">Subject: </span>[sfc] Gen rqts comments on=
 draft-ietf-sfc-dc-use-cases-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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Bookman Old Style";
	panose-1:2 5 6 4 5 5 5 2 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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Bookman Old Style","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;
	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]-->
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">A few observations on the proposed requirements:<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR1.&nbsp;&nbsp; SFC p=
olices MUST be applicable at the edges - network elements as well as the wo=
rkloads.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">A good requirement specif=
ies that 1) someone must do 2) something and 3) there should be a way to co=
nfirm whether 1 has done 2 or not. How
 would we test this requirement?</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; If you have suggested text for this, we will review and update.=
</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR2.&nbsp;&nbsp; SFC p=
olicies MUST be applicable to either Ingress or Egress traffic.<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">Ingress and egress are no=
t well-defined. From the viewpoint of an SFC, the classifier is always an i=
ngress point, and the conclusion of the
 service chain is always an egress point.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">Bidirectional flows are i=
mportant, but if this requirement is meant to introduce that topic, it is w=
ide of the mark.</span></p>
</div>
</div>
</div>
</span>
<div><br>
</div>
<div>SK&gt; This is an extension of GR1. We could include network element a=
nd workload to make the context of ingress/egress specific.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR3.&nbsp;&nbsp; SFC M=
UST support virtual as well as physical SNs.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">This is written as if phy=
sical SNs were primary, with virtual an afterthought. While recognizing the=
 differences, it is probably better to
 grant them logical equivalence. Or if one is to be regarded as primary, su=
rely it would be the virtual SN?</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; Our intent is to give them logical equivalence while capturing =
the challenges with virtual SNs and the virtual environment, for SFC to add=
ress, in order to not diminish all that flexibility and dyanamism.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR4.&nbsp;&nbsp; SFC S=
HOULD support the ability to mix virtual and physical SNs in the same SFC.<=
o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">Ok
<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR5.&nbsp;&nbsp; SFC S=
Ns MUST be deployable L2 or L3 hop away from each other or from the SFC sta=
rting entity.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">Not clear what is actuall=
y being asked for here. The first sentence in DB-3 actually states the requ=
irement more crisply.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; Basically, there should not be any assumption about the SNs bei=
ng L3 hop away to the SFC infra =96 classifier, service function forwarder =
(borrowing terms from the arch draft) etc.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR6.&nbsp;&nbsp; SFC t=
raffic MUST be allowed to follow paths not constrained by the underlying st=
atic network topology.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">We are always tied to und=
erlying topology, just as a zero-G space environment is still subject to th=
e laws of gravity. Even within a DC, and
 certainly between DCs, there will always be better ways and worse ways of =
physically arranging the virtual SNs (ie static network topology constraint=
s).<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">The problem statement dra=
ft describes this better. A reqirement might better be written something al=
ong the lines that SFs [do we need SNs
 in the intended abstraction?] should be nodes in a virtual full-mesh topol=
ogy, maybe accompanied with a requirement to be able to create new virtual =
topology nodes (ie instantiate new virtual SNs) on demand (see comment on G=
R11 below). Admittedly, this goes
 beyond the implications of the text describing fig 1, but still seems appr=
opriate.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; This is not suggesting how the topology should be or whether th=
ere should be dynamic instantiation of SNs, which are left to the implement=
ations and solutions. The key here is that SFCs be constructible on an over=
lay while still allowing underlay legacy
 methods to exist.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR7.&nbsp;&nbsp; SFC S=
Ns MUST be able to derive the tenant identification without being tied to t=
he underlying topology<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">SNs, rather than SFs? Der=
ive, rather than being told? And the point about underlying topology seems =
to preclude the continued use of physical
 boxes with hard wiring that might already be in place.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt;&nbsp;I agree, 'derive' as used may be misleading. We will updat=
e it.</div>
<div>No, it does not preclude physical boxes. Physical boxes could use over=
lay or underlay and still base tenant identification on the topology. With =
overlays and the ability to carry metadata, tenant identification can be pa=
ssed to the SN.&nbsp;</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR8.&nbsp;&nbsp; SFCs =
MUST support the ability to pass metadata among the SNs or between the SNs =
and the network elements.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">It doesn=92t say so, but =
presumably the metadata is associated with a particular [set of] flows. As =
written, this could be done with information
 conveyed out of band, at the time of flow allocation or per-packet. Are al=
l of these options intended to be left open for later resolution?</span></p=
>
</div>
</div>
</div>
</span>
<div>SK&gt; Good point about in band vs. out of band. This is specifically =
on the in band communication. Implementations can choose how to use such a =
mechanism but having such a mechanism enables many use cases.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR9.&nbsp;&nbsp; A com=
posite SFC SHOULD be achievable by way of joining sub SFCs, branching to su=
b SFCs where necessary.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">Is branching the only opt=
ion? Why not nesting?</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; Branching seems to address the use cases in a simple fashion. I=
f there are nested use cases that cannot be addressed, it would good to bri=
ng them up in this forum and update the draft as needed.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR10.&nbsp; SFCs SHOUL=
D NOT require SNAT inside the SFs to attract traffic back to them<o:p></o:p=
></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">This seems like a fine-gr=
ained requirement that addresses only one small aspect of a larger issue, n=
amely visibility of bidirectional flows.
 Are we content to chip away at the problem without considering it in its e=
ntirety?</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; By virtue of the overlay and steering, this falls right in the =
SFC architecture domain. Open to hearing the broader view point.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR11.&nbsp; SFCs SHOUL=
D have the ability to choose SN instances dynamically, at the time of forwa=
rding traffic to them.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">The last phrase is at bes=
t redundant but probably incorrect (appears to demand just-in-time; why not=
 *<b>prior to</b>* forwarding traffic?).<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">Also, although it is not =
justified by the use cases, one might hope for the ability to instantiate o=
r destroy instances of at least some kinds
 of SN/SF on demand.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; Will update to use &quot;prior to&quot;. Yes, implementations m=
ay grow/shrink the SN pool.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; ">GR12.&nbsp; An OAM mec=
hanism to easily troublshoot as well as validate the paths traversed by the=
 SFCs SHOULD be supported.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"line-height:14.4pt"><span style=3D"font-siz=
e: 10pt; font-family: 'Courier New'; color: black; "><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; ">Given the expected intell=
igent controller, would we regard it as a sufficient response for the contr=
oller to be able to report its choices?
 Or would we expect some form of traceroute in the data path itself?</span>=
</p>
</div>
</div>
</div>
</span>
<div>SK&gt; Traceroute in the data path is beneficial, as it traverses the =
same path as a packet would, in exposing SFC path issues.</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">
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 10pt; font-family: 'Bookman Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">And speaking of intelligent controllers, BTW, the dr=
awbacks clause 4 appears to be written with the intent to preclude the use =
of VLANs. As to scalability, VLANs might
 suffice for small to moderate enterprises. The argument is really based on=
 the assumption of manual configuration. Given intelligence in the SFC cont=
roller, VLANs are one of many ways in which one could construct a valid sol=
ution. If we really intend to preclude
 VLANs, there needs to be a better argument than is presented.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; Please not that VLAN stitching is not precluded. With proxy's i=
n SFC, VLAN stitching is still valuable to support the legacy SNs. With ove=
rlay based method and metadata passing, there is obvious value to be had in=
 SFC.</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">
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; "><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size: 10pt; font-family: 'Bookma=
n Old Style', serif; ">Dave<o:p></o:p></span></p>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_CFCF48CA48B78smkumarciscocom_--


From nobody Tue Jun 24 18:47:11 2014
Return-Path: <smkumar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F2F1B2A33 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 18:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY6QC3mVJwiS for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 18:47:07 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE4E1B2A32 for <sfc@ietf.org>; Tue, 24 Jun 2014 18:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1741; q=dns/txt; s=iport; t=1403660827; x=1404870427; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6bosAFYIy6H53PwlYvi4R/SXHIBp6D84wDOwlw1A4aY=; b=mr6U1WlPmvJJVfsUIc+B2fVwQAc/e5oE6maLMHRDbpu9HnC8QldW5zed N3XRbfxZLD7qFdaJXZxn4AQ0uB05NWUENoGPF8UjdNKnRt/SzkeTAAIjT Vxij2+KSwR1sXX+Mj3RiRvgCWq2xgETnKLKJVM7O/CvMkw4DVqKNZELwQ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am8FAMEoqlOtJV2Z/2dsb2JhbABagw1SWqpIBQGZOgGBEBZ1hAMBAQEEOj0SAgEINhAyGwEGAwIEEwkQiCkNyDoXhWOJIIRDBZpRgUaSJYNCbIFE
X-IronPort-AV: E=Sophos;i="5.01,541,1400025600"; d="scan'208";a="335229565"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jun 2014 01:47:06 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5P1l6oR003338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Wed, 25 Jun 2014 01:47:06 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 20:47:05 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt
Thread-Index: AQHPbIFScQlELIcIVkC+ZvduVETk7JuBNC+A
Date: Wed, 25 Jun 2014 01:47:05 +0000
Message-ID: <CFCF7721.48EBE%smkumar@cisco.com>
References: <20140510185452.30694.53589.idtracker@ietfa.amsl.com>
In-Reply-To: <20140510185452.30694.53589.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [10.155.165.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8378CA103682DF47A0953D42745E8263@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dsTWMxVRFHQ1IRNlO_hvpA0jnEM
Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 01:47:09 -0000

Hi,

We published a new draft last month.
Just occurred to me that I never forwarded this to the list.

Surendra.

On 5/10/14 11:54 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A new version of I-D, draft-kumar-sfc-sfp-optimization-00.txt
>has been successfully submitted by Surendra Kumar and posted to the
>IETF repository.
>
>Name:		draft-kumar-sfc-sfp-optimization
>Revision:	00
>Title:		Service Function Path Optimization
>Document date:	2014-05-10
>Group:		Individual Submission
>Pages:		14
>URL:           =20
>http://www.ietf.org/internet-drafts/draft-kumar-sfc-sfp-optimization-00.tx
>t
>Status:        =20
>https://datatracker.ietf.org/doc/draft-kumar-sfc-sfp-optimization/
>Htmlized:      =20
>http://tools.ietf.org/html/draft-kumar-sfc-sfp-optimization-00
>
>
>Abstract:
>   Service Function Chaining (SFC) enables services to be delivered by
>   selective traffic steering through an ordered set of service
>   functions.  Once classified into an SFC, the traffic for a given flow
>   is steered through all the service functions of the SFC for the life
>   of the traffic flow even though this is often not necessary.
>   Steering traffic to service functions only while required and not
>   otherwise, leads to optimal SFCs with improved latencies, reduced
>   resource consumption and better user experience.
>
>   This document describes the rationale, techniques and necessary
>   protocol extensions to achieve such optimization.
>
>                 =20
>       =20
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>


From nobody Tue Jun 24 18:51:38 2014
Return-Path: <smkumar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A181B2A33 for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 18:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59Q9BJq2F3sJ for <sfc@ietfa.amsl.com>; Tue, 24 Jun 2014 18:51:33 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A60F1B2A32 for <sfc@ietf.org>; Tue, 24 Jun 2014 18:51:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26652; q=dns/txt; s=iport; t=1403661094; x=1404870694; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T5wfp6JbbPNdYYqMxm9ZizOcTWzBt6YjfvfAy9SScro=; b=DZ5UgRaA9dC9IwiSL548s2C3InGJdBgASoUhSDDY9sRy0NdYnaf3d9/c uw698rmNskwTmB9mn0sj3wXqpUYvUytPsqAyIx4Py+S12Tqy77lgNG1dx I2kveg1YRPfqX9FQ1j9Cka5+BPE+sIIGeigDZxLH/r4dY96v35bH4eEEC s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnQFABwqqlOtJA2N/2dsb2JhbABagkZHUlqqSAUBkXoBhz8BgRAWdYQDAQEBBAEBAQsPEDgCBwsMBAIBCBEDAQEBASAHByEGCxQJCAIEAQ0FCYglAxENwVYNEIZIF4VjhnSBegcTDQQGAQaEPQWYVIF9jWGGCoNCbAGBQw
X-IronPort-AV: E=Sophos;i="5.01,541,1400025600";  d="scan'208,217";a="335396281"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jun 2014 01:51:33 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5P1pWoo021212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jun 2014 01:51:32 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 20:51:31 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "Ng, Tomy" <Tomy.Ng@team.telstra.com>, Qiong <bingxuere@gmail.com>, "Pham, Chuong D" <Chuong.D.Pham@team.telstra.com>
Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01
Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsYWBMAgBDdAICAAG9hgIAGeCmAgAUKzQCACNWKAIBDWsqA
Date: Wed, 25 Jun 2014 01:51:31 +0000
Message-ID: <CFCF75DF.48EA7%smkumar@cisco.com>
References: <CF77200F.1F832%jguichar@cisco.com> <5351B460.5040709@joelhalpern.com> <C8C844F84E550E43865561FAE10471853E9F0CDA@VOEXM20W.internal.vodafone.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> <CAH3bfADaXVoE_LA3cYY3a9QpkbyZY25kK75FJfAX_9+i+w8M+Q@mail.gmail.com> <DE51876A0B79C24589A3AF4BB0EB64EF951619DAEE@WSMSG3103V.srv.dir.telstra.com> <4A95BA014132FF49AE685FAB4B9F17F645D088B4@dfweml701-chm.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D088B4@dfweml701-chm.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [10.155.165.219]
Content-Type: multipart/alternative; boundary="_000_CFCF75DF48EA7smkumarciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Fak6aUP2O2QP8XIJovtjp-vDEHA
Cc: "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Haeffner, Walter, Vodafone DE" <walter.haeffner@vodafone.com>, "Jeffrey Napper \(jenapper\)" <jenapper@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 01:51:37 -0000

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

Linda,

Comments inline.

Surendra.

From: Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>=
>
Date: Monday, May 12, 2014 3:17 PM
To: "Ng, Tomy" <Tomy.Ng@team.telstra.com<mailto:Tomy.Ng@team.telstra.com>>,=
 Qiong <bingxuere@gmail.com<mailto:bingxuere@gmail.com>>, "Pham, Chuong D" =
<Chuong.D.Pham@team.telstra.com<mailto:Chuong.D.Pham@team.telstra.com>>
Cc: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.com=
>>, "Haeffner, Walter, Vodafone DE" <walter.haeffner@vodafone.com<mailto:wa=
lter.haeffner@vodafone.com>>, "Joel M. Halpern" <jmh@joelhalpern.com<mailto=
:jmh@joelhalpern.com>>, "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<m=
ailto:sfc@ietf.org>>, "Jeffrey Napper (jenapper)" <jenapper@cisco.com<mailt=
o:jenapper@cisco.com>>
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I have given explicit comments to the draft, yet not receiving any reply fr=
om the authors.
Specifically:


-          The =93ADC=94 in the draft is more like conventional Load Balanc=
e. Since this use case is about general Data Center use case, we should use=
 the conventional terminology.

SK> WOC and ADC are consistent in terminology. In fact we updated load bala=
ncer to ADC based on the feedback we received.



-          I can=92t see how the examples listed in Section 3 drive the req=
uirement listed in Section 5. The requirement listed in Section 5 are so ge=
neral, that you don=92t need those examples listed in Section 3.



-          Since this is a use case draft, not requirement draft, this draf=
t should only list down the requirement driven by the examples.
 SK> If there are specific concerns, we could discuss and update the draft/=
examples.

I see that the key requirement driven by the examples in Section 3 is to al=
low those Service Functions to be located  anywhere (i.e. not necessarily o=
n the data path). Therefore, the key requirement should be needing dynamic =
steering policies to Service Nodes, routers, and switches

Linda


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ng, Tomy
Sent: Wednesday, May 07, 2014 2:23 AM
To: Qiong; Pham, Chuong D
Cc: Joel M. Halpern; Jim Guichard (jguichar); Haeffner, Walter, Vodafone DE=
; sfc@ietf.org<mailto:sfc@ietf.org>; Jeffrey Napper (jenapper) (jenapper@ci=
sco.com<mailto:jenapper@cisco.com>)
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

Hi All,

Agree with Chuong=92s viewpoint and I disapprove the adoption of this draft=
.

Cheers

Tomy
...............................................

On Wed, Apr 30, 2014 at 7:35 AM, Pham, Chuong D <Chuong.D.Pham@team.telstra=
.com<mailto:Chuong.D.Pham@team.telstra.com>> wrote:
Separate drafts for pockets of environments will most likely overlook the o=
pportunities for identifying commonalities, synergies and reuse factors bet=
ween similar use cases for different environments. This is the painful situ=
ation today where silos exist while at this point in time where Mobile, Fix=
ed Broadband and Data Centre are seeing strong forces towards convergence w=
ith SDN, NFV and Cloud technologies.

An overall draft such as draft-liu or similar must exist as a common refere=
nce point for more detailed level drafts addressing use cases for specific/=
pockets of environments while allowing for future migration/convergence.

Unless draft-kumar co-exists with high level draft-liu, I see more harm in =
divergence rather than benefits therefore I disapprove.

Regards,
Chuong


-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com<ma=
ilto:walter.haeffner@vodafone.com>]
Sent: Wednesday, 30 April 2014 2:56 AM
To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.=
org>
Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com<mailto:jenapper@cisco.com=
>)
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I also support this draft. Being on DC level this draft will complement the=
 other use case drafts. Beside typical FW or DPI etc. there should be not t=
hat much overlap with the more carrier services oriented use case drafts.

Cheers, Walter


-----Urspr=FCngliche Nachricht-----
Von: sfc [mailto:sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>] Im Auft=
rag von Joel M. Halpern
Gesendet: Samstag, 19. April 2014 01:25
An: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org>
Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I support adoption of this document by the working group.  It is a good sta=
rting point for addressing the material it covers, and the working group sh=
ould cover that material.

Yours,
Joel

On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote:
> Dear WG:
>
> This message begins a two week call for WG adoption of the document
> http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd
> May 2014.
>
> Please respond to the SFC mailing list with any statements of approval
> or disapproval.
>
> Please note:
>
>  1. This is not WG Last Call. The document is not final, and the WG is
>     expected to modify the document's content until there is WG
>     consensus that the content is solid. Therefore, please don't oppose
>     adoption just because you want to see changes to its content.
>  2. If you have objections to adoption of the document, please state
>     your reasons why, and explain what it would take to address your
>     concerns.
>  3. If you have issues with the content, by all means raise those issues
>     and we can begin a dialog about how best to address them.
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org<mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc
>

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc


_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institute

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--_000_CFCF75DF48EA7smkumarciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <ED0383720626DC42BE268060D74C2457@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>Linda,</div>
<div><br>
</div>
<div>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>Linda Dunbar &lt;<a href=3D"m=
ailto:linda.dunbar@huawei.com">linda.dunbar@huawei.com</a>&gt;<br>
<span style=3D"font-weight:bold">Date: </span>Monday, May 12, 2014 3:17 PM<=
br>
<span style=3D"font-weight:bold">To: </span>&quot;Ng, Tomy&quot; &lt;<a hre=
f=3D"mailto:Tomy.Ng@team.telstra.com">Tomy.Ng@team.telstra.com</a>&gt;, Qio=
ng &lt;<a href=3D"mailto:bingxuere@gmail.com">bingxuere@gmail.com</a>&gt;, =
&quot;Pham, Chuong D&quot; &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">Cc: </span>&quot;Jim Guichard (jguichar)&q=
uot; &lt;<a href=3D"mailto:jguichar@cisco.com">jguichar@cisco.com</a>&gt;, =
&quot;Haeffner, Walter, Vodafone DE&quot; &lt;<a href=3D"mailto:walter.haef=
fner@vodafone.com">walter.haeffner@vodafone.com</a>&gt;, &quot;Joel M. Halp=
ern&quot;
 &lt;<a href=3D"mailto:jmh@joelhalpern.com">jmh@joelhalpern.com</a>&gt;, &q=
uot;<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>&quot; &lt;<a href=3D"m=
ailto:sfc@ietf.org">sfc@ietf.org</a>&gt;, &quot;Jeffrey Napper (jenapper)&q=
uot; &lt;<a href=3D"mailto:jenapper@cisco.com">jenapper@cisco.com</a>&gt;<b=
r>
<span style=3D"font-weight:bold">Subject: </span>Re: [sfc] Call for adoptio=
n of draft-kumar-sfc-dc-use-cases-01<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: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.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.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;}
/* List Definitions */
@list l0
	{mso-list-id:2057387059;
	mso-list-type:hybrid;
	mso-list-template-ids:-129312372 1588738776 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{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";}
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: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">I have given explicit comments to =
the draft, yet not receiving any reply from the authors.
<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); ">Specifically:<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"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><!--[if !supportLists]--><span style=3D"font-size:11.0pt;font-famil=
y:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"=
mso-list:Ignore">-<span style=3D"font-style: normal; font-variant: normal; =
font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Tim=
es New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 11pt; font-fam=
ily: Calibri, sans-serif; color: rgb(31, 73, 125); ">The =93ADC=94 in the d=
raft is more like conventional Load Balance. Since this use case is about g=
eneral Data Center use case, we should
 use the conventional terminology.</span></p>
</div>
</div>
</div>
</span>
<div>SK&gt; WOC and ADC are consistent in terminology. In fact we updated l=
oad balancer to ADC based on the feedback we received.&nbsp;</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">
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; c=
olor: rgb(31, 73, 125); "><o:p></o:p></span></p>
<p class=3D"MsoListParagraph"><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"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><!--[if !supportLists]--><span style=3D"font-size:11.0pt;font-famil=
y:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"=
mso-list:Ignore">-<span style=3D"font-style: normal; font-variant: normal; =
font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Tim=
es New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 11pt; font-fam=
ily: Calibri, sans-serif; color: rgb(31, 73, 125); ">I can=92t see how the =
examples listed in Section 3 drive the requirement listed in Section 5. The=
 requirement listed in Section 5 are
 so general, that you don=92t need those examples listed in Section 3. <o:p=
></o:p></span></p>
<p class=3D"MsoListParagraph"><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"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><!--[if !supportLists]--><span style=3D"font-size:11.0pt;font-famil=
y:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"=
mso-list:Ignore">-<span style=3D"font-style: normal; font-variant: normal; =
font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Tim=
es New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style=3D"font-size: 11pt; font-fam=
ily: Calibri, sans-serif; color: rgb(31, 73, 125); ">Since this is a use ca=
se draft, not requirement draft, this draft should only list down the requi=
rement driven by the examples.
<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><span styl=
e=3D"font-family: Calibri, sans-serif; font-size: 14px; ">SK&gt; If there a=
re specific concerns, we could discuss and update
 the draft/examples.</span></p>
</div>
</div>
</div>
</span><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"><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">
<p class=3D"MsoNormal" style=3D"margin-left: 0.5in; "><span style=3D"font-s=
ize: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><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); ">&nbsp;</span></p>
</div>
</div>
</div>
</span>
<p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"font-size:=
 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I see t=
hat the key requirement driven by the examples in Section 3 is to allow tho=
se Service Functions to be located &nbsp;anywhere
 (i.e. not necessarily on the data path). Therefore, the key requirement sh=
ould be needing dynamic steering policies to Service Nodes, routers, and sw=
itches</span></p>
</div>
</div>
</div>
</span>
<div><br>
</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">
<p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri=
, sans-serif; color: rgb(31, 73, 125); ">Linda<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 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; "> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mai=
lto:sfc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Ng, Tomy<br>
<b>Sent:</b> Wednesday, May 07, 2014 2:23 AM<br>
<b>To:</b> Qiong; Pham, Chuong D<br>
<b>Cc:</b> Joel M. Halpern; Jim Guichard (jguichar); Haeffner, Walter, Voda=
fone DE;
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>; Jeffrey Napper (jenapper)=
 (<a href=3D"mailto:jenapper@cisco.com">jenapper@cisco.com</a>)<br>
<b>Subject:</b> Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases=
-01<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size: 10pt; font-=
family: Arial, sans-serif; ">Hi All,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size: 10pt; font-=
family: Arial, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size: 10pt; font-=
family: Arial, sans-serif; ">Agree with&nbsp;Chuong=92s viewpoint and I dis=
approve the adoption of this draft.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size: 10pt; font-=
family: Arial, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size: 10pt; font-=
family: Arial, sans-serif; ">Cheers<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size: 10pt; font-=
family: Arial, sans-serif; "><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size: 10pt; font-=
family: Arial, sans-serif; ">Tomy<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-AU" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, =
73, 125); ">...............................................<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU">On Wed, Apr 30, 2014 at 7:35 AM=
, Pham, Chuong D &lt;<a href=3D"mailto:Chuong.D.Pham@team.telstra.com" targ=
et=3D"_blank">Chuong.D.Pham@team.telstra.com</a>&gt; wrote:<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU">Separate drafts for pockets of =
environments will most likely overlook the opportunities for identifying co=
mmonalities, synergies and reuse factors between similar use cases for diff=
erent environments. This is the painful
 situation today where silos exist while at this point in time where Mobile=
, Fixed Broadband and Data Centre are seeing strong forces towards converge=
nce with SDN, NFV and Cloud technologies.<br>
<br>
An overall draft such as draft-liu or similar must exist as a common refere=
nce point for more detailed level drafts addressing use cases for specific/=
pockets of environments while allowing for future migration/convergence.<br=
>
<br>
Unless draft-kumar co-exists with high level draft-liu, I see more harm in =
divergence rather than benefits therefore I disapprove.<br>
<br>
Regards,<br>
Chuong<o:p></o:p></span></p>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU"><br>
<br>
-----Original Message-----<br>
From: Haeffner, Walter, Vodafone DE [mailto:<a href=3D"mailto:walter.haeffn=
er@vodafone.com">walter.haeffner@vodafone.com</a>]<br>
Sent: Wednesday, 30 April 2014 2:56 AM<br>
To: Joel M. Halpern; Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.or=
g">sfc@ietf.org</a><br>
Cc: Jeffrey Napper (jenapper) (<a href=3D"mailto:jenapper@cisco.com">jenapp=
er@cisco.com</a>)<br>
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<br>
<br>
I also support this draft. Being on DC level this draft will complement the=
 other use case drafts. Beside typical FW or DPI etc. there should be not t=
hat much overlap with the more carrier services oriented use case drafts.<b=
r>
<br>
Cheers, Walter<br>
<br>
<br>
-----Urspr=FCngliche Nachricht-----<br>
Von: sfc [mailto:<a href=3D"mailto:sfc-bounces@ietf.org">sfc-bounces@ietf.o=
rg</a>] Im Auftrag von Joel M. Halpern<br>
Gesendet: Samstag, 19. April 2014 01:25<br>
An: Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</=
a><br>
Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<br>
<br>
I support adoption of this document by the working group. &nbsp;It is a goo=
d starting point for addressing the material it covers, and the working gro=
up should cover that material.<br>
<br>
Yours,<br>
Joel<br>
<br>
On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote:<br>
&gt; Dear WG:<br>
&gt;<br>
&gt; This message begins a two week call for WG adoption of the document<br=
>
&gt; <a href=3D"http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt"=
 target=3D"_blank">
http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt</a> ending 2nd<b=
r>
&gt; May 2014.<br>
&gt;<br>
&gt; Please respond to the SFC mailing list with any statements of approval=
<br>
&gt; or disapproval.<br>
&gt;<br>
&gt; Please note:<br>
&gt;<br>
&gt; &nbsp;1. This is not WG Last Call. The document is not final, and the =
WG is<br>
&gt; &nbsp; &nbsp; expected to modify the document's content until there is=
 WG<br>
&gt; &nbsp; &nbsp; consensus that the content is solid. Therefore, please d=
on't oppose<br>
&gt; &nbsp; &nbsp; adoption just because you want to see changes to its con=
tent.<br>
&gt; &nbsp;2. If you have objections to adoption of the document, please st=
ate<br>
&gt; &nbsp; &nbsp; your reasons why, and explain what it would take to addr=
ess your<br>
&gt; &nbsp; &nbsp; concerns.<br>
&gt; &nbsp;3. If you have issues with the content, by all means raise those=
 issues<br>
&gt; &nbsp; &nbsp; and we can begin a dialog about how best to address them=
.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; sfc mailing list<br>
&gt; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/sfc</a><br>
&gt;<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><o:p></o:p></span></p>
</div>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU"><br>
<br clear=3D"all">
<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU"><o:p>&nbsp;</o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-AU">=
-- <br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
Qiong Sun<br>
China Telecom Beijing Research Institute<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:=
p></span></p>
</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>

--_000_CFCF75DF48EA7smkumarciscocom_--


From nobody Wed Jun 25 07:31:50 2014
Return-Path: <hannu.flinck@nsn.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952A11B2CCB for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 07:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anHJBKaLAfH1 for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 07:31:44 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270D01B2CA2 for <sfc@ietf.org>; Wed, 25 Jun 2014 07:31:42 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s5PEVcJS006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jun 2014 14:31:38 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s5PEVchX013220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jun 2014 16:31:38 +0200
Received: from DEMUMBX011.nsn-intra.net ([169.254.11.51]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0181.006; Wed, 25 Jun 2014 16:31:37 +0200
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: "ext Surendra Kumar (smkumar)" <smkumar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt
Thread-Index: AQHPbIFScQlELIcIVkC+ZvduVETk7JuBNC+AgADy9ZA=
Date: Wed, 25 Jun 2014 14:31:37 +0000
Message-ID: <29264E37AFF9384FAEBBC9C6CD32643415DA3A73@DEMUMBX011.nsn-intra.net>
References: <20140510185452.30694.53589.idtracker@ietfa.amsl.com> <CFCF7721.48EBE%smkumar@cisco.com>
In-Reply-To: <CFCF7721.48EBE%smkumar@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.99]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3500
X-purgate-ID: 151667::1403706698-000005B1-5A06F44F/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mqMF2f0iABGCWvPEdxZebcqQcg4
Subject: Re: [sfc] New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 14:31:48 -0000

Hello Surendra

Interesting reading. Thank you for that.

I have couple of questions related to this draft (and to the arch draft):

In section Definition of Terms you define:

Network Forwarder (NF):  The entity, typically part of the network
       infrastructure, responsible for performing the transport function
       in traffic forwarding.

Service Controller (SC):  The entity, typically part of the network
       infrastructure, responsible for performing the transport function
       in traffic forwarding.
=20

So if they are the same (NF =3D SC) why to have two different names?=20


Why is optimum path in its best case starting and terminating at the classi=
fier itself (in section 3). Is a null service path a service path? Do you a=
dd a NSH into that one? If not what makes the optimum path of null path a s=
ervice path?


It is interesting choice that you do not ack transactions of offloading, ac=
tion, etc but you allow capability exchange.  =20


Now this one is hard to me:

You write: Although SFs can signal SFFs by piggy backing on the serviced pa=
cket,
   SFFs cannot repeat the same towards upstream SFFs as the traffic is
   forwarded along the SFP while the signaling has to go back to the
   upstream SFFs.

But isn't NF in the same position to SFF as what SFFs are for SFs?


- Hannu


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Surendra Kumar (sm=
kumar)
Sent: Wednesday, June 25, 2014 4:47 AM
To: sfc@ietf.org
Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-sfp-optimiz=
ation-00.txt

Hi,

We published a new draft last month.
Just occurred to me that I never forwarded this to the list.

Surendra.

On 5/10/14 11:54 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A new version of I-D, draft-kumar-sfc-sfp-optimization-00.txt
>has been successfully submitted by Surendra Kumar and posted to the
>IETF repository.
>
>Name:		draft-kumar-sfc-sfp-optimization
>Revision:	00
>Title:		Service Function Path Optimization
>Document date:	2014-05-10
>Group:		Individual Submission
>Pages:		14
>URL:           =20
>http://www.ietf.org/internet-drafts/draft-kumar-sfc-sfp-optimization-00.tx
>t
>Status:        =20
>https://datatracker.ietf.org/doc/draft-kumar-sfc-sfp-optimization/
>Htmlized:      =20
>http://tools.ietf.org/html/draft-kumar-sfc-sfp-optimization-00
>
>
>Abstract:
>   Service Function Chaining (SFC) enables services to be delivered by
>   selective traffic steering through an ordered set of service
>   functions.  Once classified into an SFC, the traffic for a given flow
>   is steered through all the service functions of the SFC for the life
>   of the traffic flow even though this is often not necessary.
>   Steering traffic to service functions only while required and not
>   otherwise, leads to optimal SFCs with improved latencies, reduced
>   resource consumption and better user experience.
>
>   This document describes the rationale, techniques and necessary
>   protocol extensions to achieve such optimization.
>
>                 =20
>       =20
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

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


From nobody Wed Jun 25 10:17:58 2014
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273931B2AB3 for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 10:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level: 
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS1RE4smcsrN for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 10:17:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBD51B2A8B for <sfc@ietf.org>; Wed, 25 Jun 2014 10:17:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJG45470; Wed, 25 Jun 2014 17:17:48 +0000 (GMT)
Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 18:17:47 +0100
Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml703-chm.china.huawei.com ([169.254.5.42]) with mapi id 14.03.0158.001; Wed, 25 Jun 2014 10:17:36 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "christian.jacquenet@orange.com" <christian.jacquenet@orange.com>, Jiangyuanlong <jiangyuanlong@huawei.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: Suggestions to "draft-boucadair-sfc-requirements-04"
Thread-Index: Ac+ASSw6EqtHtNzASnqrgNUnvnRaZQP1xq1Q
Date: Wed, 25 Jun 2014 17:17:36 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D6B87A@dfweml701-chm.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F645D2E2D7@dfweml701-chm.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2E2D7@dfweml701-chm.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.144.207]
Content-Type: multipart/mixed; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F645D6B87Adfweml701chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Se4aQLSiJGyFUridp1oN3QtU29Y
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04"
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 17:17:54 -0000

--_004_4A95BA014132FF49AE685FAB4B9F17F645D6B87Adfweml701chmchi_
Content-Type: multipart/alternative;
	boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D6B87Adfweml701chmchi_"

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

Mohamed, et al,

When you get a chance, can you address those suggestions?

Linda


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, June 04, 2014 6:03 PM
To: mohamed.boucadair@orange.com; christian.jacquenet@orange.com; Jiangyuan=
long; Ron Parker; Carlos Pignataro (cpignata)
Cc: sfc@ietf.org
Subject: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04"

Mohamed, et al,

The draft-boucadair-sfc-requirements-04 has all the requirements lumped tog=
ether, making it difficult for people to validate and provide comments.

I think that it is beneficial to create multiple categories of requirements=
. So each category can be reviewed and validated more intensively.

With this in mind, I took the first stab of breaking the requirements in th=
e draft to multiple categories.  I didn't change the order of your original=
 ones, but shuffled them around, so that similar ones are put under one sub=
-section. I also added some comments for the requirements that I don't thin=
k make sense.

I only added a few new requirements, however, I didn't add any new requirem=
ent numbers.

I suggest each sub-section has its own numbering scheme, such as "OAM-1, 2,=
 ..", so that any addition or deletion within one sub-section won't affect =
other sections.

Please see the attached with the changes marked.

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F645D6B87Adfweml701chmchi_
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: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:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	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"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Mohamed, et al, <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">When you get a chance,=
 can you address those suggestions?
<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">Linda <o:p></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"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></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;"> sfc [mai=
lto:sfc-bounces@ietf.org]
<b>On Behalf Of </b>Linda Dunbar<br>
<b>Sent:</b> Wednesday, June 04, 2014 6:03 PM<br>
<b>To:</b> mohamed.boucadair@orange.com; christian.jacquenet@orange.com; Ji=
angyuanlong; Ron Parker; Carlos Pignataro (cpignata)<br>
<b>Cc:</b> sfc@ietf.org<br>
<b>Subject:</b> [sfc] Suggestions to &quot;draft-boucadair-sfc-requirements=
-04&quot;<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<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 draft-boucadair-sfc-requirements-04 has all the =
requirements lumped together, making it difficult for people to validate an=
d provide comments.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I think that it is beneficial to create multiple cat=
egories of requirements. So each category can be reviewed and validated mor=
e intensively.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">With this in mind, I took the first stab of breaking=
 the requirements in the draft to multiple categories.&nbsp; I didn&#8217;t=
 change the order of your original ones, but shuffled them around, so that =
similar ones are put under one sub-section. I
 also added some comments for the requirements that I don&#8217;t think mak=
e sense. <o:p>
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I only added a few new requirements, however, I didn=
&#8217;t add any new requirement numbers.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I suggest each sub-section has its own numbering sch=
eme, such as &#8220;OAM-1, 2, ..&#8221;, so that any addition or deletion w=
ithin one sub-section won&#8217;t affect other sections.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Please see the attached with the changes marked. <o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Linda <o:p></o:p></p>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F645D6B87Adfweml701chmchi_--

--_004_4A95BA014132FF49AE685FAB4B9F17F645D6B87Adfweml701chmchi_
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
	name="draft-boucadair-sfc-requirements-04- Linda Suggested Changes.docx"
Content-Description: draft-boucadair-sfc-requirements-04- Linda Suggested
 Changes.docx
Content-Disposition: attachment; filename=
	"draft-boucadair-sfc-requirements-04- Linda Suggested Changes.docx";
	size=40330; creation-date="Wed, 04 Jun 2014 20:43:15 GMT";
	modification-date="Wed, 04 Jun 2014 22:53:14 GMT"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQBjgxjKjgEAAKUGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0
ldtOg0AQhu9NfAeytwa29cIYA/TCw6WaWB9guwwtkT1kZ+nh7R2gJUYttcXekBB2vvn/fydDPFmr
MliCw8LohI2jEQtAS5MVep6w9+lTeMsC9EJnojQaErYBZJP08iKebixgQNUaE7bw3t5xjnIBSmBk
LGj6khunhKdXN+dWyA8xB349Gt1wabQH7UNfM1gav5AAV2QQvArnn4WiPnxlXEYHlaKDGBGNBfdt
Wd05YcLaspDCk26+1Nm3nqHJ80JCZmRVA6KaZp2RgEjOVBntyFc1mafxA+SiKn3wuCZlbRgOSjyu
6dZkRJWNMFwUFns69LvaKtsbTmeuH3NCOB1ZiULv9O/VoSs1A0ex/v8tdeiDItBvSjjDnLTcvvYU
1qszFjlN5OAEoB6/DLKQhtWC8wV087M3fwTvKf1zmN+S/2RfVuiNGpxAiznGv6elA7x5jge3bzB9
fpu9lNMmmopZCYP7/VhMHfqgiBXM3s529V/gfUK64ZfGnRDGbmHW1b9cOW9+MuknAAAA//8DAFBL
AwQUAAYACAAAACEAmVV+BQQBAADhAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz0rDQBDG74Lv
sMy9mbSKiDTpRYTeROIDDLvTJJj9w+5U27d3LYgGatKDx5355pvffOx6c7CDeueYeu8qWBYlKHba
m961Fbw2T4t7UEnIGRq84wqOnGBTX1+tX3ggyUOp60NS2cWlCjqR8ICYdMeWUuEDu9zZ+WhJ8jO2
GEi/Ucu4Kss7jL89oB55qq2pIG7NDajmGPLmeW+/2/WaH73eW3ZyZgXyQdgZNosQM1uUPl+jGoot
SwXG6+dcTkghFBkb8DzR6nKiv69Fy0KGhFD7yNM8X4opoOXlQPMRjRU/6Xz4aDBHdMp2iub2P2n0
Pom3M/GcNN9IOPqY9ScAAAD//wMAUEsDBBQABgAIAAAAIQBBQiNEGAEAADkEAAAcAAgBd29yZC9f
cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AKyTTU7DMBCF90jcwZo9cVKgIFSnG4TULYQDOMnkR8R2ZE+B3B4TKU0qqrDxxtI8y+99nrF3+2/V
sU+0rjVaQBLFwFAXpmx1LeA9e7l5BOZI6lJ2RqOAAR3s0+ur3St2kvwh17S9Y95FOwENUf/EuSsa
VNJFpkftdypjlSRf2pr3sviQNfJNHG+5XXpAeubJDqUAeyhvgWVD75P/9zZV1Rb4bIqjQk0XIrhD
In8z5z2lrZEETErkOYFfRngIiUC+NTjnjyUf12SNYROSwdHQ+TnOTRjrtfgkZLw+qhytn8NMcJLW
ILYhISqjKZN5t5jFSVqDuA8JURj1+1QXo5iUNYS7kAhfmL/9+RULcQLhZx8+/QEAAP//AwBQSwME
FAAGAAgAAAAhACKKmsFxZgAA3RIHABEAAAB3b3JkL2RvY3VtZW50LnhtbOx923LbSpbl+0TMP2Ro
ImbsCUmmrrZ1yuyQJWtK3b6oJXkiqk6chxSQJDEGkTy4iNZ56t+Yt/mW+ZT5klk7AZBIkJAAyxIz
6azuKkskJSEv+7722n/7l+/jkN2KOAlk9G5jZ7u3wUTkST+Ihu82vl6fbb3ZYEnKI5+HMhLvNu5E
svEv/f/8n/42PfKll41FlDL8iig5usW7ozSdHL16lXgjMebJtpyICG8OZDzmKb6Nh6/GPP6WTbY8
OZ7wNLgJwiC9e7Xb6x1uFL9GvtvI4uio+BVb48CLZSIHKf3IkRwMAk8U/5Q/Ebf5u/lPnhaPrP7i
q1iEeAYZJaNgkpS/bfyjvw1LHJW/5Pa+RdyOw/Jz00mbv+bHfIrzGIf5Y09l7E9i6Ykkwaun+Zuz
37jTu+9vFxtIv2L2E20eQf+b5ZOMeRDNfg3djtr5zw5vG4f3Kv/br+hXzReCvejjLt1I/47+nbDp
Ee6if/luo9c77r0+Pny/Ub50KgY8C9PKO+onLmL6J5lwD7uBz/JBKnAlcJGnR2FAT7W7P/vmMgvx
As9SufGKfizOfzo+k1Ga0A8nXhC82ziRWRyImH0WU/o1gifpcRLwhTdGx1Gy+HEv0T+o/lLyF37R
LQ/xOD3626+KP45/J/QQ9K/bAbcDbgc67MCHg8P3xztKgyghWgM9ALVAG7B6xTQ9UpZdaVbozEks
EhHfio3+1dkJ+9H/fNpmpOnSXP+pk46lHHyIY2jH9G6CP5RMRBhepTxOCxVtzHb038vM4z4P4lZr
+BD5haLvotjdlX46W9t4pc8j+AyRSLfgTQ3Sbpf7xOor/a/c+zMTWLq70oW/18pbM19L05WOfOFT
9JZmyVFd7/oihMoN/MJThks8knCbP77eO+jtk9Pr85R8597O/lbvcKu3f73z+uhg76jX+6eyt6Sw
yVM/FXBpe73TN6/fnB3k76zcp8bDi/BafG8wYOdRHpEi9OPhfcJOMlH8ptJg5a+QSQoiChhoA3do
u354A1WoY9j2pX0YYMT8sZ+wNObet5p2KA/fyGenRMKi1/LQOc9cEpwwjlY5HeZ4HmcxjzzBrkUo
EEprp4Hndf6FOSf14fskgKt8xL54qbyBTTncZKRE77t/1ff+sc3+NeDR0J2xCoHodhf2xJgz7q5g
qgeMr/+e8akIIM3eKJKhHAYiYSdye5N9TP1td/Dre/C1e6C+vdxmF0iKCz2odFrdfBd72Wm2eO0Y
RYx4DM/8s0iRDP+WOIn/hSQe6YKLYBhxJLikO/hf4eBPgsST7OouScU42WTnkedsfJ7fXkvnbqkF
+Ldt9pkHqZP4X+3g1W34fH3tVP2voOrVaR9P4iBkvf087n/MwRcACAp816W82TGucTvg6oErqAdW
bfil+DNDRo+QbglD4YBdoQwOFBo7yyKP4GPsZAQcFIGPXqA0/vIxAu8Oe8WHnR+8doTQvXWIwjDm
YzMRCoAKAip5U+IUtpKBtxVXLjDqeG0W92PQBaesnfw+qfz2j28SKkfqYAXnUnTcAXdLn/SWNpaH
rkdBwmao+cCHRxEMqPaTjgSramnlZtCLdVdD093u1K0oEWhnZpUzofu1etKyYSHOcShCdSecJgln
XwviPgJekfGh0CSz44E5X9d5EavyIgT7Ju4Y9VElbOPT16vrjc38X/b5i/r68sO/fz2//HBKr1/9
/fjjx9kX+Scec/Hdsa/m2HGQX75+LI6Uvpof9smXT58+fD7Nz/vT8T9w2gBvso0vF9fnXz4ff9xg
QQQfM3BAAwurT5qsNnhdhuaiimbbNiso/EaTfIaGMI7HgqWS3QgIFZpG0BaVAsrDEdiJxIuDG3wD
abtEj9Tuzs5b9ju+oi/+0N1n52103AFndp7U7BDeH10iTA6YylJ8EuNHYRWce+wu7JNe2AbtzPLr
W+vnQ9otyW7GQUqqGtp5kIUh82TeBkR9FdMgHVEWTjNVTkNZYI5Zva/NomIdHvU2IOIV3TFvcPLs
cZFgRN6fXLDXb1QYor5869wfPfZwysUK5aIbkoSR90+YfUJ7lJUc5TVRtab8MPsQDUE8I2J8ylkU
+3B/1zz5xs5kDMfgxfmH67OX24x9linivhFPmcRRx2wYy2ySsDG/YzxMJPMDVKaDmyx1PoSu6KwQ
c01KG+yvmUmWQhm1WYA9DsRcsyKvUmrVnJsjgSxeQ9eGkDeKVr0sjomDbvYpbSeclXXi92TMbURj
pPhiElZLrTdoEHsEEGauoPIDCwhXDBAi3g5EOlAkjgplmLwqZO+V8+11k+e0jhVaZ2YyCiEm317d
7IpnD8LGwFdwLA5f73swzsZkdZLgOxuDMnKkR+7u4K04eM1FaNDVZnp7KOu2eXh7DA3FTyilZRPY
GeFvAgU5CblHX6HR4qGlGswUKG8SGVJlsNUa7Dmvm7si/q246CnSfHfaOp0edHrwSd3uNBjreZYG
LW6gYPURwJ6niBhQiOITlADQLQrdR5iCLJnnEItol4AFsRgIxLievmInY07GnlTGwGePDDYPNc1u
j5w1FIjhVkDSvEBlcwWceZXNRWI3IlHboHQaVYghl0OwuCXbG9ryOwqdQ0E4FIQ5KIhpANSDUPSE
DF3LNX5Cl8R5VBLHibrbAbcDbgfcDrgdWEunZwFXV8++LXzAXJaMH5rjYVK42d9kAmm3UHfarA/O
CtqdgkK77qFWSXno698v0MPJdv54TIS2lqJqzAChEHPTLgWmUMTCp8N6Hwv+Tc3XaJjMoKf8XbTd
cQfcbX7SaLuvV4x1fURTsbQuc/1tfJfzAtIsgMdoLOdeuR1wcv60cn4iJ3dxMBylBPsF1Z+TVw3E
7aySSbFAQ6GDYaJIeYtfeC/zGTSEZmfXcQbsLDEEUNPCBLOf0YHEZnRUqpkZ7zzm0jsF9aQKqvHI
tTNrCAfNRDaVeJI2KzCwqt9wIvlQOMKsH6P2okwK1fPVINXHTfpxTpDTMavRMTUWQ9Va/b+El1Jd
vdL2SbZlbm7+W8I+imENTOD8CCv8iItZmzIC3JCn1PuIs1aHe1pwvDgctF49tuJgXxQ9Hik5hELM
+ztCxDxRIrYCMCS8JDiMGAxIwoEaILEmrC5Q8JqpdrJsxZFrZ2aVgzjJbnAtoX1k1GYR9viIaCch
brZZ0wmcxYtQcGBBY3EbiCmJHL4pHWSnaS3UtG1urJlxmYeuKKLL0QH+DZrDQKFDpRS4TojQ3Yyg
jd3JLC6DMUqDICBD776a5YGR3kQFhFcmMHjasTkL5yzckwKua9Ph7JGxhuRH3aqdSF8gKTmeyEjN
0hHfqbGYKLkGsRzrRpCN4ZI68dPS7k78nlT8gsgLM19Pe1svg1fBeBLSkAmfvb86ZR/zwI6lkL0F
ztIrWDwaZ7W/7aI7Uj1O+MBz9FlMN9j0CPHIkwofHDRN21sveHmRTeU8WSWBRu4m8QwALHmLipuv
3E2ZpWzK45hHKdikXIDnJC94Psmb0Vavl/whaUmpyuX2T4fNdgzsXOXNVd6e1hhe85uQXDAES6CY
x9hRTTTdde24A+66Pul1bYj+GdshpoMojaWf5YEF2+74f4ztPubqu4NfzcHv4uCvRTwOIhnK4V3H
Q6dL4g7eyvhzDyd3KlIehIhsNDD8R6LrbHERGNtzEm9f4mEfB08NEKcBH0YyQTXzv/Lx5DdATSXK
tiIZSeCoARu53wAw9tYdvn2Hf4DDPz/+fEzuaoKkRqyK9MkDh129Cmyn5w7evoM/JKkXYIENkLf6
ocN3B2+lnX+Ng6fYVBHeyzhpY9mr8o4f39lxEm+fxL/ByR173yI5hYc3FGNVx+2g6N3B9+na23fw
b3FylyUP4Q/Iuzt4Sw8ePvm2rqobSnNmwtdw7z7LGFSGwe2aFRi7SqOzuFYqXpI/PQlqm/yd52MW
f3UJfKT8uaqjy+Y/aTa/Xy/XPCY+c7fV3dYnva2NRcdad6qPCJXgj6oFALD+P7MgLsLWAVFBE0RE
xLeARbKzLFJlysfce3fqqzl17cyscpBORjyIqDTyAvWTlzowqWEhBnbZNInjOZjUeQwKnSzk8ZF2
SvDGJ/2/4X+ALo1RNrh8t9HrFXajfOlUDHgWppV31E9cKIK7ZMI92rjpER+AqR4fIqBqiMGr7zZ2
92ffXGYhXgARg9xQzHMq94I/eYb8Jbp9jnjiBcG7jRP0BD0T6o5WTkvouANOt6xGt5Bf9D9EhFkI
nm5ACMdLYyhR6wbasETP7+ky3PGQnePkrvlqrjmBdqiE7+clfOjsxduOIcdeliT6hd93F15P6HcU
eXfhV3PhCaxUVq+3qN0XccKSO7+o4Q/dhXcXXt8B+JPkma7et8RM4iZfXI3NlreA54CKDP1HwGWN
GTnRgoaRzdpA4Ms8xk932mw12kw7s4bA0cwS3e/nWw89fH3UgDnC1j9VrEmtFmBg3N7fSgbeVqEM
thKM+lbJsT90C9dwnYr1dHR3XITjVOSTqsh+rf1Ak013WTvugLusT3pZ73XWMC0DaGoG9HwW+jQm
e8DHQRjwOCcpouIFEp9jct4GSHtSGuoxl90d9WqOWjuzBlvrXLdKcn50jD6DhZS9l+gvqWx/8hdS
/Lc8REmgR/l/aL8iSEud60a74WowbgfcDrgd6LIDa+koIAiWgw8xfKuj9G6CknE96bDwATffMOC6
ycXe/STb7OYblvMNd918Q2Nz7W6+4ZynqpP7TY6ng8DkOCaDktluvuH8Pv8EQ/aDt9xlyNfSwTRH
zu9NOpZzBtiYfwNsOsPoATWhANlHGYZyqqa/UNbRwTl1v6RjMsXdcZdt1VDHD+YrpQLotckWG1lp
FhHRGvoYZDIG5P0IRYtIptAwnEUincr4G3uBjgwO1OGQWKhR3YiFHLzEF9wxweuqxgq4EUjc2txV
MysbRJue9wm1WYOB8tZg44Hw1bEdHa2W802d3XZ2u7vdznsM10uXlA2T7KOUkyN2PoDxrjdTMtXf
RgBTjFgCDWwWC1/bhY76x0nfaqTPamO+boOV4DcD6nMrvy02LycYnBSmAZwXlgZjkWD6GQshniSB
8Kid6NlHvWW16Ik4lrF26xoATva40BSPMumB9hLtwyORz5lI+HhRGEnocjl1Ns8FsM/XYA4EQz8R
qtNnzUSPTFoudCNMUkKv/5CGUXN2IzMMVsJQciWcdSdU2wTncLrs0VNPM1NBj55nsd7sYZQHk5SU
ZcjV+nPHcpbGxZR4Mva5CFbtI3fy57zOZ2NXIeOHptZvQi8aWC9/yuChfHKDEYELaZZNFGdjjBCk
iYIyoi9IQCPndjq383ndTkyxBNOuPrDMetGTEXrk+RBVS4bQb6mLCacUQ2/wHoV8CUOGxhk9Z/Se
1eiB1kFOa9l160UP1o7aHOsRXVlWQB40mQV/usPdMc5zhU1XWllNaUUzFA0CayZIggBJa13YvJoE
YMupQpWaFFFEDoA30s6yowZy8rca+bO6vkLZT+3SNSgQe8orMOgu1NUcxx/qrHFJ3qdO8v6qoa5z
s/WkkjPzTtc8ta757zTGKtXhO9ZbepVIS+QS4ATQgtlkIuOU3WRBmG4h8TYopjMAxiQ1h8eJny3i
Z7WjzT1PjscS/vaaSWGiYtzkN8qzodcvyQP6OSHyXPDG/M5JnpVJbaslrxjao1299bB9lNlW8KVY
eAJlMzVHgoOTmbJOJe2fHwwGAF1Q7UnbAmf3nN0D385Te57TmtJfD8mbBuBAj0UCrLySLEy9ICnD
sDBiRvdEkihoIWYCJHkvKo+c8DnTp/V9PYPwwUBo18564ZNxMAwiGDcye5i/oU/r8yXQvdTcQtQT
CAFdPQUmrqRJMo0sqKHBGK6m+k+be2tmVZMnSTaepND7bdZgYGGl7zK0utg4V9kWV7mNxJmpNZCh
PW7z9AbqiwZN3gB1QBZINbWFtyCGivDfmI0lJiEuQ4I4wbNF8GCzZ+38OeolcVbEWRF9B2y5zG30
sLFW5GsUBt/WLOxbMCVESbBZJDrBAAbzQWGfJzHXARNPkAjleguBMyS2yB4Mib3ipxoY9ZtnT8rF
hX2QkWq2xCkNk5RGn+btnoqUo0/KZ5fizyyIc4Y99hFD1DWl0fHkXO+Gw46vBjt+jQrunBY5ESCG
GcygSkhzF7XrMQpLwDTN5rhVHB307T7m6ruDX83Ba2fW4COYGWKsXU0Jk6uDIbgpBvd0ClI1N5Fh
Rll9x1vewk0q9ApqnDFCsstTMeColb/b6PV+tsYJIjD6HAU+JvRt4AuepSMZv9v4+HrvoLdPrxDk
jsb37exv9Q63evvXOwdH+2+Per1/0kA/POCZJO2KH028YHEs4FMCJMhPyety81XsdV6FWoTh4+P3
tnf0uA5Lx5rpqedLV8fV7gAP9tQBmrX0fpmnKDGPSHQnKY/SgC+UA5et/2Atj77qq2tmr9wCkgI6
yAlkUGmLipooX3pCBWKA/C/dgSIq+TV2wKRIs6Gexdjlh3//LztHyFCR2166A+zT16tr9vnLdY46
4RH4dWYIAFS4iG4OPlPsClzaAF268pZBUio1roS9uDp7qRLPvpiE8g4pCR/5CC8N7+jMJ6O7JPAQ
wI1ApQQ6JbFZ13yLGs/J+ypcMNB9Nco7Djz/j3Z4uLj1UZ/mTvKs1UEant0eUEEVMfA/gzjNIGOf
uDfC+Ppkk7AEpH/RaXMDlCD5XBTT0RgYV4xuEbQ5DWSaBiKPY9d5HD9lLLDtHoeAmqOeA1S4ycVA
n4+Y8BjJDcZ9H68nNB6Lfc5nYWkWy4UXVoQXpbfBPuSjo3J7RgPOtNOcHlEnKSoClzwaCpUkRoxI
CbDDIqFleC4I+bngL+TcYLoT+MiUW0Xy9Z41wj25Z4VX6R3u/fToloc0TTzfGqG6cTxBO4Lrr+q6
840r363+VvqUoemkElmnPBxtn5xkl6dWxJKry+WueyARrxmmzJNbuTFFzx41xzJq2YMiWWJMqwrZ
iZ+GkXHiJ6aUtX/KKhExkiOs1W6e9YG8i9GPkr9Kr2V3aWrUGXe7tAv8dyJZOmLkhGYR8r+UgQK/
MEIygTlPsDihxIvIFZeFwplnpwm3O3jrDl47vwblbCaeB8WJNg9vT4q4Ao6bTWFWkjjjJFKN4yAr
0tbdUegcZtTtgNuBnw3mMgCLsUR5JxMRhhXtbVH9773MPO7zQAcJN63RQCXf32RARfNQL+AtWQDV
YA18/vuLyx++g6sLpCVfvFTeACNyuMkIqDjLBBdf/H7Bh4Lt/fEYg7WWoppnbA3O/T3mxJx5cXf2
SbsT+udRKuJIpFunMR+kuta5OjupIjcT/V367ngSB6HSV+6Wa0lRF0p03AEn508q5/f7IIVgazLc
4F9VfGBzLG+/DPjzdFubddjjJyI7k0PY0OcH2EemGgQTT07wTdGwdHaiLdmJnksexoABPUtZCpGx
FwyKTLd2DRs0iD2SJwYQuVQPOzvKlnPgnWFfjWEn3OheM260aCtXYOnz48/HgBUOwaEQ39EY6LI4
pYlzx5vvzn015z4L0rTDa9DFZnpzs5Kornob1lDYk6XXs7iEKLI/dQ+yAWnrpTtQGKBiB04FAJK9
3unJ7u571Wr6C2zL9Ggsb8VZLMcLaNnXbbttD496+6rbGPsY8TGayel37r15e3i4s7v7OgfdNmFy
3+Rvl0+BX0FI3bed/7aCpi49SMPRvlBJZI32m62RapcE8A6dOxNwt4kBmnl89PKAyY2CnAZi0HJH
Fb73oW66X/vqF5dup/dL3bqZLZxbFMbO0ZvJ4zTwspDHm4rxY7GRt+IeaXYUOtbdugdAa/MtKm/d
zq9563S/OpUsSSmFk95NVGNwHQGWT6RfJM1dvHBVSwP3p9jmws5oHArO/C/extYkMTOr387yPr4L
RZ0gVAwyq07RTB9Exy4ebWvmnI5Ha2ZPCTlVB6VThZ5AsMyUiTjymubMM0vgpoWyccZtPidbUUE9
hMhevHOtKYvW4s7NXCoMWScoc4hhqkz1pXJ/HESUQkIRBsT+vhzzIPqNBeitSdhEhoF3t3XDE+G7
O/foO9eaJmq97hyHr5OTrVDz6xzM+/CNKn0olQKYu0xF5H6Py1TlrXPJfJfUXU1Slyz9YWnp9WiV
h6GcsjGoFYMJehdzo4/xg+QBcDaEKo7q4vFQqqR6592Jr+bEZ3Z2IUrUTrMhJ25mXv8FC7b1jouG
x7emRLy9WSctmFNZ7hx2yHpUuCyLDO9lJVFveH5X0zna9UQUizfV4xuzhj4v88nzeUUej9Cjx8T4
Rvj+oofqFKYxp/cwkE27gA0Kxkz9GOiWuuHZrVGO96jGLoU3q1Uj0dGlKWibkIJBoKzdTSOV48yR
LFikSuKL5OV2/eG7aEUXOjlHesWO9HE5LBrpqAxpKAV0CiX3kZUKeeSB+2UTKS18n4CyVX2Xysfc
eXfiKz5xiqG0A2ywqGZ6A5RNHQd/rVfApMrt6MnnXj7nBqOcMup+fCG2hwimbu7YWHAQZqjkxUg+
aqaTkz8nf8APFTh4LyFqwJaZd+Jbqk1VatAd9njjngx9IBCQQ4eUoX89BVU50SPnw29eAgkjGfcI
WiBpXoqmOOGqdvH2nOQ5yXuE5E3gjgH/p91A68WPqqGpiOBoom9rIqhKCmYoojbwXGTlmMn1HbCr
f+09Iqu/owgFov1EzEtRvrgNqBBFDYxBdCvDWwRd4NnEx0BcHdObmoiv2MhUMvdvOmTuDwwbI2ZO
V+7DqVq7AzRfhKiuxmvGyonsSBuIxaI72NxUor9zUStsFTOAEsSExAOO+QsDUFLgQySEoAanyX37
s28usxAvYEKcLJjO68Pzdro0VpglvEsVoL551dK8/s4Tbyv4SeloWoxWBOTIrG2tzhfc7QJFz5dh
WPVyb3t3sX55MoJ3WR0VXDesqgr7Y/eL1v+TZXS3CwTbrMu04j00tc1Q10XPrKUM2JQcFnwtF1oM
d7tD0qFnO/cY7u7PmwyvJX6Dmob7gzBR84v9T9ZOeC37pDoN824MuuDl1eoCbspbZ82yow8HJ5oJ
bUg/mVk5mnc7tlmDPRnsn9K66SQcg9DJWEDNaZR1pQkrJbwLRsdJeKWyhA186lkgP7GzlOShQbsV
mqG0h8u7TkvPQ+uhcO4gNZzMHbEuCcUGWXp8d2l+UiT2SvjzJ3TuTitl2CWp1HCAv1QPqbOy7azs
Xpe0mlUXa9bA0sYHNdOPDpI2z26P//wT+3WdfLeU7y75Ziffz+tFAwq1XgLepnBXd/vy72t90cha
KjYEzanXuWSqOV6H7neIt9Ug3igR/Pq+xmhiM531tJS9tKpclhDg8cYoCIoReV6bACRt1LeZvmUS
0K3kkZBZEq4ZhEREkDoPYK9pkI5osDL+fxk5zLZ2fGWaydmcljvgbM7qbM6b+2yOAjiCJXYRpwGL
o935KjRlrwsoAiCb3j83VEkN6WbF4luDVancPt4yMO2UxoKnIOH0vok00TcESsA8woAbEcpo2Hxw
XUr8lhxcH1A8bcHlwXTU0k5HrUZHrUH2rdZ8e3+NShU18D8GzwFciELKMn0T7+siCMVF4M074DTN
ajQNReBvyRvSzMX0qFotViFYgSvYK5Bq5oSZ/WtqSJFhptohP329umZJNplg9I9qVeE3QRikd5Qt
yPNrs3yCtmJnGC3QwTOzuHBdLRrojLGcW2gkvAkRYecsq0kZac8ijxbx9v0GtbzOVTFGpasmxC0j
1QIOooAmuYV+XLfHCoMa2pfCyVDRV/H149EZuV7Er8/RGV2MvzN9qzN9Oz3YvkUDAjI5ElDVU58k
0gvQUZ83PlJeADlpH0zJQeQ5gos6CNEcv+BhiHBZT6h58opZSHFi+xjtnrMsvAiiG5lF/ivnNNRQ
p8YceMiT9FJEmDkk/As+FO+RpvqmyqDpw1dBO9YG02pmJQITZdXNbLMCA7Eu/ZdEFkSOD5jnB5h/
wECukKIdjppJ4bNzVk4oLZvOH1V2cLZ2NbZ25rnXxjdlUTBTshhG0KCRwSwVbGkXvPRvW3qw7thX
fOza4VmlXyvXs80iDFSxDdavUdaI9BST/BA63gSR4rnRFu5Ez2VKnmc2ObyCWMiBdvsadIc9YqcS
lIgvixyl8B/lzzjonjPtKzbtcO0+g42wNopznCUpy4ebwIsv+KNmaROGJKgm1s6o2GVUFgtGFmXg
31Mmh8d3uLdgz1TpnmyCyWeCj+H5UFZ+GuXf6rrZetvDPpVzhpz8Uaqesv+keZZUBAzEXc1i6PyL
2i0e8zuagZLXOO8Bbzq1a/exa+fXoJHMzFTmxc42z2+gN9/XTUFHf8W56W4H3A64HXA7sJbh+kLs
g5pVGFas8MIHhjEfV943poia9uFWetznQfyQoVZrNNFSEyk7Ug+6wW7wlAx8/oZ0feH9f/g+ASgh
YV+8VN6ApP9wk+32dvZrsQH7nSrgbP8P7RA7Oi1rKarmSFrDOT/mxJx5cXf2SbPB/XMMwYgjkW6d
Aq2R6loHOSV2Kf7MoJ9ovnuiv0vfHU/iIFT6yt1yLQvRUTM7OXdy/qRy3mCbGKN2kZ2dhzCz/h0Y
kAMP5Z87VnSTl9Cexwi+O/TVHPpMkdeAspgbU4NzqQYGrRWnKAGOHFGHzeUGTWobQikzw9lssjAN
r+H57QkFAdAiQSN6Dj/mU+AmAaEV31VLwrBUtKwUVu3sOjoaTuOuWOPmVEc5tsIXA8CiVZejmq8a
ienCYefNyOrz7tw1F9sufIV2eA0Ky0yFy31f3dE2K7BI5Q7YMnHLOzfRgsFG/JY6Fgg4m89H1tbv
1K4Tv+fBzMpIu3gNqsMiwSMQcLNzg1HjMZPqMwWeXVu+kzu75K70WR2nylJae3edrbjOKkm2uzRJ
hkLwbeBjyq7gkWIw9WSUxjJUAd3V2VYQDUSMBlanxZzzHgTvNk6el1Ib10/G48WeL+vdCPQgABwb
oiMc0Fj46wkJIYhNF8lYVFLTiZ8TvxWI34THaeBlIX8QfEP4IQOd+P4mCVWNvQi1YCLgKhvfSmKV
SSxu8ZYTNSdqKxA1hIzazbPewonvE5lkMdiJcjqN5e3dlKMK5RA0G9ToFKT6iBwXX1gRX8zqsW1u
sJlZ4liEoNTSwxzrRXAiw8ALAM4sHUyq0tWMYd4Eo2NTO4rdz0b/gLG75AXsMHEaKBDiMFcESwYQ
+i3dw/eHu8fHavafolg/FQOOBkhiWi/eWS9Kw8pBdpjvXBykokOsciKutAOyv7cgIgWxfGWRHUbc
7uzOGfcNWqSmwHGFF9fYYfSokQfZgCT7dP2VxXOs6NJ9WCrSH45f71VE+iImaa69WJHzAsBQDFm4
qHy4IvqBIkYNxQCq4XU+XRl+QN4UXLlurYeIvj7qoBxHx1GymOjxEj33o9RscJKof5O/sJ5bHr4r
hthNj5K/TkiHV17D5tkXV6jE6R4Sp9p9qE7Z2O8wcPMgt1BK3IsLcKl0//Heh9OdDWPUQIOIaHuw
TDfstx5OOLuQC3tRkxxNnNpv0BPf4elRA4PjGTGx8pTPhpEMpaINHMUyG47AHUiQ9NzjUpAYREcc
/02nkoX8TsTw1ACcijw+SZB0UcgawBeQIUS6kHy36u8+asDasBf4Iy/ZSHAwT6qoCvD4qYy/sTSL
IhEW72yDZVYm+d/W/iJVAYZCVTCBIRBsAi4VJEwA6sJDeDyjn8GjkMIsIrsJT0flE4ohmoGKUWio
knpC4PG3dfkp785Sffo+F4ZSPvILsN877O0db5QvVvWppn4fpU/3OwzMKUR5Vc5mOwU7NxX7rUfK
LJdMy8TwQo0CYoOYD6nxIxckD4lApNxvBXhWkJsQsHK43RgnRjIpotsglhF9mk2J5Wv2wxC+crKQ
Eoc8cQ9qliQRY8WZfiNQowB/loj8giNUcfVenTEZKVHxRqAP3WbnKQsS9AEmkkEcITKRBGUzSEVH
mF50fnF7OGMcpUeVEbDqeN5yEXiOGwwNgOTh77DkLknFONn+v/+ng2gVcdoyKTo4fH+cW6CCe2Td
CNVXGzxc49hmEyGu/v7l68dTNgZ2chz8NT9hdU1/oxs5T7sjfV03u47Jvb0fAClNj5OA674rBKCD
g1B3bktHttEJmGXD8IV2eA35JDMTYup68rDNAgys+zS4sAkaseG0UJF1xuJcKTGzZCSzEIpWgGw0
uhV3tYTgUofFadXpEU+85y+ZNJxxRfzaXF4zpS9YM9Qk+S2V4EXPpWnx9D55+TxLRxKZlI+v9w56
6hX8sKD0ws7+Vu9wq7d/vQNPtZJDK52aSkKlfOnpnde6ibjPPW82G7XbGpfPX1lSe8v3CAP3wNOr
8VbkMxcRZqEz+a0MfIbJViJWbZZh0f1DJ48YlqJCFCJeCKV31SeUyzt7a0a7n4j4NvDgFmUYZxJI
1ALgEYF1v/Yyy71qbdPuDSyb9fTPrl+YWn1o3gHXVrViP/EYKK/rYt4Eoskpj1UsiQAyzxnd8ASx
Y4lYyWioSAromG4lnHtiV7WcPBVNf1kVIFC3J+rKbRZgT4AAGMAd5WQgeMhbgjEAmADUhRKgXj2Y
L0rD0rBpbdFO7JzYIdP++Xn6qcp8oA6UatAcBgpef5Gk4QvaFRGVy5gKFrP1KWvnBM2+omklALfZ
vt2sGR6zcCthz5RXialmWxTF5Z5lYcxh6mb2D53DTvpMlb5HzRa02+9MUM+zVTQdaXcNBeR8Z7t8
5/fw3r4MUB3J4gQTdhKJ6cNXZ5TX2x5ub7LPx9cvGQ1+KKB08yDKmRJTTUkDlEnz4qxOVMzCd+0O
2hMxNdS5CpGbrY6SE0lKSJQyhJpDV15qS3dK1y6la7e/Jm3tHW2QOxS07pSN476cgNd9Pg/6RhDp
EiCgLzRxW6Jp6nT85pCA92HIWz29iamlTdQfx0FKKDltDU7hOYX3fBnaNBjr12+JAjC0Xb5B5QVE
so5eDnIxuOcJqL3Sx0heUuWyCm+kIqWTPsu9/c9frgG7wKmD/ScndsV8YG/EJjEHKAOlMB3B01HB
/mzARQXo7hpGCT41wMkBNkRQqjCICDiV9ynRN5dZiBeAsJJFr2y9r2y/S69mDsFaVR8E7l1N0CpX
oUs3ZqUzqz3G6onRxW1aTve7tGNW4HLGLHK5xdnXcRE4ZpwrPXPleFt3Px4e7Rya2Gz7lVA8aPsC
kWvenyVCNaekbjwXln7QoeewipE0/NDLpKFqwlm6CUvNzC/VU790BxyuzzQEuuob3l9KuEie1RjQ
PXRm3jE0kWXjSc6gHrGRnLLL8/c6ssOduF2x64tLgOIIQnY+py5k7znAzy9VM+4ZDpi9QKNwifGs
fK6u9Fyrl+kmq1IlKc8Y8dJETqh9mxqf2cWMQi+8Uz3f80ZAXwJSiCZQd+w1J96cdOhy97Ry6rqj
2pDpMbPHiKyQdvUant7ATG/DsSyaVNAbp9KTIfqu0TU9FmgaiYJknDDQGBCrgrZ+Z2rtMrXa4TVc
XjNF7yYLQr/N49sje6i5EDMIkamalRx03VgG7IAVikVFbQdLozZ0hKcxGPInIO5AYtwX4A/xQRZi
VBrcgHN2JtSKmz5zYFXfIap3zeS8RXuvBF4cEQ1ydEP0JkLHuyxFvfRgU9RiOaRosHa+06wIMDcz
KkQpOJ900l5t9U7l2qVy7RY9ogJM9caghsjLwNBlSe8hwpZ5Qq6giCPBcyJmcU7ObhGbgg8Qk0jW
DzbLErQZeiPFeYhMXCRp8ANS4IimQgmuLSJ6cdBN2HMneqthFOtnCpJBDBCa/rfHwjUkxudOJdju
YpAixpmXYjaLS1/osuZ8abt8aWpHvCZTEvyZwZAoiCoHT9LFxytFrB0JkNQA+V20I/qotupm1R24
XQdut2cHPvQwA6+QpcbFda/XXLOO2uNnw97ty/e7HXA74HZgLdk2gbSRgw8xsdamdxN0mNR7XBc+
QD1wZsIz3svM4z4PdF9xSRSo1mhionOTgemch3p8t2QBdvUhkveH/3z4PglAe8C+eKm8gXd/uMmI
GDp/c/6/v1/woWAHf2jeVkeTvZaianyh8jEn5syLu7NPSubcP6e+WPRsbZ2CsDmd6xv6ihj1Ludj
BBP9XfrueBIHodJX7pZree6OmtnJuZPzJ5XzhlQ6YwomeLgUJoi5BujhAtNmPp2AKl1quDlmYaqh
YkF0K8PbWgKo48V3x76aY5+p8jpWDr0F6PlBHw8jFtW8hskSDmY8NdPR4g6RPWTUb2DpNEtlTxTh
8pWPy1c6TbMaTaMMzOulBoa6h4sqwgJmt5y6mmshTWZXbGLmrA0HrUcEHx7t9hRrgzncIsbHzTMT
ZTPveh0BZI+9afAYlStwflHYUvbiRpRTlDHSB/+fw5+I9WI2lPClnrhbKr6nJwdnB4oEJU4C/7Iy
E7l4h3qnf8o014r4dhiRbJj4rngPDajVVdlzDloPhJ7pYdWKb0w/PsiRDmYTs05Ah58EAxrXg4Fx
1QRM3QoqLp2lV6HIJ5RD9yri5DINzhFcoSP4ptERvIdGhmDtAP0NIBN1EXCkIsYosQaHYS3cuEBv
ELTeiwP1KZqAbyQgwooGlQ2DWxHN83wTGQbeHfCI5xGTCnQ4xUCrZNOJn5bltwtuqB1ewxU2E8Lg
aS5Rm3UYCGNo0I8xGEzzpOuS0EkRveTCuKUtu6PX53ye1fg8M+OnHZ5VsncDtjd7Mb6MgZwOrVhJ
yiMPM350TcKoR5KmxOVT5FAfSIA0knpDthM1Z+aeZxrq2iUL0Z8l43Gex/B4HAd5WySHzHkCHqfP
Jtz7BpEre10OttJsEupEbk7+nPw9j/zpxqGNyTbQzexvUmhHpsyLAwBKtzi4WWH58KIfqyiPWDhc
NgWVOGgWF84FwbuNE0xADJ5vpoyIhhjdIOK160z2ZITqFXFLIXOfbGIIuCLG9uT4JohyM0jJFCEH
LUpiLoffvAMunl1xPFtSrSUyBEE4ylRXf//y9eMpDVSS47H0iV2tZkArhdd9muWCoS0jicEuH1/v
HfTUK/RTmO6C7oet3uFWb/8aoy52D+bTLspyFobB9CplYaXDocrPZJQCm7gatoXl2Z1bDr2aIrwc
6LsBy6OKd9Mj2i4Uyy95NBQq+YYFBP67jYODYqCNMfn9PgcEMEYTSpSNqVGlFibrS4FjVF/IA6d3
ld6FGM50hMlcZJDyXRE0sQmBO+1Faa3nf6h8V/tL9DH14VWWhip3vcP8oeKuO4wQdIB+4ms/1nct
Qo/lOhADBFBMajYGHSZb2WIM+iCC0hY81/e+CEt11WHa1ZKFnwroSePsIJZ3Lb6n/TsGowbbp7ah
fFGpcKWb8QrZtYqa7DAAa8lmXBq4FQ06a7PJE5hvxmGHkVh7Oa5UeQlVC3twsHO4e7xhjPewXDcE
EXGIUGfJTZbm827VJINNdqBv05KSSb0lm5q1FXiQ7oJpy+8v5jWbljTPKZm8oOXnyUaCI/5lqmiU
K37ogM1Zmjf4C6gDKihV3oO6QAci5rEqO6E+jri5QX1WhKQD+HqvMhHR5E3tU7wgs4SBn3qcpSpj
8PBGdICx2q0t7gmjKveiAxjUmnuBSBnzKHgKkwpF2cK5OHxciG22c6GSZw1OBTytxcDv+dDlK0xC
0Mpp+u2P7UChFi9qjtRPgdybuikuv2hUsmwGlsEXxIVI2MOYvAmgFWPhZ56owzdCKb9tZRNGQ+o3
MRALM03cGCzIv8VVLboEmsuzxE02l2tJYvzpGE5umxXM/XzDgzSisWYJue5IY9PXerIqH5PFXojt
4bYDCDvZW5FN6fPhkOb5UDXKUvHrvyzLaArBMaH5XAiVi6kpJwUIWsTK/02Vp9fk7zW7NsU7pHOc
c7cuO6BqXoXdxz8GVkJh1hUTwNulDWBJpi57iUuqWRhNnJeGN83X3SEFVowU0A7PKmfO4xN+E4RB
Wq/mNKzCHoeOUBqxSrsjtCKPrs4CxE5GHCk17eyc4FmhZSmAUv/RDq/hyprZ7lVYA2vbThpqIxVC
LWJW9OUYMmaUL1fJoh+0h2jt5RAtU2ArS/XU6eHrs94ZrWmBXyR/56f5w5U97AD92Ts0ih5oxXu4
QgeWVt6YRXdu5oqC+waNmscU4ObB4BzKUZVg1E9fr64ZsYsVo3IYTaC7W/RyVBu8ZieXXnx37KYd
e+njWJwq9uRWKMHxs45eDuOKO3qesfoNUUbOD8arDGFO9Cyu1GiHZ1d8MREeEWy1WYE9Qb2PRSVI
fhsVUThPzoAdsCtvsdBa9On4H5j+QlzkRdsq3LqtWg2Sp5TH0gTauXJ2nTv5dNoBWmVTQoQYYZvH
t8egoNpfzwsn7EWwLbY3ycET8W0ASM5ZFnmqAxBcKtr6nfw5+Xu+nnIeJlK7fg3awx7xAwZgHiOq
aQyQutLsifglTQt2Jg8yVqbr6F8ncs8ncmA7GATDLGc7WC/Zg+krJa2gYc5p+jAPRVEVYekp+la0
RTt754Tv+YQPnD7a7bPe3BEMAXMwJ0SholAXijWBXuX+OIiCBMFfCv4iaiwNQKmQjriTP2f8VlSZ
6Eu06CF5r0Nk1kIIgU3YEhG/CQE9NRuj0IE5YG/P/Pr6zu7O2Znq26tjFPR3VI9W8dJTwBY68BLs
vTVqW6uMAocdGAWKZZgVPvQJL6vZeHiYQJfQU85BJq87cAXsV9qg1VqLiGmlcOH+bu/hRXbp9c6v
pFlnuRy/8P/+438f1VOeeQxrwsHwG4XoaqCxQOqhVuOl6U8zBw5UTmpwaN6zcEcMD2XyPu//B2VY
2e9fDB/goIzC5BvpBUQeRo7fJCYrO8s0KkwqO/fJARwQXWEBXs05ZBMwXNKfKeM24W/re7tUejr0
zu9XmDbMkR46hxnuBSlY3KmUtjHDxE5ykZeVRRaVSJeeeXvkq35BH9YzHbrmzbwO0yDUqxBLb30X
cKdFxz3iCA9JcQyyMGTfIjmFDwvCOsrmyDF4paFXEswzJ0Y5ejEpShiDooShZk5CTQEsBrYF0l/0
ywq9hXTr0vuzNO2jO2zVcXZP57e97gI3NctvW7qHBYXPEshuhdznpzRwVbypDiFF4U2ZAnvWnMIu
LnweGdngL2m2bpwlMHQKFhAgGRuPha8ch0j6mKfy4ursbJN9xn8hxVdnL8lXWCq+2rZ1CBmqvnR5
RYk7oyLfBvOSorb04G686RJZ7C5naTVtN/plzQK5jRe4GZMsGQn/5cN70SEAsftmtLgXXXzminIx
WUr61Jvz8C3o4CZbfgvI8Xl4P7q4y5bchOWRui9SHlBC9OE96eBb23JH+osMrsvCijcdHNB9WwxG
vfd36cK7e43K3TJZIy6XA5qT9bAIdPA+9y1RC/3pKPBGjDo2Ho6v3/wyfuQDIfSDV+XtOvqYlDgo
cpIPb8Cv41jOcruYDABvi3kihlEFoKbIwnhEOcAwPqVI7y70MSykLd+uoSfaoHe10PfhW9XFUd23
JHSrBPw5HWqS5jOE5oUE1c/JsgkNEgFvEieiYVgsX4xRXHh4134Zd7ZFZeRtFz/WEmeuQbYevhgd
HNsCaGBDOm25J7c0F7uKfPbbLl61BfQJe7s7xyfvl1FQFO/QnfnJ+ey3HVzxvdwQmJLPXnoPV7KH
Xbz518biYXZ6XXztXJ5s0GJ724fLFVk1s7/Ta+1nvz46qBT6qyH627PXbw5PNtSmmADQ6J/ylLOL
kEc6FHhZimKn18VXtuf02SXquUEsaIYa42MJAEi9Me1B877T6+Iu5xJulmT0E3JzKWergqilK16q
T5trrD/bJhnRBj0v9O7kEwfbzSDct0ge2p+9Y7VZEXa8IQwpyIx2lpIZoWBLiGwqYyO9hInOfolL
AewtnQoB8Z/qDZBLBd4dummHPqMyqtst6rWObmV4iyQGEmOk3RMOVF/9c3WJXxx/4g7d2ENXmNaX
KiEqMQEtFqHCymZog1InDixLWo6O5r4PfG3CgH0NkdcauIO3uPVXO7yGviEz2VmhiNo8vD2N9qAk
o0AqL9ksVB26qNNC0f60RI4BTrPzIqzoaqZeod3dpa5jjpEs0cxlFY5mtgMCDUYJ18qOlCeuuTMm
QUCT1zOM7Y3ZZzGlVLXgTzo+YBF312AK7bEm5KdX7EmSDzKb8DgNvCzk8ZFmPDuqV2dg3DyPJxXI
xtzELExdpOcjsuXZABfc/nxoBhgaJOLWW/lNdxc73nh33is+b7tp+fxgMBAxQYrWj2k5ESny/oM5
/IV8vEVivsfYGyd9BkjfC+0EGxwkM3MFRJbV5untce8WhA5ETAygYGoOuIjlAF0CCVHzHVP3On2n
Ld8ZPyui6ZmzY7nxE5FcO4oiDsBwqpm9Sk8fXE6eg/TLMsljxM9FW24H3A6spQ8I4ywHH+IYKa70
biLebSQTEYYVJ2rhA+YOHX8vM4/7PIg1XbfET1RrNNDV6m8yqHQe6rWXJQugMzDw+e9Pmnz4PgFA
LWFfvFTeILN6uMl2ezv7mo+Bb36/4KAqOfxDO0TnL1rgLz7mxJx5WUvzYg6LW/+cyFEikW6dxnyQ
6lqHxpBWALSJ/i59dzyJg1DpK3fLtQJhR83s5NzJuQGpxNmwlhdie4gxLqr4H6VbSFRBS2x5oyD0
F159jOS7Uzfg1LUDbHCrK6GPQcaL+1mos7w3PL6BUUH/pR7POIvRcQec7nC6Y45E8hIdnKT6VJO/
kMC55eG7jd3eRgXGhaxOn6MKcyambZSfgdqjIadQFJUSloxkBhQ49YUosl+fVamSSzuvLd6JnwXJ
hMUQTO9ubbB/ZprvVO9Ianh2e6SPe+ARHkuiF1HdGZFA1ZdQFwkqwKo/q6TiTpzt1wG1TvnYp3w0
69EgvGYqnhtCYLR5fHt0zyCI4AyhAhIRipgmYBH0q0CcsDG/I19gXgrXFu+Ezz7hI0dAO0SrBNBH
yctLw7s2K7BHBgEvERw0kPUW3N/IGwAODBNQgsiHU6At20mfk77n7aqJ1szvVn42hE9iMkcoObgP
qMlGJMFQNbHVxdEk6atSjrSm1Ht9VFBDm0LG5QT4eQVY0QIkOU/qbEwW/L1QTrdCcSvCqiOoh5oN
bkJhZJfaot7xwfG+4jisDx4s3ln7huYHd6DgAVOjF9dwU6ZHY+jWa3nJo6FQIR0WHPjvNnZ6rbkv
obRy4jT8aASikncb9Dv33rw9PDx8+2aX0rPln5n98tYUj7NfbhbxVkOWtqDyeYN+7LptSspQLSZP
UuWMsoTm1p1f3O4z0NS+QjoJXx/qUg25zU+oT8ZtkZPAXeB8e2Y3qzXxpW03a5YgvqZWS300dj6u
t5yQ/YkaM6lAUBBH+YJyCHTH6g6Su1pLakgkZznNY+1qteYDtfZqafejwaEwM/Enov/P3pfuRm5k
6b5KQAPcrhqkZKV26d5KWGtbdi1qSUZjxjAaFBmppMUk01ykkn/1a8zrzZPc7wTJFCNJlpJWqTIi
fQy0S1u1FRFn+c72HaTjXX3oquUA9qQdpghQ8ebH8hb0b/muQmUCClYoZ+wHauj6Rj8+uw44hQ76
3Z+bJ5f1Wy/J455fmy8kA6X/PNbJHuV+GIG7UfEkEAqsj28zDix6QL7Y8FE6awbHlS6Y8lLK2KEE
x/0OZNhGrjluDbum4JhYSg5rwZdQeZUyAqOdwJFaETJU0ZdmV9hrdvSac/OLW+s17a7IFeyhMtHE
3B5sjCFBSosg5FV4VyZqta8jxv5nqoTfRFgpVeZQtCOyJnfU5LnZ8K3WZF2YGGUxyvqTvcatKGvu
dWLW6tERUNYHTGj4E1DT1zPdrhNS/nE2043iLRvonGFzrpimBt+71JEru2xU6cSExTXPw3e7oRbR
9GsSbg/Kanma84sSd0HjT6kFCpALepw0qb2vQ0zGXx3xV/eKqyVF0Wl0brd6Z6hu3/i3WZQly9bg
ON2+W+zoracjNbtmtGpXOq/6XfoM+oat8NOrj/3lL2zbbR3O2xdYl2X2L8MBiifIoE/gNlQ/1ruV
9fW/en9HeSn5Fao2JZR4cENlk5JC0tqVFZQb5S2eyKGDUIUus7LIsajwJ1j+QeUX7AkagggBP0Tk
9wHaJTBZujX95DIL8AUsjYvybibFCKLtmex3aA7YNs3SVCwmxmnpMjJs2sZtvN/d3M4X5tHoGw3b
9rdW13dW17eu+9iXmZ/DLBAywF7Q//33/4hjrLeIoyBfk4lQdLotctaR4fAtvVWFuHxbQdroUKPZ
yIM8pQKmrozZWu8f7x+SUM32mBbfUSYvj05fpo0G3IBmEjY6VEaKlzRLlZpjws21XfHp8EOVP0qf
V4LJbtepduPMrA+LYX1QG4Q2n9kg9AkkA06K3UGovhxWeg+jsNfUV1jHMfzuxq4i/OD4oIoLndCV
4g00+60YSifNiLryl8uz452N/f6vyP6ch9iUVi6z6VESaNaT8qsr+21HplV7vJbAxMxWz5JqYZ4T
2NMORk3bvCKKuSP0G7Br/o6ar66yySSKUzGWTqh6lTG66Q/Rn4yWZWq8CiTBiKKMUO60RgiuaXMZ
9c8Z1zN0XAx0XJK8vuMqZKtJYItHtMefZFh9FSitI7Lfoyj2qM0h8hRZgarMg8LoTSIZxdlsce1O
mV+BKoScweba1lqfXALFG9u76zu/zlBoflkbO3oLpmRmf7lgf0n9UzWgJMMEQTdAElHKhKlwAzA8
+kPfVYkXEaMGUWuw4JDbopDbbmONfXfLhZCQpE7z/X1+SElMjE+rGVKQqz5iKU0Ono4LJZQxrdzU
LqCj22Gju2Cja7f6zeZbvwyJLMgbUFiS8xbUevC7eDVGc2xYFmxYjpvQnBvFsQyIMHgGx2lD/exQ
tOU6FpgtLedlM1NndJPI+H7ZpuqB4B7AkqFG6vO0HnsXPcHFsNUuK3NS8S5+uHpDkUrggwoQTYpJ
ogKXYRYqWXcCood2R9K944oK5Jx9y4GTuL7/zdlaxhIUd6GfjPWElfUxC618oEKmSh2gwAJ459Xm
H3OyCf3kbHTtMrp25wpmmf6s1zvSufqYcTpyUswZBxEa+EESjR/CWCIMD7STQZ/u/Nj+WGF/VC/u
VmMv7iQG/TOqQn4IMk8faYVZfRDvo2jCgj+D+ljwrRD8aVZFtZAhL+GjGblcZpeID4f/RYQSii0P
iGtcUk+k/hhdyijfzGbH+dntena78dby8T7UnEtOoPcGM64RxTxOIq7OxNXEj53gbU/cZPqy3gWr
HwAg5s3UhOhGB1KrzX3DJsDNWcjcPAo2tdrFB1o1oyXoMHOmYNZ/tPzy9rR/lkMSQpHB18BjJU0e
zAkbn51EX6ZBzkYD9uwNFEOuf71lIRsdKM8KK4u7qi0LgbFWs8w688VGB9qr4v/chjla2EwV7u02
hnvJ7BiFJ1N0y6rsYyX7X29JKrkmWIIhSriEmRrAjGh1oFyyS7SmrnkWyVEbG4pGgG/Hqxj6xIoQ
r2zDmZ3x1Nw5rpJFq8M2gY0O1EOWipYmHy2IieGe+CgfiP5idBgm9Uqcm+jFOeX/kj/w8w2y9nCQ
tgBxHe7VnMcb7xHOFp3kQfD4FgsUC1fi1KI2VvGGaydX2rQQaKMDJZeJKo7W5vRSYm9tLL0L51Ye
YSzsTglgm5hNvYrNjU/OPHbLnkhv1sEXxWnkT7GVOMpS8vdJkVGl3hEkcIp5XO0e2L8329xW5e9A
+GWi8i+1iqPzVt47oe7eWhCKPZqOQ41RAkTPl4vuYupxxN6vNxcn4OiFXlcmVXo0V8/aHSvo9UVE
1abdmx1o8Fi7j7/tkuQotHUSbTAz19zgdHMEPkt0iQSbkuM5CTG+9lBMpaCy2YWf0CyiS1J2laSG
p38iWO1vn50278DOv/PV0trVS+xCDWjWJWoUh5sdqmsbJrKFNofTm2t7zZSG+uE7JL23dlRpUeWl
q9K3d7q5sX+2or5uLm/YpXSx0TvGVCxwxvvI8cSREyi+uAqvavONGaRzHcoIGxtGVYIXfIkGEKs2
3gBzSprGKakKWtuNBS2kHqMHiktEAAOCMRYyILNTKrp97VCc2chbN2r2df3Jhxec3QsU5vb0rTOm
HuZpWxuQQkrmVdVqqPeZGoymSZxy2mc2wMPfUuc3xpkMuAtbLz+yFbOrK5GaUQnuPFmrcoXsJI7u
sTNFUYUE2MvuguAQM09hFES3PultLf1SjzzYfZnmvirlDZsLHBDONHKjQB9Bsz79+Uau3a71oIF3
UmAdPNU1KlACBD1vZz1iF5372imTBeIMcjMUTLK7scvdECtci7sB8TrJO2HB2XrfS4SeqWMWTB1D
Hkd7wBYrbWYbjZ8mMtBJ0Vp+fwOLbBydzDRHsruwy10Q7VTFXYDeeew80picizUtCE7Q1UNzOs+v
cuwCk9hjsMf4k/vSkf4aFC0M87g8dhnlKsKW7YP2RRgcY/EN8A3wDSwliEDWLRqexjHK++njBMtS
k4kMgkrgVvuB29gZV75vzrTv4CjKXMdzfD2L3RDbqTOa6Kl7QqYg8dYrUA0HoDcw8Pdv7ksp89On
nzF4jyrDJzeNboDGdnqCNvOW3y7//IWa+sXurxra4ijPgijvJS/G7mUp3YtB3uEc60LjUKarJzG2
ppfWJv+TWN0vn5ZtJ/p36bPDSYzFVGSvWMq14eSOlpn1nPV8wbkooiY+kq5TVGOpOjWJsLMIQ+X5
rsdid9FsIbraCd1lTDrvyqw3eR1uH27tmN5Ei2V7mTuijKz8jHXL1DxC9GWiaKH19DoQjEHRz1W9
rC4Dp9vNHccFiYk5TWIgNIzi8WwnYPP5u8zc2S0ss76xLgxbXUaU1luEwYr2SMIU5RINRDshLbGc
4346DKpsVmYTqu35xikLzfKmWM6uOkPLqd6yIXQ6+avb20ZV2uowgbK52SI9htndQa0BqNAag7Bz
T/UsiTnan7c6zNZsbtnxQi1pDRd8NKhbejHWGuCjx3m0u8PwzeauHbcz8CmwGkuPeOXnMHAdBlos
FxAy+ck8UtFhZMAWqWjWmTf+mlyb50a64Os9O/Sk+UZCLBImpPA0B6+QQvJ2nlvqAqyttrWKM38O
29IBaW+1zN6YNts4wAZT6o0JwaM3s/aqESJtdwHYVgsFbU94Xia2uwBqW6LPWeLXZknoApbtloQ5
xKALLrVEDJo9CqKHOcbwWrwwBIn76ozJMjU/8GxxQhP+hwM3GhPfjuLiuEqpBR9JOe/dSn+7YOPw
ZDD9UhcwXo+nT2TwbmV93bB8A853jWTl4OqHTz+/PxEfP13rYZoaR9AgF91g+bfoY0Te+VdIEqr3
iZr79OqK26TOiSdajnpu4Sp9RF65IEY8Lt5GDtHnilFZokeh/15OolD+l8rv6v+p/PcyqQxsVi96
JeO83SGg2srDbMVTY2pvYoFJS0k7kUMHu0RI9SpotSB7TCYODajjZ1HllDF+qGzIfLeykWdfaQdj
S3dm9RI7xGCGXaI2kL/dIUoqzqEcgOFeAKQFG9v/++//OdAxsEn2wblRWtXC2XdNDAFRkKU+QmCy
gmluC9W/ixRoVRy7xHaVlIAxzzhIRlEWeM+fdKdDBGeRwIqS33eOG+gQs20Z+dY0zIyAHaI9x2k7
xGk2vXed5b+u1TsdwjIjX7oFos8VoO90qAbY9PBDxyd+fpDmEP/WHArQIQoxUggGq3McsjsmNQuG
DOCpA/+PeXKQO12go4n2u0Wr20vXa4LgzJPVF9Nd0qIoEwYReOxBYu/6CQGenDuJQtG8SjRnhnun
C5itZLjNQUEd09k7tsO+FlFC7vomStFYBZBwL7+jlJ2HEvIXJOx5E7PbBTiaKBwtdzXHybsAxkpd
3Ri16HJyhEr1HO1CUgS73ZEr51nytp6ziCjRF0ElReLDPDsFba3pBqDYtrbTSE6ZyIkTo+kGDQSr
GGlz/aHvopU58MHrBihyr5AGcoE1dFo3H0VbfkOGkdvVF9yurnm/lllAVefJudYN6hrEPgtIp57x
ajmAPcOMDmkaTPcwjsaK2QoILgOyHwHAIbF+S4RXSMHfybTWz8pqZ765nRZX39ird37oBhktWpnn
CPZoXmX7bxlGJ/XNFF2U7K85jKZX7f8qLp82lJzBZtf7InY75KCLrTm4tC+uAab/EH5GtV3sdsjy
VpfyFA+jv5b5BvS1tgPTlarS4HMKrl/YX028p1LXIae+BFI3dduzPKNq5OjPLw5mqXt2s6hm6zoU
OZZJ6iiPP+1l+PDz1fW02D2WTphQp3KnZbYsdt3ErkO9aZnErk6SOR2m/FNrVFnsuoldh2LcMold
uadUvHy1J0tcN4nrUA1dJonD7sx6pF9GdE9RQfmV2T2UiPBU3WlBeyhNbSvWk/5/7bipnhbY61JN
z5kqEHzV0gJ7G7nslbJZBmh7XUrWdSIM/bUsSQvsoYxVD9AK/u9YOu7IIRKeLKE8+vnF/RatbvwO
fWT4eGdNy2aiilne6JP+f0G/9fv6q2YFIIw4upOlowiTAe93N7fXVXbKQ50G4wFgN1td31ld37ru
7x5s2S9006wANWc5Huh6/CRFxRQdN8KLxo4fCkxK+emjUDEbyByU/CFa8+QQQxIkfix1WewX3OnK
iSZ/QIQ6oZa9DgnWZZI6SRxRLrGLoSRP+9UefHR8xVi8FnsqJ0BpA8fzQIqKeqIz9gPsY0NfWI1F
gy1dd5nrkHVfJpkDqR1GFEcgpPHD++iOHGk9S/DKrpTLaioNqqZCK7N6S9lJU5qmKaztUHdYJr2j
pZuHNXArjkcEMqYbbsYgmqTJiKFCtwwtXg4tOhQclkncCNkWyEEmPRUfVT9HyOSIsf+ZJE21mZfB
FIvcy0WuQ7Fh2USO4vAnOWMYEXWUpsbWfU7DPeVypjCiQ2llmZSMlql+ALeDP0EerJ4qK2bJZlNl
iCPZsHdUxQaZ61BcWSaZIyyROOD0Pr8obTuk8BTZ2GJ5L7ZW10XRr7U3l6EA52ORSaWkP6y9tiqh
LnL73WsMKtUPM0nRpZ7UNr8IQJI2/SdDqeTGv82iLEHeC5s/kYkd+pS9oCxZPWnxIgt3+YpxeIWk
ZL9LUSdn7zZlIK5BOP+ixQKS0PNSHOOuIHdvb3f7WHmSuoYWalsVxuLHSXe/CoGTAbVmjX1pv0vu
v8Jnb7gx21zbF++RyMek3axrFFfZZBKBdq+yUKiZ36iMBkrHOdu2gAo0ty081+5dVaalzLCaM9DX
MqRezKjuN86oOkEQPQjUwQR2Fno0KOfJSRA9EkUlShQiUEo069v50Q23f1MUhw+0x2uZ7zRzQBVL
fGIHHQEZRjhRhJ3nIAaOyw161KdAs6ixhKIRW7j8jEaHHEizgjVGYhZY1amOzSOXZioYOPBGYRRE
t+h+mOcUBmpXi9NTfE1Ix4VROp31wB6HJx4G15k4NyDMSnH0nnb2EvZ9oVuNQU3RcYSIScJCHya+
827luJJuxzdGh2Hi177qJvqXFIJu61kC6WjL+06Vz2b/Rqv7NNFr8c72qB32ENbirbzGrrYQTWKJ
PWOKX63eucegkkHl69uTAZh3XDT02Uu/MED2nxpm9YHGSnPsQxTfUezmFE20molh72YSBfcyezeC
YJroWe/dij4xsHqlKIlgHcS0XSyaOL9ncjpw1xO0SI1h5Wx9jaM6mu94ZcQ8KMc+l0v5VETnReDj
nSOiq1WFuoDLr90fXS1Adml7z3d+mVKAbAQOejWtGhYvfeGsSyN1ZXub4Rh/c62/rmeM8e7FXgAg
52h4GtNGpfRxgoE0UO0FQSWzVRX0Do2/2/VJtktanrN/tru3c7xizI0N/hFdaTb1uauZxu3Vi+nS
nmqP3MxfTeW0WsFtuziK4S+l1YgfbHO9sVZYCTEVfa2HKU1/qFalpeLq/WEi3hTJn1kt6eJ9uUi8
4Hzqe3mPDYSHt7GUVAXm7HitTdCmMOaXc51euiEIn3Xj5hxvcLJ2E2Wu4zm+vqem7RRTj2vQGVaL
7dD+PSbZVzXib3wyxC6eX99qBrPhcGjOGFeAlkGnQzLyPJzn1y+epjGM0EcsqmEEe4MFe4N5ntZM
yaQ0ne9mgfOs6SDtMtFyvCiB+LWzGAZ0rrLtsKt2QUPX9UrVU8vhU/QQEOZUXLCJjO99tzYvxRGE
MWmQ52tW1Jxhr99Io3l+dwP9RcvDIGwvwnVPNfo+aR24loa0kwYtltIZI3yXa7dctbI63LNb9RAp
DTFyFuvmvyUeskcDjwMnScAvBbaHsjvq2fUlBgflx9HV8+2i6vc38IkGb+tMpV3ABcNqDskXHJIT
CUEdVley86oBDD5/ImP0qdC8LnWDaaiGQym7Qql5/Pqsy4AE6PVac7OIJ6gjUeSnyWiD3zfVq7RA
74LE9JfLs+ONrd3tX/W2lIbzVTJRHTWU/RLfAN8A38BSorOaJ7PY1R1ZX9DsCZkKJ+jizOwBW6ef
Jz5mjcUnN41uMOW20xPEu074q/rPLxfOrRR7v2qApaPLXkpVNac03YLJXvJi7F5YZl81+B+ch6mM
Q5muniA3n1YtDlZznB1X2ywT/bv02eEk9gNlr1jKNWq3jpaZ9Zz1/FX1vMU3VTT6eDbJd/XDp5/f
n0zJDEAnItKHSIwjD2gl34fiYerzJYrPj77gR6f3V8mi/b3NmWQRW7CON8DCvBhhVgMEfQwQnB5/
xDKd1bET05qTXr71JJa/Z4ivvN50pROKFGBFGoNY1HHdKPZmB/P52e0Jnsl+aQ6oJcVtZsPosjX+
kCfZWd9aZ08y09LDJsUkkzLYAtSl2PbEd27DKPET8X+c8eT/ius4yrBvMhlFUfpCr8ABHcOhxcCh
6xHkOZGuYr0KQPuIzYJE3oMUOtrBCjik5uxUcyZ9r0EXNKfK5ssk89Uays+YL2rCdaWH5kbxBuzl
UQrES5SgSPOhzADitBUlF1GQkaiscJcaO+2ZG7BC6k/OD//+L4oBKQS8rtGU5cMf2KKqOmILWwhO
wEx1x0ID2NJpiWsr3pzCvso/2hNaFQEWw0c5MezjPOcwsMO5xSEBbdSXtog3iqiMIIl2WoYYNipe
OVxwloU53lScWcAd91jfU+JONV73JnkrfBD866zP/Oo2vrqmuFaZ2+m4jzfPGewxtchnM3yHKhHR
EdmU8k8aYWX6JwPonzCPll7K0EP46VEj2xHC0DtFNNjOtz4F9huNwP7jp2tkMzBuEoXqX7St8Dmt
nu3iNKd3bFCs8KQFAc/iQMuGEmbKHOz02enH/jfb5zDIA//nTENlEMaC53kYSURQtNS9BsGR/c0m
agFQnIUhyhh623RH7eM6BtcxFlPHmLr/zUb3n+f15tFqU2v/4LJU5Uc9EdIST9kTi8AuCefe8YMi
qYWqk/ZKHQ0Qq99i1K+SXqUPtSdskVEzFU0fQ2/51e1Rr5q/V9uO2Mdz8K/fgAUgVoipj99q9PFJ
sTiZXAo6NRHt57u8bmT6ICUzTMCVaikvK958xrE027NygSladFPaEYwE54OjWnXFxEn1HXYMKGx8
d3sBxTCiFdZyyUoIN49IJkwc9w59YmMndcHgc4sqrQOi/bNjhhe6oWWTY4XJmcKL7UZ4wSkEvKKJ
S0E4hdC2n5gMT1HOs4yel1MIfn039Ssv5mtpzErkLfV/Uzt4Q/1A5ROKfZL4fpLdoHVcQ2vs/azw
fjOBlvaELWkwMzN4Mwnklt/dnhRekjPOi2HRNUeNcsDZNzKICHNH+byG43vCHTl+yOCbwbd+A1aY
nyn43mkE39XcXhZitbjv+jShgjkVHxTxKtGnmSz2OlY8O3sdQ4OqxL8NHaw8weCXI8bSCeF21HJj
f/ioPM7FyUWiOBOwGiUWSTTWC9Osf6x/37JtC1KIXZCaC7Ae+UWum8XiDaoZQn7GyHkge6SMTlBC
QUq6FvBQOzkrHyvft1S+Uh41IbRe/bAVO3VCV/KsBLSpnJEo/+RZCQyLqFvBHyZmxSvtEruNIdXT
nrsgclE0L/oLsZPyiQpAd6jsVtitfEu3gsEVl6L75XIrCKOk445qrficuGMvo98AW5tvaW3+s+Om
cAte52nFdC+vEhTsPTm55ZTrZOzcSZElnMCxX/2s7r1ftsrdF3B1scsWI8m3tQ3wDLMtMK0zhQv1
6Tw41cyauTuS7p0e7FmfvskSSo9enYmbzA/SVayYbIxw31K3uPZyrH+sf8dR9i2xJ1FqFtKJgexJ
Fk8iLGTWI8IvK2RHoeVBbZ4UXcyk6LTRY++ZrKSbJWk09v9AlwfXuFbAfgMV19LwNlppzdG2WDQz
IdITeJjnDAa2Fw50d8IOg2+Ab4BvgG+Ab6DjDSwldOYdzgcG8RvyDmds2lM7nPd5h7N1YY8WIXQ0
rpyZWUr3YpBt5R3OT2yio8MwqQ/ausm7lWoGWFEPPzdkzXre8QZYzxeTgZ0pXWrOyqqUHDp2zmZq
dy2/v4HpuJZp++mgB7FaYM5RbdsS2DGYBR5mfoWDjYOYxNIejfXOxlS41a06tzKUsZPqLWPWK58j
UpmkJa8VRh+x/BkTV3klSsZ/S9RCRPwIq5/1lSir1e9hpHsA6zVv7DyKkXMvRQT+mPiear6YKC4L
v8KTINz31JQ/V7H0dAg7f5Oc/2Aby6LPDz8eiuMIkSU22Cih1VvrOj4ZZ4Q4UlxMpKiWQ3uRmykC
MC/Ckj4QrpRbocG6CxbQfJPfMI7GSu7ZPLN51m/AKPO8A/N8JUGrgL1ZbKIP7p3g3crGelN3WUcn
xSZ6MSb6CDRwD8LB1vbAT4gRq8DNuYivKhJ8fDWWv2d+LMmOKyIfZJJSTH2Fwg85mQQLVdIaWMOW
qmUgWsI/MxspHdeNslBPobQcwJ60LTasYb5EEmtWzoQua/PdQlGlKsqeIq0LX0QIS3tKNrsm4YWW
JL3N7MRga0v8KNSEznr1m4YmbkRsdFQ7UWvF6aSkcfByMh46rhpz9ojJToYY+3L1/DXrHuteepj4
jl79Fw8HX6FN4OEgHUwUb6nULb71ykcQUqncMfY2JyBsoaJJ6NUc4Mw8W0dt4ywYh1iLCbGuTo//
dXn6j//oNw6sKT/jySeO1EmsuCgpO6Y52Y7yzq/9mq/9ZzbMV/tmtJdtseBmhl8+AR+sbFo6DBhI
5y6PvcCO/1D2y4DWxstJjLGiKiXkd5vJRPfArJlW4L5l0T+EIqDWnseC2JP/kOGtH0oZkwJOYioK
uSgWvZFrt2s9EWIBZxTfQfkAgKPbx552dtY+1r5YfJQPKwi0XnnF0aCJSaDFfdujfHDpsZOkcYbt
pygETNVMkMtLRBSq6EyG1Duq76Fk3WPd+2a6N5ZYUBT6yVhHX9arHzAlgsBUummeZ4Rznzau6aqZ
sOezsNS2HLhTpq4Gu+xRu8EaM/DDTVVL1Oy3rfPbsCLX1ZGeDz9fXWNd5mQSxVihXS5YKh0JVbBA
CqdpLD+6jY+uPWGL0TUzU+hFY+yTnOf3tydUUuvMMD2BITrnFqfDtI+TpthjX2zVzPOGSCVSkVg7
Omsfa9+3pASFB9Dkr8V02KN6np+o7oxH2iR9VSy1PZsutS3SEwihMHHHrg/mRkN8rHzfUvmsdn1M
9DijO+y6bbQe5yEGsWMUkmhBAvaXFMUjJLU9qjLlIZOKotDMXgRSnN6eEX0bH34e2GNmxDQTMlgP
2Zz7yEcghFyE/AxGeiouAbsVuYnVErE1OEu2uKx43xKvlc5hHtNhT8T0xg/dIFPejnQukWmpfkUZ
WzQu3mXlY+X7lsqHqi4SaculelM8KR78FG0Uyunljk71ts9mZ1jnWOe+qc5FcSyTSRSSd1gu1aun
BtMROnpvMOiMsC8fNeFdlVC3akGYte+bap/NHm/A3RQzysPO2wrzUc5hbTTOYT3XSrGqeUl+ciue
fEla7xo6r63PDZbBUNlFAS4wjF95lKHwZOg7wWo0XC3zFBgHZvWzG7Bp79civYZm5UdyuGR0M1Cy
UrWKGSs/COStn/qY7ERrk4vpK8XzxHkKeHpWPCdx/fqaCx62Omhb6kFsHW+L1kCmtNQ1iLGzddgZ
OBqbMlDFdcaTQPbQYYe5+LhcK0GcruihAMU2aJIwLV96D83l86vb+OraE1qF2twoDDFS59+DqXWe
U9hT1i2QWyJG8rsEdV3P98K/pWhhuknc2IcizrSRsObZqHlv5hFaMwOmadvBPEewR+88EOBiRnfq
3nKq3Kuz5C0cIqhhoIqxn9whg6Gdm9XPRvXTntAqx5cTii1dWbclQVFyw6CaHWUg5GSSQGhbtbLL
5scK81MWpzYbi1MfP10XHLQSPbTUUiSeM1DJRAaBmfjg/CKRz5IJqN/fHnDwy+XZ8dbmev9Xga5L
7W1YAa1QwOUoFT5NvGgy2AJg7FGv507D1k5bOP3VKKdbCOyJD/1W7cBxRxLD79wS9DLUxeTUfAN8
A3wDS0najYRENDyNYzil9HEi363MOuvaD6CSNDYzdDmKMheLZP14LkBiIL4a9ATGwJxAL0pbjw8L
9H76eYIkbSI+uWl0gwLlTk9srPe3qtgeH/9y4dxK0V//VXtEjtMsiNNe8mLsXpbSvcSD/1eAb/xx
FhFj8cPBYhqWzmlNFDLSqyexM0x1qwNKInFZ3aKofxufHU5iP1D2iqX8JSls1nPW89fc/ZIOdrF5
EfvZU3RbZGkU67PLHXEESytL66tKa0sKL6eTHUYB9v8SHxJmL9Ar5WVOkAj0TuWyjW6+VH5Gb0O+
oK1c5X7ADuolDooFfjECD4z1A2bAHzPx3n+JBPP7Le79MudB+uIaqyBC2gXkI9g/jrAj6H3q6SmN
jm6Y33Rhb6qpYkMmajZdaFDAd4SOd9/R6/1tJzAwGdgMDXo295a8h4G/dZ7nNLGsvQTkx0Bkrj6G
yCbOgoylSvNcjWT4B/4ntvt7/Y19XuOj9yja8ozHYPJyNHfVUQU52GecxTjrwE3eae1K31EK/0uj
tKcfHP/ZjaemuvTBgRipsHMt8PMPvh+pMGbNjcZsTTiTot2ALb7wR38s/p75IO+MmZvFUjhDG1XE
1WOSynHSE+ehyykUO1/y56tDdiSaGe0IzBmWviYsDbBd+lKGHoaXPOq9Ooqlc6dAX9qcgsp7IzSR
bkurmdknaDtg/e02d+3fu+QjGKiSKLJ90W7AFqB64WSB+Efmh3qanh2ELQ94zDD1D7Q03jvBu5WN
9RX4zVljZMtLMkydfTm2QrbI7imWGQcHWCmXBb8zKmoxRCzOJonzYA99qofuXRg9BNK7lWOJ5ngt
qOr4Xly+4jzBa+YJ2rMBHxzwg2OPS0iL1iPx05r4e+w89sTHNXHt3DmPTk/8sGZz38pPfoq5Qk05
2zIeBjYSYaoQ1/9T9Bv4o3viZE2cREEShdznoCcNTHIOrYm3o+f1yNz53H/G/u0o1eWuQY/oAAaq
UcubYPuB+HFN/OAEE4yXiSGYeEE26Mfo0x8rn/6isg07dXbqr+rUB/uAoZdyiOx/CII+zccxAO14
Ayyrry2rfU1AW5yHmVUn6NnHKMYKD/9eznMKe1wgmw/OuLTcgBWgmughN/r9/V+FzUHqUex4obSZ
++YKo2IrP8lH8RDFXqKgNDZZYPhV4IFUauEcc7AuliBp9pOdtBValreNqH9XqDbEe3kvg2SlJ46O
L0R/q0dvLUgbe+KDE7sj0d/f3+UYSs9VsMibJPKIoTY0i2QbLj0PkbZgZLp7uHO0gmJ+nPje5Ykc
opqYvltZX+ckDAe2rxrYtqQWQYZ3rm82bjAsBg9gn6zdWM/IuFpdVbWq1nckfhSClIU+GfqBZKJC
HZuY5JlbFasCRp/z3AYrmPWEp83vA+SPSNDid/nRcX/PJLgG5zqDgYk+lIyP8QRU20IR/5+gbEBk
DlK15qV9HI3YZvMu4ujeL/yYwCfkx8Sb44uLtwjEPeLHtBl3LBvq0KwIK5ttyqY9XwOCN7dhownu
rq5vznMgA51aM9gQb5BtvqMkM057C35y2hiZZx6JnZwzjzq6Z/NjhfmxPXHgy1Rf1NpgN42lFFlN
hi5lB24COV5NUtSrqBGM8wS6JbFCjyp5AjWl2BMXayosul4THx1POhkCoysZ3/uuFGdZiJ3mUSiO
R45PKSLNUbLltO3FERiRCgv0E+UqPA2OyDw1a/ksPOJXt+3VLd7tTkhWszkNXtOu7modlj8t4WBY
rjvTjmaGK5p8A3wDS1nVRtzBC/2MWTrFC/3KhX59jn91l20BLtawJEOMjjewlO7FoP0OvNAPS1Q/
ygdqWRwdhomv8zbjq52onEm6L/C8HaWcYSTr+YKaI2lsZ2t3e46xHXNLrEeBcyd7gkZf8KF7RwQN
aL5xYkXRoBqhTpx7bFLqiVN8I2/F+e+1LkP0HRWaxXkx4lwpNWi4qyWHZ+aQKzrG5vnl7ekO+Cfa
36SfQP1WDkNxiIEkP5VumsVSzaed+EM1Oo9FU6nUj85qZ0GEU1E6IYo6Hg2jqSE0+BaYY+nKMa2r
xxzaHqed9RiWZdwKGVcDzvt7m0BKFZCxohuvqfjn9e0Mzb5qLhOqoJl0fnMr3rxi2Tbw9D3xyU0j
smMb6+vrbMfYjuk3YIVMkx3b2lzvw479hI4qCpuUsQLjoGaiGiCzwVM8VzKa67c3EDQPVPeTm8V+
+lgHx+BB0w7GnsMKLat4jjLFSjMiaeRGQQGNSQkr0BguZZtdim5QWditEHZyKdu76ztwKT84cYym
zRTUqCoJt4INap4M/BBrzInWEfNvIAaQ9DPiE8geweSFr5ADYitn5fKR0tCBvxh7j6hHW0RDqqhM
zZ163eln4vRzKiEDePXcDvK7W/3upPdgqY7u8wQPvNg+ezH2YvoNWOPFdta31inBE9NGHpSUjlAu
WtEslF1h0bXKQMH96mMUbYcwMDpqGTiEjzn9PAl8108JU9zKhICE9lIMHq1QuxJA4M+PUeoPiZsQ
T1kESaSQmnvpc94Nz1r2mJR/0nrxScm6VaHbKr9UIeLi0vRiStMUJO1s7FPe7ZAWhSYJxUjv4WDu
ndDm1NsPMriPothanpZmD0P7PuD/wVLlYuHHJT7WnEubBzWzo+AyGjuJ64TZXGcwEAUM9F4ddu22
uXZqyCImJBQbkClIhr4MPEDrmewQkt3iZ7AVA93RhyufDj/o6Jsf3raHP3TjKHwcEzcIPen56fUZ
oJ3iKd5B+htOUZBX7Ikfs1Cirtrvc/qA8Z1+AybJ/OAwS0dRnPxNHHoeMd3wvheOR2ZuwCR5bUa3
CLY/RCNnLD2bYe2fou5kCGGFeJ7FDnZpiWsZSCyB0+IWfkErXlB7s4Z42dx5kkuJvs1EiM1ttPnN
c4wiYmbBtEIwc9OivWvHl+N5Pc4iLyaLrEltg1E1uEXz9IPjB3P9/iYmIA/EOAfMT/sYvo+AUW7l
2gvxCRsTvgE2p4sxp8cjdHpg7tDqAtyf2pTQEfGwgC5GQDkMvneCdzYvRn0O8XAYvL1zdNhfUS0s
1M/ycJBMHJcaxB8OsERDxuhnIXoWaiKHJGxNP7nMAnzBydJo5Tv6a6orBn+cRWGa0F9OXL/O5yKd
19NkMqr5Ecyh+GlNAHMYDKnBi3EzlXYDVqRwnjOqHAZj0xQmCr8qudXDQTo4EG4Jmdd+Kzd0cSDc
hlA6omwOhDnOeD10Av1tBQMWG9T/ypwwwAjAXEcwMLXY8iY/Iiuhn6mjMWFVWowq/ZA5D9JH5dod
hVEQ3YJ3DiMq6H98n3ov6m3jB13Mg85lWMxs/D5yQspuznUCa0yj1a347+Gpbmcte1shz5onER7S
6LHv6kMg7LCsCKavRjL8A/8T2/29/sY+j1roKSEr3vB45IeOZuY7Kh+HngyvGF7p7O+qqpD8gVJC
QxGKsmG2t7T8RjHmYxE/fz9SgQu3s5AZ1VLibEr5BvgG+AY63sBSAgpejXZgTm1/wKvRytVoG7wa
TQctFoStHK++BGYupXsxyLaWvL2rJzHa0Co0VfjwCrQFl/L3zI8V5SVmxWb/OZzEfkB8Blss5S+R
cs5LsZ4vJi91GYXiwonvZPwSDebXW8zrHQ6Hfkz8Bh9l+hDFdwk/omaGLYCHIMrDupVni9fmNtD3
wLJxqMldQ6GXfv2izsv5BSuk8ucr/VE7PhsjGvaJi/GJz5ki7pp/ta55gMl/5WDye6dAJmEBTLjg
RnKpgRO2qB1vgC3qYiwq7ZiOEnHh34ZO6sT6DjJ+Qyvg3DHtehBXj0kqx1hRfB663KWtm2MrnpFR
+Qu9KPuQxfgQRuULmNQvZlknueP+3iUfwECcgfhLb4CNKBvRjk3E2MJ8qwcODVlilZqxZxzoo+On
+pk4GDIIRQfgwAHJLbYQSe8CazuPYuncqW739gnxj9fXGlLhBzXoQduf7YPvRbG/ejyKxObq/mq/
z4+opRqteETtzdq8g5kTyB+yxEkwnBat4t9zncNAL4c+2+vo7jES/b311b3tvW3tIGwJrVCiH53J
zCR8x4fjwi1HNxzddIxubB+RDCmSWbujGO37wLlZC9MUeaK13yYvcQFsSfgG+Ab4BvgG+Ab4BvgG
+Ab4BvgG+Ab4BvgG+Ab4Bpb6Bv6/AAAAAP//7FhNT+MwEP0rVs4I0tKGD9FKKRROLBU9rvbgOk5q
yY2j8YTC/npmnJQt6iK4LVo5F8fz4Rm/xJbe216CN8XjJEnTPD3Ls1kietONLmVrcc8zvdpeNgvg
wTdSmbqiWFmiBgriPGtqPUmGo7fJY2vJIFt0yQmnQZcNt65Gz8leGTNJrl0LRoP4obe8jJYec2/k
gWOd1/4wXPn3gaGS/00LPUlL7aRc+6QvTmPYAo9hPxQWEYgIRAQiAhGBiEBEICIQEYgIRAS+gMB8
nM3yQfI/8QKiBeBcOQcgYoAvDdEX32hrlygBOxJzEFCB3Oz5A0H690yH2p/OXKtkIQ0w/8GOBYWv
9dc9zuuip2nfg6txy0dCo5D2+LMN8Df4hv2L540NZJn+owa01/Ckk6non/lzY8goHhS6FfHf7EgM
08Fo5+7HnwtZaTE4/fUOg0hgdwh4rXDBx/WDG2tJflYxxhfZ7OK8u62qJesD20kyGPZyxZrex+ck
XQT5oKnuZbgBXEP2UadogKnWtNJuunKIbvNnbnW5511rWbAwckb6A5UqnQs6ST+tWuxlk1BOOcty
CKsq9KNwTDAXTt2BKcjDysrCoKIuT7OdoNFtPJzqlStewgultBtd4/QVAAD//wMAUEsDBBQABgAI
AAAAIQC8RAlz2AMAAIMPAAARAAAAd29yZC9jb21tZW50cy54bWzcV91u2zYUvh+wdyB0XVuyYzmr
ENtI7QQbULRFnGLA7mjpyCJKkRpJyXGv+hoFupfrk/SQkhw7NVx1yLqgV7ZJnv/vnPP5YnaXc1KB
0kyKiTfoBx4BEcuEifXEe3t73fvNI9pQkVAuBUy8LWhvNv31l4tNFMs8B2E0QRVCRxXeZsYUke/r
OIOc6r4sQOBlKlVODf5Uaz+n6l1Z9FC2oIatGGdm6w+DYOw1auTEK5WIGhW9nMVKapkaKxLJNGUx
NB+thOpit5ZcyLi0PjuLvgKOPkihM1boVlv+b7VhiFmrpDoVRJXz9t2m6GItUXSD9ch57fZGqqRQ
Mgat8XRRX+40DoJTtpsEWhU7iS4uHNpsPckpEzs1Fh0P6r8rXh+L59e2favqPhDMxfQeS2QTsWTi
IRg2ES1NJrG2L8/PwmBkTxJq0MYwGIx6wbgXjG4HYRQOoyD4y94ywQyjXKOEU1ngGcI6uZl4QXAV
jl9cDuwzd7SAlJbc7N1YJ4o3yn0szZYDPq0on3jzGuW3cGc8f3rh7565t6oWUcdEbiAFhc0EjVzz
lgohjcMdPqg11qqsbWO7INIFjTHSQoEGVYE3/TOjhjBNPn/4hDlh76UwlBMdU44IIDIl9h12BklL
ETtIf/7wz4xYb43zGS1Yz114bRL2om+PHi0vZrqQoAkzJAcqrN9feUhWYJ1HJFcsgYSstvWgIW7S
kARsQNrGcSQMDAYhZVvZhtR8xSgsenBidUPPOArCnwY9bQltVRfz4fBF6J0A1DIr05Rj1o0kJgMS
Y2utEVlYM0TTskHTPMMGJzfwd8kU2GT3/w9I/Rjg1lZO4WrohlCXsYTAGnUCVlOotnZ77Xd48+ZB
VZ/4pEps75sMB5a6x46bBDM7Clp4xRZe2OB2stGVLA3RBcQMVzzBHYGc5Ohk64LBw+zd/Cd5PQrL
H2f4FFLPvgep54+DVLdansACnc5m37swwrD7xjjrxjcW8/A6fH6MbzQ3TyZd2I8H+xVZgpIyvVIK
p5LZFshD1ormS0OVI0DIoNpxZYdSGA7Gw8t61UxpF01XIrGE6ISe4xzocPWg+In1xqlaAxFlvgJl
B0xMcc58NEg5CN2fSd1mySOX8tubZhB2buDz6KxbAweX4eXIEeuHDLi5eSqIPF79Pxz/NVKSjCqd
Wd6i6dZtk99fv325IK9e32Kl+4RcS0W0zAH/x1ZMSWF5yzPLRHHLFBL/M62Q3ONfUsd7ltdzEnOK
pykDRYRM7OaSJFGsAveCS4rclHKKRP4ZAbehKOfbnbiC3kMNR2G1P7Dvv+vpFwAAAP//AwBQSwME
FAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/Y
dyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Q
r7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY
8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablW
W12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+
8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpB
zwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQ
xTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY
80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r5
96+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDS
ZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF
/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJS
xu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtN
MqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErI
wVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpj
P5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxc
XDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJXZTP
Zy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ4Ooj
qqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmj
FU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe
3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRLeQTP
vKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXcJKjD
NYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFt
O/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3KrUzTP
ZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE/b6A
xsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWETESV
xJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXWYdPQ
5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGiIUrhvgfp
P7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ02atk7ZavllfcKdb8D1h
bC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAlTTDB
NyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAhAD8/R9xvAwAARAgAABEAAAB3b3Jk
L3NldHRpbmdzLnhtbJxV247bNhB9L9B/MPRcry62ZFtYbyDLVptiNy3i5AMoibaIJUWCpK11vr5D
SYx2EyYI+mTqnJnDITlzfP/uhdHZFUtFeLv1wrvAm+G24jVpz1vv86divvZmSqO2RpS3eOvdsPLe
Pfz+232XKqw1hKkZSLQq5VvvIttUVQ1mSM0ZqSRX/KTnFWcpP51Ihccfb8yQW6/RWqS+PybdcYFb
UDtxyZBWd1ye/SFzz6sLw632oyBIfIkp0lCwaohQVo39XzXYqrEi158d4sqojevC4GeR43E7Luuv
Gb9SnkkQkldYKbhZRofjMkRaK6Por+gM9/lISonk7ZXIAzzbF87ZrEsFlhVcKLx5EHi+IWBjfjpq
pDHQSmBK+yaoKEawfZeeJWIMwaMNSJ+jJaqeP+IrMf2jeqjGJ3Sh+hMqj5oLyLsiqHkVjbtUDYIc
jeVRoAo2yHmrJac2ruYfuM45ExLuYKgL+kcgbSq8KFwcHtGNXzRs5XfpREED18rEmMVHzrUVDIIs
WGXJbtAy7MQEYVwcEieTxdnSyYRRWBRLV064jPf7g4tZRGGWOytYBmG+yVw5cRwmkZvZJLvN2pWz
Xq/ifONkDotoU7iYTbFaJ7mL+fG97aCyzLnPLlsc9qFLbZ+sisBZwX69WhexMyePot0PmLiInRUc
4mSXOSs4ZKvFUDV0ztgvLDXT/698uB9WBXTjjA0tmyNWSoJmT8YfoN9YWsrnHWktX2LwKfyaOV5K
S87nA6EYorSAjrcEWMPA1ESJPT71wvQJyfOk3I8KS6UThfn6+6uaGWEs/5T8IgbVTiLxvq0BthuG
y+WoR1r9SJjF1aU82qwWbOIVdWnrf67SCPrTBXWpBmfH5oYeUXu2U4Tb+eejsQeMlM4UQVvvSzPP
P5hsGFAqj+YPAT8hIWDaIa48h1uPknOjQ5Om4atG8rn/KM/RyEU9B1+G6z9QZQ4L0ePCBAxLiBoX
E7aw2GLClhZbTlhssXjCEoslBmtuYJVghc9gvHZp8BOnlHe4/suCW+87aLgE1SCB4amNLYJH8bQH
Rp9Us2uKX8CHcU00/NcKUjP0svWWwTDjYzTtXe9NrFEyweINOquRhjfoJ8B/k9w75je1dGmNKwI9
eryxcnLhu6FwSpQ+YgGGrbmEI/dO/kffF9Pf/8N/AAAA//8DAFBLAwQUAAYACAAAACEAIRTVgisB
AACOAgAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1slFJNT8MwDL0j8R+q3FkKE1/V2knTxIkTjB+Q
JekaKYmr2GsZvx6vHTA+DuyUF/s959nObP4afNbZhA5iKS4nuchs1GBc3JTiZfVwcScyJBWN8hBt
KXYWxbw6P5v1RW/Xz5aImZhxlYhFKkVD1BZSom5sUDiB1kbO1ZCCIr6mjYS6dtouQW+DjSSv8vxG
JusVsQNsXIviUK3/T7UekmkTaIvIRoIf6wXloqjYo3EdHs6sL5zhFu+meX4/vb6dDoQ1mN3SdZzs
lOeskHt6UOnR1vQRzT+jT27T/BFeQfubuwAiCD/ibGhh0v4N+tJEHq1gIr6VghfAoFWahz1gDR54
sGpLMNrwR85OU66/OTpNm447P0Uqhy0MTY+wmo0nL4bB0S+q3gEAAP//AwBQSwMEFAAGAAgAAAAh
AOirO/OqCQAA7EcAAA8AAAB3b3JkL3N0eWxlcy54bWzEXNty2zgSfd+q/QeW3jPWXVZqlClbiTeu
yngykV37TFGQxTVFaEkqtvP122hAEEQKRMOka59skkCfvuE0aKP5+x8v2yT4ybI85ums0/ut2wlY
GvFVnD7OOg/3Nx8uO0FehOkqTHjKZp1Xlnf++PTPf/z+/DEvXhOWByAgzT9ms86mKHYfLy7yaMO2
Yf4b37EUnq15tg0LuMweL/h6HUfsM4/2W5YWF/1ud3yRsSQsADzfxLu8o6Q9U6Q982y1y3jE8hy0
3SZS3jaM084nUG/Fo89sHe6TIheX2fdMXaor/HHD0yIPnj+GeRTH96A4mLiNU559vUrzuANPWJgX
V3kcmg+/qHvi+UYMNB/qmVFeGAKv41XcuRCg+S+Y9jNMZp1+/3BnLpQ4uZeE6ePhHks/PCxMZWad
X5sP8ztxawlyZ50w+7C4EsIu0NLDT8Pi3Yn9cIWq7MIIfAdiwnXBIIYQEiE0iUWs+5Px4eLHPoEb
4b7gCgQFAJgpFi5LTofQQqAXMlHgKVt/49ETWy0KeDDrIBbcfLj9nsU8i4vXWWc6FZhwc8G28dd4
tWIiL9W9h3QTr9i/Nyx9yNnqeP/vG8wyJTHi+7QA9ccTTIQkX315idhOZBmITkMR5DsxIRFicwMH
FdrHR23kjRIq3vzvAbInY3gWZcNCsZIC1L8WCK3eNwbqC4tMA1Cul66D5iKGzUWMmovA5G3mi0lz
LYA/m0ZE5oaRlfSgFjySyWf6YTCtSVkxo5JFzhmVpHHOqOSIc0YlJZwzKhngnFEJuHNGJb7OGZVw
1s6IQiSuchYN0BukhX0fFwkT82sJqNeQ6lSpCb6HWfiYhbtNIGprWe06slzslwVNVaTTt5Plosh4
+uj0CFRnsXTfzMlftrtNmMewqXG4vt/Q9ffhMmHBv7J45YQayeSr2IQbk7Ml7HsSRmzDkxXLgnv2
IiPqMf+OBwu5y3Aq1zCs3+LHTREsNlhynWBji9PtnpDyv8U5+qB2MY0tpriEk2I4tuSlXfifbBXv
twfXEHYjY8nnHmEuQaCK9S4aihBVV5fTChEAigmyXPibgPIJ+svi4i9fxJiivyxFb5RP0F8WrjfK
x/yoj68303wOs6eAtLwm3mt3zhOerffJYQ046WHivYI1BM0E70Ws5ZNIYuK9gk/oM7iKInhzo+Sp
dyyOPOqB4h0OiYKLjW6Ld1BKtNfzsMg7QCWsvgdWM671APIm3R/sZyz+9uRbDJCl9V7TuZwHFg9A
CSLtof/e88K9h+5bOI+KcpvCn0tyFtDQBpaVR0VT+STrnUeMmxU+D6BmFdADqFkp9ACy5Id9z6Nr
Ih2keXH0wPKmZV3FMO3IzDzxZmYN5FcCWqqbhP2XZfXac6FaNwko3gGq1k0Cind0SrVM100CVmt1
k4BlqRr2GJmc6mOUd900gfROgGBRO+RNAGqHvAlA7ZA3Aag5ebtB2iNvApY3N2hONcmbAIRDfF71
NZBJ3gQgb26QbKf+ZnSoeyil/uW2BfImoHgHqEreBBTv6NjIm4CFQ3wyoYSlqY6A1Q55E4DaIW8C
UDvkTQBqh7wJQO2QNwGoOXm7QdojbwKWNzdoTjXJmwDkTQ8ayCRvAhAO8eGGs+SNq/7dyZuA4h2g
KnkTULyjUyJUvUklYHkHqISlyZuAhUN8kkFhYXL7GNUOeRMsaoe8CUDtkDcBqB3yJgA1J283SHvk
TcDy5gbNqSZ5E4C86UEDmeRNAPLmhrPkjYvx3cmbgOIdoCp5E1C8o1MiVM1zBCzvAJWwNHkTsDBf
GpM3AQiHvBXIx6J2yJtgUTvkTQBqh7wJQM3J2w3SHnkTsLy5QXOqSd4EIG960EAmeROAvLnhLHnj
Gnl38iageAeoSt4EFO/olAhVkzcByztAJSxNdQSsdsibAISJ2Zi8CUA45A1AuIp8wtQOeRMsaoe8
CUDNydsN0h55E7C8uUFzqkneBCBvetBAJnkTgLy5QZyzhfOi5OOpPUsSUM8ZHE41kAH7liBRAZWB
P9iaZdDMxNynQxoCHiz0QLSkB9XEa86fAtrB7oElQchQ8TKJOR7pfsVTOkYjwmBS00lw/9c8+Cob
YCrzMKVOT95A95DZLoTtSaJxCPQsXnfQsrM7nCwX0qBBSLR2qRYgbEW7hYYg1dYjJos+HxiITVXq
Nv7fVqHi79D2tjqM6XZH0/H19FI1OKHIqhLRBrSIoFeqRgl1FF6fTsKD8GWVLOflUa1js8ZBOXVu
/ri7kuNOTm/CLfChRe9CnBGv0RnPkNd6L8AhMt5VBaFtC1VyaajPW+HoYpnIRjT45TYVoYDOP/zf
mgz56iWUYuH5nCXJnyG2rRV8Zx+asHUhn/a6WCdLopa8KPjWPj/DY+SoyTkB4GJTGXkpjLD7Pt1v
lyyDPrAa/99xUV+wX+00ceWJWBluvfJAe8xrqtftup3ks15Gc74VHZpHPitnb5imHHr4REddpmkW
lVyG0Jn3l2i0Qw3ProWG1kCL48m6/TIaX1+pFQJtnrhodY9lb6wS89exx1LeA6fgaLtzThin7Bxs
hqjxSyGaJc65xCQjaLR8OrhKOV3InQPLyLlNVprdS5X2T9XwOcS1Jy7ON3wqjwHLaP9C8woamRv+
lffc/j1Jvmifw7pcCMovs3rZM2Wvq+fYnxIcfUdORUsUPCNgd3clKZs4rTYpYevzHxZVecRYr7ka
ci41DUdL41NIxjP5KR+ecZvCP8bgffJXOXQpbZjn8LP1bDNNsSWcGmPPOcOhR5/Y/dZ2xvk56Hxm
XYdJwnl6lu7UM9kYdi6hbFxnCD365X1ypcJ1qtVdUx10ipN5Lzv5YMCscx9u+DYUdR2/A2DeiHJ9
hZ45UmaTkhSZ+88ayiw7uJzBZuTs6Wuv3mYOG1htJ/D/3d8na6LG3z9u5mIDd71PElalX3iK+7hA
PXctldNS8nk+uoHGTZyksvmJsd03KNOC+eBVZ7+V2x745Va/0OCOCGhRP4V3APwUBvw8cLrYLIvs
3XHI1uFAfY/CNqDXn6rdlHXEpI8vULBJtoD0e9B5iVpbR4ymDj0G3f6wXsZgOHJoOri8dGgK7nBo
OpyMHJqOepcOTUfjAx3Y/DHuDh2ajoeXDk3H055D08lg6NB0MoHvgdRG7rIPb1z1I8ZAtbUjpl04
618/YtR1aDqdDlBTSH5wKuZ8XvnSyZHzzxQA9gIv+UINEKGWnNpzlBlpzvdZDL3Rd+xZLKTD52Jm
nesQPpuDr3yqNJRGivpg3kKbj0XikOEn+2plt/o2zBFLfiBGqlt6pwED8M0l//Q/AAAA//8DAFBL
AwQUAAYACAAAACEAjrhPwRUDAABtBQAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lF2PokgUhu8nmf9guNqNcar4EuhoT/gQFEVRQRtv
DAIiSAFShYib/e9rZ3ac9EXf7GYuK6fy1HnfJ6nB9xvKOteowkmRDyn6G6Q6UR4UYZLHQ8p19J5I
dTDx89DPijwaUm2Eqe+vX78M7Kooo4okEe48EDkeUidCyhcAcHCKkI+/Pcb5Y3IsKuSTx7GKQXE8
JkGkFUGNopwABsI+CGpMCtQrnzjqB+/lSv4rMiyC9+3wxmnLx7qvg3/hbeeISBIOqb80XtU0HvI9
ZiSpPRrSSk9iJaEHRQgZhVF1SR79TXXK98sM1cl99Ii+z6Nmj/C+nGh7geE59kG+kpesbDCpXv9g
/5TA0W7VfESWZfeNphuuUs+Etkpj4WBbvkn3XUvYviom0UlMtSTo1g5j0P50ZkTsW7wS1hcE9StX
728QwnD/9cu9Xk+tYuc3WO6renvazBydrqLVkub0273bX4V3bRKoW/u29kSZCeepV9Lmaqw3cXhz
jPMox0K+Nq5PoMeDzIyjwz3OSNq1xcQT0VwxzsWbGZajieNxVhCNA43FtscUkskRxq+mts+HB/YQ
4ZLrzyvs5vMncJY6/EaXT9taauBkid82A/CrkwH42fz/dMB+6oD+IKE2zjusHC+NTHauUrqlINw9
xVLCVppOztqJRbucrLylsXmLZ2OCQcbK2uKZZgmDbEkUGfn2BMHxyLZY7XJJ3YXlHdZytUJkpLro
MplCdgEu4gXQiaD318BP5ts1J8yumDHDovafwMxywUIqMzOreWeqQKIdANhtJ2WtVYBYbYiQl7om
4R3UYFAX/HGJDHVmnngBgYA7jjkOdbfRr76XiTJyLYtJGJCSJC+4mIGb2oOLOAsEsxbrprn9FgPc
pwaYDwakYjte+fo64qf+Nh3fNakMd6UoKwlMCNvNxOvZeNbjd80cqvx9vB658mnCuZaW89bZTtnN
zPPZzVaapwcjcpZu1bSqZPaD3O7e3WIODXqtRm3s+6MDEi5P4G+Jzv+Mjo+ZH39IS3OQlhiGFeBn
L4P3n+jHP/n6DwAAAP//AwBQSwMEFAAGAAgAAAAhAE/m6cJDAQAAWwIAABEACAFkb2NQcm9wcy9j
b3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySXUvDMBSG7wX/Q8l9
l/Rjc4Q2A5VdbSA4UbwLydkWbNKQxHX797ZdVyd64WV43/Pw5CTF4qir6ADOq9qUKJkQFIERtVRm
V6KXzTKeo8gHbiSvagMlOoFHC3Z7UwhLRe3gydUWXFDgo5ZkPBW2RPsQLMXYiz1o7idtw7Thtnaa
h/bodthy8cF3gFNCZlhD4JIHjjtgbEciGpBSjEj76aoeIAWGCjSY4HEySfB3N4DT/s+BPrlqahVO
tr3ToHvNluIcju2jV2OxaZpJk/UarX+C39ar5/6qsTLdrgQg1u2n4j6s21VuFcj7E1vdZVOSF/h3
0pUdHFT3CCxJ+8p4LqToxalwwAPIqFWhZ/FL8po9PG6WiKUkyWMyi0m+SQnN55SQ9wJfWsM8G4F6
cPsnMaXT7CfxAmC98c/vwL4AAAD//wMAUEsDBBQABgAIAAAAIQAMSkw/LwMAAH0PAAASAAAAd29y
ZC9udW1iZXJpbmcueG1szJdLbtswEED3BXoHQ/tEki1/akQJ8jOQIg2KJkXXskTHRPkRSMqOt71M
jtBj9QodkqIi24EQK27hjWlxhjPDx+GQPDl7oqSzQEJizmIvPA68DmIpzzB7jL3vD5OjkdeRKmFZ
QjhDsbdC0js7/fjhZDlmBZ0iAYodsMHkeAHiuVL52PdlOkc0kcc8RwyEMy5oouBTPPo0ET+L/Cjl
NE8UnmKC1crvBsHAK83w2CsEG5cmjihOBZd8pvSQMZ/NcIrKxo0Qb/FrR17xtKCIKePRF4hADJzJ
Oc6ls0bbWoMpzp2RRdMkFpQ4vWX+Fm+ZSJbAmRIb9pKLLBc8RVJC75UVVhbDoMl3CVCbqEa8JYR1
ny4SmmBWmdHpsbH+1eIdw+L51revTb1MBFicQjIlU6lEkqq7gnbWvm6y2AuMCpM4A9kiIdDTC0fD
8OLS8/VgWhCFb9ECkYdVjpzOfDUVOPuiZUTLrK6iOXEa3eEkCvrRtZWQhRZgaLRH+Ktyksbe5fn5
dTeMBiYG2ApCueGhHQf7YEKrzmlBCFJWkt+rFani+Ta5vMVSXdQUwNcDeqrG8iqQz6lzQtDMWfsq
9GQVoCpbpwMR6HhzLmNvNIi0Ff9FETONTduxUviYJ+zR7PCo1y21c2tdlM2EMyVBM5EpxgCBFwIj
0blDS+1pfg6Lsd2LGbjI0CwB5qVZYw+CgZnqoOuMwxfGQRR8CoKg14LxP0AYRlHQwNCI6xB7A6e+
B4gprOEm7d24dre49k0PlD2odrpKh+/n/OfXs0ZkVrR9snbDCp1L63q2GnEb0j8gufURBkW9Stb1
vt2Q9raQ2uTdM9Lf+0A6GrlsfBWpFrdBer+iUw7nVsWz1rEbzGgLpsW7V5j7KKWwr5tQGnEblJvb
+9Vi+v46YHe9OcPK+nqwdQCOoSbSRtyG9Pqet5zX+3ZLXbikumtBifRg60AfAmw4xIy4DdLatrc8
ax27wRxuwTzQOtAfNp5SRtwG5X+qA/CC20jag60Dg6jx8DLiNqTX93ybOgBX2NoTRV984NINocCv
fqHYG1VN40bfue1TpdyFoGmu5dDaZ/PpXwAAAP//AwBQSwMEFAAGAAgAAAAhACLsxLLNAgAAgwoA
ABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzEls9u2jAcx++T9g6R72vsECig0qqwcuxhZdrZBAOWYjuy
A5Tzjjtue41pL9C32U7T3mE/2wm0kKxE2h8iiPg6dpyPv7+vc3F1L9JgzbThSg4QOcMoYDJRMy4X
A/R2Mn7VRYHJqZzRVEk2QFtm0NXlyxcXm/5cydwE0F+avh6gZZ5n/TA0yZIJas5UxiS0zZUWNIe/
ehGq+Zwn7LVKVoLJPIww7oSapTSHe5slzwwqRtucMtpG6VmmVcKMgcmK1I8nKJfosphdsOlLKmDW
I7XSnOnglm1cY0alMoxA+5qmA4QjfI5buAfnCLfhG+MYhXaUZEm1YfnuQuzlORU83ZaqUDOmpW/J
eJ4sy4Y5v2czrxu+AHVlpniAbjDG0fV4jLxCYH6gnHfjVqFEMCX/6RVKa6fAAsG03DjuEuLHAQXG
KXq5WYZ+hY5YTLhgxpII3ihBPaxjHhHuAJE2kLA8Wo14aDeu4/cEx5pqTqcpa0CE/Asi78A/1vCm
0hvtEur+7B/g0BuRl596g65y5fUTUZR3KR4cFpUU0hEKZwWwVKU5uo96nW6Ou62YqrSGQxsT8AKB
Wum4OjlvwKG5J/4viBFN+VTzShIRHruqsGkRQ23AbzWJyrQwG25MI0vYvMDR47yIQbge7ZR9XpT1
UmkJR5T0XO40sAQXdysfEzTNbyFPy3j7/uXDt4ePxaMcJSoBl2CgQ8qjklG34+U/UzVlgELVRN3u
2D7wYdWQTqHUIbJsHcbTEU3oEiKvxitD4GBdYrM0/vtegbSIbnbOKPaWDm4PD0FEz+0tsHBN95Yh
hVeFhQNx4JUfXz/9fP+5zist5xXgXh7VXiG/94pU+USv2GSbsePNp2YvthaBT1k3dg/t+ckc8iKl
leqM4xLX9jrdOCMqIGTqnGP3Xu8buxc3S5nmeVudMjjeeWmfMs+RAJ7PpkzxemIufwEAAP//AwBQ
SwMEFAAGAAgAAAAhAPLkWAoBAgAAAwQAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFNdb9MwFH1H4j9EeWZxErpuVK4n1An1YbBKzbZn49wk
Fo5t2W5Z+fVcJ2ubAk/k6X7l+PjcY3r32qtkD85Lo5dpkeVpAlqYWup2mT5VX65u08QHrmuujIZl
egCf3rH37+jGGQsuSPAJQmi/TLsQ7IIQLzrouc+wrbHTGNfzgKlriWkaKeDeiF0POpAyz+cEXgPo
GuorewJMR8TFPvwvaG1E5Oefq4NFwoxW0FvFA7BvkY7KahN6Sk5VWpnAVSV7YEVZYOOU0g1vwbPi
mpIxoi/G1Z7Nrj/dUDLGdNVxx0VAFVk5L3OcnVToZ2uVFDygwuyrFM5404TkcdAiiQiUTEco6rMF
sXMyHFhOyTSlD1Ijm7K4pWQMkZ/jreO282yOzCcp3QquYIU6sIYrD5ScC3QNPO54wyWSpvuw2IMI
xiVe/sItl2nynXuI6i3TPXeS64AqxrExGWJlfXCskkEhNvbGfAinY9NYzhiSxFkMLgdjceSAjUt2
wwn+scG7hX+QLaZkBw4j1QmdSXg64w/Ulekt1we23vGfIJMKRKeNMm00+MpkHx5CneFe36biIn74
J1uZ++iqN30vixNbvMjQbS0XuLuP+c0MJTgbZNKjWzQS1LjxI+K5QNe4DKfisfivbqE+zvzdiJZ7
Ht80+jnL8Rs8dqyhTU6Pjf0GAAD//wMAUEsBAi0AFAAGAAgAAAAhAGODGMqOAQAApQYAABMAAAAA
AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAmVV+BQQBAADh
AgAACwAAAAAAAAAAAAAAAADHAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAQUIjRBgBAAA5
BAAAHAAAAAAAAAAAAAAAAAD8BgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQA
BgAIAAAAIQAiiprBcWYAAN0SBwARAAAAAAAAAAAAAAAAAFYJAAB3b3JkL2RvY3VtZW50LnhtbFBL
AQItABQABgAIAAAAIQC8RAlz2AMAAIMPAAARAAAAAAAAAAAAAAAAAPZvAAB3b3JkL2NvbW1lbnRz
LnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAAP1zAAB3b3JkL3Ro
ZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAPz9H3G8DAABECAAAEQAAAAAAAAAAAAAAAADG
egAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAIRTVgisBAACOAgAAFAAAAAAAAAAA
AAAAAABkfgAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA6Ks786oJAADsRwAA
DwAAAAAAAAAAAAAAAADBfwAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAI64T8EVAwAA
bQUAABMAAAAAAAAAAAAAAAAAmIkAAGRvY1Byb3BzL2N1c3RvbS54bWxQSwECLQAUAAYACAAAACEA
T+bpwkMBAABbAgAAEQAAAAAAAAAAAAAAAADmjQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA
CAAAACEADEpMPy8DAAB9DwAAEgAAAAAAAAAAAAAAAABgkAAAd29yZC9udW1iZXJpbmcueG1sUEsB
Ai0AFAAGAAgAAAAhACLsxLLNAgAAgwoAABIAAAAAAAAAAAAAAAAAv5MAAHdvcmQvZm9udFRhYmxl
LnhtbFBLAQItABQABgAIAAAAIQDy5FgKAQIAAAMEAAAQAAAAAAAAAAAAAAAAALyWAABkb2NQcm9w
cy9hcHAueG1sUEsFBgAAAAAOAA4AgQMAAPOZAAAAAA==

--_004_4A95BA014132FF49AE685FAB4B9F17F645D6B87Adfweml701chmchi_--


From nobody Wed Jun 25 12:13:43 2014
Return-Path: <narten@us.ibm.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF841B2E36 for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 12:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level: 
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH_Ef7kXufLc for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 12:13:40 -0700 (PDT)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308EF1B2E30 for <sfc@ietf.org>; Wed, 25 Jun 2014 12:13:40 -0700 (PDT)
Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <sfc@ietf.org> from <narten@us.ibm.com>; Wed, 25 Jun 2014 13:13:39 -0600
Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 25 Jun 2014 13:13:38 -0600
Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id BCBC53E4003F for <sfc@ietf.org>; Wed, 25 Jun 2014 13:13:37 -0600 (MDT)
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by b03cxnp08027.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s5PJCWeb8192286 for <sfc@ietf.org>; Wed, 25 Jun 2014 21:12:32 +0200
Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id s5PJHZvW025729 for <sfc@ietf.org>; Wed, 25 Jun 2014 13:17:36 -0600
Received: from cichlid.raleigh.ibm.com ([9.80.96.116]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id s5PJHYgu025680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sfc@ietf.org>; Wed, 25 Jun 2014 13:17:35 -0600
Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s5PJDZP2008091 for <sfc@ietf.org>; Wed, 25 Jun 2014 15:13:35 -0400
Date: Wed, 25 Jun 2014 15:13:35 -0400
Message-ID: <m3y4wkztsw.wl%narten@us.ibm.com>
From: Thomas Narten <narten@us.ibm.com>
To: sfc@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14062519-0928-0000-0000-000002F54100
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XLYHY9fgwVst-Ga_PB5tLBpBlEo
Subject: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 19:13:42 -0000

Hi.

We ran a WGLC on the problem statement draft
(draft-ietf-sfc-problem-statement-07.txt) back in May.
Although the draft received significant review and support prior to
the formal LC, the actual last call resulted largely in silence.

While it would be convenient to take silence as acceptance, that's not
good enough. To show the document is ready, we need WG members to
speak up and indicate they have read a recent version of the document
and think its ready to go.

Note that the document was just reissued. Section 3 has been edited to
remove some of the text was deemed to be encroaching on
architecture. You can see the changes at
http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-sfc-problem-statement-07-from-06.diff.html

With that, we are restarting a 2-week WGLC on the document. We
specifically need to see sufficient indications from WG members that
the document is ready to advance, and that the document does not
contain significant deficiencies.

Thomas


From nobody Wed Jun 25 14:54:10 2014
Return-Path: <smkumar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40A21B279A for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 14:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwZY-Pev_az3 for <sfc@ietfa.amsl.com>; Wed, 25 Jun 2014 14:54:05 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E161A854B for <sfc@ietf.org>; Wed, 25 Jun 2014 14:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5316; q=dns/txt; s=iport; t=1403733245; x=1404942845; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xzORcBrs+4TvO/6MFvrhBe42mC9fgvXANTieNpmE1RU=; b=NonFKAOdTFASTQyVz06ta3tdZUqiyBPm0I4USBLGj7r2wmoKFQ3yT231 sieIJQSYLG30f+wMmHENVSY8jKRPetVz99UOxedWiW3aZ9iIRsScyLT/p nr3GXe6LJplaEnc+cbHlKSe2PGRWw8Rh+dSCnrciawj5JbxZzzDGUUJ2j g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnEFAFBEq1OtJA2I/2dsb2JhbABYgw1SWqoYBQGReodAAYEOFnWEAwEBAQQBAQE3NAkOBAIBCBEEAQEfCQcnCxQJCAIEARIJEIgpDcNmF4Vjg2OFPQaEPQWaUYFGkiWDQmyBRA
X-IronPort-AV: E=Sophos;i="5.01,548,1400025600"; d="scan'208";a="55968993"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 25 Jun 2014 21:54:04 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5PLs47K010501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jun 2014 21:54:04 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 25 Jun 2014 16:54:04 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt
Thread-Index: AQHPbIFScQlELIcIVkC+ZvduVETk7JuBNC+AgADy9ZCAAF5EgA==
Date: Wed, 25 Jun 2014 21:54:03 +0000
Message-ID: <CFD07646.491EA%smkumar@cisco.com>
References: <20140510185452.30694.53589.idtracker@ietfa.amsl.com> <CFCF7721.48EBE%smkumar@cisco.com> <29264E37AFF9384FAEBBC9C6CD32643415DA3A73@DEMUMBX011.nsn-intra.net>
In-Reply-To: <29264E37AFF9384FAEBBC9C6CD32643415DA3A73@DEMUMBX011.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [10.21.70.158]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29064D3C5ED6084AA6AD2E88BC7CFF90@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BKQvp_VPYPZWLdJxpCKtB4iRNqw
Subject: Re: [sfc] New Version Notification for draft-kumar-sfc-sfp-optimization-00.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 21:54:07 -0000

Hannu,

Thanks for reading and the comments. Comments/responses inline.

Surendra.

On 6/25/14 7:31 AM, "Flinck, Hannu (NSN - FI/Espoo)"
<hannu.flinck@nsn.com> wrote:

>Hello Surendra
>
>Interesting reading. Thank you for that.
>
>I have couple of questions related to this draft (and to the arch draft):
>
>In section Definition of Terms you define:
>
>Network Forwarder (NF):  The entity, typically part of the network
>       infrastructure, responsible for performing the transport function
>       in traffic forwarding.
>
>Service Controller (SC):  The entity, typically part of the network
>       infrastructure, responsible for performing the transport function
>       in traffic forwarding.
>=20
>
>So if they are the same (NF =3D SC) why to have two different names?
SK> I had a review comment to fix this but it still fell through; will
take care of it, thanks.
SC is the entity responsible for managing the service chains, including
create/delete/update actions as well as programming the service forwarding
state in the network - SFP distribution.

>=20
>
>
>Why is optimum path in its best case starting and terminating at the
>classifier itself (in section 3). Is a null service path a service path?
>Do you add a NSH into that one? If not what makes the optimum path of
>null path a service path?
SK> Classifier is the one starting the service path on a packet/frame,
after which it may traverse many NFs/SFFs. In this reference example, if
the offloads are propagated to the source - the service path
originator/classifier, there is no need for steering of traffic altogether.
It is not a null service path as the path can be un-wound if the service
functions on that path require traffic to be steered to them at a later
point. We leave the details to the implementation.

>
>
>It is interesting choice that you do not ack transactions of offloading,
>action, etc but you allow capability exchange.
SK> I suppose ACKs can be added, which adds overhead. As it is, it does
not violate the correctness even if the offload is not honored for any
reason.

>  =20
>
>
>Now this one is hard to me:
>
>You write: Although SFs can signal SFFs by piggy backing on the serviced
>packet,
>   SFFs cannot repeat the same towards upstream SFFs as the traffic is
>   forwarded along the SFP while the signaling has to go back to the
>   upstream SFFs.
>
>But isn't NF in the same position to SFF as what SFFs are for SFs?
SK> That is correct. In general, the principle is to pass additional
metadata (such as offloads) with the packet at hand - in band, as opposed
to generating signaling only packets - out of band. For optimization to
work, SFFs have to signal the upstream SFF (for the SFP) of the offload.
However the packet itself goes downstream. Implementations can choose to
do the signaling out of band or can potentially use the opposite flow to
do it in band.

I will clarify this further in the next revision. We did not want to get
into the specifics of how the offloads are signaled between SFFs.

>
>
>- Hannu
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Surendra Kumar
>(smkumar)
>Sent: Wednesday, June 25, 2014 4:47 AM
>To: sfc@ietf.org
>Subject: [sfc] FW: New Version Notification for
>draft-kumar-sfc-sfp-optimization-00.txt
>
>Hi,
>
>We published a new draft last month.
>Just occurred to me that I never forwarded this to the list.
>
>Surendra.
>
>On 5/10/14 11:54 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
>wrote:
>
>>
>>A new version of I-D, draft-kumar-sfc-sfp-optimization-00.txt
>>has been successfully submitted by Surendra Kumar and posted to the
>>IETF repository.
>>
>>Name:		draft-kumar-sfc-sfp-optimization
>>Revision:	00
>>Title:		Service Function Path Optimization
>>Document date:	2014-05-10
>>Group:		Individual Submission
>>Pages:		14
>>URL:           =20
>>http://www.ietf.org/internet-drafts/draft-kumar-sfc-sfp-optimization-00.t
>>x
>>t
>>Status:        =20
>>https://datatracker.ietf.org/doc/draft-kumar-sfc-sfp-optimization/
>>Htmlized:      =20
>>http://tools.ietf.org/html/draft-kumar-sfc-sfp-optimization-00
>>
>>
>>Abstract:
>>   Service Function Chaining (SFC) enables services to be delivered by
>>   selective traffic steering through an ordered set of service
>>   functions.  Once classified into an SFC, the traffic for a given flow
>>   is steered through all the service functions of the SFC for the life
>>   of the traffic flow even though this is often not necessary.
>>   Steering traffic to service functions only while required and not
>>   otherwise, leads to optimal SFCs with improved latencies, reduced
>>   resource consumption and better user experience.
>>
>>   This document describes the rationale, techniques and necessary
>>   protocol extensions to achieve such optimization.
>>
>>                =20
>>       =20
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc


From nobody Thu Jun 26 07:04:17 2014
Return-Path: <paulq@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AF11B2790 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 07:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUvsvA3J6CSq for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 07:04:09 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CAB1B30EE for <sfc@ietf.org>; Thu, 26 Jun 2014 06:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1364; q=dns/txt; s=iport; t=1403789706; x=1404999306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dpAvSJIurF0CB85iirq6v1KlRyF9d0xwkIAXST0Xg+k=; b=Zs7WMn100oXJBgO6YY3embL7Uodwjgw9YwrVn6m7PjOQci6d+OdejiRO va0G8WMgydBVZCjEyARvxpZ4WjQ5jPRzeDYFZABItTGHbTSttGkZEB1EF X4SaxLHDsZALPXikBmBOv+fj0gh0ZLSNefNTOMLOBn6qF0JgCIO0GOKM8 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAGQgrFOtJV2Q/2dsb2JhbABagw1SWrxCh0ABgQsWdYQDAQEBAwEBAQE3NAsFCwIBCBIkECcLFw4CBA4FiDoIDcMwF45NMweDLYEWBZpYgUaSKYNCbAGBQw
X-IronPort-AV: E=Sophos;i="5.01,553,1400025600"; d="scan'208";a="335792791"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jun 2014 13:35:05 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5QDZ5lc011584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 13:35:05 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 08:35:04 -0500
From: "Paul Quinn (paulq)" <paulq@cisco.com>
To: Thomas Narten <narten@us.ibm.com>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmY2GzMEM1YrUSzZ89YzxwzcZuDuVsA
Date: Thu, 26 Jun 2014 13:35:04 +0000
Message-ID: <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
In-Reply-To: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.116.113]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C911A3B8D339DC4FB337BB1FF4A6A05B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2htfjSi9KqqgzUfd3iy7D2GwzFQ
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 14:04:15 -0000

Thomas,

As an editor: I support moving this draft forward.

Paul

On Jun 25, 2014, at 3:13 PM, Thomas Narten <narten@us.ibm.com> wrote:

> Hi.
>=20
> We ran a WGLC on the problem statement draft
> (draft-ietf-sfc-problem-statement-07.txt) back in May.
> Although the draft received significant review and support prior to
> the formal LC, the actual last call resulted largely in silence.
>=20
> While it would be convenient to take silence as acceptance, that's not
> good enough. To show the document is ready, we need WG members to
> speak up and indicate they have read a recent version of the document
> and think its ready to go.
>=20
> Note that the document was just reissued. Section 3 has been edited to
> remove some of the text was deemed to be encroaching on
> architecture. You can see the changes at
> http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-=
sfc-problem-statement-07-from-06.diff.html
>=20
> With that, we are restarting a 2-week WGLC on the document. We
> specifically need to see sufficient indications from WG members that
> the document is ready to advance, and that the document does not
> contain significant deficiencies.
>=20
> Thomas
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


From nobody Thu Jun 26 08:12:42 2014
Return-Path: <diego@tid.es>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715CF1B31E5 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.953
X-Spam-Level: 
X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEPZCBrr_GBi for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:12:35 -0700 (PDT)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFA91B2E05 for <sfc@ietf.org>; Thu, 26 Jun 2014 07:19:48 -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 <0N7S003BV54YPP@tid.hi.inet> for sfc@ietf.org; Thu, 26 Jun 2014 16:19:46 +0200 (MEST)
Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id E7.DB.05381.20C2CA35; Thu, 26 Jun 2014 16:19:46 +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 <0N7S003UB54YM0@tid.hi.inet> for sfc@ietf.org; Thu, 26 Jun 2014 16:19:46 +0200 (MEST)
Received: from EX10-MB1-MAD.hi.inet ([169.254.1.134]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 26 Jun 2014 16:19:45 +0200
Date: Thu, 26 Jun 2014 14:20:03 +0000
From: "Diego R. Lopez" <diego@tid.es>
In-reply-to: <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
X-Originating-IP: [10.95.64.115]
To: "Paul Quinn (paulq)" <paulq@cisco.com>
Message-id: <87E1DDFD-0648-48F3-9A51-C0F9A324F36A@tid.es>
Content-id: <23D99B1628420C43B7BBE7AA0F958BDE@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US, es-ES
Thread-topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-index: AQHPkKmZ9fvMrcNI9EWydhcw8ieXxpuDRAUAgAAMfIA=
X-AuditID: 0a5f4068-f79276d000001505-1a-53ac2c02b9fc
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsXCFe/ApcuksybYYNoXRYsnD7ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48LKr8wFP8QrJs9/zNjAuEK8i5GTQ0LAROL4tf1MELaYxIV7 69lAbCGBg4wS11fVdjFyAdnfGCVuvTzBBuHMZJTY0bGLEaSKRUBVYlPzLzCbDch+1PybHcQW FrCQWDr7ApDNwcEpYCuxc2MNxAIFiT/nHrOA2CICWhK3f20Gs5kFXCQOz24AW8wrYCkxb9Zn Zoi4mcTPp8fZIeKCEj8m32MBGcksoC4xZUouRIm4RHPrTagxihLTFjWAXcMoICvxbv58VohV lhLnXp5hA2kVEbCSePgsG+IaAYkle84zQ9iiEi8f/2OFeD1BYsHkZsYJjBKzkBwxC8kRsxCO mIXkiFlIjljAyLqKUaw4qSgzPaMkNzEzJ93AUC8jUy8zL7VkEyMk3jJ2MC7fqXKIUYCDUYmH 1+PZqmAh1sSy4srcQ4wSHMxKIrzHpNYEC/GmJFZWpRblxxeV5qQWH2KU5mBREueNe10UICSQ nliSmp2aWpBaBJNl4uCUamCMYay2ZzR5t/uc7iXBLj8e9Rm5vqYTVU5PLWzbXyJrFm1n+trn MlPWind/Y9qFTz2ed4Kn48k+4WmHP7HMFy8VfnZjk9WniI+n3kQ87rDa4Pz0Z6vEjhtvFr2y SmITzTuzSp976p17MrKz+WSqzVZlMOpmR90/YPpsU8eZD6f31ei/X+n5P15ViaU4I9FQi7mo OBEAs4MAr7MCAAA=
References: <m3y4wkztsw.wl%narten@us.ibm.com> <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-5kD5X7syM8GuGB2xP80BK9NYzE
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 15:12:40 -0000

SSBzdXBvcnQgaXQgYXMgd2VsbA0KDQpPbiAyNiBKdW4gMjAxNCwgYXQgMTU6MzUgLCBQYXVsIFF1
aW5uIChwYXVscSkgPHBhdWxxQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj4gVGhvbWFzLA0KPg0KPiBB
cyBhbiBlZGl0b3I6IEkgc3VwcG9ydCBtb3ZpbmcgdGhpcyBkcmFmdCBmb3J3YXJkLg0KPg0KPiBQ
YXVsDQo+DQo+IE9uIEp1biAyNSwgMjAxNCwgYXQgMzoxMyBQTSwgVGhvbWFzIE5hcnRlbiA8bmFy
dGVuQHVzLmlibS5jb20+IHdyb3RlOg0KPg0KPj4gSGkuDQo+Pg0KPj4gV2UgcmFuIGEgV0dMQyBv
biB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQNCj4+IChkcmFmdC1pZXRmLXNmYy1wcm9ibGVt
LXN0YXRlbWVudC0wNy50eHQpIGJhY2sgaW4gTWF5Lg0KPj4gQWx0aG91Z2ggdGhlIGRyYWZ0IHJl
Y2VpdmVkIHNpZ25pZmljYW50IHJldmlldyBhbmQgc3VwcG9ydCBwcmlvciB0bw0KPj4gdGhlIGZv
cm1hbCBMQywgdGhlIGFjdHVhbCBsYXN0IGNhbGwgcmVzdWx0ZWQgbGFyZ2VseSBpbiBzaWxlbmNl
Lg0KPj4NCj4+IFdoaWxlIGl0IHdvdWxkIGJlIGNvbnZlbmllbnQgdG8gdGFrZSBzaWxlbmNlIGFz
IGFjY2VwdGFuY2UsIHRoYXQncyBub3QNCj4+IGdvb2QgZW5vdWdoLiBUbyBzaG93IHRoZSBkb2N1
bWVudCBpcyByZWFkeSwgd2UgbmVlZCBXRyBtZW1iZXJzIHRvDQo+PiBzcGVhayB1cCBhbmQgaW5k
aWNhdGUgdGhleSBoYXZlIHJlYWQgYSByZWNlbnQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQNCj4+
IGFuZCB0aGluayBpdHMgcmVhZHkgdG8gZ28uDQo+Pg0KPj4gTm90ZSB0aGF0IHRoZSBkb2N1bWVu
dCB3YXMganVzdCByZWlzc3VlZC4gU2VjdGlvbiAzIGhhcyBiZWVuIGVkaXRlZCB0bw0KPj4gcmVt
b3ZlIHNvbWUgb2YgdGhlIHRleHQgd2FzIGRlZW1lZCB0byBiZSBlbmNyb2FjaGluZyBvbg0KPj4g
YXJjaGl0ZWN0dXJlLiBZb3UgY2FuIHNlZSB0aGUgY2hhbmdlcyBhdA0KPj4gaHR0cDovL3Rvb2xz
LmlldGYub3JnL3dnL3NmYy9kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC9kcmFmdC1p
ZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNy1mcm9tLTA2LmRpZmYuaHRtbA0KPj4NCj4+IFdp
dGggdGhhdCwgd2UgYXJlIHJlc3RhcnRpbmcgYSAyLXdlZWsgV0dMQyBvbiB0aGUgZG9jdW1lbnQu
IFdlDQo+PiBzcGVjaWZpY2FsbHkgbmVlZCB0byBzZWUgc3VmZmljaWVudCBpbmRpY2F0aW9ucyBm
cm9tIFdHIG1lbWJlcnMgdGhhdA0KPj4gdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGFkdmFuY2Us
IGFuZCB0aGF0IHRoZSBkb2N1bWVudCBkb2VzIG5vdA0KPj4gY29udGFpbiBzaWduaWZpY2FudCBk
ZWZpY2llbmNpZXMuDQo+Pg0KPj4gVGhvbWFzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0Bp
ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4N
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2Zj
IG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9zZmMNCg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv
ciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8v
cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDog
ICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug
ZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61v
IHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRv
IG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0
cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMg
b2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rp
c2NsYWltZXIuYXNweA0K


From nobody Thu Jun 26 08:35:10 2014
Return-Path: <repenno@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74671B3105 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4xhPizjrCsg for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:35:04 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DF41B3131 for <sfc@ietf.org>; Thu, 26 Jun 2014 07:40:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3525; q=dns/txt; s=iport; t=1403793645; x=1405003245; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1anqxFj3UUn5TTUJmKh7tB9Gt8zhr1C2dcm4AbJMw/A=; b=AMjnEd4WPw25ONVzrUKAISwaUsCdvbAPj5lePs9C3Zxq3HBYGlrYSc4r BvoiXaeTR47KqPsMTWln/tFuuH0q0TyQCsz4yGIHde9nhArvA80RhWVoV xecW3YycUlFsd6EJw5QTxF6NwU3SAzpxBso3yNy74zPIUkr1Gpe7tPteQ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigJABYwrFOtJV2S/2dsb2JhbABagw1SWqocAQEBAQEBBQFskS2Dd4NJAYEMFnWEAwEBAQQBAQFrCxIBCBIGVQsXDgIEAQ0FiEINwxoXhWSIaTMHhEMFigyQTIFGkimDQoIw
X-IronPort-AV: E=Sophos;i="5.01,553,1400025600"; d="scan'208";a="56186158"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 26 Jun 2014 14:40:44 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5QEehSr013207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 14:40:43 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 09:40:43 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Paul Quinn (paulq)" <paulq@cisco.com>, Thomas Narten <narten@us.ibm.com>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmY2GzMEM1YrUSzZ89YzxwzcZuDuVsA//+dBIA=
Date: Thu, 26 Jun 2014 14:40:43 +0000
Message-ID: <CFD1786C.C99A%repenno@cisco.com>
In-Reply-To: <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@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.21.150.65]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <BB4173335BE00A45BCE9EA3DB1E1D28B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XULbpgv_eXjoAULcSYynL0REjV0
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 15:35:08 -0000

Hello,

I think the document needs editing and clarification before moving
forward. Many sub-sections seems redundant and intertwined.

Comment 1:

Section 2.1, 2.2, 2.4, 2.7 and 2.8 are  talking about the same root
problem: configuration complexity.

2.1, 2.4, 2.7 and 2.8 are consequences of 2.2 and not really a problem
statement in itself. At least that=B9s how I see it. If you solve
configuration complexity, the others will consequently be solved.

I think it is worth to maintain the discussion but not as a separate
problem space, they should be under =B3Configuration complexity=B2 sub-sect=
ion.

Some snippets to the point:

Section 2.1

"resulting in complex network changes and device configuration."

Section 2.4

"Service function chains today are most typically built through manual
   configuration processes.  These are slow and error prone."


Section 2.7

"rapid
   changes to the service deployment can be hard to realize due to the
   risk and complexity of such changes.
=B3

Section 2.8

"This
   results in operationally complex configurations and is still
   relatively inflexible."


These are all basically saying that today configuration is complex and
manual and automatic configuration would be a great idea.


Comment 2:

Section 2.6 seems a executive summary of parts of section 2.1 since the
tying service function to topology you are saying service function must
understand that transport.

"The coupling of service
   functions to topology requires service functions to support many
   transport encapsulations or for a transport gateway function to be
   present.=B2


Comment 3:

I have trouble parsing this sentence.


"Since traffic reaches many service functions based on network
   topology, alternate, or redundant service functions must be placed in
   the same topology as the primary service.=B2



On 6/26/14, 6:35 AM, "Paul Quinn (paulq)" <paulq@cisco.com> wrote:

>Thomas,
>
>As an editor: I support moving this draft forward.
>
>Paul
>
>On Jun 25, 2014, at 3:13 PM, Thomas Narten <narten@us.ibm.com> wrote:
>
>> Hi.
>>=20
>> We ran a WGLC on the problem statement draft
>> (draft-ietf-sfc-problem-statement-07.txt) back in May.
>> Although the draft received significant review and support prior to
>> the formal LC, the actual last call resulted largely in silence.
>>=20
>> While it would be convenient to take silence as acceptance, that's not
>> good enough. To show the document is ready, we need WG members to
>> speak up and indicate they have read a recent version of the document
>> and think its ready to go.
>>=20
>> Note that the document was just reissued. Section 3 has been edited to
>> remove some of the text was deemed to be encroaching on
>> architecture. You can see the changes at
>>=20
>>http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-
>>sfc-problem-statement-07-from-06.diff.html
>>=20
>> With that, we are restarting a 2-week WGLC on the document. We
>> specifically need to see sufficient indications from WG members that
>> the document is ready to advance, and that the document does not
>> contain significant deficiencies.
>>=20
>> Thomas
>>=20
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc


From nobody Thu Jun 26 08:48:12 2014
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584BA1B28E4 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waNHfUu380Fj for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:47:59 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978091B28F5 for <sfc@ietf.org>; Thu, 26 Jun 2014 07:50:36 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id B0B502ACC4A; Thu, 26 Jun 2014 16:50:34 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 71A4E158063; Thu, 26 Jun 2014 16:50:34 +0200 (CEST)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 26 Jun 2014 16:50:33 +0200
From: <mohamed.boucadair@orange.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, JACQUENET Christian IMT/OLN <christian.jacquenet@orange.com>, Jiangyuanlong <jiangyuanlong@huawei.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: Suggestions to "draft-boucadair-sfc-requirements-04"
Thread-Index: Ac+ASSw6EqtHtNzASnqrgNUnvnRaZQP1xq1QAEtbEGA=
Date: Thu, 26 Jun 2014 14:50:32 +0000
Message-ID: <94e3ad39-feb7-49ea-9f30-7b6985026936@OPEXCLILH01.corporate.adroot.infra.ftgroup>
References: <4A95BA014132FF49AE685FAB4B9F17F645D2E2D7@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D6B87A@dfweml701-chm.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D6B87A@dfweml701-chm.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_94e3ad39feb749ea9f307b6985026936OPEXCLILH01corporateadr_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.26.130917
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rdRtaocHTnidqdNqZoNXFd8SEeA
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04"
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 15:48:09 -0000

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

Hi Linda,

Thank you very much for your review.

Your suggestion to group the requirements looks good to me. I'm currently w=
orking on a revision to implement this change.

Cheers,
Med

De : Linda Dunbar [mailto:linda.dunbar@huawei.com]
Envoy=E9 : mercredi 25 juin 2014 19:18
=C0 : BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; Jiangyuanlong=
; Ron Parker; Carlos Pignataro (cpignata)
Cc : sfc@ietf.org
Objet : RE: Suggestions to "draft-boucadair-sfc-requirements-04"

Mohamed, et al,

When you get a chance, can you address those suggestions?

Linda


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, June 04, 2014 6:03 PM
To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; chri=
stian.jacquenet@orange.com<mailto:christian.jacquenet@orange.com>; Jiangyua=
nlong; Ron Parker; Carlos Pignataro (cpignata)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04"

Mohamed, et al,

The draft-boucadair-sfc-requirements-04 has all the requirements lumped tog=
ether, making it difficult for people to validate and provide comments.

I think that it is beneficial to create multiple categories of requirements=
. So each category can be reviewed and validated more intensively.

With this in mind, I took the first stab of breaking the requirements in th=
e draft to multiple categories.  I didn't change the order of your original=
 ones, but shuffled them around, so that similar ones are put under one sub=
-section. I also added some comments for the requirements that I don't thin=
k make sense.

I only added a few new requirements, however, I didn't add any new requirem=
ent numbers.

I suggest each sub-section has its own numbering scheme, such as "OAM-1, 2,=
 ..", so that any addition or deletion within one sub-section won't affect =
other sections.

Please see the attached with the changes marked.

Linda

--_000_94e3ad39feb749ea9f307b6985026936OPEXCLILH01corporateadr_
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=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<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: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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Texte de bulles Car";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.TextedebullesCar
	{mso-style-name:"Texte de bulles Car";
	mso-style-priority:99;
	mso-style-link:"Texte de bulles";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{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 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"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;;color:#993366">Hi Linda,<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:#993366"><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;;color:#993366">Thank you very much for your review.
<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:#993366"><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;;color:#993366">Your suggestion to group the requirements lo=
oks good to me. I&#8217;m currently working on a revision to implement this=
 change.<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:#993366"><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;;color:#993366">Cheers,<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:#993366">Med<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:#993366"><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>
<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"FR" style=3D"font-size:10.0pt;font-=
family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">De&nbsp;:</span></b><span=
 lang=3D"FR" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;"> Linda Dunbar [mailto:linda.dunbar@huawei.com]
<br>
<b>Envoy=E9&nbsp;:</b> mercredi 25 juin 2014 19:18<br>
<b>=C0&nbsp;:</b> BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; J=
iangyuanlong; Ron Parker; Carlos Pignataro (cpignata)<br>
<b>Cc&nbsp;:</b> sfc@ietf.org<br>
<b>Objet&nbsp;:</b> RE: Suggestions to &quot;draft-boucadair-sfc-requiremen=
ts-04&quot;<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"color:#1F497D">Mohamed, et al, <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">When you get a chance,=
 can you address those suggestions?
<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">Linda <o:p></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"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></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 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;"> sfc [<a =
href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Linda Dunbar<br>
<b>Sent:</b> Wednesday, June 04, 2014 6:03 PM<br>
<b>To:</b> <a href=3D"mailto:mohamed.boucadair@orange.com">mohamed.boucadai=
r@orange.com</a>;
<a href=3D"mailto:christian.jacquenet@orange.com">christian.jacquenet@orang=
e.com</a>; Jiangyuanlong; Ron Parker; Carlos Pignataro (cpignata)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> [sfc] Suggestions to &quot;draft-boucadair-sfc-requirements=
-04&quot;<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<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 draft-boucadair-sfc-requirements-04 has all the =
requirements lumped together, making it difficult for people to validate an=
d provide comments.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I think that it is beneficial to create multiple cat=
egories of requirements. So each category can be reviewed and validated mor=
e intensively.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">With this in mind, I took the first stab of breaking=
 the requirements in the draft to multiple categories.&nbsp; I didn&#8217;t=
 change the order of your original ones, but shuffled them around, so that =
similar ones are put under one sub-section. I
 also added some comments for the requirements that I don&#8217;t think mak=
e sense. <o:p>
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I only added a few new requirements, however, I didn=
&#8217;t add any new requirement numbers.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I suggest each sub-section has its own numbering sch=
eme, such as &#8220;OAM-1, 2, ..&#8221;, so that any addition or deletion w=
ithin one sub-section won&#8217;t affect other sections.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Please see the attached with the changes marked. <o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Linda <o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_94e3ad39feb749ea9f307b6985026936OPEXCLILH01corporateadr_--


From nobody Thu Jun 26 08:58:13 2014
Return-Path: <tnadeau@lucidvision.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4751B2BDB for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7HC6ZX0Rr4c for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 08:58:08 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 183081B31F8 for <sfc@ietf.org>; Thu, 26 Jun 2014 07:59:53 -0700 (PDT)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 3B0F227F8DE1; Thu, 26 Jun 2014 10:59:52 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_654EE2FE-EE2F-4789-B14F-D188EF34155A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
In-Reply-To: <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
Date: Thu, 26 Jun 2014 10:59:25 -0400
Message-Id: <A4F56D41-DAA9-4523-9927-22EAFE9771F9@lucidvision.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com> <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
To: "Paul (paulq) Quinn" <paulq@cisco.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XIpoHtFMtKOms5Zms6HuJSP_puA
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 15:58:11 -0000

--Apple-Mail=_654EE2FE-EE2F-4789-B14F-D188EF34155A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	Same here.

	--Tom

On Jun 26, 2014:9:35 AM, at 9:35 AM, Paul Quinn (paulq) =
<paulq@cisco.com> wrote:

> Thomas,
>=20
> As an editor: I support moving this draft forward.
>=20
> Paul
>=20
> On Jun 25, 2014, at 3:13 PM, Thomas Narten <narten@us.ibm.com> wrote:
>=20
>> Hi.
>>=20
>> We ran a WGLC on the problem statement draft
>> (draft-ietf-sfc-problem-statement-07.txt) back in May.
>> Although the draft received significant review and support prior to
>> the formal LC, the actual last call resulted largely in silence.
>>=20
>> While it would be convenient to take silence as acceptance, that's =
not
>> good enough. To show the document is ready, we need WG members to
>> speak up and indicate they have read a recent version of the document
>> and think its ready to go.
>>=20
>> Note that the document was just reissued. Section 3 has been edited =
to
>> remove some of the text was deemed to be encroaching on
>> architecture. You can see the changes at
>> =
http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-s=
fc-problem-statement-07-from-06.diff.html
>>=20
>> With that, we are restarting a 2-week WGLC on the document. We
>> specifically need to see sufficient indications from WG members that
>> the document is ready to advance, and that the document does not
>> contain significant deficiencies.
>>=20
>> Thomas
>>=20
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>=20


--Apple-Mail=_654EE2FE-EE2F-4789-B14F-D188EF34155A
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 - https://gpgtools.org

iQIcBAEBCgAGBQJTrDVOAAoJEPcO+I7eiUJZwKgP/2wXn8251mni9TFFGQ3kMmvb
2S23EikWJ1QxkJyIvmla6bEKKosL/hOK1OcWSxiTXfUXmrLTCyeBlAMIJco5iin3
9qv9ZDMFA0eR63EwC0RUL1qE+Hk4e42++Gv6lwJ7XtlCurTu1IP/Wyc//fVFN+G1
fdgIT1lePQdQsfmmKZb4AEieQYtB5kb5aAc4fCqHQIlx+LWvNMqoG1UwBOSc/1O2
2hzBT0wD0AtyWKp4K3BdRoWv8dNAPk8nsrKnc18SRFXNwFFuE3qNhRfMG6Tl8Bl/
8rMGRgiu7erzZf50TvUzKYGRT/r8MfYb5NErefD95JiVO2bDYaGJiOVCFW383bF9
NzAc/ME6V4kyKsKMqdDZT7lP6AcelMe2CZK/Io0EzwxofS67WmBOtamMC71OFXb/
prq+CDxHTVxBU6YuZ+d/PdJr0o4e/D9aO4Pd3VtclG5gz6pIhRwANRV4blF9ztBU
jDiMF+sj+1SBX612anbEmJghhfk75H6bbR6bwtlKHQMyOrpo6QuoQRH0yQgq/V1F
gTbqkzr7w1IeThtTCP5lJ9cO07IBch9UR1zll0bbWtH7J60Fb84l1zNzSsar3zIS
kcsDlmkw/unZupApIdnUOYWzZ3mXP2gHpLyTVzymPUd8XR13xGvRKTiufB3uom+f
Yo9qSgkaI0mwLpdjPvma
=rPgx
-----END PGP SIGNATURE-----

--Apple-Mail=_654EE2FE-EE2F-4789-B14F-D188EF34155A--


From nobody Thu Jun 26 09:05:37 2014
Return-Path: <smkumar@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015241B2D90 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 09:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS58W2E4D3bL for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 09:05:20 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7B41B2DBA for <sfc@ietf.org>; Thu, 26 Jun 2014 08:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1670; q=dns/txt; s=iport; t=1403795393; x=1405004993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4tp8hm5IyOpXqAwzcRA2PXR010ltoFLXxTk6FU5knWo=; b=QVO5sKTx/hNALP1W4JBMSRtWApURgvvZknnUb819UpqL23txeH6dOftR r9DEoxrtCsIiLDKIn/jIOeAUYdTrX50v73mr08320+a6w7ac1ij8ZlrM9 7Atc6XIglQqhTrNx0KVXOOUaLHsfnN1N2HReGgN6wfKbX+/S19OwvihiK I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am8GAB43rFOtJA2F/2dsb2JhbABagw1SWqocAQEBAQEBBQFskS2HQAGBDBZ1hAMBAQEEAQEBNzQLEAIBCBIGHhAnCxcOAgQBDQWIQg3DCBeFZIkcB4RDBZpYgUaSKYNCgjA
X-IronPort-AV: E=Sophos;i="5.01,553,1400025600"; d="scan'208";a="335836735"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jun 2014 15:09:52 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5QF9q5I005138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 15:09:52 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.78]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 10:09:51 -0500
From: "Surendra Kumar (smkumar)" <smkumar@cisco.com>
To: "Paul Quinn (paulq)" <paulq@cisco.com>, Thomas Narten <narten@us.ibm.com>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKoIOpqgdyeRNkWqEozErVhdM5uDuV0A//+lIQA=
Date: Thu, 26 Jun 2014 15:09:51 +0000
Message-ID: <CFD18575.49697%smkumar@cisco.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com> <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
In-Reply-To: <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.2.140509
x-originating-ip: [10.21.74.76]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <841A41A64F0AF14581B52D755BFD5B98@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Stm9Ek9yzKylgVbW9vEhKUapq_E
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 16:05:28 -0000

As a co-author, I support advancing the draft.

Surendra.

On 6/26/14 6:35 AM, "Paul Quinn (paulq)" <paulq@cisco.com> wrote:

>Thomas,
>
>As an editor: I support moving this draft forward.
>
>Paul
>
>On Jun 25, 2014, at 3:13 PM, Thomas Narten <narten@us.ibm.com> wrote:
>
>> Hi.
>>=20
>> We ran a WGLC on the problem statement draft
>> (draft-ietf-sfc-problem-statement-07.txt) back in May.
>> Although the draft received significant review and support prior to
>> the formal LC, the actual last call resulted largely in silence.
>>=20
>> While it would be convenient to take silence as acceptance, that's not
>> good enough. To show the document is ready, we need WG members to
>> speak up and indicate they have read a recent version of the document
>> and think its ready to go.
>>=20
>> Note that the document was just reissued. Section 3 has been edited to
>> remove some of the text was deemed to be encroaching on
>> architecture. You can see the changes at
>>=20
>>http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-
>>sfc-problem-statement-07-from-06.diff.html
>>=20
>> With that, we are restarting a 2-week WGLC on the document. We
>> specifically need to see sufficient indications from WG members that
>> the document is ready to advance, and that the document does not
>> contain significant deficiencies.
>>=20
>> Thomas
>>=20
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc


From nobody Thu Jun 26 09:08:46 2014
Return-Path: <Ron_Parker@affirmednetworks.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149C71B2C62 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 09:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOAj7gungwta for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 09:08:37 -0700 (PDT)
Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC1B1B2E12 for <sfc@ietf.org>; Thu, 26 Jun 2014 08:13:58 -0700 (PDT)
Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 9E9C253E27; Thu, 26 Jun 2014 08:13:46 -0700 (PDT)
MIME-Version: 1.0
x-echoworx-emg-received: Thu, 26 Jun 2014 08:13:46.595 -0700
x-echoworx-msg-id: f296e207-9288-4644-92de-4fd88d8c66ed
x-echoworx-action: delivered
Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 247; Thu, 26 Jun 2014 08:13:46 -0700 (PDT)
Received: from HUB021-CA-8.exch021.domain.local (unknown [10.254.4.112]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 7A22953E27; Thu, 26 Jun 2014 08:13:46 -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.0174.001; Thu, 26 Jun 2014 08:13:57 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Linda Dunbar" <linda.dunbar@huawei.com>, JACQUENET Christian IMT/OLN <christian.jacquenet@orange.com>, Jiangyuanlong <jiangyuanlong@huawei.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: Suggestions to "draft-boucadair-sfc-requirements-04"
Thread-Index: Ac+ASSw6EqtHtNzASnqrgNUnvnRaZQP1xq1QAEtbEGAAAN84kA==
Date: Thu, 26 Jun 2014 15:13:57 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8A3EA4@MBX021-W3-CA-2.exch021.domain.local>
References: <4A95BA014132FF49AE685FAB4B9F17F645D2E2D7@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D6B87A@dfweml701-chm.china.huawei.com> <94e3ad39-feb7-49ea-9f30-7b6985026936@OPEXCLILH01.corporate.adroot.infra.ftgroup>
In-Reply-To: <94e3ad39-feb7-49ea-9f30-7b6985026936@OPEXCLILH01.corporate.adroot.infra.ftgroup>
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_CDF2F015F4429F458815ED2A6C2B6B0B1A8A3EA4MBX021W3CA2exch_"
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7-Yz5yoGgrGX4n7eB-nHI6xv0c8
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04"
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 16:08:41 -0000

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

Med,

I'll be happy to review when you complete these changes.

   Ron


From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, June 26, 2014 10:51 AM
To: Linda Dunbar; JACQUENET Christian IMT/OLN; Jiangyuanlong; Ron Parker; C=
arlos Pignataro (cpignata)
Cc: sfc@ietf.org
Subject: RE: Suggestions to "draft-boucadair-sfc-requirements-04"

Hi Linda,

Thank you very much for your review.

Your suggestion to group the requirements looks good to me. I'm currently w=
orking on a revision to implement this change.

Cheers,
Med

De : Linda Dunbar [mailto:linda.dunbar@huawei.com]
Envoy=E9 : mercredi 25 juin 2014 19:18
=C0 : BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; Jiangyuanlong=
; Ron Parker; Carlos Pignataro (cpignata)
Cc : sfc@ietf.org<mailto:sfc@ietf.org>
Objet : RE: Suggestions to "draft-boucadair-sfc-requirements-04"

Mohamed, et al,

When you get a chance, can you address those suggestions?

Linda


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, June 04, 2014 6:03 PM
To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; chri=
stian.jacquenet@orange.com<mailto:christian.jacquenet@orange.com>; Jiangyua=
nlong; Ron Parker; Carlos Pignataro (cpignata)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04"

Mohamed, et al,

The draft-boucadair-sfc-requirements-04 has all the requirements lumped tog=
ether, making it difficult for people to validate and provide comments.

I think that it is beneficial to create multiple categories of requirements=
. So each category can be reviewed and validated more intensively.

With this in mind, I took the first stab of breaking the requirements in th=
e draft to multiple categories.  I didn't change the order of your original=
 ones, but shuffled them around, so that similar ones are put under one sub=
-section. I also added some comments for the requirements that I don't thin=
k make sense.

I only added a few new requirements, however, I didn't add any new requirem=
ent numbers.

I suggest each sub-section has its own numbering scheme, such as "OAM-1, 2,=
 ..", so that any addition or deletion within one sub-section won't affect =
other sections.

Please see the attached with the changes marked.

Linda

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8A3EA4MBX021W3CA2exch_
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=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
=09{font-family:"Cambria Math";
=09panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
=09{font-family:Calibri;
=09panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
=09{font-family:"Segoe UI";
=09panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
=09{font-family:Tahoma;
=09panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
=09{margin:0in;
=09margin-bottom:.0001pt;
=09font-size:11.0pt;
=09font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
=09{mso-style-priority:99;
=09color:blue;
=09text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
=09{mso-style-priority:99;
=09color:purple;
=09text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
=09{mso-style-priority:99;
=09mso-style-link:"Balloon Text Char";
=09margin:0in;
=09margin-bottom:.0001pt;
=09font-size:8.0pt;
=09font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
=09{mso-style-name:"Balloon Text Char";
=09mso-style-priority:99;
=09mso-style-link:"Balloon Text";
=09font-family:"Segoe UI","sans-serif";}
span.EmailStyle19
=09{mso-style-type:personal;
=09font-family:"Calibri","sans-serif";
=09color:windowtext;}
span.EmailStyle20
=09{mso-style-type:personal;
=09font-family:"Calibri","sans-serif";
=09color:#1F497D;}
p.Textedebulles, li.Textedebulles, div.Textedebulles
=09{mso-style-name:"Texte de bulles";
=09mso-style-link:"Texte de bulles Car";
=09margin:0in;
=09margin-bottom:.0001pt;
=09font-size:11.0pt;
=09font-family:"Calibri","sans-serif";}
span.TextedebullesCar
=09{mso-style-name:"Texte de bulles Car";
=09mso-style-priority:99;
=09mso-style-link:"Texte de bulles";
=09font-family:"Tahoma","sans-serif";}
span.EmailStyle23
=09{mso-style-type:personal;
=09font-family:"Courier New";
=09color:#993366;}
span.EmailStyle24
=09{mso-style-type:personal-reply;
=09font-family:"Calibri","sans-serif";
=09color:#1F497D;}
.MsoChpDefault
=09{mso-style-type:export-only;
=09font-size:10.0pt;}
@page WordSection1
=09{size:8.5in 11.0in;
=09margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
=09{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"color:#1F497D">Med,<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">I&#8217;ll be happy to=
 review when you complete these changes.<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">&nbsp;&nbsp; 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"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b>From:</b> mohamed.boucadair@orange.com [mailto:mo=
hamed.boucadair@orange.com]
<br>
<b>Sent:</b> Thursday, June 26, 2014 10:51 AM<br>
<b>To:</b> Linda Dunbar; JACQUENET Christian IMT/OLN; Jiangyuanlong; Ron Pa=
rker; Carlos Pignataro (cpignata)<br>
<b>Cc:</b> sfc@ietf.org<br>
<b>Subject:</b> RE: Suggestions to &quot;draft-boucadair-sfc-requirements-0=
4&quot;<o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
urier New&quot;;color:#993366">Hi Linda,<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:#993366"><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;;color:#993366">Thank you very much for your review.
<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:#993366"><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;;color:#993366">Your suggestion to group the requirements lo=
oks good to me. I&#8217;m currently working on a revision to implement this=
 change.<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:#993366"><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;;color:#993366">Cheers,<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:#993366">Med<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:#993366"><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 lang=3D"FR" style=3D"font-size:10.0pt;font-=
family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">De&nbsp;:</span></b><span=
 lang=3D"FR" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;"> Linda Dunbar [<a href=3D"mailto:linda.dunbar@huawei.com=
">mailto:linda.dunbar@huawei.com</a>]
<br>
<b>Envoy=E9&nbsp;:</b> mercredi 25 juin 2014 19:18<br>
<b>=C0&nbsp;:</b> BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; J=
iangyuanlong; Ron Parker; Carlos Pignataro (cpignata)<br>
<b>Cc&nbsp;:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Objet&nbsp;:</b> RE: Suggestions to &quot;draft-boucadair-sfc-requiremen=
ts-04&quot;<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"color:#1F497D">Mohamed, et al, <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">When you get a chance,=
 can you address those suggestions?
<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">Linda <o:p></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"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></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;"> sfc [<a =
href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>]
<b>On Behalf Of </b>Linda Dunbar<br>
<b>Sent:</b> Wednesday, June 04, 2014 6:03 PM<br>
<b>To:</b> <a href=3D"mailto:mohamed.boucadair@orange.com">mohamed.boucadai=
r@orange.com</a>;
<a href=3D"mailto:christian.jacquenet@orange.com">christian.jacquenet@orang=
e.com</a>; Jiangyuanlong; Ron Parker; Carlos Pignataro (cpignata)<br>
<b>Cc:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<b>Subject:</b> [sfc] Suggestions to &quot;draft-boucadair-sfc-requirements=
-04&quot;<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<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 draft-boucadair-sfc-requirements-04 has all the =
requirements lumped together, making it difficult for people to validate an=
d provide comments.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I think that it is beneficial to create multiple cat=
egories of requirements. So each category can be reviewed and validated mor=
e intensively.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">With this in mind, I took the first stab of breaking=
 the requirements in the draft to multiple categories.&nbsp; I didn&#8217;t=
 change the order of your original ones, but shuffled them around, so that =
similar ones are put under one sub-section. I
 also added some comments for the requirements that I don&#8217;t think mak=
e sense. <o:p>
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I only added a few new requirements, however, I didn=
&#8217;t add any new requirement numbers.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I suggest each sub-section has its own numbering sch=
eme, such as &#8220;OAM-1, 2, ..&#8221;, so that any addition or deletion w=
ithin one sub-section won&#8217;t affect other sections.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Please see the attached with the changes marked. <o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Linda <o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8A3EA4MBX021W3CA2exch_--


From nobody Thu Jun 26 09:17:01 2014
Return-Path: <ramk@Brocade.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA091B2FF9 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 09:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJYJdpkB4boU for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 09:16:58 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC841B304A for <sfc@ietf.org>; Thu, 26 Jun 2014 08:26:41 -0700 (PDT)
Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s5QFOnHD016370; Thu, 26 Jun 2014 08:26:40 -0700
Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1mrnya80a3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Jun 2014 08:26:40 -0700
Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Jun 2014 08:26:39 -0700
Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Thu, 26 Jun 2014 08:26:39 -0700
From: ramki Krishnan <ramk@Brocade.com>
To: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Date: Thu, 26 Jun 2014 08:26:39 -0700
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: Ac+QqZdAioJuAYoSRVux9Tp68jbqEAAqWqqw
Message-ID: <C7634EB63EFD984A978DFB46EA5174F2C14FDB8172@HQ1-EXCH01.corp.brocade.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
In-Reply-To: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14,  0.0.0000 definitions=2014-06-26_05:2014-06-26,2014-06-26,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406260155
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OkwZEq7CZadD6GwcBEJzbu2XCmU
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 16:17:00 -0000

Support.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten
Sent: Wednesday, June 25, 2014 12:14 PM
To: sfc@ietf.org
Subject: [sfc] 2nd WG Last Call on Problem Statement

Hi.

We ran a WGLC on the problem statement draft
(draft-ietf-sfc-problem-statement-07.txt) back in May.
Although the draft received significant review and support prior to the for=
mal LC, the actual last call resulted largely in silence.

While it would be convenient to take silence as acceptance, that's not good=
 enough. To show the document is ready, we need WG members to speak up and =
indicate they have read a recent version of the document and think its read=
y to go.

Note that the document was just reissued. Section 3 has been edited to remo=
ve some of the text was deemed to be encroaching on architecture. You can s=
ee the changes at http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-state=
ment/draft-ietf-sfc-problem-statement-07-from-06.diff.html

With that, we are restarting a 2-week WGLC on the document. We specifically=
 need to see sufficient indications from WG members that the document is re=
ady to advance, and that the document does not contain significant deficien=
cies.

Thomas

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


From nobody Thu Jun 26 13:27:28 2014
Return-Path: <Kevin.Glavin@riverbed.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0E11B2DCC for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 13:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYaUisxLVpSG for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 13:27:25 -0700 (PDT)
Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id E1E6D1B2E24 for <sfc@ietf.org>; Thu, 26 Jun 2014 13:27:25 -0700 (PDT)
Received: from unknown (HELO 365EXCH-HUB-P3.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 26 Jun 2014 13:27:25 -0700
Received: from SFO1EXC-MBXP11.nbttech.com ([fe80::835:f956:5315:225c]) by 365EXCH-HUB-P3.nbttech.com ([::1]) with mapi id 14.02.0328.009; Thu, 26 Jun 2014 13:27:25 -0700
From: Kevin Glavin <Kevin.Glavin@riverbed.com>
To: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmWbxldHwLLP0a3VvXrDLKhbZuD2L+A
Date: Thu, 26 Jun 2014 20:27:24 +0000
Message-ID: <9EA32E60D7600C43B6FE22876DF564C857ECD39A@sfo1exc-mbxp11.nbttech.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
In-Reply-To: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.16.205.250]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <85D73ABA49BC714D87E9563644954E0E@riverbed.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IyWdihVMIpkA_-zwcS9bADRohwU
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 20:27:27 -0000

As a contributor to the draft, I support it advancing.


Kevin


On 6/25/14 12:13 PM, "Thomas Narten" <narten@us.ibm.com> wrote:

>Hi.
>
>We ran a WGLC on the problem statement draft
>(draft-ietf-sfc-problem-statement-07.txt) back in May.
>Although the draft received significant review and support prior to
>the formal LC, the actual last call resulted largely in silence.
>
>While it would be convenient to take silence as acceptance, that's not
>good enough. To show the document is ready, we need WG members to
>speak up and indicate they have read a recent version of the document
>and think its ready to go.
>
>Note that the document was just reissued. Section 3 has been edited to
>remove some of the text was deemed to be encroaching on
>architecture. You can see the changes at
>http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-s
>fc-problem-statement-07-from-06.diff.html
>
>With that, we are restarting a 2-week WGLC on the document. We
>specifically need to see sufficient indications from WG members that
>the document is ready to advance, and that the document does not
>contain significant deficiencies.
>
>Thomas
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc


From nobody Thu Jun 26 14:11:07 2014
Return-Path: <Myo.Zarny@gs.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502EB1A02A8 for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 14:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level: 
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwmV72k_Dw3P for <sfc@ietfa.amsl.com>; Thu, 26 Jun 2014 14:10:57 -0700 (PDT)
Received: from mxecd05.gs.com (mxe1.gs.com [204.4.187.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A931A028F for <sfc@ietf.org>; Thu, 26 Jun 2014 14:10:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.01,555,1400040000"; d="scan'208";a="48447891"
Received: from unknown (HELO mxpbd01-public.ny.fw.gs.com) ([148.86.115.129]) by mxecd05.idz.gs.com with ESMTP; 26 Jun 2014 17:10:56 -0400
From: "Zarny, Myo" <Myo.Zarny@gs.com>
X-sendergroup: RELAYLIST
Received: from gshcbdp12ex.firmwide.corp.gs.com ([10.135.172.21]) by mxpbd01.ny.fw.gs.com with ESMTP; 26 Jun 2014 17:10:56 -0400
Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp12ex.firmwide.corp.gs.com ([10.135.172.21]) with mapi; Thu, 26 Jun 2014 17:10:56 -0400
To: 'Thomas Narten' <narten@us.ibm.com>, "'sfc@ietf.org'" <sfc@ietf.org>
Date: Thu, 26 Jun 2014 17:10:54 -0400
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: Ac+QqZcku5cHscstQFyJ3r/z5S98xAA2YBjA
Message-ID: <A3233753A4B65F43BCA1B64DA99A9C230708D662EF@GSCMAMP19EX.firmwide.corp.gs.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
In-Reply-To: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-retentionstamp: Firmwide
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wfCTyG8fdDcnCeunYATm9m84514
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 21:11:04 -0000

Support.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten
Sent: 25 June 2014 3:14 PM
To: sfc@ietf.org
Subject: [sfc] 2nd WG Last Call on Problem Statement

Hi.

We ran a WGLC on the problem statement draft
(draft-ietf-sfc-problem-statement-07.txt) back in May.
Although the draft received significant review and support prior to the for=
mal LC, the actual last call resulted largely in silence.

While it would be convenient to take silence as acceptance, that's not good=
 enough. To show the document is ready, we need WG members to speak up and =
indicate they have read a recent version of the document and think its read=
y to go.

Note that the document was just reissued. Section 3 has been edited to remo=
ve some of the text was deemed to be encroaching on architecture. You can s=
ee the changes at http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-state=
ment/draft-ietf-sfc-problem-statement-07-from-06.diff.html

With that, we are restarting a 2-week WGLC on the document. We specifically=
 need to see sufficient indications from WG members that the document is re=
ady to advance, and that the document does not contain significant deficien=
cies.

Thomas

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


From nobody Fri Jun 27 11:52:47 2014
Return-Path: <darlewis@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CA21B29B5 for <sfc@ietfa.amsl.com>; Fri, 27 Jun 2014 11:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqI5myDjkq-3 for <sfc@ietfa.amsl.com>; Fri, 27 Jun 2014 11:52:37 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D3C1B2967 for <sfc@ietf.org>; Fri, 27 Jun 2014 11:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1384; q=dns/txt; s=iport; t=1403895157; x=1405104757; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rNglZs1rApukojkShaGYUY+DkCNsEGvT8N9+deUUjQE=; b=LIw5/w1JIh4u2EF70vYbN4cofSxgXzH69EHSIgDsBoOOtXVP0/yVLkn9 N6wF7QT+zQepJI73QlqtF8Q1AsiPDCdBzpuUC/OdTwjpOpdE9mXqpig7D PlLb7bWhtXTV8eep0ibPcIOl6fGSs4wuUMM8B44tb35/NdU4BqxI5HPlc o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqwFAHq8rVOtJA2B/2dsb2JhbABagw1SWqo/AQEBAQEBBQFtAZFCh0ABgQ0WdYQDAQEBAwEBAQE3NAsFCwIBCBIkECcLFw4CBA4FiDoIDcQCF4VkiG4zB4MtgRYFml2BRpI1g0JsAYFD
X-IronPort-AV: E=Sophos;i="5.01,562,1400025600"; d="scan'208";a="56546054"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 27 Jun 2014 18:52:37 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5RIqatg026277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 18:52:36 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.61]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 13:52:36 -0500
From: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
To: Thomas Narten <narten@us.ibm.com>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkjj1Gt0xx2EpGkC2RCM3ztpXcQ==
Date: Fri, 27 Jun 2014 18:52:35 +0000
Message-ID: <F8A2F1A4-D4A1-4351-B67E-AB2305A5D69C@cisco.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
In-Reply-To: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.253.184]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <88C468BA429BF74EA27D1A8C8D611D65@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dTjwS3pJNySnumfh7qyoUPIAKjA
Cc: "Darrel Lewis \(darlewis\)" <darlewis@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jun 2014 18:52:39 -0000

I have read this document, I think it is ready, and support its publication=
.

-Darrel
On Jun 25, 2014, at 12:13 PM, Thomas Narten <narten@us.ibm.com> wrote:

> Hi.
>=20
> We ran a WGLC on the problem statement draft
> (draft-ietf-sfc-problem-statement-07.txt) back in May.
> Although the draft received significant review and support prior to
> the formal LC, the actual last call resulted largely in silence.
>=20
> While it would be convenient to take silence as acceptance, that's not
> good enough. To show the document is ready, we need WG members to
> speak up and indicate they have read a recent version of the document
> and think its ready to go.
>=20
> Note that the document was just reissued. Section 3 has been edited to
> remove some of the text was deemed to be encroaching on
> architecture. You can see the changes at
> http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-=
sfc-problem-statement-07-from-06.diff.html
>=20
> With that, we are restarting a 2-week WGLC on the document. We
> specifically need to see sufficient indications from WG members that
> the document is ready to advance, and that the document does not
> contain significant deficiencies.
>=20
> Thomas
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


From nobody Mon Jun 30 05:25:09 2014
Return-Path: <kegray@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9464D1A02BD for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 05:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqWSw27xZpns for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 05:25:05 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3731A0295 for <sfc@ietf.org>; Mon, 30 Jun 2014 05:25:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1673; q=dns/txt; s=iport; t=1404131105; x=1405340705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lSp3emz9khrxnb6B7LthQPVMSwBGUBGVAW2eMxNNJMw=; b=g8j/VzyxR8sk/HCv5pL1UsDrDWXppdPeE2uwzz8TYipLnI6R3Uihkufz A8NkhHtdZY+wCR1fjTa+UPY8J3i6mY4mrUWq4jb6/jp04wFnNTtIMODda X9ZZVCQD/pQS5A9eZbxAnAQ22WfpUFefvMvE59s0Qv27C1jqdfyVqGHKb 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUHAM5VsVOtJA2G/2dsb2JhbABagw1STasjAQEBAQEBBQFuAZIGh0ABgQkWdYQDAQEBAwEBAQE3NAsFCwIBCBIGHhAnCxcOAgQOBYg6CA3HEheFZIhwMweDLYEWBZpegUaSN4NCbAE
X-IronPort-AV: E=Sophos;i="5.01,575,1400025600"; d="scan'208";a="57103142"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 30 Jun 2014 12:25:05 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5UCP455021238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 12:25:04 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.80]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 07:25:04 -0500
From: "Ken Gray (kegray)" <kegray@cisco.com>
To: "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmYw+N+K2oqvkOsWT1eqAZMY5uDuV0AgAXh8yw=
Date: Mon, 30 Jun 2014 12:25:03 +0000
Message-ID: <17308B2F-9AEF-4E13-9F99-90D5024148C3@cisco.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>, <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
In-Reply-To: <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com>
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
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hEiR0WsAx2gfkjVMT1fl1EAvSMg
Cc: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 12:25:07 -0000

+1

Sent from my iPhone

> On Jun 26, 2014, at 10:05 AM, "Paul Quinn (paulq)" <paulq@cisco.com> wrot=
e:
>=20
> Thomas,
>=20
> As an editor: I support moving this draft forward.
>=20
> Paul
>=20
>> On Jun 25, 2014, at 3:13 PM, Thomas Narten <narten@us.ibm.com> wrote:
>>=20
>> Hi.
>>=20
>> We ran a WGLC on the problem statement draft
>> (draft-ietf-sfc-problem-statement-07.txt) back in May.
>> Although the draft received significant review and support prior to
>> the formal LC, the actual last call resulted largely in silence.
>>=20
>> While it would be convenient to take silence as acceptance, that's not
>> good enough. To show the document is ready, we need WG members to
>> speak up and indicate they have read a recent version of the document
>> and think its ready to go.
>>=20
>> Note that the document was just reissued. Section 3 has been edited to
>> remove some of the text was deemed to be encroaching on
>> architecture. You can see the changes at
>> http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf=
-sfc-problem-statement-07-from-06.diff.html
>>=20
>> With that, we are restarting a 2-week WGLC on the document. We
>> specifically need to see sufficient indications from WG members that
>> the document is ready to advance, and that the document does not
>> contain significant deficiencies.
>>=20
>> Thomas
>>=20
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


From nobody Mon Jun 30 06:02:58 2014
Return-Path: <ddolson@sandvine.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7FA1A02D2 for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 06:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55IcRfQZrhdH for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 06:02:54 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD131A02C2 for <sfc@ietf.org>; Mon, 30 Jun 2014 06:02:54 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Mon, 30 Jun 2014 09:02:53 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmaKzeihPSkAUuBQ4GfldcGXpuJpcyA
Date: Mon, 30 Jun 2014 13:02:53 +0000
Message-ID: <E8355113905631478EFF04F5AA706E9830A23F4F@wtl-exchp-2.sandvine.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
In-Reply-To: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.200.68]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OpX7UvMRe5JXUhM3whRO7ir2sqs
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 13:02:56 -0000

Support.

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten
Sent: Wednesday, June 25, 2014 3:14 PM
To: sfc@ietf.org
Subject: [sfc] 2nd WG Last Call on Problem Statement

Hi.

We ran a WGLC on the problem statement draft
(draft-ietf-sfc-problem-statement-07.txt) back in May.
Although the draft received significant review and support prior to
the formal LC, the actual last call resulted largely in silence.

While it would be convenient to take silence as acceptance, that's not
good enough. To show the document is ready, we need WG members to
speak up and indicate they have read a recent version of the document
and think its ready to go.

Note that the document was just reissued. Section 3 has been edited to
remove some of the text was deemed to be encroaching on
architecture. You can see the changes at
http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-sf=
c-problem-statement-07-from-06.diff.html

With that, we are restarting a 2-week WGLC on the document. We
specifically need to see sufficient indications from WG members that
the document is ready to advance, and that the document does not
contain significant deficiencies.

Thomas

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


From nobody Mon Jun 30 07:06:29 2014
Return-Path: <nobo@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42F61A033B for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 07:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Level: 
X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8NGy2e3_T64 for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 07:06:26 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFF31A034E for <sfc@ietf.org>; Mon, 30 Jun 2014 07:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1482; q=dns/txt; s=iport; t=1404137186; x=1405346786; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=c+Y/2rcmYGVv0SM5L3e6SxQ18MjWoEeUsSzaSzTfVvU=; b=hzPfazhB2ewkxfOpYoSjpehVwjLCGzmjvHEBBPjBpAzi4aoVRUXFnINz AsZ5eIhrlsHs6loTsUR0Vpj6ewH8C7Lyet3MToR9sBxg6vb4hyaNJxKC3 ZMHMjS/yDne/nVOGd2vEP70cZ0Pzxr8/qZ36Y9ibMecbX/xd50d83CXcC Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFAFlusVOtJV2b/2dsb2JhbABagmkkUlq+GYdAAYELFnWEAwEBAQQBAQE3NBcEAgEIEQEDAQELFAkHJwsUAwYIAgQBEgiIOgEMxykXjlY4BoMngRYFnCSSN4NCgjA
X-IronPort-AV: E=Sophos;i="5.01,575,1400025600"; d="scan'208";a="57128615"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 30 Jun 2014 14:06:22 +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 s5UE6MmU006197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 14:06:22 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 09:06:22 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: Thomas Narten <narten@us.ibm.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmYbBa3wIHhxEGu4vj/1uvbgpuJtwLw
Date: Mon, 30 Jun 2014 14:06:21 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E2548A3@xmb-aln-x01.cisco.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
In-Reply-To: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [161.44.212.73]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CLrvgqWcCY8Kc3YmQwOXTcf7aZY
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 14:06:27 -0000

Yes/Support.

Thanks!

-Nobo

> -----Original Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten
> Sent: Wednesday, June 25, 2014 3:14 PM
> To: sfc@ietf.org
> Subject: [sfc] 2nd WG Last Call on Problem Statement
>=20
> Hi.
>=20
> We ran a WGLC on the problem statement draft
> (draft-ietf-sfc-problem-statement-07.txt) back in May.
> Although the draft received significant review and support prior to the
> formal LC, the actual last call resulted largely in silence.
>=20
> While it would be convenient to take silence as acceptance, that's not go=
od
> enough. To show the document is ready, we need WG members to speak up
> and indicate they have read a recent version of the document and think it=
s
> ready to go.
>=20
> Note that the document was just reissued. Section 3 has been edited to
> remove some of the text was deemed to be encroaching on architecture.
> You can see the changes at http://tools.ietf.org/wg/sfc/draft-ietf-sfc-
> problem-statement/draft-ietf-sfc-problem-statement-07-from-06.diff.html
>=20
> With that, we are restarting a 2-week WGLC on the document. We
> specifically need to see sufficient indications from WG members that the
> document is ready to advance, and that the document does not contain
> significant deficiencies.
>=20
> Thomas
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


From nobody Mon Jun 30 07:11:23 2014
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EDE1A036D for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 07:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.451
X-Spam-Level: 
X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndb6Vm_fLA6L for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 07:11:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EE61A035B for <sfc@ietf.org>; Mon, 30 Jun 2014 07:10:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJK60191; Mon, 30 Jun 2014 14:10:47 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 15:10:46 +0100
Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001;  Mon, 30 Jun 2014 07:10:42 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com>, "Ng, Tomy" <Tomy.Ng@team.telstra.com>, Qiong <bingxuere@gmail.com>, "Pham, Chuong D" <Chuong.D.Pham@team.telstra.com>
Thread-Topic: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01
Thread-Index: AQHPW1X8U8UhsrhhTUWWEhfLxMVVkZsvyRbNgAV/2wCACF1ZUIBESFuAgAQXNoA=
Date: Mon, 30 Jun 2014 14:10:41 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D6DE7F@dfweml701-chm.china.huawei.com>
References: <CF77200F.1F832%jguichar@cisco.com> <5351B460.5040709@joelhalpern.com> <C8C844F84E550E43865561FAE10471853E9F0CDA@VOEXM20W.internal.vodafone.com> <5602569641FB314FB4D9AD5659D41B9C2C1B0AA05D@WSMSG3154V.srv.dir.telstra.com> <CAH3bfADaXVoE_LA3cYY3a9QpkbyZY25kK75FJfAX_9+i+w8M+Q@mail.gmail.com> <DE51876A0B79C24589A3AF4BB0EB64EF951619DAEE@WSMSG3103V.srv.dir.telstra.com> <4A95BA014132FF49AE685FAB4B9F17F645D088B4@dfweml701-chm.china.huawei.com> <CFCF75DF.48EA7%smkumar@cisco.com>
In-Reply-To: <CFCF75DF.48EA7%smkumar@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.245.68]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D6DE7Fdfweml701chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2Bj25Va8LJVX2-vGhTpYdNhQ5xQ
Cc: "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Haeffner, Walter, Vodafone DE" <walter.haeffner@vodafone.com>, "Jeffrey Napper \(jenapper\)" <jenapper@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 14:11:15 -0000

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

Surendra,



From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]




-          I can't see how the examples listed in Section 3 drive the requi=
rement listed in Section 5. The requirement listed in Section 5 are so gene=
ral, that you don't need those examples listed in Section 3.



-          Since this is a use case draft, not requirement draft, this draf=
t should only list down the requirement driven by the examples.
 SK> If there are specific concerns, we could discuss and update the draft/=
examples.

[Linda] I think that the requirement section should be removed from the dra=
ft because it is a use case draft, not a requirement draft.

Linda

I see that the key requirement driven by the examples in Section 3 is to al=
low those Service Functions to be located  anywhere (i.e. not necessarily o=
n the data path). Therefore, the key requirement should be needing dynamic =
steering policies to Service Nodes, routers, and switches

Linda


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ng, Tomy
Sent: Wednesday, May 07, 2014 2:23 AM
To: Qiong; Pham, Chuong D
Cc: Joel M. Halpern; Jim Guichard (jguichar); Haeffner, Walter, Vodafone DE=
; sfc@ietf.org<mailto:sfc@ietf.org>; Jeffrey Napper (jenapper) (jenapper@ci=
sco.com<mailto:jenapper@cisco.com>)
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

Hi All,

Agree with Chuong's viewpoint and I disapprove the adoption of this draft.

Cheers

Tomy
...............................................

On Wed, Apr 30, 2014 at 7:35 AM, Pham, Chuong D <Chuong.D.Pham@team.telstra=
.com<mailto:Chuong.D.Pham@team.telstra.com>> wrote:
Separate drafts for pockets of environments will most likely overlook the o=
pportunities for identifying commonalities, synergies and reuse factors bet=
ween similar use cases for different environments. This is the painful situ=
ation today where silos exist while at this point in time where Mobile, Fix=
ed Broadband and Data Centre are seeing strong forces towards convergence w=
ith SDN, NFV and Cloud technologies.

An overall draft such as draft-liu or similar must exist as a common refere=
nce point for more detailed level drafts addressing use cases for specific/=
pockets of environments while allowing for future migration/convergence.

Unless draft-kumar co-exists with high level draft-liu, I see more harm in =
divergence rather than benefits therefore I disapprove.

Regards,
Chuong


-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com<ma=
ilto:walter.haeffner@vodafone.com>]
Sent: Wednesday, 30 April 2014 2:56 AM
To: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.=
org>
Cc: Jeffrey Napper (jenapper) (jenapper@cisco.com<mailto:jenapper@cisco.com=
>)
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I also support this draft. Being on DC level this draft will complement the=
 other use case drafts. Beside typical FW or DPI etc. there should be not t=
hat much overlap with the more carrier services oriented use case drafts.

Cheers, Walter


-----Urspr=FCngliche Nachricht-----
Von: sfc [mailto:sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>] Im Auft=
rag von Joel M. Halpern
Gesendet: Samstag, 19. April 2014 01:25
An: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org>
Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01

I support adoption of this document by the working group.  It is a good sta=
rting point for addressing the material it covers, and the working group sh=
ould cover that material.

Yours,
Joel

On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote:
> Dear WG:
>
> This message begins a two week call for WG adoption of the document
> http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt ending 2nd
> May 2014.
>
> Please respond to the SFC mailing list with any statements of approval
> or disapproval.
>
> Please note:
>
>  1. This is not WG Last Call. The document is not final, and the WG is
>     expected to modify the document's content until there is WG
>     consensus that the content is solid. Therefore, please don't oppose
>     adoption just because you want to see changes to its content.
>  2. If you have objections to adoption of the document, please state
>     your reasons why, and explain what it would take to address your
>     concerns.
>  3. If you have issues with the content, by all means raise those issues
>     and we can begin a dialog about how best to address them.
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org<mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc
>

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc


_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institute

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<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: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.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.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-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:2057387059;
	mso-list-type:hybrid;
	mso-list-template-ids:-129312372 1588738776 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{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-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;}
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">Surendra,
<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;"> Surendra=
 Kumar (smkumar) [mailto:smkumar@cisco.com]
<br>
<br>
</span><span style=3D"font-size:7.0pt;font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=3D"MsoListParagraph"><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span=
 style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"font-family:&quot;Calibri&quot;=
,&quot;sans-serif&quot;;color:black"><span style=3D"mso-list:Ignore">-<span=
 style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&=
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">I can&#8217;t see=
 how the examples listed in Section 3 drive the requirement listed in Secti=
on 5. The requirement listed in Section 5 are so general, that
 you don&#8217;t need those examples listed in Section 3. </span><span styl=
e=3D"color:black"><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">&nbsp;</span><span=
 style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"font-family:&quot;Calibri&quot;=
,&quot;sans-serif&quot;;color:black"><span style=3D"mso-list:Ignore">-<span=
 style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&=
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">Since this is a u=
se case draft, not requirement draft, this draft should only list down the =
requirement driven by the examples.
</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"font-size:7.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;=
color:black">SK&gt; If there are specific concerns, we could discuss and up=
date the draft/examples.</span><span style=3D"color:black"><o:p></o:p></spa=
n></p>
</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:#1F497D">&nbsp;</span><span style=
=3D"font-size:11.0pt;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:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Linda] I think that the =
requirement section should be removed from the draft because it is a use ca=
se draft, not a requirement draft. &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">Linda
<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>
<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=
">I see that the key requirement driven by the examples in Section 3 is to =
allow those Service Functions to be located &nbsp;anywhere (i.e.
 not necessarily on the data path). Therefore, the key requirement should b=
e needing dynamic steering policies to Service Nodes, routers, and switches=
</span><span style=3D"color:black"><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:7.0pt;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;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Linda</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;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"> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bou=
nces@ietf.org</a>]
<b>On Behalf Of </b>Ng, Tomy<br>
<b>Sent:</b> Wednesday, May 07, 2014 2:23 AM<br>
<b>To:</b> Qiong; Pham, Chuong D<br>
<b>Cc:</b> Joel M. Halpern; Jim Guichard (jguichar); Haeffner, Walter, Voda=
fone DE;
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>; Jeffrey Napper (jenapper)=
 (<a href=3D"mailto:jenapper@cisco.com">jenapper@cisco.com</a>)<br>
<b>Subject:</b> Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases=
-01</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>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-=
family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Hi All,</span>=
<span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-=
family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><=
span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-=
family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Agree with&nbs=
p;Chuong&#8217;s viewpoint and I disapprove the adoption of this draft.</sp=
an><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-=
family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><=
span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-=
family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Cheers</span><=
span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-=
family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">&nbsp;</span><=
span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-=
family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Tomy</span><sp=
an style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-AU" =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&=
quot;;color:#1F497D">...............................................</span>=
<span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">&nbsp;<=
/span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:black">On Wed, A=
pr 30, 2014 at 7:35 AM, Pham, Chuong D &lt;<a href=3D"mailto:Chuong.D.Pham@=
team.telstra.com" target=3D"_blank">Chuong.D.Pham@team.telstra.com</a>&gt; =
wrote:</span><span style=3D"color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:black">Separate =
drafts for pockets of environments will most likely overlook the opportunit=
ies for identifying commonalities, synergies and reuse factors between simi=
lar use cases for different environments.
 This is the painful situation today where silos exist while at this point =
in time where Mobile, Fixed Broadband and Data Centre are seeing strong for=
ces towards convergence with SDN, NFV and Cloud technologies.<br>
<br>
An overall draft such as draft-liu or similar must exist as a common refere=
nce point for more detailed level drafts addressing use cases for specific/=
pockets of environments while allowing for future migration/convergence.<br=
>
<br>
Unless draft-kumar co-exists with high level draft-liu, I see more harm in =
divergence rather than benefits therefore I disapprove.<br>
<br>
Regards,<br>
Chuong</span><span style=3D"color:black"><o:p></o:p></span></p>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:black"><br>
<br>
-----Original Message-----<br>
From: Haeffner, Walter, Vodafone DE [mailto:<a href=3D"mailto:walter.haeffn=
er@vodafone.com">walter.haeffner@vodafone.com</a>]<br>
Sent: Wednesday, 30 April 2014 2:56 AM<br>
To: Joel M. Halpern; Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.or=
g">sfc@ietf.org</a><br>
Cc: Jeffrey Napper (jenapper) (<a href=3D"mailto:jenapper@cisco.com">jenapp=
er@cisco.com</a>)<br>
Subject: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<br>
<br>
I also support this draft. Being on DC level this draft will complement the=
 other use case drafts. Beside typical FW or DPI etc. there should be not t=
hat much overlap with the more carrier services oriented use case drafts.<b=
r>
<br>
Cheers, Walter<br>
<br>
<br>
-----Urspr=FCngliche Nachricht-----<br>
Von: sfc [mailto:<a href=3D"mailto:sfc-bounces@ietf.org">sfc-bounces@ietf.o=
rg</a>] Im Auftrag von Joel M. Halpern<br>
Gesendet: Samstag, 19. April 2014 01:25<br>
An: Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</=
a><br>
Betreff: Re: [sfc] Call for adoption of draft-kumar-sfc-dc-use-cases-01<br>
<br>
I support adoption of this document by the working group. &nbsp;It is a goo=
d starting point for addressing the material it covers, and the working gro=
up should cover that material.<br>
<br>
Yours,<br>
Joel<br>
<br>
On 4/18/14, 6:31 PM, Jim Guichard (jguichar) wrote:<br>
&gt; Dear WG:<br>
&gt;<br>
&gt; This message begins a two week call for WG adoption of the document<br=
>
&gt; <a href=3D"http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt"=
 target=3D"_blank">
http://www.ietf.org/id/draft-kumar-sfc-dc-use-cases-01.txt</a> ending 2nd<b=
r>
&gt; May 2014.<br>
&gt;<br>
&gt; Please respond to the SFC mailing list with any statements of approval=
<br>
&gt; or disapproval.<br>
&gt;<br>
&gt; Please note:<br>
&gt;<br>
&gt; &nbsp;1. This is not WG Last Call. The document is not final, and the =
WG is<br>
&gt; &nbsp; &nbsp; expected to modify the document's content until there is=
 WG<br>
&gt; &nbsp; &nbsp; consensus that the content is solid. Therefore, please d=
on't oppose<br>
&gt; &nbsp; &nbsp; adoption just because you want to see changes to its con=
tent.<br>
&gt; &nbsp;2. If you have objections to adoption of the document, please st=
ate<br>
&gt; &nbsp; &nbsp; your reasons why, and explain what it would take to addr=
ess your<br>
&gt; &nbsp; &nbsp; concerns.<br>
&gt; &nbsp;3. If you have issues with the content, by all means raise those=
 issues<br>
&gt; &nbsp; &nbsp; and we can begin a dialog about how best to address them=
.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; sfc mailing list<br>
&gt; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/sfc</a><br>
&gt;<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a><br>
<br>
<br>
_______________________________________________<br>
sfc mailing list<br>
<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/sfc</a></span><span style=3D"color:black=
"><o:p></o:p></span></p>
</div>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:black"><br>
<br clear=3D"all">
</span><span style=3D"color:black"><o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:black">&nbsp;</s=
pan><span style=3D"color:black"><o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-AU" =
style=3D"color:black">--
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
Qiong Sun<br>
China Telecom Beijing Research Institute<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span><s=
pan style=3D"color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F645D6DE7Fdfweml701chmchi_--


From nobody Mon Jun 30 08:55:13 2014
Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411DB1A0397 for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 08:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlGLYczPdU2g for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 08:54:58 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912971A0389 for <sfc@ietf.org>; Mon, 30 Jun 2014 08:54:57 -0700 (PDT)
Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 30 Jun 2014 17:54:54 +0200
Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 30 Jun 2014 17:54:54 +0200
From: <Dirk.von-Hugo@telekom.de>
To: <repenno@cisco.com>, <paulq@cisco.com>, <narten@us.ibm.com>
Date: Mon, 30 Jun 2014 17:54:53 +0200
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmY2GzMEM1YrUSzZ89YzxwzcZuDuVsA//+dBICABnVa8A==
Message-ID: <05C81A773E48DD49B181B04BA21A342A2E170CFA30@HE113484.emea1.cds.t-internal.com>
References: <EDE2C6DC-28C4-42FE-BAA3-69351CC90DED@cisco.com> <CFD1786C.C99A%repenno@cisco.com>
In-Reply-To: <CFD1786C.C99A%repenno@cisco.com>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/SyBC_syiiwaLF4sfI6n5-h_jbW4
Cc: sfc@ietf.org
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 15:55:01 -0000

Dear Reinaldo, all,
As non-contributor nor editor or author of the draft I think that it descri=
bes typical challenges of operational usage of networks, i.e. to configure =
and deliver a multitude of services. The networks are made up of different =
nodes which are connected by a structured topology and communicate via spec=
ific protocols. Moreover the current networks have been once deployed and a=
fterwards extended within years and decades: Thus it is clear that many pro=
blems result from topology constraints - i.e. configuration complexity.
The different sections just describe different aspects of and impacts on se=
rvice performance which are often related to each other.
That works for me.

Regarding your comment 3 on section 2.3 below, my understanding of the sent=
ence is as follows:
In case of large-scale networks to achieve high performance same service fu=
nctions may have to be implemented in multiple instances. All these instanc=
es have to be executed at the same hierarchical level of the network topolo=
gy in order not to impact the service performance (e.g. as a function of en=
d point location).
Is that correct?  =20

Beside some grammar nits in the text (e.g. p.1: The set of enabled service =
function chains reflect =3D> The set of enabled service function chains ref=
lects, p.3: The delivery of end-to-end services often require =3D> The deli=
very of end-to-end services often requires etc.) I think that in ch. 5 it s=
hould read "three components" instead of "four components" reflecting the c=
hanges from -06 (ch. 3). Or did I misunderstand something?

After clarification of these minor issues I agree to support forwarding.

Best regards
Dirk
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn=
o)
Sent: Donnerstag, 26. Juni 2014 16:41
To: Paul Quinn (paulq); Thomas Narten
Cc: sfc@ietf.org
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement

Hello,

I think the document needs editing and clarification before moving forward.=
 Many sub-sections seems redundant and intertwined.

Comment 1:

Section 2.1, 2.2, 2.4, 2.7 and 2.8 are  talking about the same root
problem: configuration complexity.

2.1, 2.4, 2.7 and 2.8 are consequences of 2.2 and not really a problem stat=
ement in itself. At least that=B9s how I see it. If you solve configuration=
 complexity, the others will consequently be solved.

I think it is worth to maintain the discussion but not as a separate proble=
m space, they should be under =B3Configuration complexity=B2 sub-section.

Some snippets to the point:

Section 2.1

"resulting in complex network changes and device configuration."

Section 2.4

"Service function chains today are most typically built through manual
   configuration processes.  These are slow and error prone."


Section 2.7

"rapid
   changes to the service deployment can be hard to realize due to the
   risk and complexity of such changes.
=B3

Section 2.8

"This
   results in operationally complex configurations and is still
   relatively inflexible."


These are all basically saying that today configuration is complex and manu=
al and automatic configuration would be a great idea.


Comment 2:

Section 2.6 seems a executive summary of parts of section 2.1 since the tyi=
ng service function to topology you are saying service function must unders=
tand that transport.

"The coupling of service
   functions to topology requires service functions to support many
   transport encapsulations or for a transport gateway function to be
   present.=B2


Comment 3:

I have trouble parsing this sentence.


"Since traffic reaches many service functions based on network
   topology, alternate, or redundant service functions must be placed in
   the same topology as the primary service.=B2



On 6/26/14, 6:35 AM, "Paul Quinn (paulq)" <paulq@cisco.com> wrote:

>Thomas,
>
>As an editor: I support moving this draft forward.
>
>Paul
>
>On Jun 25, 2014, at 3:13 PM, Thomas Narten <narten@us.ibm.com> wrote:
>
>> Hi.
>>=20
>> We ran a WGLC on the problem statement draft
>> (draft-ietf-sfc-problem-statement-07.txt) back in May.
>> Although the draft received significant review and support prior to=20
>> the formal LC, the actual last call resulted largely in silence.
>>=20
>> While it would be convenient to take silence as acceptance, that's=20
>> not good enough. To show the document is ready, we need WG members to=20
>> speak up and indicate they have read a recent version of the document=20
>> and think its ready to go.
>>=20
>> Note that the document was just reissued. Section 3 has been edited=20
>> to remove some of the text was deemed to be encroaching on=20
>> architecture. You can see the changes at
>>=20
>>http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ie
>>tf- sfc-problem-statement-07-from-06.diff.html
>>=20
>> With that, we are restarting a 2-week WGLC on the document. We=20
>> specifically need to see sufficient indications from WG members that=20
>> the document is ready to advance, and that the document does not=20
>> contain significant deficiencies.
>>=20
>> Thomas
>>=20
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc

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


From nobody Mon Jun 30 10:47:54 2014
Return-Path: <cpignata@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C0C1A03B6 for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 10:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geQRHNmoGJxF for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 10:47:51 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90971A03B5 for <sfc@ietf.org>; Mon, 30 Jun 2014 10:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1948; q=dns/txt; s=iport; t=1404150470; x=1405360070; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=K7ENWYDaj4HGP3JW/hZAYdONvZ2uBnUP6giQgB+Ncy8=; b=nJz92NLD1r4/Gtd9lcgsxuS6LzLDEDTSWrIPh94XPQVi86bVDzF5GlK0 dAtXyRNDt20DB7Jba4Mp2CoQtyEQyUB/FXL2WvzDY5L2qWO2rqKUWgbCU onm67RxOzXwbMLFUFIxtSFUyw8kv+Lc5nQg3C7icMxxPuvozbu9w5LTis k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj0HALehsVOtJV2Y/2dsb2JhbABagw1SWqsaAQEBAQEBBQECbAGSBodAgRIWdYQDAQEBAwEBAQE3NAsFCwIBCBIkECcLFw4CBA4FiDoIDcgfF4VkiHAzgzSBFgWaXoFGkjeDQmwBgUM
X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="57180386"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 30 Jun 2014 17:47:50 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5UHloCd019758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 17:47:50 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.80]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 12:47:49 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Thomas Narten <narten@us.ibm.com>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmYIIVe2oMP8Eymhuf7Vagdvg==
Date: Mon, 30 Jun 2014 17:47:49 +0000
Message-ID: <598A8AA5-B1EB-440F-B8A9-CCA84534B6CA@cisco.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.157.229]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3514B82447882647B9BF3253AB2C3E3D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bJYTHDi1E3W_NL_G9RQzTP9MvZ0
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 17:47:52 -0000

Thomas,

Having read a recent version of the problem statement document (rev -06, an=
d checked the diffs below), I believe it is complete (modulo small comment =
below) and comprehensive yet not bloated, clear, idnits-free, and has incor=
porated all WG's feedback.

Consequently, I think it is ready to advance and support progressing this d=
ocument to the IESG.

The small comment: I would like to see a small sentence added that the topo=
logical dependencies have not only an impact in creating/modifying service =
chains, but also to manage them, and it is part of the problem that there i=
s no consistent OAM.

Thanks,

Carlos.

On Jun 25, 2014, at 3:13 PM, Thomas Narten <narten@us.ibm.com> wrote:

> Hi.
>=20
> We ran a WGLC on the problem statement draft
> (draft-ietf-sfc-problem-statement-07.txt) back in May.
> Although the draft received significant review and support prior to
> the formal LC, the actual last call resulted largely in silence.
>=20
> While it would be convenient to take silence as acceptance, that's not
> good enough. To show the document is ready, we need WG members to
> speak up and indicate they have read a recent version of the document
> and think its ready to go.
>=20
> Note that the document was just reissued. Section 3 has been edited to
> remove some of the text was deemed to be encroaching on
> architecture. You can see the changes at
> http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-=
sfc-problem-statement-07-from-06.diff.html
>=20
> With that, we are restarting a 2-week WGLC on the document. We
> specifically need to see sufficient indications from WG members that
> the document is ready to advance, and that the document does not
> contain significant deficiencies.
>=20
> Thomas
>=20
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


From nobody Mon Jun 30 15:03:52 2014
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9191A0AFF for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 15:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAS4jQX6-nzs for <sfc@ietfa.amsl.com>; Mon, 30 Jun 2014 15:03:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8D91A002E for <sfc@ietf.org>; Mon, 30 Jun 2014 15:03:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGQ67348; Mon, 30 Jun 2014 22:03:47 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 23:03:46 +0100
Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001;  Mon, 30 Jun 2014 15:03:38 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "Zarny, Myo" <Myo.Zarny@gs.com>, "'Thomas Narten'" <narten@us.ibm.com>, "'sfc@ietf.org'" <sfc@ietf.org>
Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement
Thread-Index: AQHPkKmcNxJAAL6doke0WX1xOHa0CZuEWkAAgAXiqFA=
Date: Mon, 30 Jun 2014 22:03:38 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D6ECA8@dfweml701-chm.china.huawei.com>
References: <m3y4wkztsw.wl%narten@us.ibm.com> <A3233753A4B65F43BCA1B64DA99A9C230708D662EF@GSCMAMP19EX.firmwide.corp.gs.com>
In-Reply-To: <A3233753A4B65F43BCA1B64DA99A9C230708D662EF@GSCMAMP19EX.firmwide.corp.gs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.245.88]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bntIV1InGzm9nS4ZAJEoKyow0ik
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jun 2014 22:03:51 -0000

Support.=20

Linda=20


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten
Sent: 25 June 2014 3:14 PM
To: sfc@ietf.org
Subject: [sfc] 2nd WG Last Call on Problem Statement

Hi.

We ran a WGLC on the problem statement draft
(draft-ietf-sfc-problem-statement-07.txt) back in May.
Although the draft received significant review and support prior to the for=
mal LC, the actual last call resulted largely in silence.

While it would be convenient to take silence as acceptance, that's not good=
 enough. To show the document is ready, we need WG members to speak up and =
indicate they have read a recent version of the document and think its read=
y to go.

Note that the document was just reissued. Section 3 has been edited to remo=
ve some of the text was deemed to be encroaching on architecture. You can s=
ee the changes at http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-state=
ment/draft-ietf-sfc-problem-statement-07-from-06.diff.html

With that, we are restarting a 2-week WGLC on the document. We specifically=
 need to see sufficient indications from WG members that the document is re=
ady to advance, and that the document does not contain significant deficien=
cies.

Thomas

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

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