Re: [Ibnemo] service based intent

[Zhoutianran <[e-mail]>]

Hi Sue,

You raised a very interesting topic.
In the NEMO implementation in ODL, we have some embedded types for Node and Connection.
For example, we will have point to point, point to multi point, and mesh connections with QoS and bandwidth properties.
But NEMO language and engine enable the dynamic import of new models.
The L3VPN type you shown in the case is a very good example. And I think many other models developed by IETF can also be used by NEMO language to express the service intent.
The NEMO language could be the glue to connect many models, and instantiate services, apply policies.

WRT your question on the model expression, whether to support hierarchy. It depend on the demand from use cases, as the intent is going to be simple can clear. I current implementation we do not support unfortunately, because that will increase the complexity.
But it's a very good discussion point that

1.  whether we really need this?

2.  Whether we can find a elegant way to express the hierarchy.

I really look forward to your comments and suggestions.

Thanks,
Tianran

From: Susan Hares [mailto:[e-mail]]
Sent: Wednesday, October 14, 2015 10:16 PM
To: [e-mail]
Cc: 'PEDRO ANDRES ARANDA GUTIERREZ'; Zhoutianran; 'Bert Wijnen (IETF)'
Subject: service based intent

Hi all:

I could really use some help this week on service-based intent as I'm trying to link service-based intent to the various service modes.  At IETF 93, we described the application expressing their service level needs at a service level by expressing the service needs, and letting the Intent based work negotiate the service.

I would like to explore how this works for five different types of services:  L3VPN, L2VPN, and EVPN, Cable-network services, B-2B. However, let me start with the L3VPN which has an IETF service level description (draft-ietf-l3sm-l3vpn-service-model-01) or
https://tools.ietf.org/pdf/draft-ietf-l3sm-l3vpn-service-model-01.pdf.   See the bottom of the page for the diagram of an L3VPN network.

L3SM
The L3VPN Service model limits is description to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364].  The L3SM model is input to the orchestration system shown in the diagram below this text.  The L3SM provides two top level information:


1)      vpn-svc [name]

2)      sites* [site-id]

vpn-svc [name] list  has the following components per service:

*        name, id, customer-name, topology id, cloud access, mpls, multicast tree
sites [id] list has the following components per site:

*        Site-id

*        Apply-template (yes/no)

*        site level parameters [start/stop service time, location, site diversity, availability, management, vpn policies, maximum number of routes,  management, VPN policies,  customer-info, security, physical attachment (aka bearer), service parameters (bandwidth in/out, QOS, traffic protection, mpls, protocols-run), site templates

An example from draft-ietf-l3sm-l3vpn-service-model-01 is:
<vpn-svc>
<name>ZKITYHJ054687</name>
<id>12456487</id>
<customer-name>CUSTOMER_1</customer-name>
<topology>any-to-any</topology>
<cloud-access>
<cloud-identifier>51</cloud-identifier>
<nat-enabled>true</nat-enabled>
<nat-address>1.1.1.1</nat-address>
</cloud-access>
</vpn-svc>

IB-Nemo Intent to Create this L3SM

Concept: IBNemo - would have the sites become nodes with specific EndNodes as the end nodes at each site.   The L3VPN would be created by the following statement:

Create Connection ZKITYHJ054687
           Type  L3SM
           EndNodes <site_1> <site_2> <site_3> ... <site_n>
           Property  id: 1245487; customer-name: Customer1; topology: any-to-any;
                           cloud-access-cloud-identifier: 51;
                           cloud-access-nat-enabled: true;
                           cloud-access-nat-address: 1.1.1.1;
                                mpls-signaling-type:  BGP;
                           multicast-tree: SSM;

The problem is that one would like hierarchy in the property so that one can give cloud access the following type of syntax:
           Create Property  cloud-access [id]  {
                   identifier: 51;
                 nat-enabled: true;
                 nat-address: 1.1.1.1;
          }

Is this possible with Nemo properties?

This would shorten the definition to:
           Create Connection ZKITYHJ054687
           Type  L3SM
           EndNodes <site_1> <site_2> <site_3> ... <site_n>
           Property  id: 1245487;
                           customer-name: Customer1;
                           topology: any-to-any;
                           cloud-access: 51;
                                mpls-signaling-type:  BGP;
                           multicast-tree: SSM;

Thank you.


Background info
------------------


The sites is a list of sites where each site has the following information:

*        Site-id

*        Apply-template (yes/no)

*        site level parameters:

o   Requested start/stop

o   Actual start/stop

o   Location: address, zip, city, country code,

o   Site diversity - (type, site-group)

o   Availability (Availability type (service-type, access-type), Loadsharing: type)

o   Management: Type, transport, address

o   VPN policies

o   Maximum number of routes

o   Customer specified information

o   Security (apply template, authentication, encryption)

o   Attachment (apply template, bearer, ip-connection)

o   Service (apply template, Bandwidth In, Bandwith out, svc-mtu, QOS, traffic protection, mpls, multicast, prototype type)

o   Site-templates

ASCII diagram for L3VPN-SVC Model

L3VPN-SVC |
   MODEL  |
          |
     +------------------+         +-----+
     | Orchestration    | < --- > | OSS |
     +------------------+         +-----+
     |             |
+----------------+ |
| Config manager | |
+----------------+ |
|                  |
|     Netconf/CLI ...
|                  |
+------------------------------------------------+
Network
+++++++
+ AAA +
+++++++


+++++++ Bearer  ++++++++     ++++++++       +++++++
+ CEA + ------- + PE A +     + PE B + ----- + CEB +
+++++++ Cnct    ++++++++     ++++++++       +++++++
Site A                                Site B