Minutes IETF98: pim
minutes-98-pim-00

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.