[MBONED] Quebec MBONED draft mtg mins

[Leonard Giuliano <[e-mail]>]

Special thanks to Toerless for taking such excellent notes last week. 
Draft minutes below- please take a look and provide any 
additions/subtractions/corrections you see.


Agenda
   review status of work items

    draft ietf-mboned-addrarch is now RFC6308
    draft-ietf-mboned-mtrace-v2-08 to be revised after IESG eval
    draft-ietg-mboned-ssmping-08 in IESG evaluation
    draft-ietf-ip-multicast-pm-requirement-01
     Author commented on status.
    draft-ietf-mboned-mcaddrdoc-01
     stig is going to talk about it.
    draft-mboned-mcaddrdoc-01
     Peter Koch posted 8 weeks before deadline. GOt feedback from Stig,
     can not go forward because there are known issues. Subject to further
     WG feedback edit out problematic element.

    charter issues.
     Ron Bonica, AD. Have taken beating by IESG for protocols because
     it is out of charter. Proposes to update charter to indicate that
     we do not do protocols in this WG unless we do.

     Lenny: Interpretation of charter is to not do protocols that
     are routing and membership signaling.

     Greg - AMT got into mboned because of request by the IESG after BOF
     in Vienna and because multiple competing proposal where made.

     Ron aggrees that we can do operational protocols, but not routing
     protocols.

     Greg asking Ron what the charter text suggestion is. Ron recommends
     squishy text.

   draft-ietf-mboned-mcaddrdoc

     Stig presenting. Simple draft to define what addresses shuold be
     used in documentation. Includes example addresses IPv4/IPv6,
     ASM/SSM, well-known/GLOB/unicast-prefix based ones.

     Few changes since last IETF.
      - removed allocation for SSM
      - added GLOB, unicast-prefix IPv4/IPv6, embedded-RP

     Greg complains about insuficient readership/review. Please read.

     Tim Chown asks about mails from yesterday mails about redirecting
     traffic for AS and wanted to know if this applies to multicast.
     Stig says it is more difficult for multicast.

     Bill A reads from email about AS112 and reverse lookup. From William
     Sotomeyer

     Peter Koch. Proposes to cover in context of mcast.arpa.
     Stig: There is some /24 allocation for documentation prefixes.

     Peter Koch not concerned because he does not expect a lot of
     traffic to DNS to be caused by this.

   draft-chown-mboned-multicast-filtering

     Tim Chown (author):

     Initial rationale of draft: 234.0.0.0/8 (RFC6034) still seems to be
     filtered in many networks. Asking for operational feedback to summarize
     in draft.

     Also targets to survey discovery mechanisms

     Greg: HTTP ? No, not considered, only SAF.

     Responses from academic oriented lists, janet(UK), Internet2(USA)
     Dozen of responses about border and MSDP peer filters

     Scopes learned from feedback
      - Organization border
      - MSDP peer filters (same as org, but also excluding SSM)
      - intra-organization
      ...

     Topics raised
      - no direct responses mentions 234.0.0.0/8
      - TTL filtering seems obsolete
      - some commonalities in filtreing of specific IANA
        assigned addresses under 224.0.0.0/8. How arbitrary is the filter
        list here ?
        Greg: Where are those filters applied ? For PIM joins ?
        Not sure.
      - varying use of RFC2365 scoping within sites.

     Aggregate filter list slide lists summary of prefixes
     filtered in responses. Filtering inconsistent across all feedback.

       Greg: General problem in IETF. Applied inconsistent applied policy.
       Question to AD. What eg: does IANA do about unicast filtering.

       Ron: Short answer IANA does do nothing. Long answer: There is not
       much what IETF can do, there is no policy application police. Can chase
       wrong policy implementation in opeational groups like NANOG/RIPE,
       but nothing else. In unicast world you can complain to upstream
       network. Suggests to also try this in unicast, eg: contact the folks
       who misapply filtering policy.

       Lenny: So this is a survey, but less so a recommendation ?
       Tim Chown: First state, showing what is being done. Would be good
       to come up with recommendations.

       Lenny: Unicast never routes unicast blocks that do not belong to
       anybody, so he is wondering why there is permission for equally
       unassigned blocks are mostly allowed in global internet (eg: 225/8).
       Agree/Disagree ?

       Ron: When there was a large block of unassigned unicast those would
       be published for filtering - bogons. Now that all addresses are
       assigned this list is gone.

       Greg agrees with Lenny. Problem is that there is no guidance given
       to applications that want addresses. Used schemes such as expanding
       ring-search via multicast addresses. No address use recommendation
       never panned out.

       Stig: several applications want hard-coded applications to ship box
       from service with burned in addresses. Problem is this is often
       for site-local discovery but applies for global addresses.

       Stig is IANA expert for site address allocation (eg: doing review of
       requests).

       Finance market requests (stock market) and IPTV uses are asking for
       real-inter-domain used addresses.

       Greg: Even if we where to create a solution for address assignment
       there is no way these would be applied appropriately.

       Toerless: would be interested to know what rate of global address
       assignment is - eg: With prediction of current assignments,
       how long would it last ?

       Liming: General idea from day 1: Multicast addresses are not
       same as unicast. Not to be assigned statically.

       Lenny: There was an ad-hoc block. Greg: handed out via SDR.
       Liming: do not see documented guidance.
       Greg: Original intent of multicast by Deering is different from
       what application vendors today want to do. If there is no better
       solution, app vendors will continue to ask for such addresses.

       Stig: public registry exists, but no explanation how it should be
       assigned. Maybe we can create statistics about type of allocations.

       Lenny: DOcumentation for use of each block exists in draft/RFC.

       Peter Koch: registry at IANA web page. Still lot of addresses available.
       Wrt. bogon list, maintaining living list of changing objects is best
       not done in IETF.

       Toerless: SSM is better. Just exhaust global IPv4 addresses.
       Question: What global IPv6 ASM assignments exist ?
       Stig: Yes there are global ASM assignments, listed on IANA page.
       Mostly for local use though (service discovery type). Optimistic
       about us running out of ASM IPv4 addresses not sooner than IPv4
       multicast is replaced by IPv6.

       Liming: Question on filtering in draft. Does rthe list implies
       that other ranges are permitted ? Tim

       Lenny: List is game of wackamole. Thinks we should recommend
       blocking larger unused/bogon prefixes.

     Next slide: Topics raised(2)

     Next steps ?
       Extract recommendations out of this ?
       Need more IPv6 information into this ?

       Greg: Would like to move interdomain solution to SSM (Lenny, Greg,
       others). If there is going to be a filtering recommendation,
       then it should include a section to very simply state how simple
       filtering would be if a site only uses SSM interdomain (only permit
       232/8).

     Question for adoption as WG draft ? 10-15 yes. 0 No.
     question will also go to list.

   MBONED feedback on work in Softwires

     Slides:
       Multicast Extensions to DS-Lite Technique in Broadband Deployments
       draft-qin-softwire-dslite-multicast-04
       Xiaohong Deng

     Greg:  Last minute request giving update of work in other WG.

     Mechanism relies on stateless IGMP-MLD interworking function at receiver
     (v4 join -> v6 join and decap). And stateless IPv6-IPv4 PIM interworking
     function on first-hop network doing encap.

     Uses mB4 and mPREFIX64 and uPREFIX64 addresses.

     Greg: other mechanisms proposed only PIM. Why IGMP/MLD?
     Co-Author: receiver side in home on actual receiver LAN.

     Address-building:
       boudacair-behave-64-multicast-address-format
       ..

     Toerless wondering aobut use-case of v6-only network and ONLY good
     support for v4only sources/receivers. Translation of header v4->v6
     instead of tunneling would better support v4-only and v6-only receivers
     simultanesously.

     ??: Other solutions targeting translation, this one is only encap based.
     Argument against translation: Content provider claim that their
     packet must not be touched.

     Yiqun Cai wondering why to restrict to the case that CPE only does
     IPv6 towards network.

     Answer (co-author): Assumption of DSlite deployment cases is that
     CPE only gets IPv6 addresses.

     Yiqun: Could also let IGMP join go all the way to QR.
     Toerless: CPE could generate IGMP memberships even if it does not
     have an outside IPv4 address because IGMPv3 explicitly supports
     source-IP address 0.0.0.0.

     Will this solution support ASM and SSM ? Yes.

     RP-placement. Toerless: Should use same RP-placement recommendations
     as if this was a native end-to-end IPv6 solution.

     Request for joining discussion in softwires, WG/Mailing List.

   Discovery of optimal AMT relay
     Presentation by Bob Sayko.
     Draft name not mentioned.

     Toerless: issue of overload of A entries in in-addr.
     Stig: should maybe use amt.z.y.x.a.in-addr.arpa to look up the
     AMT relay for a.x.y.z.

     Peter Koch: proof point exists with old RFCs overloading reverse mapping.

     Peter concerned about whether or not we can expect for the reverse
     mapping to exist for sources.

     Address returned could be unicast or anycast address.

     Bill A. ... (did not understand the question)
     Is there is enough control to tell users which AMT relay to use ?
     Toerless: No. AMT model is SSM receiver. and gateway may not need to
     be directly integrated into

     Toerless suggesting a solution with additional DNS prefixes using
     same type of entries.

     Show of hands for adoption of draft as WG item.  10-15 yes, 0 no.
     Will also take to the list.

   AMT update
     draft-ietf-mboned-auto-multicast-11

     Greg Bumgardner
     - another revision will be required.

     GregS: Need normative reference (security section).

     Issue about mixed IPv4 in IPv6 or vice versa. The gateway does not
     indicate what version of protocol is used inside the tunnel, so
     relay does not know initially what type of queries to send, IGMP
     or MLD. Needs a solution.
      GregB: couple of possible solutions. indication in initial signaling
             packet

     Greg: Need to have AMT support v6 over v4 and vice versa, but do not
     take on any address or other translation - just tunneling v4/v6 over v4/v6.

     Lenny: Lets try to find the most easy solution.

     Discusssion about issues listed on larger protocol design issues.

     Lenny: Is it in spec to stop advertising anycast address when running
     out of resources ? It is now. Suggest to add headroom to avoid
     race-condition.

     No solution understood for issue 1 on slide (account for update
     message loss, reordering or rejection).

     Yiqun: Wants to put MTU limit on update message.
     Greg: Would require additional work in gateway to split up IGMPv3/MLDv2
     packets. Yiqun explaining how such large packets are a possible issue
     for routers to handle. Recommends for protocol messages to fit into
     IPv6 default MTU of 1280.

     Toerless: if we adopted the DNS draft and we would select different
     relays for different sources simultaneously, would this be supported
     by the current AMT-spec ? Greg: yes.

     Greg giving public chastizing for an open, transparent process
     improving this document. Send diffs to the list with explanations
     to allow creating agreement/disagreement.

     Discussion about possible larger changes in future versions of AMT.
     Toerless/Kurt: Let not change requirements against the forwarding plane.

     second point ?

     Mike McBride. Get it out as an RFC even if there are gaps otherwise
     it gets on forever.

     Toerless: Try to resolve security issues that would cause IESG
     refusal. Greg: If necessary change target status to experimental,
     but hopefully not needed.

     Bill: security section has to acknowledge existing security
     gaps. But they may not necessarily need to be fixed.

     GregB/Toerless: Existing vendor mechanisms to enforce state limits
     to minimize resource exhaustion due to attacks is something that should
     maybe added to security considerations section.

     Yiqun Cai: how about mtrace over AMT ?
       Need two things:
         - AMT-relay needs to accept mtrace packets coming in from gateway
           currently not included in spec (not possible right now because
           sourcing from gateway not supported).
         - add code-points for AMT tunnel into mtrace to indicate it in
           mtrace results.
       But does not have full solution together to propose text.