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

From: Nicolas BOUTHORS <[email-masked]>
Date: Sun, 1 Feb 2015 17:10:49 +0000

I can understand that in many cases a local SFF appears best suited to take load balancing/rerouting decisions.

Still we should allow for the case where a remote SFF, such as the Classifier at the entrance point of the network, for example based on DPI or subscriber awareness, performs remote load balancing decision thanks to the transmission of the Rendered Service Path identifier. DPI capability may not be available in all SFF for example.

In addition the Rendered Service Path identifier can be used as a hash key by  SFF(y) load balancing decision. So it is also compatible with the notion of local load balancer.
Regards,

Nicolas

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]]
Sent: vendredi 30 janvier 2015 23:53
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

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.
>
>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,
>
>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
>
>
>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é.
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

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 20:21:23 +0000

Hi Sumandra,

I agree with you that more information can be added to the protocol document on some use case scenarios to make it clear on the usage of RSP-ID and Path-ID.

Just to make the realistic and complex scenario

IngressSFF-----SFF1-----SFF2-----EgressSFF

In virtual world, SFF1 could be frontending SFx-1, SFx-2, SFy-1 and SFF2 could be front ending SFx-3, SFy-2, SFz-1
For simplicity, assume that IngressSFF is a edge router (eg. Openstack Network Node)
EgressSFF is a virtual switch hosting set of Web Server VMs.
SFF1 and SFF2 are also virtual switches hosting SFx, SFy and SFz Service VMs.

Assuming that chain requires packets go to SFx, SFy and SFz,  IngressSFF (with the help of SFF controller) needs send the traffic to one of SFx-1, SFx-2 and SFx-3. Based on SF-x selection, ingress SFF sends the traffic to corresponding SFF.  If SFx-1 or SFx-2 is chosen, then the traffic is sent to SFF1.  If SFx-3 is chosen, then the traffic is sent to the SFF2. Next in the chain, selection needs to happen between SFy1 and SFy2.  Similarly for next service in the chain,   either SFF1 or SFF2 (with the help of controller) will send the traffic to SF-y. It does this by sending the traffic to SFF2 that is hosting the SF-z. And finally traffic needs to go to EgressSFF to deliver to destination web-server VM.

Essentially, a given SFF would need to be programmed with the information related to next SF.  That is where path ID, RSP-ID and Overlay networks would help - Path ID indicating the chain and RSP-ID indicating the SF instance AND  VxLAN destination IP indicating the next SFF. SFF Controller having the network wide visibility would program the SFFs appropriately. 

For example, on ingressSFF, flows are programmed with RSP-ID related to SFx service instances.  IngressSFF, as part of packet processing, adds the RSP-ID, Path_ID to the SCH header and encapsulates in VxLAN.  SFF1 and/or SFF2 are programmed with flows that match on PATH-ID and RSP-ID to send the traffic to right SFx instance. Essentially, previous SFF adds the SCH header related to next SF instances and hosting SFF uses that information to route the traffic to right SF instance.

On your concern about poor scalability :  SFF controller need not be a single entity.  It could be distributed and scale-out entity for performance scaling.   Also, controllers need not be informed of every fine granular flow. It could be based on 4-tuple or 3-tuple flows, thereby reducing the number of decisions logical controller need to make.  

I did not understand  your concern on " The amount of state, probability of a instance going down between selection and flow arrival goes up."  This seems to be important and can you elaborate?

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Friday, January 30, 2015 2:53 PM
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hello,

    
       
       PHYSICAL WORLD:
          A) the SFF could be a

          B) Sf instance could be,

Regards.

Sumandra

---

From: Srini Addepalli <[email-masked]>
Date: Sun, 1 Feb 2015 21:54:32 +0000

Hi,

I sent an response email few minutes back. RSP-ID and centralized logical controller are really going to help in cases where a given SF instances are not front ended by one SFF.

In NFV world, SFF is a virtual switch in servers.  It should not be assumed that all SF instances for a given SF would be hosted in one server.

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nicolas BOUTHORS
Sent: Sunday, February 01, 2015 9:11 AM
To: Sumandra Majee; Cathy Zhang; [email-masked]'
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Nicolas

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]]
Sent: vendredi 30 janvier 2015 23:53
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hello,

       PHYSICAL WORLD:
          A) the SFF could be a

          B) Sf instance could be,

Regards.

Sumandra

---

From: Henry Fourie <[email-masked]>
Date: Mon, 2 Feb 2015 19:12:42 +0000

Srini,
    The RSP Identifier refers to the Rendered Service Path (RSP) as defined in
