Welcome to Etherpad!

This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!

Get involved with Etherpad at http://etherpad.org

2)Protocol Requirements [Jeff Haas] Discussion [9:05-9:15]  
 
http://datatracker.ietf.org/doc/draft-haas-i2rs-netmody-netconf-requirements/
 
Todo list for I2RS group. 
Long term goal is to have individual drafts covering each of the items. 
 
 
http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/
Subscriptions and notifications, etc.
The broader audience is the IETF. 
 
Ephemeral state: sticky point. Not sure what we want to do. Now we have the data model for this. 

Need to map Transactions to NETCONF/RESTCONF

Future steps: need NETCONF to help how to move forward on the ephemeral state work item. NETCONF WG needs more clear requirement from I2RS. 

Sue: this is what we need design team to clarify the requirement. Please volunteer if you are interested. 


 http://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/

• 
  
• Explicitly called out the role of load balanceing, protection and replication. 
• Primary backup based on protection levels. Multiple levels. 
• Added explanation 
• 
  
• A few more topics under discussion: 
• Add nexthop in another routing-instance.
• IPSec tunnel encapsulation for outgoing packets.
• 
  

• Jeff: We've been asked about what the relationship of the i2rs rib model is to the netmod rtg-cfg module.
• Sriganesh: That's in the data model.
• 
  
• 
  

Anoop: what is the use case for next hop in another routing instance.
[answer] 
Linda Dunbar: You have ipsec tunnel, would have other types, such as vxlan?
Sue: vxlan is already there.

 http://datatracker.ietf.org/doc/draft-wang-i2rs-rib-data-model/
 Presented by Hariharan from Packet Design

•  Totally align will the informational model
• RIB capabilities: Next hop capability, nexthip tunnel 
• 
  
• Nexthop recursion: 

Linda Dunbar: The recursion - when do you use that?
Hariharan: Route resolution is an example. Nexthop may resolve to a BGP route may resolve to an IGP route.
Linda: So, like IGP or another routing table?
Hariharan: It's how it resolves, e.g. direct.

Jeff: We've been asked how does this compare to the rtg-cfg module?
    
Sue: Lada volunteered to help with this check.

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

• Sue summarized for Joe because Joe is not here. 
• Additional reviews are welcome. Reviews from NETCONF folks. 
• 
  
• If you have questions, please send to the list. 
• 
  

Requirements for Subscriptions to YANG datastores: 
    by Eric Voit
    
    Looking for requiremnet that is way beyond IETF. 
    Considering more than 100 YANG model 
    
    Set of requirements that are common 
    
    Subscription QoS Parameters:
        Liveliness
        dampening
        reliability
        coherence
        presentation
        deadline
        push latency
        
      Periodic Filtering: send update if ...
      Make sure not excluding more complex filter that may be needed in the future
      
      On-change Filtering: easy to say route is changed, but hard to say the filter has been changed. 
      make sure not preclude 
      
      Added Assurance
      

• No questions at the end. 
• 
  

-----
Topology Model Draft Series
-----
draft-clemm-i2rs-yang-network-topo/
draft-clemm-i2rs-yang-l3-topo

• BGP model will augment what BGP done by other group. 
• 
  
• Only some minor changes since the -02 version. 
• 
  
• Overall data model architecture: 
• 
  
• Discussion: 
• Generic, optional features.
• Topology specifies; augment separately
• 
  
• Linda Dunbar: I love this draft - really good work.  Love the way the layers are defined.  In the L2, L3, service draft: L3VPN is a service, and then you have another service topology.  
• Alex: Separate service topology draft.  When you have a new type of topology, you augment that draft.  additional property go there.  When you have different types of services, you can recurse in the model.  E.g. how ISIS is implemented in the model via augmentation for the service specific properties.  For the layering relationships, that is provided by the basic model.
• Linda: Hypothetically, could hae a cdn service on top?
• Alex: Yes.
• 
  
• Juergen: Why is this two modules rather than one?
• Alex: In some circumstances you'd need the inventory of the nodes in the network to keep it separate.
• Juergen: Consider tradeoffs of an expanded namespace.  
• 
  
• Lou Berger: [data model architecture slide] How do you see TE toplogy fitting into this?  You don't mention it in your call, only vaguely referred to in the draft.
• Alex; 
• Lou: Playing Jeff in TEAS - how that model fits into here?
• Sue: Initial intent was to augment that each layer augmented each other, but wanted to follow TE WG.
• Lou: You answered where it fits in.  TEAS will let authors figure out where it fits in.
• Sue: Reporting what we thought we heard from the design team.
• Lou: Goal is to align models.
• ZuFeng Liu (Ericsson): TE will be dervied from base topology.
• 
  
• Sue: this is our next journey on topology to include TE work. 
• 
  
• Georgios Karagiannis: 
• Sue: it is protocol independent model. We give an initial service model. The service model needs more help. 
• 
  
• Georgios Karagiannis: CDN service model hasn't been included. 
• Sue: currently it hasn't covered the CDN yet, more help is needed. 
• 
  
• Himanshu Shah: there are some service models done by L2VPN, L3VPN, I don't know how this overlap with other groups
• 
  
