Subject: [nsc] Comments on draft-boucadair-network-function-chaining-00

From: Ron Parker <[email-masked]>
Date: Tue, 25 Jun 2013 21:40:16 +0000

Med, Christian,

Thanks for the excellent document and to all that are contributing to this worthwhile effort.   I have included specific comments below and would be pleased to see them spur some discussion on the thread.

Best regards,

Ron Parker
Affirmed Networks

1.3 Objectives
Is it desirable to support unidirectional chains or are only bidirectional chains considered?   For bidirectional chains, is NLF chronology always reversed for each direction, or is it arbitrarily  controlled?
Are NLF's identified by IP address, FQDN, or both?
Is it an objective for NLFC to explicitly handle load balancing towards multiply-instantiated NLF's , or is load balancing in this regard considered to be part of each NLF?
Is it an objective for NLFC to determine the availability of an NLF?   If so, are there policies regarding what to do when an NLF becomes unavailable?

1.4 Assumptions
All NLFs are reachable via standard IP routing techniques (i.e., no assumptions regarding non-IP SDN protocols or techniques)?

1.5 Rationale
Suggest comment about fragmentation be moved to Objectives section.

1.6 Generic Requirements
Whether path stretch occurs or not is an administrative matter, assuming reasonably correct IP routing topologies.

3.3 Building NLF Maps
Does an NLF map specify the set of NLF's, only, or does it specify the set of NLF's and the policy to be applied by each.   For example, assume that Firewall-A and NAT64-A are distinct instances of NLFs.   Is {Firewall-A-profile-1, NAT64-A-profile-1} distinct from {Firewall-A-profile-2, Nat64-A-profile-1}.   Or, alternatively, is the policy conveyed outside of the map?

4.1  NLFC Boundary Node
I think the definition of ingress/egress here is problematic as it seems to be implying topological direction (i.e., uplink and downlink in a mobile environment).   If, however, the NLFC domain is thought of as residing in between 2 non-NLFC domains (or segments of the same domain), then there is both ingress and egress at both ends of the chain.   A more descriptive approach may be to use terms such as "West-ingress", "East-egress", "East-ingress", "West-egress".    In a wireless domain, perhaps "north" and "south" would be more intuitive, but I think the connotation is more limiting in a general sense.

4.3 NLFC Ingress Node
As an ingress node which connects to the non NLFC domain, when would an NLFC Map Index be present?   Also, this implies an encapsulation technique that has not been previously introduced in the document.

5.1.1 NLFC Map Index
If the individual entries in an NLFC Map indicate only the identity of the NLF, then 8 or 16 bits to identify which NLFC Map would be sufficient.   If, however, the entries in an NLFC Map indicate NLF identity+policy, then 16 or 32 bits would be more appropriate.

5.1.3 Where to store NLFC Map Index in a packet?
Consider usage of GRE key.   Advantage is that in many cases, encapsulation is required and GRE is a standard encapsulation technique which provides a 32-bit general purpose field.   Disadvantage is that some systems may require each unique GRE key to be provisioned as an IP interface.

---

From: <[email-masked]>
Date: Wed, 26 Jun 2013 08:31:35 +0200

Dear Ron,

Thank you for the review.
Please see inline.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Ron Parker
Envoyé : mardi 25 juin 2013 23:40
À : [email-masked]
Objet : [nsc] Comments on draft-boucadair-network-function-chaining-00

Med, Christian,

Best regards,

Ron Parker
Affirmed Networks

1.3 Objectives
Is it desirable to support unidirectional chains or are only bidirectional chains considered?
[Med] The current text (section 3.3) indicates distinct chains can be applied for inbound and outbound traffic. The direction of the chain is not included as an attribute of the NLFC Map but this is realized using two chains: i.e., two NLFC Maps will be installed in the NLFC Policy Table.

  For bidirectional chains, is NLF chronology always reversed for each direction, or is it arbitrarily  controlled?
[Med] The current text allows to specify distinct NLFC Map for each direction.

