Subject: [sfc] Suggestions on draft-ietf-sfc-control-plane-08

From: Phaneendra Manda <[email-masked]>
Date: Tue, 13 Dec 2016 18:54:36 +0530

Dear Authors,

I have the below suggestions on the draft-ietf-sfc-control-plane-08.

1. In Section 2.3,
   By default, SFC data and control plane elements must assume that SFC
   control information are dynamic by nature.  This requirement applies
   even for policies that are communicated via an upper layer to
   communicate service objectives and guidelines to a control element.
   Additionally, the SFC control plane must not assume that the
   capabilities of SFC data plane elements are frozen.  The SFC control
   architecture must be designed to accommodate any *dynamic of *SFs/SFFs
   attachments, software updates, dynamic network condition events, etc.

  can be

  By default, SFC data and control plane elements must assume that SFC
   control information are dynamic by nature.  This requirement applies
   even for policies that are communicated via an upper layer to
   communicate service objectives and guidelines to a control element.
   Additionally, the SFC control plane must not assume that the
   capabilities of SFC data plane elements are frozen.  The SFC control
   architecture must be designed to accommodate any *dynamic updates of *
SFs/SFFs
   attachments, software updates, dynamic network condition events, etc.

  -- Better readability.

2. In section 3.3.1
    The control plane must instruct the classifier about the initial
     values of the Service Index (SI).

     can be

     The control plane must instruct the classifier about the initial
      values of the *Service Path Index(SPI)* and Service Index (SI).

     -- The control plane must also instruct the Service Path Index(SPI) to
the classifier.

3.  In section 4.8
      Number of flows, packets, bytes dropped due to unknown service
      function chain (this is valid in particular for an SF node)

  -- The above point is not clear. If the packet does not classify any
classifier rule, then it will take the default forwarding path. If the
intention is to specify the broken Service function chain path, then this
point can be updated as

        Number of flows, packets, bytes dropped due to *broken path in *
service
      function chain (this is valid in particular for an SF node)

4. In section 4.10.1
    In the Examples of use cases for SFP adjustment are listed below:
  The first point can be *SF fail over*.  or Please help me understand if
there any specific reason why it is considered as SFP fail over.

-- 
Thanks & regards,
Phaneendra Manda.

---

From: <[email-masked]>
Date: Wed, 14 Dec 2016 07:00:44 +0000

Dear Phaneendra,

Thank you for sharing your comments.

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Phaneendra Manda
Envoyé : mardi 13 décembre 2016 14:25
À : [email-masked]
Objet : [sfc] Suggestions on draft-ietf-sfc-control-plane-08

Dear Authors,

1. In Section 2.3,
   architecture must be designed to accommodate any dynamic of SFs/SFFs

  can be

   architecture must be designed to accommodate any dynamic updates of SFs/SFFs

  -- Better readability.

[Med] I prefer the initial wording as the intent is to cover the dynamic of SFs instantiation and attachment to SFFs; of course this can be implemented as “update” control messages but the text does focus on purpose on the expected behavior rather than how to achieve it.

2. In section 3.3.1

     can be

     The control plane must instruct the classifier about the initial
      values of the Service Path Index(SPI) and Service Index (SI).

     -- The control plane must also instruct the Service Path Index(SPI) to the classifier.

[Med] The suggested modification is redundant with early text in that section. Indeed, SPI setting is already covered earlier in (Section 3.3.1):

   This interface is used to install SFC classification rules in
   classifiers.  Once classification rules are populated, classifiers
   are responsible for binding incoming traffic to service function
   chains and SFPs according to these classification rules.

SPI will be set according to these classification rules.

3.  In section 4.8

  -- The above point is not clear. If the packet does not classify any classifier rule, then it will take the default forwarding path. If the intention is to specify the broken Service function chain path, then this point can be updated as
[Med] Yes, the intent is to cover cases where a packet is directed to an SF but that SFC-aware SF is not supposed to be part of the associated service chain (e.g., local policies are configured to the SFC-aware SF to restrict its service to a set of chains).

        Number of flows, packets, bytes dropped due to broken path in service
      function chain (this is valid in particular for an SF node)

[Med] This change looks good to me.

4. In section 4.10.1
    In the Examples of use cases for SFP adjustment are listed below:
  The first point can be SF fail over.  or Please help me understand if there any specific reason why it is considered as SFP fail over.

[Med] You are referring to this item :

   SFP fail-over:   re-construct an SFP with replacing the failed SF

      instance with another instance of the same SF or withdraw the

      failed SF from being invoked.  Note that withdrawing an SF may be

      envisaged if the resulting connectivity service is not broken

      (that is, packets bound to the updated SFP can be successfully

      delivered to their ultimate destinations).

This is about ‘SFP fail-over’ because this item discusses actions that have an impact on how an SFP is constructed. Sure, the root cause in this example can be an SF failure, but the action is set (in this case) at the SFP level not the SF one. Of course, there are other means to handle an SF failure without impacting SFPs that make use of it, but those are not the purpose of the item you quoted.

Thank you.

--
Thanks & regards,
Phaneendra Manda.

---

