Subject: [nsc] Fwd: New Version Notification for draft-lee-nsc-verification-problem-statement-01.txt

From: Seung-Ik Lee <[email-masked]>
Date: Tue, 16 Jul 2013 00:29:23 +0900

FYI,

We have submitted an I-D to address the problem of service chain
conflicts with a verification method.
Your comments are appreciated.

Thanks.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2013/7/16
Subject: New Version Notification for
draft-lee-nsc-verification-problem-statement-01.txt
To: Myung-Ki Shin <[email-masked]>, Yoon-Chul Choi
<[email-masked]>, Seung-Ik Lee <[email-masked]>

A new version of I-D, draft-lee-nsc-verification-problem-statement-01.txt
has been successfully submitted by Seung-Ik Lee and posted to the
IETF repository.

Filename:        draft-lee-nsc-verification-problem-statement
Revision:        01
Title:           Problem statement for Verification of Network Service Chains
Creation date:   2013-07-15
Group:           Individual Submission
Number of pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-lee-nsc-verification-problem-statement-01.txt
Status:
http://datatracker.ietf.org/doc/draft-lee-nsc-verification-problem-statement
Htmlized:
http://tools.ietf.org/html/draft-lee-nsc-verification-problem-statement-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-lee-nsc-verification-problem-statement-01

Abstract:
   This document addresses the possible conflicts between service
   overlays in the network service chaining.  These conflicts are due to
   overlapping in classification rules and resource sharing of service
   overlays.  The verification of service chains provides a method for
   network administrators to detect such conflicts and correct a
   problematic service chain before applying it on the real network.

The IETF Secretariat

-- 
Seung-Ik Lee (이승익)
Protocol Engineering Center, ETRI
Tel.    +82-42-860-1483
Fax.   +82-42-861-5404
Email. [email-masked]; [email-masked]

---

From: Ron Parker <[email-masked]>
Date: Mon, 15 Jul 2013 15:47:31 +0000

Seung-Ik, et al, 

Thanks for contributing on this topic.

If I read this correctly, you are interested in identifying the number of rules that specify a particular network function instance.   One reason to wish to do this is because there may be many service orchestrators in the network.   Do I have this correct?

While it is informative to know how many rules, network wide, select a particular network function instance, it would also be informative to know the actual processing load on that network function instance.   The existence of a rule doesn't imply that the rule is being executed with any particular frequency.

Also, in your proposal, how does the network function instance discover that it is referenced by a rule?   And conversely, how does it discover that the reference is no longer valid?   Are there control plane requirements here?

Thanks.

   Ron Parker
   Affirmed Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Seung-Ik Lee
Sent: Monday, July 15, 2013 11:29 AM
To: [email-masked]
Subject: [nsc] Fwd: New Version Notification for draft-lee-nsc-verification-problem-statement-01.txt

FYI,

We have submitted an I-D to address the problem of service chain conflicts with a verification method.
Your comments are appreciated.

Thanks.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2013/7/16
Subject: New Version Notification for
draft-lee-nsc-verification-problem-statement-01.txt
To: Myung-Ki Shin <[email-masked]>, Yoon-Chul Choi <[email-masked]>, Seung-Ik Lee <[email-masked]>

A new version of I-D, draft-lee-nsc-verification-problem-statement-01.txt
has been successfully submitted by Seung-Ik Lee and posted to the IETF repository.

Abstract:

The IETF Secretariat

--
Seung-Ik Lee (이승익)
Protocol Engineering Center, ETRI
Tel.    +82-42-860-1483
Fax.   +82-42-861-5404
Email. [email-masked]; [email-masked] _______________________________________________
nsc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsc

---

From: Seung-Ik Lee <[email-masked]>
Date: Tue, 16 Jul 2013 10:21:43 +0900

Hello Ron,

Thank you for the comments.
Please see my in-line responses:

> If I read this correctly, you are interested in identifying the number of rules that specify a particular network function instance.   One reason to wish to do this is because there may be many ser…

Not about a physical instance but a logical function.
We think that the rule should specify logical network functions. The
corresponding physical service nodes and processes can be dynamically
located at invocation procedures.
For example, rule A specifies a logical function NFa in its service
chain. And NFa is deployed at LOCa and LOCb so that
system/administrator can automatically/manually select one of the
locators to invoke NFa according to the network or service status
(e.g., load or path strech).

> While it is informative to know how many rules, network wide, select a particular network function instance, it would also be informative to know the actual processing load on that network function…

You're correct. The existence of a rule does not imply that the rule
or target network function instances are being executed.
It just gives the *possibilities* of a use of network function (not an
instance but a logical one) and indicates that the corresponding
resources would be requested in the future.

The current verification approach in the draft is a sort of off-line
tools which indicates the relationships among the service chains in
terms of resources and rules.
Based on this idea, we are under study on an on-line verification
approach to see what happens with the service chains in the network
right now.
With this on-line approach, we expect that it can handle the actual
processing load of a network instance and the actual executions of the
rule.

> Also, in your proposal, how does the network function instance discover that it is referenced by a rule?   And conversely, how does it discover that the reference is no longer valid?   Are there co…

We can formally check the occurrences of the network function in the
service chains.
We cannot see and don't care the validity of the reference to the
network function instance at this moment.
But this information would be helpful for verification and can be
obtained with additional control plane requirements.
Let us study further on it.

Thanks.