Subject: Re: [sfc] Adrian Farrel's No Objection on draft-ietf-sfc-problem-statement-10: (with COMMENT)

From: Alia Atlas <[email-masked]>
Date: Fri, 9 Jan 2015 16:46:35 -0500

Hi Adrian,

Thanks for your detailed review.  I'm certain that the authors will also
chime in, but here
are my thoughts.

On Sun, Dec 28, 2014 at 5:58 AM, Adrian Farrel <[email-masked]> wrote:

> Adrian Farrel has entered the following ballot position for
> draft-ietf-sfc-problem-statement-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm balloting No Objection on this document although I did not find it a
> satisfying or detailed read. I think it contains text that could be left
> out and would improve the document. I think it omits material
> (describing the deployment and operation of service function chains
> today, and discussing security) that should be included. None of these
> issues quite makes it to the level of a Discuss for me, but it was a
> close thing.
>
> Perhaps the authors and working group would like to look at the
> document more closely.
>

I completely agree about the security section.  I don't think that
describing more of
what's bad about the deployment and operation today will help noticeably
and can distract the WG from constructively working on their solutions.

> ---
>
> Section 1
>
>    Furthermore
>    there is a cascading effect: service changes affect other services.
>
> This is not clear (to me).
> Perhaps you intend s/affect/may affect/
> Perhaps you intend s/service changes/service function changes/
> And maybe you meant that the introduction of a new service function onto
> a path in order to change one service, causes that same service function
> to be applied to all traffic on that path thereby changing other
> services.
>

I think they mean the last - but agree it needs to be clarified.

Section 1.1
> Thank you for the reference to OSI layers. It's been a long time and
> they have been sorely missed.
> In a document where you are hot on overlays (which imply layer
> inversions) the mention of OSI layers is certainly "interesting".
>
> ---
>
> Notwithstanding your definition in section 1.1, the term "Service
> Function" remains ambiguous. Under your definition, a packet forwarder
> is a service function. What about a packet classifier?
>

I think so.  I'd welcome a clearer definition but do think this one is
understandable.
If I were to extend it, it would be that the Service Function takes in a
series of
packets on one (or more?) interface and outputs a modified series of
packets on
one or more interfaces.  The modifications may include adding information
to the
metadata associated with the packet.

---
>
> Section 1.1 Service Function Chain
> I stumbled over "The implied order may not be a linear progression".
> I think you need s/implied order/ordering constraints/
>

 Agree

I suspect 2.2 needs to say "physical topology" since the point of this
> work is to introduce overlays that make changes to the service topology
> possible with simple configuration.
>

Agree

> Section 2.3
>
> Flip the order of the paragraphs so that the current first paragraph
> has context for its statements.
>

Agreed

> However, I think I contest the scope of your statements. They are
> true when the failure is the failure of a service function but there is
> continued ability to forward traffic. They are not true when the failure
> is of connectivity (such as a link) or of forwarding (such as a service
> function node). In those cases "in the same topology" might be better
> phrased as "in parallel paths through the same topology."
>

Topology isn't implying a single path; I do agree that your phrasing is
clearer.

Section 2.4 is something of a marketing statement which is a shame.
> Anyway, it conflicts with two things when it says:
>    Service function chains today are most typically built through manual
>    configuration processes. These are slow and error prone.  With the
>    advent of newer service deployment models
> Firstly, the prior text gives the impression that the service function
> chain is most typically built through physical deployment of service
> function nodes along traffic paths and their subsequent configuration.
> Secondly, there is little (if any) difference between a manual
> configuration process and a "newer service deployment model". That is,
> automation of configuration is identical in effect to manual
> configuration.
> Surely the distinction you want to draw out is the change from physical
> placement of service function nodes and the consequent constraints on
> ordering with the proposed virtualisation of topology through the
> overlay that allows service function nodes to be located anywhere and
> chained in arbitrary orders.
>

Perhaps what is meant is that because service function chains today are
built
based upon physical topology, the associated configuration is done via
manual
processes which can be error prone?   At any rate, I agree that some
rephrasing
would be useful here.

> I think the concept of "transport" in section 2.6 will (or should) run
> into the classic problem of the two meanings of "transport". Can you
> make the text clearer that you are not discussing whether UDP, RTP, SCTP
> etc. are in use.

Agreed.  Perhaps even encapsulation dependencies?   I know that SFC is
intended
to run at different layers - but clarifying the issues here would be much
better.

>  Does 2.7 mean "flexible" instead of "elastic"?

Would it be good to have explained the current state of the are
> described here for the first time? Maybe an early section of the
> document could spend some (more) time describing how SFC is done today.
>

I do think flexible is clearer while elastic is also very common in the
cloud space.
A bit of description earlier around VLANs and current state would be nice.

> Shouldn't 2.8 say "...unless packets are reclassified and classification
> behaviors are configured at each service function node" ?
>
Agreed

> The point being that a more flexible and granular SFC mechanism (such
> as the WG is producing) effectively performs fine-grained classification
> at the head of the chain and then "marks" each packet with the result of
> that classification through a chain identifier, through a composite
> chain, or in metadata. Where an overlay topology is used, you are not
> actually changing the behavior you describe in this section (the mapping
> of traffic on a segment into a service function is still coarse), but
> you are changing the granularity of the topology.