From: Phaneendra Manda <[email-masked]>
Date: Thu, 15 Dec 2016 18:51:27 +0530

Dear Med,

I agree with you for 1, 3 and 4.

But for 2nd point, i could not find any reference in the draft for Service
Path Index(SPI).
I think this value also should be sent by control plane to classifier.

Thanks,
Phaneendra.

On Wed, Dec 14, 2016 at 12:30 PM, <[email-masked]> wrote:

> *De :* sfc [mailto:[email-masked]] *De la part de* Phaneendra Manda
> *Envoyé :* mardi 13 décembre 2016 14:25
> *À :* [email-masked]
> *Objet :* [sfc] Suggestions on draft-ietf-sfc-control-plane-08
>
>
>
> Dear Authors,
>
>
>
> [Med] I prefer the initial wording as the intent is to cover the dynamic
> of SFs instantiation and attachment to SFFs; of course this can be
> implemented as “update” control messages but the text does focus on purpose
> on the expected behavior rather than how to achieve it.
>
>
>
>
>
> 2. In section 3.3.1
>
> [Med] The suggested modification is redundant with early text in that
> section. Indeed, SPI setting is already covered earlier in (Section 3.3.1):
>
>
>
> [Med] Yes, the intent is to cover cases where a packet is directed to an
> SF but that SFC-aware SF is not supposed to be part of the associated
> service chain (e.g., local policies are configured to the SFC-aware SF to
> restrict its service to a set of chains).
>
>
>

---

From: <[email-masked]>
Date: Thu, 15 Dec 2016 13:29:11 +0000

Dear Phaneendra,

Please see inline.

Cheers,
Med

De : Phaneendra Manda [mailto:[email-masked]]
Envoyé : jeudi 15 décembre 2016 14:21
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: [sfc] Suggestions on draft-ietf-sfc-control-plane-08

Dear Med,

[Med] Ok, thank you.

But for 2nd point, i could not find any reference in the draft for Service Path Index(SPI).
I think this value also should be sent by control plane to classifier.

[Med] You are right. This is actually part of the “classification rules” mentioned in the text I shared in my previous message. A classification rule is defined in the document as follows:

   o  SFC Classification rule: Refers to a rule maintained by a
      classifier that reflects the policies for binding an incoming
                                                ^^^^^^^^^^^^^^^^^^^^
      flow/packet to a given SFC and Service Function Path (SFP).
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I can modify the text to make it explicit that SPI is part of the classification rule.

Thanks,
Phaneendra.

On Wed, Dec 14, 2016 at 12:30 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Phaneendra,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]<mailto:[email-masked]>] De la part de Phaneendra Manda
Envoyé : mardi 13 décembre 2016 14:25
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] Suggestions on draft-ietf-sfc-control-plane-08

Dear Authors,

1. In Section 2.3,

  can be

  -- Better readability.

2. In section 3.3.1

     can be

3.  In section 4.8

4. In section 4.10.1

Thank you.

--
Thanks & regards,
Phaneendra Manda.

---

From: Phaneendra Manda <[email-masked]>
Date: Fri, 16 Dec 2016 14:36:46 +0530

Dear Med,

I can modify the text to make it explicit that SPI is part of the
classification rule.
  -- This would be helpful. According to my understanding SPI, SI and
metadata goes to the service header and this information need to be
configured by control plane.

-- 
Thanks & regards,

Phaneendra Manda.

On Thu, Dec 15, 2016 at 6:59 PM, <[email-masked]> wrote:

> Dear Phaneendra,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Phaneendra Manda [mailto:[email-masked]]
> *Envoyé :* jeudi 15 décembre 2016 14:21
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* [email-masked]
> *Objet :* Re: [sfc] Suggestions on draft-ietf-sfc-control-plane-08
>
>
>
> Dear Med,
>
>
>
> [Med] You are right. This is actually part of the “classification rules”
> mentioned in the text I shared in my previous message. A classification
> rule is defined in the document as follows:
>
>
>

---

From: <[email-masked]>
Date: Fri, 16 Dec 2016 10:11:08 +0000

Dear Phaneendra,

OK, noted.

This will be fixed in the next revision of the document.

Cheers,
Med

De : Phaneendra Manda [mailto:[email-masked]]
Envoyé : vendredi 16 décembre 2016 10:07
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: [sfc] Suggestions on draft-ietf-sfc-control-plane-08

Dear Med,

I can modify the text to make it explicit that SPI is part of the classification rule.
  -- This would be helpful. According to my understanding SPI, SI and metadata goes to the service header and this information need to be configured by control plane.

--
Thanks & regards,

Phaneendra Manda.

On Thu, Dec 15, 2016 at 6:59 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Phaneendra,

Please see inline.

Cheers,
Med

De : Phaneendra Manda [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : jeudi 15 décembre 2016 14:21
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Suggestions on draft-ietf-sfc-control-plane-08

Dear Med,

Thanks,
Phaneendra.

Please see inline.

Cheers,
Med

Dear Authors,

1. In Section 2.3,

  can be

  -- Better readability.

2. In section 3.3.1

     can be

3.  In section 4.8

4. In section 4.10.1

Thank you.

--
Thanks & regards,
Phaneendra Manda.