[MBONED] draft meeting minutes

[Leonard Giuliano <[e-mail]>]

Please take a look at the notes from today's meeting while it's still 
fresh on the mind and let the chairs know if you see anything 
incorrect/missing.

Special thanks to Percy for the exceptional meeting notes.


MBONED Meeting Notes  IETF 88

1. Lenny presented Agenda

2. Lenny:
a. Greg Bumgardner AMT address issue problem (IANA reallocated block) & 
Congestion Control concerns from Transport Area;
i. Joel: Liaise number block issue with IANA & Transport Area issues can 
be resolved possibly with Gregs Transport document??
ii. Greg: Transport Area standing on assumptions that may not be 
relevant??
iii. Gorry: Possible for use of peewee to resolve CC  concern?? RFC may be 
available for circuit breaking mechanism?? To be emailed to Chair.
b. Mtrace Draft probably ready for Last Call
c. CDNi draft ready for adoption
d. MULTRANS Last Call summary:
i. Enough support to advance but still concerns with Use Cases  (some may 
not be relevant).
ii. Toerless may have neat solution

3. Jeffrey Zhang: Geodistribution I-D v3:
a. CDNi problems addressed  ensure multicast delivery where appropriate & 
restrict multicast delivery where not authorized.
b. Multicast Reachability control mechanism described.
c. Reachability signaling flows.
d. Exclusion signaling where not authorized.
e. Proposal  split original draft into 3 separate I-Ds with specific 
purposes.
f. Stig: Seems abstract  provide more specifics on geo part as this is in 
title but not in I-D. Jeffrey points to backup slide that shows this info. 
Add some more illustrative examples?
g. Jeffrey Haas  info there but should be more explicitly mentioned.
h. Stig & Jeffrey Haas exchange comments on how document can be improved. 
Maybe allow some more useful Use Cases. Point out other relevant drafts if 
possible (in idr??).
i. Lenny asked if draft ready for adoption? Stig believes draft is missing 
parts? Lenny proposes taking to the list for adoption.

4. Toerless: Immediate Options for Multrans avoiding NAT:
a. Use Case 1: Leverage this case to avoid NAT for v4 multicast ==> v6 in 
routers.
b. Use Case 2: Longer term use case (new v6 centric network designs). NAT 
can be simple static v6 ==> v4 multicast group address mapping.
c. Stig: Link local addresses considered as option? Also home gateway may 
need some addresses? Toerless responded positively. Stig approves of this 
approach.
d. Greg on the wall: Approves of this simple approach to resolve issue.
e. Lenny: Next steps?? Create I-D?? Toerless: Possible to Write up 3-4 Use 
Cases in I-D??
f. Simon: Question on Details on Step 2?? Toerless provides answers  Maybe 
home gateway issue may need additional configuration setup??
g. Tim??: Homenet gives IPv6 address?? Dont make homenet stuff or home 
gateway more complex but supports going forward.
h. Lenny: Source is v4 & receiver is v6  important to remember.
i. Stig: Get this documented & clear up problem statement.
j. Tina Tsou: Solution should not be in MBONED. Joel: Maybe solution could 
go to PIM WG if not in MBONED but MBONED can define problem statement for 
eventual protocol solution. Tina: Has cable market supported v6 for home 
gateways?? Toerless: If not v6 support then no multicast?? Majority of 
IPTV is over DSL and is running out of v4 addresses.
k. Simon: Really nice if ths could be in an I-D.
l. Tim: This is positive spin on use of Homenet  v6 architecture
m. Lenny: Lets see a draft

