Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

From: Cathy Zhang <[email-masked]>
Date: Thu, 29 Jan 2015 19:44:15 +0000

Hi everyone,

We have uploaded a new SCH version (3) which adds definition of a new metadata type for the flow ID to support load balancing among SF instances and mitigate the potential issue of "not enough path ID". The flow ID is named "rendered service path ID" in the draft. Please refer to section 4.3.2 of https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for detail description. 

In its previous version, SCH defines a "Bypass bit" in the base header. This bit enables the SF to provide feedback/notification via the data path to its connecting SFF about whether the remaining packets of the SFC should bypass that SF. This is useful in the case that only the first few packets of a flow need to go to a SF (such as a DPI or FW or IDS) and remaining packets can bypass that SF, thus saving the expensive SF resource and reducing data path latency.  

B bit: The B (Bypass) bit, when set to 1, it is used by a Service 
       Function to signal to its Service Function Forwarder that no
       further packets are to be sent to it for the flow specified in encapsulated packet.

In addition, SCH defines a metadata type for Generic Context Block, which is optional and can be used if needed to carry any vendor's specific "Context Header". 

Any comments on these new additions? 

Thanks,
Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Friday, December 05, 2014 11:47 AM
To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Ron, Louis, Myo and I have been discussing off line last few weeks about defining a metadata type for flow ID in addition to the path ID of the main header to support load balancing among SF instances. We will define a TLV type for the flow ID. The combination of "path ID + flow ID" specifies a realized service chain instance path. It is left to the design/implementation whether to use a centralized method or a distributed method to bind the flow ID to a realized service instance path although our original thought is for distributed LB usage. I am not sure if we need a bit in the header to denote whether there are more path ID bits (we call it flow ID) in the metadata fields since when you parse the TLV metadata, you will know whether there are flow ID bits or not. Note that if multiple sessions share the same realized service instance path, they will share the same "path ID+ flow ID".  We can also consider extending the number of bits to 32 if that is the consensus. We will post an updated draft describing these soon. 

Thanks,
Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Friday, December 05, 2014 7:17 AM
To: Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

[RP] Data plane efficiency. 

SRINI> I am not so sure about data plane efficiency.  Most of the processors work good if the number of bits are either 32 or 64.  If it is 24 bits, then one needs to do masking and shifting before the value is used to do any lookup.   But, this discussion can go into different direction :-), it may not be good to go in that direction.

Where do we draw the line? 32-bits, 64-bits,
128 bits? I think we should have a sensible value in the Service Path
header and if you need to convey more bits you need to use the context
headers.

SRINI> This is a good point.  This should work fine as long as there is way to convey in the main header that the extension to path ID is available in so and so TLV field.  That should work too.

Thanks
Srini

________________________________________
From: Reinaldo Penno (repenno) <[email-masked]>
Sent: Friday, December 5, 2014 7:08 AM
To: Addepalli Srini-B22160; Joel M. Halpern; [email-masked]'
Cc: NS Srinivasa Murthy-B37840
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

On 12/5/14, 6:54 AM, "Srini Addepalli" <[email-masked]> wrote:

>
>In real deployments, number of active path IDs are very lesser than 2^64,
>but there is a good possibility of the number being more than 2^24 (16M).
> I think bigger point is that why restrict this in the standards? What
>advantage do we have restricting this size to 24 bits?

[RP] Data plane efficiency. Where do we draw the line? 32-bits, 64-bits,
128 bits? I think we should have a sensible value in the Service Path
header and if you need to convey more bits you need to use the context
headers.

