Subject: [nsc] Prior to Berlin: some questions

From: Paul Quinn <[email-masked]>
Date: Wed, 19 Jun 2013 14:44:32 -0700

Fellow NSCers,

In preparation for Berlin, I'd like to kick of some discussion on the list:

1.  How do you feel about the topic of service chaining in general?  There's a lot of discussion in the industry and amongst operators about it, but on this list, what is the general thought about how service chaining will impact networks?

2.  I'm hoping folks have started to read the documents posted with the BoF request.  Please send you comments to the list.  In addition to those documents, what else do you expect to see addressed by this effort?  

Thanks
Paul

---

From: Ken Gray <[email-masked]>
Date: Thu, 20 Jun 2013 02:01:27 +0000

Okay, out here in the open then ...

For the header doc, I had two questions ...

1) The requirement for the context headers to be present if
they're unused.  Do you have a feel for what the reaction to the 128 bit
 overhead is going to be?  If the context could be collapsed when
unused, it could cushion the blow of the overhead, even though it may
complicate header offset setting in machine microcode - I mean, it's a
tradeoff.  Interested in your thoughts there ...

2) I love the idea of the proxy.  It applies to already
existing virtual or non-virtual appliances so allows us to suck in vApps
 that were designed for other chaining schemes (and for a while this is
going to be the wild-wild west), even proprietary ones.
So, is the vision that this be a user space agent that is just "canned"
as far as it's processing goes (like a utility function) - that is, it's
 a vendor-independent piece of software (potentially open-sourced)
and/or a similar thing but with hooks to vendor specific overlay mapping
 software to help with the encap/decap?  I mean, do I have it wrong or
would the expectation be that this manipulates no metadata as there is
no real context sharing with non-compliant apps - or am I missing
something and it is more complex/customizable?

On 6/19/13 5:44 PM, "Paul Quinn" <[email-masked]> wrote:

>1.  How do you feel about the topic of service chaining in general?
>There's a lot of discussion in the industry and amongst operators about
>it, but on this list, what is the general thought about how service
>chaining will impact networks?
>
>2.  I'm hoping folks have started to read the documents posted with the
>BoF request.  Please send you comments to the list.  In addition to those
>documents, what else do you expect to see addressed by this effort?
>
>Thanks
>Paul
>_______________________________________________
>nsc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nsc
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 Jun 2013 22:12:27 -0400

Service Chaining is clearly a topic of interest to man of us 
individually and many of our companies either as vendors, service 
providers, or users of services.  That's the easy part.

I find myself concerned seeing a number of proposals for specific 
protocol mechanism when there is nothing resembling agreement on the 
needs, scales, or architecture for the problem.  The number of sets of 
non-matching assumptions out there is large enough that I am having 
difficulty getting my head around what a working group would do. 
Defining protocol seems an odd place to start.

Yours,
Joel

---

From: Thomas Narten <[email-masked]>
Date: Thu, 20 Jun 2013 09:50:27 -0400

> providers, or users of services.  That's the easy part.

Totally agree!

> Defining protocol seems an odd place to start.

Agree here as well.

I suspect getting on the same page in terms of the problem statement
will not be too hard. I agree with much of what is in the
draft-quinn-nsc-problem-statement-00.txt. Saying where the pain is
is relatively easy.

But in terms of how best to address those issues, as in architectural
choices, and what the tradeoffs are with different approaches, that
will be harder.

draft-quinn-nsh has a lot of fields that are more or less opaque or
are just identifiers for some sort of context information that is not
defined.  That makes it challenging to understand what sort of general
*architecture* is being thought of here.

Thomas

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Jun 2013 07:07:49 -0700

On Wed, Jun 19, 2013 at 7:12 PM, Joel M. Halpern <[email-masked]> wrote:
> Service Chaining is clearly a topic of interest to man of us individually
> and many of our companies either as vendors, service providers, or users of
> services.  That's the easy part.

Agree Joel.

>
> I find myself concerned seeing a number of proposals for specific protocol
> mechanism when there is nothing resembling agreement on the needs, scales,
> or architecture for the problem.  The number of sets of non-matching
> assumptions out there is large enough that I am having difficulty getting my
> head around what a working group would do. Defining protocol seems an odd
> place to start.

Again, agreed.

--dmm

---

From: Paul Quinn <[email-masked]>
Date: Thu, 20 Jun 2013 09:01:27 -0700

Hi Ken,

Thanks for the great questions.  Please see my replies inline.

Paul

On Jun 19, 2013, at 7:01 PM, Ken Gray <[email-masked]> wrote:

> tradeoff.  Interested in your thoughts there …
> 

PQ>  We discussed the trade-off and decided the simplicity of a single fixed sized header
 is worth the potential extra overhead.  Given that most of the initial service chaining use cases are 
 focused in the data center, with planned NSH ASIC platforms (forwarding at multiples of 
 10/40/100G) the overhead is relatively minimal. 

> software to help with the encap/decap?

PQ> A "canned" or open source piece of software is precisely what we have in mind.  
This "agent" can reside in a physical switch, a vswitch, or some other proxy node and 
participate in the overlay.   The only hooks needed are to present to the chaining control
system the location of the services in the dataplane.

>  I mean, do I have it wrong or

PQ>  Metadata manipulation is interesting in this case.  The proxy must be able to 
preserve the existing metadata.  As a base function, a proxy will map the path ID to a 
locally significant identifier that the service functions can understand.  However, an 
interesting evolution to that proxy functions is to offer configurable mapping of more 
than just the path ID.  So perhaps, in some deployments, metadata (or a combination of 
fields) is mapped to locally significant identifier(s).

---

From: Paul Quinn <[email-masked]>
Date: Thu, 20 Jun 2013 09:42:18 -0700

Hi Joel,

Thanks for your email.  First off, it's great to hear that overall, many of us agree that 
service chaining is an worthy topic :)

As you probably saw, we submitted two documents with the BoF proposal.  Our goal with
those documents is twofold: i) describe a problem, that we can discuss as a group at the
BoF, and eventually a WG, ii) reflect our implementation that addresses some of the problems
outlined in the problem statement.

Given how "hot" service chaining is, we opted to be pragmatic and to quickly start 
offering guidance for implementors, based on work we are doing; 
starting down the interoperability path seemed reasonable.

Of course, in Berlin, we'll get together as a group, and decide what other drafts are 
needed.

Thanks
Paul

On Jun 19, 2013, at 7:12 PM, Joel M. Halpern <[email-masked]> wrote:

> Service Chaining is clearly a topic of interest to man of us individually and many of our companies either as vendors, service providers, or users of services.  That's the easy part.
> 
> I find myself concerned seeing a number of proposals for specific protocol mechanism when there is nothing resembling agreement on the needs, scales, or architecture for the problem.  The number of sets of non-matching assumptions out there is large enough that I am having difficulty getting my head around what a working group would do. Defining protocol seems an odd place to start.
> 
> Yours,
> Joel
>