Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-05.txt

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 5 May 2014 17:41:47 +0000

Folks,

A new version of the architecture draft has been submitted.  This version reflect comments from the community, and welcomes a new co-editor: Joel Halpern.

As always, comments and suggestions are encouraged!

Thanks
Paul

> 
> 
> A new version of I-D, draft-quinn-sfc-arch-05.txt
> has been successfully submitted by Paul Quinn and posted to the
> IETF repository.
> 
> Name:		draft-quinn-sfc-arch
> Revision:	05
> Title:		Service Function Chaining (SFC) Architecture
> Document date:	2014-05-05
> Group:		Individual Submission
> Pages:		31
> URL:            http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/
> Htmlized:       http://tools.ietf.org/html/draft-quinn-sfc-arch-05
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-quinn-sfc-arch-05
> 
> Abstract:
>   This document describes an architecture for the specification,
>   creation, and ongoing maintenance of Service Function Chains (SFC) in
>   a network.  It includes architectural concepts, principles, and
>   components used in the construction of composite services through
>   deployment of SFCs.  This document does not propose solutions,
>   protocols, or extensions to existing protocols.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 6 May 2014 22:38:51 +0000

Hi Paul and Joe,

This version expends a lot. The writing is clear.

Here are some comments and suggestions:

*       In introduction, statement "No IANA registry is required to store the identity of SFs." Is it important or necessary to state this? If yes, why?

*       The term of "Service Node" is defined; but the doc. does not describe its relationship to other architecture components specified in section 4. Does it mean that a service node has to contain SF(s), SFF, NF or some of these components? For example, could a SN only have a SF, i.e. not co-locate with SFF/NF? BTW, the service node is barely used in text, which make hard to picture its roles.

*       Does the architecture allow that passing SFC encapsulated packets between a SF and its associated SFF go through NF or not?

*       If the SFC architecture allows branching as described, it is good to show a branching example in figure 1. BTW, the last sentence in sec. 2.2 should be moved to sec. 2.1 and state that is the third example in figure 1.

*       Section 4 describes core SFC arch components. Classification is stated as a core SFC arch component and is a logical component, and "as a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data prior to forwarding along the SFP." However, is does not illustrate this component in figure 2, which makes unclear how this component relates to other component in this figure or described in the text. Suggest illustrating this component in figure 2 and/or describe it in text.

*       In Section 4.3, don't know why show SFF table here. Does that mean that all SFs in the table associate to the same SFF? The text and table is quite misleading. The SFP of SFC may result SFs on multiple SFFs. The table on each SFF only maintains the SFs in a SFP associated to it.

*       Statement about stateful SFF mixes with SFC proxy function. It should be distinct.

*       SFC architecture should work in multi-tenant environment where individual tenant may use SFCs. Should we add some clarification on that?

*       Does the SFC architecture impose some security consideration? Statement in section 11 seems weak.

*       Overlay network and SFC network mean the same in this doc, is that right? May be good to state out clearly or use one term through the doc.

Cheers,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Monday, May 05, 2014 12:42 PM
To: <[email-masked]>
Subject: [sfc] Fwd: New Version Notification for draft-quinn-sfc-arch-05.txt

Folks,

Thanks
Paul

>
>
> A new version of I-D, draft-quinn-sfc-arch-05.txt has been
> successfully submitted by Paul Quinn and posted to the IETF
> repository.
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

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

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 15 May 2014 13:51:24 +0000

Lucy,

Thank you for the comments, please see inline.

Paul

On May 6, 2014, at 6:38 PM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Paul and Joe,

PQ>  We are clarifying that there is no implication of a SF registry.

PQ>  All the components are logical, and therefore and be combined as needed by an implementor.  You do raise a good point about a SN though.  I tend to think of it as an optimization used for implementation, we’ll review how to present it in the draft.

PQ>  I don’t understand the question.  Packets go NF <—> SFF <—> SF.

PQ>  Figure 1 simply uses a linear depiction of the path.  If it’s confusing one of the figure can be reoriented to explicitly depict branching.  Also, that sentence will be moved, thanks for catching it.

PQ>  Do you have any suggested text and/or a updates to the figure?

PQ>  This table is simply a conceptual representation of how service forwarding is maintained at the SFFs. SFID details, including which SFF they are associated with, could be maintained separately at each SFF. We do not want to impose how they are implemented.

PQ>  There is a dedicated “SFC Proxy” subsection, so it is a distinct (logical) component.

PQ>  That is a broad statement, there’s nothing in this draft the precludes, or assumes for that matter, multi-tenancy.  Are there specific areas you’d like to see addressed, or sections added?

PQ>  We will update this section.

PQ>  Yes and no: the SFC network is an overlay but it introduces a new topology due to the service chain.

Thanks
Paul

---

From: Lucy yong <[email-masked]>
Date: Thu, 15 May 2014 16:41:03 +0000

Hi Paul and Joel,

