RIFT meeting notes:
1, Chairs reported the status of working group. 
The protocol draft is going mature. The YANG model is on it’s way. The multicast parts is in discussion… (Please see slides)
AD Alvaro: We had agreed the threat analysis doc would go with the base protocol. If we are doing WGLC for the base protocol, we really need to work on the threat analysis doc now.
Chairs’ answer: Yes. We have also requested security AD early review.

2, Tony P presented RIFT update
AD Alvaro’s question: How is the mailing list? If it is too quiet?
Chairs’ answer: RIFT WG has weekly interim meeting. Many people have attend this work and discussion. They haven’t sent the mail to the mailing list.
Alvaro suggested there should be more discussion in mailing list.

3, Gregory Mirsky presented Extend BFD
Tony P’s question: Is this function like TWAMP?
Gregory’s answer: No. This is the data plane monitoring and measurement, and no additional control protocol is required.
Tony P’s question: Is jitter included in the function?
Gregory’s answer: The performance measurements are according to RFC 6374. The jitter can be calculated using the measured packet delay..
Tony P’s question: Is it any change to BFD discriminator? The path MTU detection is useful.
Gregory’s answer: No change to BFD discriminator.

4, Tony presented RIFT Hackathon

No question.

5, Tony presented RIFT open source process.

Alistair Woodman: Look forward to seeing the implementation in FRR.
Tony P: Bruno is interested in implementation by C language in FRR.
Jeffrey Zhang: To clarify, does the other (non-open-source) implementation has everything but security envelope?
Tony P: Correct.
Jeffrey Zhang: So the protocol development and design was accompanied by implementation.
Tony P: Yes.
Chair Jeff Tantsura asked Alistair Woodman: Does RIFT implementation have timeline in FRR?
Alistair Woodman: No.

6, Jeffrey Zhang presented RIFT multicast

Pascal Thubert: Another way to think is that you have a NBMA RPL in case of RIFT
Jeffrey Zhang: yes.

Pascal Thubert continued the presentation.
Tony P: There are multicast-capable and non multicast-capable nodes in the topology. The non multicast-capable nodes should be avoided in the multicast path.
Pascal Thubert: Yes. The non multicast-capable nodes will not be in the multicast path by signaling.
Bill Fenner: Do you imaging to dynamically decide if a group is going to have elephant flows?
Jeffrey Zhang: Elephant flows would be determined out of band, and then corresponding (*,g) trees will be set up. For example, a notification could be flooded on the (*,*) tree so that the senders and receivers will join the tree.
Sandy Zhang: Is there (*,G) and (S,G) state in the topology?
Jeffrey Zhang: For giraffe/elephant flows  there are (*,G-prefix) or (*,G) state. Forwarding is based on longest match - traffic will match either a (*,G) or (*,G-prefix) or (*,*) state.