Subject: Re: [sfc] 2nd WG Last Call on Problem Statement

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Fri, 4 Jul 2014 08:11:57 +0000

This latest revision looks good to move forward. Just one minor comment.

Section 3.3 Dataplane metadata, second paragraph "Metadata can include the result of antecedent classification and/or information from external sources. "  Such description can't support exchanging data between SFs, the case mentioned in previous paragraph "Data plane metadata provides the ability to exchange information between ... and between service functions." 'cause processing by a SF to create metadata is not necessarily a classification. Propose to add "processing".

BTW, a typo in abstraction. "reflect" -> "reflects".

Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Thursday, June 26, 2014 3:14 AM
To: [email-masked]
Subject: [sfc] 2nd WG Last Call on Problem Statement

Hi.

We ran a WGLC on the problem statement draft
(draft-ietf-sfc-problem-statement-07.txt) back in May.
Although the draft received significant review and support prior to the formal LC, the actual last call resulted largely in silence.

While it would be convenient to take silence as acceptance, that's not good enough. To show the document is ready, we need WG members to speak up and indicate they have read a recent version of the document and think its ready to go.

Note that the document was just reissued. Section 3 has been edited to remove some of the text was deemed to be encroaching on architecture. You can see the changes at http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-sfc-problem-statement-07-from-06.diff.html

With that, we are restarting a 2-week WGLC on the document. We specifically need to see sufficient indications from WG members that the document is ready to advance, and that the document does not contain significant deficiencies.

Thomas

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

---

From: Kengo Naito <[email-masked]>
Date: Mon, 07 Jul 2014 18:08:57 +0900

Support.

Kengo

(2014/06/26 4:13), Thomas Narten wrote:
> Although the draft received significant review and support prior to
> the formal LC, the actual last call resulted largely in silence.
>
> While it would be convenient to take silence as acceptance, that's not
> good enough. To show the document is ready, we need WG members to
> speak up and indicate they have read a recent version of the document
> and think its ready to go.
>
> Note that the document was just reissued. Section 3 has been edited to
> remove some of the text was deemed to be encroaching on
> architecture. You can see the changes at
> http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-sfc-problem-statement-07-from-06.diff.html
>
> With that, we are restarting a 2-week WGLC on the document. We
> specifically need to see sufficient indications from WG members that
> the document is ready to advance, and that the document does not
> contain significant deficiencies.
>
> Thomas
>

-- 
----------------------------------------
NTT Network Technology Laboratories
Kengo Naito
E-Mail: [email-masked]
TEL: +81 422-59-4949
----------------------------------------

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Mon, 7 Jul 2014 12:05:19 +0000

Also support - Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Kengo Naito
Gesendet: Montag, 7. Juli 2014 11:09
An: [email-masked]
Betreff: Re: [sfc] 2nd WG Last Call on Problem Statement

Support.

Kengo

(2014/06/26 4:13), Thomas Narten wrote:
> remove some of the text was deemed to be encroaching on architecture. 
> You can see the changes at 
> http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ie
> tf-sfc-problem-statement-07-from-06.diff.html
>

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 8 Jul 2014 03:38:08 +0000

Hi Thomas and all,

After a review of draft-ietf-sfc-problem-statement-07, I have the following comments and suggestions:

1. The definition of "Classification" does not parse to me, it says:
"   Classification:  Locally instantiated policy that results in matching
      of traffic flows for identification of appropriate outbound
      forwarding actions."
Classification seems to be defined as a kind of policy, but it is not.
It is suggested to be defined as:
"     Classification: Identification of traffic flows based on locally 
      instantiated policy for appropriate outbound forwarding actions."

2. "Network Overlay" is defined but not used at all in the contexts - except in Section "Related IETF Work", however, the definition of "Service Overlay" introduces a new terminology "overlay network":  
"   Service Overlay:  An overlay network created for the purpose of
      forwarding data along a service function path. "
Is this "overlay network" actually a typo of "network overlay"? 

3. "Service Function Path" is defined as:
"   Service Function Path (SFP):  The instantiation of a service function
      chain in the network.  Packets follow a service function path from
      a classifier through the required instances of service functions
      in the network."
SFP seems to be instantiation of an SFC, that is very confusing. Maybe it will be more concrete to be repharased as:       
"   Service Function Path (SFP): A path for packet forwarding constructed 
      from a classifier through the required instances of service functions 
      after the instantiation of a service function chain in the network."

4. In Section 2.10, the title is "Per-Service (re)Classification", but it actually discusses per-service-function (re)classification.
Therefore, it is suggested:
s/Per-Service/Per-Service-Function/
s/per-service/per-service-function/

5. In Section 3.2, it says:
"Symmetric classification ensures that forward and reverse chains are in place."
But what is "Symmetric classification"? What does it mean by "in place"?

6. In Section 3.3, it says:
"...As such metadata is not used as forwarding information to deliver packets 
along the service overlay."
It is strange to have such a negative phrase here. From the definition of "service overlay" and the contexts, it is unclear who will forward the packet, and what forwarding information is realy needed, therefore, it is too early to make such a statement, and it should be rightfully considered in an architecture draft IMHO.

