CHAIR(s): Susan Hares John Scudder o Administrivia Chairs 10 minutes - Note Well - Scribe - Blue Sheets - Document Status o YANG model for BGP 5 minutes draft-idr-shaikh-bgp-model-00 Anees Shaikh o Yang Data Model for BGP 5 minutes draft-zhdankin-netmod-bgp-cfg-01 Keyur Patel o Comparison of Yang Modules from I2RS 5 minutes draft-hares-i2rs-bgp-compare-yang-00 Sue Hares o IPv6 flowspec implementation report 10 minutes draft-vandevelde-idr-ipv6-flowspec-imp-00 Andy Karch o Layer 2 BGP flowspec 10 minutes draft-hao-idr-flowspec-l2vpn-01 Weiguo Hao o BGP extension for Extended admin Group 10 minutes https://tools.ietf.org/html/draft-wang-idr-eag-distribution-00.txt Michael Wang o Segment Routing Prefix SID extensions for BGP 15 minutes draft-keyupate-idr-bgp-prefix-sid Keyur Patel o Segment Routing Egress Peer Engineering BGPLS Extensions 5 minutes draft-previdi-idr-bgpls-segment-routing-epe Stefano Previdi o Egress Peer Engineering using BGP-LU 10 minutes http://datatracker.ietf.org/doc/draft-gredler-idr-bgplu-epe/ Hannes Gredler o Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios draft-dong-idr-rtc-hierarchical-rr 10 minutes Sue Hares o Add-Paths implementation report 5 minutes draft-retana-idr-add-paths-implementation-00 Alvaro Retana o BGP Link-State Extensions for Seamless BFD 10 minutes draft-zhuang-idr-bgp-ls-sbfd-extensions-00 Zhenbin Li Discussion Notes: (Note taker is Bill Fenner). * Document Status (chairs) o YANG model for BGP Effort assembled by a set of network operators - “OpenConfig” Motivation is to have vendor-neutral models Vendors can augment the model with proprietary features Goal is to have operators drive the model development since operators are the consumers. Will publish in relevant IETF WGs and work to unify IETF and OpenConfig models. Plan to publish in netmod yang repo. Kireeti: what I’ve heard from operators about service models: L3VPN, across multiple vendors, need lowest common denominator. When you’re looking at policy models, is it driven by lowest common denominator? what you use? A: It’s based on what we use. Trying not to go too far into service level since different operators have different ideas of how to deploy. Kireeti: How do you avoid devolving to lowest common denominator? A: Trying to do more of a union, but the features that we use Rob Shakir: Same functionality implemented in different ways on different vendors -> we will still include it in the model, Jeff Haas: Want this to be picked up in idr: you don’t want to put in all the knobs. How do you see this fitting into the idr model? A: Want it to reflect useful subset, it can grow over time to reflect all of the features published in RFCs. Rob Shakir: That makes work like ? has been doing for features like AS migration able to be modeled. o Yang Data Model for BGP No comments at mic. o Comparison of Yang Modules from I2RS bgp yang models way forward: we’ll likely have interims on these models to try to move towards a common configuration draft. Need rapid progress, prototypes. Configs (and common types, etc.) are a prerequisite for the i2rs work. Jeff Haas: comment to all: figuring out what the “core set” is will be tricky. OpenConfig says “this is what is in our network” and that is great; will the base model have to work for just-RFC4271 or is it OK to have the common set. Sue: We’ll have to do that at interims, etc. Kireeti: If you’re discussing yang models, the room has to be twice as good! Saikat: At the end of the day there’ll be one draft for config? Sue: Yes. One draft for config, another for i2rs. o IPv6 flowspec implementation report Have multiple implementations, testing them out. No comments at mic. Sue: asks room about flowspec adoption; I was too far forward to see the hands. o Layer 2 BGP flowspec Andy Card: Did you look at other L2VPN technologies? Draft is specific to Ethernet, but other technologies can do any kind of attachment circuit. Weiguo: Flowspec uses BGP to distribute traffic filtering rules. Hannes Gredler: Missing different Ethernet encapsulation formats: LLC, SNAP. Seems there’s no support for Ethernet hierarchy, e.g., q-in-q. Weiguo: Will add. Andy Card: Want to consider the cases that it’s not IP, but you still have actions like “set DSCP” or “redirect VRF”. Weiguo: It’s not always IP traffic. Andy Card: But you have some extended communities that are specific to IP. John: Repeat the comment on the mailing list. Andy: If you’re looking to keep the NLRI component types discontiguous [[does he mean distinct?]], IPv6 has already gone up to type 13; flow-label was type 13; you’re using type 13. Weiguo: We should unify the assignments. Sue: Andy, follow up to the list. ?1: Something feels wrong here. For every new address family or new protocol, I need to have a different AFI/SAFI for the flowspec. Can we look at a flowspec type that can combine match critera for IPv4, IPv6, Layer2, …? Saikat from Cisco: I have the exact same feeling: we’re matching ?1: would like to look at the whole problem space and try to find a solution for flowspec. o BGP extension for Extended admin Group Saikat from Cisco: People will continue to add new things. This doesn’t have to be added to the main draft, jgs: it’s fine to progress this as its own document discussion on the list says it’s fine o Segment Routing Prefix SID extensions for BGP Kireeti: Did you really mean that SRGB is global within an AS? Keyur: It is unique within an AS. Kireeti: There are DCs that use lots and lots of ASes, maybe an AS only has two devices. Keyur: You can reuse Kireeti: make it 4 bytes? Keyur: it is 4 bytes jgs: 50 ASes coupled Kireeti: 1000 ASes! — Hannes Gredler: In section 7, you write that it’s both SAFI 4 and SAFI 128. I can understand why SAFI 4, but for SAFI 128, we have more than one routing universe. What is the mapping of a SAFI 128 NLRI to the SRGB? Keyur: We can announce the label, but if you have a label index associated, you could use that value to compute a label if you’re configured with the SRGB on a given router. Hannes: What if you have two VPNs, and on those two VPNs we have the same index assignment? Saikat: That’s invalid index assignment. You cannot assign the same label index for two VPNs. jgs: What about label collisions? How do you handle this error condition? Keyur: In VPNv4, between two VPNs you don’t overlap the label space. Hannes: So you’re constrained in how you allocate index values for VPNs. Keyur: yes Hannes: How do you want to promote this draft where you’re obviously violating the MPLS architecture? jgs: It’s obvious that we’d bring this draft up in MPLS. Hannes: I’ll make some popcorn ?2: DC providers want to build graphs of what supports this — want to add capability negotiation? Saikat: BGP is hop by hop. ?2: If you have devices that don’t support it you will create black holes Ahmed (Cisco): related to violation of MPLS architecture: this pops up in every discussion of segment routing. Keyur: yes, this is up to spring to clarigy ?3 (Huawei): If you assume there’s only a single label block Keyur: No ?3: Do you believe there’s no way to have multiple blocks Saikat: For a given node you only have one block; if there’s a device limitation you choose the range that can be supported on that device. Even if you do that, all you need is the lowest level (out of the offset), and every index is an offset. Think of the whole thing being there, but you have some holes in it, and you don’t allocate labels out of the holes. Keyur: Each protocol can have a configuration extension for that protcol’s block. ?4: What’s this mean on 128? Keyur: If you attach it to 128-safi, you are telling your neighbor that here’s a label that you should attach to send to me. ?4: But you receive the 4364 update today, and the label you’re receiving is the inner label. We expect another protocol to give us the next-hop label. Keuyr: No, this is used to compute the inner label! [[discussion got pretty technical and fast. Sorry, but I couldn’t capture the back and forth.]] jgs: This is very relevant, let’s take it and hash it out offline. ?5: Every node has to be jgs: for those who weren’t at the spring meeting, we’re referring back to the conversation that was in spring. ?5: The index is globally unique, right? For all the VPN prefixes? Keyur: yes. jgs: There was a pretty extensive discussion of this basic topic in spring; there were a whole different set of issues [[More discussion with Luyuan and Keyur not captured]] o Segment Routing Egress Peer Engineering BGPLS Extensions No discussion. o Egress Peer Engineering using BGP-LU Shane Amante: advice: seems like we’re rapidly converging on the idea that we can use BGP for everything: routing, SNMP (link utilization), maybe not delivering YANG models yet. All the things you outline in here (e.g., using BGP-LS to signal) - you take a hard line saying that’s required. Can you say that these are things that would be nice to have in case some providers want to use it or don’t want to use it? E.g., also, add-paths: you only need that in some scenarios. — Keyur: 1. We would use this with 3107? Push approach if the bandwidth changes? Is this going to affect dampening? Will this destabilize the network with push approach? Hannes: I hope you don’t enable dampening Keyur: Why not use a different way to distribute some of this information? Hannes: Perfect point: what we also have lined up for version 2 of the draft; Evan from Facebook brought up that you don’t necessarily want to have *one* iBGP mesh; you probably want to split it into peer groups, and just do some of the features on the “controller” peer group. You’ll see that in version 2. Saikat: You really want it to only go one place Hannes: What are you suggesting? DNA community? Saikat: If you want to do it through 3107, some scoping is required. Rob: I think there’s space for both BGP-LS and link bandwidth community. Give some options as to how to deploy it. Hannes: One block for egress labels, one block for stats, some signaling carrier, could even be IGP path extensions. o Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios Sue’s opinion: add-path scenario (#2 in the slides) is preferable Please send comments to the list jgs: There could be a 3rd bullet on slide 3: propose some other solution? Jeff Haas: Propose to adopt this as a wg item, not because the solutions are the right ones but because it describes the problem and it gives us a place to work on. Saikat: The original RFC’s language is a little too restrictive. Nobody follows what the RFC says but does what should be done. It may be better to just fix the route-reflector RFC. jgs: so you have a different candidate solution? Saikat: We don’t think you have to be so restrictive as long as you do the right thing. Regenerate the path at each hop will solve a lot of problems. Sue: So there’s feedback that this is work that is worth doing. Work amongst yourselves. o Add-Paths implementation report Alvaro: We should bundle all this stuff together; last call it. Jeff Haas: The guidelines may need a tiny bit more love. We came up with a bunch of recommendations about how to use add-paths. Alvaro: Will send survey on Wednesday; people can reply by Friday; then we’ll be done by Monday. o BGP Link-State Extensions for Seamless BFD Jeff Haas as BFD chair: This is chartered work for BFD. OSPF and ISIS have already accepted their extensions. BGP-LS is the right place for it. Saikat: Question to the chairs: this will come again and again in the future: do we need an idr draft for every code point in BGP-LS? jgs: We should look at how to streamline it. Hannes: Eric Osbourne(?) did OSPF and IS-IS in one draft; maybe we can do OSPF, IS-IS and BGP-LS in one draft.