IETF
mboned
mboned@jabber.ietf.org
Thursday, 29 March 2012< ^ >
Peter Koch has set the subject to: mboned
Room Configuration

GMT+0
[06:27:54] lennygiuliano joins the room
[06:45:13] dtaht joins the room
[06:56:19] jpc joins the room
[06:58:39] leebingice joins the room
[07:01:17] <leebingice> is it started?
[07:08:06] gorryf joins the room
[07:08:37] <gorryf> I'm going to scribe for mboned today (gorry fairhurst)
[07:08:56] <gorryf> Are there any remote participants?
[07:09:16] <lennygiuliano> Lenny here
[07:09:32] <gorryf> Can you hear Marshall at the front?
[07:09:50] <gorryf> Working Group Status
[07:09:54] <lennygiuliano> Yeah, audio clear, but volume a little low
[07:10:00] <gorryf> Charter update discussion
[07:10:54] <jpc> seems marshall speaking at the wrong mike ?
[07:11:23] <leebingice> leebingice here
[07:12:06] <gorryf> The IESG thinks there should be a verb in each sentence
[07:12:26] <gorryf> Suggest first line on slide: s /ment of//
[07:13:04] <gorryf> AD: Everyone else gets the first right of refusal, and this group may get the remainder
[07:13:36] <gorryf> Marshall: Does anyone wish to comment on the new charter?
[07:13:59] <gorryf> - What is the meaning of "transition" in this sentence?
[07:14:15] <lennygiuliano> Transition is there to cover AMT
[07:14:18] <gorryf> AD: The word has to be pulled out of this.
[07:14:40] <gorryf> Toerless: Should aslo say requirements
[07:14:45] <gorryf> AD: Requirements we do.
[07:14:58] leebingice leaves the room
[07:16:20] <gorryf> Tim Chown: What is the status of multrans
[07:16:35] <gorryf> Marshall: Multrans is likely to be done in here.
[07:17:04] <gorryf> Bill: AMT is "deployments"
[07:18:00] <gorryf> Stig:
[07:18:05] leebingice joins the room
[07:18:20] <gorryf> .. If we say requirements, tools and protocols ...
[07:18:24] <gorryf> Bill:
[07:18:58] <gorryf> ... separate developments of tools and protocols (including transition) and development of tools and protocols that ...
[07:19:48] <gorryf> Toerless: I think the first "protocols" is probably part of the problem with understanding the scope.
[07:20:07] <gorryf> Now: MBONED adenda
[07:20:42] <gorryf> Tim Chown next
[07:21:28] <gorryf> Multicast Filtering Practices
[07:24:48] <gorryf> Toerless
[07:25:50] <gorryf> I think I don't know any BCP for customer networks - BCP sounds rather strong on recommending the right security
[07:26:01] <gorryf> Bill: Here is a range of practices
[07:26:38] <gorryf> Marshall: Key queston is whether we should split this
[07:27:00] <gorryf> Stig:
[07:27:28] <lennygiuliano> Trouble hearing Toerless and Stig at mic
[07:28:37] <gorryf> Ron (as AD)
[07:29:27] <gorryf> Toerless:
[07:29:51] <gorryf> ... could say this a toolset that the vendors should have
[07:29:54] <gorryf> AD:
[07:30:20] <gorryf> ... Think about 2119 keywords
[07:30:34] <gorryf> Toerless: Requirements may be on toolset or operator needs
[07:30:47] <gorryf> Tim:
[07:31:00] <gorryf> ... started out as what are people doing?
[07:31:20] <gorryf> - I think the essence is more practioce, looks liked INFO
[07:31:30] <gorryf> Marshall: Document in your hands
[07:32:12] <gorryf> ... Think about the effort needed to make this a BCP and come back to the WG (you may publish this as INFO anywat)
[07:32:32] <gorryf> Tissa : Mcast OAM next
[07:32:39] <gorryf> - speaker not in room
[07:32:51] <gorryf> Rehket - geo control
[07:36:20] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-mboned-2.pdf
[07:36:24] Florin Coras joins the room
[07:40:07] <gorryf> Toerless:
[07:40:56] <gorryf> .. The policy for what can come from Zone Y comes from the content provider, and the distribution router is responsible for filtering
[07:42:59] <gorryf> Questions/Comments next:
[07:43:33] <gorryf> Marshall: Content providers often ask for this.
[07:43:43] <gorryf> ... Would SAFIs be propsagaed?
[07:44:27] <gorryf> R1 in one AS, etc. Can you ensure the BGP gets to the edge router?
[07:45:05] <gorryf> - Have you considered AAA machinery? AAA server is multicast enabled, but entitled, this may be far simpler.
[07:46:21] <gorryf> Does not require a specific SAFI, AAA may be more straight forward - customer access generates a AAA request to check profile and the set of Bosquet they can access that controls the BRAS for the customer
[07:46:25] <gorryf> Toerless:
[07:46:49] <gorryf> ... Such a solution control interaction between content providers, using RADIUS
[07:46:51] <gorryf> Bill:
[07:47:12] <gorryf> Look at the set of protocols as a package.
[07:47:46] <gorryf> Speaker: Our proposal uses BGP. For AAA you still need a database - we can talk more.
[07:48:29] <gorryf> Geoff: AAA v BGP - there may be many service providers, there are different trust relationships here - acces, transport, content under different networks/policies
[07:49:11] <gorryf> AAA coordination may nnot provide the tools we need.
[07:49:25] <gorryf> Toerless: there are clear protocol preferences in certain areas.
[07:50:58] <gorryf> We need to explain why the content server trusts the Access Network to do what is requested. Content encryption is way to ensure the right customers get content, I like the review here - there may be stuff in CDNI that may be useful.
[07:51:11] <gorryf> Marshall: What do the authors want?
[07:51:34] <gorryf> Ans: We'd like to talk about the use case here. The BGP details could be worked out in IDR.
[07:51:58] <gorryf> Geoff: we expect the draft to generate multiple drafts
[07:52:22] <gorryf> Marshall: This sounds like it is not ready for a WG draft.
[07:53:02] <gorryf> Toerless: I would like see the requirements (even without implying a solution) and looking at the security, etc. This may fall into mboned.
[07:53:43] <gorryf> Geoff: The use cases - e.g. encryption, by user...
[07:54:04] <gorryf> Toerless: I was suggesting the access provider does the decryption (not the customer)
[07:54:24] <gorryf> Speaker: restriction info. may be dynamic.
[07:54:57] <gorryf> Greg:
[07:55:09] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-mboned-4.pdf
[08:11:58] <gorryf> Toerless:
[08:12:30] <gorryf> ...we should decribe membership reports with zero address and we accept any address and explain this in the ID
[08:12:38] <gorryf> Stig:
[08:12:54] <gorryf> just need unique identifier
[08:13:26] <gorryf> could declare one end 1 and the other 2 as link local and define the addresses for IPv6
[08:13:48] <gorryf> should we do the same for v4? (Toerless continuing...)
[08:14:48] <gorryf> Toerless: We could use anycast addresses.
[08:17:13] <gorryf> Thomas: We do need more trhan 6man
[08:17:34] <gorryf> There are cases where this may fail
[08:18:02] <gorryf> ... there is a csse where it will fail
[08:20:54] <gorryf> Gorry: The current text seems like the new text resolves the comments I sent (while ago)
[08:23:47] <gorryf> Gorry: Probes do not need to be sent very often
[08:26:21] <gorryf> Toerless: Suggest we used predefined addresses for tunnel endoiints - as suggested by Stig.
[08:26:29] <gorryf> - is anyone opposed?
[08:26:53] <gorryf> Kurt:
[08:27:27] <gorryf> Should we allow backwards compatbility with previous implementations?
[08:27:41] <gorryf> -Does the implementation look at the address of the source for MRs?
[08:27:58] <gorryf> Kurt: I don't think we support any source.
[08:28:06] <gorryf> .. filtering
[08:29:39] <gorryf> Marshall: Should we returnt the /16 if we do not need it all?
[08:30:10] <gorryf> Toerless: Question - the global anycast address may not be needed?
[08:30:21] <gorryf> Thomas: A /24 is sufficient.
[08:30:56] <gorryf> Toerless: the longest BGP prefix ... this needs a /16? ... and /30 for other cases?
[08:31:12] <gorryf> Marshall: we may want two /24s?
[08:31:35] <gorryf> Toerless: Preassigned address in inner IP address can be a /30 - client and server.
[08:31:51] <gorryf> Stig: We need one address from the /24, we could use the same block.
[08:32:00] <gorryf> Toerless: Isn't this comfusing?
[08:32:05] dtaht leaves the room
[08:32:15] <gorryf> ... what if in the routing tbale.
[08:32:54] <gorryf> Speaker: Anycast isn't that useful at the moment - this may mean 2 blocks? Let's see Greg.
[08:33:12] <gorryf> Marshall: This is a substantial change. Has this version been implemented?
[08:33:25] <gorryf> ... there are existing implementations out there.
[08:33:37] <gorryf> Speaker: Most of this is compatinle.
[08:34:05] <gorryf> ... can we ay we have EXPERIENCE of this version?
[08:35:27] <gorryf> Bob: Is it a good idea to have a separate draft on the discovery process?
[08:35:55] <gorryf> Speaker: The current draft describes the protocol around this. We still need relay discovery in the draft.
[08:37:01] <gorryf> Marshall: Is this version ready for LC?
[08:37:12] Bill joins the room
[08:40:30] <gorryf> Tom: I think a WGLC is a good idea
[08:40:38] <gorryf> ... reviewers today is cools
[08:41:47] <gorryf> ... send reviews within 1 week
[08:42:03] <gorryf> NEXT PRESENTER ..........
[08:43:50] <gorryf> Marshall (slides do not seem on the proceeding pages - see agenda)
[08:46:08] <gorryf> Question: Publication will be several months after another draft. The material comes from another drfat - Jacqueline.
[08:46:28] <gorryf> AD: This draft is to setup a roadmap for the work.
[08:47:17] <gorryf> -: Section 5 of the Jacquenet draft also documents this
[08:47:25] <gorryf> ... in march 2011
[08:48:05] <gorryf> Marshall: I'm perosnally not interested in questions of priority - if people think the Jacquenet draft is the framework - this is just a roadmap
[08:48:42] <gorryf> AD (Ron): That is true - it sets the direction. Here is my question, get authors in one room and come out with one draft.
[08:49:02] <gorryf> Marshall: I was only planning to be editor - I have no problems with that.
[08:49:53] <gorryf> -: It's not an issue of the document - we need to correct what happened and coordinate the effiort.
[08:50:31] <gorryf> ... this draft exists: draft-jaclee-behave-v4v6-mcast-ps-03
[08:51:48] <gorryf> Christopher: I'd favour continuing the draft
[08:52:05] <gorryf> ... the history was from softwires.
[08:52:55] <gorryf> Mike McBride: What's the procedure when you have two do?
[08:53:11] <gorryf> Gorry: Neither of these are WG documents....
[08:53:33] <gorryf> Stig: I think we just need one document.
[08:53:58] <gorryf> Mike: We could put the new stuff into the new draft.
[08:55:01] <gorryf> ?: These are requirements documents, we should converge.
[08:55:39] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-mboned-5.pdf
[08:56:23] <gorryf> C. Jacquenet: on draft-jaclee-behave-v4v6-mcast-ps
[08:57:04] Bill leaves the room
[08:59:34] <gorryf> Ron (AD):
[08:59:55] <gorryf> Primary focus is live TV - the scope at the BoF was only live TV broadcast.
[09:06:19] <gorryf> <pause while Marshall restores power to his pc>
[09:06:53] <gorryf> Comments on draft...
[09:07:05] <gorryf> Bill:
[09:07:47] <gorryf> ... China telecom case has a division of networks into metro and backbone - the latter is planned v6 - the metro/acces will be v4
[09:08:05] <gorryf> Marshall: Is one of these un icast inly?
[09:08:51] <gorryf> Ron: I see use cases 6-4, 6-46 etc - once you have done the 4-6 and 6-4 adaptations is this done?
[09:09:20] <gorryf> Bill - The direction also matters v4 -> v6 and v4 -> v6
[09:10:16] <gorryf> Marshall: theres also IGMP<->MLD and PIM->PIM
[09:10:28] <gorryf> Stig can we use tunnels in some cases?
[09:10:38] <gorryf> <back to slides>
[09:11:44] <gorryf> Marshall: do you see aggregation?
[09:12:13] <gorryf> Yes - this a RP for IPv4 content, where all the Ipv4 is processed by obe router
[09:13:53] <gorryf> speaker - can we adopt this?
[09:14:09] <gorryf> Joe: Can we consider other cases also in the use cases?
[09:14:52] <gorryf> ... can it be mentioned in the document?
[09:15:11] <gorryf> Ron: I think the use cases may tell us how many modules you need?
[09:15:45] <gorryf> Tom: The two directions do have different directions?
[09:15:59] <gorryf> ,,, there are 4 modules.
[09:16:37] <gorryf> ... you can also compose the MLD interactions differerntly
[09:17:03] <gorryf> Marshall: When you just talk about moving the bits I see for modules.
[09:17:19] <gorryf> Ron: Can there be less?
[09:17:55] <gorryf> Joe: The second 6-4 is to serve non-upgraded v4 use.
[09:18:23] <gorryf> Marshall: Authors ask for WG adoption.
[09:18:47] <gorryf> How many have read - ans 12 ~ 1/2 people
[09:19:02] <gorryf> Who would like to see this merged ~4 people
[09:19:20] <gorryf> Who would like to see the Haclee document adopted - about 8
[09:21:02] <gorryf> COMMENT: Many people have read the documents, would also like to see a merged document - so in fact I expect it to be a merged document - The editor can decide (2 groups) can decide this.
[09:21:32] <gorryf> Stig: We are talking about a base - I'm fine either way. I don't support adoption of any documents right now.
[09:21:59] <gorryf> Marshall: I think we shoudl take these to the list and figure out how to go forward.
[09:23:31] <gorryf> Who is interested in this problem? 95% of people would like to see work in this space
[09:24:03] <gorryf> Question from floor: Is there a clear intention to progress with this work?
[09:24:15] <gorryf> Marhall: I don't see this.
[09:24:50] <gorryf> Toerless: I think we need to see this problem should be understood.
[09:25:26] <gorryf> Marshall: I think we need to make requirements in this WG
[09:26:15] <gorryf> Dino: All the work that I've seen is great work - there are many solutions to the problem. We need an IPv6 network that works for multicast. We need to see the forerst and trees.
[09:27:36] <gorryf> ... translation is "evil" in general - please do it in the edge - there are lots of combinations. There seem to be good engineering here - I think overlays are important. We need to be strategic.
[09:28:53] <gorryf> ... I suggest we do not go this way - i suggested that we create an integrated PIM that allows both AFs and uses it olist with different AFs. I do not see an IGMP/MLD gateway - we should do group translation - not protocol translation
[09:29:22] <gorryf> ... This is going to be expensive and very specific to translations.
[09:31:49] <gorryf> Ron: AD final comment - keep architectural things simple.
[09:32:12] <gorryf> Comment: Address the concerns we just heard in the requirements.
[09:32:35] Florin Coras leaves the room
[09:32:36] <gorryf> Meeting closed
[09:33:04] lennygiuliano leaves the room
[09:33:09] leebingice leaves the room
[09:33:21] <gorryf> people leaving ... sorry for any name/name translations... in the jabber log
[09:35:35] jpc leaves the room
[09:37:10] gorryf leaves the room
[10:17:28] dtaht joins the room
[10:31:29] dtaht leaves the room
[11:19:39] Bill joins the room
[12:20:15] Bill leaves the room
[15:43:03] dtaht joins the room
[19:33:12] dtaht leaves the room