Section 1.3 of the SFC architecture draft:

https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

The RSP is a constrained SFP. The RSP ID is 32 bits.
See section 4.3.2 Rendered Service Path Identifier in

 - Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Saturday, January 31, 2015 6:49 PM
To: Cathy Zhang; 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 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,

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". 

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)

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

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

>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.

>view, assumption that there will be LB SF for each scale-out service in 
>the chain is not valid in all cases.
>
>Thanks
>Srini
>
>the device providing the service sits on. Well, at least from a GPE+NSH perspective.
>
>
>>combinations of services and the policies for service function selection.
>>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.
>>>to tenant/controller/flow/scale-out.  But SFC controllers should keep these
>>> ambiguity, the index tells the SFF where in the path the packet currently resides.

---

From: Cathy Zhang <[email-masked]>
Date: Mon, 2 Feb 2015 21:57:37 +0000

Hi Nicolas,

Thank you for your comment. Please see inline for my reply.

Cathy

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]] 
Sent: Friday, January 30, 2015 3:38 AM
To: Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: RE: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

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
Rendered service path which was defined in the architecture document.

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.

Cathy> Yes, RSP ID is uniquely scoped within the service path ID. We will update this in the next version. 

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)

Thanks
Srini

---

From: Cathy Zhang <[email-masked]>
Date: Mon, 2 Feb 2015 22:40:33 +0000

Hi Srini,

You gave a very good example of how to use RSP ID which is in line with our thought when we added the RSP ID into the service chain header. 

Thanks,
Cathy

-----Original Message-----
From: Srini Addepalli [mailto:[email-masked]] 
Sent: Sunday, February 01, 2015 12:21 PM
To: Sumandra Majee; Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET; [email-masked]; Bharat Mota; Rajesh Kumar Madabushi
Subject: RE: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Sumandra,

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Friday, January 30, 2015 2:53 PM
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hello,

    
       
       PHYSICAL WORLD:
          A) the SFF could be a

          B) Sf instance could be,

Regards.

Sumandra

---

From: Cathy Zhang <[email-masked]>
Date: Mon, 2 Feb 2015 22:42:02 +0000

Hi Sumandra,

Thank you for your comments. Please see inline. 

Cathy

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Friday, January 30, 2015 2:53 PM
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

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.

       
       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,

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.

Cathy> RSP ID is used by SFF to identify a rendered path of service instances. So Even SFF have the best knowledge to select the SFx, 
Cathy> after the SFF selects the SFx and binds it to the RSP ID, follow-on packets can just be forwarded based on RSP ID. 

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).

Cathy> I do not get what you mean here. Could you clarify? 

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.
>
>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.
>
>Path, which would revent 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.
>
>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.
>
>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"
>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.
>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
>
>processors work good if the number of bits are either 32 or 64.  If it is
>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.
>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: Henry Fourie <[email-masked]>
Date: Mon, 2 Feb 2015 23:34:32 +0000

Srini,
    In your example I presume that Sfx-, SFy- and SFz- are all instances of the
same type of SF, eg., Sfx- are all instances of a FW. So, in the example, you have
instances of a given type, eg, SFx- homed on two different SFFs. SFx1 and SFx2 are
homed on SFF1 and SFx3 is homed on SFF2. This can be done but adds complexity to
an implementation where a SFF may want to do load-balancing over a group of SFs.

An alternative configuration would be where SFs of a given type are all homed
on the same SFF, eg, SFx1-3 are all homed on SFF1, allowing it to perform load-balancing
across this set of SF instances. 

Section 4.3.2 of the SCH draft describes the use of the RSP ID in this case.
Each SFF may perform a late binding of each SF instance to a RSP through the hop-by-hop selection
of the SF instances by the SFFs as the first packet for a flow traverses the chain.
  
 - Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Sunday, February 01, 2015 12:21 PM
To: Sumandra Majee; Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: [email-masked]; Jerome TOLLET; Rajesh Kumar Madabushi; Bharat Mota
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Sumandra,

In virtual world, SFF1 could be frontending SFx-1, SFx-2, SFy-1 and SFF2 could be front ending SFx-3, SFy-2, SFz-1 For simplicity, assume that IngressSFF is a edge router (eg. Openstack Network Node) EgressSFF is a virtual switch hosting set of Web Server VMs.
SFF1 and SFF2 are also virtual switches hosting SFx, SFy and SFz Service VMs.

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Friday, January 30, 2015 2:53 PM
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hello,

    
       
       PHYSICAL WORLD:
          A) the SFF could be a

          B) Sf instance could be,

