Re: [sfc] WG Last call - Hierarchical SFC

["Adrian Farrel" <[e-mail]>]

All,

I'm not very excited by hSFC. So far we haven't been able to come up
with examples of very long chains and while they may one day be found
it seems premature to do work on hSFC. I do agree that the use cases
shown can be solved with hSFC, but I also don't see use cases as 
insoluble using other approaches.

So please take this as a "publish it if you must" level of support :-)

But anyway, here are a few comments from reading the latest revision.

Cheers,
Adrian

Seven authors will probably give the AD heartburn.

---

I'm surprised to see this last called when it has normative references
to one document that the still needs work before it can go to a second
WG last call, and another document that the WG is debating abandoning.

---

The introduction contains the reasonable note...
      Note: in this document, the notion of the "path" of a packet is
      the series of SF instances traversed by a packet.  The means of
      delivering packets between SFs (i.e., the forwarding mechanisms
      enforced in the underlying network) are not relevant to the
      discussion.
Why, then, does the document go on to discuss SFFs?

---

We were explicitly told in the WG that an SFF cannot make assumptions 
based on the transport tunnel used to deliver a packet to the SFF.

3.1.1 seems to be counter to this.

I would be happy to hear that 3.1.1 is a valid approach, but if so then
the WG needs to agree that an SFF *can* make determinations based on the
transport tunnel. In particular, it can tell whether a packet has 
arrived from another SFF, from an SF, or from a classifier.

---

It is all very well for section 3.1 to describe 5 perfectly achievable
approaches to hSFC, but in order to achieve interop, the head and tail
ends of a lower layer SFC need to use the same mechanism. That means
that the mechanism either has to be determined through the control plane
or exposed by examination of the data plane. Furthermore, the 
implication is that all implementations have to support all five 
mechanisms.

Saying that this document "sets expectations for control planes" is
all very well, but by keeping so many options and punting on the details
you are making it unlikely that a workable solution will be 
standardised.

Following the principle that "options are bad" can't we manage to cut
this list down to just one method (or worst case, two)?

Why do we need five mechanisms?

(I note that option 3 is "free" with reclassification, while option 4
is already defined in the NSH spec.)

---

Section 9.2 seems to be out of date.
Indeed, some of the hSFC approaches here include "reclassification" in 
a way that would stop the SI being used to detect loops. So we need to
invoke the TTL. But how will the TTL be used? Will the lower layer SPF
inherit the TTL from the higher layer, or will it reset it? Will the
higher layer SFP be updated according to the TTL of the lower layer?
Can two lower layer SFPs be stitched together without a "hop" in the 
higher layer?

More work needed on loops, I think.

> -----Original Message-----
> From: sfc [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> Sent: 14 March 2017 18:30
> To: [e-mail]
> Subject: [sfc] WG Last call - Hierarchical SFC
> 
> This is a last call for:
> https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02
> 
> Please respond to the list as to whether you see problems with this, you
> think it is done, or any other input for the WG.
> 
> Due to the run up to the IETF, we will let this run until April 7.