Subject: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

From: [email-masked]
Date: Wed, 11 May 2016 23:44:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Service Function Chaining of the IETF.

        Title           : Service Function Chaining (SFC) Control Plane Components & Requirements
        Author          : Mohamed Boucadair
	Filename        : draft-ietf-sfc-control-plane-05.txt
	Pages           : 27
	Date            : 2016-05-11

Abstract:
   This document describes requirements for conveying information
   between Service Function Chaining (SFC) control elements and SFC data
   plane functional elements.  Also, this document identifies a set of
   control interfaces to interact with SFC-aware elements to establish,
   maintain or recover service function chains.  This document does not
   specify protocols nor extensions to existing protocols.

   This document exclusively focuses on SFC deployments that are under
   the responsibility of a single administrative entity.  Inter-domain
   considerations are out of scope.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Thu, 12 May 2016 06:47:53 +0000

Dear all, 

This version addresses the comments received during the WGLC. You can check the diff to track the changes. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 12 mai 2016 08:45
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-ietf-sfc-control-plane-05.txt
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Martin Stiemerling <[email-masked]>
Date: Sat, 14 May 2016 11:28:48 +0200

Dear all,

The authors have posted an updated version addressing the reviews out of
the WGLC.

Please check until May 20th 5pm CEST if your comments have been addressed.

Thanks,

    Martin

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Sat, 14 May 2016 17:47:45 +0000

I would like to see my comments addressed for section 4.10.4.

Our charter calls for a single SFC encapsulation and that is being
documented in draft-ietf-sfc-nsh. The text within this section suggests
that forwarding can be enabled using an SFP-id and some other condition
such as input port etc. This is inaccurate based upon the SFC
encapsulation as well as our WG charter. There is no mention of the SFC
encapsulation or the fact that the NSH base header is the method used for
forwarding; note that the most common forwarding method (and the one
implemented in several places) is SFP-id + index - this is not even
mentioned!. In addition, this is a control plane document; there is no
need to talk about forwarding other than point to the SFC encapsulation
document.

For these reasons I would like to see this section removed from the
document.

Jim

On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Tue, 17 May 2016 05:42:24 +0000

Hi Jim,

I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in -05) have been addressed. 

