Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt

From: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 14:52:44 +0000

Heya, Med.

I gave it a quick read.  I have the following questions/observations:

REQ#2 - The document doesn't specifically say whether we're constraining
our focus on chains that require an "externality" for each link (that is,
ARE we assuming that each "link" will pass through a network/networked
element e.g. Hypervisor switch) - and are thus excluding from discussion
IPC (or RPC) mechanisms between service elements on the same device (which
are much harder to detect, monitor, standardize).

REQ#13 is putting a constraint on the header discussion.  Is this the
right place to put that, particularly since the requirements there haven't
been fully defined (yet)?

REQ#15 - while I fully appreciate your desire to avoid another 80+ part
email thread on whether MPLS is an overlay, I think you make your point
well enough in the main assertion and part "b" is actually redundant.  8^)

REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 has
to be a MUST (I think the need for downstream reclassification can be a
normal outcome of the function of an individual service element as it
potentially transforms a header - unless your argument is that we should
avoid this wherever possible by imbedding a clue in the header - in which
case we run into issues with "non-speakers" or legacy devices).

REQ#23 seems to obviate the use of simple route NH manipulation to create
a chain (this is destination address based).  So, to be inclusive, I think
that has to be a SHOULD.

REQ#25 seems to be difficult to require if you don't dictate how the chain
is formed (how the forwarding is instantiated) and should be worded more
like REQ#29, IMO.

REQ#30 I think you're trying to say that static definition/topology of
service functions SHOULD be supported but dynamic MUST (not that every
element has to support dynamic discovery but that the overall goal of the
ongoing architecture should be dynamic with static augmentation for
corner/legacy cases) ...which would be more in alignment with the tenor of
REQ#32.

Thanks for kicking it off and reading this drivel ...

On 8/27/13 2:58 AM, "[email-masked]"
<[email-masked]> wrote:

>Dear all,
>
>A new version of the requirements draft is now available online. The main
>changes in this new version are as follows:
>
>* Enrich the document with inputs from
>draft-li-service-chaining-requirements
>* Welcome authors of draft-li-service-chaining-requirements as co-authors
>* Add new security-related requirements.
>* Re-order the requirements
>
>A more detailed diff is available at:
>http://tools.ietf.org/rfcdiff?url2=draft-boucadair-chaining-requirements-0
>1.txt 
>
>Feel free to share your comments, suggestions and text contributions on
>the list or direct them to the authors.
>
>Cheers,
>Med
>
>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]]
>De la part de [email-masked]
>Envoyé : jeudi 22 août 2013 14:21
>À : [email-masked]
>Objet : I-D Action: draft-boucadair-chaining-requirements-01.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title           : Requirements for Service Function Chaining
>	Author(s)       : Mohamed Boucadair
>                          Christian Jacquenet
>                          Yuanlong Jiang
>                          Hongyu Li
>                          Ron Parker
>	Filename        : draft-boucadair-chaining-requirements-01.txt
>	Pages           : 10
>	Date            : 2013-08-22
>
>Abstract:
>   This document identifies the requirements for the Service Function
>   Chaining.
>
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirements
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-boucadair-chaining-requirements-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-boucadair-chaining-requirements-01
>
>
>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/
>
>_______________________________________________
>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
>_______________________________________________
>nsc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nsc
>
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 15:47:22 +0000

Hi, Ken.

Responding to your comment on REQ #2, from my perspective...

A particular network element (physical or virtual) can definitely support multiple service functions simultaneously.   Any particular chain may invoke any of them in any order.     However, I feel that it is an implementation specific design issue whether hops between these co-resident services literally follow the exact service chaining procedures that we ultimately define or simply behave as if they were exactly followed (i.e., external-service A to internal-service B to internal-service C to external-service D -- only the external A to internal B and the internal C to external D are externally observable).

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Gray
Sent: Wednesday, September 04, 2013 10:53 AM
To: [email-masked]; [email-masked]
Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt

Heya, Med.

REQ#2 - The document doesn't specifically say whether we're constraining our focus on chains that require an "externality" for each link (that is, ARE we assuming that each "link" will pass through a network/networked element e.g. Hypervisor switch) - and are thus excluding from discussion IPC (or RPC) mechanisms between service elements on the same device (which are much harder to detect, monitor, standardize).

REQ#13 is putting a constraint on the header discussion.  Is this the right place to put that, particularly since the requirements there haven't been fully defined (yet)?

REQ#15 - while I fully appreciate your desire to avoid another 80+ part email thread on whether MPLS is an overlay, I think you make your point well enough in the main assertion and part "b" is actually redundant.  8^)

REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 has to be a MUST (I think the need for downstream reclassification can be a normal outcome of the function of an individual service element as it potentially transforms a header - unless your argument is that we should avoid this wherever possible by imbedding a clue in the header - in which case we run into issues with "non-speakers" or legacy devices).

REQ#23 seems to obviate the use of simple route NH manipulation to create a chain (this is destination address based).  So, to be inclusive, I think that has to be a SHOULD.

REQ#25 seems to be difficult to require if you don't dictate how the chain is formed (how the forwarding is instantiated) and should be worded more like REQ#29, IMO.

REQ#30 I think you're trying to say that static definition/topology of service functions SHOULD be supported but dynamic MUST (not that every element has to support dynamic discovery but that the overall goal of the ongoing architecture should be dynamic with static augmentation for corner/legacy cases) ...which would be more in alignment with the tenor of REQ#32.

On 8/27/13 2:58 AM, "[email-masked]"
<[email-masked]> wrote:

>Dear all,
>
>A new version of the requirements draft is now available online. The 
>main changes in this new version are as follows:
>
>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: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 16:15:01 +0000

We're bouncing around my point, though you actually bring up an ancillary
thing of interest. 

Assuming that an element performs multiple functions (either as multiple
virtual machines or as part of it's physical/logical architecture as a
non-virtual device), then there is an interesting question about how we
represent this in service discovery - particularly if we cannot manipulate
the order or isolate an order (that's the part I think is new and
interesting in your response).

I think we're agreeing that the work of the NSC workgroup will ignore the
mechanics of such chaining as implementation details and thus not describe
how they are chained - keeping us out of the IPC/RPC bailywick and
focusing only on the description of/standardization of externally chained
services (though, as I mentioned above, representation of that combined
service IS relevant to NSC work).

Yes?  If so, we should make this clear in #2?

On 9/4/13 11:47 AM, "Ron Parker" <[email-masked]> wrote:

>A particular network element (physical or virtual) can definitely support
>multiple service functions simultaneously.   Any particular chain may
>invoke any of them in any order.     However, I feel that it is an
>implementation specific design issue whether hops between these
>co-resident services literally follow the exact service chaining
>procedures that we ultimately define or simply behave as if they were
>exactly followed (i.e., external-service A to internal-service B to
>internal-service C to external-service D -- only the external A to
>internal B and the internal C to external D are externally observable).
>
>   Ron
>
>
>Subject: Re: [nsc] TR: I-D Action:
>draft-boucadair-chaining-requirements-01.txt
>
>Heya, Med.
>
>IPC (or RPC) mechanisms between service elements on the same device
>(which are much harder to detect, monitor, standardize).
>
>right place to put that, particularly since the requirements there
>haven't been fully defined (yet)?
>
>a chain (this is destination address based).  So, to be inclusive, I
>think that has to be a SHOULD.
>
>REQ#25 seems to be difficult to require if you don't dictate how the
>chain is formed (how the forwarding is instantiated) and should be worded
>more like REQ#29, IMO.
>
>corner/legacy cases) ...which would be more in alignment with the tenor
>of REQ#32.
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 17:31:25 +0000

Hi, Ken.

