Subject: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

From: Tina TSOU <[email-masked]>
Date: Mon, 6 Jul 2015 23:04:42 +0000

Dear all,

Below is the draft agenda and logistics for next call during 7:30-8:30am, Monday, July 13, San Francisco time.

Look forward to talking to many of you at the meeting.

----------

1. Note Well, logistics, agenda bashing (chairs, 5 min)

2. Slides Preparation for the BoF (Times are the ones in the call next week – not the BOF)

2.1. Goals, Framework, Examples (Max, Oscar (Luis) et al, 10 minutes)

2.2. Relationship to other WGs (Scott/Sue et al, 5 minutes)

2.3. Information Model Overview (John et al, 5 minutes)

2.4. Data Model Overview (Andy et al, 5 minutes)

2.5. Charter presentation (Dan/Juergen et al, 10 minutes)

2.6. Discussion on whether the progress assessment implies going forward changes to the charter (all, 15 minutes)

2.7. Questions to the audience (chairs, 10 minutes)

-----------

Join WebEx meeting<https://ietf.webex.com/ietf/j.php?MTID=m23e113c8822a0970e0e779383ab09322>

Meeting number: 646 022 302

Meeting password:       2015

Join by phone

1-877-668-4493 Call-in toll free number (US/Canada)

1-650-479-3208 Call-in toll number (US/Canada)

Access code: 646 022 302

Toll-free calling restrictions<http://www.webex.com/pdf/tollfree_restrictions.pdf>

Can't join the meeting? Contact support.<https://ietf.webex.com/ietf/mc>

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

Thank you,

Dan & Tina

---

From: Tina TSOU <[email-masked]>
Date: Fri, 10 Jul 2015 08:31:26 +0000

Dear Scott and Sue,

Regarding “2.2. Relationship to other WGs (Scott/Sue et al, 5 minutes)” (Times are the ones in the call next week – not the BOF), attached is a quick update based on Jun’s presentation in last BoF, according to the discussion after Dallas.

Feel free to use or update the slides.

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Tuesday, July 07, 2015 7:05 AM
To: [email-masked]
Subject: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Dear all,

----------

-----------

Meeting password:       2015

Join by phone

Access code: 646 022 302

Thank you,

Dan & Tina

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 10 Jul 2015 09:20:37 +0000

Hi,

It would be very useful for the call on Monday that folks who own items on the agenda can prepare and submit for discussion a draft of their slide decks. It is understood that these would be only draft slides for discussion that will be updated after the call on Monday and before IETF 93.

Thanks and Regards,

Dan

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Tuesday, July 07, 2015 2:05 AM
To: [email-masked]
Subject: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Dear all,

----------

-----------

Join WebEx meeting<https://ietf.webex.com/ietf/j.php?MTID=m23e113c8822a0970e0e779383ab09322<https://urldefense.proofpoint.com/v2/url?u=https-3A__ietf.webex.com_ietf_j.php-3FMTID-3Dm23e113c8822a0970e0e779383ab09322&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=5o_Is2wUigC3ddd4rYeeX71W3SZ0iusenzX-7phZkJE&s=_zCzyFpRlFDUsruTlmLpVz6tH_QpuLrHuADg5H3rWV4&e=>>

Meeting password:       2015

Join by phone

Access code: 646 022 302

Toll-free calling restrictions<http://www.webex.com/pdf/tollfree_restrictions.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.webex.com_pdf_tollfree-5Frestrictions.pdf&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=5o_Is2wUigC3ddd4rYeeX71W3SZ0iusenzX-7phZkJE&s=nL8-teqG2Euv9I9n3SWRXhiYHxazMgQNp1fR2R72N2Q&e=>>

Can't join the meeting? Contact support.<https://ietf.webex.com/ietf/mc<https://urldefense.proofpoint.com/v2/url?u=https-3A__ietf.webex.com_ietf_mc&d=AwMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=5o_Is2wUigC3ddd4rYeeX71W3SZ0iusenzX-7phZkJE&s=pH8ALHAwVUPf8pRzxMQD30gn32p0oISnQSFwsf-9tOs&e=>>

Thank you,

Dan & Tina

---

From: Tina TSOU <[email-masked]>
Date: Wed, 15 Jul 2015 07:42:28 +0000

Dear all,

