Monday, 25 July 2011
Room Configuration
GMT+0
[15:51:22] Joel Jaeggli joins the room
[15:53:05] <Joel Jaeggli> Multitrans BOF begins Monday 7/25 13:00 EDT
[16:30:23] TomT joins the room
[16:30:39] <TomT> Thanks for the coordinate refresh
[16:46:06] Joel Jaeggli leaves the room
[16:51:46] Joel Jaeggli joins the room
[16:54:12] Wes George joins the room
[16:55:02] <Joel Jaeggli> yup no problem
[17:00:31] <Joel Jaeggli> multitrans bof commences.
[17:00:58] <Joel Jaeggli> who was at tha prague bof vs who is new here
[17:01:14] Ole Troan joins the room
[17:01:28] <Joel Jaeggli> scenarios, problem, requirements.
[17:01:47] <Joel Jaeggli> no a lot of consistency in prague so we may not a have a common set problems
[17:02:07] <Joel Jaeggli> agenda bashing
[17:02:29] <Joel Jaeggli> tina - requirements issues scope
[17:02:47] <Joel Jaeggli> greg requirements without problems seems kind of misguided
[17:03:21] <Joel Jaeggli> tina - scope, work items
[17:03:56] <Joel Jaeggli> greg scenarios first
[17:04:08] <Joel Jaeggli> agenda is bashed
[17:05:48] <Joel Jaeggli> presenting scenarios Jacquelyn deng
[17:07:18] <Joel Jaeggli> transition scenarios doc - is not new material since last meeting just clarifications
[17:07:48] <Joel Jaeggli> take inter sa scenarios into account one address family talking to another
[17:08:04] <Joel Jaeggli> ipv4 source to ipv6 reciver
[17:08:20] <Joel Jaeggli> and the ipv6 source to ipv4 reciver
[17:08:26] brian.bnsmith joins the room
[17:09:53] <Joel Jaeggli> the next category of scenarios. one address family is used by both sender and reciver while it has to cross over an network that's another address family
[17:10:11] <Joel Jaeggli> examples ipv6 sender and reciver over ipv4 network or vice-versa
[17:10:50] <Joel Jaeggli> summary - if you take the internetworking function into account we have more scenarios
[17:11:49] <Joel Jaeggli> priority - higher - 4-6-4 ds-lite or 4 sender to ipv6 reciver
[17:12:05] <Joel Jaeggli> lower ipv6 source to ipv4 reciver
[17:12:20] <Joel Jaeggli> or 6-4-6 scenario
[17:12:56] satoru.matsushima joins the room
[17:13:48] <Joel Jaeggli> ron bonica - is this ssm or asm multicast
[17:14:37] <Joel Jaeggli> j deng - assumption is that it's single source to keep it simple .
[17:15:16] <Joel Jaeggli> tim - chown would like to see the lower ones have a slightly higher priority
[17:15:54] <Joel Jaeggli> alain durant - what I really care about is bandwidth e.g. reduce duplication in the last mile.
[17:16:20] <Joel Jaeggli> to answer rons point ssm.
[17:17:29] <Joel Jaeggli> tina - tim chown nice pictures to show the problems with each scenarios
[17:17:43] <Joel Jaeggli> it's in the technical issues slide deck.
[17:19:16] <Joel Jaeggli> ichun from cisco - I don't see that there's any chance that 1/2/3/4 will interoperate with each other.
[17:19:44] <Joel Jaeggli> not convinced that priority is set propley based on deployment priorities
[17:19:51] <Joel Jaeggli> i ching from cisco
[17:20:06] <Joel Jaeggli> greg - lets accumulate this scenarios
[17:21:19] simon joins the room
[17:23:19] <Joel Jaeggli> - brief outage while I looked for blue sheets
[17:23:49] satoru.matsushima leaves the room
[17:24:06] <Joel Jaeggli> bob brisco - why is 6 sources lower priority
[17:25:59] <Joel Jaeggli> bill - something should work for both for asm vs ssm, define the bits on the wire and leave it up to the implmentaors to decide where it goes
[17:27:50] <Joel Jaeggli> hue deng I don't see an urgent requirement for nat 4-6
[17:29:40] <Joel Jaeggli> alain - very clear context e.g. this is iptv
[17:30:31] <Joel Jaeggli> reamins abstract until we put traffic on it.
[17:30:58] <Joel Jaeggli> source - things in the middle, edgepoints on different ip versions
[17:31:27] <Joel Jaeggli> maybe other is enterprise multicast vpn solution
[17:31:42] <Joel Jaeggli> at the abstract level we're missing the ment
[17:32:22] <Joel Jaeggli> "" from tsinghua univerity - 4-6-4 doesn't just reside within the ssm space.
[17:33:42] <Joel Jaeggli> bill prestegn - respond to alains point if we desgin exclusively for a particular use case we risk doing other applications a dis-service
[17:34:39] <Joel Jaeggli> alain - softwire needed this eg context for in paris and hong kong meetings
[17:35:00] <Joel Jaeggli> greg- we need set theory
[17:35:19] <Joel Jaeggli> i chun from cisco - is the problem space just with the routers
[17:35:59] <Joel Jaeggli> going throught the first scenarios I don't see a need for 34 and you can do them with 1/2
[17:36:13] <Joel Jaeggli> if you are assuming this is happening at the router
[17:37:17] teco.boot joins the room
[17:37:17] <TomT> With stuff like DS-lite you get integration of functions into customer premise equipment (B4, still router, though)
[17:38:00] Ole Troan leaves the room
[17:39:08] <Joel Jaeggli> if service provider can offer a v6 address to their customer there is then can allocate a a v6 address
[17:39:55] Ole Troan joins the room
[17:39:57] <Joel Jaeggli> - cancan huang
[17:40:24] <TomT> I didn't really
[17:40:51] <Joel Jaeggli> stig - rpf?
[17:43:05] <Joel Jaeggli> greg - anymore suggestions / scenarios
[17:43:27] <Joel Jaeggli> greg - speculative vs real scenarios
[17:43:40] <TomT> No requirement for videoconferencing?
[17:43:57] <Joel Jaeggli> looking for itemization of scnearios, presentations from operators on what their problems are
[17:44:44] <Joel Jaeggli> marshall - eubanks multicast for videoconferncing may be an idea whose time has passed
[17:45:34] <Joel Jaeggli> speak to talk idea, sort of birdirt like within an enterprise, and distribution of digital suff
[17:47:14] <Joel Jaeggli> stig venas but 8 years ago we did it with like 4 and 6 recievers.
[17:47:19] satoru.matsushima joins the room
[17:50:58] <Joel Jaeggli> greg - next presentation is problem statement
[17:51:39] <Joel Jaeggli> multi-tran requirements - yue li
[17:51:58] ꈲ joins the room
[17:52:17] <Joel Jaeggli> put some things on the table so that we can dicuss it
[17:52:24] <Joel Jaeggli> requirements
[17:52:49] <Joel Jaeggli> transition mechanism should be transparent to source or recivers
[17:53:17] <Joel Jaeggli> alain durant define reciver
[17:53:49] <Joel Jaeggli> it could be device watching the stream or the cpe
[17:53:59] <Joel Jaeggli> yue - we define it as the client
[17:54:38] <Joel Jaeggli> reuse existing multicast protocols
[17:54:58] <Joel Jaeggli> greg - reqruiement 2 should be requirement 1
[17:55:46] <Joel Jaeggli> le huang - when you try to translate source you have to change rpf
[17:56:14] <Joel Jaeggli> to keep pim as before may not be realistic
[17:56:40] <Joel Jaeggli> may want to remove that constraint
[17:56:57] <Joel Jaeggli> dave thatler - follow up, r1 should be multiple requirements
[17:57:18] <Joel Jaeggli> sending applications and reciveing applications are two requiremetns
[17:59:34] <Joel Jaeggli> requirement for interworking of control protocols
[18:00:14] <Joel Jaeggli> eg. mld igmp
[18:00:28] <Joel Jaeggli> dave thaler why is that a requirement??
[18:01:06] <Joel Jaeggli> yue li - is nice to support ssm and asm
[18:01:16] <TomT> In a DS-lite scenario (or 6rd) you get IGMP/MLD interworking
[18:01:31] <Joel Jaeggli> ron b - the last presentation aid we shouldn't
[18:02:19] <Joel Jaeggli> yue l i- content integerity must be preserved.
[18:02:39] <Joel Jaeggli> i chin - not sure that 6 7 8 are requirements
[18:06:18] <Joel Jaeggli> tina - preserve source address trhough double translation as an operational requirement?
[18:06:47] jpc joins the room
[18:06:51] <Joel Jaeggli> marshall - reword 7 to say existing excryption or drm scheme should not be broken
[18:07:08] <TomT> Technical requirement, I think -- have to have this to coordinate signalling and distribution
[18:07:20] <Joel Jaeggli> ron many translations have nat, I haven't seen a requirement to support that.
[18:08:07] <Joel Jaeggli> alain - my previous point about not duplicating streams is that here ? (next slide actually)
[18:08:53] <Joel Jaeggli> marshall - don't break l2 snooping
[18:09:25] <Joel Jaeggli> chen i chen
[18:09:58] <Joel Jaeggli> bob briscoe - bandwidth duplication isn't a requirement it's an ssumption
[18:10:15] <TomT> A goal
[18:10:43] <Joel Jaeggli> marshall - I'm going to counter that
[18:11:10] <Joel Jaeggli> people send multiple streams for redundancy and this shouldn't break that
[18:11:26] <Joel Jaeggli> e.g. because of path redundancy
[18:12:15] <Joel Jaeggli> dave t - there is a goal that an opperator has to minimize bandwidth
[18:12:56] <Joel Jaeggli> - r9 is optional e.g. it's subjective
[18:13:34] <TomT> Minimize bandwidth subject to QoE constraints
[18:18:55] <Joel Jaeggli> dave thaler comment on 11 a good to phrase that is the source and the reciever ...
[18:20:37] <Joel Jaeggli> yu li - done
[18:20:53] <Joel Jaeggli> greg - detailed accurate notes ?
[18:21:47] <Joel Jaeggli> tranistion issues - cathy zhuo
[18:21:58] <TomT> Cathy Zhou
[18:22:21] <Joel Jaeggli> technical issues -
[18:22:42] <Joel Jaeggli> multicast distribution enabled in three stages
[18:22:55] <Joel Jaeggli> 1. address aquistion by reciver
[18:23:08] <Joel Jaeggli> 2. multicast singalling for reciver to source
[18:23:27] <Joel Jaeggli> 3. transport of content from source to reciver
[18:24:07] <Joel Jaeggli> may need translation at aquisition
[18:24:28] danwing joins the room
[18:24:55] <Joel Jaeggli> i chin from cisco - are you trying to should this part of the problem be in scope
[18:25:05] <Joel Jaeggli> dave thaler - absolutely
[18:25:29] <Joel Jaeggli> would be great if it required no changes to the application but I don't know if that's feasible
[18:25:32] <TomT> My view is -- in scope, because it requires coordination with any translation used in the other stages
[18:25:46] <Joel Jaeggli> doing 2/3 of a solution is not feasible
[18:26:33] <Joel Jaeggli> colin perkins - setting some requirements is a good place for this working group to do actual solution might belong in dispatch
[18:26:55] <Joel Jaeggli> marshall - this problem is somewhare along the line to necessary
[18:29:23] <Joel Jaeggli> greg/joel - using the mechanism that the address family uses
[18:29:59] <Joel Jaeggli> tim chown - do we we have to assume that the client isn't going ot change?
[18:30:12] <Joel Jaeggli> or might they try both and pick that one.
[18:30:28] <Joel Jaeggli> bill - don't boil the ocean
[18:31:03] <Joel Jaeggli> pretty simple from one address family to the other
[18:31:16] <Joel Jaeggli> to distinguish
[18:31:51] <Joel Jaeggli> stig - well known prefix eg. a /96 to translate from 4 to 6
[18:32:21] <Joel Jaeggli> or change the mappings on the fly (nat box style) probably horrible
[18:32:44] <TomT> Key point again is that any translation has to be coordinated with the mappings used in the other stages
[18:33:14] <Joel Jaeggli> thaler - does the sender know what address the reciver is going to see? if there is an interdomain case probably not
[18:35:08] <Joel Jaeggli> spencer dawkins - suggestion was made that there was an 80% solution to t this.
[18:35:33] <Joel Jaeggli> for the purpose of the of bof do people think that this is a solvable problem
[18:36:04] <TomT> Operational issue, I think
[18:36:08] <Joel Jaeggli> thayler - yes it's sovlavble if yo uchange the requirements
[18:37:23] nmm joins the room
[18:37:24] <Joel Jaeggli> marshall - it's hardest to change recivers and hosts near recievers.
[18:38:12] <Joel Jaeggli> thayler - is it possible to do this without changing hosts, maybe not
[18:38:50] Magnus Bergroth joins the room
[18:39:04] <Joel Jaeggli> if the elements are under control of the same organization then yeah
[18:39:10] satoru.matsushima leaves the room
[18:40:52] <Joel Jaeggli> stig in the last mile you don't want the clients act independantly.
[18:41:18] <Joel Jaeggli> alain - we need diagrams for use cases
[18:41:57] <Joel Jaeggli> multicast signaling
[18:43:51] <Joel Jaeggli> igmp - mld use case isn't going to happen?
[18:44:15] <TomT> DS-lite or 6rd, where transaltion happens on customer premises
[18:45:31] <Joel Jaeggli> bill a the router and the host out of sync cannot happen
[18:46:38] <Joel Jaeggli> toerless - are we already at the point of building a big matrix of protocols
[18:47:31] <Joel Jaeggli> translation techniques - translation encapsulatio and dual stack
[18:47:40] <Joel Jaeggli> stateless translation may be an options
[18:48:07] <Joel Jaeggli> draft doudicar-behave-64-multicast may be a candidate
[18:49:17] <Joel Jaeggli> dave thatler - multicast is inherntly statefull in multicast forwording devices, don't see an applications
[18:50:43] <TomT> Stateless mapping means less coordination required between different nodes handling signalling and content
[18:51:23] <Joel Jaeggli> tina - term managment for the bof still have a short time.
[18:53:20] <Joel Jaeggli> encapsulation -
[18:54:15] <Joel Jaeggli> i chin using unicast encpsulation causes loss of efficiency.
[18:54:45] <Joel Jaeggli> dual stack netowrk operation
[18:54:48] <Joel Jaeggli> -
[18:55:04] <Joel Jaeggli> may need doubl translation for some streams at the edge
[18:55:55] <Joel Jaeggli> shep - we are pressed for time
[18:56:05] <Joel Jaeggli> please join mailing list
[18:56:18] <Joel Jaeggli> we are going to send out a call for use cases.
[18:56:40] Wes George leaves the room
[18:57:21] <Joel Jaeggli> marshall - is there a use case document
[18:58:25] nmm leaves the room
[18:59:12] <TomT> Thanks, Joel, though I guess my comments were just background noise
[18:59:16] simon leaves the room
[18:59:21] Magnus Bergroth leaves the room
[18:59:51] danwing leaves the room
[19:00:06] <Joel Jaeggli> they were not
[19:00:22] <Joel Jaeggli> they are captured in the minutes
[19:00:22] <TomT> OK, double thanks