Re: [sfc] WG Last call

Adrian,
Thank you for reading and providing suggestions.

Please see inline comments [DD]

For those who wish to follow along or make pull requests, collaboration is occurring on github: https://github.com/dcdolson/draft-dolson-sfc-hierarchical
I'm going to track issues there.

-Dave

-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, March 14, 2017 3:43 PM
To: 'Joel M. Halpern'; sfc@ietf.org
Subject: Re: [sfc] WG Last call - Hierarchical SFC

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.
[DD] Why? How is this usually handled?

---

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.
[DD] I would expect the RFC editor to queue this behind I-D.ietf-sfc-nsh? 
[DD] As for I-D.ietf-sfc-control-plane, if it is abandoned, we need to explain some concepts within hSFC.

---

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?
[DD] We should choose whether to make this agnostic about technology or embrace NSH.

---

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.

[DD] It is intended that the packets are returned to the higher layer only at the *termination* of the lower-level chain. I think we can probably clarify this better by saying the IBN is about classification and termination (the start and end of chains), not the middle. Does that help?

---

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?
[DD] I wouldn't mind reducing this, but keep in mind that being both the start and end of the sub-domain, the IBN actually do something proprietary. Perhaps we should be defining the schemes in terms of requirements at the SFs? (e.g., supporting nested NSH, respecting reserved metadata...)  Maybe others can make suggestions.

(I note that option 3 is "free" with reclassification, while option 4
is already defined in the NSH spec.)
[DD] I don't see the IBN as doing only "reclassification". It is important that we view the sub-domain as being independently administered.

---

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.
[DD] Waiting for I-D.ietf-sfc-nsh to be updated with the TTL. Yes, TTL propagation rules would need to be defined.

> -----Original Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: 14 March 2017 18:30
> To: sfc@ietf.org
> 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.

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc