IETF 98 
I2RS meeting on 3/29/2017 at  [13:00-15:00 CDT} 

Russ: Meeting starting, this is the I2RS meeting WG meeting. :-) 
Sue: note well applies.  
 
0) Agenda Bashing [13:00-13:05]

Sue: Overview of the agenda.

1) Chair's slides [13:05-13:10] 
    Netmod (session 2)     Thursday pm
[No comments] 

2) Requirements Drafts [13:05-13:10]
   Secure Environment Requirement Update 
    (WG call or Drop)  - [Daniel Migault]
   https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/
        

Sue presenting. 
WGLC for this draft - should we go forward, or just let it sit, or abandon? There are comments from opsec that indicates this work may be useful. 

37 requirements, most of them are recommendations for implementors
There are 5 major requirements for inter-plane isolations


Taking hum on the room on whether this should rapidly go to the wglc?
Russ: Any hums? A couple. 
JMH: I could not parse the question. 
Sue: How many people think this dsort of information is uselfu and it shouldbe progerssed? A few. 
Sue: Who think this is not useful and should not be progressed? 
Room:  No hums. 
Sue: we will raise the question on the list to see how to move this forward. 

3) Protocol issues (New Work) - Where will the work be done? 
  a) Revised Datastore Model [Kent Watsen [13:15-13:30]   
   https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

Kent presenting Revised Datastores. 
Guidelines for defining Datastores: define name, define which YANG modules, define which subset of YANG modeled data applies, define a module for the dynamic data store

suggest I2RS should define the datastores needed, may be stack of data stores, like one for each user, 

[discussion]

Jeff Haas: A comment - id did with netmod on how they did it. Rather than asking i2rs to produce that model, it would be better to ask netmod to do that work as there is where the expertise lies. 
Kent: We could to that. 
Sue: I was told by Benoit - I2RS protocol work goes to netconf/reestconf, model work is in i2rs and netmod. 
Alia: That is traditionally has been the setup for many wgs. Doing a document here in i2rs is not in the charter - it can be revised, but it is important how it gets reviewed. 
Sue: If anyone is interested in settoing up thos model pelase come to me to talk. 
Kent: We likely need to sync with ADs - what we try to do in the netmod is to setup the infrastructure for such extensions that all the plubming is in the place. 
Alia: We can talk about the recharter. 
Kent: If these two WGs become too related the we can move to one. 

Kick Starting Capabilities for I2RS
YANG+Protocol Discussion: from 2 directions: current YANG + revised datastores; & I2RS requriement

  b) Yang model proposal [Sue Hares] [13:30-13:45]
    https://datatracker.ietf.org/doc/draft-hares-netmod-i2rs-yang/

Sue presenting on I2RS capabilities. 


Eric Voit: Based on earlier discusions - do you need subscription in order to find whether some data has changed? 
Sue: I think so. 
Eric: Is it there already?
Sue: No

there are a lot of how. anyone has opinion? 

[discussion]

Mehmet: It was discussed with Kent - it is not very clear where to put which models. I was unaware about the -hares-netconf-i2rs-yang draft. Is this the one that we discussed together with Kent? 
Sue: Those were kickstart ideas for netconf, restconfm and yang. Charter discussion yesterday. 
Mehmet: I support Kent on this. Write somethign generic and provide guidance how to use it. 
Sue: That soumnd good. 
Kent: Adding on dynamic datastores idea - if yang is used as amodellign language, when it comes to extension statements that are inside the business logic that is coded to support the dynamic datastores, as long as it is an extesnios tatement it is ignored by the clients that do not supoirt dynamic datastores. The vase protocol needs to be updates by means to access those dynamic datastores. When we talk anbout accessing the specific dynamic data store, it is specific to that datastore. There are cross-wg applicability aspects that need to be considered. Some of them are very dynamic. I wonder what is the best path
Sue:L We can start on the model, feed into the dynamic datastore. Tell us how to proceed. 
Sue: I need feedback on the need for validation on i2rs datastores? has anyone worked in that?
Sue: Some questions: 
    Sue: how many people are interested in helping with YANG model? No hands?  

no preference on which WG those work is done. 

[Sue presaenting Our Phase 1 slides] 


  c) NETCONF/RESTCONF Changes 
   https://datatracker.ietf.org/doc/draft-hares-netconf-i2rs-netconf/ 
   https://datatracker.ietf.org/doc/draft-hares-netconf-i2rs-restconf/ 

