[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