Are NLF's identified by IP address, FQDN, or both?
[Med] I guess your question is about locators not identifiers. The current text says both can be supported but we recommend the use of an IP address since no resolution capability would be needed in the NLF-enabled node. Resolution capabilities (and advanced TE functions) can be enabled only at the PDP (Policy Decision Point); no need to overload NLF-enabled nodes with such features.

Is it an objective for NLFC to explicitly handle load balancing towards multiply-instantiated NLF's , or is load balancing in this regard considered to be part of each NLF?
[Med] Yes. The current text says:

   o  Advanced features (e.g., load balancing objectives) are also
      policy-based.  Invoked enforcement points are not aware of such
      objectives.

Is it an objective for NLFC to determine the availability of an NLF?   If so, are there policies regarding what to do when an NLF becomes unavailable?
[Med] Good point. FYI, we are currently working on a OSPF extension for this purpose. We will share the text soon.

1.4 Assumptions
All NLFs are reachable via standard IP routing techniques (i.e., no assumptions regarding non-IP SDN protocols or techniques)?
[Med] How FIBs and RIBs are populated is orthogonal to the overall procedure.

1.5 Rationale
Suggest comment about fragmentation be moved to Objectives section.
[Med] I will see how to update the text.

1.6 Generic Requirements
Whether path stretch occurs or not is an administrative matter, assuming reasonably correct IP routing topologies.
[Med] Agree. This is deployment-specific.

3.3 Building NLF Maps
Does an NLF map specify the set of NLF's, only, or does it specify the set of NLF's and the policy to be applied by each.   For example, assume that Firewall-A and NAT64-A are distinct instances of NLFs.   Is {Firewall-A-profile-1, NAT64-A-profile-1} distinct from {Firewall-A-profile-2, Nat64-A-profile-1}.   Or, alternatively, is the policy conveyed outside of the map?
[Med] I'm not sure I get the point. What do you mean by "profile" here?

4.1  NLFC Boundary Node
I think the definition of ingress/egress here is problematic as it seems to be implying topological direction (i.e., uplink and downlink in a mobile environment).   If, however, the NLFC domain is thought of as residing in between 2 non-NLFC domains (or segments of the same domain), then there is both ingress and egress at both ends of the chain.   A more descriptive approach may be to use terms such as "West-ingress", "East-egress", "East-ingress", "West-egress".    In a wireless domain, perhaps "north" and "south" would be more intuitive, but I think the connotation is more limiting in a general sense.
[Med] Each NLFC Boundary Node behaves in both the ingress and egress roles. It behaves as "ingress" for traffic entering the domain and as "egress" for traffic existing the domain.

4.3 NLFC Ingress Node
As an ingress node which connects to the non NLFC domain, when would an NLFC Map Index be present?   Also, this implies an encapsulation technique that has not been previously introduced in the document.
[Med] Just like setting/re-setting DSCP values at the boundaries of a domain, the NLFC Map Index can be set by any "non-legitimate" node. This is even a basic attack to disturb a service or try granting access to non-authorized services. This is why we recommend to enforce a basic policy to not trust any NLFC Map Index received from adjacent domains.

5.1.1 NLFC Map Index
If the individual entries in an NLFC Map indicate only the identity of the NLF, then 8 or 16 bits to identify which NLFC Map would be sufficient.   If, however, the entries in an NLFC Map indicate NLF identity+policy, then 16 or 32 bits would be more appropriate.
[Med] The policy is not signaled in packets; only the index of the NLFC Map is.

5.1.3 Where to store NLFC Map Index in a packet?
Consider usage of GRE key.   Advantage is that in many cases, encapsulation is required and GRE is a standard encapsulation technique which provides a 32-bit general purpose field.   Disadvantage is that some systems may require each unique GRE key to be provisioned as an IP interface.
[Med] Will add a new entry for it. Another inconvenient I see is for cases where encapsulation is not needed at all. This is typically when the next NLF node is an adjacent node (see Section 6.2).

---

From: <[email-masked]>
Date: Wed, 26 Jun 2013 08:38:55 +0200

Hello Ron,

Many thanks for your feedback - please see inline.

[snip]

