[10:36:15] --- timchown has joined
[10:36:48] <timchown> /?
[10:48:18] <timchown> quiet here
[10:52:26] --- dthaler has joined
[10:52:41] <timchown> OK, we have minute taker and I'll jabber scribe for Dave :)
[10:52:46] --- droms has joined
[10:52:55] --- touchwood has joined
[10:53:03] --- tskj has joined
[10:53:06] <timchown> On administravia
[10:53:35] <timchown> 8 active drafts to be discussed
[10:54:37] <timchown> will have 20 mins on point to multipoint LSPs
[10:54:44] <timchown> exploratory for mboned right now
[10:55:37] <timchown> Savola: want to discuss what is status of address assignment document rfc2908 (or something like that)
[10:56:52] <timchown> First up Durand
[10:56:55] <timchown> draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00.txt
[10:57:07] <timchown> Looks like same talk as DHC wg yesterday
[10:58:10] --- tuy has joined
[10:58:11] <timchown> Have reviewed existing mechanisms, too complex or not scalaable, or can't work with all types of addresses like embedded-rp
[10:58:38] <timchown> using dhcpv6 because will be widely deployed and has flexible options
[10:58:49] <timchown> can assign multiple addresses per host
[10:59:03] <timchown> 2 new options: IA_MA and Scope option
[11:00:26] <droms> Yes, I think this will be the same talkas at the dhc WG meeting on Tue.
[11:01:07] <timchown> [The one that croweded out dhc-dual-stack ;) ]
[11:01:32] <timchown> suggest people look to dhc jabber log for issues raised there
[11:01:38] <droms> Well, we knew the dhc-dual-stack doc was so good there would be little need to discuss it in detail.
[11:01:52] <timchown> [as it turned out, it seemed so(!)]
[11:03:48] <timchown> simple scenario is dhcp server in domain assigning embedded rp based group address to host
[11:05:02] <timchown> scenario 2: isp allocates a slice of its prefix to each of its customers, via dhcpv6, for end user applications
[11:05:53] <timchown> scenario 3: one dhcpv6 server for campus, many labs on campus, each with rp
[11:06:13] <timchown> here dhcpv6 server can supply scope
[11:07:38] <timchown> could have two drafts: assignment model in mboned, new dhcpv6 options in dhc
[11:08:08] <timchown> Durand: Questions?
[11:08:10] --- mike has joined
[11:08:11] --- mike has left: Invisible
[11:09:01] <timchown> Holbrook: why doesn;t the 3306 addresses work?
[11:09:17] <timchown> Durand: ok, but how do you know where rp is?
[11:09:38] <timchown> Durand: we don't want to go down msdp for ipv6 path
[11:09:44] <timchown> Durand: need rp mapping
[11:10:37] <timchown> Savola: for embedded addr you specify group interface id. host cannot know that
[11:11:08] <timchown> Anon: you know embedded RP range so you use that range. Whole point is you can hand out anddrsses and you know where to get them from
[11:11:27] <timchown> Savola for 3306 host could auto calculate address prefix for link, so this is more complex
[11:11:35] <timchown> if dhcp server doing that, no problem
[11:11:45] <timchown> Durand: will be clearer in next presentation
[11:11:59] <timchown> Thaler: posted comments to list...
[11:14:19] <timchown> I'm not for or against, nothing in not already in madcap in terms of functions, so question is for v4, will deployments be dual stack or v6 only. for v6 only then dhcpv6 seems way to go, as no madcap exists, but for both v4 and v6 you have v4 solution with madcap, so extra v6 complexity is negligible, so question is how do you expect v6 multicast to be deployed. what about ssm reducing demand, or application layer multicast reducing demand...
[11:14:53] <timchown> Thaler: is it worth putting effort here to get more mutlicast adoption? or just use existing rfc and madcap. i have no answer. but discuss in wg?
[11:15:38] <timchown> Meyer: dave's issues need to be discussed, as for which wg then i need to talk to Droms re dhc offline
[11:16:31] <timchown> Durand: we believe this solution is far less complex than madcap
[11:17:13] <timchown> Thaler: disagree no madcap because complex. there are two implementations for windows and linux. why no other implementtaions? not complexity (packet parsing) - issue is no customer demand?
[11:17:25] <timchown> Thaler: two implementations have not generated demand
[11:17:55] <timchown> Eckert?: need clearly distinct role to move it forward
[11:18:52] <timchown> Eckert: random reuse of address in v6 not so much of an issue
[11:19:22] <timchown> Eckert: request doesn't offer context
[11:19:33] <timchown> Meyer: to list please
[11:19:50] <timchown> Next: Durand: Questions about embedded RP
[11:20:13] <timchown> don't want to start msdp for ipv6
[11:20:25] <timchown> only solution now is embedded rp
[11:21:38] <timchown> question: will isps accept to give service without providing an rp
[11:21:59] <timchown> meyer: msdp is because isp doesn't want service to depend on 3rd party
[11:22:15] <timchown> meyer: also problems with flooding on exchange points
[11:22:29] <timchown> meyer: dense mode is no-no of course
[11:23:09] <timchown> durand: question - how does end user know rp to use?
[11:23:52] <timchown> how does app know rp to use, hence we need assignment mechanism. not about collision - we have enough space, we need assigment tool to know rp to use, end user cannot guess address
[11:24:38] <timchown> q3: i have deployed embedded rp for global scope - how do i know who is using it?
[11:25:00] <timchown> global rp could be used by external hosts, have no way to control
[11:25:11] <timchown> problem for cpu use etc.
[11:25:28] <timchown> and external users then rely on a service they don't control
[11:25:54] <timchown> suggestions are group address filters, pim register filtering, not sure these will do the job fully
[11:26:33] <timchown> maybe only have external users allowed if we have internal users on session
[11:28:14] <timchown> savola: does rp have to keep state of registers after switched to native forwarding?
[11:29:17] <timchown> eckert: use ssm(?)
[11:29:30] <timchown> eckert: you're assuming asm
[11:30:17] <timchown> meyer: what do you want wg to do?
[11:30:29] <timchown> durand: want reaction - is work needed?
[11:30:45] <timchown> meyer: take to list
[11:31:02] <timchown> tuy: [mike broken, sat down]
[11:32:06] <timchown> Meyer: ok, on to active drafts on agenda
[11:32:27] <timchown> Thaler: draft-ietf-mboned-auto-multicast-02.txt
[11:32:48] <timchown> thaler: issue raised, not yet into draft, so needs update from ietf 59 issues
[11:32:54] <timchown> (issues)
[11:33:12] <timchown> have co-author volunteer, but is there interest in this draft?
[11:33:37] <timchown> Jim?: general interest in auto-tunneling so yes continue
[11:33:56] <timchown> Anon: yes we want this feature
[11:34:15] <timchown> Anon: applicability to vpn case for this. could expand draft to include that?
[11:34:33] <timchown> thaler: is this on charter?
[11:34:38] <timchown> meyer: yes its a goal
[11:34:48] <timchown> thaler: ok, will update in next 4 weeks
[11:35:01] <timchown> Next: draft-ietf-mboned-ssm232-08.txt
[11:35:06] <timchown> (meyer presenting)
[11:35:14] <timchown> almost historic already!
[11:35:31] <timchown> maybe 3 years old now
[11:36:02] <timchown> has reference to pim and reference changed to new pim spec which supposed to be on std track, and new spec is where?
[11:36:21] <timchown> holbrook: new spec is ready after this ietf to go to iesg
[11:36:27] <timchown> meyer: ipr resolved?
[11:36:59] <timchown> meyer: intended to have this sit in rfc editor q while that happens, but not in q yet...
[11:37:19] <timchown> Next: draft-ietf-mboned-msdp-deploy-06.txt
[11:37:23] <timchown> (meyer presenting)
[11:37:34] <timchown> same dependency on pim spec but also to msdp
[11:37:52] <timchown> these things both sitting around, stuck on normative reference round about seoul
[11:38:02] <timchown> both should be in rfc editor q, but not yet
[11:38:26] <timchown> kessens: just completed last call on variants, so will be in q very soon
[11:38:53] <timchown> meyer: no more wordsmithing needed
[11:39:05] <timchown> Next up: Savola
[11:39:07] <timchown> draft-ietf-mboned-embeddedrp-06.txt
[11:39:26] <timchown> it's past IESG. needs one comment to be resolved. waiting for AD to pass to rfc editor
[11:41:02] <timchown> in one or two revisions spec specifies ff7 and fff prefix due to comments by iesg now only specifices ff7, so fff would be future work
[11:41:21] <timchown> Next: draft-ietf-mboned-mroutesec-02.txt, this is ready
[11:41:27] <timchown> (savola)
[11:42:01] <timchown> savola: suggestion to add one para, ad thinks not needed and will cause delay
[11:42:07] <timchown> (this is mroutesec)
[11:43:53] <timchown> Next: draft-ietf-mboned-rfc3171bis-02.txt
[11:44:04] <timchown> meyer: let;s just wglc and push it out
[11:44:33] <timchown> Next: MSDP MIB update (Fenner)
[11:45:16] <timchown> Fenner: talking about changes from -07 version
[11:45:29] <timchown> now draft-ietf-mboned-msdp-mib-00
[11:45:36] <timchown> (note now 00 due to wg change)
[11:45:58] <timchown> subtle changes in msdp meant that mib doc needed updates
[11:46:16] <timchown> thaler: are there implementations of deprecated things?
[11:46:46] <timchown> fenner: at least one has SA-Requests (all objects related to that are deprecated)
[11:47:00] <timchown> since rfc3618 doesn't have either one
[11:47:09] <timchown> need to check that
[11:47:26] <timchown> [Fenner making note to self :]
[11:47:46] <timchown> weird for mib to show up with deprecated objects in first official revision
[11:48:01] <timchown> will check for implemntations that use those objects
[11:48:35] <timchown> was ipv4-specific, because AF independent, then went back to v4 specific
[11:49:08] <timchown> we say will be no msdp for v6, so no sense to go back to ip independent version
[11:49:50] <timchown> meyer: any mib doctor ipv4 specific problems we'll hit
[11:49:58] <timchown> fenner: spec will need to justify v4 only
[11:50:13] <timchown> meyer: need variance statement
[11:50:25] <timchown> thaler: doc only needs to state why v4 specific
[11:50:43] <timchown> thaler: ok if wg approved, for mib doctor review
[11:51:41] <timchown> [show of hands, not many people have looked at this]
[11:51:49] <timchown> fenner: will post open issues to list
[11:51:53] <timchown> fenner: done
[11:52:12] <timchown> Next up: Savola
[11:52:40] <timchown> draft-savola-v6ops-multicast-issues-03.txt
[11:52:50] <timchown> IPv6 Multicast Deployment Issues
[11:53:16] <timchown> goal: provide historical reference as to why we chose this path for v6 inter domain multicast, why no msdp for v6, etc.
[11:53:30] <timchown> also talks on igmp/mld snooping problems
[11:53:47] <timchown> documents discussion to avoid repeating the discussions
[11:54:13] <timchown> issues:
[11:54:21] <timchown> a) multiple pim domainss and asm
[11:54:31] <timchown> b) issues with ssm and embedded rp
[11:54:41] <timchown> c) ND uses multicast and not broadcast
[11:54:52] <timchown> d) functionality like MLD snooping
[11:55:11] <timchown> So what to do next?
[11:55:25] <timchown> meyer: [mike broken again!]
[11:56:15] <timchown> meyer: many places in ietf where we didn't do this kind of informational doc and we revisited stuff, so let's not relive these decisions here, so (hat on or off) i'd like to see this doc.
[11:56:25] <timchown> john?: yes
[11:56:54] <timchown> savola: i am hearing support
[11:57:08] <timchown> eckert: what is limiter on bcp as opposed to informational?
[11:57:43] <timchown> savola: doc is historical record, which might go bcp, but might be overkill, informational is probably best
[11:57:59] <timchown> meyer: go informational, because its informational(!)
[11:58:03] <timchown> john?: yes agree
[11:58:15] <timchown> savola: poll room?
[11:58:45] <timchown> meyer: allows people who have read it to vote
[11:58:57] <timchown> meyer: seems to be consensus to make it wg doc
[11:59:01] <timchown> meyer: so be it
[11:59:20] <timchown> meyer: so that's end of active document discussions
[11:59:48] <timchown> meyer: next is discussion of IMDOC initiative
[11:59:55] <timchown> meyer: noone wants to write
[12:00:25] <timchown> what should we do about existing address allocation architecture?
[12:00:30] <timchown> discussion has happened on list
[12:00:44] <timchown> savola: sorry no slides
[12:01:06] <timchown> savola: on list i raised concern that many rfcs discuss m/c address alloc and assignment and those aren't applicable in most cases
[12:02:28] <timchown> plenty of evidence of people in or out of ietf learning mcast and how to get addresses, they go to ietf website and find mcast rfc2908 or something and this describes the architecture that was proposed with madcap and stuff which never really came to be, so this is confusing, and VERY important to fix this problem and document it in a better way for allac and assigment and in doing so make one document historic
[12:03:12] <timchown> thaler: 2908 does not say mast, mentions it in an example, draft specifies issues, e.g. how to decide which ranges which domains use, eg. with glop
[12:04:06] <timchown> thaler: lots of different level mechanisms - so can update list of examples, but core parts of doc don't cause a problem from what i hear. people associate it with protocols that rfc really doesn't do.
[12:04:40] <timchown> meyer: lots of uncoordinated allocation docs, if we agree alloc architecture (here or elsewhere eg malloc)...
[12:04:48] <timchown> thaler: problems from examples not core model?
[12:05:30] <timchown> thaler: people today use glop, embedded rp etc, this may change over time, rfc should be independent of that
[12:05:52] <timchown> thaler: need to update, but what?
[12:06:22] <timchown> savola: large part of doc is ok in tech sense but examples confuse readers not familiar with mcast.
[12:06:35] <timchown> savola: we need a self-standing doc to replace old one, not just update
[12:07:08] <timchown> meyer: we should write alloc drafts and require them to have para as to how they fit into alloc architecture, might help.
[12:07:18] <timchown> savola: agree
[12:07:47] <timchown> savola: architecture in doc has three levels and in practical sense 2 levels can be collpaosed to alloc and assignment
[12:08:13] <timchown> savola: need to avoid confusion
[12:08:30] <timchown> meyer: does architecture doc need to be rewritten
[12:08:37] <timchown> savola: yes
[12:09:02] <timchown> meyer: ad - is this something we can do?
[12:09:09] <timchown> kessens: think it's ok.
[12:09:27] <timchown> john: some portions of architecture are no longer valid.
[12:10:33] --- wag has joined
[12:12:39] <timchown> haberman: we need bcp
[12:12:45] <timchown> chown : agree
[12:12:51] <timchown> meyer: need authors
[12:13:13] <timchown> eckert: asm or work on session layer for ssm?
[12:13:34] <timchown> eckert: wasting cycles? only seeing academic interest
[12:13:39] <timchown> savola: agree in a sense
[12:14:54] <timchown> meyer: let's take to list, i pur charter goal into charter on this topic, we can do this work in mboned, need to scope it, on list
[12:15:02] <timchown> meyer: ok.
[12:15:11] <timchown> meyer: next up: point to multipoint LSPs
[12:16:13] <timchown> Yiqun Cai, Cisco
[12:16:25] <timchown> see www.1-4-5.net/~ycai
[12:17:49] <timchown> at least 200 proividers have deployed mpls/vpn today
[12:17:59] <timchown> want to provide mcast to customers
[12:18:08] <timchown> i mean v4 and v6 mcast here
[12:18:54] <timchown> may see native mcast, mcast in a vpn environment, or L2 multicast packets
[12:22:10] <timchown> meyer: transit here we talk of transport of packets
[12:33:36] <timchown> meyer: can we get a single solution to this problem?
[12:33:42] <timchown> Cai: yes
[12:38:14] --- wag has left
[12:41:29] <timchown> [Some discussion missed - see minutes]
[12:46:35] <timchown> open mike:
[12:47:22] <timchown> savola: mcast mpls seems to mean how can mcast be provided over mpls or over vpn or whatever, but i hope you make clear that that is separate to using mcast for mpls transport or instead iof mpls transport
[12:47:52] <timchown> cai: how to run mcast in vpn environment, and how to realise that traffic, what if native mpls, how to do it
[12:48:16] <timchown> savola: clarify second one - not requirement that customer shave mcast traffic therefore have mcast transport(?)
[12:48:25] <timchown> eckert: you could use unicast with replication at edge
[12:48:50] <timchown> savola; might want mcast for distribution even if customer unicast only
[12:51:03] <timchown> anon: good exerice to educate multicast community
[12:51:19] <timchown> anon: get p2mp authors to present here
[12:52:09] <timchown> cai: p2mp requirements are going last call, don't want delay
[12:52:33] <timchown> meyer: we're trying to bring out issues here for ops people
[12:52:57] <timchown> meyer: to inform protocols group with operational requirements, that's the point of this
[12:53:04] <timchown> john: two key issues
[12:53:49] <timchown> 1: very active discussion to do multipoint forwrading mechanisms, and those do apply to mcast wgs - look at requirements document on basis current specs were derived from - given last call and active, so do comment
[12:54:31] <timchown> 2nd thing is solution has multifaceted set of requirements - tree building, etc. this dictates applicability statements for solutions that are proposed in mcast or mpls area
[12:54:42] <timchown> not being done right now, we should give input
[12:56:24] <timchown> anon: lack of p2mp would be big hole
[12:57:35] <timchown> meyer: again, as operations group we should be able to inform protocol group
[12:57:44] <timchown> meyer: we're done
[12:58:04] <timchown> [mboned closed]
[12:58:24] --- timchown has left
[12:59:24] --- touchwood has left
[13:00:39] --- tskj has left
[13:08:52] --- droms has left: Disconnected
[13:12:51] --- dthaler has left: Replaced by new connection
[13:12:53] --- dthaler has joined
[13:16:56] --- tuy has left: Disconnected.
[13:51:46] --- dthaler has left: Replaced by new connection
[13:51:48] --- dthaler has joined
[13:51:50] --- dthaler has left