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

From: Srini Addepalli <[email-masked]>
Date: Thu, 4 Dec 2014 15:02:00 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Dec 2014 10:42:59 -0500

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

---

From: Dave Dolson <[email-masked]>
Date: Thu, 4 Dec 2014 16:16:15 +0000

Joel,

> While a deployer can have a path per tenant, the architecture still does not treat the path ID as a tenant ID.

Is this spelled out in draft-ietf-sfc-architecture-02? 
I might have glossed over it, but searching reveals no mention of the word "tenant".

I'd been thinking the ability to attach a tenant to a path ID was a point of configuration within an SF.

One reason I ask is that metadata probably wouldn't be sent to so-called "legacy SF".

-Dave

________________________________________
From: sfc [[email-masked]] on behalf of Joel M. Halpern [[email-masked]]
Sent: Thursday, December 04, 2014 10:42 AM
To: Srini Addepalli; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Dec 2014 11:20:19 -0500

The ability to cause a tenants traffic to use a particular (single or 
set of) service path(s) is there.  That has nothing to do with whether 
the path identifier can be treated by the SFs as a tenant ID.  Unless 
you couple the SF behavior to specific deployment and specific 
implementations (which is not the point of a standard) the WFs can not 
treat the Path ID as a tenant ID.

I don't see what this has to do with legacy support, since a legacy SF 
won't get the path ID or the metadata.  It will be the proxy's job to 
determine how to render any needed identification to the legacy (and it 
will likely be different for different legacy SF implementations.)

Yours,
Joel

---

From: Srini Addepalli <[email-masked]>
Date: Thu, 4 Dec 2014 19:01:57 +0000

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)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Dec 2014 15:04:30 -0500

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

---

From: Ron Parker <[email-masked]>
Date: Thu, 4 Dec 2014 20:29:54 +0000

While this is subtle, I agree with Joel.   Policy may be that a particular path ID is used on behalf of a single "tenant", but path ID isn't intended to directly convey the identity of the tenant in any meaningful manner.   For that, metadata is perfectly suited.   In the SCH draft, there are 2 approaches to identifying the metadata type that conveys the tenant id.   In the first, an IANA registration may be made to globally define the TLV ID, type, and length.   In the second, a vendor OUI may be used to convey the assigning authority.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 4, 2014 11:20 AM
To: Dave Dolson; Srini Addepalli; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

The ability to cause a tenants traffic to use a particular (single or set of) service path(s) is there.  That has nothing to do with whether the path identifier can be treated by the SFs as a tenant ID.  Unless you couple the SF behavior to specific deployment and specific implementations (which is not the point of a standard) the WFs can not treat the Path ID as a tenant ID.

I don't see what this has to do with legacy support, since a legacy SF won't get the path ID or the metadata.  It will be the proxy's job to determine how to render any needed identification to the legacy (and it will likely be different for different legacy SF implementations.)

Yours,
Joel

On 12/4/14, 11:16 AM, Dave Dolson wrote:
> Subject: Re: [sfc] Comments on SCH Draft 
> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)
>
>> Based on our experience in traffic steering,  this path identifier 
>> needs to encode good amount of information to make it unique.  For example,
>>    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,

---

From: Srini Addepalli <[email-masked]>
Date: Thu, 4 Dec 2014 20:57:15 +0000

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

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 4 Dec 2014 21:17:19 +0000

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
>
>
>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.
>
>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
>>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: Sharon <[email-masked]>
Date: Thu, 4 Dec 2014 16:29:59 -0800

That's correct.

 If we take load balancing out of (the base of) the permutation equation -
which would be a great  ..
then 24 bits is equivalent to yes/no for 24 functions. 

Enough today but given good standard sfc solution the a trend of "everything is a middle box" can push this limit. 

--szb

> On Dec 4, 2014, at 12:04 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 5 Dec 2014 01:54:04 +0000

Since the path-id-based SFC approach requires SFFs to maintain path states, if the total number of paths within an SFC domain is very large, it'd better for us to consider how to replace stateful SFC approaches with stateless SFC approaches, just as what SPRING and BIER have done for MPLS-TE and multicast services.

Best regards,
Xiaohu

> From: sfc [mailto:[email-masked]] On Behalf Of Sharon
> Sent: Friday, December 05, 2014 8:30 AM
> To: Joel M. Halpern
> Cc: [email-masked]; Srini Addepalli; [email-masked]
>  If we take load balancing out of (the base of) the permutation equation - which
> would be a great  ..
> > 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
> >
> 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
> >>
> >> 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: "Zarny, Myo" <[email-masked]>
Date: Fri, 5 Dec 2014 09:06:13 -0500

