Subject: [sfc] A request for Metadata allocation schemes

From: Dave Dolson <[email-masked]>
Date: Wed, 6 Apr 2016 14:13:26 +0000

To those authors of metadata allocations, I have a request.
I believe many types of service functions are going to want to distinguish up-link traffic from down-link traffic.
E.g., a security device treats in-bound to the protected device differently from out-bound.
E.g., an accounting system needs to know whether to charge the source or destination node.

So my request is to allocate a bit for up-link/down-link discrimination.
I think the alternative is to configure each SF about each path whether it is up or down, or to use something like an even/odd path ID scheme.

Does anyone else see this as useful?

I believe all of the allocation drafts have reserved bits.

David Dolson
Senior Software Architect
Sandvine

---

From: Azhar Sayeed <[email-masked]>
Date: Wed, 6 Apr 2016 09:23:14 -0500

Hi Dave,

Why would you need a bit to distinguish the upstream and downstream traffic - the traffic stream can be determined from SA/DA pair at the classifier and the classifier can map the traffic to a service chain

May be I don't understand the use case you are describing.

Moreover upstream and downstream is relative to the point of view 

Regards
Azhar

> On Apr 6, 2016, at 9:13 AM, Dave Dolson <[email-masked]> wrote:
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Wed, 6 Apr 2016 14:41:44 +0000

See inline [DD]

From: Azhar Sayeed [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 11:23 AM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Hi Dave,

Why would you need a bit to distinguish the upstream and downstream traffic - the traffic stream can be determined from SA/DA pair at the classifier and the classifier can map the traffic to a service chain
[DD] Yes, the classifier should know; I’m looking for a way for the classifier to convey the information to the service function.

Moreover upstream and downstream is relative to the point of view
[DD] Yes, but I believe few applications are providing service to both nodes in the conversation. Datacenter nodes are working for the servers, and ISP nodes take the perspective of the internet subscriber.
Service Functions that don’t care can ignore the bit.

Regards
Azhar

On Apr 6, 2016, at 9:13 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

David Dolson

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

---

From: Azhar Sayeed <[email-masked]>
Date: Wed, 6 Apr 2016 11:34:50 -0500

Inline please

> [DD] Yes, the classifier should know; I’m looking for a way for the classifier to convey the information to the service function.

Azhar> The question is why would an SF care about upstream vs downstream unless the SF is also doing accounting in which case it may be possible - Even if you need to identify upstream vs downstream wouldn’t the sub-id/accounting id be different for upstream vs downstream traffic?

<snip>

Azhar

---

From: Dave Dolson <[email-masked]>
Date: Wed, 6 Apr 2016 17:41:17 +0000

Azhar,

I guess by sub-id/accounting-id you are referring to some metadata?
Nonetheless, the charging schemes that I’m familiar with discriminate upload bytes from download bytes.
(E.g., RFC4006 (and 3GPP Gy), which refers to CC-Input-Octets and CC-Output-Octets for up/down traffic
https://tools.ietf.org/html/rfc4006#section-8.24)

Also think about a firewall, which needs to know the difference between an in-bound SYN and out-bound SYN.

I assure you direction is important, and will be accomplished somehow.
It seems to me that a bit in metadata might be a good approach.

-Dave

From: Azhar Sayeed [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 1:35 PM
To: Dave Dolson
Cc: [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Inline please

<snip>

Azhar

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 7 Apr 2016 15:27:23 +0000

?Dave,

The use case you have defined is supported by most devices by binding policies explicitly on,

   a) interface or equivalent

   b) flow direction. Most flow aware devices has to detect to and from correctly to do lot of thngs correctly.

So the question is what do we get by adding this bit? I am opposed to the term UP and DOWN (from show point of view?), rather forward and reverse (even that is confusing).

Sumandra

________________________________
From: sfc <[email-masked]> on behalf of Dave Dolson <[email-masked]>
Sent: Wednesday, April 6, 2016 7:13 AM
To: [email-masked]
Subject: [sfc] A request for Metadata allocation schemes

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Fri, 8 Apr 2016 02:11:59 +0000

Sumandra (and others who have questioned this),
What do you mean by detecting direction from the encapsulated packet?
I’m having trouble understanding how one could tell from an arbitrary IP packet which direction it is going.
(Unless knowing the IP address allocation scheme in the inner network…?  That would be arduous.)

And possibly in-bound, out-bound are better names?
I don’t like forward/reverse because I can’t guess which is which.

-Dave

From: Sumandra Majee [mailto:[email-masked]]
Sent: Thursday, April 07, 2016 12:27 PM
To: Dave Dolson; [email-masked]
Subject: Re: A request for Metadata allocation schemes

​Dave,

Sumandra

________________________________
From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 6, 2016 7:13 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] A request for Metadata allocation schemes

David Dolson

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 8 Apr 2016 04:51:42 +0000

?I think the part of the problem lies in the definition of UP and DOWN. So lets take some use cases.

a) In case of service provider many functions sits at the border between network/internet  and subscriber/user. Typically the two sides of the border is defined by way of configuration, this interface/tunnel point to subscriber side and that points to the internet. Anything ingress on subscriber side is FROM subscriber and vice versa. The UP or DOWN is not so useful.

