Subject: [sfc] Comments and suggestions to draft-boucadair-sfc-framework-00

From: Linda Dunbar <[email-masked]>
Date: Wed, 29 Jan 2014 17:31:14 +0000

Mohamed,

I have some comments and suggestions to your draft "draft-boucadair-sfc-framework-00":

1.5 Rationale:
First bullet: Does "Dynamic Provisioning" mean the "provisioning of the service functions" or dynamically steering traffic to service functions?
Third to last bullet (p6):  "Nodes are provisioned with the policy table of the SFC enabled domain they belong to": what is the "policy table"? Do nodes include SF nodes and transport nodes?

Section 2 Terminology:
"Legacy Node":
We need to acknowledge the existence of "Legacy Service Functions" that don't terminate any new SF header to be specified by IETF SFC WG.   The term "proxy node" is introduced by [NSC-header] as an entity to remove and insert service layer encapsulation on behalf of service nodes that are not aware service layer encapsulation.
Suggest the following warding for the "Legacy Node":
"Legacy service node:  the existing service nodes that are not aware of the new service encapsulation layers or overlay encapsulation layer being specified in SFC WG. "
"SF proxy node: a node, most likely a network node along the data path, to terminate and encapsulate service layer encapsulation on behalf of legacy service nodes."

Section 3:
"SFC Classifier": the policy for service chain can also be based on port or other attributes that are not in the packet header. Therefore suggest the following wording.
"SFC Classifier: an entity that classifiers packets for service chaining according to classification rules defined in a SFC Policy Table. Packets are then marked with the corresponding SF Map Index. SFC Classifier is embedded in a SFC boundary (Ingress) Node."

Maybe also worth mentioning: "SFC Egress Node removes the SF Map Index from the packets"?

Section 4.4:
Direction can be reflected by the ports for the Ingress SFC boundary nodes. It can be easier to eliminate the "direction" attribute in the SFC Policy Table.

BR,

Linda Dunbar

---

From: <[email-masked]>
Date: Thu, 30 Jan 2014 08:09:41 +0100

Hi Linda,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : Linda Dunbar [mailto:[email-masked]]
Envoyé : mercredi 29 janvier 2014 18:31
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Comments and suggestions to draft-boucadair-sfc-framework-00

Mohamed,

1.5 Rationale:
First bullet: Does "Dynamic Provisioning" mean the "provisioning of the service functions" or dynamically steering traffic to service functions?
[Med] It refers to the provisioning of the "Service Functions" and "SFC Classier".
Third to last bullet (p6):  "Nodes are provisioned with the policy table of the SFC enabled domain they belong to": what is the "policy table"?
[Med] The policy table is defined in Section 2:

   o  SFC Policy Table: is a table containing a list of SF Maps, SFC
      classification rules and Locators for all SF Nodes.  A SFC Policy
      Table may contain a default SF Map.
Do nodes include SF nodes and transport nodes?
[Med] It includes only "SF Nodes" and "SFC Boundary Node".

Section 2 Terminology:
"Legacy Node":
We need to acknowledge the existence of "Legacy Service Functions" that don't terminate any new SF header to be specified by IETF SFC WG.   The term "proxy node" is introduced by [NSC-header] as an entity to remove and insert service layer encapsulation on behalf of service nodes that are not aware service layer encapsulation.
Suggest the following warding for the "Legacy Node":
"Legacy service node:  the existing service nodes that are not aware of the new service encapsulation layers or overlay encapsulation layer being specified in SFC WG. "
[Med] Shouldn't the wording be updated to reflect that these legacy service nodes cannot be upgraded to support the (to be defined) SFC features? There are various considerations to take into account such as the following:

·         Some of the existing service nodes can be upgraded while other cannot

