Agenda: http://tools.ietf.org/agenda/87/agenda-87-status.html

Scribe: Carlos Pignataro

IETF87 -- Interface to the Routing System (Active WG) 

I2RS WG -- IETF 87, Berlin, Germany           
Thursday, August 1, 2013 from 1pm - 3pm           

Location: Potsdam 3           
WG info: current charter, status page
 Mailing List (archives)

Chairs:
Alia Atlas
Edward Crabbe

Meeting start at 1:05pm local time

Agenda:

Administrivia
(Chairs, 5')

• Ed: This is the new Note Well, please note it well...
• ... who is the Jabber scribe? It's Joe Clarke!
• Alia: thanks for Carlos for volunteering to scribe :-)
• Ed: Some ground rules:
  • If you go over time, I will cut you off
  • Please state your name before speaking at the mike.
• ... the big red exclamation point is where we are -- further along that I thought we would
• ... agenda bashing: there is one more at the end on the agenda online.
• ... not on the agenda today, there are two drafts, please check them and send comments.
  
  
  
  

Introduction, Discussion of interim results and current status
(Chairs, 10')

• Current  status: several new drafts, no expirations, no WG drafts, no WGLCs, no  new RFCs, we are doing really well <laughts in the room>
• Milestones, it's a copy.
• Interim  meeting report: Most of the draft authors managed to show up. It was  extremely productive and produced drafts. The notes are online from  Giles, really good notes as usual.
• and with that...
  
  
  
  

draft-atlas-i2rs-architecture-01
(J. Halpern, 15')

• Joel H: I'm Joel Harlpern. This is work a bunch of us did as a design team to propose an architecture for I2RS.
• We started with two drafts as starting material (Ward and Alia's drafts). 
• There was a lot here about architecture and a lot that we also took out -- we removed use cases.
• Keep it simple, clean, and make some choices. We need to make right choices, if wrong, tell us! We can make the change.
• We wrote proposals on controbersial issues which are our guess and we might be wrong. For example, we removed a bunch of parameters.
• One of the contentious issues was the issue of Mult-headed control. When discussed, a lot of people mean different things. For us: Can multiple devices write to the single piece of data. Our stance: if that happens, that's "an error".
• As we define the data model we need to define the atomicity. The core definition is that the same field cannot be written by two guys.
• Second: If it happens, we need to understand what to do. Would need to understand what to do.
• Corollary: we do not need to store state for everone elses's value. We do not store alternatives. Increases robustness and simplicity.
• Should I2RS worry about side effects? You turn off here, and something happens there. We have notifications, but we will not find side effects. Not part of the I2RS client requirement. Other thoughts?

Question:

• R, from BT: I can see the simplification. But if you have more applications we want to write to the same, we end up with an offbox arbitration who ends up being an NMS.
• Joel: Part of our thinking is that arbitration is more complex than priority. In I2RS we handle the error gracefully.
• R: Can you have something intermediate?
• Joel: I cannot stop you from doing it. But for us it's an error and you won't get a complex system.
• R: It's the ancient problem of how much rope you give...
• JOel: we won't have a lot of rope.
• Ed: In the interim, the issue of backend synchronization came up. These things need to be aware of each other. You can 1. have a broker, or 2. assume these know about each other and they will figure it out, and some subset decomposed in the boxes. The conclusion is that there was not a lot of utility for that case.

Joel continues with slides:

• Corollaries on persistence, starting and ending, because we want to keep it simple. People can make complicated scenarios. But the I2RS client doing its job covers 90% of the cases. I was exchanging a conversation with a person (forgot their name) talking about time based interactions. But the benefit of simplicitaion outweights the small gain in capability.
• Corrollary: If I2RS goes away, you go back to the config state.

Question:

• Wes G: On previous slide, can we clarify if "happens now" is immediately as sent versus schedule during the controller.
• Joel: I am not sure I follow, let me paraphrase: From the I2RS agent, when it's told to do something, it does it. It does not wait.
• Wes: We agree, but that's a real important clarification, no complexity during the client.
• Ed; How many of you read the draft?
• Joel: Wonderful
• Ed: I was going to say that's distressfully low.
• Ed: When we say "client", we mean "controller".

Joel continues with slides:

• The only addition is notifications for things being deleted and added, requested by Joel Clarke. No problem, we will add it.
• Transactions: Transaction integrity is *per message*. It's not across larger things. A message could be more than an operation. We have 3 modes of operation or behavious (perform all or none|until error|all). This is the proposal, and I hope we found the right balance.

Question:

• Someone: Can you clarify the difference between all or none, and all?
• Joel: all or none is classic SNMP, which is if "all or none" and one fails, then do not do any of them. If it is "all", then if 2 fails, I can still do 1, 3, and 4.
• The agent does not know, it from the I2RS client what it's requestion, in the message, which behavior.

Joel continues:

• The architecture draft does not go in "why we do this", use cases, or data models. Brief mentions of RIB, IGP, etc., is to provide context. If you think this is too much, say so on the list. I am one of those guys that prefer short comments.
• Joel: We had a call for adoption, we received comments, we will take care of them
• Ed: One chair is co-author, the other will run the IETF process.

Question:

• Lou B: Redundancy or fault tolerance?
• Joel: on the list
• Lou: To be added?
• Joel: I do not think there is a need to add it, let's discuss on the list.
• Thomas, from Orange: what about protocol?
• Joel: Given our charter, the protocol is outside the scope of this architecture. There are use cases which will fall out, won;t address that. If you have a topology abstractor, that's out of scope.
• Thomas: Interesting!
• Joel: I agree.
• Thomas: debatable.
• Lucy Young, from H: Controller can be redundant controller? 
• Joel: Writting data is not about authority, it is about practicality. Regarding redundancy I say it is out of scope because charter says I2RS agent talks to many I2RS clients.
• I am out of time.
  
  
  
  

draft-nitinb-i2rs-rib-info-model-01
(N. Bahadur, 15')

• I'd start by apologizing to co-authors, etc.. I have been sick and have not been able to create a collage of the great collaboration.
• We create a RIB model to program things on the router. It's not just a router or a switch. You can apply this to Hosts. 
• We said: 1. we should read data, 2. we should write data., 3. we should receive notifications.
• This is not a data model. That's another I-D, this is an info model.
• Read:
  • Routes, NHs, info about RIBs. There are some terminology issues in the draft.
  • Writting: NOT to the FIB, only to the RIB manager, who in term decides what goes in the FIB. For routes you can do MPLS routes. The draft tries to use the RIB manager but provide flexibility to the controller.
  • ...What happens when something programmed? You get 2 notifications: is it active? is it installed? Then with this the I2RS client can figure out if this is installed in the FIB without querying the router.
  • Aync notifications are very powerful. Notifications go up to the I2RS client, with "the route you programmed is/is not in the FIB".
• Nex few slides talk about how we model the RIB. The basic concept is the routing-instance. This is different than the draft published. I think this clears some of the terminology issues. From there we have three elements in the route.
• The IETF community needs to figure out what to anchor the routing-instance into. A device maybe?
• A route has 3 things: route-attributes, match, and nexthop-list.
• A list member can contain a chain. For example you want to chain headers. Or chain header + interface. It's a sequence of operations.
• And at the lowest level you have a next hop that can be represented by multiple things. NH, logical tunnel (like GRE, or MPLS LSP), or explicit tunnel encap (and you can implement MPLS PP using this model)
• Devil is in the details. You might argue this feels very complex. If we start with something basic, it would be a lab experiment. This is writting by multiple routing vendors so we understand what's in the field. Instead of later have people say "but we also need this" after the fact.
• Solving use cases, there are thee examples that can be achieved with this model.
• We got lots of feedback on the list, really good. Terminology issues are mostly done, and there are other things that need to be fixed. We want to resubmit a draft and re-issue the call for adoption.

Questions:

• Someone: Terminology differences aside, it is encouraging that this info model is consistent. I want to express my support. I hope we can coordinate our effort.
• Nitin: We will be coordinating.
• Jeff Haas: the complexity of this is not bad. It's better than others. Request: as we go through these info models, we need to understand the read vs. right mode of the info model. But also we should keep in mind the read portions are good places to make hooks. Cover the RIB which contains routes. When you want to manage traffic you should say "refer to this information model existing".
• Thomas Morin: Good doc. But we need to ensure at the WG level that it's happening, not only for your draft but also for others. It would be bad if there;s inconsistencies.
• Ed: That's acknowledged. As chairs and authors want that.
• Someone: There was some discussion about PBR in the RIB model. Does that mean it's out of scope?
• Ed: No, clearly in scope. 
• Alia: When it becomes a WG draft, make suggestions to the editors.
• Ed: Address those separately. I cannot comment on the answer because I'm not an author, but it is in scope.
• Navine Broadcom: Event notifications.
• Alia: This draft was up for WG adoption. Good discussion on the list. I've not seen a lot of substantive comments on the details of the model. We should have that commentary happening on the actual details of the information model. We have tight timeframe. Other than terminology there seems to be good interest.
  
  
  
  

draft-atlas-i2rs-problem-statement-01
(T. Nadeau, 10')

• Tom: Like the architecture, this is one of the early docs.
• We've only made some minor changes on this doc. Giving a small overview.
• The problem statement is what you see -- key problem that we think we are solving. It is now fairly aligned to the architecture. 
• For example, the definition of an Interface to the routing system. As well as data models that describe the interface. And the interface must support a variety of use cases, which is obvious.
• Data models need to be used to describe the things we will be talking to. We need to describe the RIB (routing system), and Topology.
• The other key areas are what you do with routing information. And lastly some of the desired elements of an interface.
• What are we doing now? Alia announced we asked for WG adoption.
• Alia: I sent out the email, but it was a join desicion.  We co-chairs talk.
• Ed: Same thing applies here with chair being co-author.
• Tom: We've god good feedback and a couple of detailed request for edits. One from Ed, one from Carlos, we will be addressing in the next version. Encourage you all to comment on the list for that.

Questions:

• Alia: we have some wordsmithing comments. WGLC ends on the 12, continue discussion on the mailing list.
  
  

I2RS and SDN Security Models
(S. Hartman, 15')

• Sam: I'm talking about different models and security. The background is that in the Interim you had some discussions, and Wes George had found a draft I had written a while ago of security requirements on the broad SDN context. If you say you are only defining an interface between client and I2RS agent, then there's the question of how if fits in the overall system.
• You have to be thinking about the security of those impacts for I2RS. Or at least you might want to...
• Wes asked me to see how much it would take to adapt my draft to I2RS.
• The question is: do you want security requirements broadly and then see I2RS, or look into the the I2RS specifics only.
• My co-authors, someone, and Margaret W. who work on security. The draft is pretty old, but I will discuss what's in the draft.
• On the figure. We are assuming there's a controller, and the controller has multiple applications, and that's interesting from a security standpoint, and is it interesting enough that it affects the interface of I2RS. 
• Three classes of applications, because they have different security properties.
  • Network sensitive applications. App influences the network environment. Its routing. App talks to routers and switches, possibly mediated by controller doing authorisation, etc.
  • Service for the entire network. Like Firewall. Basically manipulating routers to accomplish that service.
  • Packaged network services. Package up a service and add it to the network as an application. Package a service like a Firwall and drop it in the network. This makes us think.
• Need for authentication and authorization across multiple organizations. The answer might be that for I2RS there's no impact, but for the broader security architecture there is.
• Talks about OpenFlow. Maybe take it out and add I2RS stuff. Although if you take this as a starting point, it talks about the broader security applications. And then talk about security that comes in play between I2RS client and server.
• We have to think about the thread. Yes, error if two people write the same data. But if people are maliscious, there are more interesting questions.
• Big question is: do you want something this far, with a largest system focus, and include the specifics of I2RS, or have something much more focused only on I2RS

Questions:

• Wes George: Clarify my involvement. Before I2RS I wanted to get some actual text instead of talking theoretically. That's on my list to do. Unless someone says "no, no", that's where we'd start. If you were not present on the I2RS interim, there are good notes, recording, and a good preso.
• Alia, with WG Chair hat of: In my view, the scope of I2RS is from the client and interface down. I think the security aspects that we'd do are client down, with understanding that client works on behalf of applications. If you let any applications write any prefixes they want that's not good. Start with the assumption of the same adminsitrative authority controlling router and apps, and then expanding from there.
• Nancy Can-Widget: You covered some of the points I was going to cover. I am new to I2RS but I cover security. In the presentation that D Mc Grew and I pot together, we have the many-to-many that adds the attack surface.  The group should have security requirements, whichever way you choose.
• Sam: Whether you assume one trust domain is a big question.
• Alia -- WG Hat off again: Even if there are different orgs, do they trust each other?
• Wes: No.
• Alia: But we need to understand that.
• Sam: If you assume multiple trust domains security becomes much more interesting. 
• Ed: Have multiple identities. Notion of redundancy. We need to get down to that level. As much as we have consensus since noone talks about this on the list.
• Sam: It is a bit more complicated.
• Nancy: I break it up into two dimensions. Multiple orgs, there is federation of who you are willing to trust, and which applications within the operations. It's a richer policy mechanism.
• Wes: Maybe the easier way, I will write the background info that I wrote to Sam and send it to the list.
• Alia: I was going to suggest that there's a few people investigating this topic. Those interested come here after the WG is over so that everyone knows each other.
  
  
  
  

Thoughts on an I2RS protocol
(E. Crabbe, 10')

• Ed: I've been talking with vendors and operators.
• ...As much as much as I can have different opinions with different hats.
• Alia: it just takes practice.
• As an operator: I find value of this. I want increased functionality which ties to simplicity. Simple to manage. One of the worst problems in operations is that there is no common APIs and we write screen scraping scripts. We want to avoid that.
• Speed: We are moving to model-based networking. Models themselves can be fungible but developed quiclky.
• As well as deployability.
• One thing that keeps coming up is the number of component protocols involved in the system. I will arbitrarily say 5.
• With just one protocol we get all these things. We see the IETF issue in as a good example, PCE. We have multiple IGPs doing the same thing.
• If you have 5 protocols, we retain functionality but through out of the window the simplicity, extensibility, and deployability.
• So the close we get to this side, the more danger we have of not being practical.
• I would posit as an IC, that we need one protocol.
• As a chair: operator feedback is that we want something as simple as possible (and speak up if you disagree or agree).
• There are significant number of experiments going on in private. Using the term "experiment" loosely. Making things outside the charter because there's demand. That's normal in the IETF, but it's a dychotomy. Alia and I said we would encourage people to present their experiments.
• I'd encourage people to share your experiments.
• And that's it.

Questions:

• Alia: I'd like to echo as co-chair, to share experiments. That's how the WG learns.
• Ed: Any operator wants to comment? Wes? No yelling? Thanks.
  
  

draft-medved-i2rs-topology-im-00
(J. Medved, 15')

• Jan: Info model for network topologies, in collaboration with many people.
• Why? Commoon information model for network topology to be used by applications. That's topology at any layer. So we are thinking layer 1, 2, 3, maybe services topologies.
• We attempt to create a generic topology model, and then extensions, as L3 unicast IGP, and then extensions for the two more common ones, OSPF, and ISIS.
• The draft uses RBNF. We would like to get a lot of feedback on the mailing list. If the feedback is positive want to ask chairs to issue call of adoption.

Question:

• Ed: In the Interim meeting we discussed this: topology model is most usable northbound from client or controller. Therefore it might be totally out of charter.
• Jan: You clearly need an info model, and you need a network topology view to drive those requirements.
• Ed: We should deliberately start that conversation. That was the main reason why we did not put this one up for adoption.

Jan continues:

• At a higher level, a topology mode., and added IGP, and TE DB, which exteds the ISIS and OSPF topologies. There's multple levels of refinement, and other topos of L2, services.
• The basic structure is simpleL topology, nodes, links. Links reference nodes. And either nodes or links as termination points can have underlined elements to create topology layers.

Question:

• Ed: Do you do layers with multiple termination points or increase the links.
• Jan: Both. Link in L3 can have multiple L2 links.
• Ed: so for an underlying link. Direct x-connect running L3 and ethernet. Would I associate the logical termination point with L2 and L3?
• Jan: No, only the L2
• Ed: So, there's another termination point for L3?
• Jan: Yes.

Jan Continues:

• Links extended with L3 IGP attributes. This allows us to put integrity rules and assure links/nodes/TP are a matching type.
• This slide shows the further extension of the IGP unicast topo with ISIS and OSPF specific attributes.
• And that's the end of my preso.

Question:

• Someone: I've seen a doc with a YANG specification, is the same?
• Jan: Yes, we have that other corresponding doc that we will present in NETMOD.
• Someone: Why?
• Jan: Charter of I2RS is info model, and NETMOD is data model. An info model can be modeled in multiple data model languages, including YANG.
• Alia: WG Chair on, make sure there is coordination, we need a simple data model.
• Acee: It would be good to have examples in an appendix and map to RBNF.
• Someone else: in slide 4, need consistency with 2 termination points.
• Jan: that's a good point. THis might be an artifact of an early version.
• Ed: I agree
• Someone else: this reminds me of someone else I've seen in terms on what the solid diamonds mean and so on.
• Jan: Yes. that's deliberate.
• Someone else: yes
• Ed: You are doing two things: replicating nodes, and replicating termination points. Are you maintaining protocol adjacencies for all of these?
• Jan: The node can be an abstract node. Can be mapped to an abstract node, then mapped to a physical node.
• Ed: In slide 5, how are you maintaining adjacencies? And then ext slide, isis links.
• Jan: It should have the same association but we run out of space.
• Ed: One of the previous comments made an excellent point, which I also made.
• Nitin: To respond to Ed's mention earlier. This is a data model that can be used to export topology from the network device, or not bound by an I2RS client. Have a model that applies both from network device and from controller, so as to not duplicate.
• Jan: If a network element is running a routing protocol is could export all topology.
• George: There's a draft in ISIS this afternoon, in which I've found useful pointing two unidirectional links to each other and get the whole relationship without confusion.
• Jan: got it. Thank you.
• Someone from Ericcson: Why all links are point-to-point?
• Jan: L3 bias that we have. Links as pseudonodes.
• Alia: chair hat off. Start is what's in the IGP. It would make made the model useful to amplify the prefixes and termination points as customer terminations, and inactive links. SOmeone that is good enough. This model describes things that what we have is almost good enough.
• Alia: Another: A link to a link in different layers talk to a path so I am not sure.
• Jan: Yes, we might need path. But on your other question, we thought about inactive topologies, etc., but decided to focus this draft on IGP topology. We decided to chew off a chunk of work that would absolutely do. If other people contribute models would be great.
• Ed: Can you start that discussion on the list?
• Jan: Yes.
• Ed: Thank you.
  
  

draft-bitar-i2rs-service-chaining-00
(N. Bitar, 10')

• Nabil:
• This also started in the interim.
• Let me be clear as to the scope and what this addresses.
• Objective is to describe service chaining use cases and what can be controlled by I2RS. We want to do service chaining for multi-tenant (tenant being the same as customer in this context).
• The first use case is representation/discovery of service topology to be used by higher-level orchestration system, and service path.
• Here we are not liming services to be virtualized. Different ways of realizing services. In VM, router, etc., each of which can have a different way of identifying it. And then it's about the capabilities of the service. And then includes access point, not only the core. In a VPN you want to know which router and which access port is an AC. That could be an extension along the lines of the work Jan just presented.
• The next use case is monitoring liveliness of a services, to detect node failure or select a different path. service node and hosted system (VM, router), CPU, memory, etc.
• Then after talking about topology and monitoring, the question is how can we use that? on a given service path (realization of a service in the network). You could mirror, steer, policy route on a given tunnel, etc.
• The other use case is to do BGP traffic steering.
• What scalability we need? And also what security considerations are specific to service chaining.
• We should also align terminology of controller-system to "client-agent". And avoid congestion-triggered DoS.
• Next steps? We want comments and input. We also need to update the draft with comments from a private exchange with Alia.
• That's all I have. Any questions?

Questions:

• Ed: Let's take those to the list. If you get that started it would be great.
• Alia: The thing that it is nice about this draft is that it talks about feedback that gives guidelines on scalability. Who's read it?
• Alia: reasonable handful but not too many, I encourage you to read.
  
  

draft-keyupate-i2rs-bgp-usecases-00
(all, 15')

• Ed: There's been some discussion on the list about adopting this document. Although Keyur does not have a presentation, I want to talk about this.
• Ed: How many people has read the draft?
• Ed: Not too many.
• Keyur: Currently the authors have received two pieces of feedback, the first one to merge with draft-white's use cases, and the second to remove the configuration pieces and we are OK.
• Ed: Yes, that's a short conversation with the number of people who read it.
• Ed: Please read the draft and send your comments.
• We have one last preso in the remaining 9 minutes.
  
  
  
  

draft-camwinget-i2rs-pubsub-sec-00
(N.Cam-Winget / D. McGrew)

• Nancy: My collegues, David McGrew and Ken we submitted a draft, admitedly close to the deadline so I do not know how many people have read it.
• The need ot async transport for notification.
• We want to mane some observations:
• 1. The need tof the publish-subscribe model to address the requirements. We talk about subscribers looking at it from a topic or contextual based. Organizations might be topic, and operations might be contextual.
• 2. How the pub-sub fits into the I2RS group. THese requirements highlight the model: async router-to-app notification, many to many relationships, topology. RIB updates, as well as policy management (within your I2RS). But also the ones that drive authorization. Also the need to discover the type of informations, and from security to do that dynamic discovery.
• From that, I did a very quick overview for the need of pub-sub. Then there's the need to design patterns. This covers the whole breath of security requirements. We need to make sure that there's pee-to-peer, or app-to-client authentication. But beyond that, the communication be autenticated. Also auth against replay attacks, and the ordering issues.
• For providing those security services we should look at transport models: single vs. multiple message brokers.
• The draft is only about observations on the design patterns, that highlight requirements.

Questions:

• Greg Mersky: on pub-sub, who should receive early published state
• Nancy: I am not sure I understand your questions.
• Greg: There is the published and subscriber.
• Nancy: That's why I highlight the difference between topic based vs. context based, and perhaps after the discussions today we might need to have a hybrid. If there is a state change the subscriber needs that update.
• Greg: The state already exists, it's been published.
• Ed: He is talking about synchronization of the pb-sub model.
• Nancy: But I am talking about how to give notification updates.
• Greg: Ed mention to reuse existing mechanisms. Have you seen routing protocols? They quite well fit pub-sub good enough.
• Nancy: I am saying architecturally should look at pub-sub, not which 
• Joel: I am not sure I gollow why you call it pub-sub. From an architectural perspective, it does not matter if it is one transaction or multiple. Then, after that, we get into protocols. I can pretend NETCONF or ForCES is pub-sub. If receiving the notiication is pub-sub it's OK. Otherwise I do not understand the question.
• Alia: We need protocol requirements drafts, and in that we need to be thinking bout this. I would like to see conversation before next IETF.
• I would like to see the blue sheets.
• See you on the list, thank you.
  
  

Meeting adjourned, 2:58pm, Berlin time
EOF