>
>There can be deployments, where SFC controller (Logically central, but
>distributed)  itself can do the SF instance selection on per
>connection/session basis, thereby avoiding the LBs for services.   In my
>view, assumption that there will be LB SF for each scale-out service in
>the chain is not valid in all cases.
>
>Thanks
>Srini
>
>________________________________________
>From: Reinaldo Penno (repenno) <[email-masked]>
>Sent: Thursday, December 4, 2014 1:17 PM
>To: Addepalli Srini-B22160; Joel M. Halpern; [email-masked]
>Cc: NS Srinivasa Murthy-B37840
>Subject: Re: [sfc] Comments on SCH Draft
>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02)
>
>If I understood you, I do not think this is realistic. Are you saying you
>need 64-bits of paths and then will monitor them all? Do fault tolerance
>and OAM for 2^64-bits worth of paths? Just for comparison, it¹s like
>managing and monitoring the entire IPv6 host range, one-by-one.
>
>Anyway, I do not expect every single permutations to be a different path.
>
>If each service has 256 devices providing similar service, you should most
>likely use load-balancing and then you would have a single (or a few)
>paths. There is some discussion going on LB.
>
>From a data plane perspective, the path is ultimately defined by the SFFs
>traversed and services provided, not by a specific IP:port that the device
>providing the service sits on. Well, at least from a GPE+NSH perspective.
>
>
>On 12/4/14, 12:57 PM, "Srini Addepalli" <[email-masked]> wrote:
>
>>If I take a chain with 5 services with each service  say having 256
>>instances for scale-out, possible number of paths are 256*256*256*256*256
>>= 0xFF FF FF FF FF. One requires 33 bits in this case.  If there are more
>>services in the chain or more chains or more instances for scale-out,
>>then it could go to big number very fast.
>>
>>As I mentioned my preference is to make the path ID size flexible for
>>future growth. If that is perceived as complex, then going for 64bit is
>>safer bet.
>>
>>Thanks
>>Srini
>>
>>
>>-----Original Message-----
>>From: Joel M. Halpern [mailto:[email-masked]]
>>Sent: Thursday, December 04, 2014 12:05 PM
>>To: Addepalli Srini-B22160; Joel M. Halpern; [email-masked]
>>Cc: NS Srinivasa Murthy-B37840
>>Subject: Re: [sfc] Comments on SCH Draft
>>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02)
>>
>>A controller (or other decision logic) can certainly be aware of such
>>concerns.
>>But the number of service function paths is not related to the number of
>>flows or the number of tenants.  It is related to the number of
>>combinations of services and the policies for service function selection.
>> While that can be a large number, I sure hope it does not come close to
>>saturating 24 bits.
>>
>>Having said that, if we think that 24 bits is only just enough, then we
>>ought to use 32.  From where I sit, I would normally expect 16 bits to be
>>more than sufficient, which is why I am comfortable with 24.  Having said
>>that, the field size is not a big deal to me.
>>
>>Yours,
>>Joel
>>
>>On 12/4/14, 2:01 PM, Srini Addepalli wrote:
>>>
>>> I was not implying that path ID should have information in regards to
>>>tenant/controller/flow/scale-out.  But SFC controllers should keep these
>>>in mind to assign the path ID.    A deployment can have multiple
>>>tenants, each tenant can have multiple networks,  there could be
>>>millions of flows in each of those networks.  And considering all these,
>>> 24 bit path ID may not be able to represent paths for these flows.
>>>Hence, I was wondering whether path ID can be extended to 64 bits or
>>>make it flexible.
>>>
>>> Thanks
>>> Srini
>>>
>>> ________________________________________
>>> From: Joel M. Halpern <[email-masked]>
>>> Sent: Thursday, December 4, 2014 7:42 AM
>>> To: Addepalli Srini-B22160; [email-masked]
>>> Cc: NS Srinivasa Murthy-B37840
>>> Subject: Re: [sfc] Comments on SCH Draft
>>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)
>>>
>>> The Index is not just for loop prevention.  In the case of ambiguity,
>>> the index tells the SFF where in the path the packet currently resides.
>>>    There are multiple ways such ambiguity can occur.
>>>
>>> The Path Identifier is specifically not expected to include controller
>>> ID or Tenant ID.  While a deployer can have a path per tenant, the
>>> architecture still does not treat the path ID as a tenant ID.  Tenant
>>> ID, controller ID, and other non-path-specifying information is to be
>>> carried in metadata.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote:
>>>> Two comments :
>>>>
>>>>
>>>> 1.  SF Index :  Since it is meant for loop detection,  wouldn't
>>>> better to rename this as "TTL"?
>>>>
>>>> 2.  Path Identifier :    24 bit path identifier seems to be too less.
>>>> Based on our experience in traffic steering,  this path identifier
>>>> needs to encode good amount of information to make it unique.  For
>>>>example,
>>>>    this identifier needs to encode (in our case) some information
>>>> representing the distributed controller ID,  tenant ID,  flow ID,
>>>>    Service function instance (in case of scale-out) and few more..
>>>> One suggestion is to make it 64 bits value  or to make it even
>>>>extendable,
>>>>    it is good if path identifier is also represented in TLV form.
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Srini
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>
>>_______________________________________________
>>sfc mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/sfc
>

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

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

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 29 Jan 2015 21:23:37 +0000

