IETF 98 Chicago PIM WG Tues, Mar 28, 2017 9-11:30AM Zurich B (Held jointly with MBONED WG) WG Status Stig/Mike Agenda bashing Louis Contreras: draft-ietf-pim-multiple-upstreams-reqs should update before Prague Stig: In general if we want the ietf yang models to be relevant we need them done soon. draft-ietf-pim-source-discovery-bsr-06: Stig Venaas presenting Slide: PFP-SA Slide: Status - feels they're done with this draft. Two different implementations, four organizations showing interest in deploying. - one of the implements has been tested. - Ready for WGLC ? - Toerless: intended status ? A: should be experimental. - who has read the draft ? 5 ? Ready for last call ? 5. Mike(WG chair): will be taken to the list, but looks like it is ready for last call draft-ietf-pim-igmp-mld-yang-03 Guofeng (Huawei) Slide: Status - version 033 reviewed by yang doctor. Slide: IGMP & MLD yang global structure Slide: 3 level hierarchy relationship Slide: draft updarte information-1 Slide: draft update information-2 Slide: Future Plan: appply to WGLC Toerless: how much vendors involved: Stig Venaaas: design team from 5 different vendors, going through their implementations to figure out what commonality is. Don't want to put much mandatory stuff into a model because it becomes impossible to implement. 5 companies have looked at this at this point. Yang doctor also was fine with it. Common mistake for models is descriptions are not detailed enough. Guofeng: feedback from 5 vendors. Stig: there is also a wiki showing a matrix of what model elements overlap how with vendor implementations: IETF PIM status page -> PIM Wiki -> Yang multicast team: Design team members shows operator/vendor participation long list of PIM configuration items, this matrix was use Toerless: great, should be referenced in the draft/RFC. should make a copy around last call to freeze the status of the wiki related to the RFC. Jake Holland: Liked pictures in mboned draft for yang shown. Would it be possible to add appropiate block diagrams to show with elements mapping to appropriate configuration. Alvaro Retana: please also refer to RFC7942 the Wiki might not be maintained forever. Diagrams may be taken out for publication if they are dated. Will make another revision and ask for last call. Mike(WG chair): Xufeng et.al. involved in a range of other Yang models, so this work will be well aligned. 10:30 draft-ietf-pim-msdp-yang-00 Sandy Zhang Slide: MSDP YANG Slide: Next to do some fixes, spelling -> yang doctors review. Stig: This was also worked on via the design team, see Wiki, some entries for MSDP. Jake Holland: Would find it helpful to have a diagram also for this draft. Stig: please read draft! draft-pim-with-ipv4-prefix-over-ipv6-nh Ashutosh Slide: example Topology - rfc5549 available for a long time. Slide: Problem statement Slide: Solution when PIMv4 and PIMv6 are enabled - use of interface identifiers per rfc6395 Status: solution based on secondatry address list shipping and deployed by one customer Donald Sharp: Why do we need 3 solutions ? A: Efficiency. If v4+v6 are enabled, one piece of information needs to be signalled, if not, another set of information needs to be signalled (secondary list option). Donald: why not remove unnecessary option ? A: Would like feedback from WG. Stig Venaas(co-author): if you only have deployed v4 multicast and do not want to enable v6 multicast solely to create the necessary announcements. But it does not say that it's only for IPv6. Check address list to find neighbor. Donald Sharp: agrees all three options would work, but want to implement least amount. Stig: agreed. Donald: prefers solution that cisco did implement. Eric Rosen: is this not strange? Donald: rfc5549 is strange. Eric: MAC address sounds hacky (third option). ashutosh: agreed, but looking for guidance. Btw: running both ipv4 and ipv6 control plane required more resources, might also increase licensing requirements. draft-zzhang-bess-bgp-multicast-01 Jeffrey Zhang (Juniper) Slide: Multicast: fear/dislike & necessity Slide: BGP signaled multicast: what & why - replace both PIM and mLDP Slide: How to signal tree/tunnel using BGP Toerless: inquring about way it works. In case of RR, the PIMs are indirectly directed to the upstream via the RR by using route-target (one route target for each router necessaery). Dino: would this solution work on leaf-spine DC. run joins the way specified. Could you encapsulate multicast in the BGP virtual next hop ? Slide: Source Discovery for ASM - no (*,G) state into network, just on last-hop, all joins (S,G). Toerless: how does it compare with Stigs BSR approach: Stig: this scales better, hard state vs. soft state. Dino: also not flooded everywhere because of last hop to RR mechanism - last-hop routers send membership announcmeents to RR, only get "SA" for group of interest. Dino: possible to do /m prefix ? A: yes. Slide: Incremental Transition Toerless: Q: how about losing first few packets after new join ? A: prior BGP MVPN solutions did have options to support tranmitting first few packets, this one solution does not. Dino: and thats good!. Jake Holland: using only SSM seems to be barrier to adoption of multicast. A: tree setup and ASM discovery can be done Jake started discussion why PIM is bad, BGP not, couple answer, Lenny, Toerless about history of resistance to PIM. Dino: could somebody implement this with two BGP instances ? Lots of combination of complexities in one implementation/instance. Fast join/leave required. A: multi-session BGP would allow separate implementations of BGP for example. Dino: would you recomend this to a customer. Toerless: so where can you do the demultiplexing for two processes Joel: different port numbers... Ashutosh: asserts ? a: there is a section in the draft, these will be handed lin control plane, replacing data plane assert. Donald Sharp: is the point bringing the database together ? a: main thing is signaling of tree (which protocol). The other point is source discovery. Donald: one reason why PIM is so complex is source discovery Stig: are you trying to get this adopted in bess and is it being dicussed there? a: will review in bess, but got more feedback from this PIM WG.