·         Even in the presence of an SFC domain, an operator may decide to not enable SFC feature in a node (even if supports the sfc features)
"SF proxy node: a node, most likely a network node along the data path, to terminate and encapsulate service layer encapsulation on behalf of legacy service nodes."
[Med] I see the point. I think this is useful to be discussed in Section "10.2. Deployment Models" (http://tools.ietf.org/html/draft-boucadair-sfc-framework-00#section-10.2)

Section 3:
"SFC Classifier": the policy for service chain can also be based on port or other attributes that are not in the packet header. Therefore suggest the following wording.
"SFC Classifier: an entity that classifiers packets for service chaining according to classification rules defined in a SFC Policy Table. Packets are then marked with the corresponding SF Map Index. SFC Classifier is embedded in a SFC boundary (Ingress) Node."
[Med] Works for me. Thanks.

Maybe also worth mentioning: "SFC Egress Node removes the SF Map Index from the packets"?
[Med] No problem to add it.

Section 4.4:
Direction can be reflected by the ports for the Ingress SFC boundary nodes. It can be easier to eliminate the "direction" attribute in the SFC Policy Table.
[Med] In fact there is no "direction" attribute in the SFC Policy Table. Will double check the text to make it clear.

BR,
[Med] Thank you for the review and suggestions.

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 30 Jan 2014 16:04:44 +0000

Med,

Thanks for the reply. Some additional comments inserted below. Hope you can incorporate them into 01 version.

1.5 Rationale:

[Linda] You don't mean including dynamically provisioning service function behavior, do you?  Provisioning Video Optimizer is so different than provisioning Firewall. It will be too much for SFC WG to address the individual service function behavior.

Section 2 Terminology:

[Linda] The section 10.2 in the current  00 version is very brief. You can consider adding some sections from https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/, especially the Section 3.3:

1.1. Proxy Node for Legacy Service Functions
Section 3.4 of [NSC-Header] describes a scenario that the service nodes are not aware of service encapsulation header. The term "proxy node" is introduced by [NSC-header] as an entity to remove and insert service layer encapsulation on behalf of service nodes that are not aware service layer encapsulation.
Even though Service Nodes can be instantiated anywhere in the network, it is not uncommon to have multiple [legacy] service nodes located in close vicinity with a service chain proxy node, or one to two links away. The following figure depicts typical network architecture for chaining those service nodes that are not aware of service layer encapsulation.

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

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

                 | Ad    |   |Content|   |Video|   |Security|

                 |Insert |   | Opt   |   | Opt |   | App    |

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

                     :           :          :         :  :

                     :           :          :         :  :

                      \         /            \       /

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

-- >| Chain        | ->| Proxy  |--------->   | Proxy   | ---->

    |classification|   |Node-1  |             | Node-i  |

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

                              |--                  |  |

                              V                    +--->

                         +--------+

                         | Proxy  |

                         |   -j   |----->

                         +--------+

Figure 1                        Chaining existing service nodes
When there are multiple service nodes located in the vicinity of a service chain "proxy node", the Proxy node needs to steer designated traffic to the designated service functions.
The service chain proxy nodes can be standalone devices, or can be embedded with routers or switches in the network. Overlay tunnels are expected to connect the "proxy nodes" together.

Linda Dunbar

---

From: <[email-masked]>
Date: Fri, 31 Jan 2014 07:42:43 +0100

Hi Linda,

Please see inline.

Cheers,
Med

De : Linda Dunbar [mailto:[email-masked]]
Envoyé : jeudi 30 janvier 2014 17:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : RE: Comments and suggestions to draft-boucadair-sfc-framework-00

Med,

1.5 Rationale:

[Linda] You don't mean including dynamically provisioning service function behavior, do you?  Provisioning Video Optimizer is so different than provisioning Firewall. It will be too much for SFC WG to address the individual service function behavior.
[Med] What is meant is SFC-specific provisioning. Note, the same entity responsible for provisioning SFC-specific features may be responsible for provisioning SF-specific features, but IMHO that is out of scope of SFC WG.

Section 2 Terminology:

[Linda] The section 10.2 in the current  00 version is very brief. You can consider adding some sections from https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/, especially the Section 3.3:
[Med] Will consider adding that text. Thanks.

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

                     :           :          :         :  :

                     :           :          :         :  :

                      \         /            \       /

                              |--                  |  |

                              V                    +--->

                         +--------+

                         | Proxy  |

                         |   -j   |----->

                         +--------+

Linda Dunbar