Agreed

> Section 2.10
>
> Is "may not" "might not", "must not", or "cannot"?
>

I agree clarification is desired.  I believe that the classification may
mark
the traffic in some way (e.g. a particularly VLAN) so that it can sometimes
be used in a similar way to how metadata might be used.

> ---
>
> Why doesn't section 3 mention encapsulation? Isn't this a large part
> of the work and solution?
>

Implied I think by the overlay - but I agree that it should be called out.

> ---
>
> I should really be happier were Section 4 to be removed. I don't believe
> it adds anything, it is (by its own admission) incomplete and leaves one
> to wonder about the significance of omissions, and it is out of date
> even before it is published.
>
> Actually, I have this particular Comment almost at the level of a
> Discuss: this section is harmful to the work of the IETF and detracts
> from the value of this document.
>

Agree - at the least it should be updated and made useful.  Probably, the
simplest
path is removal.

> ---
>
> Section 5 (rightly) notes the content present in Section 3.
> Why doesn't the Abstract also mention what will be in Section 3?
> Why doesn't the Introduction mention the content of Section 3?
> What value does Section 5 add to the document?
>

Agreed that Sec 5 as it is seems to add nothing.

> ---
>
> Section 7 is deficient, IMHO. The problem statement should describe the
> problem of security of configuration and construction of service chains
> today. It should also observe that some service functions are
> specifically security functions: placing such functions on the physical
> path ensures that they are executed, while allowing them to be by-passed
> in the overlay network or left out of a chain is a considerable risk.
>
> However, I will leave it for the Security ADs to decide whether this
> point needs to be Discussed.
>

If you have suggestions on text, that'd be useful.  I'm pulling thoughts
together
based on Kathleen's and Stephen's comments.

Thanks,
Alia

> ---
>
> Dave Mcdysan needs a capital D
>
>
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 12 Jan 2015 16:28:38 +0000

Hi Adrian,

Thank you for taking the time to review the draft.  Please see some comments inline below.  

As you know this draft received signifiant WG review.  Any of the substantive changes discussed below will need to go back to the list for review again.  Tom and I will get a rev out asap.

Paul

> On Dec 28, 2014, at 5:58 AM, Adrian Farrel <[email-masked]> wrote:
> 
> 
> 

On the security front I replied to Ben’s comments, and agree we will add some additional details to the security section.  

I’m not sure what material topics you feel are missing from the draft wrt service chains overall.  The goal of the draft, as you know, is to provide a high level review of the issues associated with existing service deployment.   We deliberately decided to not make it a treatise on all things service chaining in order to keep the draft both succinct and focused on the key issues.  Of course, if you feel there are specific topics that need to be addressed please let us know.

> to be applied to all traffic on that path thereby changing other

We will review the phrasing to make it clearer that moves/add/changes of a specific service, may in many cases affect other deployed services.

> is a service function. What about a packet classifier?

Coming up with a SF definition is something the WG spent a lot of time on.  Strictly speaking, you are correct, the current definition would include forwarders.  I will raise the point with the WG and get some feedback 

> I think you need s/implied order/ordering constraints/

I think perhaps “defined or prescribed order” is more accurate.

> possible with simple configuration.

Given that 2.2 can also apply to a logical underlay (the most common case), perhaps we are best served by stating the logical or physical underlay topology.

> phrased as "in parallel paths through the same topology.”

> chained in arbitrary orders.

I think we can clean up 2.4.  The key point of the section is in the 1st paragraph.

> —

Yes.

> document could spend some (more) time describing how SFC is done today.

Depends on how you define flexible.  Elastic has an accepted implication about scaling up and down.  Is that your defn of flexible?

> behaviors are configured at each service function node” ?

The point being made here is slightly different: even if a node reclassifies, it still (often) has to rely on coarse “steering” mechanisms to direct the traffic.  Of course the local granular classification is useful for local policy enforcement but not necessarily for chaining.

> chain, or in metadata.

The goal here was to highlight the existing issue wrt classification vis a vis chaining.  We deliberately did not prescribe solution (but section 3.2 highlights the relevance of classification), rather leaving that to the architecture draft. 

> Where an overlay topology is used, you are not

I not sure I follow: we are changing this behavior: the service topology selection is based on classification (and possible re-classifcation).

> 
> ---
> 
> Section 2.10
> 
> Is "may not" "might not", "must not", or "cannot”?

I think that was a cut and paste error: “may not be able to…"

> of the work and solution?

The “dataplane metadata” bullet was meant to imply encap, but I can see how it isn’t clear enough.  Thank you.

> from the value of this document.

IIRC, there was a request to include it (I’d have to check the archives).  Speaking as an editor, I’m happy to take it out, and will of course review that choice with the WG.

> What value does Section 5 add to the document?

Let me try to augment the abstract, and review the conclusion.

> point needs to be Discussed.

Yes, working with secdir on this.

> Dave Mcdysan needs a capital D

Thank you.

> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc