The I2RS has held two interims during December to discuss use cases, yang
models for RIB and topology, and the I2RS requirements on protocol. These
minutes of these meetings are attached.
You can find slides and minutes for the December 11th, 2014 meeting at:
http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedings.html
You can find slides and minutes for the December 11th, 2014 meeting at:
http://www.ietf.org/proceedings/interim/2014/12/16/i2rs/proceedings.html
Please let us know if you have any questions we can answer regarding the
I2RS current status.
Sue Hares
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. I2RS interim meeting December 11, 2014. Chairs Sue Hares, Jeffrey Haas.
10:00-11:00 ET
Attendees:
Jeff, Sue, Alia
Amit Dass
Dhruv Dhoty
Hariharan Anathakakrishnan
Igneous Bagdonas
Lixing Wang
Juergen Schoenwaelder
Alexander Clemm
Cary FitzGerald
Dean Bogdanovich
Don Fedyk
Yael Frank
Zafar Ali
Status
=======
RIB model looking for design team members. Currently, Amit and Lixing.
Use case summary
==============
Dean: The main issue with the protocol selection was does I2rs want to talk
directly
to daemons or via configuration? Do we want to focus on managing primitives
such as routes,
interfaces, etc. or do we want to manage more complex objects such as VPNs
(l3vpn, l2vpn, etc.)
If we can figure out what we want to do, it will make selecting protocol
behaviors a bit easier.
Maybe even outside of the IETF since there already exist some solutions.
What do we want to enable through the agent? E.g. Apache Thrift is an
interesting protocol
if we are dealing with primitives.
Sue: Use cases have both. E.g. virtual topology. Can these be done with just
primitives?
One option is we can take a protocol selection that works for just the
primitives, but we know
that BGP is something that people want to do and BGP cannot be solved with just
primitives.
[slide Virtual topology cases]
25 reqs. that are in-charter.
[slide Discussion questions]
Is it okay to just use primitives or do we need complex objects?
Dean: If we do not want to support bgp vpns, only need primitives.
Ignas: One of the important thing is transactions. If we have both, there is a
lot of flexibility.
If transactions are not in protocol level but are in client agent interaction
or some other entity,
then we have to worry about deterministic issues.
Jeff: Speed may require two distinct mechanisms.
Ignas: Speed? Possible. Depends on use case. Maybe makes sense.
Alia: In architecture, we do not have the idea of transactions. You may have
multiple
operations in single exchange with agent. Trying to add transaction complexity
will rat-hole us.
The concept of going to two mechanisms if the more complex use cases sounds
much better than trying
to push more complexity into the simpler use cases.
Jeff: Getting state out of the system is also important.
Dean: This might push us into duplicating cases already elsewhere? If you can
already do complex stuff
via configuration - e.g. l3vpn - many components, each particular daemon has
work to do.
If we can do it using primitives as well, but exposing those interfaces adds
complexity.
Know from two vendors that we have different approaches; this would lead to
vendor specific issues.
Sue: Your suggestion is we go through config process for everything or complex?
Dean: Primitives should go through daemons - [it is] faster. But then you limit
flexibility.
Complex always should go through config; already a solved problem. What is
open? Do we want to have
two different ways to do this?
Jeff: Simple, complex, issues may have protocol impacts. See discussion about
netconf vs. restconf.
Sue: Dean, you know about this in thrift?
Dean: Yes, have done some implementation.
Sue: We should split this into simple or complex. Next week, let discuss
having the protocol split-up
between complex and simple.
Dean: Iâve already done that split up, can send to list.
Sue: Want to focus on protocol independent items and topology. Alexander,
could you do the analysis
on your topology items?
Alexander: Ok I can present that.
Jeff: IETF session broke things down into interactions with config state vs.
i2rs injected state.
This discussion clarified we need to further break this down to simple vs.
complex.
Rib Info Modelsâ¦
[slides]
Nitin and Sriganesh are in Asia and donât think they can present. Theyâll
talk info model next week.
RIB yang model
[technical issues with Amit and Lixing presentingâ¦]
Jeff: How to do the multiple encaps. Is this a good idea?
Amit: Good idea, best idea to date?
Jeff: Overlap with rtg-cfg?
Amit: Not yet.
Hari: I did some of this. Collaborating with Lada. Will work with Amit.
There is some confusion
about who is the derived model of whom.
Dean: Many discussions about rtg-cfg model. When we started modeling other
protocols such as ospf,
we realized we could not do that work yet due to inconsistencies in rtg-cfg.
IMO, should be used
as base for all rtg-cfg models.
Jeff: Motivation for asking is overlap with regard to complex config vs.
primitives.
Hari: Should be complementing?
Sue: For next week, figure out how this relates to rtg-cfg.
Amit will come back with that information to the next interim.
Sue: letâs talk about this on list. Can you drive it Dean, Amit, Lixing?
Alex, for your model?
Jeff: Juergen general recursion for 1.1, 2.0?
Juergen: 1.1, no. 2.0 no clue.
Jeff: Raise on netmod mailing list?
Juergen: yes.
Jeff: Will raise on netmod.
EOF.
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