I propose the following figure for figure 2 to show Classification Function described in section 4.5.

    +---------------+    +----------------+      +----------------+
    |Classification |    |   SFC-aware    |      |  SFC-unaware   |
    | Function      |    |Service Function|      |Service Function|
    ++----------+---+    +-------+--------+      +-------+--------+
     |          |                |                       |
     | SFC Encapsulation   SFC Encapsulation     No SFC Encapsulation
     ^          |                |                       |
   Original     |                |                  +---------+
   Traffic      +-----------+    |   +--------------|SFC Proxy|
     |                      |    |   |              +---------+
    .~.~.~,.             +--+----+---+----+
   /        \            | SF Forwarder   |
  | Original |           |      (SFF)     |
  | Network  |           +-------+--------+
   \.~.~.~.~/                    |
                         SFC Encapsulation
                                 |
                         +-------+--------+
                         | SFC Network    |
                         | Forwarder (NF) |
                         +----------------+
                                 |
                      Network Overlay Transport
                                 |
                              _,....._
                           ,-'        `-.
                          /              `.
                         |     Network    |
                         `.             /
                           `.__     _,-'
                               `''''

I'll send my other response on your feedbacks in another email.

Regards,
Lucy

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Thursday, May 15, 2014 8:51 AM
To: Lucy yong
Cc: Joel M. Halpern; [email-masked]
Subject: Re: Comments on RE: New Version Notification for draft-quinn-sfc-arch-05.txt

Lucy,

Paul

Hi Paul and Joe,

PQ>  All the components are logical, and therefore and be combined as needed by an implementor.  You do raise a good point about a SN though.  I tend to think of it as an optimization used for implementation, we'll review how to present it in the draft.

PQ>  I don't understand the question.  Packets go NF <-> SFF <-> SF.

PQ>  Figure 1 simply uses a linear depiction of the path.  If it's confusing one of the figure can be reoriented to explicitly depict branching.  Also, that sentence will be moved, thanks for catching it.

PQ>  There is a dedicated "SFC Proxy" subsection, so it is a distinct (logical) component.

PQ>  That is a broad statement, there's nothing in this draft the precludes, or assumes for that matter, multi-tenancy.  Are there specific areas you'd like to see addressed, or sections added?

Thanks
Paul

---

From: Lucy yong <[email-masked]>
Date: Thu, 15 May 2014 19:21:19 +0000

Hi Paul and Joel,

Thank you for the reply. Please see inline below.

[snip]

PQ>  We are clarifying that there is no implication of a SF registry.
[Lucy] Yes. Why is this clarifying necessary?

[Lucy] Good.

[Lucy]

PQ>  Figure 1 simply uses a linear depiction of the path.  If it's confusing one of the figure can be reoriented to explicitly depict branching.  Also, that sentence will be moved, thanks for catching it.
[Lucy] IMO: since branching is allowed in the arch and figure 1 gives several SFC examples, it is better to show branching case as well.

PQ>  Do you have any suggested text and/or a updates to the figure?
[Lucy] proposed in another mail.

PQ>  This table is simply a conceptual representation of how service forwarding is maintained at the SFFs. SFID details, including which SFF they are associated with, could be maintained separately at each SFF. We do not want to impose how they are implemented.
[Lucy] I see. Suggest "The SF columns of this table may come from different SFFs." to be replaced by "The SFs in this table may be on same or different SFFs".

PQ>  There is a dedicated "SFC Proxy" subsection, so it is a distinct (logical) component.
[Lucy] text:
   The SFF component has the following primary responsibilities:
...
   3.  Maintaining flow state: In some cases, the SFF may be stateful.
       It creates flows and stores flow-centric information.  When
       traffic arrives after being steered through an SFC-unaware SF,
       the SFF must perform re-classification of traffic to determine
       the SFP.  A state-full SFF simplifies such classification to a
       flow lookup.

[Lucy] comment: if SFC proxy is used in b/w SFF and SFC-unaware SF, the SFF can treat the SF as a SFC-aware SF, isn't it? Not sure why SFF must perform re-classification as described in text.

PQ>  That is a broad statement, there's nothing in this draft the precludes, or assumes for that matter, multi-tenancy.  Are there specific areas you'd like to see addressed, or sections added?
[Lucy] In DC, a SF may be used by several SFCs that may belong to different tenant networks, is this valid use case? If yes, NF component need to maintain the state about SFP/tenant network mapping, right? Suggest to add some text in section 4.4 to cover that.

[Lucy] Good.

PQ>  Yes and no: the SFC network is an overlay but it introduces a new topology due to the service chain.
[Lucy] Agree. Maybe consider using "SFC network" through the doc, and state about in SFC network definition.

Thanks,
Lucy

Thanks
Paul

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 16 May 2014 14:46:41 +0000

Paul,

 Section 4 describes core SFC arch components. Classification is stated as a core SFC arch component and is a logical component, and "as a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data prior to forwarding along the SFP." However, is does not illustrate this component in figure 2, which makes unclear how this component relates to other component in this figure or described in the text. Suggest illustrating this component in figure 2 and/or describe it in text.

[Linda] I suggest using this figure from http://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/

                     |1  -----   |n        |21   ---- |2m

                 +---+---+   +---+---+   +-+---+   +--+-----+

                 | SF#1  |   |SF#n   |   |SF#i1|   |SF#im   |

                 |       |   |       |   |     |   |        |

                 +---+---+   +---+---+   +--+--+   +--+--+--+

                     :           :          :         :  :

                     :           :          :         :  :

                     \         /            \       /

    +--------------+   +--------+             +---------+

-- >| Chain        |   | SFF    |   ------    | SFF     | ---->

    |classifier    |   |Node-1  |             | Node-i  |

    +--------------+   +----+---+             +----+--+-+

                  \         |                     /

                   \        | SFC Encapsulation  /

                    \       |                   /

,. ......................................._

,-'                                        `-.

/                                              `.

|                      Network                   |

`.                                             /

`.__.................................. _,-'

Linda