[MBONED] Draft minutes of the mboned session in Prague (IETF-68)

Hiroshi Ohta <ohta.hiroshi@lab.ntt.co.jp> Thu, 19 April 2007 03:01 UTC

Return-path: <mboned-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeMuB-00015n-MT; Wed, 18 Apr 2007 23:01:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeMuA-00015f-Og for mboned@ietf.org; Wed, 18 Apr 2007 23:01:54 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeMu9-0002bT-JC for mboned@ietf.org; Wed, 18 Apr 2007 23:01:54 -0400
Received: from sfs2.rdh.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.rdh.ecl.ntt.co.jp [129.60.39.117]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3J314O5024326 for <mboned@ietf.org>; Thu, 19 Apr 2007 12:01:52 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by sfs2.rdh.ecl.ntt.co.jp (MOS 3.8.3-GA) with ESMTP id AHM57872; Thu, 19 Apr 2007 12:01:52 +0900 (JST)
Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 929EF20AE2F for <mboned@ietf.org>; Thu, 19 Apr 2007 12:01:51 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4E06A20AE29 for <mboned@ietf.org>; Thu, 19 Apr 2007 12:01:51 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3J31oG1011821 for <mboned@ietf.org>; Thu, 19 Apr 2007 12:01:50 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3J31o6D017708 for <mboned@ietf.org>; Thu, 19 Apr 2007 12:01:50 +0900 (JST)
Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3J31oCa017695 for <mboned@ietf.org>; Thu, 19 Apr 2007 12:01:50 +0900 (JST)
Received: from hiroshi-tp4.lab.ntt.co.jp ([129.60.13.238]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l3J31nVp026386 for <mboned@ietf.org>; Thu, 19 Apr 2007 12:01:50 +0900 (JST)
Message-Id: <6.2.3.4.2.20070419114615.03dfc060@imf.m.ecl.ntt.co.jp>
X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2
Date: Thu, 19 Apr 2007 12:02:11 +0900
To: mboned@ietf.org
From: Hiroshi Ohta <ohta.hiroshi@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 509eeaf340e89c687918a6101c6def35
Subject: [MBONED] Draft minutes of the mboned session in Prague (IETF-68)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
Errors-To: mboned-bounces@ietf.org

All,

Attached below is the draft minutes of the last mboned session 
in Prague (IETF-68) based on the Joel's note (Thank you, Joel).

If you have any comment, please post it by the end of next week 
(i.e., April 27).  I uploaded this draft minutes to the web 
site also.  I will replace this with a revised one after reflecting 
your comments.

Thank you.
Hiroshi and Marshall


------------- draft minutes ---------------


MBONE Deployment WG (mboned) IETF 68
Thursday, 13:00-15:00
=========================================================
 
CHAIRS: Marshall Eubanks <tme@multicasttech.com>
        Hiroshi Ohta <ohta.hiroshi@lab.ntt.co.jp>
 
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  ---------   
   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 ---------   
 
   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’s 
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

-------------- end ----------------




_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned