Minutes IETF97: i2nsf
minutes-97-i2nsf-01

Interface to Network Service Functions (I2NSF) Working Group

Charter: https://datatracker.ietf.org/wg/i2nsf/charter/
Mailing list: https://www.ietf.org/mailman/listinfo/i2nsf/

Jabber: i2nsf@jabber.ietf.org
IETF-97, Seoul

Monday Nov 14, 2016
15.50 - 17.50 (two hours)
Room: Park Ballroom 1

Chairs:
Linda Dunbar linda.dunbar@huawei.com
Adrian Farrel adrian@olddog.co.uk

AD:
Kathleen Moriarty kathleen.moriarty.ietf@gmail.com

=======

1. Administrivia [5 minutes : 5/120]
Chairs
- Working Group status and progress on milestones

Linda: Please look at milestones in the slides and comment on list
       if you have any issues

2. Working Group Drafts status update [20 minutes:25/120]
draft-ietf-i2nsf-terminology-02
Sue Hares (5 minutes)
- Open issues
- Next steps and plans

* Capability interface is removed to accurately reflect the meaning
  of capability

draft-ietf-i2nsf-problem-and-use-cases-02
Sue Hares (5 minutes)
- Next steps and plans

* New use cases added by Rakesh (customer-facing interface related)
  and Paul (SDN related)

* Asking for comments and requesting WG LC

* Will incorporate the SDN sections from
  draft-jeong-i2nsf-sdn-security-services-02

draft-ietf-i2nsf-framework-04
Diego Lopez (5 minutes)
- Open issues
- Next steps and plans
Remote presentation working perfectly thanks to meetecho

* Next Steps in Editing are:
  o Incorporate parts from the drafts on gap analysis, attestation,
    requirements.
  o Prune and graph from other drafts
  o Clean up issues on 'developer' and 'vendor'

* Go for WG LC - should we stay informational?

draft-ietf-i2nsf-client-facing-interface-req-01
Rakesh Kumar (5 minutes)
- Changes and updates in this revision
- Remaining issues and next steps

* Change the name according to I2NSF terminology to customer(client)-
  facing interface req

* The draft is about policy constructed based on user oriented
  parameters, in order to be easier for end-user to express policy
  and independent on network topo and so on

* Use group style design, telemetry data collection, integration with
  extern systems (i.e., SIEM), ...

* Next steps:
   1. add examples for clarification
   2. expand more requirements by comments
   3. improvement based on comments
   4. ...

Sue: Should we include the concepts of requirements about expressing
     contract relation in the draft?
Rakesh: Yes good points
Sue: Naming of groups proved useful in hackathon
Sue: Would also like feedback from users

Rakesh: Yes need to hear from ops guys

3. I2NSF Hackathon report [10 minutes : 35/120]
Jaehoon Paul Jeong

Linda: Very impressed with hackthon. This hackathon attracted more than
       20 graduate students from local universities to hack the data
       models specified by I2NSF. It was a perfect example of how a
       hackathon team should work.
       Netconf/Restconf + Data Model was proved to be a good solution
       for security management by Hackthon.
       This kind of activity works for student: 25 first-time attenders
       for the IETF.
Kyle: Could you explain about the SFF forwarding block in your
      hackathon?
Paul: The SFF is implemented in two data models:
      draft-hyun-i2nsf-sfc-enabled-i2nsf-01
      draft-hyun-i2nsf-nsf-triggered-steering-01
Dan Romascanu: How many different code bases?
Paul: We used CONFD (Cisco) for netconf code for NETCONF. We coded the
      NSF portions in firewalls and in our own code. We integrated with
      web functions.
      We had multiple models and a registration service
      draft-hyun-i2nsf-registration-interface-im-00
      [No second set of code for NETCONF/RESTCONF] .

4. I2NSF Capability Informational Model [15 minutes : 50/120]
draft-xibassnez-i2nsf-capability

Frank: It is an update from our previous draft - so it is a mature I-D
       Three models:
       o General I2NSF capability information model for registration
         interface
       o NSF-facing interface policy infromation model
       o Customer-facting interface policy model
Eric Voit: On the ACL model for capability: compare and contrast with
           Netmod ACL draft
Frank: We need to work together to extend the ACL. It is a good
       question.
Sue: Next presentation is about the capability (data) model. What we
     did initially link this to the packet ECA model with the ACL model
     underneath.
     In the hackathon we saw that the existing model is fairly complex
     although has good coverage.
     We have taken a simpler model to see if it is implementable with
     functional value.
     Need to have this discussion.
