Minutes IETF104: rift
minutes-104-rift-00

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.