Subject: Re: [sfc] I-D Action: draft-penno-sfc-yang-09.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 31 Oct 2014 17:12:22 -0400

This draft, and maybe the NSH protocol draft, seem like the place to 
raise a question that was pointed out to me.

In the architecture, we permit SFs to trigger reclassification, if a 
classifier is present at the SFF.
We also permit the same SFF to be supporting several SFs.

We could easily have the case where an SFF has a classifier to support 
those SFs (like security appliances) which need to be able to trigger 
reclassification.  But many SFs should not trigger reclassification. 
While the protocol can not tell this, the administrator / operator can.

Would we improve robustness if we added a flag telling the SFF whether 
to permit a given SF to request reclassification?

Thank you,
Joel

On 10/27/14, 7:59 AM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : Yang Data Model for Service Function Chaining
>          Authors         : Reinaldo Penno
>                            Paul Quinn
> 	Filename        : draft-penno-sfc-yang-09.txt
> 	Pages           : 36
> 	Date            : 2014-10-27
>
> Abstract:
>     This document defines a YANG data model that can be used to configure
>     and manage Service Function Chains.
>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 31 Oct 2014 22:10:10 +0000

By ³trigger² you mean that SF uses method such as a bit in the NSH header
to convey the need for reclassification? I know some transformation
services could require that on a per packet basis.

Another possibility is that there is always a need for reclassification
after a certain SF (example, tunnel termination). Not the VXLAN transport
tunnel, but something like a Softwire tunnel.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 31 Oct 2014 18:19:03 -0400

The former case is what was discussed earlier in the SFC work.  The 
example proposed was a security SF.  Normally, it says yes, and the 
packet goes merrily on its way.  If it says no, the SF needs to add 
metadata and tell the SFF that reclassification is needed.

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 31 Oct 2014 22:33:40 +0000

What is the proposed action if a SF inserts metadata to require
classification but it is not allowed to do so based on its configuration?
Drop the packet, send the packet on its merry way, and/or remove metadata,
etc?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 31 Oct 2014 18:50:28 -0400

My preference would be to drop the packet, and generate a network
management event about a misbehaving SF.  I can live with forwarding the
packet along the original path, presumably without the bit requesting
reclassification.  But not trying to guess what metadata the SF modified.

Yours,
Joel

PS: I would expect the reclassification request to be one of the header
bits in the NSH header.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 31 Oct 2014 22:58:49 +0000

This makes sense. I can change the model to include a choice between those
actions.