Regards.

Sumandra

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Tue, 3 Feb 2015 02:47:13 +0000

I wouldn¹t make a categorical statement such as this, it is just one
possibility.

Surendra.

On 2/1/15, 1:54 PM, "Srini Addepalli" <[email-masked]> wrote:

>In NFV world, SFF is a virtual switch in servers.

---

From: Srini Addepalli <[email-masked]>
Date: Tue, 3 Feb 2015 06:33:10 +0000

Hi Louis,

In Openstack based NFV world,  NOVA, based on its scheduling policy and filters, can create vNF instances in various servers.  It means that instances of one SF can be in various servers and it means that multiple SFFs may be front ending one service.  My only point was that, this is a big possibility and that is where centralized logical controller would come in handy in allocating RSP IDs and programming them in SFFs in those cases.

In physical deployments, one could have one SFF front ending all physical SF instances.  Here late binding works as same SFF is going to select the SF Instance as well use it for further packets.

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Henry Fourie
Sent: Monday, February 02, 2015 3:35 PM
To: Addepalli Srini-B22160; Sumandra Majee; Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: NS Srinivasa Murthy-B37840; Jerome TOLLET; Madabushi Rajesh Kumar-B38870; Mota Bharat-B19479
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Srini,
    In your example I presume that Sfx-, SFy- and SFz- are all instances of the same type of SF, eg., Sfx- are all instances of a FW. So, in the example, you have instances of a given type, eg, SFx- homed on two different SFFs. SFx1 and SFx2 are homed on SFF1 and SFx3 is homed on SFF2. This can be done but adds complexity to an implementation where a SFF may want to do load-balancing over a group of SFs.

An alternative configuration would be where SFs of a given type are all homed on the same SFF, eg, SFx1-3 are all homed on SFF1, allowing it to perform load-balancing across this set of SF instances.

Section 4.3.2 of the SCH draft describes the use of the RSP ID in this case.
Each SFF may perform a late binding of each SF instance to a RSP through the hop-by-hop selection of the SF instances by the SFFs as the first packet for a flow traverses the chain.

 - Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Sunday, February 01, 2015 12:21 PM
To: Sumandra Majee; Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: [email-masked]; Jerome TOLLET; Rajesh Kumar Madabushi; Bharat Mota
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Sumandra,

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Friday, January 30, 2015 2:53 PM
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hello,

       PHYSICAL WORLD:
          A) the SFF could be a

          B) Sf instance could be,

Regards.

Sumandra

---

From: Srini Addepalli <[email-masked]>
Date: Tue, 3 Feb 2015 06:33:00 +0000

Sure :-).

I have heard that ToR switches are also used to switch traffic among VMs even if they are on a server.

In any case, my point of previous email is that multiple SFFs can be front ending different instances of a service.

Thanks
Srini

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Monday, February 02, 2015 6:47 PM
To: Addepalli Srini-B22160; Nicolas BOUTHORS; Sumandra Majee; Cathy Zhang; [email-masked]'
Cc: NS Srinivasa Murthy-B37840; Madabushi Rajesh Kumar-B38870; Mota Bharat-B19479
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

I wouldn¹t make a categorical statement such as this, it is just one possibility.

Surendra.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 3 Feb 2015 14:19:34 +0000

> On Jan 30, 2015, at 6:38 AM, Nicolas BOUTHORS <[email-masked]> wrote:
> 
> Hello Cathy,
> 

Nicolas, thanks for reading NSH-05, I just want to clarify the RSP / SPI discussion in that context.

Architecturally, the definition of rendered path does not imply the need of an RSP ID, and the SPF ID can represent the path to be rendered in the network.  We’ve found this to be true in implementation.  If however, you feel that additional granularity is required, for load balancing for example, an additional ID (RSP or flow in some cases) is easily carried in NSH.

I’m sure the architecture draft authors can weigh in as needed as well.

<trimmed below for readability>

Thanks,
Paul

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 Feb 2015 15:37:50 +0000

Hi,

[Top-post responding, not addressed to any message in particular but making a generic comment]

Since the architecture document got cited a couple of times in this thread, my view is that the fact that the arch document defines an RSP does not imply that there ought to be an RSP Identifier, less so one carried in the dataplane.

The real question is what cannot be done with a Service Path ID, in terms of both functionality and scaling — to me, a hierarchical set of identifiers (“ RSP ID values could be relative to a particular Service Path”) seems over-engineering, and an independent allocation can create conflicts.

In other words, what problem are we solving?

Thanks,

— Carlos.

---