1.3 Objectives
Is it desirable to support unidirectional chains or are only bidirectional chains considered?
[CJ] I guess this depends on the nature of the service to be delivered and the corresponding NLF functions to be invoked. Admittedly, the draft was originally written with a kind of "request/response" type of service in mind, but I think nothing really prevents unidirectional chaining scenarios - this could apply to a multicast service within the context of a QoS-based multicast forwarding scheme that would solicit several functions in the access infrastructure to make sure the multicast contents are properly delivered to the receiver, for example.
   For bidirectional chains, is NLF chronology always reversed for each direction, or is it arbitrarily  controlled?
[CJ] This should be arbitrarily controlled.
Are NLF's identified by IP address, FQDN, or both?
[CJ] I guess you refer to the NKF Identifier, as introduced in section 2, right? As for the NLF Locator, we currently privilege the IP address, but FQDN could be used (see Section 3.2). As for the Identifier, this could be both an IP address and a FQDN.
Is it an objective for NLFC to explicitly handle load balancing towards multiply-instantiated NLF's , or is load balancing in this regard considered to be part of each NLF?
[CJ] I think it's primarily a design choice that will be conditioned by the very nature of the NLF to be activated. I'm not sure each and every NLF we can think about has implicit load balancing capabilities. Therefore, I would consider load balancing as a possible (but not necessarily mandatory) objective of the NLFC machinery.
Is it an objective for NLFC to determine the availability of an NLF?
[CJ] No, I think the availability of an NLF suggests another mechanism, e.g., the (automated) discovery of the network topology, devices and their respective capabilities which will feed the PDP intelligence with information to not only dynamically structure a network service but also to trigger NLFC according to the outcomes of the negotiation of the service parameters between the customer and the provider, for example.
   If so, are there policies regarding what to do when an NLF becomes unavailable?
[CJ] To me, this is part of a feedback mechanism introduced in draft-sin-sdnrg* which is meant to assess how efficiently a policy (or a set thereof) is enforced, but also to notify the PDP about any event (such as the unavailability of a NLF which failed the chaining operation for example) that may affect the decision-making process.

1.4 Assumptions
All NLFs are reachable via standard IP routing techniques (i.e., no assumptions regarding non-IP SDN protocols or techniques)?
[CJ] Yes, the draft is generic enough to consider any IP networking environment.

1.5 Rationale
[CJ] Makes sense.

1.6 Generic Requirements
Whether path stretch occurs or not is an administrative matter, assuming reasonably correct IP routing topologies.
[CJ] Agreed, but do you suggest any particular wording?

3.3 Building NLF Maps
Does an NLF map specify the set of NLF's, only, or does it specify the set of NLF's and the policy to be applied by each.   For example, assume that Firewall-A and NAT64-A are distinct instances of NLFs.   Is {Firewall-A-profile-1, NAT64-A-profile-1} distinct from {Firewall-A-profile-2, Nat64-A-profile-1}.   Or, alternatively, is the policy conveyed outside of the map?
[CJ] Policies are conveyed outside of the map.

4.1  NLFC Boundary Node
I think the definition of ingress/egress here is problematic as it seems to be implying topological direction (i.e., uplink and downlink in a mobile environment).   If, however, the NLFC domain is thought of as residing in between 2 non-NLFC domains (or segments of the same domain), then there is both ingress and egress at both ends of the chain.   A more descriptive approach may be to use terms such as "West-ingress", "East-egress", "East-ingress", "West-egress".    In a wireless domain, perhaps "north" and "south" would be more intuitive, but I think the connotation is more limiting in a general sense.
[CJ] I would avoid that kind of elaboration. As for the case you rightfully mention, I think we can still deal with ingress and egress notions on both "sides" of the NLFC domain.

4.3 NLFC Ingress Node
As an ingress node which connects to the non NLFC domain, when would an NLFC Map Index be present?
[CJ] I guess the operation is similar to DSCP-re-marking, with implicitly security threats that have been mentioned in the document.
  Also, this implies an encapsulation technique that has not been previously introduced in the document.

5.1.1 NLFC Map Index
[CJ] Right.

[CJ] OK.

Thanks,

Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

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

Thanks, Med.

My followup inline.

