IETF 106 Singapore
MBONED Agenda
Thurs, Nov 21, 2019
3:50-5:20PM
Orchard


Jabber Log: https://www.ietf.org/jabber/logs/mboned/2019-11-21.html
Audio log: https://ietf.org/audio/ietf106/ietf106-orchard-20191121-1550.mp3
Video log: https://www.youtube.com/watch?v=ttGJyd5is2w

Note taker: Kyle Rose

-----

Notes take in etherpad at https://etherpad.ietf.org/p/notes-ietf-106-mboned

Text (from 12/12/19) pasted below for reference:

MBONED IETF 106 Singapore

Minute takers

    Kyle Rose


Bikeshedding on traceroute port conflict
~10 minutes

    Warren said he would push for IANA to reassign port if we really want him to


draft-mirsky-ippm-hybrid-two-step
draft-song-multicast-telemetry
Mike McBride/Greg Mirsky, 10 min

    IPPM (IP performance measurement) working on multicast

    There is an implementation, but might not be accessible by those outside the country in which it's hosted


LISP Mobile-Node
Dino Farinacci, 30 min

    Editor note: I recommend watching the video for this one because there's a bunch of jargon I didn't capture

    2 demos: unicast and multicast

    Phone is just for convenience of the demo; this is intended for constrained IoT-type devices

    Kyle Rose: Music player demo not convincing because players typically buffer a bunch in case of temporary connectivity loss

    Stig: Do you configure a static RTR on your mobile phone?

    DF: Yes

    Kyle: No STUN/TURN-style complexity for NAT traversal? No: connection to RTR is a simple PtP IP-encapsulating UDP tunnel

    Jake Holland: Can multicast functions happen in the underlay, leaving the overlay alone?

    DF: Segue to next slide

    Stig: ...

    DF: Also segue to next slide

    Toerless Eckert: ASM or SSM?

    DF: Doesn't care. If you want source-specific state, you can put that in.

    TE: SSM is really an access control mechanism

    DF: You could do access control via the mapping system

    Jake: Where do you get the ETR source IP for NAT to pass RPF checks?

    DF: For now, ETR is just statically joined to 224.3.3.3


Multicast to the Browser (MTTB)
Jake Holland, 25 min

    Kyle Rose: We expect to have a fight with the security area over the required length of the hashes given the timeliness of the data

    Jake spoke with Ben Kaduk and Dave Black about the appropriateness of adopting things like CBACC that might want to live in TSVWG, or AMBI that might want to live in the security area. Both thought neither of these were particularly complicated and recommend early review by the appropriate area, but not out of line for work like this to happen in MBONED.

    Warren is in contact with other area ADs

    Stig: Anyone else working on the receive API?

    JH: Integrated into PyTAPS. Max from TAPS is also working with it.

    Stig: Is security optional? What if browser is in a controlled environment?

    JH: I want this to work when deployed in the general case (i.e., on the public internet)

    Stig: I could change my unicast player to use this multicast receive API...?

    JH: Just port my existing player to webassembly and use this MulticastReceive API, and as long as my player can live within the guard rails, it's all good.

    Craig Taylor: Pervasive monitoring could be done via some protocol that centralizes all subscriber IPs

    JH: No one has yet said they will die on the hill opposing this work on that basis

    Call for adoption?

    Several people in favor, no one opposed