From: Ron Parker <[email-masked]>
Date: Tue, 3 Feb 2015 15:48:51 +0000

Srini,

Late binding could also be used for the more general case of equivalent SF instances hosted on multiple SFF's.   It does, however, require a more sophisticated decision making at each previous hop.  During the trail blazing (i.e., first packet with a particular {SFP ID, RSP ID}), the classifier selects one SFF amongst those that host the first SF type.   That SFF must choose the SFF (perhaps itself) that hosts the second SF type, etc.   I'm not saying that central orchestration is precluded, just that late-binding/trail-blazing is possible and worth allowing from an architectural perspective.

The previous comment regarding whether SFF's are realized on commodity class switches is relevant here.   Absolutely that is one approach and realities of that approach perhaps push you towards desiring central orchestration.   But, it is not the only approach that could be realized.    There is such a breadth of application for SFC (i.e., enterprises, carriers) that allowing for different deployment strategies within the architecture is very valuable.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Tuesday, February 3, 2015 1:33 AM
To: Henry Fourie; Sumandra Majee; Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: [email-masked]; Jerome TOLLET; Rajesh Kumar Madabushi; Bharat Mota
Subject: [GRAYMAIL] Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Louis,

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Henry Fourie
Sent: Monday, February 02, 2015 3:35 PM
To: Addepalli Srini-B22160; Sumandra Majee; Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: NS Srinivasa Murthy-B37840; Jerome TOLLET; Madabushi Rajesh Kumar-B38870; Mota Bharat-B19479
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Srini,

 - Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Sunday, February 01, 2015 12:21 PM
To: Sumandra Majee; Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: [email-masked]; Jerome TOLLET; Rajesh Kumar Madabushi; Bharat Mota
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Sumandra,

Thanks
Srini

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Friday, January 30, 2015 2:53 PM
To: Nicolas BOUTHORS; Cathy Zhang; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hello,

       PHYSICAL WORLD:
          A) the SFF could be a

          B) Sf instance could be,

Regards.

Sumandra

---

From: Ron Parker <[email-masked]>
Date: Tue, 3 Feb 2015 15:59:40 +0000

Carlos,

I agree that single level vs. dual level identifier in the data plane is a worthwhile discussion.   Related to this -- within the architecture, to my knowledge, both central orchestration and hop-by-hop load balancing/resiliency selection is allowed.   

In a centrally orchestrated approach, a single level identifier abstracting the concrete sequence of hops is sufficient.   I would propose that this single level identifier would be better called the RSP ID than the SFP ID, since SFP, by definition is not necessarily fully concrete/specified in terms of exact hop sequence.

In a distributed hop-by-hop (trail-blazed) approach to load balancing and resiliency, a 2-level identifier is very useful.   The SFP ID describes the sequence of SF's in terms of types, but not necessarily instances.   It is allowed to convey policy with respect to exact instances, and that policy could be fully concrete or could be merely describing subsets (i.e., one of the "orange" IDS/IPS followed by one of the "purple" firewalls).    In order to assist the SFF's to make this decision, they would require not only the policy under which they are working to make this decision (i.e., SFP ID), but also a value that could be used to repeat the actual selections (i.e., RSP ID).   In this approach, the {SFP ID, RSP ID} tuple is interpreted as "all packets with this tuple value must traverse the exact same concrete sequence".

