IDR interim 2/8/2016 - Minutes
0) Bash Agenda [10:00 - 10:05 ]
1) BGP Flow Specicification Version 2 [10:05 - 10:45]
2 IDR WG drafts [draft-ietf-idr-flow-spec-v6,
draft-idr-flowspec-l2vpn] and
9 proposed drafts suggest additions to BGP Flow
specification. On January 11, 2016 we had discussion
of the issues of combining these drafts.
draft-hares-idr-flow-spec-combo
a) issues relating to combination of drafts
b) Precedence ordering for new BGP Flow Specification
c) Precedence among Routing Functions doing flow Filtering
d) Yang models for BGP Flow Specification
This interim introduces this discussion
2) Discussion [10:45-11:30]
Discussion questions:
2-1) Should we go toward a BGP Flow Specification version 2
with ordered filters and ordered actions?
If so what format:
a) BGP Attribute
b) BGP NLRI with order + actions
c) BGP NLRI + BGP Wide Communities
d) Another Format
2-2) Shall we Align all the Yang Modules for
Filter-Based RIBs (config (aka policy routing), BGP, I2RS)
Minutes
John Scudder
10:05 meeting starts
10:08 strawman proposal/draft-hares-idr-flow-spec-combo-draft-00
10:27: Stephane: Is it a question of overriding (precedence), or chaining actions?
John: "chain" is relevant for things that can be combined. "Precedence" for things that are mutually exclusive (e.g. different tunnel dispositions).
Jeff: Think in terms of match criteria. Some don't make sense, e.g. you might not be able to apply L3 filtering to L2. Actions are more complicated, because of how they can be applied and combined. Scopes are tricky because bundled with match criteria. E.g., from redirect-ip, we had to figure out interaction when we had redirect-vrf already there. Decision was traffic might be inserted into VRF, then redirected to IP within that VRF. General rule couldn't express that, had to decide it in the context of the two specific primitives. Since these actions are communities, and it's easy to add/drop communities, we might have multiples of given action, e.g. you might have multiple redirect-ip. What does that mean? Load balance? Closest exit? Left it as implementation-specific. Overall precedence big picture is complicated when potentially more than one entity injecting flowspec routes into network. If you have a single entity doing it, you can rationalize it, but if you have two or more (e.g. SDN controller + DDoS mitigation system), which is more important? If we follow flowspec rules for validation, you may have match criteria for overlapping traffic that is clear from protocol PoV but doesn't reflect user intent.
Sue: Yes! This is a challenge. Note interface-set is an action.
Jeff: From my PoV (not sure about Stephane) I treat it as a match. Matching on direction traffic is arriving from. What interfaces, what direction.
Sue: But since it's specced as a community, it's syntactically like an action.
Jeff: I see your point, challenge for interface-set was that it is a match criteria that's not as usefully transitive as the other match criteria in the RFC. Choices for encodings were put in NLRI (semantics may change, have to rewrite on ingress), or create the idea of a "match" community which is easier to write policy on. We can move it to the NLRI if the WG thinks that is better.
Sue: It exposed useful complexity.
10:38: continues
Sue: seeking feedback about document development and adoption: get the docs "right" and then adopt? Or adopt and then refine?
10:42
Sue: To network operators -- how far do you expect flowspecs to travel? Intra-domain? Interdomain?
Jeff: Clarifying question. You mentioned protecting the source. Wes, did you mean dest?
Wes: Yes, dest.
Jeff: Using ROAs to protect resource makes sense if you have RPKI anyway. More "interesting" if you have a covering ROA but no covering ucast route. Do we want to allow the flowspec to be installed? My initial thought, you don't. W/o the matching ucast route traffic shouldn't be going to that party anyway, but what about strange SDN-ish cases? E.g. where all traffic is sent via FBF?
Wes: Agreed.
Sue: Would you check for a match, or need more-spec?
Jeff: You'd want *a* matching route.
Sue: OK, that is what draft says now. Please look at S. 4.1 of draft to confirm it is right.
Wes: My only other Q was about capabilities. Would FS v2 imply ability to use ROAs to validate FS?
Sue: What do you think?
Wes: Don't have an opinion.
Jeff: Want to urge caution about obsessing. Two reasons. First, have to add considerations in draft-oid that relaxes validation for various cases, e.g. transit. Will esp be true for FS in SDN context, binding between FS and matching ucast routes will be weak at best. I think checks were originally there for customer ASes to inject a FS route toward their upstream, but for local-to-service-provider you can pretty much neglect that.
10:48
https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-02 -needs to be considered in section 4.1 of draft-hares-idr-flow-spec-combo-00.txt.
Sue: on to security. Wes?
Wes: only applies to cases where you're not working w/in a single AS, so the question of whether FSv2 is intended for inter- or intra-network use is important.
Sue: "more researchy"
Jeff: SIDR had excluded anything outside BGP ucast, haven't even defined for VPN. Also as a practicality, BGPSEC intentionally doesn't secure path attributes like ext comms, since SPs tend to add and sub communities. Becomes more complicated where we are using extcomms as controls, e.g. RTs in VPN context. Becomes FAR more complicated in FS context since action criteria intentionally allow traffic redirection, may need to change on hbh basis. So, can't secure since you have to change them, but must secure since they have impact. Maybe split? ROA is independently useful. BGPSEC will be highly controversial.
Wes: Yes, we saw it that way. At last interim I said this is "way more experimental and not ready to include in the standard."
Sue: Based on that, I left most out of the initial draft. Wanted to double-check that was still accurate, I will leave the BGPSEC stuff off. See security considerations. Can consider it in the future. That's section 9.
10:54 FSv2
Jeff: Grouping tricky because some things can be grouped, some can't. Need to provide guidance per item.
Robert: Also hardware dependent. Can provide guidance in control plane but might not be possible in forwarding plane due to hardware capacities.
Jeff: Robert's point is different subsets have different forwarding hardware, example half nodes can match MAC, other half can't. Hard to build one combo action that makes perfect sense. Almost argues for a discovery functionality. Because there will be cases where you "support" FS but not every subfeature. This would make it even trickier.
Robert: Yes. But also, in HW you may not be able to match against (say) MAC after first matching on proto. On others you can.
Stephane: Would be good to discover capabilities. Hard to discover kind of constraints Robert describes though.
Jeff: Further, biggest problem is not adjacent node. It's the entire network. Maybe BGP-LS?
Stephane: Regarding ordering, what if two BGP speakers are both trying to choose the same ordering for their filter?
Sue: Suppose you have such a conflict. Then you fall back to hard-coded precedence. Pretty much, status quo. If anyone has a better option, please bring it forward!
Stephane: Another option would be drop all conflicting entries. But have to evaluate impact of doing that.
Sue: Which is "least surprise"?
Jeff: We've identified a piece that will have controversy/discussion. By bundling we have the ability to say "must do this whole set atomically" and if not, fall through to next rule set.
Sue: Match type and actions would be grouped together for that reason. Compare to PBR, i2rs FBF RIB.
11:06 action order
11:07 discussion q 1
Jeff: Interop with base flowspec will be an issue for FSv2
Sue: yes, do we want it to be backward-compatible? Work w/ precedence is meant for compatibility. Traffic rates will be challenging since it has to occur before other functionality.
Robert: FS was designed to be lightweight DDoS mitigation to many ASes. FSv2 is a huge load of new functionality, maybe instead of new attribute (or as well?) consider a new SAFI, since the use case is different.
Jeff: We are potentially making it so complicated it will be hard to get it implemented. At what point do we say we have one set of functionality for DDoS, keep that in BGP, put the much more complex set of functionality in i2rs or other group?
Sue: Or simple FS is one functionality and more complex as another. Can be a range. If we stick with "simple" we have to pick actions to be either "simple" or have some sort of default ordering. What CAN we do, vs. what SHOULD we do?
Acee: Agree with Jeff. Is BGP a generalized SDN protocol when we have Netconf, Yang, i2rs as well?
John: Agree but: MY feature is obviously simple. YOURS is obviously complex and should be pushed into a different protocol! (Joking but serious.)
Sue: And regardless, we need some ordering.
Jeff: Well, what is taking us this direction is ongoing request to add features.
Sue: Have to be practical. Does business need the complexity? If DDoS is all we need in BGP, fine. I'm neither for, nor against. Where is the value? (Personal opinion.) "We can put Shakespeare in BGP if the Internet needs it."
11:16 FS YANG
Suggest align FS, i2rs PBECA
... and oper state
11:19
Jeff: Interesting Q is not CAN we combine them but SHOULD we? Existing FS Yang doc is that it represents RFC well. More of a protocol Yang module, but much like service as well. If merged into ECA, makes it exclusively a protocol module.
Sue: Can you elaborate about 5575?
Jeff: FS Yang doc I last read was a nice Yang representation of capabilities of FS mechanism. Lacked tie-ins to BGP, what you need to plug into IDR Yang module to make it work w/ BGP. Whether intentionally or not, that's a "service" module. You're asking for a service to be enable that has N features. ECA draft is deeply tied in almost to hardware level. Local system impact. Similar issue, doesn't have tie-in w/ how to interop w/ BGP portion of Yang. Overlapping features, loses abstraction that this is a flowspec service module.
Sue: Not sure that matches with the version I read. Need deep dive. Traffic filters looked like ECA filters.
Jeff: I agree there is semantic overlap, very strong. From that PoV, you can think about analogy between ECA model and CLI access manual configuration. FS model is closer to what happens when you're on a RR and you add a FS entry to the FS table. You're telling BGP to emit something and eventually something happens. One is a local config mechanism, the other a service mechanism that causes something to be emitted to the network.
Sue: Not sure I agree, basic stats, actions, are all doing same sort of match/modification/forwarding at the same level. If what you're saying is the FS is service level, OK, but not seeing diffs in -02 as of September.
Jeff: End impact the same. We agree. But go the other direction. If I program somethng in ECA, why would I expect that to be pushed into BGP?
Sue: Ah, I see. Packet-based functionality is same policy. Rules same. How it's sent in BGP not the point. My point is they should be aligned where they share common groupings.
Jeff: Yes. Where messy, consider analogy to ACL model in Netmod. Applicable to FW, route flitering. But BGP route filtering? No, we need more complex primitives. One size doesn't fit all, need to find overlap but there will continue to be reuse of common bits but augmented per-technology. So, simple capabilities, simple FW filters, but will quickly end up with strong differentiations in how they can be combined, which is tricky in Yang groupings.
Sue: Current set are essentially 90-95% overlap. If you're projecting future divergence, I don't see it there now. You're thinking FS should be more reduced to keep simple, i2rs should expand?
Jeff: Things that can be refactored and made reusable, maybe 40% of functionality for FS? Will have appl for firewalling, FS, i2nsf, i2rs. For the remaining 60%, shouuldn't spend a lot of effort trying to align.
Sue: Your guess is 60% difference in FS.
Jeff: My guess is common LOOKING things but not amenable to common grouping because the way of combining is not well represented in Yang.
Sue: Thanks. We may need to discuss further off line. Acee too.