Subject: [sfc] NSH: RSP open item

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Sun, 22 Nov 2015 15:09:37 +0000

SFCers,

We need resolve the concept of the RSPID that's been discussed on list, and listed in the NSH draft as an "open item".  Currently, NSH specifies a service path ID which is used to i) identify the service path, ii) select the required overlay encap + next hops.  The arch and the NSH drafts do not specify the granularity of the path ID: it can represent as specific a path as the control plane wants to assign.  In the current open source implementation, we've been using it as an explicit indication of which SFF and SFs are composed to create a path.

Having said that, I know some folks have presented a case where further granularity might be required: an explicit indication of specific instances within the scope of a SFP.  I think we have a  solution for each NSH MD Type, although we might have slightly different terminology, the desired functionality will be equivalent:

MD-type 1: As you know the metadata in type 1 is opaque, so in theory an implementation could assign any additional identifiers to the metadata.  There are also a couple of drafts that provide allocation guidelines, the data center one specifically allows for an additional identifier -- a flow ID of sorts -- that can be used for dataplane granularity.

MD-type 2:  As per the recently submitted draft (http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh-tlv/), a flow id specific TLV has been defined.  This can be used, as needed, within the dataplane to further identify a flow, and therefore be used for specific instance selection, load balancing and such.

So, given these two options, I think we can, with the existing drafts, provide the needed functionality for the RSPID use cases.  If we get consensus, we can update NSH accordingly so please weigh in, on list, as needed.

Thanks
Paul

---

From: Ron Parker <[email-masked]>
Date: Sun, 22 Nov 2015 16:53:15 +0000

I'm in agreement with this approach.  However some of the terminology around SFPID is confusing, especially where part of the SFPID's role is to "select the next hops", as stated below.  The phrase is certainly truthful, but perhaps inadequate.   When considering a loosely specified approach with allowed late binding, the phrase would be more evocative as "select the eligible next hops (I.e., one or more service function instances for each abstract service function specified in the chain)".  This would allow for another explanatory sentence that makes it explicit that in some deployments, there may be exactly one eligible service function instance in each position of the chain to satisfy the SFP (i.e. Strictly specified). 

   Ron

> On Nov 22, 2015, at 10:09 AM, Paul Quinn (paulq) <[email-masked]> wrote:
> 
> SFCers,
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Mon, 23 Nov 2015 16:31:24 +0000

I think a flow ID is useful to have around as a key to select from a choice of next hops, but I wouldn't want to see it MUST be used.
I believe there are many cases when deeper analysis of the traffic can make a better decision, or may be stateful.

A fairly obvious example is when a vendor provides a load-balancer to accompany their service functions, using a proprietary SF-selection.
I don't think it is reasonable to expect an up-stream classifier to know the load-balancing requirements.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, November 22, 2015 11:53 AM
To: Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [sfc] NSH: RSP open item

   Ron

---

From: Ron Parker <[email-masked]>
Date: Mon, 23 Nov 2015 17:20:05 +0000

Agree that this is an optional attribute, but also that it could be very useful.   

For example, the classifier can determine on what granularity a "macro-flow" is identified and consequently stamped with a unique "flow ID".   This is extremely useful if the classifier understands "subscribers" and can facilitate the late-binding style of load balancing such that all flows from a particular subscriber are processed by the exact same set of service function instances (barring failures, of course).

    Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, November 23, 2015 11:31 AM
To: Ron Parker <[email-masked]>; Paul Quinn (paulq) <[email-masked]>
Cc: [email-masked]
Subject: RE: [sfc] NSH: RSP open item

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, November 22, 2015 11:53 AM
To: Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [sfc] NSH: RSP open item

   Ron

---

From: Dave Dolson <[email-masked]>
Date: Mon, 23 Nov 2015 17:22:59 +0000

Yes, I think it has a lot of value.
Even when (optionally) present, however, I don't think it must be obeyed.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 23, 2015 12:20 PM
To: Dave Dolson; Paul Quinn (paulq)
Cc: [email-masked]
Subject: RE: [sfc] NSH: RSP open item

    Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, November 23, 2015 11:31 AM
To: Ron Parker <[email-masked]>; Paul Quinn (paulq) <[email-masked]>
Cc: [email-masked]
Subject: RE: [sfc] NSH: RSP open item

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, November 22, 2015 11:53 AM
To: Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [sfc] NSH: RSP open item

   Ron

---

From: Ron Parker <[email-masked]>
Date: Mon, 23 Nov 2015 17:25:28 +0000

Agree.   It is optional whether SFF consumes this value when present.

   Ron

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, November 23, 2015 12:20 PM
To: Dave Dolson; Paul Quinn (paulq)
Cc: [email-masked]
Subject: RE: [sfc] NSH: RSP open item

    Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, November 23, 2015 11:31 AM
To: Ron Parker <[email-masked]>; Paul Quinn (paulq) <[email-masked]>
Cc: [email-masked]
Subject: RE: [sfc] NSH: RSP open item

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, November 22, 2015 11:53 AM
To: Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [sfc] NSH: RSP open item

   Ron

---

From: "Bottorff, Paul" <[email-masked]>
Date: Mon, 23 Nov 2015 18:57:05 +0000

Hi Dave:

I believe a flow ID is desirable. I also agree that the classifier may not always provide sufficient flow analysis for LB operations. Your example of a SF specific LB is well taken.

I don't see how the existence of a flow ID in the meta-data mandates that it is always used for directing packets to specific SF instances along the path. If the NSH MUST have a flow ID it doesn't limit a SF specific LB from using other information for the LB decision. What a MUST have a flow ID does is assure that simple LBs can rely on having a flow ID.

We should consider that other transport fields may also carry a flow ID. It seems to me we have been mixing both transport and meta-data in the NSH header. Particularly the SPI, SI and RSP together form a transport address.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, November 23, 2015 8:31 AM
To: Ron Parker; Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [sfc] NSH: RSP open item

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Sunday, November 22, 2015 11:53 AM
To: Paul Quinn (paulq)
Cc: [email-masked]
Subject: Re: [sfc] NSH: RSP open item

   Ron