In my view, the architecture, as it stands today, allows for both approaches -- centralized path management and distributed path management.   Furthermore, both are valid and worthwhile.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, February 3, 2015 10:38 AM
To: Nicolas BOUTHORS
Cc: Cathy Zhang; Jerome TOLLET; [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi,

Thanks,

— Carlos.

> 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.
> 
>>> 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
>>> 
>>> 
>>> 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.
>>>> Hence, I was wondering whether path ID can be extended to 64 bits 
>>>> or make it flexible.
>>>> 
>>>> Thanks
>>>> Srini
>>>>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Tue, 3 Feb 2015 17:15:00 +0000

Not an author, but you could use the Network Shared Context for it.

On 2/3/15, 9:19 AM, "Paul Quinn (paulq)" <[email-masked]> wrote:

>>(SFP) provides an abstract notion of a service chain, while the RSP is a
>Architecturally, the definition of rendered path does not imply the need
>of an RSP ID, and the SPF ID can represent the path to be rendered in the
>network.  We¹ve found this to be true in implementation.  If however, you
>feel that additional granularity is required, for load balancing for
>example, an additional ID (RSP or flow in some cases) is easily carried
>in NSH.
>
>I¹m sure the architecture draft authors can weigh in as needed as well.
>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Tue, 3 Feb 2015 18:08:31 +0000

As a general comment on this submission (and perhaps life in the current
IETF).  I have a REALLY hard time differentiating this draft from the
quinn draft (which pre-dates it by quite a bit).  Why are we pursuing a
separate draft when the suggestions, IMHO, seem incremental at best?

I have reach out to the chairs here … we have a lot to read. Aren’t drafts
supposed to offer significantly different views if they are to persist
(without that, a “call to adopt” becomes a beauty contest, IMO)?  No
offense to the authors, but we’re in revision 3 and I don’t see that here.

Regarding the changes in this document:

I do not find the flow ID functionally different than the use context
headers in the nsh draft, which seem to be a more multi-purpose concept.

The B bit suggestion can cause a conflict in control and create an avenue
for undesirable behavior, IMO.  I’ve been working from the assumption that
a minimum requirement of a function is that it be manageable (if for no
other reason than effective elasticity and cohesive/predictable delivery
of service), so I have little sympathy for those that are not - be they
virtual or physical (even less sympathy for virtual functions that are
unmanageable, frankly).  A self-management option in the SFC scenario has
low value and the corruption or misuse of the bit can cause chaos (an
extra level of “fail”).

The Generic Context Block is confusing in light of the already extant
optional/variable metadata TLVs (why wouldn’t you leverage one of them)?

On 1/29/15, 2:44 PM, "Cathy Zhang" <[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).
>>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.
>>
>>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.
>>
>>
>>>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
>>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 Feb 2015 19:43:41 +0000

Hi, Ron,

Thanks for the follow-up — My main point is that the architecture defining (yet not using) the term RSP does not imply there has to be an explicit identifier for it.

What you describe below seems to be the passing of granular context for a classification coloring or for a pseudo-flow, for which context headers and metadata seem to give that extensibility. To me, use cases are useful but not necessarily universally applicable — in which case is best to design for the generic path id and not overgeneralize functionality (that can be solved without defining a new identifier). 

Thanks!

— Carlos.

> On Feb 3, 2015, at 10:59 AM, Ron Parker <[email-masked]> wrote:
> 
> Carlos,
>

---

From: Cathy Zhang <[email-masked]>
Date: Tue, 3 Feb 2015 21:54:27 +0000

Hi Ken,

Please see inline.

Thanks,
Cathy

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]] 
Sent: Tuesday, February 03, 2015 10:09 AM
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)

Cathy> The original motivation for drafting the SCH is to provide an alternative to draft-quinn-nsh to address the following perceived issues:
1. Mandatory fixed-sized metadata. We think they should not be mandatory since the 4-word context fields are not needed in many scenarios 
2. No variable length metadata. We think metadata should be optional and TLV format should be used to define metadata 
3. No organizationally defined metadata 
4. No Version field.  
When we uploaded SCH 1st version (3/24/2014), NSH version did not have the TLV metadata and version field (they were added in its later version).

I have reach out to the chairs here . we have a lot to read. Aren't drafts
supposed to offer significantly different views if they are to persist
(without that, a "call to adopt" becomes a beauty contest, IMO)?  No
offense to the authors, but we're in revision 3 and I don't see that here.

Cathy> Different people have different viewpoints. RSP ID is not defined in NSH and from Paul (NSH author)'s reply, it seems he does not feel the need of an RSP ID. 
Cathy> We see the need for RSP ID and thus defined it in SCH for open discussion and would like to see the community's feedback on it.  

for undesirable behavior, IMO.  I've been working from the assumption that
extra level of "fail").

Cathy> Could you clarify what you mean by "cause a conflict in control"? 