• Sue: I2RS only provides the service models on top of what other groups have done. I think this draft is at its early stage. 
• 
  
• Jeff: read the charter: injection & not considered by the group. May not be the job to alter the topology. For CDN, we might have overview of the topology, provide the framework for other groups to work on. We will work with other groups to find out where that work should happen.  Our ADs have told us that we may do the work where it makes sense when it is bigger.
• 
  
• Sriganesh Kini [Ericsson]: it is more like IP connectiviity topology. May be reconsidering the naming: E.g. IP connectivity topology instead of L3
• 
  
• 
  
• -----
• 
  
• TE Topology - Yang Model (draft-liu-teas-yang-te-topo), Presented by Pavan Beeram
• 
  
• No questions asked. 
• 
  
• draft-zhang-i2rs-l1-topo-yang-model Presented by Xian Zheng
• focused on L1, protocol independent
• 
  
• L1 Topo is a Tree structure
• 
  
• Question: where to submit this draft? 
• 
  
• Lou Berger:the details are important. Can't see what is L1 specific than TE. Happy to hear that you already see some issues. What you have here is close with what TEAS. should bring it up in TEAS. 
• TEAS will have specific data plane technology. expect to be done by MPLS, or other gorup
• 
  
• Sue: what is the value that I2RS can add. 
• 
  
• Lou: What presented here is the augmentation on top of TE
• 
  

draft-dong-i2rs-l2-network-topology  by Jie Dong

• 
  
• In incorporate different L2 technologies: VLAN, QinQ, PBB, TRILL, VPLS/EVPN, VxLAN, ...
• 
  
• To describe the encapsulation type as L2 termination point. 
• 
  
• Q: how to represent tunnels in L2 topology model
• 
  

Himanshu Shah: All those work are happening in other groups. The chairs need to monitor the work, make sure there are no conflict. 

Sue: I2RS provides dynamic model that can be alligned with all other groups

Alex Clemm: if you have some specific topologies, bring it up and make them aligned. 

Himanshu: we just started the L2VPN topology design team. Hope you can participate as well

Jie: We will participate


Sriganesh Kini: [Incorporate Different L2 Technologies slide] What do you want to achieve with this topology 

Jie: We just want to explain the topology

Kini: Not sure what this middle box is doing?

Jie: just want to descripbe the L2 connectivites that can be used by other L2 services. 


[confusion - will clarify after session]


Mehmet Toy (Comcast): This is a good start. This matches to MEF L2 services. Suggest you look in MEF and take the work from there. 



Don Fedyk: Like to see the same terminology used among different layers topology. 

Sue: Yes. they should be consistent. 

Dean Bogdanovic: Trying to find out use for all topology models that are presented from the i2rs perspective.  Why do we need all of these models? Reduce the number of them and put them together in a more meaningful way. Not sure of the value of each one.


Sue: Go back to our use case requirements and analyze it from that perspective.

draft-wang-i2rs-yang-sff-dm by Michael (Zitao) Wang

Sue: the design team concerned more of this Service Topology. We did this as a general service topology. 

Joel Halpern: There is already a yang model for service function forwarders, in progress in SFC WG.  What is the relationship of this model and that one?

Sue:  The authors have looked at the SFC IM and DM. will align. I2RS use cases were not in the penno(?) draft.  

Joel Halpern: We can't enumerate all the SFs. when you have "FW" types. not understanding two aspects of
Sue: Let's see what we can find inside the penno(?) draft to reference?
Joel Halpern: Can't figure out what you could be done inside of this structure?  I can understand wanting some sort of opaque type.
Sue: Next version should have that.
Linda: Made comment to authora about that this week.  Should not list SF types, maybe  capabilities, like if the SF supports the Service Chain Header?  They can be listed?

Diego Lopez Same direction as Joel is mentioning. Classification/capabilities we should be careful about this.  We don't allow a mechanism for some sort of free-form; otherwise we are pretending we are making a complete list of all important roles. 
Sue: This draft is targeted off of some I2RS submitted use cases.  Is there a way we can get those use cases reviewed by SFC? I'm sensing there's a whole lot of mstery between original work we got 2 years ago and now.
Diego Lopez: Can't speak for SFC, but we should look into that.
Sue: We should revisit.
Michael ?: ? 
Sue: Next step for the service area is to check our requirements and go forward.
----
Filte based RIBs - Sue Hares
Sue: We really appreciate all this feedback. Charter allows read topology, but not changing the topology. New addition to the charter is the "Filter-Based RIB"

Filter-Based RIB:
    draft-kini-i2rs-rb-fib-info-model presented by Sue. 
    Start this direction on the Filter - RIB
    
   Just started this work. Need more feedback if this is the right direction. 
   
    Dean Bogdanovic: routing group has a Filtering group
    Sue: yes, we will 
Dean: Will there be support to chain filters?
Sue: haven't decided.
Lind: Chaining filters would be good.

[slides form LInda dunbar lightning round that shows chaining]
Sue: Ther eis an identity chaining slide set.

Jeff: make sure the YANG model drafts are posted on RTG YANG coordination wiki, especially the ones that touch upon other WGs.