Minutes for I2RS at interim-2014-i2rs-3
minutes-interim-2014-i2rs-3-1

I2RS interim, December 16, 2014.
10:00-11:40 ET

Attendees:
Hariharan Ananthakrishnan
Alia Atlas
Ignas Bagdonas
Nitin Bahadur
Lou Berger
Andy Bierman
Deborah Brungard
Alexander Clemm
Amit Dass
Dhruv Dhody
Jie Dong
Jan Medved
Jie Dong
Don Fedyk
Cary FitzGarald
Jeff Haas
Joel Halpern
Susan Hares
Ace Linden
Xufeng Liu
Jan Medved
Dan Romascanu
Juërgen Schönwälder
Himanshu Shah
Robert Varga
Lixing Wang
Michael Wang
Kent Watsen
Qin (Bill) Wu

Agenda
 Discussion on I2RS RIB Info Drafts [10:00 - 10:30 (zctual)] discussing:

1) Interaction between RIB Yang Model and draft-ietf-netmod-routing-cfg
2) Nexthop structures proposed in RIB Info Model 
[draft-ietf-i2rs-rib-info-model-04]

 Discussion of I2RS topology drafts [10:30 - 11:15]
  Overview and PBR {Sue Hares] [10:30 - 10:35]
  Yang Model for Network Topologies:  [Alexander Clemm] [10:35-10:45]
   draft-clemm-i2rs-yang-network-topo-01.txt
   draft-clemm-i2rs-yang-l3-topo

  Yang Model for L2 Topologies [Jie Dong]  [10:45 - 10:50]
    draft-dong-i2rs-yang-l2-network-topology

  Yang Model for Service Topologies [Qin Wu/Sue Hares] [10:50 - 11:00]
        http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/
   Discussion on topology drafts [10:35 - 10:45]

Protocol Discussion: [11:05 - 11:30]
1) Simple protocol option -  [Dean Bogdanovic]
2) Complex Protocol option - [Sue Hares]
3) pub-sub option [Alexander Clemm, Eric Voit]

==================
I2RS Adoption calls in December-January
I2RS will make an adoption call for RIB Yang/IM model after 12/16/2014 meeting.

Topics for 1/8/2015 and 1/23/2015 I2RS interim:
  1) Protocol Requirements for I2RS
  2) Topology drafts
  3) RIB Info drafts.

1) Document status:
Traceability draft has been adopted.
We dovetail our Yang modules with netconf and netmod.

====
2) Rib Info Yang model - Amit
[slides]
High level differences.
What are unique for i2rs?
I2RS is not covering the default rib model, compared to the netmod-cfg they do.
Using capabilities for tunnel encap types.
Propose add RPC from agent to client for route changes

Q: Juergen - why do we need rpc vs. notification?
Lixing: Example from BGP use case. …
Sue: This is for pub-sub, for retrieving history. From BGP use cases.

Jan: Do we need both info and data model now?
Sue: Alia says one draft.
Alia: That’s up to WG.  IM could proceed separately from DM since we’re not yet
rechartered for DM.

Jeff: Notification in I2RS. Does it also belong in netmod-cfg?
Amit: They should align. Sooner or later, we should come back and revisit it.
Alia: Amit and Lixing, very useful comparison vs. netmod rtg-cfg model. Thanks
for doing it. There’s a recent draft by Eric et al. and motivations for
pub-sub. Does it describe the rib model requirements?  Useful for i2rs to
discuss and netconf to review. Sue: See end presentation.

Nitin: Lots of questions raised. Is there a design team to resolve this?
Sue: Yes. We are taking volunteers for that team.
Nitin: Feel free to add me to it.
=====
3) Protocol Independent (Topology) Data Models - Sue
[slides]

3.1 Contrast topology dependent vs. independent.
PBR - Sits underneath the rib list, above the BNP.
Default RIB? PBR needs a default RIB for failover.
We are only proposing groups, rules.
------

3.2 Network topology Models - Alex Clemm
[slides]

Represents both horizontal and vertical layering

Lou B: Will you be in Thursday’s TEAS interim?
Alex: Yes.
Lou: Will defer. Grappling with issue of control plane topo vs. data plane
topology.  L3 IGPs they’re the same.  SDN, TE - they’re not necessarily the
same. Sue: PBR is a forwarding data plane focus. Qin will cover service
topology and Jie will cover Layer 2.  Many people will join you on Thursday.
-------
3.3 Yang data model for L2 topology - Jie Dong
[slides]

