Minutes for MBONED at IETF-94
minutes-94-mboned-3

IETF 94 Yokohama
MBONED Mins
Thurs, Nov 5, 2015
5:40-6:40PM
Rooms 411/412

Note Taker: Mike McBride

Audio Log:
http://ietf.org/audio/ietf94/ietf94-rooms411_412-20151105-1740.mp3

Video log:
https://www.youtube.com/watch?v=eB6U1FEUKjo
http://www.ietf.org/audio/ietf94videos/IETF94-MBONED-20151105-1740.webm

Jabber log:
http://www.ietf.org/jabber/logs/mboned/2015-11-05.html

Status of wg items
-mtrace- been around a long time. authors requested WGLC. hard to take a LC.
        -no one read latest draft- need people to read and comment
-peering draft- some useful feedback from other ops list (I2)
-wifi mcast problem draft- some have read (~5), all support adoption
        Stig/Mike- IETF's role to define problems, IEEE's role to provide
        solutions

Interdomain Peering BCP- Percy Terapore presented
its in last call. last call comments and responses.
2 substantive comments.
general comment from Dale Garder: this would have been good 10-15 years ago, so
why now? response: there is  a significant increase in video delivery and
distribution via CDN's and industry acquisitions (eg ATT & directtv merger).

comment: why assume only compatible protocols across administrative domains?
response: incompatible protocol resolution may require new rfc in its own right:
out of scope of bcp

comment: add text to guideline c for policy to allow certain groups only from
administrative domain 2.

section 4.3 most telling comment: is ietf dictating how to operate ones network?
response: absolutely not

section 5: add description for looking glass style

section 6: test should be added to invoke bcp-38 style filtering. something
like each multicast peer MUST (can you say MUST?) employ BCP-38 style filtering

Lenny Giuliano comment: document is too long. answer: if 2 operators intend to
setup a multicast peering arrangement, then they will need to read.

Lenny Giuliano - general comments response to comment 2
greg: to think we are going to have billing points granularly defined on each
point is putting a lot of pressure on bcp. greg: articulating requirements for
ASM would unnecessarily extend the document. stig: its fine to focus on SSM,
but ASM is done and may be more useful to document Toerless: help simply
platform and design considerations. the hops inside the network with AMT it may
not be clear its beneficial. you don't want to do two forwarding planes in
hardware. Moving to AMT may be good. Greg: address comments on list and rev the
doc then publish and ask for list comments.

Optimal AMT Relay (draft-nortz-optimal-amt-relay-discovery-00)- Percy Terapore
presented Scope: develop RFC for finding an optimal AMT relay via a DNS based
procedure in an SSM multi network environment, where connectivity between
networks may or may not be multicast enabled. -uses dns to find nearest AMT
relay, also considers load -Shep- how does it know shortest path to receiver?
-Percy- authoritative DNS server does more than just DNS -Shep- SDN-like
entity! -Shep- Who has read, who understands the problem?
        Support adoption?: 3 hands in support.  Will take to list.
-Shep- pls read draft and comment on list

Mcast vs WIFI- Mike McBride presented
-lots of discussion on multiple lists
-Brian Habermen creating a new wifi-mcast list.
-this draft documents the problems, describes some workarounds
-stig: we need to document issues and go to ieee and say something needs to be
done. -Joel- IEEE to create effort to fix, want to corral all relevant
conversations -Toerless- focus on signaling, not data -Mike- MBONED should lead
this effort to define problem -Joel- newer solutions coming- other problems are
multiple antenna's beam forming towards a single client. Not helpful for
multicast. -suggest adoption soon, will take to list -Joel- share draft with
INTAREA, as discussion is emerging there (should adopt in MBONED)
        -multidiscipline effort, good to contribute here
-add toerless comments, add him as author, then wg adoption call. 5 in favor of
adoption.

Addr Acquisition for diff IP versions (multrans-addr-acquisition-06) Lionel
from FT presented solve issue when different ip version between source and
receiver. -3 solutions, no conclusion on which is best changes from -05 to -06:
delete the multicast transition or multrans words in the document. It applies
to all mcast use cases. If the change is accepted by the working group, then
WGLC? -who has read? authors and chair -short, simple draft- pls read -rev doc,
ref changes, send to list -should be updated to remove multrans to something
else. Its informational. they will rev it then we will ask for WGLC.

Shep- read drafts, respond on list!