7. In Section 3.3, it says:
"  ... Service functions utilize
   metadata, as required, for localized policy decisions."
   Is "localized policy decisions" the only valid thing for metadata to be used? Or is it just an example?

Other minor editorial proposals:
s/real or virtualized/physical or virtualized/     
s/fearing misconfiguration and downtime/for fear of misconfiguration and consequent downtime/ 
s/inter- vendor/inter-vendor/
s/decoupling of policy from the topology/decoupling of policy from the network topology/  (BTW, we only defined service topology in the document)

Regards,
Yuanlong

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Thursday, June 26, 2014 3:14 AM
To: [email-masked]
Subject: [sfc] 2nd WG Last Call on Problem Statement

Hi.

Thomas

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 8 Jul 2014 19:37:24 +0000

Hi,

Thank you for your comments, please see inline.

On Jul 7, 2014, at 11:38 PM, Jiangyuanlong <[email-masked]> wrote:

>      instantiated policy for appropriate outbound forwarding actions.”

PQ>  I don’t think this improves the definition.  Unless there’s consensus from the community, this doesn’t need to change.

> Is this "overlay network" actually a typo of "network overlay”? 

PQ>  We use the term overlay network appropriately here.  The service overlay is an overlay network.  

>      after the instantiation of a service function chain in the network.”

PQ>  Thank you for this comment, the original defn explains a key concept which is the relationship to an SFC; your suggested text makes that less clear.

> s/per-service/per-service-function/

PQ>  Will update.

> But what is "Symmetric classification"? What does it mean by "in place”?

Symmetric classification involves the use of classification criteria that reflect the “forward” and “reverse” traffic.  For example: src a —> dst b and src b —> dst a.  

> It is strange to have such a negative phrase here. From the definition of "service overlay" and the contexts, it is unclear who will forward the packet, and what forwarding information is realy nee…

PQ>  We bound the problem to not include forwarding based on metadata.  Thus far the consensus is that this makes sense.

>   Is "localized policy decisions" the only valid thing for metadata to be used? Or is it just an example?

PQ>  This is an example.

> s/decoupling of policy from the topology/decoupling of policy from the network topology/  (BTW, we only defined service topology in the document)

PQ>  Those edits will be reflected in the draft.

Thanks again,
Paul

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 9 Jul 2014 03:24:37 +0000

Hi Paul,

Please see my further comments inline with [JY].

BTW, another editorial proposal:
s/both forwarding directions/both forwarding and reverse directions/

Thanks,
Yuanlong

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2014 3:37 AM
To: Jiangyuanlong
Cc: Thomas Narten; [email-masked]
Subject: Re: [sfc] 2nd WG Last Call on Problem Statement

Hi,

>      instantiated policy for appropriate outbound forwarding actions."

PQ>  I don't think this improves the definition.  Unless there's consensus from the community, this doesn't need to change.

PQ>  We use the term overlay network appropriately here.  The service overlay is an overlay network.  
[JY]  Then definition of "Network Overlay" is suggested to be removed, as it is only referred by Section 4 [NVO3]. It is actually a terminology frequently used in NVO3, thus there is no need to be defined in this SFC PS.

> SFP seems to be instantiation of an SFC, that is very confusing. Maybe it will be more concrete to be rephrased as:       

PQ>  Thank you for this comment, the original defn explains a key concept which is the relationship to an SFC; your suggested text makes that less clear.
[JY]  if it is a key concept, then "instantiation of a service function chain" needs to be explained in the first place. 

PQ>  Will update.

> But what is "Symmetric classification"? What does it mean by "in place"?

Symmetric classification involves the use of classification criteria that reflect the "forward" and "reverse" traffic.  For example: src a -> dst b and src b -> dst a.  
[JY] Can we add this into the document to make it clear?

PQ>  We bound the problem to not include forwarding based on metadata.  Thus far the consensus is that this makes sense.
[JY]  Section 2 "Problem Space" does not have such a requirement, it is definitely in solution space. 
Even there is consensus that metadata cannot be used as forwarding information to deliver packets, the statement should be better made in SFC architecture document.

>   Is "localized policy decisions" the only valid thing for metadata to be used? Or is it just an example?

PQ>  This is an example.
[JY] To be clearer, it is suggested to replace "as required" with "e.g.".

Thanks again,
Paul

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 08:30:55 +0000

Hi Thomas,

Great to see the document updated to remove some architectural discussion. Many thanks to the editors.

This version is much better, nevertheless the document is still touching on architectural point or hinting some design choices (the point about re-classification as an example, or mentioning metadata that is an optional component of the overall architecture). 

The document defines also terms that are not cited in the document, and which belong to the architecture discussion (e.g. SFP, service node). The actual definition + what exact term is to be used is still ongoing. Having those terms in a PS is not only odd, but will make it harder for the reader. Please remove these terms from the document.

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de Thomas Narten
>Envoyé : mercredi 25 juin 2014 21:14
>À : [email-masked]
>Objet : [sfc] 2nd WG Last Call on Problem Statement
>
>Hi.
>
>http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-
>sfc-problem-statement-07-from-06.diff.html
>