In some of the I'D's we do touch on the logical network function concept, but we may need to consolidate and strengthen the requirements around that.     Not only can multiple disparate network functions co-reside at the same managed network element, but even multiple instances of the same type of network function where these instance imply differentiated behaviors.   For example, the same managed network element may support 'firewall-strict', 'firewall-loose', 'content-filter-adult', 'content-filter-child', 'dpi-analytics'.    A useful service chain may, for example, select 'firewall-strict' and 'content-filter-child' plus other service functions that happen to reside in other managed network elements.

In draft-boucadair-service-chaining-framework, section 9.3, On Service Function Profiles (a.k.a., Contexts), we point out that logical service functions can imply differentiated behavior (policy).

In the same I-D, section 5.5, SF Node, we have the text:
            In case several SFs
            are co-located in the same node, the packet is processed by
            all SFs indicated in the SF Map. Once the packet is
            successfully handled by local SF(s), the packet is forwarded
            to the next SF Node in the list or to an intermediate node
            (if the local SFC Node is the last element in the SF Map).

Thanks.

    Ron

-----Original Message-----
From: Ken Gray [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 12:15 PM
To: Ron Parker; [email-masked]; [email-masked]
Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt

We're bouncing around my point, though you actually bring up an ancillary thing of interest. 

Assuming that an element performs multiple functions (either as multiple virtual machines or as part of it's physical/logical architecture as a non-virtual device), then there is an interesting question about how we represent this in service discovery - particularly if we cannot manipulate the order or isolate an order (that's the part I think is new and interesting in your response).

I think we're agreeing that the work of the NSC workgroup will ignore the mechanics of such chaining as implementation details and thus not describe how they are chained - keeping us out of the IPC/RPC bailywick and focusing only on the description of/standardization of externally chained services (though, as I mentioned above, representation of that combined service IS relevant to NSC work).

On 9/4/13 11:47 AM, "Ron Parker" <[email-masked]> wrote:

>REQ#2 - The document doesn't specifically say whether we're 
>constraining our focus on chains that require an "externality" for each 
>link (that is, ARE we assuming that each "link" will pass through a 
>network/networked element e.g. Hypervisor switch) - and are thus 
>excluding from discussion IPC (or RPC) mechanisms between service 
>elements on the same device (which are much harder to detect, monitor, standardize).
>
>REQ #19 part "a" seems to clash a bit with REQ#22 and I think REQ#22 
>has to be a MUST (I think the need for downstream reclassification can 
>be a normal outcome of the function of an individual service element as 
>it potentially transforms a header - unless your argument is that we 
>should avoid this wherever possible by imbedding a clue in the header - 
>in which case we run into issues with "non-speakers" or legacy devices).
>
>REQ#23 seems to obviate the use of simple route NH manipulation to 
>create a chain (this is destination address based).  So, to be 
>inclusive, I think that has to be a SHOULD.
>
>chain is formed (how the forwarding is instantiated) and should be 
>worded more like REQ#29, IMO.
>
>element has to support dynamic discovery but that the overall goal of 
>the ongoing architecture should be dynamic with static augmentation for 
>>http://tools.ietf.org/rfcdiff?url2=draft-boucadair-chaining-requiremen
>>t
>>s-0
>>1.txt
>>
>>Feel free to share your comments, suggestions and text contributions 
>>on the list or direct them to the authors.
>>
>>Cheers,
>>Med
>>
>>De la part de [email-masked] Envoyé : jeudi 22 août 2013 
>>14:21 À : [email-masked] Objet : I-D Action: 
>>http://www.ietf.org/rfcdiff?url2=draft-boucadair-chaining-requirements
>>-
>>01
>>
>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 17:53:20 +0000

I would add that if the SF Map Index (aka service path id) also carries an
index into the service chain (aka SF Map) then regardless of whether the
receiving node is virtual or not it can still determine the placement
within the service chain and the necessary service function to apply.
Likewise the context, if carried, can indicate which particular profile of
a given service function to apply.

On 9/4/13 1:31 PM, "Ron Parker" <[email-masked]> wrote:

>Hi, Ken.
>
>In some of the I'D's we do touch on the logical network function concept,
>but we may need to consolidate and strengthen the requirements around
>that.     Not only can multiple disparate network functions co-reside at
>the same managed network element, but even multiple instances of the same
>type of network function where these instance imply differentiated
>behaviors.   For example, the same managed network element may support
>'firewall-strict', 'firewall-loose', 'content-filter-adult',
>'content-filter-child', 'dpi-analytics'.    A useful service chain may,
>for example, select 'firewall-strict' and 'content-filter-child' plus
>other service functions that happen to reside in other managed network
>elements.
>
>In draft-boucadair-service-chaining-framework, section 9.3, On Service
>Function Profiles (a.k.a., Contexts), we point out that logical service
>functions can imply differentiated behavior (policy).
>
>represent this in service discovery - particularly if we cannot
>manipulate the order or isolate an order (that's the part I think is new
>and interesting in your response).
>
>mechanics of such chaining as implementation details and thus not
>describe how they are chained - keeping us out of the IPC/RPC bailywick
>and focusing only on the description of/standardization of externally
>chained services (though, as I mentioned above, representation of that
>combined service IS relevant to NSC work).
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 18:04:39 +0000

Hi, Jim.

I agree that an index is required to support multiple service functions co-residing within the same network element.   I'll point out that when a chain selects multiple co-resident network functions, there is no requirement that they be contiguous.   For example, a chain with A, B, C where A and C happen to be co-resident.

However, this concept of co-residence is orthogonal to virtualization.    The important part, IMO, is that a single managed network element may support any number of co-resident service functions.   That network element could be a single VM, a cluster of VMs, a single physical server, a cluster of physical servers, a cluster of blade-based physical servers, etc.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 1:53 PM
To: Ron Parker; Ken Gray; [email-masked]; [email-masked]
Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt

I would add that if the SF Map Index (aka service path id) also carries an index into the service chain (aka SF Map) then regardless of whether the receiving node is virtual or not it can still determine the placement within the service chain and the necessary service function to apply.
Likewise the context, if carried, can indicate which particular profile of a given service function to apply.

On 9/4/13 1:31 PM, "Ron Parker" <[email-masked]> wrote:

>Hi, Ken.
>
>In some of the I'D's we do touch on the logical network function 
>concept, but we may need to consolidate and strengthen the requirements around
>the same managed network element, but even multiple instances of the 
>same type of network function where these instance imply differentiated
>Assuming that an element performs multiple functions (either as 
>multiple virtual machines or as part of it's physical/logical 
>architecture as a non-virtual device), then there is an interesting 
>question about how we represent this in service discovery - 
>particularly if we cannot manipulate the order or isolate an order 
>(that's the part I think is new and interesting in your response).
>
>I think we're agreeing that the work of the NSC workgroup will ignore 
>the mechanics of such chaining as implementation details and thus not 
>>constraining our focus on chains that require an "externality" for 
>>each link (that is, ARE we assuming that each "link" will pass through 
>>a network/networked element e.g. Hypervisor switch) - and are thus 
>>REQ#15 - while I fully appreciate your desire to avoid another 80+ 
>>part email thread on whether MPLS is an overlay, I think you make your 
>>point well enough in the main assertion and part "b" is actually redundant.
>>8^)
>>
>>be a normal outcome of the function of an individual service element 
>>as it potentially transforms a header - unless your argument is that 
>>we should avoid this wherever possible by imbedding a clue in the 
>>header - in which case we run into issues with "non-speakers" or legacy devices).
>>
>>the ongoing architecture should be dynamic with static augmentation 
>>for corner/legacy cases) ...which would be more in alignment with the 
>>tenor of REQ#32.
>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 18:06:13 +0000

