home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mboned / mboned-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  5KB  |  153 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.                    mboned
  4.                    96.12.09 15:30
  5.                  Dave Meyer
  6.  
  7. Administrivia
  8.   o mailing list mboned@ns.uoregon.edu (majordomo)
  9.  
  10. Status
  11.   o have some active drafts
  12.     - pruning
  13.     - administrative scope
  14.     - will have new issue of seneria
  15.     - Eliz Gentile's Deployment draft
  16.     - RPSL draft on tunnels
  17.   o also need to think about topology data base
  18.   o need to discuss 500k limit and how to raise it
  19.   o need to discuss dynamic address allocation
  20.  
  21. Pruning Draft
  22.   o was a communication problem between the author and the IESG.  has been
  23.     cleaned up and will go to    BCP post haste.
  24.   o it was a nice goal statement, but there is no enforcement.  what could
  25.     be done?  state that the policy will be enforced.  the reason this draft
  26.     came about because people wanted to enforce but had no document.  this
  27.     provides that.
  28.  
  29. Scoping Draft
  30.   o was a de facto standard already
  31.   o draft-ietf-mboned-admin-ip-space-00.txt
  32.   o IANA has been asked to enshrine the number assignment
  33.   o what kind of additional admin structure might there be?
  34.     - flat has the advantrage that others may enhance structure
  35.     - reserved scope addresses?  SAP us to use highest multicast ddress within
  36.     the scoped range.
  37.     - but the address is large, so making some structure now would give us
  38.       some hierarchical structure for the future
  39.     - as border is bidirectional, hierarchy is out.  
  40.     - how about site, country, piece of wire, ...?  i.e. geograpic
  41.     - 239-255 was suggested as a local, probably site, scope
  42.   o what about sparse mode or admin join protocols, how are these effected
  43.     by administrative scoping?
  44.     - explicit join model handles this
  45.     - except boundary enforces scope
  46.     - privacy can encrypt
  47.     - except participant list
  48.     - have to make sure that your RP is in same group as scope you are
  49.       using.
  50.     - why is admin scope mechanism linked to the particular protocol?
  51.     - should we define a protocol which lets us discover the scope?
  52.  
  53. Heartbeat Draft
  54.   o SNTP as a Multicast Heartbeat
  55.     - provide operational visibility for large auditoria on a dialup
  56.       network
  57.     - end users can subscribe to a stream
  58.   o will not resolve
  59.     - whether a particular dialup link is capable of multicast
  60.     - deciding if a dialup line has connectivity tot eh mbone
  61.     - solve this problem on the mbone, targetting a scoped environment
  62.   o constraints
  63.     - must work with IGMPv1
  64.     - join latencies have a high variation
  65.     - membership state between application and stack may be out of sync
  66.     - must not reqire configuration by end user
  67.   o how it works
  68.     - establish heartbeat which provides end-to-end control from media
  69.       server to end client
  70.     - quick convergence by having dialup servers, last hop before users,
  71.       subscribe to group
  72.     - put an SNTP packet into the message so you can use existing code,
  73.       sequence numbers, rough time estimate
  74.   o inplementation
  75.     - client listner, continuous or only at startup
  76.     - SNTP server, standard v3 with multicast capability
  77.     - multicast devices
  78.   o what they have done
  79.     - ascend max 4000
  80.       . multicast address = G
  81.       . source address S, mask = M
  82.       . slot time = T
  83.       . shift register length = N
  84.       . required messages ove N slots = K
  85.       . no authentication yet
  86.       . if less than K messages in last N slots, SNMP trap generated
  87.       . trap contains sysUpTome, G, T, N, K
  88.       o trap backs off until it is down to 1/hr
  89.   o benefits
  90.     - a NOC gets a realtime picture
  91.     - clients can decide to go uni or multi-cast
  92.     - customer support has an extremely easy tool to debug problems while
  93.       on phone
  94.   o much discussion of necessity, benefits, join latency, ...
  95.   o much discussion of why this presentation, BCP?  protocol spec?
  96.   o envisaged as a very short term solution.  though it points out the value
  97.     of being able to have an API which detects IGMP membership
  98.   o they want to submit it as BCP
  99.   o for a host which wonders, why not just send a multicast ping?
  100.  
  101. RPSL Tunnels Draft
  102.   o see RPS minutes (get from Sue Hares, who did it in detail)
  103.   o there were actually good suggestions/corrections by folk who actually
  104.     understood the semantics of multi-cast tunnels
  105.  
  106. Discussion of
  107.   o much discussion of benefits and problems of default rate limit
  108.   o 3.9 will not have the default rate limit, but it will be required to
  109.     specify something
  110.   o MCI, BBN, ... do not rate limit
  111.   o we can not include mtrace to add more info about routers, info is not
  112.     necessarily known
  113.   o should be a BCP making clear there is no global rate limit
  114.  
  115. 12/10 (Scribe: Bill Fenner)
  116.  
  117.     Dynamic Address Allocation 
  118.  
  119.         - Van suggests adding *.255/16 as the local
  120.           scope range.
  121.     
  122.  
  123.         - "No Rate Limiting" BCP will be written by
  124.            Doug Junkins (NWnet).
  125.  
  126.     Agenda
  127.         Topology Database
  128.         
  129.             Data sources?
  130.  
  131.         Van: mtrace listeners, but clients need to
  132.         specify that response must be multicast
  133.         back. Need a document describing this. 
  134.  
  135.  
  136.         Dave Thaler:
  137.  
  138.             Database would be useful for
  139.  
  140.             (i).    Tracking loss over tim
  141.             (ii).    Generating network design
  142.             (iii).    Simulations (ave node degree,
  143.             etc).
  144.  
  145.         Elizabeth Gentile
  146.  
  147.             Spoke on her draft.
  148.  
  149.             Math Crawford will be co-author.
  150.  
  151.     
  152.             
  153.