Subject: [nsc] Comments on draft-quinn-nsh-00

From: Ron Parker <[email-masked]>
Date: Mon, 24 Jun 2013 15:19:10 +0000

I am new to this group and want to thank the authors and participants for the good work you've done so far.   I feel that this work is very complementary to the Network Function Virtualization Forum's nascent network function chaining work.   Draft-quinn-nsh-00 and draft-quinn-nsc-problem-statement-00 are, however, appropriately more general in that mobile data services are not assumed to be the de facto business problem and co-location of network functions are not assumed to be within the data center.
My specific questions and comments on draft-quinn-nsh-00 follow...
General - I agree with some previous comments on the thread that "service" is an overloaded term.   I prefer the NFV's terms "network function" and "network function chaining".   Let the business folks determine what set of functions constitute a "service" that consumers or businesses will pay for.
2.2 Problem Statement; 1. Topological Dependencies - This would be a good place to clarify whether service chains are unidirectional or bidirectional.   If bidirectional, is symmetry assumed (i.e. if from client to server network functions A, B, C are invoked, then from server to client, is it always C, B, A?  Must a classifier be at both ends of the chain?   Must it be the same classifier at each end?
2.2 Problem Statement - It may be useful to discuss how standard IP routing and NSC co-exist.   For example, a deployment based on this technique may utilize IP routing to ensure packets arrive at the two ends of a service chain, but the service overlay is used to steer traffic between the two ends of the chain.
3.1 NSH Actions; 1. Insert / Remove Service Header - this section introduces the concept of control plane to indicate which node is "end of the chain".   This could also be accomplished via the management plane.   Perhaps a discussion of control plane and management plane could be added to section 2.2?   From the balance of the draft, it seems that control plane is deferred for a future proposal?
3.1 NSH Actions; 3. Update a Service Header - this section introduces the concept of a service index.   From context, I assume that this indicates the previous node was considered to be index N out of M total nodes?   Is it 0-based or 1-based?
3.3 NSH Usage; 2. Service Chaining - this section introduces OAM messages, but none are defined elsewhere in this document.   Does this lend itself to a separate draft?   If so, should this document acknowledge that it won't attempt to define OAM procedures?    Perhaps it could acknowledge the possibility that the fields following the Base Header would be different for OAM messages?
3.3 NSH Usage; 3. Metadata Sharing -It is mentioned that semantics of the metadata require coordination via a control plane, but this seems somewhat contrary to the previous statement that a fixed size and format header is used for simplicity.
3.4 NSH Proxy Nodes - it is mentioned that the proxy may deliver the packet to the service node via a local attachment circuit.  I suggest that it should be specified that the service node is required to deliver the packet back to the proxy (i.e., "bump-in-the-wire" forwarding paradigm) via the same or different access circuit.   Also, this mechanism could also be extended to non-NSH tunnels (i..e, IP-in-IP or GRE).
4. Header Format; C bit - the text states that when C bit is set, there are one or more contexts present.   But then states that the format is fixed to 4 32-bit contexts.
4. Header Format - the distinction of network/service and platform/shared is not clear to me.   Perhaps some usage examples could be added to help clarify?
4.  Header Format - for deployment topologies that  encompass access networks (e.g., most), it is very common to wish to convey a subscriber identity (e.g., IMSI or MSISDN in a mobile network) distinct from the IP address used in the packet.   This may facilitate application of local policy.   It can also facilitate application of local policy in network functions chained after a NAT function.   Perhaps an optional 128-bit generic subscriber identity can be considered in the NSH?    On the other hand, I can see where keeping the NSH size minimal is extremely beneficial.   One thought here would be a mechanism that could be employed by stateful network functions using flag bits to acknowledge that certain metadata has been received and is no longer necessary in subsequent packets of the fully qualified flow.   With this approach, the 128-bit generic subscriber identity could be conveyed in the first N packets to the next node until a packet is received back from the next node with the corresponding acknowledgement bit set.   This approach could be extended to other fields, including the 4 context fields already defined.

---

From: Paul Quinn <[email-masked]>
Date: Wed, 26 Jun 2013 08:32:46 -0700

Hi Ron,

Thanks for the thoughtful comments!  My apologies for not getting back to you sooner, I've been traveling.

See my comments inline.

Paul

On Jun 24, 2013, at 8:19 AM, Ron Parker <[email-masked]> wrote:

> I am new to this group and want to thank the authors and participants for the good work you’ve done so far.   I feel that this work is very complementary to the Network Function Virtualization Forum’s nascent network function chaining work.   Draft-quinn-nsh-00 and draft-quinn-nsc-problem-statement-00 are, however, appropriately more general in that mobile data services are not assumed to be the de facto business problem and co-location of network functions are not assumed to be within the data center.
> 

PQ>  Yes. We make no assumption on applicability to particular market segments or location of service functions – all are within scope of this work. 

> My specific questions and comments on draft-quinn-nsh-00 follow…
> 
> General – I agree with some previous comments on the thread that “service” is an overloaded term.   I prefer the NFV’s terms “network function” and “network function chaining”.   Let the business folks determine what set of functions constitute a “service” that consumers or businesses will pay for.

PQ>  We tried use the term service function to describe the specific "services": e.g. firewall.  As Jim Guichard mentioned on the alias: services are what a customer buys and those services could be constructed using one or more "service functions". I don't want to use the term network function as that implies that the network somehow does something here which is not the case as the function applied is not necessarily at the network layer. 

> 
> 2.2 Problem Statement; 1. Topological Dependencies – This would be a good place to clarify whether service chains are unidirectional or bidirectional.   If bidirectional, is symmetry assumed (i.e. if from client to server network functions A, B, C are invoked, then from server to client, is it always C, B, A?  Must a classifier be at both ends of the chain?   Must it be the same classifier at each end?
> 

PQ>  Point well taken, we have two choices: do you have suggested text you think captures this, or I'm happy to send out a revision that incorporates comments to date early next week.  One thing to note: service chains could be unidirectional, bidirectional or something in-between and that symmetry may or may not be required. As part of the work we will have to define the "types" of service chains and this is something that the WG would be assigned to do. 

> 2.2 Problem Statement – It may be useful to discuss how standard IP routing and NSC co-exist.   For example, a deployment based on this technique may utilize IP routing to ensure packets arrive at the two ends of a service chain, but the service overlay is used to steer traffic between the two ends of the chain.
> 

PQ>  Can you elaborate a bit more?  In general, routing carries the encapsulated packets from service to service.  The chaining function provides the service function destination for routing lookup.   IP routing is simply used for reachability of each service function within a service chain. 

> 3.1 NSH Actions; 1. Insert / Remove Service Header – this section introduces the concept of control plane to indicate which node is “end of the chain”.   This could also be accomplished via the management plane.   Perhaps a discussion of control plane and management plane could be added to section 2.2?   From the balance of the draft, it seems that control plane is deferred for a future proposal?
> 

PQ>  Precisely.  We expect there to be several possible control plane options depending on environment and use case and this is something the WG would be assigned to work through.

> 3.1 NSH Actions; 3. Update a Service Header – this section introduces the concept of a service index.   From context, I assume that this indicates the previous node was considered to be index N out of M total nodes?   Is it 0-based or 1-based?

PQ>  Correct, the index provides location with the path, and is decremented.  Service index=0 means the packet should be discarded.

> 
> 3.3 NSH Usage; 2. Service Chaining – this section introduces OAM messages, but none are defined elsewhere in this document.   Does this lend itself to a separate draft?   If so, should this document acknowledge that it won’t attempt to define OAM procedures?    Perhaps it could acknowledge the possibility that the fields following the Base Header would be different for OAM messages?
> 

PQ>  Yes, the plan is to have a future OAM focused document.  I'll update the draft to reflect that.

> 3.3 NSH Usage; 3. Metadata Sharing –It is mentioned that semantics of the metadata require coordination via a control plane, but this seems somewhat contrary to the previous statement that a fixed size and format header is used for simplicity.

PQ> The size is fixed, but the semantics of the data itself needs to be coordinated by the control plane.  For example, if the network shared context header is used to convey some form of classification, the value carried in the context but be meaningful to all participating nodes.  The control plane assigns that meaning. 

> 
> 3.4 NSH Proxy Nodes – it is mentioned that the proxy may deliver the packet to the service node via a local attachment circuit.  I suggest that it should be specified that the service node is required to deliver the packet back to the proxy (i.e., “bump-in-the-wire” forwarding paradigm) via the same or different access circuit.   Also, this mechanism could also be extended to non-NSH tunnels (i..e, IP-in-IP or GRE).
> 

PQ>  Good clarifications, and yes, the same of different circuits is viable, as are other encaps.  I'll update the doc.

> 4. Header Format; C bit – the text states that when C bit is set, there are one or more contexts present.   But then states that the format is fixed to 4 32-bit contexts.

PQ>  This is a parsing optimization: there are always 4 contexts but if non are used, then c=0 and they don't need to be checked.

> 
> 4. Header Format – the distinction of network/service and platform/shared is not clear to me.   Perhaps some usage examples could be added to help clarify?
> 

PQ>  Very valid comment, the next revision will include examples.

> 4.  Header Format – for deployment topologies that  encompass access networks (e.g., most), it is very common to wish to convey a subscriber identity (e.g., IMSI or MSISDN in a mobile network) distinct from the IP address used in the packet.   This may facilitate application of local policy.   It can also facilitate application of local policy in network functions chained after a NAT function.   Perhaps an optional 128-bit generic subscriber identity can be considered in the NSH?    On the other hand, I can see where keeping the NSH size minimal is extremely beneficial.   One thought here would be a mechanism that could be employed by stateful network functions using flag bits to acknowledge that certain metadata has been received and is no longer necessary in subsequent packets of the fully qualified flow.   With this approach, the 128-bit generic subscriber identity could be conveyed in the first N packets to the next node until a packet is received back from the next node with the corresponding acknowledgement bit set.   This approach could be extended to other fields, including the 4 context fields already defined.
> 
>  

PQ> The header is flexible enough to accommodate such a case but I need to understand the use case in more detail.  In theory, a control plane could indicate that the context headers are to be interpreted differently.  Again, I'd like to get a better sense of how you'd use this.

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

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Jun 2013 15:50:43 +0000

Hi, Paul.

Thanks for the response.   My follow up embedded.

BR,
Ron

-----Original Message-----
From: Paul Quinn [mailto:[email-masked]] 
Sent: Wednesday, June 26, 2013 11:33 AM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [nsc] Comments on draft-quinn-nsh-00

Hi Ron,

See my comments inline.

Paul

> I am new to this group and want to thank the authors and participants for the good work you've done so far.   I feel that this work is very complementary to the Network Function Virtualization Foru…

PQ>  Yes. We make no assumption on applicability to particular market segments or location of service functions - all are within scope of this work. 

Ron> Makes sense.

PQ>  Point well taken, we have two choices: do you have suggested text you think captures this, or I'm happy to send out a revision that incorporates comments to date early next week.  One thing to note: service chains could be unidirectional, bidirectional or something in-between and that symmetry may or may not be required. As part of the work we will have to define the "types" of service chains and this is something that the WG would be assigned to do. 
Ron> I don't have specific text at this point.   Agree that unidirectional, inversely-symmetrical bidirectional, and asymmetrical bidirectional are all valid.   Suggest that the flexible location of the classifier(s) be brought out, too.

PQ>  Can you elaborate a bit more?  In general, routing carries the encapsulated packets from service to service.  The chaining function provides the service function destination for routing lookup.   IP routing is simply used for reachability of each service function within a service chain. 
Ron> I feel that many people thinking about this topic have somehow arrived at a conclusion that OpenFlow is automatically and exclusively the basis for achieving things like NSC.

PQ>  Precisely.  We expect there to be several possible control plane options depending on environment and use case and this is something the WG would be assigned to work through.
Ron>  My suggestion is that the concept be explicitly supportable with a control plane and without (i.e., solely via coordinated management of the affected Network Elements).   This may allow for earlier adoptions and thereby market validation of the concepts.

PQ>  Correct, the index provides location with the path, and is decremented.  Service index=0 means the packet should be discarded.
Ron> I suggest that the text be enhanced to bring out the semantic meaning more explicitly.

PQ> The size is fixed, but the semantics of the data itself needs to be coordinated by the control plane.  For example, if the network shared context header is used to convey some form of classification, the value carried in the context but be meaningful to all participating nodes.  The control plane assigns that meaning. 
Ron> Suggest that the concept include the option whereby the management plane assigns that meaning, too.

PQ>  This is a parsing optimization: there are always 4 contexts but if non are used, then c=0 and they don't need to be checked.
Ron> This was more of an editorial comment.   "When the C bit is set, all four contexts are present" would more accurately reflect the intention, if I have interpreted correctly.

PQ> The header is flexible enough to accommodate such a case but I need to understand the use case in more detail.  In theory, a control plane could indicate that the context headers are to be interpreted differently.  Again, I'd like to get a better sense of how you'd use this.
Ron> Given this split notion of classification-capable nodes and non-classification-capable nodes, could the classification nodes add more value than simply choosing which SF's need to be invoked.   In particular, certain SF's would be capable of providing differentiated services for different groups of subscribers.   Can the classifier determine not only that some SF needs to be inserted but also which locally significant set of policy should be applied?   If so, how is this conveyed from the classifier to the SF?   Inband?   Out of band?

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 28 Jun 2013 18:58:22 +0000

Ron,

See my comments inline - SK>

Rgds,
Surendra.

On 6/26/13 5:50 PM, "Ron Parker" <[email-masked]> wrote:

>> I am new to this group and want to thank the authors and participants
>>for the good work you've done so far.   I feel that this work is very
>>complementary to the Network Function Virtualization Forum's nascent
>>network function chaining work.   Draft-quinn-nsh-00 and
>>draft-quinn-nsc-problem-statement-00 are, however, appropriately more
>>general in that mobile data services are not assumed to be the de facto
>>business problem and co-location of network functions are not assumed to
>>be within the data center.
>> 
>
>PQ>  Yes. We make no assumption on applicability to particular market
>segments or location of service functions - all are within scope of this
>work. 
>
>
>
>> General - I agree with some previous comments on the thread that
>>"service" is an overloaded term.   I prefer the NFV's terms "network
>>function" and "network function chaining".   Let the business folks
>>determine what set of functions constitute a "service" that consumers or
>>businesses will pay for.
>
>PQ>  We tried use the term service function to describe the specific
>"services": e.g. firewall.  As Jim Guichard mentioned on the alias:
>services are what a customer buys and those services could be constructed
>using one or more "service functions". I don't want to use the term
>network function as that implies that the network somehow does something
>here which is not the case as the function applied is not necessarily at
>the network layer.
>Ron> Makes sense.
>
>
>> 
>> 2.2 Problem Statement; 1. Topological Dependencies - This would be a
>>good place to clarify whether service chains are unidirectional or
>>bidirectional.   If bidirectional, is symmetry assumed (i.e. if from
>>client to server network functions A, B, C are invoked, then from server
>>to client, is it always C, B, A?  Must a classifier be at both ends of
>>the chain?   Must it be the same classifier at each end?
>> 
>
>PQ>  Point well taken, we have two choices: do you have suggested text
>you think captures this, or I'm happy to send out a revision that
>incorporates comments to date early next week.  One thing to note:
>service chains could be unidirectional, bidirectional or something
>in-between and that symmetry may or may not be required. As part of the
>work we will have to define the "types" of service chains and this is
>something that the WG would be assigned to do.
>Ron> I don't have specific text at this point.   Agree that
>unidirectional, inversely-symmetrical bidirectional, and asymmetrical
>bidirectional are all valid.   Suggest that the flexible location of the
>classifier(s) be brought out, too.
>
>
>
>
>> 2.2 Problem Statement - It may be useful to discuss how standard IP
>>routing and NSC co-exist.   For example, a deployment based on this
>>technique may utilize IP routing to ensure packets arrive at the two
>>ends of a service chain, but the service overlay is used to steer
>>traffic between the two ends of the chain.
>> 
>
>PQ>  Can you elaborate a bit more?  In general, routing carries the
>encapsulated packets from service to service.  The chaining function
>provides the service function destination for routing lookup.   IP
>routing is simply used for reachability of each service function within a
>service chain. 
>Ron> I feel that many people thinking about this topic have somehow
>arrived at a conclusion that OpenFlow is automatically and exclusively
>the basis for achieving things like NSC.
SK> That is a fallacy! What is needed is a mechanism to steer the traffic
(frames/packets) to one or more service nodes while being able to identify
the path used to steer the traffic. A simple overly network in the "data
plane" with a service header like NSH satisfies this.

>
>
>> 3.1 NSH Actions; 1. Insert / Remove Service Header - this section
>>introduces the concept of control plane to indicate which node is "end
>>of the chain".   This could also be accomplished via the management
>>plane.   Perhaps a discussion of control plane and management plane
>>could be added to section 2.2?   From the balance of the draft, it seems
>>that control plane is deferred for a future proposal?
>> 
>
>PQ>  Precisely.  We expect there to be several possible control plane
>options depending on environment and use case and this is something the
>WG would be assigned to work through.
>Ron>  My suggestion is that the concept be explicitly supportable with a
>control plane and without (i.e., solely via coordinated management of the
>affected Network Elements).   This may allow for earlier adoptions and
>thereby market validation of the concepts.
SK> By not requiring a specific model, NSH is generic to be implementable
in either model. As Paul said, further work in the WG can add to this.
>
>
>> 3.1 NSH Actions; 3. Update a Service Header - this section introduces
>>the concept of a service index.   From context, I assume that this
>>indicates the previous node was considered to be index N out of M total
>>nodes?   Is it 0-based or 1-based?
>
>PQ>  Correct, the index provides location with the path, and is
>decremented.  Service index=0 means the packet should be discarded.
>> 3.3 NSH Usage; 2. Service Chaining - this section introduces OAM
>>messages, but none are defined elsewhere in this document.   Does this
>>lend itself to a separate draft?   If so, should this document
>>acknowledge that it won't attempt to define OAM procedures?    Perhaps
>>it could acknowledge the possibility that the fields following the Base
>>Header would be different for OAM messages?
>> 
>
>> 3.3 NSH Usage; 3. Metadata Sharing -It is mentioned that semantics of
>>the metadata require coordination via a control plane, but this seems
>>somewhat contrary to the previous statement that a fixed size and format
>>header is used for simplicity.
>
>
>PQ> The size is fixed, but the semantics of the data itself needs to be
>coordinated by the control plane.  For example, if the network shared
>context header is used to convey some form of classification, the value
>carried in the context but be meaningful to all participating nodes.  The
>control plane assigns that meaning.
>> 3.4 NSH Proxy Nodes - it is mentioned that the proxy may deliver the
>>packet to the service node via a local attachment circuit.  I suggest
>>that it should be specified that the service node is required to deliver
>>the packet back to the proxy (i.e., "bump-in-the-wire" forwarding
>>paradigm) via the same or different access circuit.   Also, this
>>mechanism could also be extended to non-NSH tunnels (i..e, IP-in-IP or
>>GRE).
>> 
>
>PQ>  Good clarifications, and yes, the same of different circuits is
>viable, as are other encaps.  I'll update the doc.
>
>
>
>
>> 4. Header Format; C bit - the text states that when C bit is set, there
>>are one or more contexts present.   But then states that the format is
>>fixed to 4 32-bit contexts.
>
>PQ>  This is a parsing optimization: there are always 4 contexts but if
>non are used, then c=0 and they don't need to be checked.
>Ron> This was more of an editorial comment.   "When the C bit is set, all
>four contexts are present" would more accurately reflect the intention,
>if I have interpreted correctly.
>
>
>> 
>> 4. Header Format - the distinction of network/service and
>>platform/shared is not clear to me.   Perhaps some usage examples could
>>be added to help clarify?
>> 
>
>> 4.  Header Format - for deployment topologies that  encompass access
>>networks (e.g., most), it is very common to wish to convey a subscriber
>>identity (e.g., IMSI or MSISDN in a mobile network) distinct from the IP
>>address used in the packet.   This may facilitate application of local
>>policy.   It can also facilitate application of local policy in network
>>functions chained after a NAT function.   Perhaps an optional 128-bit
>>generic subscriber identity can be considered in the NSH?    On the
>>other hand, I can see where keeping the NSH size minimal is extremely
>>beneficial.   One thought here would be a mechanism that could be
>>employed by stateful network functions using flag bits to acknowledge
>>that certain metadata has been received and is no longer necessary in
>>subsequent packets of the fully qualified flow.   With this approach,
>>the 128-bit generic subscriber identity could be conveyed in the first N
>>packets to the next node until a packet is received back from the next
>>nod
> e with the corresponding acknowledgement bit set.   This approach could
>be extended to other fields, including the 4 context fields already
>defined.
>> 
>>  
>
>PQ> The header is flexible enough to accommodate such a case but I need
>to understand the use case in more detail.  In theory, a control plane
>could indicate that the context headers are to be interpreted
>differently.  Again, I'd like to get a better sense of how you'd use this.
>Ron> Given this split notion of classification-capable nodes and
>non-classification-capable nodes, could the classification nodes add more
>value than simply choosing which SF's need to be invoked.   In
>particular, certain SF's would be capable of providing differentiated
>services for different groups of subscribers.   Can the classifier
>determine not only that some SF needs to be inserted but also which
>locally significant set of policy should be applied?   If so, how is this
>conveyed from the classifier to the SF?   Inband?   Out of band?
SK> Precisely! The classification-capable nodes can provide such metadata
or ID to the service nodes to provide enhanced service delivery where the
service node is acting on a policy selected by the classifier-capable
node. This ID may in turn lead to fine-grained classification at the
service-node based on any number attributes, including, flow, environment,
network, ... How to carry large metadata seems like a perfectly valid
discussion to have as part of the WG and should be input to the WG when it
is formed.