BGP interim will be held on Monday 3/7/2016 from 10:00am – 11:30am ET.
The topics are:
1) BGP Flow Specification – 2 options for work [10:00 – 11:00 am]
a. Option 1: Extension of current BGP Flow Specification
b. Option 2: Version 2 of BGP Flow Specification using new NLRI and Wide BGP communities to allow ordering of filters and actions.
c. Option 3: Do both option 1 and option 2
Documents discussed:
draft-hares-idr-bgp-flowspec-combo-01.txt
draft-eddy-idr-flowspec-packet-rate-00.txt
draft-hao-idr-flowspec-nv03-03.txt
draft-hao-idr-redirect-tunnel-00.txt
draft-liang-idr-bgp-flowspec-label-01.txt
draft-liang-idr-bgp-flowspec-time-01.txt
draft-litkowski-idr-flowspec-interfaceset-03.txt
draft-vandevelde-idr-flowspec-path-redirect-01.txt
draft-ietf-idr-wide-bgp-communities-01.txt
draft-ietf-idr-tunnel-encaps-01.txt
draft-ietf-idr-flowspec-l2vpn-03.txt
draft-li-idr-flowspec-rpd-01.txt.
Discussion:
2) Yang models [11:00am – 11:30]
a. BGP Flow Specification Yang model
Documents discussed:
draft-wu-idr-flowspec-yang-cfg-02
draft-hares-idr-bgp-flowspec-combo-01.txt
Discussion:
Web ex:
https://ietf.webex.com/ietf/j.php?MTID=m944a81587e9ce48ff4c927d7545c1456
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Bluesheets
http://etherpad.tools.ietf.org:9000/p/idr-interim-march-7-2016-vBluesheets
Minutes
http://etherpad.tools.ietf.org:9000/p/idr-interim-march-7-2016-minutes
10:08
Meeting underattended, quick Q/A before closing.
10:09
Assem -- working on flowspec Yang model, wants to know how to proceed.
Sue --
10:12
more attendees arrive; resuming full agenda, recording started
(will resume discussion of Yang model post main agenda)
10:16
request to robert to resubmit v6 flowspec
10:18
Jeff -- do we really need RPKI/ROA for documents to proceed?
John -- context is that intradomain security is OK, interdomain security is... sketchy?
Jeff -- Q to Alvaro: agree?
Sue -- as a chair I'm not comfortable with the interdomain security, now over to Alvaro.
Alvaro -- I can't tell you about whole IESG. Security ADs will want "some security". Does it need to be ROA? ROA per se is not required. Depends on scope of propagation, what is the real interdomain use case?
Sue -- it's defined as a multihop thing. Use case is within one domain, 5575 is unrestricted hops.
Jeff -- two things. Applying RPKI to several of these mechanisms probably isn't applicable. You clarified that it's optional, and in the applicable cases, fine. Second, in terms of security 5575 has a base rule that you're not allowed to originate a flow spec route against a given destination without (... at this point I lost audio ...)
10:24
(... notes resume...)
Sue presenting slides
10:35
Sue to Jeff: Please suggest revisions to draft (S. 4?) regarding security, ROA, etc. SHOULD or MAY instead of MUST, would be good to clarify.
Sue: Draft-hares-flowspec-combo is a chair's attempt to aggregate issues and discussion points, adoption call is attempt to drive discussion of issues. Actual protocol work would be done in future documents.
10:41
flowspec-combo preso ends
Jeff: This may be the first application of widecomms
Sue: There are several people interested in implementing widecomms
Robert: Yay
Sue: What I learned is I need to refine ROA section. Purpose of this draft is to expose issues. Do we want flowspec to support SDN? Robert, Gunter. Will ask authors who have proposed various to things to provide their use cases. My understanding is there are data center, SDN, NFV use cases, will try to get those documented in drafts or email. Anything else I've missed?
Don Smith: Hardware-driven precedence? Filtering is often hardware dependent.
Sue: Consider policy routing. N-tuple filters done is a given order. (... missed some points...) your question is relevant to the action portion.
Don: Yes.
Sue: Drop or forward -- understand. Modify-then-forward case, does that change your view?
Don: No, because there is natural precedence in actions. Example, log is naturally last precedence. Actions like drop can be done on a fairly smart line card whereas maybe redirect requires going to CPU.
Jeff: This was a point of discussion in redirect-ip. Some implementations might not support functionality, your example might be software-forwarded some impls, hardware others. More broadly, point is about hardware capability. Open question what to do if some hardware supports what the filter requires, other hardware doesn't.
Don: Correct.
Sue: Flowspec puts stuff in policy-rib, must be processed before being put in forwarding plane. Good to consider, but doesn't restrict how we set precedence.
Don: Maybe default precedence should take hardware capabilities into consideration.
Sue: Some say one thing, some another. Please propose specific alternatives. Great feedback.
Sue: Any further discussion of precedence/actions?
Lucy Yong: Precedence/ordering on matching fields, actions. i2rs can do similar. Apply precedence to i2rs rules too?
Sue: Three types of precedence. Default precedence within BGP flowspec filters. Default precedence for BGP actions. These two define how BGP FS RIB is built, basically. Then inter-protocol precedence, between BGP-FS and other sources of ECA policy such as i2rs.
Lucy: In that sense, .... execution is on the router. How does BGP-FS convey how the rule is executed on the router?
(10:53)
Sue: Correct.
Sue: ...
Sue: Operator can configure policy for tie-breaking between filter sources. Make sense?
Lucy: Kind of? Adds requirements for hardware design.
Sue: I would expect conflicts to be resolved in software before downloading to hardware. Assume hardware...
Lucy: ... can execute in any order?
Sue: ...
Sue: I had assumed selection of an active forwarding policy would be resolved in software first.
(10:56 paused taking minutes)
(10:58)
John: Lucy, Don, others: An example would be really helpful.
On to Yang
Presenting Yang slides
Sue: first slide in line with Aseem's Yang model?
Aseem: Yes
(... missed ...)
11:04
Aseem: I haven't looked @ i2rs model. Will look and try to harmonize.
Sue: Let's discuss in more detail off line.
...
Sue: Xufeng, this isn't TEAS related but makes sense?
...
Sue: OK.
Lucy: Regarding local config?
Sue: Yes?
Lucy: You can use both BGP and local config to create flowspec routes. Deliberate?
Sue: Local config of flowspec is what will be sent to other nodes. Aseem, is there also assumption it will be installed in router?
Lucy: Might be created but not installed locally?
Sue: Aseem, does local config imply local install?
Aseem: Yes.
Sue: That makes sense.
Jeff: Comments on the model. You talk about harmonization. Some of the stuff is operational state (localpref, cluster list, etc). Should be referenced from IDR BGP Yang model, not repeated. Second comment is we haven't clearly answered route targets etc. In flowspec Yang model it's a string with a magic length, no defined content. Not generic, not harmonized, yet. Need to reconcile across models. (Also Openconfig, etc.)
Aseem: RTs to be harmonized across models, yes, I'll need to look at other models.
Sue: We should look at BESS, extended RT in Openconfig.
Jeff: OC has similar problem. Ambiguous. I'm not saying there exists a solution yet. Haven't looked @ BESS. But we do NOT want to have multiple formats for RT.
Sue: Some are in base model, need to reference.
Aseem: If you can point out inheritable stuff from base model, that will be helpful.
Jeff: I'll provide in chat window. But OC doesn't have one yet either, or at least didn't last time I looked. Generic problem, not just yours.
11:13
meeting closes