Subject: [MBONED] draft meeting minutes

From: Leonard Giuliano <[email-masked]>
Date: Mon, 4 Nov 2013 18:20:04 -0800

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.

---

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Tue, 5 Nov 2013 15:20:55 +0000

On this following issue - can anyone quantify,  over a time interval (years perhaps),  this problem.   I need to understand it better (would like to chat with Toerless) but if need be I can try and find out the size of problem at AT&T and any solutions already being looked at or even implemented.

My comments on following:
-I do think this is an important issue to address.   I think it becomes a key business problem for MC in general
-If I understood all of what Bill is proposing then I can sum up my biggest concern about the approach in one word "TRUST" ,    Content owners need/want complete assurance from network provider that a) their content is safe (meaning cannot be accessed by unauthorized EU  b) the content delivered to an EU is measurable and  that is for proper billing/accounting. And they need to know the measurement of data delivered is accurate.   If this is what Bill means by transparent then that is good,  but I was not sure enough information about this was explained (at least for me) in the presentation.   AT&T has been dealing with this issue for quite some time now......we have dealt with some very large content owners and providers
-I think a clear definition of a content owner and content provider needs to be made to avoid confusion.   An owner to my mind is a movie studio or a producer of the media.   A content owner can be a provider too,  but there are providers that are not owners (e.g. Akamai) and I think that depending on the business relationships (and even the relationship between content provider and service provider) entailed it might help to examine this in Bill's work...........just a suggestion
-I think some of this work could dovetail with the BCP Percy and I are working on (the MC CDNi document).
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.

In response to some of the questions raised please see inline.  These are my thoughts prior to going back to my colleague to discuss,  but wanted to address some of the issues today if I could
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.
To reiterate from the network providers point of view this is generally correct.  However, as mentioned there could be policies imposed that might require providing the GW with a Relay that is not necessarily the closest in a physical sense (e.g. Relay supporting a low utilized peering point to GW's network might be a better choice).  The AMT DNS in the source network could implement this.
g. Stig: Question on DNS server lookup. All DNS servers be reachable by
same Anycast address? Why? Bob: Answer to be provided.
Specifically,  we are talking about the AMT DNS (a special set of DNS set up for this solution).   In thinking about this I think the reason an anycast would be used is because it ensures that the AMT DNS reached is closest to the GW's local DNS.  At least that is how I read my colleagues paper (having only been able to read it last week I've not been able to delve into it with him before Vancouver.   Other reasons might be consistency of the process across networks providing AMT access interdomain.   Additionally,  I think it helps if the source network is in a federation of networks that all have multicast connectivity to the source.   That is my read on it,  but as soon as I can confirm with David I will get back to you on it.   I will say that after considering the comments made I don't think it is absolutely necessary to be an anycast address - particularly in light of the fact we also say policy might dictate which AMT Relay is eventually provided to GW.
h. Jeffrey Zhang: Best Relay for one source may not be best relay for
anther source. Bob: Answer to be provided.
This is true of course - but perhaps I misunderstood the question initially.  The problem is solved by provisioning the AMT DNS.
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.
This document does not include that in scope.  The assumption is that it can.
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?
After speaking briefly with Jeffrey I think I also misunderstood his question.  First let's be clear  on the fact that Percy and I are working on 2 documents.  One is the BCP for MC CDNi which describes various interdomain use cases and guidelines for technological solutions to the business issues.   The presentation I made was for a specific solution to one aspect of the BCP.  Namely finding the right AMT.    My fault for not making this clear.   My presentation does not directly involve multi-hop solution.   But,  yes on a point to point consideration of multi-hop it should work,  but again the solution does not encompass multi-hop end to end.
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?
Greg's point is a very good one.   Percy and I also discussed this briefly with Lenny after meeting.  We should expand this document to include other solutions (e.g. manifest file could easily include best interdomain Relay - a solution that works even if not very dynamic).   In that light we will probably rename the document to something like "Finding the right/optimal Relay".   I think we will also address what is "optimal"  as there could be several solutions.    Lenny has volunteered to become a co-author on the document.    I will post the current document later today.