Jeff: Your model includes layer 2 physical info (vlan etc.) Does this belong in
our I2RS stuff? Alex’s draft lets you look between layers. Do we want this
level of detail in our model? Jie: Topo use case draft suggests we want to
gather the sum of the info from across the network.  What about layer 3/2/1?
Agree it needs discussion. Alex: Reasonable to do this.  Fine line between
abstraction model vs. other info, but not specific to topology.  Discuss on
case by case basis. If not tied to topology properties, should go to inventory.
Jie: Agreed. Sue: As Lou put it we have forwarding layer at l2 and control
plane at l2.  Alex, when you speak at abstract, which do you mean? Alex: Both. 
Even with service. Jeff: If we allow write, then the l2 config details matter.
Sue: Need active discussions on mail list. Tie into use case.

3.4 Service Topology Info Model - Qin Wu and Sue Hares
[slides]

Joel: *Who* knows the info needed to populate this model? Service topology
needs to be more than just tunnels. Sue: Abstract topology to lay on top of
network topology.  We’re describing this using UML. Joel: Starting to cover my
questions. Let’s keep going.

Lou: I think you made an important clarification. You mean TEAS requests to
I2RS.

Juergen: Concerned with restconf extensions and netconf extensions being called
out in UML. They should work in both. Sue: Thanks for correction, will fix in
next rev.

[slides]
Sue: Note how this ties back to Alex’s model.  Additional questions?

Lou: Document has TE data. This doesn’t get covered in these slides. Is that
still there? Sue: We had removed it. Expect to harmonize with Alex. Lou: Usage
of TE is not the normal use of it. Perhaps better term, like NAT load balancer,
etc.
     TED is different than normal usage of TED.
Sue: I think you’re correct.  We’ll update it, happy to take further feedback.

Don Fedyk: There is a lot more commonality in models in layer 3 models and
others. They could be harmonize a bit more. Jeff: What is the additional
harmonization My point was the Yang Model for L3 (as presented) seemed to
outline L3, Service and Optical and missed L2 totally.  (Not saying this is one
document but one architecture as presented). Then the L2 Presentation had some
L2 but missed several L2 capabilities. (VPLS, EVPN, VXLAN, PBB etc.) If you
look at this more generically each layer (l3,l2,l1) has: Data path,
Tunneling/Multiplexor/Virtual network, Topology, Topology data base, TE
extensions, Control Plane.  Each layer can and may use IS-IS or OSPF (and even
BGP) for some address distribution VPN information, connection coordination, TE
information, within the context of an Instance/VPN. Each layer can and may
offer a service, p2p, p2mp, mp2mp,(some type of persistent connection or set of
connections that may have their own resiliency mechanisms) at the layer or up
to a higher layer. Layers can be skipped and upper layers may be unaware of
lower layers. Lou Berger (from email response): My comment on control plane vs
data plane is very much in line with this comment.  And Don has begun some of
the discussion I was hoping to talk a bit more about in Thursday's TEAS
interim. (At least the TE aspects, as well as the possible formal
representation of control plane separately from data plane.)

——

Subscribing to datastore push updates - Alex Clemm
[slides]
XXX - transport and subscription decoupling

—

Simple vs. Complex I2RS - Dean Bogdanovich and Sue (via mailing list)
[slides]

Joel: This was discussed in WG. Defining granularity at which we conflict
should be in model.  Not sure what we’re discussing here.
Sue: Trying to come to some conclusion about ephemeral database from ietf-91.
Dean Bogdanovic thought there might be a different way to look at it.
Joel: I don’t think these things are really primitives. We’re only interacting
with some properties of the interface.  Same for route - only changing some
property. Jeff: Example of route, ownership is internal. Joel: Correct myself
from route vs. route-table. Route-table handles that arbitration. Jeff: Russ
White basically says just interact with routing table, it is much simpler.
Joel: Have discussed with Russ - who does not believe we have covered the scope
properly. Sue: Agree that things are complex, like next hops, recursive
nexthops.  Let us have more of this discussion on the mail list. RFC 6095 may
help here, per netconf folk. Don: Distinction is based on ability override
something in config vs. the ownership of that thing.  Objects that are simple
can be easily made to override some properties.  Ownership is still in config.
Only need this relationship if config is involved. Jeff: Had presented this
override picture at last ietf. Covered by option 4 “panes of glass model”. Sue:
need to continue this on mailing list.  Put more questions out on list.  Need
to pick this up for Jan 8 meeting.  We had hoped this discussin would clarify
things, but we need to go a few more rounds.