The Generic Context Block is confusing in light of the already extant
optional/variable metadata TLVs (why wouldn't you leverage one of them)?

Cathy> I am not sure if I understand your point. The Generic Context Block is one type of metadata which is in TLV format and is optional. 

Thanks,
Cathy

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 3 Feb 2015 17:27:05 -0500

Hi Ken,
*

IETF90 minutes explain the differences then.
o

Yes, the drafts are now very similar because the NSH draft has incorporated the TLV portion.
o       The generic context block is to accommodate NSH's four mandatory context header fields.
*

The chairs are actively working on a merged document with a section for remaining differences.
Thanks,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: 3 February 2015 4:54 PM
To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'; Cathy Zhang
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Ken,

Please see inline.

Thanks,
Cathy

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 10:09 AM
To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

As a general comment on this submission (and perhaps life in the current IETF).  I have a REALLY hard time differentiating this draft from the quinn draft (which pre-dates it by quite a bit).  Why are we pursuing a separate draft when the suggestions, IMHO, seem incremental at best?

Cathy> The original motivation for drafting the SCH is to provide an alternative to draft-quinn-nsh to address the following perceived issues:
1. Mandatory fixed-sized metadata. We think they should not be mandatory since the 4-word context fields are not needed in many scenarios 2. No variable length metadata. We think metadata should be optional and TLV format should be used to define metadata 3. No organizationally defined metadata 4. No Version field.
When we uploaded SCH 1st version (3/24/2014), NSH version did not have the TLV metadata and version field (they were added in its later version).

I have reach out to the chairs here . we have a lot to read. Aren't drafts supposed to offer significantly different views if they are to persist (without that, a "call to adopt" becomes a beauty contest, IMO)?  No offense to the authors, but we're in revision 3 and I don't see that here.

I do not find the flow ID functionally different than the use context headers in the nsh draft, which seem to be a more multi-purpose concept.

The B bit suggestion can cause a conflict in control and create an avenue for undesirable behavior, IMO.  I've been working from the assumption that a minimum requirement of a function is that it be manageable (if for no other reason than effective elasticity and cohesive/predictable delivery of service), so I have little sympathy for those that are not - be they virtual or physical (even less sympathy for virtual functions that are unmanageable, frankly).  A self-management option in the SFC scenario has low value and the corruption or misuse of the bit can cause chaos (an extra level of "fail").

The Generic Context Block is confusing in light of the already extant optional/variable metadata TLVs (why wouldn't you leverage one of them)?

Thanks,
Cathy

On 1/29/15, 2:44 PM, "Cathy Zhang" <[email-masked]<mailto:[email-masked]>> wrote:

>Cc: [email-masked]<mailto:[email-masked]>
>Cc: [email-masked]<mailto:[email-masked]>
>From: Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>>
>On 12/5/14, 6:54 AM, "Srini Addepalli" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>
>>From: Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>>
>>To: Addepalli Srini-B22160; Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>>On 12/4/14, 12:57 PM, "Srini Addepalli" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>>more services in the chain or more chains or more instances for
>>>scale-out, then it could go to big number very fast.
>>>
>>>To: Addepalli Srini-B22160; Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>>>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
>>>
>>>> From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
>>>> To: Addepalli Srini-B22160; [email-masked]<mailto:[email-masked]>
>>>>> [email-masked]<mailto:[email-masked]>
>>>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 4 Feb 2015 00:20:56 +0000

Respectfully, I don’t think TLVs were a unique proposition, as these were discussed informally in meetings (that I did attend) … have to search the list for “TLV” uniqueness.  Regardless, we shouldn’t have had to read three iterations of another document just to get that addition.

Regarding remaining differences … I don’t really see any, which makes “merge” a really inappropriate word for what’s required.

If “merge” means “time”, I see no reason to delay a call for support of the nsh draft.

On 2/3/15, 5:27 PM, "Zarny, Myo" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ken,

  *   IETF90 minutes explain the differences then.

  *   Yes, the drafts are now very similar because the NSH draft has incorporated the TLV portion.
  *   The generic context block is to accommodate NSH's four mandatory context header fields.

  *   The chairs are actively working on a merged document with a section for remaining differences.

Thanks,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: 3 February 2015 4:54 PM
To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]<mailto:[email-masked]>'; Cathy Zhang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Ken,

Please see inline.

Thanks,
Cathy

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 10:09 AM
To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]<mailto:[email-masked]>'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Thanks,
Cathy

On 1/29/15, 2:44 PM, "Cathy Zhang" <[email-masked]<mailto:[email-masked]>> wrote:

>[email-masked]<mailto:[email-masked]>'
>To: Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]<mailto:[email-masked]>'
>To: Addepalli Srini-B22160; Joel M. Halpern; [email-masked]<mailto:[email-masked]>'

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Feb 2015 19:28:53 -0500

I very much agree with ken's comments below. There is no reason to merge the drafts other than waste everyone's time. If you have something substantive to contribute, go head and specify that very specific change. However, coming up with a draft that is what appears to be %95 the same as the other one does not seem like a good reason to merge drafts. You typically only do this when there are two very different approaches that the WG wants combined. This does not seem like that to me.

Tom 

> On Feb 3, 2015, at 7:20 PM, Ken Gray (kegray) <[email-masked]> wrote:
> 
> On 2/3/15, 5:27 PM, "Zarny, Myo" <[email-masked]> wrote:
> 
> Hi Ken,
> The generic context block is to accommodate NSH's four mandatory context header fields.

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 4 Feb 2015 00:56:25 +0000