Completely agree.

Sent from my iPhone

---

From: Ken Gray <[email-masked]>
Date: Wed, 4 Sep 2013 18:10:06 +0000

Yup.  I agree as well.  Looping back to #2, are/do we need to explicitly
rule out IPC/RPC from the requirements/focus or am I being an @ss for
wanting to be so explicit?

On 9/4/13 2:06 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>> I agree that an index is required to support multiple service functions
>>co-residing within the same network element.   I'll point out that when
>>a chain selects multiple co-resident network functions, there is no
>>requirement that they be contiguous.   For example, a chain with A, B, C
>>where A and C happen to be co-resident.
>> 
>> However, this concept of co-residence is orthogonal to virtualization.
>>  The important part, IMO, is that a single managed network element may
>>support any number of co-resident service functions.   That network
>>element could be a single VM, a cluster of VMs, a single physical
>>server, a cluster of physical servers, a cluster of blade-based physical
>>servers, etc.
>> 
>>   Ron
>> 
>> 
>> I would add that if the SF Map Index (aka service path id) also carries
>>an index into the service chain (aka SF Map) then regardless of whether
>>the receiving node is virtual or not it can still determine the
>>placement within the service chain and the necessary service function to
>>apply.
>>>> elements on the same device (which are much harder to detect,
>>>>monitor, 
>>>> standardize).
>>>>

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Sep 2013 18:12:35 +0000

