I2RS interim on 3/5/2015 MInutes


Attendees:

• Susan Hares 
• Jeffrey Haas
• Mach Chen
• Brad Dreisbach
• Dean Bogdanovic
• Hariharan Ananthakrishnan
• Benoit Claise
• Jie Dong
• Dhruv Dhody
• Linda Dunbar
• Amit Dass
• Alia Atlas
• Xufeng Liu
• Dan Romascanu
• Eric Voit
• Robert Varga
• Jan Medved
• Alexander Clemm
• Sriganesh Kini
• Cary FitzGerald
• Ignas Bagdonas
• Juergen Schönwälder
• Don Fedyk
• Tony Tkacik
• Xian Zhang
• Kausik Majumdar

-----
Minutes:

[Agenda Bashing]
none.

[Design Team introduction]
Protocol Independent Topologies.
Team decided to use draft-clemm-i2rs-yang-network-topo model.
Learning via Acee and OSPF yang draft, the topo draft needs to carefully align with config draft.
We need to also have the TEAS work aligned.  This impacts draft-wang-i2rs-service-topo-dm
Benoit has started the L3 service model draft.

In Clem draft, multi-layer.
RIB info model has been updated. Draft-wang-i2rs-rib-data-model aligned to rib-info model.

[Network Topology Models] - Presenting Alex Clemm
Important to represent horizontal and vertical layering.
Horizontal - connectivity.
Vertical - topology stacks, overlay/underlay relationships.
Original work included draft-liu-yang-abstract-te-topo.  TEAS group doing the basic TE topology for config and status. Need to align with TEAS.

Discussion: 

• question from Linda Dunbar: You have a list of nodes and termination points (ports). Why can't you have the links under the nodes?  Why are links in parallel with the nodes?
• Alex Clemm: Links are relationships between different nodes.  A link does not belong to one particular node.  It really relates two nodes.  May be different from the set of interfaces in the system.  Think of links as topologies in a graph sense.  A network view of the topology, not just the individual nodes view.  
• Linda: In that case, the topology should only consist of links.  Every link has a source and destination.  Every node is represented by link property.  Nodes and links are redundant.  Could have another property under topology that isn't nodes - could be underneat the source.
• Alex: That makes an interesting point.  The reason why we did that was for another reason.  We wanted to be able to anchor the links somewhere.  Secondly in network, nodes in a network may not be connected to anything, but are part of network inventory. If you only represented links, you'd lose that infomation.
• Linda: That would be under the inventory topology. A lot of duplicate information.
• Sue: Please defer rest of conversation to end?

[more slides] 

• Srigansh: Question on multiple underlay slides.  This seems to break the model of what a VPN is - whether it's L3 or optical.  This could be a VPN that is both.
• Alex: Perhaps a poorly chosen example. Point was you could represent multiople underlays and that you could do so.
• Jan: Should refer to latest version of draft.  See fig. 2&3 in that draft.
• Sriganesh: You can do this in the model?
• Jan: Yes, you can.  VPNs are service topologies.
• Sriganesh: Can go across multiple underlays?
• Jan: Model permits that - perhaps want to put some constraints on it.
• Alex: More specific models can constrain that.
• Sriganesh: Is there a way to speciffy those constraints in this model?
• Alex: In this model, we don't do that.
• Jan: In a particular service model, you'd give the constraint that only particular kinds of underlay could be used.  Could be done via augmenting the base model.

• Linda: [missing]
• Jan: Nodes may have multiple termination points.
• Linda: Trying to be hierarchically more clean.
• Alia: Confused. Link connected to 2 or more termination points on a node. Each node may have a large number of termination points. A large number of links.  Don't want to dup. large number of nodes under links.  In a graph, nodes and links are first class things.
• Jan: By having model structured this way, it's a good common base for inventory models.
• Linda: Under the nodes, many termination points.  256 ports. Each port is a termination point?  Ethernet may connect to multiple things.  Just an opinion.

[Yang data model for network inventory] Presented by Jie Dong
Discussion: 

