I2RS interim meeting 7/1/2015
time: 10:00-11:30am ET
[Scribes: Jeff Haas and Sue Hares]
Notes - are missing quite a bit - but these will be revised after the recording appears.
Agenda:
1) Agenda bashing [10:00-10:05]
2) FB-RIB base model [10:05 - 10:20]
[draft-kini-i2rs-fb-fib-info-model-01]
Question from Jeff: Is the ACL model sufficient?
Sue: Lets look at examples later on.
Sri: What layers should we be looking at? Up the stack?
Jeff: You're asking my question a different way. ACL model does L3/L4 fine, maybe L2. What about L7?
Linda: Think this should be differentiated from RIB. Not routing protocol. Really a protocol independent way. Really on any part of the packet. Should really allow client to match on any criteria. E.g. new threat on packet size 47, send it to particular scrubbing center.
Sri: This is already covered in info and data model? Do you think that's insufficient? Static routes are different. Do you think there's potential for confusion?
Linda: Base RIB model has good definition of static route. That's traditioanl IP routing; destination based routing. For filter-based, we need to emphasize the differences. We should take (inherit) from static route?
Sue: I2RS filter based rib is i2rs ephemeral state. I2RS RIB is also ephemeral.
Linda: Need to document better how rib model interacts with fb-rib?
Sue:Filters are ordered. They're different than the rib.
Linda: fb-rib is under a routing-instance. Since this is a match/action, why does this belong in a RI?
Sue: It was put under RI .[...?]
Linda: I2RS has many instances - ipv4, ipv6. You want filters to apply regardless of table.
Jeff: We're using RI in the same context as rtg-cfg model. THey map to VRFs rather than tables - ipv4, etc.
Alia: routing arch design team starting via openconfig individual drafts. haven't looked personally at the output yet.
Linda: Fine to make it consistent with vrf/RI. Want to give customers tools to updating forwarding without interfering with routing config. Using hierarchical filtering, can handle forwarding to specific clients?
Jeff: (missing section)
... I think that you might find the lack of interactino might be
Linda: Can you ask about why it might be scary?
jeff: Take example 10/8 to one direction next-hop A, instead it goes to
next-hop b in the system. This is great as long as
next-hop B is up. If next-hop B goes down, this down.
If next-hop B is directly attached or a tunnel,
then this is ok. The interaction is dynamic and static
and the whole network. if next-hop b goes down,
you will get BGP
Linda: SDN has the problems. People still want to move to
SDN. ATT has 5%. Asia's want to move to it.
We might to make everythign be reliable.
People want to send the traffic, and
though there is a scrubbing center.
Jeff: I think it is not less scary.
Linda:
Sue - shows ACL list
Linda: Think we should have this based on ACL model.
Jeff: [shows acl model has l4, some l2, missing l2 vlan tag] Linda needs to evaluate whether her desired behavior can be added outside of acl model.
BNP-ECA model.
Jeff: How does this overlap with ACL model? How should it? Do we need duplicate modeling because the applicatio demands it?
Linda: How does the rib model interact with this?
Sue: The 4 policy models pose precisely this question. They cover different things. Need feedback to figure out how we're going to use these. E.g. use acls, use routing, etc.
Joel: I understand the conflict. I hope we don't end up with a multiplicity of modules, especially in i2rs. Don't have a good way to solve the problem.
Sri: two main differences I see in the fb-rib vs. standard rib - time of day, [?]
Sue: Encaspulation, decap. 802.1q tagging, q-in-q. Trying to be comprehensive. We could enhance the acl model to layer 7 if that's what netmod wanted. (augment?) What none of these have is order.
Jeff: They each have their place. Don't prematurely refactor things, let's do it when it makes sense.
Linda: BNP ECA - lots of overlap from rib info model?
Sue: Work on functionality first, remove duplicate stuff later. Main overlap is default rib when you don't match.
3) Example Policy models that plug-in [10:20-10:35]]
ACL policy model
[draft-ietf-netmod-acl-model-03]
routing policy model
[draft-shaikh-rtgwg-policy-model-00]
generic policy model [Sue Hares]
[draft-hares-bnp-eca-data-model-00.txt]
SFC traffic model
[draft-dunbar-i2rs-fbrib-sfc-filters]
4) Discussion: [10:35 -10:45 ]
5) Service Topology model [10:45-11:00]
[draft-hares-i2rs-service-topo-data-model]
SFF toplogy model [11:05 - 11:15]
6)Service topology discussion
Sri: Is this independent of the service type?
Sue: This is intended to be protocol independent. Prior version went too close to service chaining.
Linda: What angle is this looking from?
Sue: There is a bit of dichotomy. i2rs rib/fb-rib is forwarding for a given device. The topology is network-wide from the viewpoint of a given node. Union of layer 3 forwarding protocols/config. This is the same thing at the service layer.
Linda: The viewpoint may not be complete.
Sue: Correct. As chair of IDR, had similar concerns about BGP-LS. Why not PCE? They wanted a tap at one location. Because of that experience, don't feel bad about having topology pulled from a single area.
Linda: As a controller, we want to scan all attached termination points, even if from a given node's perspective. The controller can build the full view from the individual views.
i2rs interim 7/1/2015
Wednesday, July 1, 2015
10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs
[interim web-ex available at 9:30 for speakers to check audio]
Join WebEx meeting
https://ietf.webex.com/ietf/j.php?MTID=m01b6aeeeb1b8701466c0ec6ebb11a301
Meeting number: 319 797 760
Meeting password: models.security
Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 319 797 760
Blue Sheets
http://etherpad.tools.ietf.org:9000/p/i2rs-interim-July-1-2015-vBlue-Sheets
Minutes
http://etherpad.tools.ietf.org:9000/p/i2rs-interim-july-1-2015-minutes