I feel that we could explicitly rule out specification of the details of intra-network-element IPC/RPC as an implementation detail.

   Ron

-----Original Message-----
From: Ken Gray [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2013 2:10 PM
To: Jim Guichard (jguichar); Ron Parker
Cc: [email-masked]; [email-masked]
Subject: Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-01.txt

Yup.  I agree as well.  Looping back to #2, are/do we need to explicitly rule out IPC/RPC from the requirements/focus or am I being an @ss for wanting to be so explicit?

On 9/4/13 2:06 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>>server, a cluster of physical servers, a cluster of blade-based 
>>physical servers, etc.
>> 
>>   Ron
>> 
>> 
>> I would add that if the SF Map Index (aka service path id) also 
>>carries an index into the service chain (aka SF Map) then regardless 
>>of whether the receiving node is virtual or not it can still determine 
>>the placement within the service chain and the necessary service 
>>function to apply.
>> Likewise the context, if carried, can indicate which particular 
>>profile of a given service function to apply.
>> 
>>> for example, select 'firewall-strict' and 'content-filter-child' 
>>>plus  other service functions that happen to reside in other managed 
>>>network  elements.
>>> 
>>> In draft-boucadair-service-chaining-framework, section 9.3, On 
>>>Service  Function Profiles (a.k.a., Contexts), we point out that 
>>>logical service  functions can imply differentiated behavior 
>>>(policy).
>>> 
>>> I think we're agreeing that the work of the NSC workgroup will 
>>>ignore  the mechanics of such chaining as implementation details and 
>>>thus not  describe how they are chained - keeping us out of the 
>>>IPC/RPC bailywick  and focusing only on the description 
>>>of/standardization of externally  chained services (though, as I 
>>>mentioned above, representation of that  combined service IS relevant 
>>>to NSC work).
>>> 
>>>>procedures that we ultimately define or simply behave as if they 
>>>>were  exactly followed (i.e., external-service A to internal-service 
>>>>B to  internal-service C to external-service D -- only the external 
>>>>A to  internal B and the internal C to external D are externally 
>>>>observable).
>>>> 
>>>>  Ron
>>>> 
>>>> 
>>>>each link (that is, ARE we assuming that each "link" will pass 
>>>>through  a network/networked element e.g. Hypervisor switch) - and 
>>>>are thus  excluding from discussion IPC (or RPC) mechanisms between 
>>>>service  elements on the same device (which are much harder to 
>>>>detect, monitor,  standardize).
>>>> 
>>>> REQ#13 is putting a constraint on the header discussion.  Is this 
>>>> the right place to put that, particularly since the requirements 
>>>> there haven't been fully defined (yet)?
>>>> 
>>>>part email thread on whether MPLS is an overlay, I think you make 
>>>>your  point well enough in the main assertion and part "b" is 
>>>>actually redundant.
>>>> 8^)
>>>> 
>>>> REQ #19 part "a" seems to clash a bit with REQ#22 and I think 
>>>>REQ#22  has to be a MUST (I think the need for downstream 
>>>>reclassification can  be a normal outcome of the function of an 
>>>>individual service element  as it potentially transforms a header - 
>>>>unless your argument is that  we should avoid this wherever possible 
>>>>by imbedding a clue in the  header - in which case we run into 
>>>>issues with "non-speakers" or legacy devices).
>>>> 
>>>> REQ#25 seems to be difficult to require if you don't dictate how 
>>>> the chain is formed (how the forwarding is instantiated) and should 
>>>> be worded more like REQ#29, IMO.
>>>> 
>>>> REQ#30 I think you're trying to say that static definition/topology 
>>>>of  service functions SHOULD be supported but dynamic MUST (not that 
>>>>every  element has to support dynamic discovery but that the overall 
>>>>goal of  the ongoing architecture should be dynamic with static 
>>>>augmentation  for corner/legacy cases) ...which would be more in 
>>>>alignment with the  tenor of REQ#32.
>>>> 
>>>>> A new version of the requirements draft is now available online. 
>>>>> The main changes in this new version are as follows:
>>>>> 
>>>>> http://tools.ietf.org/rfcdiff?url2=draft-boucadair-chaining-requir
>>>>> eme
>>>>> n
>>>>> t
>>>>> s-0
>>>>> 1.txt
>>>>> 
>>>>> Feel free to share your comments, suggestions and text 
>>>>> contributions on the list or direct them to the authors.
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>>> 
>>>>>  This document identifies the requirements for the Service 
>>>>> Function  Chaining.
>>>>> 
>>>>> 
>>>>> 
>>>>> https://datatracker.ietf.org/doc/draft-boucadair-chaining-requirem
>>>>> ent
>>>>> s
>>>>> 
>>>>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-chaining-requirem
>>>>> ent
>>>>> s
>>>>> -
>>>>> 01
>>>>> 
>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 4 Sep 2013 18:14:55 +0000