b) Consider a typical client server.  Assuming you mean UP: client ->server/final destination and DOWN the other way. A flow aware service would have state SIP->DIP as UP and DIP->SIP as DOWN. Others like router etc. may not care at all and that is fine.

In case of security device the inbound and outbound (or zones) are defined by configuration that is local to that entity. So having a classifier say IN or OUT would be wrong in that case.

Sumandra

________________________________
From: Dave Dolson <[email-masked]>
Sent: Thursday, April 7, 2016 7:11 PM
To: Sumandra Majee; [email-masked]
Subject: RE: A request for Metadata allocation schemes

Sumandra (and others who have questioned this),
What do you mean by detecting direction from the encapsulated packet?
I'm having trouble understanding how one could tell from an arbitrary IP packet which direction it is going.
(Unless knowing the IP address allocation scheme in the inner network...?  That would be arduous.)

And possibly in-bound, out-bound are better names?
I don't like forward/reverse because I can't guess which is which.

-Dave

?Dave,

Sumandra

David Dolson

---

From: Nilanjan Sarkar <[email-masked]>
Date: Fri, 8 Apr 2016 09:15:30 +0000

Will a SF device have 2 ports? Problem was to find an  IP packet direction in a single port SF device. In case there are 2 ports, one is connected to subscribers and another is connected to internet, then there is no issue.

Regards,
Nilanjan
(sent from my mobile phone)

On 8 Apr 2016 10:22, Sumandra Majee <[email-masked]> wrote:

​I think the part of the problem lies in the definition of UP and DOWN. So lets take some use cases.

Sumandra

-Dave

​Dave,

Sumandra

David Dolson

---

From: "Bottorff, Paul" <[email-masked]>
Date: Fri, 8 Apr 2016 13:10:18 +0000

Hi Nilanjan, Sumandra, Dave:

Agreed, the case where there are two ports (or two vNICs), then we can use the SA (or SIP) to determine the direction.

Though this does not work for a single armed SF I suspect the SFs which need to form reverse paths are dual armed today. If we simply say that SFs which need to reverse directions also need to be dual armed, then this could be a universal solution. The other nice thing about it is that it works for multi-armed branching also. So if I have an SF with N egress ports (or vNICs) then the SF can branch N ways simply by sending to the correct egress port. This seems natural from an SF coding point of view.

Cheers,

Paul 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nilanjan Sarkar
Sent: Friday, April 08, 2016 2:16 AM
To: Sumandra Majee <[email-masked]>
Cc: Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Regards,
Nilanjan

Sumandra

Sumandra (and others who have questioned this), What do you mean by detecting direction from the encapsulated packet?
I’m having trouble understanding how one could tell from an arbitrary IP packet which direction it is going.
(Unless knowing the IP address allocation scheme in the inner network…?  That would be arduous.)

-Dave

​Dave,

Sumandra

David Dolson

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 15 Apr 2016 16:42:52 +0000

Dave, Paul and Nilanjan,

I am not opposed to having a direction bit in the metadata, yes it might become necessity in certain situation. I am not sure if we need this sense of direction for majority of use cases.

I am generally opposed to standardizing metadata allocation this early.

What I would really like to have a metadata registry and a scheme for that.  
________________________________________
From: Bottorff, Paul <[email-masked]>
Sent: Friday, April 8, 2016 6:10 AM
To: Nilanjan Sarkar; Sumandra Majee
Cc: Dave Dolson; [email-masked]
Subject: RE: [sfc] A request for Metadata allocation schemes

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nilanjan Sarkar
Sent: Friday, April 08, 2016 2:16 AM
To: Sumandra Majee <[email-masked]>
Cc: Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Regards,
Nilanjan