B.R.,
Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 26, 2013 2:32 AM
To: Ron Parker; [email-masked]
Subject: RE: Comments on draft-boucadair-network-function-chaining-00

Dear Ron,

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Ron Parker
Envoyé : mardi 25 juin 2013 23:40
À : [email-masked]<mailto:[email-masked]>
Objet : [nsc] Comments on draft-boucadair-network-function-chaining-00

Med, Christian,

Best regards,

Ron Parker
Affirmed Networks

1.3 Objectives

Are NLF's identified by IP address, FQDN, or both?
[Med] I guess your question is about locators not identifiers. The current text says both can be supported but we recommend the use of an IP address since no resolution capability would be needed in the NLF-enabled node. Resolution capabilities (and advanced TE functions) can be enabled only at the PDP (Policy Decision Point); no need to overload NLF-enabled nodes with such features.
[Ron] Yes, I meant locators.   Thanks for the clarification.

Is it an objective for NLFC to determine the availability of an NLF?   If so, are there policies regarding what to do when an NLF becomes unavailable?
[Med] Good point. FYI, we are currently working on a OSPF extension for this purpose. We will share the text soon.
[Ron] I was thinking more along the lines of ping or BFD to determine if the node is reachable.   For example, an NLF realizing Analytics may be deemed non-critical.   If it goes down, the desired behavior may be to prune it from the chain.    Another aspect is load balancing.   If there are, for example, 4 addressable entities provisioned to collectively realize an NLF, if one goes down all subsequent traffic should be steered to the remaining 3.

1.4 Assumptions
All NLFs are reachable via standard IP routing techniques (i.e., no assumptions regarding non-IP SDN protocols or techniques)?
[Med] How FIBs and RIBs are populated is orthogonal to the overall procedure.
[Ron] I'm fine with that answer.   My thought here was to point out that techniques like OpenFlow are not presumed :).

1.5 Rationale
Suggest comment about fragmentation be moved to Objectives section.
[Med] I will see how to update the text.
[Ron].   Thanks.   Also, "avoid" fragmentation may be described better as "minimize" fragmentation.

1.6 Generic Requirements

3.3 Building NLF Maps
Does an NLF map specify the set of NLF's, only, or does it specify the set of NLF's and the policy to be applied by each.   For example, assume that Firewall-A and NAT64-A are distinct instances of NLFs.   Is {Firewall-A-profile-1, NAT64-A-profile-1} distinct from {Firewall-A-profile-2, Nat64-A-profile-1}.   Or, alternatively, is the policy conveyed outside of the map?
[Med] I'm not sure I get the point. What do you mean by "profile" here?
[Ron] By profile, I mean a set of local differentiated policies.   For example, an NLF realizing DPI and traffic enforcement may wish to block peer-to-peer protocols for some group of users and block voip protocols for some other group of users.   Can the PDP facilitate this by conveying to the NLF whether the traffic belongs to the first group of users or the second?

4.1  NLFC Boundary Node
I think the definition of ingress/egress here is problematic as it seems to be implying topological direction (i.e., uplink and downlink in a mobile environment).   If, however, the NLFC domain is thought of as residing in between 2 non-NLFC domains (or segments of the same domain), then there is both ingress and egress at both ends of the chain.   A more descriptive approach may be to use terms such as "West-ingress", "East-egress", "East-ingress", "West-egress".    In a wireless domain, perhaps "north" and "south" would be more intuitive, but I think the connotation is more limiting in a general sense.
[Med] Each NLFC Boundary Node behaves in both the ingress and egress roles. It behaves as "ingress" for traffic entering the domain and as "egress" for traffic existing the domain.
[Ron]  Ok.   This connotation of topological direction may have been my misreading of the text.

4.3 NLFC Ingress Node
As an ingress node which connects to the non NLFC domain, when would an NLFC Map Index be present?   Also, this implies an encapsulation technique that has not been previously introduced in the document.
[Med] Just like setting/re-setting DSCP values at the boundaries of a domain, the NLFC Map Index can be set by any "non-legitimate" node. This is even a basic attack to disturb a service or try granting access to non-authorized services. This is why we recommend to enforce a basic policy to not trust any NLFC Map Index received from adjacent domains.
[Ron]   My comment was partly editorial - the text describes procedures related to encapsulation prior to introducing the concept of encapsulation.

