[MBONED] Mboned 80 draft minutes
Leonard Giuliano <lenny@juniper.net> Wed, 30 March 2011 13:36 UTC
Return-Path: <lenny@juniper.net>
X-Original-To: mboned@core3.amsl.com
Delivered-To: mboned@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F423A6B51 for <mboned@core3.amsl.com>; Wed, 30 Mar 2011 06:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.351
X-Spam-Level:
X-Spam-Status: No, score=-106.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRWxcnj6G7RY for <mboned@core3.amsl.com>; Wed, 30 Mar 2011 06:36:15 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 161353A6B11 for <mboned@ietf.org>; Wed, 30 Mar 2011 06:36:15 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTZMyMWNkZ9COD6CURAG1vtPIBKF7++CV@postini.com; Wed, 30 Mar 2011 06:37:54 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Mar 2011 06:35:22 -0700
Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p2UDarv94018 for <mboned@ietf.org>; Wed, 30 Mar 2011 06:36:53 -0700 (PDT) (envelope-from lenny@juniper.net)
Received: from zircon.juniper.net (localhost [127.0.0.1]) by zircon.juniper.net (8.12.11/8.12.3) with ESMTP id p2UDarfA093222 for <mboned@ietf.org>; Wed, 30 Mar 2011 06:36:53 -0700 (PDT) (envelope-from lenny@juniper.net)
Received: from localhost (lenny@localhost) by zircon.juniper.net (8.12.11/8.12.3/Submit) with ESMTP id p2UDarGq093219 for <mboned@ietf.org>; Wed, 30 Mar 2011 06:36:53 -0700 (PDT)
X-Authentication-Warning: zircon.juniper.net: lenny owned process doing -bs
Date: Wed, 30 Mar 2011 06:36:52 -0700
From: Leonard Giuliano <lenny@juniper.net>
To: MBONED WG <mboned@ietf.org>
Message-ID: <20110330062926.R92821@zircon.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Subject: [MBONED] Mboned 80 draft minutes
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 13:36:16 -0000
While it's still fresh on everyone's minds, here are draft meeting minutes from today's MBONED mtg. Please take a look and let me know if you see anything that should be added/modified. And thank you Stig for taking notes. **** ietf80 mboned working group status pub requested drafts: mtrace, Ron had some issues, Hitoshi waiting for response. Ron says owes review for mtrace. ssmping should go to ietf last call soon. AMT has new editors, should be almost done. Explicit tracking draft probably going to pim wg. Stig presented mcaddrdoc Hitoshi: How is this different from Peka's draft Stig: This is for documentation purposes only Tim: What's the recommendation for ipv4 unicast based addresses Stig: If you have a /24 uni, you get just one Tim: We found group address filters, 234 needs to get removed Is there a filter bcp draft? Lenny: Good point. Perhaps we need a doc here. Tim: Writing some docs.. It would be nice to point to an "official" doc, perhaps including the "why" certain addresses are filtered Someone: Second Tim's request Bechet: Isn't it time to focus on ipv6 and begin ignoring ipv4? Stig: This doc covers both Lenny: Who would like to see this as a WG doc? half the room - no discent Lenny: Who would like to take on the filter recommendation doc? Thanks Tim Limitations of SAP Greg notes that SDP can be done with e.g. a web page. Stig also noted that SDP can be done without SAP, and using different group addresses etc. Lenny notes that limitations of SAP are well understood. Says there are more effective scalable solutions now. Presenter: asking if limitations are well known. Hitoshi: Changed from requirements to limitation draft because requirements may indicate looking for new protocol? Greg: points out that SAP does many to many announcments. There are many ways to do one to many. Tim: Said something about issues? Greg: Says he sees some need to document SAP vs sdr etc. Tim: Volunteering for a new document Brian Adamson: Mentiones mDNS can be used, and possibly extended to site scope Lenny: Notes various issues with SAP, says should talk about various ways of doing content discovery ATT AMT trial Lenny: Noted that unicast and multicast both uses UDP so any firewall issues would apply to both unicast and AMT. Tim: What was the cause for a small percentage of users having trouble. Presenter: The previous mentioned firewall issues Thomas: Asked why ".......?" so low Presenter: Not sure why so low AMT draft recommendations Presenter: why anycast address restricted Greg: Says the anycast address has to be a prefix due to BGP filtering. Then just picked an address in that prefix. Thomas: Will talk about this later. Greg: SDP could be extended to include a relay address AMT draft update Stig: Fine with removing sourcing from doc Lenny: Agree Show of hands: lots of people in favor, non against Stig: Observing that more and more users behind the same IP address so may be more gateways behind the same IP address Teemu: Suggests may allow more tunnels per gateway address. Thomas: Says it may break things and not clear if good practice. Greg: Suggests could relax requirements Robert Sayko: Says a bit simplistic to restrict to one address and should perhaps be more dynamic. Lenny: MSDP per source limits limit number of MSDP SAs per source address works well, and says it may indicate per resource limit may work here. Greg: It's not that easy, may or may not be parallels, could be different deployment profiles. Lenny: Yes, need enough flexibility Greg Bauman: Points out spec doesn't talk about relay resource exhaustion. Hitoshi: Has some issues with the anycast IANA prefix? Thomas: Prefix does not have to be address from IANA. Hitoshi: Asking if anycast mandatory for discovery Greg: Says yes Thomas: It could be done anyway Robert: You could just use some other address Thomas: Spec doesn't prevent anycast Greg Bauman: Limiting amount of tunnels may require more often to do discovery to establish new tunnels. Robert: It is when you get an update you need to state that relay is overloaded, that is when resources are allocated. Robert: ATTs solution to gateway address change is to create a new tunnel instance, no easy way to correlate old and new tunnel instances. Thomas: So it is an incomplete solution? Robert: Unless you are on the wire and can snoop Greg: Asking if time to check all 2^48 is for checking all. Thomas: Yes, 2 years is worst case Greg B: A possible race condition related to tear down message. Says a session ID could be good. Lenny: Why not same checksum issue for IPv4 and IPv6 Stig: Problem is old IPv6 implementations and that they cannot always accept 0. Teemu: May be issue with intermediate devices Thomas: What do you suggest? Teemu: Some kind of test would be good. Lenny: Should not try to solve everything now Greg B: Yes, better allow some extensibility, e.g. a version field. Greg B: Could put proposed changes in a separate document. Thomas: Main thing is to keep it extensible Robert Kebler: Agrees better put it in a separate document. Greg: We found some holes thanks to trial. Now we have data, need a focused effort to fix big issues found, and at the same time keep it extensible. Lenny: Points out more implementations and tests. AAA: Greg: Extending AAA to AMT is one example of a future extension Greg B: this seems more an IGMP issue than an AMT issue. Jeffrey Zhang: wondering about AMT relay logging for billing etc. same problem without AMT. Lenny: Have you read existing mboned AAA drafts? Should look at multiaaa-framework draft
- [MBONED] Mboned 80 draft minutes Leonard Giuliano