Re: [Supa] draft-karagiannis-supra-problem-statement-05

[Georgios Karagiannis <[e-mail]>]

Dear Sue,

Thanks for your comments.

Not sure if I understand your argumentation. Based on the existing i2RS charter, i2RS is:

o) focusing on Interactions with the Routing Information Base (RIB), by allowing read
and write access to the RIB, but no direct access to the Forwarding  Information Base (FIB)

o)  i2RS is not focusing on encoding languages, or data models and it is

Please note however, that I agree with the situation that if i2RS will be re-chartered and  data models work will be in scope,
then the work on a data model of a protocol independent physical or network topology can be done in i2RS.

Please also note that the SUPA problem statement draft, already mentions:
"In particular, the network is first defined as a topology.
 Depending on IESG decisions, the YANG based data model required for
 the specification of the network topology can be selected to be
 either the output work of existing IETF WGs or a data model specified
   within SUPA WG."

Regarding the other two objectives, sorry but I cannot deduce from the i2RS charter that the i2RS WG will work on:



 o) network service data models that can be driven by network domain specific policy rules



o) network domain specific policy data models for managing the network service and mapping this service dynamically to the network topology and network resources

SUPA focuses in the two above listed items.

Best regards,
Georgios

From: Supa [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: 02 March 2015 16:09
To: [e-mail]
Cc: 'Jeffrey Haas'; [e-mail]; [e-mail]
Subject: [Supa] draft-karagiannis-supra-problem-statement-05

Georgios, Luis and Jean-Francois, Parviz:

Are you aware of the following drafts:

http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
http://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary/

If not, perhaps you should read these drafts.  If you are aware, I am not sure what is unique about SUPA problem statement.  This email details the overlap and the

Section 3: Use Cases
------------
The use cases suggested presented in the draft (Inter-Data Center use case, the China Telecom Datacenter Traffic Schedule use case, CERNET and Tsinghua University, and Harvard VPNs) all seem to be covered in the draft-ietf-i2rs-usecase-reqs-summary draft.  The advanced functions of the traffic engineering and optimized topologies functions of:


1)      Variable bandwidth requirements,

2)      Time of day,

3)      Inter Data Center connections

4)      Flexible VPNs (one of I2RS first use cases)

5)      Virtual Private Clouds

6)      QoS drafts

appear to be included.  If you feel some use case is not included, please send me email so that I can include this information into the draft-ietf-i2rs-usecase-reqs-summary draft.

Please note that the use cases within draft-ietf-i2rs-usecase-reqs-summary are all included because the WG found these use cases to be important.  The listing of "in-scope" or "out-of-scope" indicates the scope for the existing charter.   The work for the initial charter are likely to complete in the June-July timeframe.   These "out-of-scope" features will be considered for the I2RS charter.  The proposed changes to the charter to approve yang drafts will be announced to the WG within a few days.

I2RS provides dynamic models, monitoring, and management of L1, L2, L3, and Service topologies.  If SUPA is looking to provide the configuration base models for L1 and L2 Topologies, I believe these are being handled within TEAS or TRILL.  If you are looking for L3 Topologies, the protocol independent topologies policies and configuration yang models are already being defined in the n netmod or rtgwg.

Path Optimization is one of the key elements of the PCE working group.   The configuration for the path elements should fall under this category.

Section 3.5 - Conclusion on use cases
--------------------------
SUPA's problem statement claims the first use case is the inter-datacenter traffic management with:

1)      Automatic provisioning of site-to-site VPNs,

2)      IPSec

3)      MPLS L2VPN and L3 VPN tunnels

You will note that the RIB-Info draft contains the ability to dynamically configure L3 connectivity over the L2VPN, L3VPN, and other tunneling technology.   If you feel that the RIB-Info model should contain an IPSec tunnel, please provide the details to the I2RS list.

If you desire to create the MPLS-based L2VPN and L3VPN topologies which are specific to the protocol, the Routing ADs have indicated that the configuration work for this belongs within appropriate working group (BESS, MPLS or PALs).  I2RS supports the protocol independent topologies.

Section 4.0 - Three challenges
-----------
The three challenges of dynamic configuration SUPA for protocol independent work are being covered within I2RS:


1)      Support of a protocol independent service topology

2)      Support of a protocol independent physical or network topology

3)      Yang modeling based on policy rules

The policy rules are being worked in collaboration netmod and the routing
http://datatracker.ietf.org/wg/rtgwg/documents/

You state that "None of the IETF WGs focus on:

a)      Models of the network service and network resources required

By the network service to be correctly executed in the physical

And/or virtual topology?


b)      Models of policy rules for managing the network service and mapping services dynamically to the network topology and network resources including resources"

I2RS is working on the dynamic model of protocol independent topologies for these two items.
The routing working group is working on the configurations of policy and topologies for routing and forwarding linked to routing.  The SFC is considering the service chaining.  I do not see any gaps that must be filled by SUPA.  In fact, the draft

http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-network-topo/

The following draft provide SFC policy and a generic model
http://datatracker.ietf.org/doc/draft-hares-dunbar-i2rs-sfc-policy-im/

Upcoming drafts will  provide addition input on the service toipology.

draft-dong-i2rs-network-inventory-00
draft-dunbar-i2rs-sfc-discover-traffic-rules-00
draft-wang-i2rs-service-topo-sfc-dm-00

The security policy is being worked in the i2NSF BOF and the SACM working group.

Summary
----------------
I do not see where your SUPA problem statement has indicated anything new except the desire for the IP-SEC link in the I2RS RIB topology model.   There are a great number of misconceptions within the draft that I hope will be handled in a revised draft.

The I2RS WG has made repeated calls for input from operations and routing experts.  We continue to invite interested parties to join the design teams within I2RS looking at protocol independent topologies.

Sue Hares