Cathy,

I believe that you omitted a reference to an existing draft that clearly describes the use of what you call bypass (and provides an implemenation example).  

I suggest that you review https://datatracker.ietf.org/doc/draft-kumar-sfc-sfp-optimization/ and update your references accordingly.

Paul

> On Jan 29, 2015, at 2:44 PM, Cathy Zhang <[email-masked]> wrote:
> 
> Hi everyone,
>

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Fri, 30 Jan 2015 11:38:00 +0000

Hello Cathy,

Indeed the notion of "rendered service path ID"(RSP ID) seems relevant as the architecture document stipulates that the Service Function Path (SFP) provides an abstract notion of a service chain, while the RSP is a constrained list of locations.

SFC header "Service Path Identifier" (SPI)  is used in both NSH and SCH protocol and in both case seem to identify to a particular SFP.

NSH(v5) for example states that
" As described above, NSH contains a service path identifier (SPI) and
   a service index (SI).  The SPI is, as per its name, an identifier.
   The SPI alone cannot be used to forward packets along a service path.
   Rather the SPI provide a level of indirection between the service
   path/topology and the the network transport.  Furthermore, there is
   no requirement, or expectation of an SPI being bound to a pre-
   determined or static network path."

Still NSH(v5)  shows that SPI (not a RSP ID)  should be part of the key  element of an SFF to lookup on forwarding tables.  But I could not find in NSH  how to use the notion of
Rendered service path which was defined in the architecture document.

You proposal seems to me very useful,

An RSP ID (independent of the SPI but part of the same name space) could be used the same way as SPI by SFF for example, allowing a Service Classifier to control remote load balancing for example.

This said the RSP ID values could be relative to a particular Service Path, which would prevent using them as we do for SPI in SFF forwarding tables.

We may want to precise if the RSP ID is to be relative of absolute, as it should have an impact on forwarding table structure if we decide to use this concept.

Personally I like the notion of a relative RSP ID, as we could then use some conventions, structure it, possibly extending its use.

Nicolas

-----Original Message-----
From: Cathy Zhang [mailto:[email-masked]]
Sent: jeudi 29 janvier 2015 20:44
To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi everyone,

Thanks,
Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Friday, December 05, 2014 11:47 AM
To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Thanks,
Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Friday, December 05, 2014 7:17 AM
To: Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Where do we draw the line? 32-bits, 64-bits,
128 bits? I think we should have a sensible value in the Service Path header and if you need to convey more bits you need to use the context headers.

Thanks
Srini

On 12/5/14, 6:54 AM, "Srini Addepalli" <[email-masked]> wrote:

>
>In real deployments, number of active path IDs are very lesser than
>2^64, but there is a good possibility of the number being more than 2^24 (16M).

[RP] Data plane efficiency. Where do we draw the line? 32-bits, 64-bits,
128 bits? I think we should have a sensible value in the Service Path header and if you need to convey more bits you need to use the context headers.