Cathy> RSP ID is used by SFF to identify a rendered path of service
instances. So Even SFF have the best knowledge to select the SFx,
Cathy> after the SFF selects the SFx and binds it to the RSP ID, follow-on
packets can just be forwarded based on RSP ID.

So RSP IS is a state that is local to SFF(x). My point is that in that
case there is no reason to *SHARE* the state. If you are looking to bind
all pkts for given flow/app/transaction etc. then please look at
https://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-dc-allocation and
more specifically at ServiceTag portion of it

This is an example on how to carve out the shared context and tag flows
etc. 

If a controller wants to preselect a particular SF(x) instance then it can
use NSH shared context if necessary.

On 2/2/15, 2:42 PM, "Cathy Zhang" <[email-masked]> wrote:

>Cathy> RSP ID is used by SFF to identify a rendered path of service
>instances. So Even SFF have the best knowledge to select the SFx,
>Cathy> after the SFF selects the SFx and binds it to the RSP ID,
>follow-on packets can just be forwarded based on RSP ID.
>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 4 Feb 2015 00:59:08 +0000

In, line ….

On 2/3/15, 4:54 PM, "Cathy Zhang" <[email-masked]> wrote:

>Cathy> The original motivation for drafting the SCH is to provide an
>alternative to draft-quinn-nsh to address the following perceived issues:
>1. Mandatory fixed-sized metadata. We think they should not be mandatory
>since the 4-word context fields are not needed in many scenarios
>2. No variable length metadata. We think metadata should be optional and
>TLV format should be used to define metadata
>When we uploaded SCH 1st version (3/24/2014), NSH version did not have
>the TLV metadata and version field (they were added in its later version).

<keg> This could have been ironed out with the authors on the list without
a separate document.  The authors were pre-disposed to the idea of
optional/variable metadata early on - I know because this was discussed
during informal review while I was in another company.  They had agreed to
address it in a later release if it was supported on the list.  I’m pretty
sure I was not the only one to provide that feedback.

>Cathy> Different people have different viewpoints. RSP ID is not defined
>in NSH and from Paul (NSH author)'s reply, it seems he does not feel the
>need of an RSP ID.
>Cathy> We see the need for RSP ID and thus defined it in SCH for open
>discussion and would like to see the community's feedback on it.

<keg> If there are varying opinions about it, that’s even a stronger
argument to use the Network Context rather than a dedicated field, IMO.

>Cathy> Could you clarify what you mean by "cause a conflict in control"?

<keg> If the premise of the system is that the element is managed (within
a chain) for the purposes of agility/elasticity/goodness-and-light and
that a higher power is managing the setup of flows, having the ability for
the node to autonomously remove itself is unnecessary and dangerous.  It
allows the node to do things the management system may not expect or react
to (or be capable of reacting to) creating a conflict over who/what
actually controls the efficacy of the chain.

>Cathy> I am not sure if I understand your point. The Generic Context
>Block is one type of metadata which is in TLV format and is optional.

<keg> Why do we need to define the optional metadata and how is it
significantly different from the context block already proposed in nsh?

>>>2^64,
>>>you
>>>SFFs
>>>>of
>>>>to
>>>>>controller

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Wed, 4 Feb 2015 01:00:09 +0000

I have to second Ken and Tom. If there is functionality that is not supported by draft Quinn, I propose the additional functions  be brought to the list/group as additional proposals to extend draft Quinn. We can then discuss those additions.

The authors have been working with others, myself included, to build broad consensus the draft Quinn represents. Thus, I see no reason to delay the call for support of the NSH draft.

Andrew

Sent from my iPhone

On Feb 3, 2015, at 7:29 PM, Thomas Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

Tom

On Feb 3, 2015, at 7:20 PM, Ken Gray (kegray) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ken,

Thanks,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: 3 February 2015 4:54 PM
To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]<mailto:[email-masked]>'; Cathy Zhang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Ken,

Please see inline.

Thanks,
Cathy

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 10:09 AM
To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]<mailto:[email-masked]>'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Thanks,
Cathy

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 4 Feb 2015 16:12:36 +0000

The ONF , as well as Openstack share the idea of defining abtract chains, which then get instanciated in concrete instance many times.

So it is likely that they can generate identifiers both the Service Path and a Rendered Service Path.  I think we should take benefit of this alignment, and avoid generating a new concepts such as a Service Tag or Service Class, limited to a particular use case.

The header defined in draft-guichard-sfc-nsh-dc-allocation is useful in many ways, but has many implications in how the policies deployed in a DC are organized.  It is mentioned for example that ServiceTag can be used for multiple purposes orthogonal one to the others. How would an SFF know that the service class should be used for load balancing purposes ?

