Subject: [sfc] Metadata Definition in problem statement

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Mar 2014 17:39:39 -0400

As requested, Lucy and I have tried to put together a definition 
(actually two definitions) that capture the distinction I was trying to 
explain.

The text below replaces the existing first pargraph of definition 4. in 
the problem statement with the two items given.  The second and third 
paragraph of the published item 4 remain as the second and third 
paragraph of the new item 5:

-------

4. Dataplane Service Chain Identification: This represents the result
of classification or reclassification.  It is carried in the packet
in support of the service chain forwarding function.  Service
functions may also receive it. Service functions may indicate to
the data plane that reclassification should be performed, resulting in
an update by the data plane of the chain identification.

5. Dataplane Metadata: This provides the ability to carry additional
information used by service functions or (re)classifications in their 
processing.
This information is carried in the data packet and is not used by the
dataplane forwarding functionality.  This metadata may come from
external sources, from classification based on packet properties not
carried in the service chain (such as arrival ports or vlans), or may
come from service functions as an output of their processing.

-------------

I hope that this at least provides a basis for clear discussion.  I find 
it very helpful to draw this distinction.

Yours,
Joel and Lucy

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Mar 2014 21:45:36 +0000

Hi Joel,
I don't think we want to prevent the forwarding function from consuming metadata; a vrf-ID comes to mind as something that might be useful at that level.

Sent from my iPhone

> On Mar 14, 2014, at 5:39 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> As requested, Lucy and I have tried to put together a definition (actually two definitions) that capture the distinction I was trying to explain.
> 
> The text below replaces the existing first pargraph of definition 4. in the problem statement with the two items given.  The second and third paragraph of the published item 4 remain as the second and third paragraph of the new item 5:
> 
> -------
> 
> information used by service functions or (re)classifications in their processing.
> I hope that this at least provides a basis for clear discussion.  I find it very helpful to draw this distinction.
> 
> Yours,
> Joel and Lucy
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Lucy yong <[email-masked]>
Date: Fri, 14 Mar 2014 22:01:28 +0000

Hi Jim,

In what context that vrf-id relates to SFC? Is this about that SFC exists in VPN? Or GW SF passes traffic between two VPNs?

Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, March 14, 2014 4:46 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] Metadata Definition in problem statement

Hi Joel,

Sent from my iPhone

> of classification or reclassification.  It is carried in the packet in 
> support of the service chain forwarding function.  Service functions 
> may also receive it. Service functions may indicate to the data plane 
> that reclassification should be performed, resulting in an update by 
> the data plane of the chain identification.
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Mar 2014 22:09:23 +0000

No I meant it could be carried as metadata to provide forwarding context on exiting an SFC so as to avoid daisy chaining.

Sent from my iPhone

> On Mar 14, 2014, at 6:01 PM, "Lucy yong" <[email-masked]> wrote:
> 
> Hi Jim,
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Mar 2014 18:11:00 -0400

OAM on the forwarding behavior is going to be interesting enough with 
just the service chain ID and index.  I think we can make it work.
If we add metadata dependence in the forwarding plane, I fear that we 
have created something that is simply not operable.

To comment on the specific example, f you are using different devices 
for different VRFs, then that would lead to separate service chains.  If 
not, then the service function can use the metadata to do its job.
And the control functions that establish the chains and establish the 
mappings of traffic to the chains can easily have enough capability to 
cope with both choices, and other variations.

Yours,
Joel

On 3/14/14, 5:45 PM, Jim Guichard (jguichar) wrote:
> Hi Joel, I don't think we want to prevent the forwarding function
> from consuming metadata; a vrf-ID comes to mind as something that
> might be useful at that level.
>
> Sent from my iPhone
>
>> (actually two definitions) that capture the distinction I was
>> trying to explain.
>>
>> The text below replaces the existing first pargraph of definition
>> 4. in the problem statement with the two items given.  The second
>> and third paragraph of the published item 4 remain as the second
>> and third paragraph of the new item 5:
>>
>> -------
>>
>> 4. Dataplane Service Chain Identification: This represents the
>> result of classification or reclassification.  It is carried in the
>> packet in support of the service chain forwarding function.
>> Service functions may also receive it. Service functions may
>> indicate to the data plane that reclassification should be
>> performed, resulting in an update by the data plane of the chain
>> identification.
>>
>> 5. Dataplane Metadata: This provides the ability to carry
>> additional information used by service functions or
>> (re)classifications in their processing. This information is
>> carried in the data packet and is not used by the dataplane
>> forwarding functionality.  This metadata may come from external
>> sources, from classification based on packet properties not carried
>> in the service chain (such as arrival ports or vlans), or may come
>> from service functions as an output of their processing.
>>
>> -------------
>>
>> I hope that this at least provides a basis for clear discussion.  I
>> find it very helpful to draw this distinction.
>>
>> Yours, Joel and Lucy
>>
>> _______________________________________________ sfc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 14 Mar 2014 22:23:55 +0000

