Minutes IETF102: pim
minutes-102-pim-01

PIM WG notes

draft-ietf-pim-multiple-upstreams-reqs:
Carlos: Author to update document and upload new revision which would address
AD comments.

draft-ietf-pim-msdp-yang:
There was no response in WGLC.
There would be 2nd WGLC.

draft-ietf-pim-explicit-tracking-13:
Hitoshi: AD need some implementation detail, since document is experimental it
need to have some more detail. Author is considering it to change it to
informational document. AD has some concern over document so Author need input
from vendor about implementation. Mike: Will draft be in hold for now? Hitoshi:
Yes. Action Item: WG need to provide some help to author, to get implementation
detail to move forward.

draft-ietf-pim-igmp-mld-snooping-yang-03
Updated new version, 03. It was accordance with rfc6087
New update is expected with comment from Yang doctors.
Robustness variable range got changed.
Added example of instance data tree with JSON encoding.
Requesting WGLC.

draft-ietf-pim-igmp-mld-yang:
Waiting for AD eval.
Mike: to Alvaro, if Yang data model been reviewed.
Alvaro: He would review the draft.

PIM with IPv4 prefix over IPv6 NH:
Presented 2 IETF back. It got adopted as WG document
Author thinks it is ready for WGLC.
3 in room support none against.
WGLC to be done in list.

pim-reserved-bits:
It is intended to update PIM RFC to make sure bits are not marked as available
in PIM RFC . Extending Type space Discussions: Andrew: Do we need to solve this
problem?  We think right now there is no need. Toerless: We can procrastinate
it for some time. Ravinder : No need to update now Alvaro: If we adopt, we do
not need to publish. We can change the document as per need. So even if we
publish this document, it would have no impact on existing implementation.
Toerless: You can let it expire and bring it up when there is really need. Dave
Allen: Is there some way to change IANA policy? Alvaro: 4601 / 7761 does not
say how to assign bits. Another RFC took it. If some other WG assigns the
document, we have no way to block it.  Since we do not have allocation policy,
we can potentially allocate the space. Donald: You can have Ack to check if
implementation supports new type? Stig: New hello options can be added to check
if Extended type is supported. Action Item: Mike to check interest in list.

p2mp-BFD:
Presented in London.
BFD to use to monitor health of DR
There was discussion in list, and draft was updated based on feedback.
It would be good to monitor DR and BDR
Suggestion is to be used for PIM Assert too.
Stig: There are several implementations already.  This document does not
require mull mesh of BFD sessions.  There is no existing document in PIM
describing BFD uses. 2 people are for adoption, none against. Need to take it
to list for adoption call.

Framework for multicast applied to SR-MPLS:
Toerless: Is tree-SID proprietary?
Hooman: Tree-SID was never discussed in IETF.  Tree-SID was discussed in BGP-SR
TE draft. Mike: Since Spring is not accepting multicast related draft, it is
not part of their charter, it is being presented in PIM which we’ve agreed to
between the SPRING/PIM chairs. Toerless: State reduction is coming from
tunneling?  what is the reason to call it as MPLS / SR ? Initially it started
work as global SID , that was the reason it was named with SR Hooman: We need
SR type of solution of multicast.  Multiple solution exist, should it go in
single group. If there is one solution needed Toerless: Whether SR or MPLS ?
can we have technical reason to pick one above other.  Author to provide more
detail. First Presented IETF97 , Its updated new text and improvement to
algorithm in current version. Jeffery Zhang:  we still have state in core, as
long as there is replication point. It does not fit SPRING. In SPRING does not
need, single solution for all case.  Is there really gain with this solution? 
This could be one solution, using name framework in draft is not good. It does
not modify existing data plane solution. And this solution can be done with
existing MPLS. Andrew: multicast is not easy, by the time this become standard.
We might already have hardware which support other better solution.  Do we
really need complex solution? Hoomann:  It might be complex solution and might
not be useful.  It might need to make simple. Jeffrey Zhang: multicast is not
in latest SPRING. Is it not related to SPRING. Alvaro: It must be part of
multicast. Ravinder: Do not agree to use only BEIR , it would be good to have
multiple solution.  How would it scale for high scale? Andrew: We cannot have
multiple solution. We need to have proper technologies. We should have reason
to have some solution. Action Item: WG adoption call in list.