We have with the RSP ID a clear concept, more precise than the SPI even. We know can be filled by upper level entities, and that some use cases like enabling remote load balancing could take advantage of it. Why not make it available clearly ?

Besides remote load balancing, an RSP ID can be useful when a service chain is setup between two organizations (each with its Orchestration layer). No need to pass additional information (tenant Id, ...) to recover a local context.

Nicolas

Remote LBS:   Allow a Service  Function or the Classifier to load balance traffic within a Service Chain (same SPI) by distributing the traffic to various Rendered Service Path (RSP ID) based on its own internal criteria, so that a remote SFF ends up forwarding the traffic to corresponding Service Function Instances.

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]]
Sent: mercredi 4 février 2015 01:56
To: Cathy Zhang; Nicolas BOUTHORS; [email-masked]'
Cc: Jerome TOLLET
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Cathy> follow-on

So RSP IS is a state that is local to SFF(x). My point is that in that case there is no reason to *SHARE* the state. If you are looking to bind all pkts for given flow/app/transaction etc. then please look at https://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-dc-allocation and more specifically at ServiceTag portion of it

This is an example on how to carve out the shared context and tag flows etc.

If a controller wants to preselect a particular SF(x) instance then it can use NSH shared context if necessary.

On 2/2/15, 2:42 PM, "Cathy Zhang" <[email-masked]> wrote:

>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.
>
>
>
>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
>
>
>
>>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.
>>
>>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
>>Personally I like the notion of a relative RSP ID, as we could then
>>use some conventions, structure it, possibly extending its use.
>>
>>Nicolas
>>
>>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
>>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> This is a good point.  This should work fine as long as there
>>SRINI> is
>>> I think bigger point is that why restrict this in the standards?
>>>What advantage do we have restricting this size to 24 bits?
>>
>>>> While that can be a large number, I sure hope it does not come
>>>>close to saturating 24 bits.
>>>>
>>>>> tenant ID.  Tenant ID, controller ID, and other
>>>>> non-path-specifying information is to be carried in metadata.
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>>> Based on our experience in traffic steering,  this path
>>>>>>identifier needs to encode good amount of information to make it
>>>>>>unique.  For example,

---

From: "Elzur, Uri" <[email-masked]>
Date: Thu, 5 Feb 2015 05:46:14 +0000

Assuming the issues listed below are the complete set of "delta" between the drafts, it makes sense to reach out to NSH authors and try to reach an acceptable compromise, which is part of the standardization process. I do not see in that list a fundamentally different approach that warrants another draft, it seems like feature level disagreement/ preference difference etc. It can also be discussed on the ml or during the next meeting

I'll join other who mentioned we should go ahead w NSH draft
Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Tuesday, February 3, 2015 1:54 PM
To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; [email-masked]'; Cathy Zhang
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Ken,

Please see inline.

Thanks,
Cathy

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 10:09 AM
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)

Thanks,
Cathy

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 6 Feb 2015 05:36:35 +0000

Same here. Not sure why we are still playing "where's is Waldo?" across
these two drafts. 

On 2/4/15, 9:46 PM, "Elzur, Uri" <[email-masked]> wrote:

>Assuming the issues listed below are the complete set of "delta" between
>the drafts, it makes sense to reach out to NSH authors and try to reach
>an acceptable compromise, which is part of the standardization process. I
>do not see in that list a fundamentally different approach that warrants
>another draft, it seems like feature level disagreement/ preference
>difference etc. It can also be discussed on the ml or during the next
>meeting
>
>since the 4-word context fields are not needed in many scenarios 2. No
>variable length metadata. We think metadata should be optional and TLV
>format should be used to define metadata 3. No organizationally defined
>metadata 4. No Version field.
>I have reach out to the chairs here . we have a lot to read. Aren't
>drafts supposed to offer significantly different views if they are to
>persist (without that, a "call to adopt" becomes a beauty contest, IMO)?
>No offense to the authors, but we're in revision 3 and I don't see that
>here.
> 
>
>for undesirable behavior, IMO.  I've been working from the assumption
>that a minimum requirement of a function is that it be manageable (if for
>no other reason than effective elasticity and cohesive/predictable
>delivery of service), so I have little sympathy for those that are not -
>be they virtual or physical (even less sympathy for virtual functions
>that are unmanageable, frankly).  A self-management option in the SFC
>scenario has low value and the corruption or misuse of the bit can cause
>chaos (an extra level of "fail").
>