5.1.1 NLFC Map Index
If the individual entries in an NLFC Map indicate only the identity of the NLF, then 8 or 16 bits to identify which NLFC Map would be sufficient.   If, however, the entries in an NLFC Map indicate NLF identity+policy, then 16 or 32 bits would be more appropriate.
[Med] The policy is not signaled in packets; only the index of the NLFC Map is.
[Ron]  I meant policy that is locally significant to the NLF.   See my followup to 3.3, above.

5.1.3 Where to store NLFC Map Index in a packet?
Consider usage of GRE key.   Advantage is that in many cases, encapsulation is required and GRE is a standard encapsulation technique which provides a 32-bit general purpose field.   Disadvantage is that some systems may require each unique GRE key to be provisioned as an IP interface.
[Med] Will add a new entry for it. Another inconvenient I see is for cases where encapsulation is not needed at all. This is typically when the next NLF node is an adjacent node (see Section 6.2).
[Ron]  Depending on your views on conveyance of NLF-significant policy from the PDP towards the NLF (see 3.3, above), encapsulation may be desirable even when on the same L3 subnet.

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Jun 2013 14:39:07 +0000

Thanks for the response, Christian.

My follow up is embedded.

BR,
Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 26, 2013 2:39 AM
To: Ron Parker; [email-masked]
Subject: RE: Comments on draft-boucadair-network-function-chaining-00

Hello Ron,

[snip]

1.3 Objectives
[Ron] If the NLFC explicitly allows for load balancing by the PDP, then some requirements would follow wrt availability determination of the constituent addressable entities.  Optionally, a means to determine loading of the constituent addressable entities so that the PDP may make a more informed decision.   For the first, ping and BFD could be considered.   For the second, SNMP could be considered.

Is it an objective for NLFC to determine the availability of an NLF?
[CJ] No, I think the availability of an NLF suggests another mechanism, e.g., the (automated) discovery of the network topology, devices and their respective capabilities which will feed the PDP intelligence with information to not only dynamically structure a network service but also to trigger NLFC according to the outcomes of the negotiation of the service parameters between the customer and the provider, for example.
[Ron] End-to-end reliability and resiliency could be enhanced if the PDP could prevent launching packets into a broken chain.   Perhaps in some cases, an unreachable NLF should be pruned from the chain while in other cases, the traffic should be dropped.   A trap or other indication coming from the PDP would assist in overall network visibility and troubleshooting.

   If so, are there policies regarding what to do when an NLF becomes unavailable?
[CJ] To me, this is part of a feedback mechanism introduced in draft-sin-sdnrg* which is meant to assess how efficiently a policy (or a set thereof) is enforced, but also to notify the PDP about any event (such as the unavailability of a NLF which failed the chaining operation for example) that may affect the decision-making process.
[Ron]  My thinking here was a a proactive mechanism initiated by the PDP.

1.4 Assumptions

1.5 Rationale

1.6 Generic Requirements
Whether path stretch occurs or not is an administrative matter, assuming reasonably correct IP routing topologies.
[CJ] Agreed, but do you suggest any particular wording?
[Ron] I think the requirement could be removed without diminishing the rest of the specification.

3.3 Building NLF Maps
Does an NLF map specify the set of NLF's, only, or does it specify the set of NLF's and the policy to be applied by each.   For example, assume that Firewall-A and NAT64-A are distinct instances of NLFs.   Is {Firewall-A-profile-1, NAT64-A-profile-1} distinct from {Firewall-A-profile-2, Nat64-A-profile-1}.   Or, alternatively, is the policy conveyed outside of the map?
[CJ] Policies are conveyed outside of the map.
[Ron] My thinking here is that some NLF's are capable of providing differentiated services (i.e., a DPI function could block peer-to-peer for one group of users and voip for another group of users).   If the DPI function is a non-classification node (in NLFC parlance), then it may be beneficial for the PDP to indicate which differentiated service to apply.   One approach is that the NLFC map explicitly indicates this.   If that approach were followed, then an NLF's containment within a particular NLF Map would indicate 2 things - first, that the NLF should be a member of the chain with a particular previous hop and a particular next hop (this is pretty obvious), and second, that the NLF should apply a particular local policy (where coordination of the NLFC map index and the local policy is an administrative matter).