Hi Xiaohu,

I don't think we can necessarily equate being stateless to a smaller number of path IDs. Traffic flows can be stateless (or stateful) and still have the same number of paths. To me, the number of paths is a function of policy, not necessarily that of statefulness/statelessness of the flows.

I think you mean devolving forwarding decision making to the SFFs, which can make their own decision as to which of the SF instances (of the same service function) the traffic needs to be forwarded, (thereby potentially reducing the number of explicit path IDs) right? Potentially because the SFFs could still enforce statefulness locally. To me, that's centralized vs decentralized path identification/forwarding (as opposed to stateful and stateless).

Anyway, I do agree with the overall point that we should also consider approaches that could reduce the total number of paths.

Regards,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: 4 December 2014 8:54 PM
To: Sharon; Joel M. Halpern
Cc: [email-masked]; Srini Addepalli; [email-masked]
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Best regards,
Xiaohu

> Cc: [email-masked]<mailto:[email-masked]>; Srini Addepalli; [email-masked]<mailto:[email-masked]>
>  If we take load balancing out of (the base of) the permutation
> equation - which would be a great  ..
> Enough today but given good standard sfc solution the a trend of
> "everything is a middle box" can push this limit.
>
> --szb
>
> > On Dec 4, 2014, at 12:04 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> 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.
> >
> 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
> 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]<mailto:[email-masked]>>
> >> To: Addepalli Srini-B22160; [email-masked]<mailto:[email-masked]>
> >> 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.
> >> tenant, the architecture still does not treat the path ID as a
> >> tenant ID.  Tenant ID, controller ID, and other non-path-specifying
> >>> [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: Srini Addepalli <[email-masked]>
Date: Fri, 5 Dec 2014 14:54:23 +0000

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?

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)

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 5 Dec 2014 15:08:50 +0000

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: Srini Addepalli <[email-masked]>
Date: Fri, 5 Dec 2014 15:16:38 +0000

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

---

From: Dave Dolson <[email-masked]>
Date: Fri, 5 Dec 2014 16:58:52 +0000

Speaking to efficiency, note that a 24-bit field could be implemented by indexing into an array, whereas a 64-bit field would certainly require a hash-based approach (CAM).

Today, I think 32 bits is a bit large for index lookup. This may change in the next few years.

Suppose an SFF could report its maximum number of supported IDs, which would be numbered from 0...MAX ?
This would allow a wide field in the protocol, but also efficient implementations that have a limited memory.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Srini Addepalli
Sent: Friday, December 05, 2014 10: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: Sharon <[email-masked]>
Date: Fri, 5 Dec 2014 11:06:20 -0800

Think the tradeoffs are well stated.
Centralization and large or stacked headers do simplify forwarding,
but:

- compiling instances into the path depletes IDs quickly
- there's not enough state for the SFF to self-heal 
- very complex to manage, changes to often

SFFs will most likely have flow tables these days,
that's enough state to pin instances affinity.

The result is not distributed load balancing and high availability,
but also much simpler scheduling of allocated resources.
Whatever capacity is allocated will be filled evenly by the network.
This makes the centralized tasks like the orchestration "Tetris" simpler -
and consequently the network more valuable.

--szb

> On Dec 5, 2014, at 06:06, Zarny, Myo <[email-masked]> wrote:
> 
> Hi Xiaohu,
>

---

From: Cathy Zhang <[email-masked]>
Date: Fri, 5 Dec 2014 19:46:38 +0000

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)

Thanks
Srini

---

From: Ron Parker <[email-masked]>
Date: Fri, 5 Dec 2014 20:24:35 +0000

I think the SFF can simply look for the FlowID TLV (Quinn's arguments about hardware parsing notwithstanding).   It should be 32 bits, IMO.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Cathy Zhang
Sent: Friday, December 5, 2014 2:47 PM
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

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 8 Dec 2014 01:33:26 +0000

From: Zarny, Myo [mailto:[email-masked]]
Sent: Friday, December 05, 2014 10:06 PM
To: Xuxiaohu; 'Sharon'; 'Joel M. Halpern'
Cc: [email-masked]'; 'Srini Addepalli'; [email-masked]'
Subject: RE: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Hi Xiaohu,

[Xiaohu] No, I didn't mean reducing the number of paths by using local load-balancing. Instead, I mean a totally different approach in which the explicit SFP info is directly encoded within the packet (see https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-01).

Best regards,
Xiaohu

Regards,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: 4 December 2014 8:54 PM
To: Sharon; Joel M. Halpern
Cc: [email-masked]<mailto:[email-masked]>; Srini Addepalli; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02)

Best regards,
Xiaohu

> > we ought to
> >> to