Sumandra

-Dave

​Dave,

Sumandra

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Fri, 15 Apr 2016 16:49:40 +0000

Sumandra,

> I am generally opposed to standardizing metadata allocation this early.

Referring back to my original email, I made the request to those who are proposing metadata schemes in drafts; I am not asking for a direction indication in the NSH base protocol.

In each of the allocation schemes there are "reserved" bits that could be used.

-Dave

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Friday, April 15, 2016 12:43 PM
To: Bottorff, Paul; Nilanjan Sarkar
Cc: Dave Dolson; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Dave, Paul and Nilanjan,

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nilanjan Sarkar
Sent: Friday, April 08, 2016 2:16 AM
To: Sumandra Majee <[email-masked]>
Cc: Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Regards,
Nilanjan

Sumandra

-Dave

​Dave,

Sumandra

David Dolson

---

From: Sunil Vallamkonda <[email-masked]>
Date: Thu, 21 Apr 2016 18:30:34 +0000

Vendors already seem to be working on proprietary mechanisms to share the metadata in implementations which seem to infer the need for a standard framework for interop and scale.
The document https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-00 proposes method using IANA registry for supporting both the generic allocation schemes as mobility, broadband and others, and the vendor specific ones, as they evolve.

Thanks,
Sunil.
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Friday, April 15, 2016 9:50 AM
To: Sumandra Majee <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Sumandra,

-Dave

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Friday, April 15, 2016 12:43 PM
To: Bottorff, Paul; Nilanjan Sarkar
Cc: Dave Dolson; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Dave, Paul and Nilanjan,

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nilanjan Sarkar
Sent: Friday, April 08, 2016 2:16 AM
To: Sumandra Majee <[email-masked]>
Cc: Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Regards,
Nilanjan

Sumandra

-Dave

​Dave,

Sumandra

David Dolson

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 26 Apr 2016 17:06:23 +0000

Sunil, 

Do you suggest that the metadata carried by the packets need to carry those Metadata attribute-Value pairs (Section 4 of your draft)? 

Or are those metadata attribute value distributed by out of band control plane messages? 

Do assume that Classifier is informed of those Metadata Attribute value pairs? What if different instantiation of the SF (by different vendor) will be traversed by the packet? 

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sunil Vallamkonda
Sent: Thursday, April 21, 2016 1:31 PM
To: [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Thanks,
Sunil.
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Friday, April 15, 2016 9:50 AM
To: Sumandra Majee <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Sumandra,

-Dave

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Friday, April 15, 2016 12:43 PM
To: Bottorff, Paul; Nilanjan Sarkar
Cc: Dave Dolson; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Dave, Paul and Nilanjan,

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nilanjan Sarkar
Sent: Friday, April 08, 2016 2:16 AM
To: Sumandra Majee <[email-masked]>
Cc: Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Regards,
Nilanjan

Sumandra

-Dave

​Dave,

Sumandra

David Dolson

---

From: Sunil Vallamkonda <[email-masked]>
Date: Thu, 28 Apr 2016 18:12:52 +0000

Linda,

It would not be OOB though there is no restriction to be part of OOB messages also as needed. 
The local policy rules and capabilities would dictate at run time when and which the metadata Attribute-Value-Pairs (AVPs) and/or Vendor-Attribute-Pairs (VAPs) in packet(s) for PathID. The Classifier's policy could have the ability to incorporate and/or operate with metadata in its rules which depends on implementation.
When SF instantiation is by different vendor since the Controller would be aware, the metadata dictionary would updated as part provisioning the SF.

Thank you,
Sunil.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, April 26, 2016 10:06 AM
To: Sunil Vallamkonda <[email-masked]>; [email-masked]
Subject: [sfc] Questions to SFC-Metadata-model

Sunil, 

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sunil Vallamkonda
Sent: Thursday, April 21, 2016 1:31 PM
To: [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Thanks,
Sunil.
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Friday, April 15, 2016 9:50 AM
To: Sumandra Majee <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Sumandra,

-Dave

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Friday, April 15, 2016 12:43 PM
To: Bottorff, Paul; Nilanjan Sarkar
Cc: Dave Dolson; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Dave, Paul and Nilanjan,

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nilanjan Sarkar
Sent: Friday, April 08, 2016 2:16 AM
To: Sumandra Majee <[email-masked]>
Cc: Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] A request for Metadata allocation schemes

Regards,
Nilanjan

Sumandra

-Dave

​Dave,

Sumandra

David Dolson