Enclosed pls find the updated slides based on Monday July 13 call discussion, only page 8 added.

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Friday, July 10, 2015 4:31 PM
To: Scott O. Bradner; Susan Hares
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Dear Scott and Sue,

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Tuesday, July 07, 2015 7:05 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Dear all,

----------

-----------

Meeting password:       2015

Join by phone

Access code: 646 022 302

Thank you,

Dan & Tina

---

From: Xiayinben <[email-masked]>
Date: Thu, 16 Jul 2015 01:38:40 +0000

Hi Tina and all,

I do not agree with your word about NEMO/ibnemo in page 8.

Your sentence: “NEMO uses a flatter, simpler object model with fewer objects to represent targets of policy. NEMO does not define a policy model, and does not support ECA policies. NEMO uses a condition-action paradigm to execute its policy commands.”
The truth is that NEMO define an object model and an operation model to represent network abstraction for intent NBI, because NEMO’s target is a simplified network interface(Intent NBI) for application even for ender-user.  policy is only a type of operation in Intent NBI. NEMO doesn’t NEED to define a new policy model, because industry already has well defined policy model(such as RFC 3460). We will not rebuild a wheel.

Your sentence: “IBNemo – 'intent' means I express a desired topology and its properties.”
The truth  is that Ibnemo –‘Intent’ means user simply and intuitively  express demands of network resource and/or network behavior. Topology and its properties are typical type of network resource, so they are part of network intent, but not all.

Best regards,
Yinben
发件人: Supa [mailto:[email-masked]] 代表 Tina TSOU
发送时间: 2015年7月15日 15:42
收件人: Scott O. Bradner; Susan Hares
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Dear all,

Thank you,
Tina

Dear Scott and Sue,

Thank you,
Tina

Dear all,

----------

-----------

Meeting password:       2015

Join by phone

Access code: 646 022 302

Thank you,

Dan & Tina

---

From: John Strassner <[email-masked]>
Date: Thu, 16 Jul 2015 16:47:07 -0700

What, exactly, are you not agreeing with in the following sentence:
"NEMO uses a flatter, simpler object model with fewer objects to represent
targets of policy. NEMO does not define a policy model, and does not
support ECA policies. NEMO uses a condition-action paradigm to execute its
policy commands.”

Lets take the sentence point by point.

#1 FLATTER, SIMPLER OBJECT MODEL
NEMO defines three objects: node, link, and flow. How many managed objects
do G.805 or G.809, let alone the average MIB, define? It is irrelevant that
you can define subclasses of node - the user has to do all the work, and
this guarantees non-interoperable solutions.

#2 TARGETS OF POLICY.
You just said that you define an object model and an operation model. Both
would be policy targets, by any standard CA or ECA definition.

#3. NEMO DOES NOT DEFINE A POLICY MODEL
You said: "NEMO doesn’t *NEED* to define a new policy model, because
industry already has well defined policy model(such as RFC 3460). We will
not rebuild a wheel." Not only did you agree that you aren't defining a
policy model, but you appear to be unaware of why RFC3460 is badly broken.
So yes, you do need to rebuild this.

#4. DOES NOT SUPPORT ECA POLICIES. NEMO USES A CONDITION-ACTION PARADIGM TO
EXECUTE ITS POLICY COMMANDS.
It is inconceivable to me how you could disagree with this. From
draft-xia-sdnrg-nemo-language-02, Section 5.1: "All the policies follow the
same pattern "when <condition>, to execute <action>, with <constraint>",
and can be applied to any entity." This is NOT an ECA policy; any useful
implementation of CA or ECA allows constraints - EXCEPT RFC3460.

John

On Wed, Jul 15, 2015 at 6:38 PM, Xiayinben <[email-masked]> wrote:

> Your sentence: “NEMO uses a flatter, simpler object model with fewer
> objects to represent targets of policy. NEMO does not define a policy
> model, and does not support ECA policies. NEMO uses a condition-action
> paradigm to execute its policy commands.”
>
> The truth is that NEMO define an object model and an operation model to
> represent network abstraction for intent NBI, because NEMO’s target is a
> simplified network interface(Intent NBI) for application even for
> ender-user.  policy is only a type of operation in Intent NBI. NEMO doesn’t
> *NEED* to define a new policy model, because industry already has well
> defined policy model(such as RFC 3460). We will not rebuild a wheel.
>
>
>
> The truth  is that Ibnemo –‘Intent’ means user simply and intuitively
> express demands of network resource and/or network behavior. Topology and
> its properties are typical type of network resource, so they are part of
> network intent, but not all.
>
>
>
> Best regards,
>
> Yinben
>
> *发件人:* Supa [mailto:[email-masked] <[email-masked]>] *代表 *Tina
> TSOU
> *发送时间:* 2015年7月15日 15:42
> *收件人:* Scott O. Bradner; Susan Hares
> *抄送:* [email-masked]
> *主题:* Re: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco
> time
>
>
>
> Dear all,
>
>
>
> *From:* Supa [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Tina TSOU
> *Sent:* Friday, July 10, 2015 4:31 PM
> *To:* Scott O. Bradner; Susan Hares
> *Cc:* [email-masked]
> *Subject:* Re: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San
> Francisco time
>
>
>
> Dear Scott and Sue,
>
>
>
> Regarding “2.2. Relationship to other WGs (Scott/Sue et al, 5 minutes)”
> (Times are the ones in the call next week – not the BOF), attached is a
> quick update based on Jun’s presentation in last BoF, according to the
> discussion after Dallas.
>
>
>
> *From:* Supa [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Tina TSOU
> *Sent:* Tuesday, July 07, 2015 7:05 AM
> *To:* [email-masked]
> *Subject:* [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco
> time
>
>
>
> Dear all,
>
>
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>
>

-- 
regards,
John

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Jul 2015 20:00:14 -0400

John: 

The premise of Nemo is still the 80/20 rule – of trying to provide a simple model for 80% of the application with 20% of the commands.   We posit two points:  

1)       IBNemo’s 15 specific commands for targeted use cases are better than the generic commands.  

2)      IBNemo’s 15 specific commands are better than NETCONF or RESTCONF commands 

In order to confirm our assumptions, we have proposed to prove this for specific use cases (see hares-.   This work includes checks on the user’s range of inputs, the expected output, and the prototype IBNemo code, and looks at the SUPA intent policy.  The user’s input includes:  use cases and potential intent policy.  

What’s the benefit for IB-NEMO for SUPA’s work?   SUPA’s defining generic policy information models for ECA and Intent.  While we have many examples of ECA policy over the last 30 years in IETF, we do not have many examples of Intent policy.   IB-Nemo will benefit from SUPA’s definition and design work.  One thing that would be useful, is to post how SUPA’s model can guide IB-Nemo’s user policy or IB-Nemo’s translation of user policy into network-wide policy in the network management system. 

What the benefit for IETF for IB-Nemo’s Work?  IBNemo presents a light weight protocol designed for application to network controller use. The design of a protocol will include feeding into network-wide yang modules.  NETCONF/RESTCONF were designed for device level single node usage.   

·         If IBNemo succeeds in standardizing a new protocol, then two different protocols (NETCONF/RESTCONF/) and IBNemo can feed the network-wide models.  

·         If IBNemo work does not prove to be more efficient (Juergen’s supposition), then RESTCONF will have specific proof that RESTCONF is sufficient design for both device-level and network-wide level.

See my comments on the discussion below. 

https://datatracker.ietf.org/doc/draft-hares-ibnemo-overview/  - provides some use cases. 

Best wishes, 

Sue Hares 

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, July 16, 2015 7:47 PM
To: Xiayinben
Cc: [email-masked]; [email-masked]; Susan Hares; Scott O. Bradner; Tina TSOU
Subject: Re: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

"NEMO uses a flatter, simpler object model with fewer objects to represent targets of policy. NEMO does not define a policy model, and does not support ECA policies. NEMO uses a condition-action paradigm to execute its policy commands.”

NEMO defines three objects: node, link, and flow. How many managed objects do G.805 or G.809, let alone the average MIB, define? It is irrelevant that you can define subclasses of node - the user has to do all the work, and this guarantees non-interoperable solutions.

[Sue]: Rather than consider the possible number of managed objects, you need to look at the ones which are used by the use cases.  An example of this is the control of the routing functions on a devices.  The interface and route changes are most frequently used. 

#2 TARGETS OF POLICY.

You just said that you define an object model and an operation model. Both would be policy targets, by any standard CA or ECA definition.

[Sue]:  In the world of policy, both an object model and an operation model can be consider policy targets.   And in the academic sense – both can be consider policy.  However, we are trying to describe the difference between the user’s policy view,  the network-wide policy model, and the device-level policy.

You said: "NEMO doesn’t NEED to define a new policy model, because industry already has well defined policy model(such as RFC 3460). We will not rebuild a wheel." Not only did you agree that you aren't defining a policy model, but you appear to be unaware of why RFC3460 is badly broken. So yes, you do need to rebuild this.

[Sue]: See #2.  IB-NEMO is looking at Intent policy at the user-level that results in network-wide policy for the network management system. The network-management system will distribute this to devices.  I agree RFC3460 does not cover all use cases and has some technical difficulties. However, there is wisdom from that generic model guides the IB-NEMO translation of user policy to network policy.  If SUPA provides additional wisdom from ECA or Intent-based policy to guide IB-NEMOs translation of user policy to network policy, it would be good to post that here. 

#4. DOES NOT SUPPORT ECA POLICIES. NEMO USES A CONDITION-ACTION PARADIGM TO EXECUTE ITS POLICY COMMANDS.

It is inconceivable to me how you could disagree with this. From draft-xia-sdnrg-nemo-language-02, Section 5.1: "All the policies follow the same pattern "when <condition>, to execute <action>, with <constraint>", and can be applied to any entity." This is NOT an ECA policy; any useful implementation of CA or ECA allows constraints - EXCEPT RFC3460.

[John]: This is a good step forward from RFC3460 to agree that any ECA/CA implementation allows constraints.  Can you provide us the SUPA intent generic model with the same type of constraints?  

Sue 

-----------------

Hi Tina and all,

Best regards,

Yinben 

抄送: [email-masked]

Dear all,

 

Thank you,

Tina

Cc: [email-masked]

Dear Scott and Sue,

 

Thank you,

Tina

Dear all,

 
----------

 
-----------

Join WebEx meeting< <https://ietf.webex.com/ietf/j.php?MTID=m23e113c8822a0970e0e779383ab09322> https://ietf.webex.com/ietf/j.php?MTID=m23e113c8822a0970e0e779383ab09322>
Meeting number: 646 022 302
Meeting password:       2015

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 646 022 302
Toll-free calling restrictions< <http://www.webex.com/pdf/tollfree_restrictions.pdf> http://www.webex.com/pdf/tollfree_restrictions.pdf>

Can't join the meeting? Contact support.< <https://ietf.webex.com/ietf/mc> https://ietf.webex.com/ietf/mc>

Thank you,
Dan & Tina 

-- 

regards,

John

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Jul 2015 21:43:06 -0400

John and Yinben: 

It appear my flight-dazed mind missed a few things.  Like the correct posting name for my overview draft for IB-Nemo. It is the following: 

https://datatracker.ietf.org/doc/draft-hares-ibnemo-overview/

You can see an updated version at www.nemo-project.net, and I’ve attached a copy to this email. 

Sue 

From: Supa [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, July 17, 2015 8:00 PM
To: 'John Strassner'; 'Xiayinben'
Cc: 'Scott O. Bradner'; [email-masked]; [email-masked]; 'Tina TSOU'
Subject: Re: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

John: 

In order to confirm our assumptions, we have proposed to prove this for specific use cases (see hares-overview.   This work includes checks on the user’s range of inputs, the expected output, and the prototype IBNemo code, and looks at the SUPA intent policy.  The user’s input includes:  use cases and potential intent policy.  

Best wishes, 

Sue Hares 

#2 TARGETS OF POLICY.

Sue 

-----------------

Hi Tina and all,

Best regards,

Yinben 

Dear all,

 

Thank you,

Tina

Dear Scott and Sue,

 

Thank you,

Tina

Dear all,

 
----------

 
-----------

Join by phone

 

Thank you,
Dan & Tina 

-- 

regards,

John

---

From: Xiayinben <[email-masked]>
Date: Mon, 20 Jul 2015 02:09:08 +0000

Hi John,

Ibnemo’s target is to simplify network interface. I think this is also the interesting of industry for Intent NBI.
Intent NBI is based on some level of network abstraction. An appropriate abstraction provides a simple and intuitive network interface and hides implementation detail at same time.
The network object model and network operation model in Ibnemo represent our attempt. They certainly need polish. That is why we need Ibnemo.

I know you love policy so much. I can understand you want policy theory to be more perfect and can cover more range, just as your effort in GPIM https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-02.
I think GPIM is a real generic model. Actually, it is not limited in network area.  I didn’t find any specific network abstraction in it.
I wish GPIM would have tremendous progress than RFC3460. But I think we still need concrete network abstraction for Intent NBI.

Yinben

发件人: John Strassner [mailto:[email-masked]]
发送时间: 2015年7月17日 7:47
收件人: Xiayinben
抄送: Tina TSOU; Scott O. Bradner; Susan Hares; [email-masked]; [email-masked]
主题: Re: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

#2 TARGETS OF POLICY.

John

On Wed, Jul 15, 2015 at 6:38 PM, Xiayinben <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tina and all,

Best regards,
Yinben

Dear all,

Thank you,
Tina

Dear Scott and Sue,

Thank you,
Tina

Dear all,

----------

-----------

Meeting password:       2015

Join by phone

1-877-668-4493<tel:1-877-668-4493> Call-in toll free number (US/Canada)

1-650-479-3208<tel:1-650-479-3208> Call-in toll number (US/Canada)

Access code: 646 022 302

Thank you,

Dan & Tina

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 20 Jul 2015 09:22:48 +0000

Hi Yinben,

The reason I brought up the complexity in previous network managed object specifications is that I don't understand how your three simple abstractions (node, link, and flow) can be used to manage even simple concepts, like a VPN. Look at the complexity in CTPs and PTPs for example. Look how G.805 and G.809 conflict with each other. I simply don't see how you can hide all of the semantics with these concepts by just saying "I have a link" or "I have a node". What I see happening is that people will subclass your three basic classes (which will ruin interoperability), not use them because they can't find what they want (which ruins the effort), or you will be forced to add a LOT of properties to these three base objects. This last approach violates good OO design practice. Instead, I recommend that you have a more robust set of classes and use metadata to augment your base classes with semantics. There are many different OO patterns that you could use for this purpose.

You are correct - GPIM is ONLY about abstracting policy. We specifically avoided defining models for generic resources and services - those are not in the SUPA charter, and we would much rather use the work of other WGs. That's why I continue to bug you about your network model. :-)

Finally, work has started on the SUPA data models. Stay tuned.

regards,
John

John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

From: Ibnemo [mailto:[email-masked]] On Behalf Of Xiayinben
Sent: Sunday, July 19, 2015 7:09 PM
To: John Strassner
Cc: [email-masked]; [email-masked]; Susan Hares; Scott O. Bradner
Subject: [Ibnemo] 答复: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Hi John,

Yinben

#2 TARGETS OF POLICY.

John

Best regards,
Yinben

Dear all,

Thank you,
Tina

Dear Scott and Sue,

Thank you,
Tina

Dear all,

----------

-----------

Meeting password:       2015

Join by phone

Access code: 646 022 302

Thank you,

Dan & Tina

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 20 Jul 2015 12:47:50 +0000

Sue:
> The premise of Nemo is still the 80/20 rule – of trying to provide
> a simple model for 80% of the application with 20% of the
> commands.
<jcs>
I understand, but what does this have to do with the previous email?
</jcs>
> We posit two points:
<jcs>
I understand, but what does this have to do with the previous email?
That email had 4 points:
    1) flatter, simpler object model
    2) targets of policy
    3) NEMO does not define a policy model
    4) NEMO does not support ECA (and a larger issue, why is NEMO's
         declarative language implemented using imperative controls)
