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

["Jun Bi" <[e-mail]>]

Could SUPA be consider as a framework for two more controllers are involved,
e.g. two DDCs need to be coordinated or enforced a general policy.

 

One DDC may use I2RS, another may use sth other than I2RS. 

Then we have a World Language on policy and topology  (SUPA) to have them
work together

Then it would be quite different than I2RS WG.

 

Best Regards,

Jun

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Georgios Karagiannis
Sent: Friday, March 6, 2015 10:01 PM
To: Susan Hares; [e-mail]
Cc: 'Jeffrey Haas'; [e-mail]; [e-mail]
Subject: Re: [Supa] draft-karagiannis-supra-problem-statement-05

 

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] <mailto:[e-mail]> 
Cc: 'Jeffrey Haas'; [e-mail] <mailto:[e-mail]> ;
[e-mail] <mailto:[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