I am talking about post chain; when traffic exits a chain it may need to be forwarded within a particular VPN context. Unless you carry something in the metadata you need to reclassify to figure out how to continue forwarding. Using the metadata can help avoid all of that.

Sent from my iPhone

> On Mar 14, 2014, at 6:11 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> OAM on the forwarding behavior is going to be interesting enough with just the service chain ID and index.  I think we can make it work.
> If we add metadata dependence in the forwarding plane, I fear that we have created something that is simply not operable.
> 
> To comment on the specific example, f you are using different devices for different VRFs, then that would lead to separate service chains.  If not, then the service function can use the metadata to do its job.
> And the control functions that establish the chains and establish the mappings of traffic to the chains can easily have enough capability to cope with both choices, and other variations.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Mar 2014 18:32:50 -0400

I will take it that you mean processing at the egress.

aside - If it were really post-chain, then:
- 1) the metadata would be stripped at the end of the chain
- 2) the usage would be outside the scope of SFC.

The problem with using the metadata to direct the egress is that we 
still have a massive OAM problem, and we have added complexity to the 
forwarding logic by needing to look at more data in the forwarder.

Clearly, it works with separate chains, ending at distinct points 
supporting the VRFs.

The question, I think, would be whether we want to observe that there 
can be a logical egress functions that may make use of metadata before 
stripping the data and returning to conventional forwarding.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Fri, 14 Mar 2014 22:43:02 +0000

I agree.  Think policy based routing where the metadata provides a hint. 

   Ron

> On Mar 14, 2014, at 6:24 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sat, 15 Mar 2014 01:34:50 +0000

I have problem with both of them as written. If they are relaxed to allow
the below, I'm fine with it.

#4: We should be able to reuse the classification performed in a SF. In
that sense, the SF MUST be allowed to convey the chain identification -
note, I'm not saying "REQUIRED".

#5: What Jim said already: "not used by the data plane forwarding
functionality" should be removed. If some implementation does not want to
use it for forwarding that is fine but we do not have to impose this
restriction.

Surendra.

On 3/14/14 2:45 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>Hi Joel,
>I don't think we want to prevent the forwarding function from consuming
>metadata; a vrf-ID comes to mind as something that might be useful at
>that level.
>
>Sent from my iPhone
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 15 Mar 2014 00:26:02 -0400

It seems to me that if we want to conflate the functions that 
completely, then we might as well just say that it is all optional 
metadata, to be used any way the forwards or service functions want.
Operability will suffer, in exchange for extreme flexibility.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 15 Mar 2014 14:59:59 +0000

> I am talking about post chain; when traffic exits a chain it may need to be forwarded within a particular VPN context. Unless you carry something in the metadata you need to reclassify to figure ou…

Further, reclassification might not be possible in some cases, since the context of the classification (in the example of a VRF context) might exist only at ingress (e.g., VRF association to the ingress port).

Thanks,

-- Carlos.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 17 Mar 2014 10:03:57 +0000

> -----邮件原件-----
> 发件人: sfc [mailto:[email-masked]] 代表 Carlos Pignataro (cpignata)
> 发送时间: 2014年3月15日 23:00
> 收件人: Jim Guichard (jguichar)
> 抄送: Joel M. Halpern; [email-masked]
> 主题: Re: [sfc] Metadata Definition in problem statement
> 
> 
> > I am talking about post chain; when traffic exits a chain it may need to be
> forwarded within a particular VPN context. Unless you carry something in the
> metadata you need to reclassify to figure out how to continue forwarding. Using
> the metadata can help avoid all of that.
> >
> 
> Further, reclassification might not be possible in some cases, since the context of
> the classification (in the example of a VRF context) might exist only at ingress
> (e.g., VRF association to the ingress port).