5. Luis Contreras: MLD Proxy Functionality:
a. Use Cases where MLD proxy functionality useful for supporting multiple 
upstream interfaces
b. Draft History: Presented to PIM & MULTIMOB previously
c. Toerless: Why not PIM? Luis: PIM possibly too complex?
d. Stig: This is useful for MULTIMOB scenario.
e. Jeffrey Zhang: No difference between this and PIM?? Toerless: Document 
in problem statement.
f. Toerless: On matrix slide  first determine which uses to work here?? 
Any of these done with PIM & if so, how?? Are these too many use cases??
g. Stig: This came up because of MULTIMOB. This may be useful for 
multi-homing??
h. Lenny: Purpose of this I-D?? Looking for home in MBONED as this is 
kicked out of PIM & MULTIMOB?? Stig: With proper requirements this could 
be a home in MBONED.
i. Jeffrey Zhang: Clarify requirements scope?? Stig: No changes to IGMP 
protocols.
j. Toerless: Could this become MLD proxy routing?? Stig: That is in an 
RFC. Need to update that proxy for this scenario. Formulate requirements.

6. Bill Atwood: Multicast Access Control:
a. Trust relationships for Unicast between Source & User  Network is 
transparent.
b. Not so for Multicast: Many EUs & fewer streams from source.
c. AAA & QoS Issues  how can they be addressed
d. Network comes into play for AAA  use of ticket (solution 1)
e. Toerless: Why does network need to be protected?? At network level?? 
Bill: Do not allow traffic on subnet level if not authorized. Scope here 
is Access Control.
f. Greg: Content could be acquired illegitimately but if it is encoded 
then what are we trying to achieve??
g. Bill: Requirements for mechanisms for Access Control & specify 
Architecture for this.
h. Stig: Authentication server on the link?? Bill: PAA does not have to be 
on the link.
i. Stig: Docs only talk about group membership. Should they also talk 
about {S,G}?? Bill: Only looking at groups & not at technologies.
j. Toerless: How many entities under consideration? Content providers? 
Network providers? Bill: Only considering network providers to EUs. Good 
stuff here with Use Cases.

7. Percy: Discussing MC CDNi draft
a. Revision history
b. Has been accepted in Berlin as working doc
c. Vancouver new use case
d. Long AMT tunnel traverse entire AD-2
e. Have chained AMT tunnels
f. Lenny:  need new title for draft  eg.  MC peering between networks

8. Bob: AMT Multicast Based Method for Finding Optimal Relay Gateway Combo 
for AMT Tunnel:
a. Anycast Addressing Issue
b. Solution presented in Quebec
c. Two requirements for solution
d. Greg: Across network providers should have same DNS??
e. Bob: Provisioning type solution
f. Jeffrey Zhang:  Optimal relay should be closest to Gateway? Bob: Yes.
g. Stig: Question on DNS server lookup. All DNS servers be reachable by 
same Anycast address? Why? Bob: Answer to be provided.
h. Jeffrey Zhang: Best Relay for one source may not be best relay for 
anther source. Bob: Answer to be provided.
i. Jeffrey Haas: Same question as Stig  seems idea may be a unique 
approach.
j. Karthik: How would Gateway know if no multicast connectivity? Greg: 
possible.
k. Toerless: Question on relay in other network? Bob: EU is on second 
network. So purpose is not to find multihop tunnels.
l. Jeffrey Zhang: Why not multihop per previous draft? Bob: To be 
provided?
m. Lenny: Some thoughts on whether optimal could be overridden by EU. 
There are many ways to find optimal. So should there be a generic way to 
find optimal?
n. Greg: Should this be extended to support different policies?

9. Joe Abbley: Reverse DNS for Multicast Addresses:
a. Proposal: Naming scheme for v6 addresses
b. V4 Naming Scheme  clean this up in ARPA??
c. V6 Naming Scheme  similar approach to v4
d. Examples provided.
e. IANA Considerations
f. Stig: Looks good. What allocations should be in DNS?
g. Peter Koch: v6 still to be done. Can revive this work.
h. Toerless: Why are these not in IADDR?? (not sure if I got this right).
i. Stig: Happy to help with this work.
j. Joe: Next step to continue advance tis as a cleanup exercise. Peter 
Koch happy to help.