• Dan Romascanu: RFC 6933, the entity mib.  Strong overlap in that mib and your draft along with the interface yang model.  Let's try not to recreate that work.
• Jeff: How do we avoid duplicating the work in the mib? yang translating mib?
• Dan: translation may be fine. need to look into details.
• Sue: Are there plans to do this translation?
• Dan: Don't know.  Juergen?
• Jeff: Indexing is appropriate in mib for original purpose, but not topology.
• Sriganesh: Question to chairs? Why is this under scope of i2rs?
• Sue: We need the information in the module to import similar to importing interfaces.  We are struggling with how we can move forward - import entity mib into yang?
• Benoit: Should I ask netmod who should do this? Wont be satsify the mapping issue.
• Jeff: Could start it. How do we drive mib translation work for reuse?
• Sue: Would be nice to ask netmod. Especially about indexing. Could use guidance.
• Benoit: Don't think people in netmod are working on this.
• Sriganesh: Inventory draft - a bit beyond what is needed for topology draft.  Need define minimal set of what topology model needs?
• Alex: Trying to talk about specific type of physical inventory. If you have specific needs in your network, this might be useful to help choose equipment.
• Sriganesh: We could do this multiple ways.  Entity mib. Or ask i2rs what are the underlying requirements. Then we could do the model for *that*.
• Jan: I'm supportive of this draft. What may need to be done for services or topologies, choose a base draft that might incoprorate entity mib.  Contents of draft may be too specific in base draft; augmentations may be appropriate.
• Sriganesh: The base model may be very minimal.
• Jan: Draft could be very simple, and include more complicated examples.
• Jie: Will see if we can re-use work from interface model.
• Benoit: RFC 7223 has lots of things we could re-use.
• Sue: Do you have all of the feedback you need for next steps?
• Jie: Have good comments.  Looking for contributors for next version for hierarchical ; base plus specific types (example augmentation). 

[Network topology model - layer 3] - Alex Clemm presenting.

• Mostly works by augmenting base topology model with layer 3 specific items.
• Benoit: See isis and ospf nodes.  Any tie-ins to isis/ospf yang models?
• Alex: Need to check that.
• Dean B: for ospf, 90% sure nothing has been done.
• Robert: l3 topo were suppoosed to be examples.  have not reached out to isis or ospf.
• Jeff: ospf model is different than isis. topo model is closer to isis. do we need to expose tie-ins?
• Robert: BGP-LS shows common topology 
• Jeff: I think that has a similar problem. Do we really need the deep tie-ins?
• Alex: Need to refresh the draft and look at those questions.
• Sue: Would also like to understand this in the context of IDR.

[Yang model for layer 1 network topology] - Presented by Xian Zhang

• Xian: Clients running on layer 1.  Exposing information there is useful.
• Jeff: Did you have any thoughts about how to correlate layer 1 models to things we'd want to use for other management?
• Sue: This is the abstract models. Looking at attachments.
• Dean B: With regards to layer 1. DWDM is being offered as a L1 service. I would include that.
• Jeff: Layer 1 goes further down in refinement. Where do we stop?

[Yang data model for l2 topology] - Presented by Jie Dong.

• Jeff: Where do tunnels get represented in the models?
• Alex/Jie: Will look into this.

• [Yang model for SFF service topology] - Presented by Susan Hares.
• Juergen: This stuff looks on track. Thanks.
• Dan Romascanu:In relationship with other topo models slide, is this a partially correct? Security services?
• Sue: SFF is a specific one.  If it's security, we haven't harmonized this with the i2nsf or sacm work.As we go up in the layers, more harmonization is needed. Lots of creative work needs to be done.Michael in design team needs some help.
• Kausik: I see in this topo diagram that there's a l3 topology. See vxlan tunneling could be represented.  Should there be another block representing all of the tunneling?
• Sue: Echoing some of jeff's questions. Representing tunnels as interfaces.  Alex/Jan?
• Alex: Wondering where we should capture this? Interface model? Part of l3 or l2?
• Robert: Tunneling - model the tunnels as overlay and point to the underlay.  Don't think it was separated into layers. Didn't analyze it l2 or l3.
• Alex: Agree. Tunnels would be links.
• Kausik: Could you please capture that?
• Alex: Want this to be elaborate it in the drafts?
• Kausik: Elaborate on all of the tunneling types.
• Jeff: Beware that link and port may be the types used for underlying implementation. If ietf has chosen a common modeling mechanism, we should go to that.
• Robert: ODL has a model for tunnels. I'll send along details from that.
• Sue: Send that to i2rs please?

[Rib info model summary of planned updates] - Presented by Sriganesh

• Kausik: Chain of nexthop - mostly for ecmp?
• Sriganesh: Tells you egress interface or encapsulation.
• Sue: ipsec - how to include? 
• Sriganesh: not a candidate for -06
• Sue: Understood.  There's a long path to figure out if it's reasonable or not.

• Jeff: For rib module, may have similar issues with tunnels. How do you model 
• Sue: Juerrgen - does interface already have this?
• Xufeng: Use interface
• Jeff: Again, issues with interface vs. port. Interface-id from if-table mib is helpful and works well for ingresses.  Some egresses get different mapping - port instead of interface.  No answers, just pointing out prior problems.
• Xufeng: In TE models, similar problems. interface module doesn't currently have "type".  
• Jurgen in chat: Interfaces are the generic concept, they've always been.

Sue: comment on the yang model for rib. 

•  Designed to an implementation of the rib model.  Design teams will work on harmonizing drafts.