Reliable PIM Registers:
No update since 101
Working group adoption?
Lenny: MSDP is not problem here, real problem is ASM. You are moving all the
stuff from MSDP to other protocol.  Do not disagree with draft, but not agree
with strategy. Toerless: MSDP works only with IPv4. It can be implemented for
IPv6 too. It would be inconsistent. So, it’s good to have new document. Lenny:
We might still need intra domain ASM.  Should we move to new solution?

PIM NULL Register:
It was presented in IETF 101
Its packs multiple NULL register in single message
WG adoption call needed.

PIM graceful insertion and removal of PIM router:
Provides mechanism to gracefully insert and remove the PIM router in network.
Jeffrey:  it has been brought up before, it can be used in more general place.
Even for topology changes, it can be used.  Do not think signaling is needed. 
It’s all local behavior. Andrew:  No signaling is needed.  It works for most of
existing implementation.  There is other mechanism which provides 0 traffic
loss. Lenny: It could be generic case. Toerless: There might be already
existing document Ravinder: Need to prevent loop or duplicate traffic. Jeffrey:
Its almost same as MOFRR. More discussion in list.

IGMP / MLD standard status:
Discussion to see if IGMP / MLD different version document should be moved as
standard. Discussion was from MBONED . Alvaro : WG can do whatever looks good.
Either absolute the document.   Or change the status as Historic.   Process is
status change document, which would explain why we are doing it.  If
justification is bigger or there are section, then it might be actual draft
which goes through all of the discussion. Andrew: if it is historic, can we
still make some changes? Can it be changed again? Alvaro: Since it goes through
all process, theoretically it should not be changed in future. Andrew: Some of
the changes can be done quick. More discussion to happen over list and move
forward with next step.

DR load balancing:
History of draft and current status.
1 hand in favor of drlb none against wglc will take it to the list.

Backup-DR:
How is it diferent from pim dr improvement
Lenny: strikes me as a narrow case. Still have failure detection with/without
this. Just reducing join latency on one router. Only solving join latency on
one hop. There’s MOFRR that kind of solves this problem. Mankamana: problem
statement is the exact problem. Can we do it with existing hellos. Lenny: do we
need to specify this in a wg doc more of an implementation issue. Ravinder: no
real problem on SP network because its already subsecond. We solved this using
other methods. Already other options that solve this problem. Mankamana: if its
in the protocol its on a as needed basis. Some customers need faster
convergence. You can still go with the existing pim dr model. Andrew: second
Lenny. Informational draft perhaps. Shouldn’t be specifying. Stig: for those
who don’t need it to be specified, do you see this as being the same for the
current wg draft. Lenny: just seems like a small optimization for a small
failure. Stig: we have two drafts in the same space. Lenny: just don’t need
changes to the protocol.

Graceful-dr-shutdown:
New hello option saying going in maintenance mode.
Lenny: confused about the assert part which is usually for a transit lan, they
don’t usually occur on the lan with receivers. Are they pim asserts and why
needed? Mankamana: yes, pim asserts. Timing for leaving and taking role. Assert
is one of the mechanisms but open to other options. Lenny: why just not send a
lower DR priority and the other will take over. Mankamana: that is one option.
This is to avoid any traffic loss. You will have to give other DR the ability
to form tree and start forming. Lenny: I set my dr priority to 0 and keep
forwarding until I see someone else forwarding. Seems like an implementation
thing. Could be specified for experimental. Not worth changing the protocol.
Ravinder: receivers don’t take two copies of the mcast copies anyway. Stig:
either you accept gap in packets or you try to make it smooth like this where
you will get a duplicate packets or two. Have to choose one or the other.
Lenny: what if he sends join to the backup dr. would that work. Then he can
prune his branch. Financial guys have problems with duplicate packets. Lenny:
lets say 110 his upstream link dies, his shortest path could be one of the
other 3 routers. Stig: you still have the assert problem.