Minutes IETF106: pim
minutes-106-pim-00

First Yang model published .

draft-ietf-pim-bfd-p2mp-use-case        Greg Mirsky     15 min

* update after discussion in list.
* draft talk about how to do failure detection using P2MP BFD for DR/BDR
* utilizes hello option from drlb draft (going to be RFC soon)
Stig: we think DR detecting BDR failure is good.
Greg: it is not mandating the uses, its just suggestion.
Stig: on GDR session flapping based on it is BDR or not. Does it make sense to
keep session up. Greg: This would be optional.

Document is waiting for more comments and then ready to WGLC.
Stig to provide comment in list and to make progress by next IETF.

draft-ietf-pim-igmp-mld-proxy-yang      Xufeng Liu       5 min
* document adopted in recent past.
* new version address review comment. And make sender-source-address as an
optional entity. * removed other filter mode and keep only filter-mode in
group. * waiting for more comment from list . Stig: is document complete. Or
expecting some more changes. Author : they are still discussing . Stig: if
other vendors can take look and see if these yang model works fine in
implementation. Hitoshi: does it has explicit tracking Author : No Hitoshi:
This document needs to add explicit tracking detail. It might have already
implementation and Yang model should reflect it. Stig: Yes, Yang model can
define this even if functionality does not exist. Authors: Help would be needed
from chairs to make progress.

draft-ietf-pim-null-register-packing    Stig Venaas      5 min
* there was WGLC and there was only one response.
* got comment about detection of RP it does support this functionality.
* Authors think that document is ready to move forward. Another last call might
be needed for this document. * chairs to discuss internally and decide when to
do WGLC.

draft-asaeda-pim-multiif-igmpmldproxy   Hitoshi Asaeda  15 min
* IGMP proxy for multi-homing use case
* proposes the solution by following the requirement draft
(pim-multiple-upstreams-reqs) * there are list of open item, authors are
investigating & making progress . * working on controller based solution . *
add more detail on automatic configuration & signaling. * come up with updated
document & discuss in IETF 107

draft-venaas-pim-igmp-mld-extension     Stig Venaas     15 min
* motivated by some work in BIER
* BIER WG is working on IGMP/ MLD overlay
* BIER specific information would be good to get along with IGMP overlay.
* It adds additional data
* to accommodate the future extension , it would have extension type.
Toreless: if you do not support, just ignore the message.
Stig: it would be added that if you do not understand extension type, ignore it.
Hitoshi: IGMP query does not have version number.

* purpose of this extension is to identify which ingress router sent this IGMP.
Mankamana : Does this extension be applicable for new application if they want
to use it.

Adoption question would be asked in list.

Toerless:
If there is no good use case other than BIER , then we might keep it in good
shape in BIER before coming to PIM.

Ice: we might not need different use case.  Add different document one for BIER
& IGMP .

draft-voyer-pim-sr-p2mp-policy          Hooman Bidgoli  15 min

* Spring does not handle multicast related work so this work is forwarded to
PIM working group.

Toreless: is forwarding plane same as mLDP & RSVP-TE
Hooman: Yes.
Toreless: Why do we need this document ? It is just changing the name of
semantics. Hooman: controller can provide traffic engineering . Toreless: its
just MPLS forwarding . Use of SID is not useful . Hooman: To have discussion
offline. Toreless: How does it work with SRv6. Hooman: SRv6 is draft under
work. Toreless: why not make as controller based multicast solution . Why to
complicate. Ice: SID is same as Label Ian: need more thought instead of just
talking about high level solution . Toerless : this document is not ready at.
It requires more discussion. Ian: Its highly pre mature to ask for document
adoption.

draft-liu-pim-assert-packing            Mike McBride    10 min

Stig:
* It may be good to get rid of assert. But it has to be use. Its good to
combine . And it is worth doing * may not needed advance packing , simple
packing might also be good enough.