2.4.9 MBONE Deployment (mboned)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://antc.uoregon.edu/MBONED/ -- Additional MBONED Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-12

David Meyer <dmm@1-4-5.net>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
David Kessens <david.kessens@nokia.com>
Technical Advisor(s):
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion: mboned@lists.uoregon.edu
To Subscribe: majordomo@lists.uoregon.edu
Archive: http://www.uoregon.edu/~llynch/mboned
Description of Working Group:
The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet. This activity will include, but not be limited to:

- Documenting deployment of multicast routing in the global Internet.

- Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies.

- Based on reports and other information, provide feedback to other relevant working groups.

- Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects.

- Update RFC 3171/BCP 51 based on experience.

- Develop a roadmap informational RFC that describes the current IPv4 and IPv6 IETF multicast architectures, including references to the relevant IETF documents and guidance for implementers and network operators.

- Complete the MSDP MIB

This is not meant to be a protocol development Working Group.

Goals and Milestones:
Done  Submit I-D on inter-provider coordination of the deployment of pruning mrouteds.
Done  Establish initial charter, goals, and long-term group agenda.
Done  Submit I-D outlining requirements for the existing MBONE infrastructure.
Done  Submit I-D specifying the use of administratively scoped multicast addresses (RFC 2365)
Done  Submit I-D specifying the use of native multicast where appropriate (e.g. exchange points).
Done  Submit I-D on IP Multicast and Firewalls (RFC 2588)
Done  Submit I-D specifying static allocations in 233/87 (RFC 3180)
Done  Submit I-D on debugging multicast problems.
Done  Submit final version of scope zone announcement protocol (MZAP RFC 2776)
Done  Submit final version of scoped address discovery protocol (SADP)
Done  Submit I-D describing ISP multicast deployment practices
Done  Submit I-D, with RPS WG, on extensions to RPSL to describe multicast routing policy
Done  Submit I-D describing extended allocations in 233/8 (RFC 3138)
Done  Submit I-D describing IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171)
Done  Submit I-D describing IP Multicast Applications issues (RFC 3170)
Done  Submit I-D describing Anycast (RP) mechanism (RFC 3446)
Done  Submit I-D describing Source-Specific Protocol Independent Multicast in 232/8
Done  Submit I-D describing MSDP Deployment Scenarios
Done  Submit I-D describing IPv4 Multicast Unusable Group And Source Addresses
Done  Submit I-D describing Embedded RP for IPv6 Multicast Address
Apr 04  Submit I-D on PIM-SM Multicast Routing Security Issues
May 04  Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast
Jun 04  Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51)
Jun 04  Submit PIM-SM Multicast Routing Security Issues to IESG for Informational
Jun 04  Submit MSDP MIB to IESG for Experimental
Aug 04  Submit IPv4 multicast address allocation procedures IESG for BCP
Aug 04  Submit IPv4/v6 co-existence strategies to IESG for Informational
Aug 04  Submit multicast roadmap/reference architecture document to IESG for Informational
  • - draft-ietf-mboned-ssm232-07.txt
  • - draft-ietf-mboned-auto-multicast-02.txt
  • - draft-ietf-mboned-msdp-deploy-05.txt
  • - draft-ietf-mboned-ipv4-uni-based-mcast-01.txt
  • - draft-ietf-mboned-ipv4-mcast-unusable-01.txt
  • - draft-ietf-mboned-embeddedrp-01.txt
  • - draft-ietf-mboned-rfc3171bis-01.txt
  • Request For Comments:
    RFC2365BCPAdministratively Scoped IP Multicast
    RFC2588 I IP Multicast and Firewalls
    RFC2770 E GLOP Addressing in 233/8
    RFC2776 PS Multicast-Scope Zone Announcement Protocol (MZAP)
    RFC3138 I Extended Allocations in 233/8
    RFC3171BCPIANA Guidelines for IPv4 Multicast Address Assignments
    RFC3170 I IP Multicast Applications: Challenges and Solutions
    RFC3180BCPGLOP Addressing in 233/8
    RFC3446 I Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)

    Current Meeting Report

    MBONE Deployment (mboned) Minutes for IETF 59
    Notes on Draft Minutes
    Bert Wijnen <bwijnen@lucent.com>: "W.r.t. the MIB issue... the minutes of 
    course need to state what was discussed. But....In SMIv2 (the language in 
    which we define MIB modules these days, it is NOT allowed to use 
    IPAddress anymore. One MUST use 
    InetAddressType/InetAddress. If you only want to require support for IPv4, 
    then you can do so in the MODULE-COMPLIANCE statement."
    Monday 03.01.2004 (0900-1100)
    CHAIR: David Meyer <dmm@1-4-5.net>
    Minutes recorded by Simon Leinen 
     o Administriva                                         5 minutes
       - Mailing list: majordomo@lists.uoregon.edu
         subscribe mboned
       - Scribe?
       - Blue Sheets
     o Agenda Bashing                                       5 minutes
     o Charter Update/Review                                20 minutes
     o Review and status of work items                      30 minutes
       Active Drafts
       draft-ietf-mboned-ssm232-07.txt                      5 minutes   
         Shepherd, et al
       draft-ietf-mboned-embeddedrp-00.txt                  5 minutes
    draft-ietf-mboned-ipv4-mcast-unusable-01.txt         5 minutes
    draft-ietf-mboned-ipv4-uni-based-mcast-01.txt        5 minutes
       draft-ietf-mboned-msdp-deploy-05.txt                 5 minutes
         McBride, et al
       draft-ietf-mboned-rfc3171bis-01.txt                  5 minutes
         Albanna, et al
       Expired Drafts
     o  PIM-SM Multicast Routing Security Issues and Enhancements
        Savola, et. al                                      10 minutes
     o Multicast Address Allocation Issues
       All                                                  15 minutes
     o MSDP MIB                                              5 minutes
     o Update on the IMDOC Initiative/charter issues        30 minutes
    Blue sheets
      Bashing 5 minutes
      Status of active drafts 30'
      MSDP MIB update 5'
      Charter update/review 10'
      IMDOC initiative 30'
      multicast address alloc 15'
      PIM-SM Multicast Routing Security Issues 10' (added)
    Status of active drafts
    draft-ietf-mboned-ssm232-07.txt for BCP
      Shepherd et al. 5'
      at the IESG
      basically finished
      normative reference to SSM, we figured out how to remove that
      normative reference to MSDP and PIM
        BCPs are treated the same as standard-track documents
        wrt normative references...
      Written up some text to ask for a variance in the procedures to
      loosen the reference conditions.
        Dependency on the acceptance of the variant text
        Expect >6 months for anything to happen.
      We don't want to advance MSDP
      PIM spec should be ready by San Diego
    draft-ietf-mboned-msdp-deploy-05.txt -> BCP
      McBride et al., 5'
      at the IESG
      Hard to do a BCP on an Experimental protocol
      Savola, et al., 10'
      Embedded-RP triggered discussion of security
      This document tries to analyze PIM-SM/MSDP/Embedded-RP security in 
        excluding Bidir-PIM (text contributions welcome if you think this is 
        excluding host issues (IGMP/MLD)
        excluding other protocols (DVMRP etc.)
          Joins to different groups
          sending multicast to empty groups
            encapsulated to the RP
            generates MSDP state
          disturb an existing group
        "aggravating factors" (catch-all)
          distant RP/source problem
            what if the addresses in PIM messages are invalid?
          RPF considers interface, not neighbor
            a problem with Ethernet-based IX'es;
            PIM should be modified
          No receiver information in PIM joins
            only DR knows the addresses joining to a group
            can't be used in policy etc.
    Toerless Eckert:
      One useful differentiation
        Whether or not you can create intra- or inter-domain DoS
        E.g. where IGMPv3 joins can be immediately transformed into PIM
        (S,G) joins, this opens up an inter-domain DoS threat]
      Threat summary table (see draft)
      Enhancements for Threat Mitigation
        retire MSDP for inter-domain
        implement some form of PIM rate-limiting or similar
        implement some "return routability" checks
            [before creating state]
          probably quite challenging to do properly
        fix new PIM-SM spec to use RPF neighbor not interface
      Going forward
        Rate-limiting difficulties
          a lot of different threats
          ...and different kinds of deployment
          should not harm legit traffic
          finding the right kind of parameters is very difficult!
            help appreciated
          one could even omit trying to find the optimal solutions
    Toerless Eckert: attacks against state in multicast are not 
    Bill Fenner: Can you expand on the PIM RPF problem?
    Pekka Savola: If I understand David Meyer correctly, the PIM spec 
    specifies that an RPF check returns an interface rather than a next-hop 
    David Meyer: RPF is a very weak policy mechanism.
    Bill Fenner: Just trying to understand which of the 
    exchange-point deployment issues we are talking about.
    Stig Venaas: This is only a problem for data packets, where one would have to 
    look at source MAC addresses - the source IP address would just be the 
    remote sender address.
    Take as WG item for Informational?
    Weak humming in favor of taking this up as a WG item.
    Will be taken to the list.
    Embedded-RP update
      Pekka Savola
      Changes since -00
      Many text changes
      [Lots of good comments received from Hugh Holbrook]
        "just a group-to-RP mapping mechanism" which cannot be 
        more text on RP redundancy and deployment tradeoffs
        clarify usability/scalability/security issues and refer to 
        add that the embedded RP mappings MUST be honored
      What didn't change?
        the group-id 32-bit -> 24 bits not done
          no proposals, no consensus => no change
      Ready for WG Last Call?
        IMHO, yes!
    Toerless Eckert:
      Did you move all the security concerns out to the mroutesec 
    Pekka Savola: No, not all of them but the text in embed-rp got 
    Toerless Eckert: In any case you should mention that the security issues of 
    Embedded-RP are similar to SSM (concerning creation of inter-domain 
      Bill Nickless, 5'
      presented by David Meyer
      Draft seems to be losing its focus
      Basic question on whether these kinds of ACLs should be documented in 
    this form.  
    Toerless Eckert: Not sure to which degree a draft is needed or useful for 
    John Meylor: We started out with a pretty clear set of addresses that 
    shouldn't be used.  Then we started adding more and more other 
    addresses that are likely to cause problems.  By now, a Web page is 
    probably a better way to publish this.
    IPv4 Automatic Multicast Without Explicit TUnnels (AMT)
      Dave Thaler
      Was recently discussed on the mailing list.
      Goal: solve last-mile problems for three situations
        receive SSM traffic even behind a NAT
        receive ASM traffic even behind a NAT
        source SSM traffic from public IPv4 address
      without requiring any state on infrastructure for idle hosts
        sourcing SSM traffic from a private IPv4 address
        sourcing ASM traffic
      Terminology: similar to 6to4/Teredo...
        native multicast - AMT gateway - AMT NBMA subnet
                           - AMT relay - AMT subnet prefix 
      Protocol overview
        use IP-in-UDP encaps (to traverse NATs)
        AMT single-host site just uses IGMP
        AMT site gw acts as an IGMP proxy
        IGMP joins and leaves are periodic since no query can be multicast 
    draft mentions multiple ways to implement
        site-site multicast goes direct, not via a relay
      After discussions with Dino Farinacci and Tom Pusateri(?):
      Protocol (latest thinking)
        3-way handshake for Reports
          Ensures return routability and mitigates DOS
          Gateway                          Relay
          Generate Noyce (e.g. seq#)
                    AMT Request(Noyce) -> Rnonce = 
                     <- AMT (Gnonce, Rnonce)
                        IGMP Query
                        AMT (Gnonce, Rnonce)
                        IGMP Report ->     No state created on relay until here
      Something for Pekka Savola and others who look at security issues to look 
    at further.  Handshake seems sufficient.
      Deployment Considerations
        Relays may be public (open) or private
          restricted to specific prefxies, etc.
        Clients are zero-config if use public,
          for private need to config relay name or addr.
        Can scale to more sites/traffic by adding more relays
          scales much better than tunnel brokers, however.
        AMT *sourcing* scales like replicated unicast over the AMT link
          Better than replicated unicast to all receivers
          Worse than tunnel broker solution 
            popular sources should get a configured tunnel instead.
      Open Issues
        Sourcing SSM from AMT site:
            [How does a relay communicate Join back to source?]
          IGMP Report or MSNIP from interested relay/site?
        Packet format optimizations suggested by Tom Pusateri
    Toerless Eckert: Why develop new tunneling protocol? Couldn't this has been 
    built modularity on top of existing tunnel mechanisms such as IPsec or GRE? 
    Don't see much additional value in a new mechanism except perhaps the 
    automatic discovery mechanism.
    Dave Thaler: 2nd question: Interest in deploying relays - relay to 
    Dave Thaler: Why a new protocol: In general, solutions you mention don't go 
    through NATs well (GRE, L2TP/IPsec).  Those that require a handshake 
    require state at the relay; thus they fall into what I classify as the 
    "tunnel broker" category.  There is no other solution that fulfills all the 
    Pekka Savola: Question about state: Do you consider as state when 
    something wants to join and the relay caches some information?
    Dave Thaler: Yes.  But this only happens after the 3-way handshake, so you at 
    least ensure return routability.
    Pekka Savola: The diagrams talk about relays, but it could be 
    Dave Thaler: Right.
    Pekka Savola: Doubts whether this will really work over NATs because of 
    keep-alive issues.
    Dave Thaler: Sourcing SSM traffic (site-to-site) from a private address is 
    out of scope.  You're right that this doesn't work if you source from 
    behind a NAT.
    Haixiang He: How do you protect the IGMP leave message?
    Dave Thaler: Same 3-way handshake
    Haixiang He: So you have the same overhead here
    Dave Thaler: Right, but you have to do this 
    Mark Handley: Do you *mandate* use of a cryptographic hash? I'd like to 
    leave this decision open as a deployment choice.
    Mark Handley: What happens if the request is lost?
    Dave Thaler: It will be retransmitted like in normal IGMP.
    Haixiang He: Report messages should be authenticated too.
    Dave Thaler: Authenticating IGMP is a separate issue, not really 
    specific to this proposal.
    Haixiang He points out possibility of spoofing Reports once the 3-way 
    handshake has succeeded.
    Dave Thaler: Yes, this is the same security characteristic as for other 
    return routability checks such as in TCP, Mobile IP etc.
    Mark Handley: This suggests that this hash doesn't have to be 
    Dino Farinacci: AMT request goes to a public address (Dave Thaler: If it's a
        public relay)
      In the draft, you do this (?) about once a day
      I think it should be done more frequently
      Should be better specified in the draft
    IPv4 Unicast-Based Multicast Addresses
        Dave Thaler
      David Meyer: THis is the first of a bunch of addr allocation drafts
      1/19 Mboned draft-01 submitted and posted on a Web site
      1/20-1/21 pseudo Last Call started and then canceled because it
      hadn't appeared in the repository yet.
        Thanks to Greg, Dave, and Toerless Eckert for reviewing anyway!
      David Meyer apologizes for slight procedural problem
        What category? (GLOP is BCP)
          Should /8 expire? (GLOP doesn't)
        "What problems does this solve?"
          4-byte ASes
          Multiple organizations within an AS
            [Example: Merit AS is used by all Michigan universities]
            Easier delegation within an AS
            Provides space to customer when AS owner is not 
            Easier debugging
              [for large sites such as MERIT]
        If developers hard-code addresses, bad stuff can happen
          [Example: you change ISPs after writing an application]
          No different from GLOP!
            Should say these mechanisms are for deployment not 
    Toerless Eckert: Big operational difference in that GLOP is limited to AS 
    owners (operators) who should make sure that this doesn't happen.  If you 
    give this possibility to any address owner, this type of abuse is much more 
    Peter Lothberg: If you ship an application that includes a hard coded 
    address, this address should be reserved by IANA and not by some 
    ISP/other registry.
    Dave Thaler: Yes.
    Toerless Eckert: Should the draft spell out which kinds of addresses 
    should (not) be used here.
    Dave Thaler: General issue: Should address allocation be implicit (as in 
    GLOP) or explicit (where you can reserve addresses e.g. through a Web 
      Albanna et al.
      briefly presented by David Meyer
      Going through allocated addresses in the IANA tables
      Try to reclaim for IANA:
        ST-Transient Block
        DIS Block
    MSDP MIB Status
    Bill Fenner
      Moved from MSDP WG to mboned because we wanted to close down the MSDP WG.
      Assumption: existing implementations based on -03 (IPv4-only
      Task (what we thought the task was):
        update -07 to back down to -03
        remove InetAddress*, etc.
      Make it as compatible as possible with the only known 
      Assumption was wrong: There are implementations based on -07
      New task: update MIB based upon -07 (republished as -08)
        Look at implementations
        Look at updated spec.
      Soliciting help with this
      David Meyer: What exactly is the requirement for publishing a MIB for an 
    Experimental protocol?
      Bill Fenner: It would be a useful thing, but yes, Procedurally we're not 
    obliged to doing this.
      Toerless Eckert: Why base on the -07 version of the spec?
      Bill: Seems to be more widely implemented than -08.
      Toerless Eckert: Differences?
      Bill: Address types were changed to InetAddress (to allow for 
    extension to IPv6).  We shouldn't do MIBs that are IPv4-only.
      Dave Thaler explains the official IETF policy on this.
      Bill Fenner: If we use IPAddress, we have to explain why.
      Toerless Eckert: Dislike anything that makes people think we could do 
    MSDP for IPv6.  MSDP has been an Experimental protocol for six years.
      David Meyer: Really only six years? Feels like at least ten.
      Toerless Eckert: Would prefer the effort to go into the important 
    multicast MIBs
          Conversion to InetAddress happened in March 2001
          Added Discontinuity Timers
      Charter update: What's New?
        Goal: Make sure we could admit IMDOC into mboned
        Discussion (where?) whether this was a directorate or not
        Triggered rechartering more or less by accident in the confusion after 
    Randy left.  But changes are benign/sensible:
          Update RFC 3171/BCP51 based on experience (June 04)
            IANA considerations
          Develop a roadmap of information RFCs describing the current IETF 
    muylticast architecture... (IMDOC stuff)
          Complete the IPv4 MSDP MIB by June 04
      IMDOC Update
      John Meylor
        Few comments on scope
          A general framework/architecture for guiding forward progress on 
    multicast issues in the IETF
            v4 and v6 for each component
            service models
        Architecture Components (Rough List)
    [the things in CAPS are actually in red and identify problematic areas.]
          Routing (congruent and divergent)
            RP/BSR Management
          Group Management
          L2 issues
          Transport Layer
          Reliable Transport
          Source Discovery/Session Control
    Dino Farinacci: Nothing on security?
    John Meylor: And on the next page...
      If you were to design and end-to-end service, would you find all the 
    components here.
    Haixiang He: What do you mean by session control?
    John Meylor: Not exactly admission and access control.  More how we can 
    identifies the sources and receivers of a group.  E.g. issue of dynamic 
    multi-source groups in SSM
    Colin Perkins: Concern about overlapping with the applications (and 
    transport) area if we include session control.  E.g. this group telling the 
    SIP group how to write SIP.
    David Meyer: We only want to provide a framework for talking about these 
    John Meylor: We're not trying to solve this within the source-group of 
    Mark Handley: [on Colin's question] There's a sliding scale of things that 
    are firmly in-scope for this, maybe in scope, out of scope...
    We have to be aware whether we want to describe where we want to be, or the 
    history, or the current mess.
    David Meyer: Effort draws on experience when trying to convince people to 
    deploy multicast.  Where is it that multicast isn't being considered where it 
    should? Document where the holes in the current architecture are.
    Mark Handley: Sounds more like a requirements document, rather than an 
    architecture document.
    Dave Thaler: Second what Colin and Mark said.  Can see 
    justification for at least two documents.  1: Document roadmap for things 
    that exist.  Probably the best focus for this ("IMDOC").  2: 
    Gap-analysis... more rat hole potential here.
    Toerless Eckert Eckert: What is the value if we don't identify gaps?
    John Meylor: Start by documenting the basic components.
        Components continued
            transit and access
            IP and MPLS
          Stack and End-User-Device Issus
          Application Issues
    Dino Farinacci: There are customer requirements for some form of 
    multicast fast-reroute.  Should there be a bullet item for 
    "convergence" or "join-latency issues".
    David Meyer: Mark, Colin etc. where should that be addressed?
    Toerless Eckert: Path selection, fast reroute, resource allocation are all 
    subsumed under Traffic Engineering (according to some marketing 
    Mark Handley: Gut feeling that "fast rerouting" is not 
    "architectural" enough to go here.  This is not to say that this isn't 
    *important*, but maybe not for this document.
      Proposed next steps:
        1. Identify most important topics to address first
          Focus is on analysis and clarification of the problem space.
          Address Allocation
        IETF60: ??
        2. Interested in contributing to various sections:
           contact John Meylor (jmeylor@cisco.com) and David Meyer 
        URL: http://www.1-4-5.net/MBONED/IMDOC
    Introduction to IPv4 Multicast Address Allocation Issues
    David Meyer
      We don't have a viable strategy to conserving the IPv4 address space.  
    Even is this is considered as IANA's responsibility, IANA only has the 
    tools that we give them.
      IPv4 multicast address space is a scarce resource
        People are starting to grasp this
      However, IANA is being besieged by requests for IPv4 multicast address 
    space.  This problem has been brought about by the fact that:
          There were previous "bad" allocations, e.g. (Nasdaqmdfeeds)
          Other people come and say "why can't I"
    http://www.iana.org/cgi-bin/multicast.pl (flowchart-type tool to 
    classify address needs) and/or RFC 3171/BCP 51 clearly aren't enough 
    (read: aren't effective)
    Peter Lothberg: Didn't we solve this problem with SSM?
    David Meyer: No.  I'll get to it.
    Toerless Eckert: Problem statement (that this space is a scarce 
    resource) is a little bit too compressed.  For example, global 
    addresses are often not desired but IANA doesn't seem to have 
    authority over Also we don't have allocation methods for 
    dynamic/temporary assignments. 
    David Meyer: Points well taken.
    Dave Thaler: Who are these requests (that besiege IANA) coming from? 
    Application developers, or deployers of existing applications?
    David Meyer: Both. No statistics on how this is distributed between this.
    Dave Thaler: Large number of application developers asking for a few 
    addresses each, and small number of deployers asking for larger spaces?
    David Meyer: Something like that.
        In practice, we're experiencing ...
        Basic Problems
          We thought dynamic address allocation was the answer
            later MALLOC
            both failed (in practice)!
              Those aren't solutions that people can field in their 
          So what's the problem
            No global dynamic address allocation (workable?)
            No lightweight Service Location Protocol (SLP?)
              Not a solution, too heavyweight
            Many applications with no definable scope (==global scope)
              Impossible to use admin space in complex administrative 
            SSM seeing limited deployment
            Oh, and bad precedent for many allocations
              Problem of IANA liability because this touches on business
              issues [Toerless Eckert remarks that this is the same for 
    unicast addresses - they also managed to change policies in the face of 
    Dino Farinacci: Just because it's not deployed... John Meylor: Should be 
    more descriptive breaking out the problem, so that 
    Mark Handley: MALLOC was intended as a replacement, but it failed among 
    others because it was linked to BGMP (thesis: BGMP was squashed by SSM). It 
    doesn't seem worth to solve the address allocation problem in the 
    absence of a routing protocol that routes this stuff. 
    Toerless Eckert: Enterprise-scope address space for discovery (with other 
    traffic using SSM).  1. Figure out better scopes; 2. Start taking money for 
    David Meyer: The economics of how IANA and the RIRs work are out of scope 
    Dave Thaler: What failed was not MALLOC but MASC (the inter-domain 
    layer). Failure of the top layer doesn't necessarily mean a failure of the 
    bottom layer. 
    David Meyer: We don't have a functional global address allocation 
    mechanism in the Internet today, right?
    Dave Thaler: Correct.  The closest thing we have today is GLOP. 
    John Meylor: Are you saying that we believe that there will be embedded 
    applications on the global scope?
    David Meyer: In the sense that you aren't able to define a non-global 
    David Meyer: SSM can often not be used because the node's IP address isn't 
    known a priori.
    Peter Lothberg: Why don't we write a lightweight protocol to resolve 
    addresses between nodes in locally scoped environments.
    David Meyer: Something like a lightweight service location protocol, 
    Dave Thaler: Do you think that the same questions apply to IPv6? My 
    answer: Yes AND no.  For deployers, no (no scarcity issue).  For 
    developers, the problem is the same between IPv4 and IPv6.  If you agree 
    that there is a difference, then the problem could be split 
    Toerless Eckert: The big issue is not that you have more addresses, but 
    that we have a clear, static, and well-known scoping model.
    Mark Handley to Peter Lothberg: In how far do you think MADCAP would solve 
    this problem?
    Peter Lothberg: If it was deployed and understood, then it might solve it.
    David Meyer: The whole point of this discussion is to find out what are the 
    open issues.  The basic problem is that the target audience for a lot of 
    these protocols didn't consider these applications developers.
    John Meylor: Whatever we do there's going to be some period where we 
    cannot solve the application developers' problems.  Maybe there should be an 
    address lease mechanism for those periods where we don't have an 
    effective address allocation or service discovery mechanism.
    David Meyer: See Alex Zinin's draft on such an approach to register 
    temporary pre-IANA code points.
    Mark Handley: SLP and MADCAP should solve many of these problems.  1. 
    People just aren't aware of them or 2. The protocols themselves have 
    Dino: The problem is that the IETF has too many solutions and not enough 
    clear directions on what to use.  That argues for e.g. mandating SSM as the 
    single way to go in the future.
    Dave Thaler: Probably lack of knowledge.  The places with access to the 
    MADCAP server code would be enterprises.  Those usually aren't the ones who 
    turn on multicast first.  Not aware of any issues with the protocol as 
    Peter Lothberg: The problems are locally scoped; not a real 
    Internet/inter-domain problem.
    David Meyer: I didn't say that.  There is no definable scope in these 
    John Meylor: Even if you could use a scoped range, there is lack of 
    knowledge in the application domain.  When David Meyer tells them you 
    could use this, they don't see enough evidence for this from the IETF.
    Peter Lothberg: I don't see an Internet-wide problem here.  There's no 
    multicast traffic to speak of in my little network (about 10% of the 
    Internet).  There's just a land grab issue, not an operational one.
    John Meylor: The problem is that you can never construct a service when you 
    cannot be sure that others won't collide with your addresses.
    Peter Lothberg: Should make dynamic address allocation very 
    lightweight in scopes where nodes can see each other.
    David Meyer: This process has really expanded my view on what people 
    understand as "the Internet" ["internet"?].  Being connected to a 
    transit provider is low on the scale of this.
    Toerless Eckert: Want public record of the exchanges between IANA and the 
    David Meyer: I personally don't have problems with that.  Writing a 
    document seems necessary to get anything going though.
    Stig Venaas: A protocol such as MADCAP alone isn't sufficient.  A 
    lightweight SLP would be very helpful for "zeroconf" applications.
    David Meyer: Yes but you don't have anything to point at right now.
    Mark Handley: What we need is a big disclaimer "You don't get what you 
    expect" (Multicast addresses assigned to them 
    Dave Thaler: To John Meylor: Indefinite-scope problem mainly a problem with 
    application developers.  As opposed to deployers e.g. NASDAQ 
    David Meyer: Even the NASDAQ deployment doesn't have a well-defined 
    scope: one island... and then a bunch of other islands.
    Dave Thaler: Missing on IMDOC list: What we used to call "Session 
    advertisements" (as in: SDP was supposed to be split into address 
    assignment and session advertisements).  The mechanism to allow 
    everybody who is interested in <something> to learn about it.
    Those protocols are good for finding things that exist, but cannot prove 
    that something doesn't exist (address allocation does this).
    Jon Crowcroft: What you're missing is part of normal protocol 
    evolution: You need an enforced address reclamation protocol.  "We're 
    going to take those back once we have figured out how to do this 
    Toerless Eckert: This goes back to how we manage unallocated 
    Jon Crowcroft: There was a day when we could enforce these things by 
    building protocols... now there are commercial issues involved, and I'm not 
    sure who can solve this - IANA/ICANN etc.
    We have a stewardship responsibility. 
    I wish we could have these discussions on the list by the way!!
        So what to do?
            Update RFC3171/BCP51 based on experience
            EGLOP (RFC 3137)?
            A few folks looking at lightweight service location
          In general, fit into the IMDOC framework
          Is anyone interested in working on this problem?
    If you're interested, send mail to John Meylor 
    (jmeylor@cisco.com) and David Meyer (dmm@1-4-5.net)
    - Adjourn 


    None received.