Eric: There are capability models with pub/sub done in other working
      groups. We need to link this work to the data models in other
      working group, and not do duplication.
Sue: +1. We should refactor these data models to remove duplication.
     Now, having said this, we need to decide as a working group
     whether we need a simple model, a complete model, or to extend
     the ACL model. At first, we linked it to the I2RS packet ECA data
     model. However, for this experiment we changed to a simple model.
     We need feedback from the implementers and from operators on
     exactly what we have.

5. Client Facing Interface info/data models [20 minutes:70/120]
draft-kumar-i2nsf-client-facing-interface-im
Rakesh Kumar (10 minutes)

* Comments to the document: how to be aligned to "ECA" model, will add
  a section to describe
* Will add more to policy-rule to capture more requirements
* Welcome more comments and contribution to help us
* Next step: more work from all co-authors will be incorporated

Sue: Group-based policy is very important, need more consideration
Rakesh: Yes, we need have what administrators need to configure the
        boxes.
Eric Voit: I see functional capabilities being exposed. Are you going
           to expose the functionality so the person can configure?
Rakesh: First we are giving the capabilities. Next we are providing
        the ability to learn what is being configured, and then
        configure the information.
Eric Voit: [Shameless advertizing] The Yang subscription model will
           provide you the ability to expose the notification.

draft-kim-i2nsf-consumer-facing-interface-dm-00
Jinyong Tim Kim (10 minutes)

Adrian: Is it your intention to cover everything in Rakesh's
        information model?
Tim: ?????
Paul: We tried to include the general model, and to also have VoIP
      drafts (??????)

6. NSF Facing Interface info/data models [30 minutes :100/120]
draft-hares-i2nsf-capability-data-model-00
Sue Hares (10 minutes)

Kathleen: What about referring people to the RFC on Yang 1.1 just
          published?
Sue: This overwhelms people sometimes.
Kathleen: I thought it was easily read.
Sue: I was trying to be helpful and point people to specific sections
     in this work.
Jabber: Diego Lopez. Credit to Politiecnico di Torino for some of the
     work. I think that the previous draft proposes would be an ideal
     test for this capability interface. (Clarify he means the VoIP
     draft)
Sue: Yes. That's why we used it as a test case.

draft-kim-i2nsf-nsf-facing-interface-data-model-00
Jinyong Tim Kim (10 minutes)
draft-zhang-i2nsf-info-model-monitoring
Dacheng Zhang (10 minutes)

Sue: This is a draft where we should factor the existing work in
     NM/OPS area with the syslog, alarms, tracing, events, and
     others provided by the data models added by the I2RS
     functioinnality.
Eric: Do you consider one controller or multiple controller? Do you
      need to to expose what type of controller to find it out.
Frank: Currently, we don't consider it, we consider the controller as
       a logically one for NSF to send its monitoring data. But yes,
       it's a interesting work we should discuss further.
[Linda]: In the interest of time, we'll need to take this offline.

7. Other Drafts [20 minutes : 120/120]
Adrian: We have only a few minutes for this draft.
draft-jeong-i2nsf-sdn-security-services-05
Jaehoon Paul Jeong (7 minutes)
draft-hyun-i2nsf-nsf-triggered-steering-00
Sangwon Hyun (13 minutes)
draft-hyun-i2nsf-nsf-triggered-steering-00

Kyle Rose: Did you consider reclassificastion at the forwarder?
Sangwon: We need to reclassify at the network.
Kyle Rose: If does serve the functions in the SFC architecture?
           We are repeating the work here. The lessons should really be
           applied in the SFC WG.
Kathleen: It is nice to see implementations. I thought we might have
          the code implemented in CODE-Stand. I do really appreciate
          the amount of coding in this WG.
Ken: I agree the comment earlier. You are making a classification on
     the first packet. I think you do not need to have re-
     classification. I think that's why you comment this is dynamic,
     and SFC is static. However, if you go beyond the 2 SFF to 3 SFF.
     I think we should work out the more details. We should should
     talk.
Adrian: I would appreciate if you would send mail to the SFC working
        group regarding this information. I recommend that you send
        mail and point them at these drafts.

draft-hyun-i2nsf-registration-interface-00
Sangwon Hyun (13 minutes)

Paul: We are trying to prepare the work for the future.