Take the BGP/MPLS IP VPN as an example, should the VPN context consumed by the SF and the VPN context consumed by the egress PE router for forwarding be two separate entities? The former may be a global VPN ID which can be understood by all SF nodes while the latter is a local VPN label which is only significant to the egress PE router. If so, it seems that the former, rather than the latter should be taken as a VPN context metadata. I agree with Joel that this metadata should be stripped by the last-hop SF node before forwarding the packet towards the egress PE router (non-SF node). Furthermore, the latter VPN context (i.e., the VPN label) should always be carried till the packet arrives at the egress PE router. 

Best regards,
Xiaohu

> >> OAM on the forwarding behavior is going to be interesting enough with just
> the service chain ID and index.  I think we can make it work.
> >> If we add metadata dependence in the forwarding plane, I fear that we have
> created something that is simply not operable.
> >>
> >> To comment on the specific example, f you are using different devices for
> different VRFs, then that would lead to separate service chains.  If not, then the
> service function can use the metadata to do its job.
> mappings of traffic to the chains can easily have enough capability to cope with
> both choices, and other variations.
> >>
> >> Yours,
> >> Joel
> >>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 17 Mar 2014 15:28:52 +0000

I'm just back from vacation, trying to catch up.  Some comments inline.

> note, I'm not saying "REQUIRED".

Agreed, the text that Joel sent stated: "Service functions may indicate to
the data plane that reclassification should be performed, resulting in
an update by the data plane of the chain identification."

Service functions MAY indicate that reclassification has occurred, in other words, the SF itself re-classifies (in many cases only the SF has the "smarts"), and then can update the chain ID.  This provides three key architectural benefits: i) allows SFs to be chain aware without having to understand forwarding per se, ii) enables rich SF-centric classification to impact service pathing, iii) completely de-couples transport and the SFC encap/SF interaction.

> use it for forwarding that is fine but we do not have to impose this

One things we tried to convey in the problem statement is that metadata might come from network nodes and/or SFs.  We didn't specify use of that metadata (not the role of the problem statement), and, at this time, we shouldn't impose limits.  Jim's example of vrf-ID is an interesting one: the data is carried along the SFC path, and used by nodes in the path that need it.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 17 Mar 2014 15:29:53 +0000

For the problem statement, I think that's fair to say.  In general, I'd like to see use cases help drive the limitations/scope of metadata.

On Mar 15, 2014, at 12:26 AM, Joel M. Halpern <[email-masked]> wrote:

> It seems to me that if we want to conflate the functions that completely, then we might as well just say that it is all optional metadata, to be used any way the forwards or service functions want.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 17 Mar 2014 16:30:49 +0000

On 3/17/14 8:28 AM, "Paul Quinn (paulq)" <[email-masked]> wrote:

>Service functions MAY indicate that reclassification has occurred, in
>other words, the SF itself re-classifies (in many cases only the SF has
>the "smarts"), and then can update the chain ID.  This provides three key
>architectural benefits: i) allows SFs to be chain aware without having to
>understand forwarding per se, ii) enables rich SF-centric classification
>to impact service pathing, iii) completely de-couples transport and the
>SFC encap/SF interaction.
SK1> These are precisely the reasons for my comment on the limitation. It
is not only impractical to duplicate the SF-classification, it is also
architecturally redundant. At the same time, I appreciate the distinction
that Joel was trying to make in achieving a clear separation between
forwarding plane and service plane w.r.t metadata. The separation still
exists but the metadata produced in one plane can be consumed in the other.

Surendra.

>One things we tried to convey in the problem statement is that metadata
>might come from network nodes and/or SFs.  We didn't specify use of that
>metadata (not the role of the problem statement), and, at this time, we
>shouldn't impose limits.  Jim's example of vrf-ID is an interesting one:
>the data is carried along the SFC path, and used by nodes in the path
>that need it.  
>
>
>> 
>> Surendra.
>>