I also see that as an implementation detail. 

Sent from my iPhone

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 09:45:44 +0200

Hi Ken,

Thank you for the comments. Please see inline.

Cheers,
Med

>De : Ken Gray [mailto:[email-masked]]
>Envoyé : mercredi 4 septembre 2013 16:53
>À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
>Objet : Re: [nsc] TR: I-D Action: draft-boucadair-chaining-requirements-
>01.txt
>
>Heya, Med.
>

[Med] IMHO how service functions are interconnected should be excluded from the scope. This included both the case where multiple functions are co-located within the same device or are located in separate ones. I added this sentence:
"Note: Communications between Service Functions co-resident on same Network Element are considered implementation-specific. These considerations are out of scope of the SFC specification effort."

>been fully defined (yet)?

[Med] This is mainly motivated by operational needs; the constraint on the header is just a side effect. From an operational standpoint, this is an important requirement to keep in mind. A typical complications that may arise is when legacy nodes (no aware of the SFC procedure) discard fragmented packets.

>well enough in the main assertion and part "b" is actually redundant.  8^)

[Med] I see your point. We initially listed those sub-bullets to provide additional information and make sure the main requirements is clear enough. Will consider how to make this better. Thanks.

>case we run into issues with "non-speakers" or legacy devices).

[Med] In the new version to be published, we removed REQ#19 (a) and maintained the normative language in REQ#22 as it is. A simple model consists to have one single SFC classification of the packet, and then the packet will be forwarding on a per SF Map Index. In such model, no SFC re-classification would be required. Unlike this simple model, there are voices arguing a SFC re-classification may be needed. We will have the opportunity to tweak the normative language. 

