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

["Susan Hares" <[e-mail]>]

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