[12:05:51] --- rhe has joined
[12:12:37] --- frodek has joined
[12:14:38] --- behcet.sarikaya has joined
[12:21:41] --- swb has joined
[12:22:21] --- behcet.sarikaya has left
[12:26:51] --- dthaler has joined
[12:27:53] <dthaler> no one scribing? can some at least state which presentation is starting, when it starts? I'm trying to follow 2 different meetings
[12:28:21] <swb> me too
[12:28:35] <rhe> OK. Will do. MLD-LITE at the moment.
[12:29:52] --- gvandeve has joined
[12:30:44] <dthaler> (I'm in CSI right now, so let me know if there's any questions specifically to me for some reason during the meeting. Hopefully the only ones to me were the ones at the beginning I was there for :)
[12:31:24] <rhe> OK, I'll keep my ears open for that. :)
[12:35:55] <rhe> Still discussing the lightweight igmpv3/mldv2 and whether if it doesn't change what is on the wire, what to go for. Experimental seems to be the conclusion.
[12:36:27] --- swb has left
[12:36:50] <dthaler> thanks, (experimental sounds good to me too)
[12:38:03] <rhe> Mtracev2 presentation.
[12:39:15] <rhe> (Previous slides and this aren't on meeting materials, btw)
[12:41:01] --- marshall has joined
[12:41:20] <marshall> sorry - we are not on mtrace
[12:41:32] <rhe> s/not/now/ :-)
[12:41:56] <marshall> Stig : tld's should be passed on
[12:42:18] <marshall> igmp/mld proxy needs to be added
[12:43:07] <marshall> Hitoshi : will add figures to draft
[12:44:02] <marshall> want opinion on ipv6 address scoping
[12:45:36] <marshall> what if routers only have link local addresses ?
[12:45:44] <marshall> can that be used in the response ?
[12:46:12] <marshall> Dino : Link local addresses are opaque
[12:49:01] <marshall> discussion of link local addresses
[12:49:17] <marshall> Brian H : Use global address or router ID
[12:49:38] <marshall> only use link local if all else falls
[12:50:09] <marshall> (the issue is that link local addresses are not that useful outside of the router using them)
[12:50:25] <marshall> Bill Fenner : Addresses are handles for interfaces
[12:50:38] <dthaler> I think "use link local if all else fails" is right
[12:51:08] <marshall> should we think about using other identifiers for interfaces
[12:51:25] <dthaler> like a MAC address?
[12:51:40] <marshall> Bill didn't elaborate
[12:52:43] <marshall> Hitoshi : Use mtrace to count receivers
[12:52:57] <marshall> couting technique : extend PIM messages
[12:53:04] <marshall> (this was a previous proposal)
[12:53:42] <marshall> may be able to add something along these lines to mtrace
[12:54:17] <marshall> Hitoshi : It could take a long time to count large number of seconds
[12:54:28] <marshall> Hitoshi : 1000 seconds for 10,000 receivers
[12:55:24] <marshall> Marshall : My feeling is not to include counting of receivers in this mtrace
[12:55:31] <dthaler> yuck
[12:56:00] <marshall> Hitoshi : Need new mcast addresses for new mtrace
[12:56:34] <marshall> bill fenner : there is a history of having parallel addresses in v4 and v6
[12:58:23] <marshall> bill fenner : first multicast replies are less reliable than they used to be
[12:59:07] <marshall> next is Stig
[12:59:10] <dthaler> on wireless the probability of loss of a multicast message is much higher than the probability of loss of a unicast message (I've heard this from several sources)
[12:59:11] <marshall> SSMPING
[12:59:21] <marshall> depends
[12:59:48] <marshall> are you talking about 802.11x or 3GPPx
[12:59:55] <dthaler> 802.11
[12:59:55] <marshall> Stig : a lot of changes
[13:00:05] <marshall> not backwards compatible any more
[13:01:03] <marshall> 2 new SSMPING message types
[13:05:49] <marshall> [Hitoshi's presentation has been uploaded]
[13:05:57] <marshall> Stig : Can specify the ttl
[13:06:09] <marshall> want a new name
[13:07:02] <marshall> Stig : feel that the work is done
[13:07:13] <marshall> needs other implementation
[13:09:53] <marshall> Stig : Multicast beacons
[13:12:27] <marshall> Mike McBride
[13:13:06] <marshall> Multicast L3VPN practice and experience
[13:13:14] <marshall> an non WG draft (so far)
[13:14:07] <marshall> was opposition
[13:14:37] <marshall> MVPN+PIM
[13:15:00] <marshall> Informational
[13:15:07] <marshall> is the intended standard
[13:15:27] <marshall> only references 2547bis documenet
[13:15:35] <marshall> not "the Rosen draft"
[13:16:35] <marshall> does this require a charter extension
[13:16:37] <marshall> ?
[13:17:37] <marshall> Richter : This draft is unacceptable
[13:17:55] <marshall> - some sections are covered by various documents
[13:18:05] <marshall> section on security is misleading
[13:18:25] <marshall> section on scalaibility is misleading
[13:19:03] <marshall> Ram [?] : The draft is referring to Rosen 8
[13:19:23] <marshall> Rosen 8 is not entirely within the L3VPN standartd
[13:19:26] <marshall> standard
[13:20:08] <marshall> draft is not talking about things implemented by other documents
[13:20:15] <marshall> draft has a section on QOS
[13:20:43] <marshall> unicast 2547 has options that are not talked about
[13:20:59] <marshall> comments should go to mailing list
[13:28:08] <marshall> Ron Bonica : One issue
[13:28:19] <marshall> can you come to ops area with deployment experience
[13:28:32] <marshall> that is OK
[13:28:41] <marshall> another issue : Is in the charter
[13:30:00] <marshall> third issue : is the document
[13:30:02] <marshall> worthy
[13:30:06] <marshall> of publication
[13:30:18] <marshall> Stig : [Speaking for Beau Williamson]
[13:30:22] <marshall> MADP
[13:31:04] <marshall> application vendors hard code addresses
[13:31:12] <marshall> this complicates access lists
[13:32:07] <marshall> want a simple alternative to "hard coding"
[13:32:09] <marshall> of addresses
[13:33:37] <marshall> client performs expanding ring search
[13:34:18] <marshall> defines 2 well know scopes
[13:34:35] <marshall> using scope relative addresses
[13:35:24] <marshall> why not use existing protocols
[13:36:16] <marshall> DNS / SAP both have issues
[13:36:34] <marshall> SLP is far too complex
[13:39:21] <marshall> Hitoshi : Do you want to care about global scope as well ? That is like a DOS tool
[13:39:28] <marshall> Stig : It will be inside 239
[13:39:44] <marshall> And ttl of 32
[13:42:07] <marshall> Question : What about using DHCP
[13:43:59] <marshall> Fenner : Why not use MADCAP
[13:44:08] <marshall> Stig : It is not deployed
[13:44:16] <marshall> Bill : Neither is this
[13:44:25] <marshall> Stig ; And it is more complex
[13:44:43] --- Simon Leinen has joined
[13:45:45] <marshall> Bill : MADCAP is based on DHCP
[13:46:12] <marshall> Toerless : This is not a global scope document
[13:47:50] <marshall> Dave Thaler
[13:47:58] <marshall> There is two different problems
[13:48:06] <marshall> The server has to know what address to use
[13:48:11] <marshall> The client has to find this out
[13:48:17] <marshall> that is allocation and discovery
[13:48:26] <marshall> MADCAP is an allocation problem
[13:48:40] <marshall> MADP is a discovery problem
[13:49:48] <marshall> MADCAP is certainly present, specifically in Windows clients and servers
[13:50:05] <marshall> SDP is used in at least 2 protocols
[13:50:37] <marshall> to carry address information
[13:50:51] <marshall> does the client know the unicast address of tthe server
[13:52:05] <marshall> Stig : The use case is that the client doesn't know anything about the server's location
[13:52:40] <marshall> Dave : You assume that there exists only one set of information for the server
[13:52:59] <marshall> Stig : As soon as you get one multicast application the client can get more information
[13:53:28] <dthaler> I'm not sure I buy the use scenario though
[13:53:32] <marshall> Hitoshi : This discovery protocol is the other side of an announcement protocol
[13:53:35] <dthaler> of only having one app context
[13:53:56] <marshall> [Bring it up on the list !]
[13:55:25] <marshall> not consensus yet to adopt this docuement
[13:56:00] <dthaler> my comment on syntax is to either use SDP, or provide a compelling answer why not
[13:56:46] --- pk has joined
[13:57:20] <marshall> Thomas Morin
[13:57:41] <marshall> draft-morin-mboned-igmpmld-error-feedback-00
[14:00:24] <marshall> a new feedback message
[14:09:45] <marshall> Toerless : We have hosts that still don't support IGMPv3 and so we need a way to figure out how not to rely on host support
[14:10:13] <marshall> Dave Thaler : There are two types of ICMP reponses : informational and errors
[14:10:21] <marshall> this is an icmp error type
[14:11:27] <marshall> also, there will be issues with deployment
[14:13:38] <marshall> draft-morin-mboned-mcast-blackhole-mitigation-00
[14:15:27] <dthaler> my 2nd point is just a more general comment... the IETF shouldn't accept proposals just because they may look like a good idea, but rather make sure people will actually implement it and use it to solve some real problem
[14:17:43] <marshall> this was also presented to the ospf working group
[14:17:58] <marshall> Stig : Present this was presented in the OSPF work as well
[14:18:22] <marshall> Toerless : The practical solution here is to ignore PIM Hello's
[14:19:27] <marshall> Toerless : This is more appropriate for the WGs that deal with the routing protocols
[14:24:02] --- gvandeve has left
[14:35:57] --- Simon Leinen has left
[14:42:43] --- marshall has left
[14:51:03] --- dthaler has left
[15:00:14] --- frodek has left
[15:06:36] --- pk has left
[15:23:23] --- simon has joined
[15:28:51] --- simon has left
[16:09:52] --- pk has joined
[16:42:32] --- pk has left
[17:09:04] --- gvandeve has joined
[17:11:07] --- gvandeve has left: Replaced by new connection
[17:21:41] --- pk has joined
[17:35:08] --- pk has left
[18:20:22] --- pk has joined
[18:20:54] --- pk has left