</jcs>
> In order to confirm our assumptions, we have proposed to prove
> this for specific use cases (see hares-.   This work includes checks
> on the user’s range of inputs, the expected output, and the
> prototype IBNemo code, and looks at the SUPA intent policy.
> The user’s input includes:  use cases and potential intent policy.
 <jcs>
SUPA intent policy is either propositional logic or first order logic.
NEMO intent policy is condition-action. This aren't compatible
in their native forms.
</jcs>
> What’s the benefit for IB-NEMO for SUPA’s work?   SUPA’s
> defining generic policy information models for ECA and Intent.
> While we have many examples of ECA policy over the last 30
> years in IETF, we do not have many examples of Intent policy.
> IB-Nemo will benefit from SUPA’s definition and design work.
> One thing that would be useful, is to post how SUPA’s model
> can guide IB-Nemo’s user policy or IB-Nemo’s translation of
> user policy into network-wide policy in the network
> management system.
<jcs>
That's nice to hear. We could of course "short-circuit" the ECA
policy rule to be a simpler CA policy rule. Constraints would be
handled in metadata, so this may be a problem for NEMO (I
don't see metadata in the NEMO model).

However, as stated above, our definitions of intent are very
different. So I'm not sure how this helps NEMO.
</jcs>
John

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, July 16, 2015 4:47 PM
To: Xiayinben
Cc: [email-masked]; [email-masked]; Susan Hares; Scott O. Bradner; Tina TSOU
Subject: Re: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

#2 TARGETS OF POLICY.

John

Best regards,
Yinben

Dear all,

Thank you,
Tina

Dear Scott and Sue,

Thank you,
Tina

Dear all,

----------

-----------

Meeting password:       2015

Join by phone

Access code: 646 022 302

Thank you,

Dan & Tina

--
regards,
John

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Jul 2015 10:29:29 -0400

John: 

Our emails are Ships in the Night (SINs) which are on different topics and different focuses.   To unwind these on a public mail list would create more SINs (ships in the Night) – so respectful I will decline to continue the miscommunication. 

Se 

From: Ibnemo [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Monday, July 20, 2015 8:48 AM
To: John Strassner; Susan Hares
Cc: [email-masked]; [email-masked]; Susan Hares; Scott O. Bradner
Subject: Re: [Ibnemo] [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

<jcs>

<jcs>

 <jcs>

<jcs>

John

#2 TARGETS OF POLICY.

 

John

Hi Tina and all,

Best regards,

Yinben 

Dear all,

 

Thank you,

Tina

Dear Scott and Sue,

 

Thank you,

Tina

Dear all,

 
----------

 
-----------

Join by phone

 

Thank you,
Dan & Tina 

-- 

regards,

John

---

From: Xiayinben <[email-masked]>
Date: Wed, 22 Jul 2015 00:54:26 +0000

Hi John,

Thanks for your question  for nemo's object model.

Yes, most of today's network model and properties/configuration are very complex,  is this not the problem what we want to solve?
let's think about why we have so complex configuration today. I can summary these configuration to two groups. One group is internal configuration to implement a network level function, e.g. configure PE,P to build a tunnel. Second group is for external features, e.g. config TE bandwidth. This group is really what customers care. Today, we have SDN and we can get network level function rather than device configuration one by one. So can we forget first group configuration? Do we need to define new network level objects and properties?

VPN is a specific network level service. SFC is a specific network level service. We can provide specific NBI for each specific network level service. But in future, we will have more and more network level service, such as new VN which can support any topology (VPN only supports fullmesh or hub-sopken topology). These network level service NBI will grow forever.
so I think Intent NBI should define network level mate objects rather than network level services. By using these mate objects, we can composite network level services. Neither VPN nor VN is combination of nodes and connections, so I think user can use node, connection to manage a simple VPN requirement. SFC is combination of nodes, connections and flows. So we summarize that network level mate objects are  three simple objects -node, connection and flow.

The properties of node, connection, flow may be lots. But those are cared and can be understood by users. What we discussed in ibnemo is to confirm those objects and its properties as much as possible. If we can cover 80% scenarios requirements, I think that will be useful.

Looking forward your comments.

Yinben

发件人: John Strassner
发送时间: 2015年7月20日 17:23
收件人: Xiayinben; John Strassner
抄送: [email-masked]; [email-masked]; Susan Hares; Scott O. Bradner
主题: RE: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Hi Yinben,

regards,
John

John Strassner, Ph.D.

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Ibnemo [mailto:[email-masked]] On Behalf Of Xiayinben
Sent: Sunday, July 19, 2015 7:09 PM
To: John Strassner
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Susan Hares; Scott O. Bradner
Subject: [Ibnemo] 答复: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Hi John,

Yinben

发件人: John Strassner [mailto:[email-masked]]
发送时间: 2015年7月17日 7:47
收件人: Xiayinben
抄送: Tina TSOU; Scott O. Bradner; Susan Hares; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

#2 TARGETS OF POLICY.

John

Best regards,
Yinben

Dear all,

Thank you,
Tina

Dear Scott and Sue,

Thank you,
Tina

Dear all,

----------

-----------

Meeting password:       2015

Join by phone

Access code: 646 022 302

Thank you,

Dan & Tina

--
regards,
John