[no additional comments] 

   d) Other Protocols possible: CBOR/CoAP, gprc (CBOR/XML), Forces (Yang->LFB, ForCES) 

    https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/
    https://tools.ietf.org/html/rfc7252
   (CBOR does binary encodings of yang models and has open source implementations) 
   [see http://cbor.io/impls.html or  http://libcbor.org
    COAP does a GET, PUT, POST, DELETE functionality like RESTCONF)
   [http://coap.technology/impls.html or   https://sourceforge.net/projects/libcoap/) 

[no additional comments]


  d) Discussion [13:45-14:00] 
  •Should I2RS continue working on NETCONF/RESTCONF? 
  •Should I2RS work on additions to CBOR encoding in CoaP? 
  •Should I2RS work on XML (GET, PUT, POST, DELETE) in google protocol buffers?  
  •Should I2RS work on ForCES encoding of Yang? 
  
   If we say yes, we'll solicit volunteers for design teams (joint with Netconf) or 
   CORE, or rtgwg.  

[no additional comments] 


 3) Data models Updates [14:00-15:00] 
    Topology Model Update [Alex Clemm ] [14:00-14:15 ] 
    https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
    https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/

         
    FB-RIB Update  [Sue Hares ] [14:15-14:20 ] 
        https://datatracker.ietf.org/doc/draft-ietf-i2rs-fb-rib-data-model/
        https://datatracker.ietf.org/doc/draft-ietf-i2rs-pkt-eca-data-model/

Alex Clemm presenting. 

[discussion]

Sue: We would like to have sense of the room whether anyone has concern on this document? 
Room: No one raised a concern. 

Sue: Would ppeole hum if they agree with this aproach? Some. 
Sue: Anyone who disagrees? No nums. 
Sue: Alex, it seems that you have got yoru direction. We will bring this to the mailing list to verify. 

  4)  Proposed Data Models [14:20-14:50] 
       
    A) (Background on Fabric) Open Fabric [Russ White] [14:40-14:50] 
        https://datatracker.ietf.org/doc/draft-white-openfabric/

Sue presenting. 


[discussion]

Sue: Any of the netmod/netconf people would have any comments? 

Russ:  

This is the use case for next presentation. 

[discussion]

Russ: Is anyone awake? :-) Many hands. 

    a)  2 Data Models for Fabric Service in Data Center [Rong Gu]  [14:30-14:40] 
        YANG Data Model for Fabric Service delivery in Data Center Network
        https://datatracker.ietf.org/doc/draft-zhuang-i2rs-dc-fabric-service-model/
        A YANG Data Model for Fabric Topology in Data Center Network
        https://datatracker.ietf.org/doc/draft-zhuang-i2rs-yang-dc-fabric-network-topology/

Rong Gu presenting. 

[discussion]

Jeff Haas: The abstractions make sense. I havent reviewed the current verio of the model. Russ'ss presentation makes to think about the specific use case of the open fabric. As it is zero configuration, what you plug in into that fabric becomes more important. If you missed something there may be a larger impact. Noticing that a misconnection has happened would be of value. 

Russ White: We have that in mind in the context of the open fabric. 
Rong Gu: We use fabric model to define the topology. 
Jeff Haas: In the fabric where you have underlay and overlay models, it allows for the underlay model to be understood based on the provisioning/vabling. What thought have you given to your models to get that exposed in the model itself?
Rong Gu: The physical topology is the bottom one, and we abstract it into the fabric topology. The fabric can have a different encapsulation, we abstract in tinot the fabric topology that has attributes. 
Yan Zhuang: Underlay infrastriucture can be exposed to the overlays. In the fabric layer we .... Internal connections are exposed to the underlay topology, we care about the tconnections between the fabric element. 
Jeff Haas: In your example, the fabric layer says it is what it is expected to look like. Models do not necessary represent the actual real topilogy well. 
Yan Zhuang: At the moment we are not considering that. 
Sue: Any other questions? 

     
    b) Control-Plane and User-Plane separation BNG Info-Model 
         [Michael Wang] [14:50-15:00] 
     https://datatracker.ietf.org/doc/draft-wcg-i2rs-cu-separation-infor-model/
     


Rong Gu presenting. 


[discussion]

Wolfgang/DT: control interface is for user profile? 
Answer: correct. 
Wolfgang/DT: do you have centralized control plane? or distributed? 
Rong: we have centralized controller. 
Wolfgang/DT: then you have to know where users are
Rong: BNG user plane is connected with users. Control plane is centralized. 
Wolfgang/DT: you might need to use Radius to reach the users 

Sue: I believe this model is like the "Broker model". 

Wolfgang/DT: We have been looking into such inbterfaces. Is your control protocol looking into changing user priofiles? 
Rong: We have a centralized controller plane. The BNG has the functioin of the management of the service and the user plane. 
Wolfgang: If you have seceral controllers, you need to be aware of where the user is now. 
Rong: BNG user plane is connected with the user, and control plane is centralized. 
Wolfgang: Today we do it with radius CoA. You need used database for this. 
Rong: This is the initial idea, we can refine it later. 
Sue: Is this model the same as the one shown learlier? 

Sue: Any more comments?  Where would be the approapriate place for this work? 

  5) Milestone Discussion [14:50-15:00 
[no further comments] 

Sue: End of the agenda. 

 
JavaScript license information