>If I understood you, I do not think this is realistic. Are you saying
>you need 64-bits of paths and then will monitor them all? Do fault
>tolerance and OAM for 2^64-bits worth of paths? Just for comparison,
>it¹s like managing and monitoring the entire IPv6 host range, one-by-one.
>
>If each service has 256 devices providing similar service, you should
>most likely use load-balancing and then you would have a single (or a
>few) paths. There is some discussion going on LB.
>
>From a data plane perspective, the path is ultimately defined by the
>SFFs traversed and services provided, not by a specific IP:port that
>the device providing the service sits on. Well, at least from a GPE+NSH perspective.
>
>
>>instances for scale-out, possible number of paths are
>>256*256*256*256*256 = 0xFF FF FF FF FF. One requires 33 bits in this
>>case.  If there are more services in the chain or more chains or more
>>instances for scale-out, then it could go to big number very fast.
>>
>>future growth. If that is perceived as complex, then going for 64bit
>>is safer bet.
>>
>>Thanks
>>Srini
>>
>>
>>But the number of service function paths is not related to the number
>>of flows or the number of tenants.  It is related to the number of
>> While that can be a large number, I sure hope it does not come close
>>to saturating 24 bits.
>>
>>Having said that, if we think that 24 bits is only just enough, then
>>we ought to use 32.  From where I sit, I would normally expect 16 bits
>>to be more than sufficient, which is why I am comfortable with 24.
>>Having said that, the field size is not a big deal to me.
>>
>>Yours,
>>Joel
>>
>>> I was not implying that path ID should have information in regards
>>>to tenant/controller/flow/scale-out.  But SFC controllers should keep these
>>> The Index is not just for loop prevention.  In the case of
>>> ambiguity, the index tells the SFF where in the path the packet currently resides.
>>> The Path Identifier is specifically not expected to include
>>> controller ID or Tenant ID.  While a deployer can have a path per
>>> tenant, the architecture still does not treat the path ID as a
>>> tenant ID.  Tenant ID, controller ID, and other non-path-specifying
>>> information is to be carried in metadata.
>>>
>>> Yours,
>>> Joel
>>>

This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur par courrier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 30 Jan 2015 22:53:17 +0000

Hello,

This is an interesting discussion and I would like to understand the
motivation of better. The trouble with a protocol document is that it is
typically has inadequate detail about the logic. So to cast this into
somewhat of a concrete terms, consider the following.

       SFF(x)  { Sfx(1) Sfx(2)…Sfx(n) }   ————>   SFF(y) { Sfy(1) Sfy(2)
…. Sfy(m) }   :: Logical Chain in ONE direction only.
       
       PHYSICAL WORLD:
          A) the SFF could be a
            - component of VSWITCH (pick your fav protocol for configuring
those entities }
            - A load balancer
            - A HW switch/router some L2/L3 combo

          B) Sf instance could be,
               - Virtual machine, #N of those
               - physical
               - Container #M which is often 5 or more x #N
               - Cluster that we don’t know

It is possible to have multiple physical SFF(x) also.

A selection of a given SF (service)(instance) is a can be simple or
complex. For example SFF(x) may have the best knowledge to select Sfx(1)
baed on a given criterion (which could be part of the policy).  Then I
don’t see a reason to have RSP.

It is possible that lookup (path) @ SFF(x) produces a specific instance of
Sfy and yes then something like RSP would be required. But I would argue
that job SFF(y) can also be subsumed by SFF(x).

Is it possible for a central controller to pick each instance of service,
but such an implementation tends to scale poorly. The amount of state,
probability of a instance going down between selection and flow arrival
goes up. 

Regards.

Sumandra

On 1/30/15, 3:38 AM, "Nicolas BOUTHORS" <[email-masked]>
wrote:

>Hello Cathy,
>
>Indeed the notion of "rendered service path ID"(RSP ID) seems relevant as
>the architecture document stipulates that the Service Function Path (SFP)
>provides an abstract notion of a service chain, while the RSP is a
>constrained list of locations.
>
>SFC header "Service Path Identifier" (SPI)  is used in both NSH and SCH
>protocol and in both case seem to identify to a particular SFP.
>
>Still NSH(v5)  shows that SPI (not a RSP ID)  should be part of the key
>element of an SFF to lookup on forwarding tables.  But I could not find
>in NSH  how to use the notion of
>An RSP ID (independent of the SPI but part of the same name space) could
>be used the same way as SPI by SFF for example, allowing a Service
>Classifier to control remote load balancing for example.
>
>This said the RSP ID values could be relative to a particular Service
>Path, which would prevent using them as we do for SPI in SFF forwarding
>tables.
>
>We may want to precise if the RSP ID is to be relative of absolute, as it
>should have an impact on forwarding table structure if we decide to use
>this concept.
>
>Personally I like the notion of a relative RSP ID, as we could then use
>some conventions, structure it, possibly extending its use.
>
>Nicolas
>
>We have uploaded a new SCH version (3) which adds definition of a new
>metadata type for the flow ID to support load balancing among SF
>instances and mitigate the potential issue of "not enough path ID". The
>flow ID is named "rendered service path ID" in the draft. Please refer to
>section 4.3.2 of https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/
>for detail description.
>
>In its previous version, SCH defines a "Bypass bit" in the base header.
>This bit enables the SF to provide feedback/notification via the data
>path to its connecting SFF about whether the remaining packets of the SFC
>should bypass that SF. This is useful in the case that only the first few
>packets of a flow need to go to a SF (such as a DPI or FW or IDS) and
>remaining packets can bypass that SF, thus saving the expensive SF
>resource and reducing data path latency.
>
>In addition, SCH defines a metadata type for Generic Context Block, which
>is optional and can be used if needed to carry any vendor's specific
>"Context Header".
>
>Ron, Louis, Myo and I have been discussing off line last few weeks about
>defining a metadata type for flow ID in addition to the path ID of the
>main header to support load balancing among SF instances. We will define
>a TLV type for the flow ID. The combination of "path ID + flow ID"
>specifies a realized service chain instance path. It is left to the
>design/implementation whether to use a centralized method or a
>distributed method to bind the flow ID to a realized service instance
>path although our original thought is for distributed LB usage. I am not
>sure if we need a bit in the header to denote whether there are more path
>ID bits (we call it flow ID) in the metadata fields since when you parse
>the TLV metadata, you will know whether there are flow ID bits or not.
>Note that if multiple sessions share the same realized service instance
>path, they will share the same "path ID+ flow ID".  We can also consider
>extending the number of bits to 32 if that is the consensus. We will post
>an updated draft describing these soon.
>
>Thanks,
>Cathy
>
>SRINI> I am not so sure about data plane efficiency.  Most of the
>processors work good if the number of bits are either 32 or 64.  If it is
>24 bits, then one needs to do masking and shifting before the value is
>used to do any lookup.   But, this discussion can go into different
>direction :-), it may not be good to go in that direction.
>
>SRINI> This is a good point.  This should work fine as long as there is
>way to convey in the main header that the extension to path ID is
>available in so and so TLV field.  That should work too.
>
>Thanks
>Srini
>
>This message and any attachments (the "message") are confidential,
>intended solely for the addressees. If you are not the intended
>recipient, please notify the sender immediately by e-mail and delete this
>message from your system. In this case, you are not authorized to use,
>copy this message and/or disclose the content to any other person.
>E-mails are susceptible to alteration. Neither Qosmos nor any of its
>subsidiaries or affiliates shall be liable for the message if altered,
>changed or falsified.
>
>Ce message et toutes ses pièces jointes (ci-après le "message")sont
>confidentiels et établis à l'intention exclusive de ses destinataires. Si
>vous avez reçu ce message par erreur, merci d’en informer immédiatement
>son émetteur par courrier électronique et d’effacer ce message de votre
>système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser,
>copier ce message et/ou en divulguer le contenu à un tiers. Tout message
>électronique est susceptible d'altération. Qosmos et ses filiales
>déclinent toute responsabilité au titre de ce message s'il a été altéré,
>déformé ou falsifié.

---

From: Srini Addepalli <[email-masked]>
Date: Sun, 1 Feb 2015 02:48:43 +0000

Hi Cathy,

I went through RSP section of the document.  RSP-ID can be used to represent the service function instance whereas "path identifier' can be used to represent the chain. New RSP-ID avoids overloading path ID with the SFIs.  That is good.

Was there any specific reason to call this as 'RSP-ID', instead of calling it as SFI-ID?

You have mentioned that RSP-ID as 2 bytes.  Could we leave the size be flexible instead of limiting the size to 2 bytes?

Thanks
Srini

-----Original Message-----
From: Cathy Zhang [mailto:[email-masked]] 
Sent: Thursday, January 29, 2015 11:44 AM
To: Cathy Zhang; Addepalli Srini-B22160; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: NS Srinivasa Murthy-B37840
Subject: RE: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi everyone,

Thanks,
Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Friday, December 05, 2014 11:47 AM
To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Thanks,
Cathy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Friday, December 05, 2014 7:17 AM
To: Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Thanks
Srini