>a chain (this is destination address based).  So, to be inclusive, I think

[Med] The destination address this REQ is referring to is the destination address of the original packet. We made this change to make:

   REQ#23:  The solution MUST be able to forward the traffic between two
            Service Functions (involved in the same Service Function
            Chain) without relying on the original destination address
            in a data packet.

Better? Or you still think this should be modified? Thanks. 

>is formed (how the forwarding is instantiated) and should be worded more

[Med] We changed the wording for this REQ to make it more specific. The new wording to appear in the new version is as follow:

   REQ#25:  The solution MUST allow for Operations, Administration, and
            Maintenance (OAM) features [RFC6291].  In particular,

            a.  Support means to verify the completion of the forwarding
                actions derived from the contents of the SF Map until
                the Border Node is reached (see Section 3.4.1 of
                [RFC5706]).

            b.  Support means to ensure coherent classification rules
                are installed to all SFC Classifiers.

            c.  Support means to correlate between the classification
                policies and observed forwarding actions.

            d.  Support in-band liveness and functionality checking of
                instantiated Service Function Chains.

Better?

>corner/legacy cases) ...which would be more in alignment with the tenor of

[Med] We used SHOULD in this REQ mainly because the solution can be enabled in some contexts without requiring dynamic discovery means. Promoting this REQ to "MUST" would assume this functionality is mandatory to deploy the chaining solution...which is not true.

---

From: Ken Gray <[email-masked]>
Date: Thu, 5 Sep 2013 13:11:55 +0000

A couple in-lines back.  Thanks for the response ...

On 9/5/13 3:45 AM, "[email-masked]"
<[email-masked]> wrote:

>>(which
>[Med] IMHO how service functions are interconnected should be excluded
>from the scope. This included both the case where multiple functions are
>co-located within the same device or are located in separate ones. I
>added this sentence:
>"Note: Communications between Service Functions co-resident on same
>Network Element are considered implementation-specific. These
>considerations are out of scope of the SFC specification effort."

We'll probably have to agree to disagree, though it's just a nit.  Seems
to me that most of what will be specify/standardized this is unique  ARE
externalities (packet headers and discovery/registration ...metadata not
so much).  =8^)

>[Med] This is mainly motivated by operational needs; the constraint on
>the header is just a side effect. From an operational standpoint, this is
>an important requirement to keep in mind. A typical complications that
>may arise is when legacy nodes (no aware of the SFC procedure) discard
>fragmented packets.
>
>>
>[Med] I see your point. We initially listed those sub-bullets to provide
>additional information and make sure the main requirements is clear
>enough. Will consider how to make this better. Thanks.
>
>>
>[Med] In the new version to be published, we removed REQ#19 (a) and
>maintained the normative language in REQ#22 as it is. A simple model
>consists to have one single SFC classification of the packet, and then
>the packet will be forwarding on a per SF Map Index. In such model, no
>SFC re-classification would be required. Unlike this simple model, there
>are voices arguing a SFC re-classification may be needed. We will have
>the opportunity to tweak the normative language.

Okay, we can leave it for later.

>[Med] The destination address this REQ is referring to is the destination
>address of the original packet. We made this change to make:
>

Better.

>>chain
>[Med] We changed the wording for this REQ to make it more specific. The
>new wording to appear in the new version is as follow:
>

Yes.

>>of
>[Med] We used SHOULD in this REQ mainly because the solution can be
>enabled in some contexts without requiring dynamic discovery means.
>Promoting this REQ to "MUST" would assume this functionality is mandatory
>to deploy the chaining solution...which is not true.

I think we're saying the same thing, just getting hung on the nomenclature
specific to a goal vs an implementation.  To me, the goal must be to
develop a dynamic mechanism (otherwise, what's the point) while allowing
static/manual.  When you flip it to implementation, then I'd agree with
your point of view.

>>>main