For the record, Andy shared a proposal here (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I send a text proposal here (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These changes were implemented in -05 given that no objections were raised against them.

Also, the old section 4.10.4 was removed as per one of your comments.

Applying policies on the full aggregate (sfp-id) is the default mode. But for the particular case of this section (that is about "Fully Controlled SFF/SF Sequence for a SFP"), there might be deployments where it is appropriate to allow for local enforcement of polices that are more fine-grained (TE, for example).  This section does not specify a new sfc encapsulation or calls for recommendation how forwarding must be achieved. It does discuss some information that can be passed via the C2 interface if additional information is required to achieve some TE goals. 

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Jim Guichard
> (jguichar)
> Envoyé : samedi 14 mai 2016 19:48
> À : Martin Stiemerling; [email-masked]
> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 17 May 2016 15:44:51 +0000

Jim, 

Why "calling for a single SFC encapsulation" conflicts with SFC control plane sending request (via out of bound) to steer NSH encapsulated packets based on some criteria (e.g. port, or time stamp, or others)? 

For example, when detecting a port status problem (from scheduling or monitoring),  can SFC control plane be allowed to ask the forwarding devices to steer traffic to different port (based on its specific criteria)?

Just curious, 

Linda 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, May 14, 2016 12:48 PM
To: Martin Stiemerling; [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

Our charter calls for a single SFC encapsulation and that is being documented in draft-ietf-sfc-nsh. The text within this section suggests that forwarding can be enabled using an SFP-id and some other condition such as input port etc. This is inaccurate based upon the SFC encapsulation as well as our WG charter. There is no mention of the SFC encapsulation or the fact that the NSH base header is the method used for forwarding; note that the most common forwarding method (and the one implemented in several places) is SFP-id + index - this is not even mentioned!. In addition, this is a control plane document; there is no need to talk about forwarding other than point to the SFC encapsulation document.

For these reasons I would like to see this section removed from the document.

Jim

On 5/14/16, 5:28 AM, "sfc on behalf of Martin Stiemerling"
<[email-masked] on behalf of [email-masked]> wrote:

>Dear all,
>
>The authors have posted an updated version addressing the reviews out 
>of the WGLC.
>
>> 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.
>>
>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 17 May 2016 17:30:54 +0000

Hi Med,

My concern (as chair) is with Figure 2 (and all of the text surrounding
it) which suggests that the forwarding is based on incoming SFP-id *and*
ingress port (or any of the other criteria listed).

This is misleading based upon RFC7665 which says the SFF forwards packets
based upon the information conveyed within the SFC encapsulation (see
https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC encapsulation
document (see 
https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7).

I suggest that the text is silent on whether the ingress interface has
context to the SFF - its an implementation/deployment decision.

Jim

On 5/17/16, 1:42 AM, "[email-masked]"
<[email-masked]> wrote:

>For the record, Andy shared a proposal here
>(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while I
>send a text proposal here
>(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html). These
>changes were implemented in -05 given that no objections were raised
>against them.
>
>Applying policies on the full aggregate (sfp-id) is the default mode. But
>for the particular case of this section (that is about "Fully Controlled
>SFF/SF Sequence for a SFP"), there might be deployments where it is
>appropriate to allow for local enforcement of polices that are more
>fine-grained (TE, for example).  This section does not specify a new sfc
>encapsulation or calls for recommendation how forwarding must be
>achieved. It does discuss some information that can be passed via the C2
>interface if additional information is required to achieve some TE goals.
>
>Cheers,
>Med
>
>>of
>> >>         Title           : Service Function Chaining (SFC) Control
>>Plane
>> >>Components & Requirements
>> >>submission

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 17 May 2016 17:32:45 +0000

Hi Linda,

See my response to Med. If you want to use other criteria above and beyond
the documented SFC encapsulation then that is an implementation choice not
a requirement within the control plane specification.

Jim

On 5/17/16, 11:44 AM, "Linda Dunbar" <[email-masked]> wrote:

>Jim, 
>
>Why "calling for a single SFC encapsulation" conflicts with SFC control
>plane sending request (via out of bound) to steer NSH encapsulated
>packets based on some criteria (e.g. port, or time stamp, or others)?
>
>For example, when detecting a port status problem (from scheduling or
>monitoring),  can SFC control plane be allowed to ask the forwarding
>devices to steer traffic to different port (based on its specific
>criteria)?
>
>Just curious, 
>
>Linda 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 17 May 2016 18:19:42 -0400

Jim,

There are no requirements in section 4.10.4, or indeed in section 4.10 at
all. There's no use of "required", "requirement", or "MUST" (although there
is a "not required" in one place).

Cheers,
Andy

On Tue, May 17, 2016 at 1:32 PM, Jim Guichard (jguichar) <[email-masked]
> wrote:

---

From: <[email-masked]>
Date: Wed, 18 May 2016 06:10:30 +0000

Hi Jim,

Thank you for clarifying your concern. 

RFC7665 does not exclude that additional information may be used with the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that multiple choices may be allowed in an SFF. See this excerpt, for example:  

   SFFs maintain the requisite SFP forwarding information.  SFP
   forwarding information is associated with a service path identifier
                          ^^^^^^^^^^^^^
   that is used to uniquely identify an SFP.  The service forwarding
   state enables an SFF to identify which SFs of a given SFP should be
   applied, and in what order, as traffic flows through the associated
   SFP.  While there may appear to the SFF to be only one available way
   to deliver the given SF, there may also be multiple choices allowed
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^     
   by the constraints of the SFP.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 4.10.4 does not violate RFC7665 because it assumes that the forwarding information is associated with SFP-id. It does not say that additional information MUST be supported other than SFP-id, or other information MUST be supported in addition to the SFP-id, but that some additional information MIGHT be needed to constrain the SFP (that is still uniquely identified by an SFP-id) for deployments requiring to control the full sequence of SFFs/SFs. The text cites some examples of such additional constraints.

Section 4.10.4 discusses how cp can be used to provision SFFs with additional constraints + how to it helps to retrieve the capabilities of SFFs. 

> context to the SFF - its an implementation/deployment decision.

I see that you are not conformable with Figure 2 (despite the text is clear this is an example). The intent of that figure is to illustrate the use of "match condition/action" cited in the text.  

Would you be OK if that Figure is removed?

Thank you.

Cheers,
Med

> De : Jim Guichard (jguichar) [mailto:[email-masked]]
> Envoyé : mardi 17 mai 2016 19:31
> À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 18 May 2016 11:41:52 +0000

Hi Med,

Yes, if you can remove Figure 2 and also the text "There are multiple different steering policies for one flow within one SFF and each set of steering policies is specific for an ingress port”.

In addition, can you also make it clear in the text that the SFP-id is carried within the SFC encapsulation. Suggested text:

Old:

For example, it could be the SFP-id together with any fields in the data packets, such as (non-exhaustive list):

New:

For example, it could be the SFP-id carried within the SFC encapsulation with any fields in the data packets, such as (non-exhaustive list):

Jim

On 5/18/16, 2:10 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jim,

You said:

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mardi 17 mai 2016 19:31
À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt
Hi Med,
On 5/17/16, 1:42 AM, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>> wrote:
>> À : Martin Stiemerling; [email-masked]<mailto:[email-masked]>
>> <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>>
>> >Dear all,
>> >
>> >Am 12.05.16 um 08:44 schrieb [email-masked]<mailto:[email-masked]>:
>> >>
>> >> [email-masked]<mailto:[email-masked]>
>> >[email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 18 May 2016 13:01:04 +0000

Re-,

Works for me.

Unless there is an objection, these changes will be implemented in the next revision.

Thank you.

Cheers,
Med

De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mercredi 18 mai 2016 13:42
À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

Hi Med,

Yes, if you can remove Figure 2 and also the text "There are multiple different steering policies for one flow within one SFF and each set of steering policies is specific for an ingress port".

Old:

New:

Jim

Hi Jim,

You said:

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mardi 17 mai 2016 19:31
À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt
Hi Med,

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 18 May 2016 09:36:28 -0400

I’m OK with the second change.

Regarding the first change, Jim asked to remove the text "There are
multiple different steering policies for one flow within one SFF and each
set of steering policies is specific for an ingress port.”.

Rather than remove it, I would suggest to revise it to: “As a local
decision, there may be multiple different steering policies for a flow
within an SFF and  steering policies may be specific for an ingress port.”.

Thanks,
Andy

On Wed, May 18, 2016 at 9:01 AM, <[email-masked]> wrote:

> *De :* Jim Guichard (jguichar) [mailto:[email-masked]]
> *Envoyé :* mercredi 18 mai 2016 13:42
>
> *À :* BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]
> *Objet :* Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt
>
>
>
> Hi Med,
>
>
>
> Yes, if you can remove Figure 2 and also the text "There are multiple
> different steering policies for one flow within one SFF *and each set of
> steering policies is specific for an ingress port*”.
>
>
>
> In addition, can you also make it clear in the text that the SFP-id is
> carried within the SFC encapsulation. Suggested text:
>
>
>
> Old:
>
>
>
> For example, it could be the SFP-id together with any fields in the
> data packets, such as (non-exhaustive list):
>
>
>
> New:
>
>
>
> For example, it could be the SFP-id carried *within the SFC encapsulation*
> with any fields in the data packets, such as (non-exhaustive list):
>
>
>
> Jim
>
>
>
> On 5/18/16, 2:10 AM, "[email-masked]" <
> [email-masked]> wrote:
>
>
>
> Hi Jim,
>
>
>
> RFC7665 does not exclude that additional information may be used with the
> SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges that
> multiple choices may be allowed in an SFF. See this excerpt, for example:
>
>
>
> Section 4.10.4 does not violate RFC7665 because it assumes that the
> forwarding information is associated with SFP-id. It does not say that
> additional information MUST be supported other than SFP-id, or other
> information MUST be supported in addition to the SFP-id, but that some
> additional information MIGHT be needed to constrain the SFP (that is still
> uniquely identified by an SFP-id) for deployments requiring to control the
> full sequence of SFFs/SFs. The text cites some examples of such additional
> constraints.
>
>
>
> Section 4.10.4 discusses how cp can be used to provision SFFs with
> additional constraints + how to it helps to retrieve the capabilities of
> SFFs.
>
>
>
> You said:
>
>
>
> I see that you are not conformable with Figure 2 (despite the text is
> clear this is an example). The intent of that figure is to illustrate the
> use of "match condition/action" cited in the text.
>
>
>
> De : Jim Guichard (jguichar) [mailto:[email-masked]
> <[email-masked]>]
>
> >I believe all your comments for section 4.10.5 (-04) (section 4.10.4 in
>
> >-05) have been addressed.
>
> >
>
> >> De : sfc [mailto:[email-masked] <[email-masked]>] De la
> part de Jim Guichard
>
> >> (jguichar)
>
> >> encapsulation or the fact that the NSH base header is the method used
>
> >>for
>
> >> >Please check until May 20th 5pm CEST if your comments have been
>
> >> addressed.
>
> >> >
>
> >> >Thanks,
>
> >> >
>
> >> >    Martin
>
> >> >
>
> >> >> A New Internet-Draft is available from the on-line Internet-Drafts
>
> >> >>directories.
>
> >> >> This draft is a work item of the Service Function Chaining of the
>
> >>IETF.
>
> >> >>
>
> >> >>    between Service Function Chaining (SFC) control elements and SFC
>
> >> data
>
> >> >>    plane functional elements.  Also, this document identifies a set
>
> >>of
>
> >> >>    control interfaces to interact with SFC-aware elements to
>
> >>establish,
>
> >> >>    maintain or recover service function chains.  This document does
>
> >>not
>
> >> >>    This document exclusively focuses on SFC deployments that are
>
> >>under
>
> >> >>    the responsibility of a single administrative entity.
>
> >>Inter-domain
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 May 2016 14:08:26 +0000

Hi, SFC,

Scanning through this discussion, I found it a bit odd that draft-ietf-sfc-control-plane-05.txt has not reference to the WG document that defines the SFC Encapsulation, draft-ietf-sfc-nsh, since that describes the specifics on SFF forwarding of packets.

I’d recommend adding a reference to draft-ietf-sfc-nsh-04.txt, with a citation next to SPI and Service Path Forwarding.

Thanks,

— Carlos.

> On May 18, 2016, at 9:36 AM, Andrew G. Malis <[email-masked]> wrote:
> 
> Regarding the first change, Jim asked to remove the text "There are multiple different steering policies for one flow within one SFF and each set of steering policies is specific for an ingress port.”.
> 
> Rather than remove it, I would suggest to revise it to: “As a local decision, there may be multiple different steering policies for a flow within an SFF and  steering policies may be specific for an ingress port.”.
> 
> Thanks,
> Andy
> 
> On Wed, May 18, 2016 at 9:01 AM, <[email-masked] <mailto:[email-masked]>> wrote:
> Re-,
> 
> 
> 
> Works for me.
> 
> 
> 
> De : Jim Guichard (jguichar) [mailto:[email-masked] <mailto:[email-masked]>]
> À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked] <mailto:[email-masked]>
> On 5/18/16, 2:10 AM, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> Hi Jim,
> 
> 
> 
> De : Jim Guichard (jguichar) [mailto:[email-masked] <mailto:[email-masked]>]
> 
> À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked] <mailto:[email-masked]>
> https://tools.ietf.org/html/rfc7665#section-4.3 <https://tools.ietf.org/html/rfc7665#section-4.3>) and the SFC encapsulation
> 
> document (see
> 
> https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7 <https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-7>).
> 
> On 5/17/16, 1:42 AM, "[email-masked] <mailto:[email-masked]>"
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> >Hi Jim,
> 
> >
> 
> >(http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html <http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html>) while I
> 
> >(http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html <http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html>). These
> 
> >> De : sfc [mailto:[email-masked] <mailto:[email-masked]>] De la part de Jim Guichard
> 
> >> (jguichar)
> 
> >> À : Martin Stiemerling; [email-masked] <mailto:[email-masked]>
> >> <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
> >>
> 
> >> >Dear all,
> 
> >> >
> 
> >> >Am 12.05.16 um 08:44 schrieb [email-masked] <mailto:[email-masked]>:
> 
> >> >>
> 
> >> >> https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ <https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/>
> >> >>
> 
> >> >> https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05 <https://tools.ietf.org/html/draft-ietf-sfc-control-plane-05>
> >> >>
> 
> >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05 <https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-05>
> >> >>
> 
> >> >>
> 
> >> >> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> >> >>
> 
> >> >> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> >> >>
> 
> >> >> [email-masked] <mailto:[email-masked]>
> >> >> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
> >> >> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
> >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> >> >>
> 
> >> >
> 
> >> >[email-masked] <mailto:[email-masked]>
> >> >https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> >>
> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> 
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 May 2016 10:17:36 -0400

So let me ask the question differently.
This is the control plane requirements draft.  As I understand the 
intent, it is to describe the properties that control solutions must 
have to meet the SFC WG needs.

If the section is not normative, and merely describes something that can 
be used in some circumstances, why are we including it?

Yours,
Joel

---

From: <[email-masked]>
Date: Wed, 18 May 2016 14:31:13 +0000

Hi Joel, 

The section describes an optional set of requirements targeting to control the full set of SFFs/SFs. For example, it specifies a requirement to instruct to SFFs which additional information to use to enforce forwarding policies (+SFP-id).

Cheers,
Med

> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : mercredi 18 mai 2016 16:18
> À : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin
> Stiemerling; [email-masked]
> > RFC7665 does not exclude that additional information may be used with
> the SFP-id to make SFF forwarding decisions. Also, RFC7665 acknowledges
> that multiple choices may be allowed in an SFF. See this excerpt, for
> example:
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 May 2016 10:36:02 -0400

If Jim and Carlos can live with it, I will let it go.  I have trouble 
with the notion of "optional requirements".

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 May 2016 15:39:11 +0000

To be frank, “optional requirement” sounds like an oxymoron to me.

Requirement [ri-kwahyuh r-muh nt]
that which is required; a thing demanded or obligatory

I understand requirements levels and RFC 2119, but really the spec ought to be clearly aligned with the control plane, and point to normative docs for other modules.

I’d suggest trying to keep the scope and focus as per “Service Function Chaining (SFC) Control Plane Components & Requirements”

I think this is also relevant: https://tools.ietf.org/html/rfc1925
   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away.

Thanks,

— Carlos.

> On May 18, 2016, at 10:36 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> If Jim and Carlos can live with it, I will let it go.  I have trouble with the notion of "optional requirements".
> 
> Yours,
> Joel
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 18 May 2016 11:47:42 -0400

Carlos et al,

There’s plenty of precedent for optional requirements - for example, one
that comes immediately to mind is RFC 5654, which contains “MAY”s in
addition to “MUST”s.

Cheers,
Andy

On Wed, May 18, 2016 at 11:39 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> *Requirement [ri-kwahyuh r-muh nt]*
> *that which is required; a thing demanded or obligatory*
>
>
> I understand requirements levels and RFC 2119, but really the spec ought
> to be clearly aligned with the control plane, and point to normative docs
> for other modules.
>
> I’d suggest trying to keep the scope and focus as per “Service Function
> Chaining (SFC) Control Plane Components & Requirements”
>
> The section describes an optional set of requirements targeting to control
> the full set of SFFs/SFs. For example, it specifies a requirement to
> instruct to SFFs which additional information to use to enforce forwarding
> policies (+SFP-id).
>
> Cheers,
> Med
>
> De : Joel M. Halpern [mailto:[email-masked] <[email-masked]>]
> it) which suggests that the forwarding is based on incoming SFP-id
>
> *and*
>
> This is misleading based upon RFC7665 which says the SFF forwards
>
> packets
>
> https://tools.ietf.org/html/rfc7665#section-4.3) and the SFC
>
> encapsulation
>
> document (see
> I believe all your comments for section 4.10.5 (-04) (section 4.10.4
>
> in
>
> (http://www.ietf.org/mail-archive/web/sfc/current/msg04616.html) while
>
> I
>
> (http://www.ietf.org/mail-archive/web/sfc/current/msg04651.html).
>
> These
>
> Applying policies on the full aggregate (sfp-id) is the default mode.
>
> But
>
> for the particular case of this section (that is about "Fully
>
> Controlled
>
> fine-grained (TE, for example).  This section does not specify a new
>
> sfc
>
> achieved. It does discuss some information that can be passed via the
>
> C2
>
> interface if additional information is required to achieve some TE
>
> goals.
>
>
> Cheers,
> Med
>
> De : sfc [mailto:[email-masked] <[email-masked]>] De la part
> de Jim Guichard
> (jguichar)
> documented in draft-ietf-sfc-nsh. The text within this section
>
> suggests
>
> that forwarding can be enabled using an SFP-id and some other
>
> condition
>
> encapsulation as well as our WG charter. There is no mention of the
>
> SFC
>
> mentioned!. In addition, this is a control plane document; there is
>
> no
>
> need to talk about forwarding other than point to the SFC
>
> encapsulation
>
> document.
>
> The authors have posted an updated version addressing the reviews
>
> out
>
> of
>
> the WGLC.
>
> until the htmlized version and diff are available at
>
> tools.ietf.org.
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 May 2016 15:51:54 +0000

Andy,

Yes, you are right, and I agree. That’s why I said "I understand requirements levels and RFC 2119”.

However, my point (which I did not clearly articulate) was not so much about optionality but about orthogonality.

I can support an "optional requirement” (as in MAY) for a control plane function.

I have a hard time understanding an “optional requirement” (as in it is a requirement about SFF Forwarding and data plane and not about control plane constructs).

Thanks,

— Carlos.

From: "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 18, 2016 at 11:47 AM
To: Carlos Pignataro <[email-masked]<mailto:[email-masked]>>
Cc: Joel Halpern <[email-masked]<mailto:[email-masked]>>, Jim Guichard <[email-masked]<mailto:[email-masked]>>, Med Boucadair <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Martin Stiemerling <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

Carlos et al,

There’s plenty of precedent for optional requirements - for example, one that comes immediately to mind is RFC 5654, which contains “MAY”s in addition to “MUST”s.

Cheers,
Andy

On Wed, May 18, 2016 at 11:39 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
To be frank, “optional requirement” sounds like an oxymoron to me.

Thanks,

— Carlos.

On May 18, 2016, at 10:36 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

On 5/18/16 10:31 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi Joel,

Cheers,
Med

-----Message d'origine-----
De : Joel M. Halpern [mailto:[email-masked]]
Envoyé : mercredi 18 mai 2016 16:18
À : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); Martin
Stiemerling; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

Yours,
Joel

On 5/18/16 2:10 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi Jim,

You said:

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mardi 17 mai 2016 19:31
À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

Hi Med,

Jim

Hi Jim,

Cheers,
Med

-----Message d'origine-----

Jim

Dear all,

Thanks,

  Martin

Abstract:

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<http://tools.ietf.org>.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 18 May 2016 17:06:32 +0000

> If Jim and Carlos can live with it, I will let it go.  I have trouble with the notion of "optional requirements".

So do I.  "optional requirements" runs contrary to the goal of the document and, in essence, runs the risk of creating a non-exhautive list of options, not requirements.

The draft should be narrow, anchored by the Arch RFC and focus on the requirements for an NSH-service chain.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 18 May 2016 17:55:01 +0000

Hi Andy,

Its the last part of the sentence I do not like as the SFC encapsulation does not call for steering policies specific to an ingress port. I am okay with saying “As a local decision, there may be multiple different steering policies that work in conjunction with the SFC encapsulation as specified in [draft-ietf-sfc-nsh reference] for one flow within one SFF”.

Frankly though I would rather see the entire section removed from the document as I don’t see it adds value but rather confusion (but that’s a decision for the WG – its just my personal opinion).

Jim

From: "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 18, 2016 at 9:36 AM
To: BOUCADAIR Mohamed IMT/OLN <[email-masked]<mailto:[email-masked]>>
Cc: Jim Guichard <[email-masked]<mailto:[email-masked]>>, Martin Stiemerling <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt

Thanks,
Andy

On Wed, May 18, 2016 at 9:01 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Works for me.

Thank you.

Cheers,
Med

De : Jim Guichard (jguichar) [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mercredi 18 mai 2016 13:42

Hi Med,

Old:

New:

Jim

Hi Jim,

You said:

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mardi 17 mai 2016 19:31
À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-control-plane-05.txt
Hi Med,
<[email-masked]<mailto:[email-masked]>> wrote:
>> >> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>> >>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 19 May 2016 07:16:15 -0400

Jim,

That sentence is fine, as is adding a reference to the encapsulation.

Cheers,
Andy

On Wed, May 18, 2016 at 1:55 PM, Jim Guichard (jguichar) <[email-masked]

> Hi Andy,
>
> Its the last part of the sentence I do not like as the SFC encapsulation
> does not call for steering policies specific to an ingress port. I am okay
> with saying “As a local decision, there may be multiple different steering
> policies *that work in conjunction with the SFC encapsulation as
> specified in [draft-ietf-sfc-nsh reference] *for one flow within one SFF”.
>
> Frankly though I would rather see the entire section removed from the
> document as I don’t see it adds value but rather confusion (but that’s a
> decision for the WG – its just my personal opinion).
>
> Jim
>
> From: "Andrew G. Malis" <[email-masked]>
> To: BOUCADAIR Mohamed IMT/OLN <[email-masked]>
> Cc: Jim Guichard <[email-masked]>, Martin Stiemerling <
> [email-masked]>, "[email-masked]" <[email-masked]>
>> For example, it could be the SFP-id carried *within the SFC
>> encapsulation* with any fields in the data packets, such as
>> (non-exhaustive list):
>>
>>
>>
>> Jim
>>
>>
>>