MBONE Deployment WG (mboned) Thursday, December 6, 9:00-11:30, Vancouver ========================================================= CHAIRS: Marshall Eubanks, Hiroshi Ohta ------------------------------ *** Review and status of work items * no RFC published since last meeting - To be WGLC'ed soon to last call as soon as meeting over draft-ietf-mboned-ipv4-uni-based- mcast-04, old Dave Thaler draft that has been reivsed based on discussion in Chicago. no objections raised in room to WGLCing on list. * WGLC ---- - draft-ietf-mboned-auto-multicast-08 much discussion about issue IPV6 unicast, Marshall thinks based on what Magnus said that has been resolved. Thinks another draft revision is necessary. Greg: need to change draft dependent on and that has to be LCed first Marshall: we have a dependency here * RFC-Ed queue ------------ - draft-ietf-mboned-ip-mcast-mib-07 David Walter: rfc editors are finsihed with it. RFC 2 of 3 has approved. Waiting for Dave Thaler - draft-ietf-mboned-routingarch-12 ------------ - draft-ietf-mboned-addrarch-05 - Marshall: waiting for the uni-based-macast-04 to be finished (dependency) *** Active Drafts and related issues ------------- - draft-ietf-mboned-maccnt-req-05 Hiroaki Sato presentation: http://www3.ietf.org/proceedings/07dec/slides/mboned-0.pdf status: 04 cleared WGLC in 2006, 05 draft to address IESG discuss comments changes:- title, abstract, intro (clarify scope) - clarified relationship to MSEC - clarified accounting requirements - to support carrier grade NSP (millions of users, thousand of edge-routers) about 8-10 people in room have read, no one disagrees with taking to WGLC will take up on ML ----- - draft-ietf-mboned-multiaaa-framework-05 Hiroaki Sato presentation: http://www3.ietf.org/proceedings/07dec/slides/mboned-1.pdf background: request review to Radius Ext list this version to reflect feedback from Alan Dekok changes: describe general case in time sequence clarified user ID clarification AAA characterists specific to multicasting change terminology cache--> proxy because more appropriate change terminology mRACF (NGN term) & CAPCF --> MACF change AN to support general case hope next version, will be ready in a week or so about 5 people in room have read Hiroshi: with next version see the status and decide how to proceed regarding WGLC ----- - draft-ietf-mboned-lightweight-igmpv3-mldv2-02 "Lightweight IGMPv3/MLDv2" Hitoshi Asaeda presentation: http://www3.ietf.org/proceedings/07dec/slides/mboned-4.pdf mostly editorial changes, added terminology section LW message type is illustrated in a separate section Update router’s process for the new record set host side will merge records.. merging record is now same as fullweight version (removed optional) it is required. (original RFC wording not clear if MUST or SHOULD) LW-IGMPv3 lightweight version implementation is finished LW-MLDv2 in progress looking for people to implement want to implement for Mac-OS check Hitoshi's webpage about implementation Software based router implementation done by Huawei based on XORP1.4, not yet publicly available-- will be available finished both LW-IGMPv3 and LW-MLDv2 implementations tried compatibility test with Linx/NetBSD. Host Windows XP shows table of compatibility tests in presentation router-router and host-router circles mean test successful Next Step: need to Finish implementations and tests revise draft wants to do WGLC after next draft goal is proposed standardization Marshall: asks how much is saved with lightweight implementation Hitoshi: don't have precise numbers now but, code size is 30% reduced (70% of previous size) will send precise number to ML Dino: IGMP and snooping issues? done through L2VPN switches? Wei Cao (Huawei): [too quiet to hear] Dino: will be simpler, that's good. Hitoshi: we should send test conditions to ML since hard to describe orally Marshall : An interop document will be necessary to move to a proposed standard. Note that in any case, breaking snooping switches is BAD. Stig: going on the wire is just subset of normal IGMP, have trouble seeing how it could break Dino: expect nothing to break Marshall : need to verify anyhow. Trust, but verify. Hitoshi : This is simplification of existing standard, and is a "delta" document so far. Is it better to do that, or to repeat the existing standard in this document ? Marshall: question to AD. AD: citations and deltas are better than repetition Marshall: this would be informational? Ronald: does it change anything on the wire? no. therefore only needs to be informational. harder to publish if not informational. Marshall: doesn't change packets Brian Habernman: changes state machine, therefore should be experimental Marshall: start as experimental and see how goes wants to see WGLC after update and before next meeting ----- - draft-ietf-mboned-mtrace-v2-00 "Mtrace Version 2: Traceroute Facility for IP Multicast" Hitoshi Asaeda presentation http://www3.ietf.org/proceedings/07dec/slides/mboned-10.pdf submitted as WG draft Changes: mtrace v2 works on top of UDP both IPv4 and IPv6 are supported every packet has 64 bits length now - several bugs implying 32 bits length Future Changes: still need to address some items on "to do" list and received more comments for current version need to change several points Mtrace2 header- current version should be protocol independent - checksum can be deleted? is a point being discussed, would like opinions on this. - should be TLV format? another point needing discussion Stig: would be good to use TLVs and have a way to pass TLVs to be passed on by routers that dont understand them Hitoshi: will add some simple figures shows slide of current version shows response data slide. bit difficult to merge. on to-do list Inserted Adresses: this important to get opinion, IPV6 case needs to care. scope address. question what type of address to add? RT-A specifies RT-B's address with link-local address Marshall: unicast address? Hitoshi: talking about unicast may use link-local address for IPv6? can we use that ? Dino: what is the value? Marshall: will cause things to break? Dino: won't break but don't see value. only value is you can see number of hops Brian Haberman: what if wrote specification that says use interface address if greate than link local otherwise use global Bill Fenner: link-local address not useful without a corresponding interface descriptive. been using address for handles for interfaces. what are the interfaces? should we think of different way to identify interfaces? -- take to list - Hitoshi: "Counting the number of receivers" slide someone may want to use mtrace. in academic world. counting (e.g. router based) or estimation technique (sampling technique, timer based approach) shows slide with pros and cons. wants to discuss and see if this type of function to the draft Considerations: privacy, CP may not want to disclose number of receivers IANA issues: mtrace2 UDP port number should be reserved need IPV6 address.. Next step- reflect comments Bill Fenner: history of assigning same parrallel address in v4 and v6. Global group for this doesn't make sense anymore Marshall: are you saying that mtrace won't work? Bill: no. multicast replies are unlikely to work Interdomain Marshall: non-chair opinion. counting shouldn't be part of the draft, maybe another draft ----- draft-ietf-mboned-ssmping-02.txt Stig Venaas presentation: http://www3.ietf.org/proceedings/07dec/slides/mboned-2.pdf Many changes. no longer trying to be backwards compatible. new and better protocol but still similar but better. Make fairly generic. trying to allow flexibility in protocol. let implementations decide how to use. Work on both open Internet and closed networks. 2 new message types: Init message (before start pinging, can give me group to use?) & Server Response message flexibility of choosing groups, don't need group assigned from IANA actual pinging same as before. client can start pinging without initial handshake if it wants shows slide "how it works" initial handshake. 2 new messages and then the normal. Server Response message: mostly used in respone to Init if client juut starts pinging without a group. means don't ping me with this group. Ping Request message. Request must contain group address. Server might return session ID Next steps- need new name - decide whether to join G or (S,G) close to done just few more changes need review and feedback from everyone hasn't been implemented- would like people to try next revision might be ready for WGLC question: why need handshake? Stig: one issue if there are multiple people to same server they will all get pings needs name before WGLC - mping= but already used - mcastping was wondering if could be used for multicast beacon Individual Drafts ----------------- - draft-ycai-mboned-mvpn-pim-deploy-00 Mike McBride presentation: http://www3.ietf.org/proceedings/07dec/slides/mboned-6.pdf Mike: in mboned charter it mentions part of goal of group is to capture experience from those actually deploying mcast technologies. last time presented was opposition for making WG document tried to address concerns used term "pre-standard" no longer reference as best current practice changed title to be more specific mvpn pim use standard based mvpn draft not refering to Rosen draft fills need to document mboned deployment experience.. informational only only issue remaining that haven't been addressed: not technology in Internet. mboned charter only for Internet Yakov Rekhter: I think mboned is clear limiting to the global Internet, thid document has nothing to do with global Internet doc not acceptable because documents stuff already existing LVPN WG docs section on security is misleading section on scalability is poor on facts, like a marketing brochure Mike: last time you said you liked the draft but it just wasn't suitable for this WG. Interesting that you changed your mind. Another person: - a bunch of stuff in Rosen 8 which is pre-standard. For example Juniper doesn't support some stuff so operational issues. this doc doesn't belong here, doesn't belong anywhere. charter related discussion continues request that detailed comments be put on the ML Ron: we discussed before and need to discuss charter and global Internet issue Marshall: maybe would be good to expand authorship Brian: need charter discussion about global Internet issue Marshall: This is part of deployment experience. This would be an informational document. He could post as individual doc but wouldn't it be preferable for WG to review. Brian: IESG would probably still ask review Kireeti Kompella: wants to know how far to expand the charter. seems clear this document is outside the current charter Ron Bonica, speaking as AD 3 issues on table: 1) is it OK to come to an ops area at same time issue? yes it is OK. 2) whether is this in the charter? 3) is the quality high enough to be a WG document ----- draft-williamson-mboned-madp-00 Stig Venaas presentation:http://www3.ietf.org/proceedings/07dec/slides/mboned-3.pdf idea presented a few years ago at IETF problem to be solved: many application vendors hardcode multicast addresses application coders want zero config problem when try to deploy multicast nightmare to maintain access lists also not registered with IANA want solution with near zero integration with no hardcoded addresses want simplicity so application developers actually adopt MADP basics, very lightweight - important the spec works not just on local scope request contains a freetext string saying what application it is Clients performs expanding ring search- can search on local link depends on the application itself whether on link or site is better RFC2365- Administratively Scoped Zones have current scope addresses IPv6 MADP would like one group for this makes scope addressing easier Key question: why can't use existing procotols? DNS- not clear what name to look up SAP- too complex parsing SDPs, etc SLP- too complex and not deployed much Other? shouldn't rely on 3rd party infrastructure Shows Detailed slides on how protocol works Asaeda: have scoping question, do you care about global scop. example expanding link search could act like a DOS Stig: don't want to do global-scope Morin: couldn't you use DHCP? Stig: don't like using DHCP as generic discovery protocol. could possibly be used. Morin: maybe say in doc why not use certain protocols Stig: some protocols tend do be on local link Bill Fenner: why is MADCAP bad idea ? Stig: complex, 3rd party and not much deployed Bill: ok you need a server to do the application. MADCAP is based on DHCP... so much software almost supports MADCAP. microsoft had some stuff that supports MADCAP. Toerless: if not global scope, according to previous discussions today this discussion shouldn't be in this WG? Stig: this has impact on Internet Dave Thaler: High level stuff. two different problems. 1) server has to know what address to use. (allocation problem) and 2) client has to find out what address the server is using (discovery problem). MADCAP is allocation protocol. relevant to 1st case not second. there was a question on the list: MADCAP allocation is not relevant to this draft Marshall: is Madcap still used, not a dead protocol, right? Dave: not sure about use but it exist in clients for Microsoft. as for discover problem, the client wants to find out the mcast address (es) that the server is using. there is syntax and the behavior. Syntax that is used today is SDP (at least protocols using). if defining new syntax, need to say why necessary. Dave Thaler- your implied assumption is that there only exists only one instantiation of this application's context Stig: yes we want to keep simple Asaeda: this type is a discovery protocol. this wouldn't be necessary if there was a good announcement protocol. Stig: for that to work each vendor would need on server, some requirements, but could be possible 2 people in room read. decide whether to adopt as WG doc after another revision ----- -- draft-morin-mboned-igmpmld-error-feedback-00 Thomas Morin presentation: http://www3.ietf.org/proceedings/07dec/slides/mboned-7.pdf start from Problem Statement/ History -lack of resources, IGMP version not supported problem statement- useful to provide applications with feedback on these issues - DSL forum asked for this 2 years ago proposed magma- suggested solution not appropriate requirement formulated in mboned-maccnt-req feedback, informational only no compatibilitiy issues feedback can be sent in unicast if IGMPv2 used. open for discussion. host can interpret and inform the applications. New message containing - error type and subtype - if related to some specific group - proposed error types important question: in which protocol ICMP or IGMP with pros and cons for each ICMP already used for feedback intermediate router to hosts Stig: worried about caching. if cached too long would be bad. with access control might want to block some hosts not. - aim not to cover transient errors - caching is very short and temporary. local cache Toerless- maybe better to do IGMPv4? still systems not using IGMPv3 Dave Thaler: informational and errors. think should be ICMP error type and not informational type. there was interest expressed in DSL forum 2 years ago need to decide protocol before deciding the WG ----- - draft-morin-mboned-mcast-blackhole-mitigation-00 Thomas Morin multicast QoS / convergence unicast routing advertise a link while the PIM-SM adjacency on a link is not ready yet. e.g- results in traffic blackhole RFC4601- when a link comes up, wait few seconds before sending hello reply - should send hello right before joins Proposed Approach - having low impact on multicast routing without any interop issues same problem with BGP - proposed approach could be generalized next steps discuss pim hello adjacency improvements presented in OSPF stig:should present in PIM too toerless: should enumerate cases where there are actually problems. (i'm not aware of any) - problem for groups that define routing protocols. reason presented here is because not protocol matter ignoring hellos doesn't cover problem of misconfigurations some implementation already doing useful to document this would like to make WG document. co-AD-Brian- can use ML to discuss. leaning towards using ICMP. should discuss this. maybe good to combine efforts. ----- draft-ietf-mboned-mcast-arpa-01 Peter Koch presentation: http://www3.ietf.org/proceedings/07dec/slides/mboned-9.pdf doing without slides, not much time and PC issues. mcast.net domain was going to migrate. some policy is needed so ... can deal with it. No new version posted since last IETF. but progress with IANA. got extensive feedback to be incorporated in next version. needs lots of advice from WG. v4 is easy, almost done. v6 case is more difficult and need to decide as a group what to do. sent questions to ML wants 1 or 2 people to go through the v6 scoping issues with me. Marshall- we can talk afterwards.. shouldn't take too much time. Charter Discussion/AOB ----------------- General discussion Marshall: should we have an interim meeting? Dino: would be good to have a real working time struggle over where to actually hold such a meeting because everyone seems to be tired of flying in airplanes. It is noted that Seattle is between Tokyo and Washington. It is noted that is true for most of the planet. Marshall mboned has dealt with more than just the Global Internet we propose to add to global Internet "as well as other applications" Yakov: reads mail from ML to explain why this is an issue focus and mboned to move L3VPN forward referring to about mcbride draft (Ichi?) from cisco- already having discussions in mboned about non-global internet stuff Ron Bonica, AD, L3VPN chair and from Juniper for full disclosure: see conflict of Juniper and Cisco flaming spilling over from L3VPN, would like to keep this to technical issues Toerless- majority of stuff dealing with are enterprise therefore like wording want scope. want to include multicast services, not just routing (??)- "as well as other applications" would like more precise wording. Bill Fenner- like using wording "IP based network including the global Internet" and that should be used above too Stig: thinks this group should be work on all IETF based protools dealing with multicast -everyone here seems OK with expanding the charter Ron: IESG decides