4.1  NLFC Boundary Node
I think the definition of ingress/egress here is problematic as it seems to be implying topological direction (i.e., uplink and downlink in a mobile environment).   If, however, the NLFC domain is thought of as residing in between 2 non-NLFC domains (or segments of the same domain), then there is both ingress and egress at both ends of the chain.   A more descriptive approach may be to use terms such as "West-ingress", "East-egress", "East-ingress", "West-egress".    In a wireless domain, perhaps "north" and "south" would be more intuitive, but I think the connotation is more limiting in a general sense.
[CJ] I would avoid that kind of elaboration. As for the case you rightfully mention, I think we can still deal with ingress and egress notions on both "sides" of the NLFC domain.
[Ron] I may have read more into the original language than was intended.

4.3 NLFC Ingress Node

5.1.1 NLFC Map Index
If the individual entries in an NLFC Map indicate only the identity of the NLF, then 8 or 16 bits to identify which NLFC Map would be sufficient.   If, however, the entries in an NLFC Map indicate NLF identity+policy, then 16 or 32 bits would be more appropriate.
[CJ] Right.
[Ron] See discussion of local policy above.

Thanks,

Christian.

Thank you.

---

From: <[email-masked]>
Date: Thu, 27 Jun 2013 13:40:47 +0200

Hello Ron,

A few additional comments.
[snip]
[CJ] I think it's primarily a design choice that will be conditioned by the very nature of the NLF to be activated. I'm not sure each and every NLF we can think about has implicit load balancing capabilities. Therefore, I would consider load balancing as a possible (but not necessarily mandatory) objective of the NLFC machinery.
[Ron] If the NLFC explicitly allows for load balancing by the PDP, then some requirements would follow wrt availability determination of the constituent addressable entities.  Optionally, a means to determine loading of the constituent addressable entities so that the PDP may make a more informed decision.   For the first, ping and BFD could be considered.   For the second, SNMP could be considered.
[CJ] I'm not sure a Ping or BFD would be sufficient to help the PDP make a decision about load balancing. I think that what you consider as an option is actually mandatory for the sake of efficient load balancing. SNMP is one candidate protocol to report about the loading conditions of an addressable entity indeed. There are others, e.g., COPS-PR along with the support of RFC 3571.

[CJ] I guess you meant a trap coming from the NLF-enabled device, right? I agree that the NLFC behavior is very likely to depend on the nature of the NLF functions to be invoked as per the NLFC Map, possibly yielding packet dropping (but this is a situation that should be avoided: this brings back the kind of feedback mechanism you rightfully mention in the previous comment so that the PDP can make a decision accordingly, which could include the triggering of either a new resource provisioning cycle, a new negotiation phase with the customer, the computation of another differentiated forwarding path, or a combination thereof.

Cheers,

Christian.

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Jun 2013 14:18:18 +0000

Thanks for the continued discussion, Christian.

Regarding load balancing performed by PDP, there may be simple scenarios where live connectivity to an NLF instance within a pool of NLF instances is a sufficient condition in order to send additional work to it and I don't want to preclude that scenario.   More complex scenarios would, of course, require some way for the PDP to obtain  a more sophisticated view of loading state of each of the NLF instances within the pool of NLF instances.

Determination of liveness is important, IMO, even for invocation of non-load balanced NLFs by the PDP.   Given that the PDP is an "orchestrator" of end-to-end service chains, it is a natural entity to query as to a high level view of the health of those chains.   This would also facilitate support of active/standby NLF instances, again, outside of load balancing.

My suggestion is that liveness determination between PDP and NLF be explicitly part of the architecture.

Thanks.

   Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 27, 2013 7:41 AM
To: Ron Parker; [email-masked]
Subject: RE: Comments on draft-boucadair-network-function-chaining-00

Hello Ron,

Cheers,

Christian.

Thank you.