Re: [I2nsf] draft-zhang-gap-analysis-00

Hi, Sue:

Sure. Hosnieh and I will include the work you mentioned into the new
version.

Thank you for the comments.

Dacheng

发件人:  Susan Hares <shares@ndzh.com>
日期:  2015年2月3日 星期二 下午6:15
至:  <i2nsf@ietf.org>
抄送:  <linda.dunbar@huawei.com>
主题:  [I2nsf] draft-zhang-gap-analysis-00

Hosnieh and Dacheng:

Do you have an update for the gap analysis for the I2NSF?  You did not
include the work in I2RS, rtgwg, and netmod/ netconf in your analysis.   It
would be good to update it to include these features

Just a few things to include to review for policy is the current

·         http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
<http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/>  - approved
ACL policy 

·         http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00
<http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00>    -
Operators model 

·         draft-yan-rtgwg-routing-policy-yang-00 – Proposed for routing
policy 
·         http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
<http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/>  - approved
ACL policy 
·         http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/
<http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/>  - an
I2RS policy (Sue’s personal draft) .

And there are probably others in the I2RS, RTWG, netmod, and netconf that I
have missed. 

I2RS has both a broker /proxy functionality it is architecture and approved
use cases for the firewall, DDoS/Anti-DoS, IDS/IPS policy.

I hope this helps you complete your gap analysis.

Sue Hares
------------------

Sections from the I2RS architecture:

I2RS architecture document(p. 11-12)   
An I2RS Client is not automatically trustworthy.  It has identity
information and applications using that I2RS Client should be aware  of the
scope limitations of that I2RS Client.  If the I2RS Client is
acting as a broker for multiple applications, managing the security,
authentication and authorization for that communication is out of scope;
nothing prevents I2RS and a separate authentication and
authorization channel from being used.  Regardless of mechanism, an  I2RS
Client that is acting as a broker is responsible for determining that
applications using it are trusted and permitted to make the
particular requests.

Use Case Document (search for the identifying strings)
o  Topo-REQ-06 (OC): I2RS should enable a orchestration manager
      attached to an I2RS client to communicate with I2RS agents into
      order to stitch together End-to-end services for network bandwidth
      optimization, load balancing, and Class-of-Service with point
      services (Firewall or NAT) within the end-to-end service).  The
      orchestration manager should also be able to immediately schedule
      any of these resources via the I2RS-Client I2RS agent exchange.
      (from section 3.4)

o SFC-Use-REQ02 (IC):Supported Service Types
      SHOULD include: NAT, IP Firewall, Load balancer, DPI, and others

o  L-Flow-REQ-06 (IC): Once a large flow has been detected, I2RS must
      be used to modify the forwarding tables in the router to:

      *  In the case of large flow load balancing, be able to
         redirecting the large flow to a particular member with the LAG
         or ECMP group and readjusting the weights of the other members
         to account for the large flow

      *  In the case of DDoS mitigation, the action involves rate
         limiting, remarking or potentially discarding the large flow in
         question
_______________________________________________ I2nsf mailing list
I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf