MBONE Deployment WG (mboned) IETF 68 Thursday, 13:00-15:00 ========================================================= CHAIRS: Marshall Eubanks Hiroshi Ohta Agenda bashing Order change: dino is the first 3 presentations Document status - No rfc's published after San Diego - None in WGLC - None in RFC-Ed queue - AD Evaluation: 3 drafts: -draft-ietf-mboned-maccnt-req-04 Pekka Savola- Quite a lot of comments in AD eval, do the authors need support from WG? Marshall- We need to talk about how to go forward today, there were a lot of comments on this doc. Hiroshi- The authors are preparing to address comments. It is taking time since there are lots of comments. Marshall- The summary of the comments is that this might be at the wrong layer. Comments that MAAA issues might be better dealt with on higher layer or application layer not normally handled by IETF. Also comment that these issues could be dealt with by walled garden approach and therefore maybe not part of mboned charter. -draft-ietf-mboned-addrarch-05 -draft-ietf-mboned-routingarch-07 Pekka Savola- Can I get a slide on the agenda about this? Chairs- Yes. Marshall- Publication requested on multicast mib Marshall asks Ron Bonica for clarification of status and how to shepherd Ron bonica - Should be the first doc I shepherd, should go to AD eval within next few days Marshall- Made some mistakes on paperwork, but it looks on track now Marshall: Request that mboned not be held at same time as routing WG that many of us want to go Ron Bonica: You need to select specific WGs that are conflicts Marshall: Wants input for ML about other conflicts ------ draft-ietf-mboned-ipv4-uni-based-mcast-03 ------ Dino, presenting for Dave Thaler because he had a schedule conflict - looking unicast based multicast address assignment for ipv4 - current status of 4-byte AS number space draft: now in RFC editor's queue - V02 of mboned-ipv4-uni-based-mcast was expiring so updated the boilerplate and dates for V03 to keep alive, no changes - issue exists in current 03 draft: Is space delegated to the subnet, or to the superblock? current draft implies to subnet, but this may be too restrictive. want text to say you can use a supernet or block allocation allocated for site. - wants allocation procedures that only require coordination within the subnet. when you don't care about the granularity you can use supernet. - found bug in BIDIR PIM that when you are using the superbock Marshall- who assigns superblocks? - /16 is called superblock, /24 is subnet Pekka: thinks good idea. hopefully dave will be able to find a reasonable definition to make clear who allocation goes to. ------ Report on AMT prototype implementation ------ Dino Farinacci - 07 submitted, not a lot of differences from 06, just normative references *Implementation Status: deployments happening and business cases developing for amt 1)-Cisco DC-OS implementation complete -had IPv4 support, added IPv6 support - unit and system tested out of business unit responsible for this OS. - software forwarding only - Includes VRF support - Based on-07 draft - runs on 3 platforms, which arent so applicable to the Internet Marshall: plan to make available? Dino: for testing yes, but not opensource 2) FreeBSD implementation--> UCSB & UTD ported to Linux got a copy at Cisco, fixed some interoperabilty bugs invite other implemntations 3) Microsoft -05 implemenation being updated to -07 hoping Dave Thaler can use the Linux implementation as a guide to update. Invite more implementations. UT and Cisco continue interop testing. Greg Shepherd will pilot deploy cisco and Linux gear in early April - Shepherd is first phase - looking at business cases, how to distribute content, quality of applications, how to minimalize error loss,etc. - Kurtis at Netnod will be first to get hands on after that. Sweeps radio transmission: application 25,000 receivers, quite enormous - seems to be some real business demand for it Next steps- at Cisco determine plan for linksys plaform support - Release code to other Cisco OSs - Open deployment up to volunteers - Guessing can open to wider deployment by next IETF Marshall: will this be deployed on a linksys, a gateway? Dino: maybe. can see that. Marshall interested in testing and deployment Marshall: this is an SSM deployment Marshall: procedural question. need how many implementations? 3? Pekka-- no requirement for interoperable implementations Stig Venaas - for draft perhaps but not for proposed Ron - strictly speaking 3 implmentations applies only to the routing area. But implementations are good things. Dino - there's a implementation guide we have to do. Tim chown: security considerations are limited? Dino - just anti spoofing attacks no real authentication Marshall - my personal feeling is that the security implications are lower since it's ssm only Security sections.. more detailed considerations may be necessary Pekka- there was a security issue in draft about relay shake, but I think corrected. Any resources requried from iana? Dino - the asm or ssm is fleshed out if sources are benhind the gateway. both data and control? havent addressed in the implementation Dino cisco relay implementation does check outersource with innersource address Pekka: any reason not to progress forward? nothing has happened on the working group list in the previous six months Dino: only concern is we could find bugs later. dont know the linux, freebsd implementations.. guessing more like Microsoft Marshall- concerned SSM and ASM implementation are flushed out, but noone is planning to implement Marshall lets get a consensus Greg Shepherd - there are technology solutions already to provide sourcing into the multicast cloud Marshall - my feeling is that this is ready for working group last call Shepherd - agreed Marshall - consensus for last call ? 10 hands Stig - since going to do tests in next few months. maybe best to waste for tests. David Kessens- issue last call and find out if people agree or not Dino - I don't know if there's any urgency before chicago Greg - interop test working out Marshall - this is not going ot go through in two weeks Dino - a little more work Marshall - you would prose waiting Dino - yeah Marshall - can't declare consensus if the implemntors don't have it Thinks more interops, maybe do WGLC after more interops ------ mboned-routingarch draft ------ - Pekka Savola, presenting : had been AD review issues - doc seemed a bit descriptive, not so much specific advise to operators - is informational better than BCP? - Pro for informational: easier for approval - BGP- requires wider IETF .. good since it obsoletes stuff from other groups, obsoletes some standard track docs Dave Kessens- still the ops ad for two days - if you're concerned about cross area review it's still up to you as to how to handle. it depends on meaning of obsoletes.. but if replacing another doc then more problematic. Pekka: second issue is Normative references-- might lead to waiting most in RFC editor's queue - related to isis draft.. could take time or not... maybe they don't need to be normative reference - DKessens-- concern about ref to addarch doc, likes to have normative refs finished up first Pekka-- maybe don't need to be normative reference Marshall: who to talk to resolve? probably AD DKessens: Decide what you want out of this then decide BCP and informative Marshall- aim to get this resolved by Chicago ------ draft-ietf-mboned-addrarch-05 ------ Pekka Savola presenting has sent some summary mails to ML in Dec, Jan. Great deal of discussion on list. Major issues: - WG has tried to revise IANA policy references a few times and failed was deferred in 3171-update (2002) and 3171bis (2004) - difficulty of reaching consensus on how to proceedis this worth solving? will require time and energy. it is in the charter. -some new hope eGLOP, IPv4-unicast-prefix-based not clear of impact IANA policies - doesn't explicitly say how should be changed. this is a major problem options 1) propose don't change IANA policies, but reword draft to remove indication - make specification 2) change policies is to make more difficult to get multicast assignemnt from IANA- to make some specification of requriement with expert review, could make stricter policy. Too complex? 3) make guidelines goal is to retain ranges for IETF, other SDO use and other cases where interop is important DKessens-- AD hat off. should decide first if change IANA guidelines first, could become a very deep discussion. Other issues from AD review: - 32-bit AS number holders have no GLOP, IANA allocations have a role? - Should MADCAP and eGLOP be made Historic? Tim Chown-- what about resurrecting G. Durand's draft / dynamic allocation of group addresses to nodes. referenced G. Durand's draft about IPv6 multicast address assignment with DHCPv6. D. Kessens-- doesn't think should reference expired doc Marshall what need to be done to get done? rough consensus to make wording non-normative D. Kessens-- advice on text to getting it done.. just write down the gap about MADCAP still no implementation Pekka- Dave says Windows deployment is being used in Windows Media Server --------- draft-ietf-mboned-multiaaa-framework-03 --------- presented by Sato - reviewed purpose of the draft and relation to mboned-maccnt-req - maccnt-req-04 completed WGLC, currently responding to IESG comments - Changes between 02 & 03 - clarification of Common usage models - Elaboration on API to map user IDs between providers - clarifications regarding Multiple User IDs - Description of Network Access Provision and Network Transit Provision as subset functions of Network Service Provision Next draft 04 - elaboration of meaning of management from NSP standpoint coordination with ANCP WG? --------- draft-ietf-mboned-ip-mcast-mib-05 --------- McWalter lastcalled by WG. Marshall got the process done, waiting for IESG comments Ron Bonica: any implentations? McWalter: not sure, but have requests from operators Ron Bonica: wants it implemented before RFC ideally --------- draft-ietf-mboned-lightweight-igmpv3-mldv2-00 --------- Hitoshi Asaeda no big changes since individual draft summary of draft - motivation: implified IGMPv3/MLDv2 to facilitate further SSM deployment - presents approach (see slides) - asks for review by group -implementation: 1 open source host-side implementation (BSD) for LW-IGMPv3/ MLDv2 should be available by Chicago. also hopefully multiple router-side implementations for LW-IGMPv3 and LW-MLDv2 Next steps: draft revision implementation- one open source host-side impleentation BSD for LW-IGMPv3/ MLDv2 by next IETF - 2 vendors support light weight version -if you plan please tell WG ML - Interoperability test Pekka: we use the earlier MIB that it is based on. Should look at the differences Comment by ??: can test syntax, but most importantly need to test usefulness by implementationss --------- draft-ietf-mboned-mcast-arpa-00 --------- Koch presents accepted as WG item mcast.net should be moved to mcast.arpa, therefore need policy on how to maintain proposals - Names for addresses from 224.0/16 - Labels follow host name rules - Remove entries for 224.1/16 and 224.2/16 - Also:re-order name servers should be synchronized with registry some entries to throw out of zone some names with white space. naming scheme seems to be freetext now names should be unique per group legacy stuff to take out of zone.. there should be a decision about certain addresses interaction with addarch-05.txt base on RFC3171 or rfc3171bis? Which v6 address to add? propose to push as BCP, since IANA guideline --------- draft-venaas-mboned-ssmping-00 --------- Stig Venaas tool for testing multicast connectivity using udp user specifies source address S,G useful how long before start receiving multicast can see router how useful? complements multicast beacons use adhoc tests also asmping -shows duplicates protocol overview message type one octet (Q or A) what to do if server overloaded? must refuse to reply? asmping security issues next steps - reserve port number of SRV name? reserve IPv4 address? Ron - concerned about another security issues-- spoofing .. create a loop Stig: requests group to adopt marshall will test seems like consensus to adopt, to be confirmed on the list --------- draft-asaeda-mboned-mtrace6-00 --------- Hitoshi Asaeda Motivation: provide IPv6 multicast traceroutefacility in multicast routers decided to ask if whether should be integrated in draft-fenner-traceroute- ipm-00 draft (mtrace) or separate draft presents differences from MTRACE - Require ICMPv6 type values mtrace6 uses - Allow to use link-local and global scope unicast addresses for routerfs response - IANA Issue: Need assignment of some ICMPv6 type values - need implementations -- any other implementations? Toerless - supports to merge the drafts Marshall- to early to call for adoption of draft take to list --------- Charter Discussion/Multicast survey status/AOB --------- Running out of time - supported proposals to 2 RIRs and got good feedback - not clear if should be RIR or IANA policy - Charter- presents current items for charter proposal - people out in the fields are wanting guidelines - RFC3171 does not to be updated - some drafts that were allowed to die - some AAA stuff - ssmping - Best current practices for multicast VPN-- need more discussions