Re: [multrans] Multrans Miniutes

[Greg Shepherd <[e-mail]>]

Please keep the multrans mail list on the distribution of all things
related to multrans.

Thanks,
Greg

On Tue, Nov 22, 2011 at 4:29 PM, Tina TSOU <[e-mail]> wrote:
> Toerless, Marshall,
> Some supplements from my memory and Tom's audio record:
> 1. The part of "Spencer Dawkin: ..." is something like this if I remember corectly:
> "Twenty people want to do SOMETHING, and maybe three people don't think we should, so we should do SOMETHING".
>
> 2. Dave Thaler said
> "how multicast addresses are discovered on each side of the address family boundary."
>
> 3. There are 10 in the room + 1 in the jabber said "working group, then interim meeting", not 9+1.
> When Greg counted 10 in the room, then I said from the my seat "Tom said 'I will break the tie' in the jabber", Greg said "I don't understand what u said", sorry about my Chinese accent.
>
> Tina
>
>
> -----Original Message-----
> From: Tina TSOU
> Sent: Monday, November 21, 2011 4:55 PM
> To: '[e-mail]'
> Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares
> Subject: RE: Multrans Miniutes
>
> Thank you, Toerless.
>
> " Tina: work coming from group of people taking multicast work identified
>  out of behave, then derived the use cases etc. and figured that it
>  touches multiple areas and that's why they feel this justifies a WG."
>
> Can you rephrase what I said in the meeting as following which I remembered,
> " Tina: work coming from group of people taking multicast work identified
>  out of behave, then derived the problem and use cases, priority of issues etc.
>  it was everything in Prague, then strip encapsulation in Quebec, and now its translation + ops,
>  figured that it touches BEHAVE, MBONED, V6OPS and PIM and that's why they feel this justifies a WG."
>
>
>
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, November 21, 2011 12:04 PM
> To: Tina TSOU
> Cc: Marshall Eubanks; Greg Shepherd; Ron Bonica; Susan Hares
> Subject: Re: Multrans Miniutes
>
> I had sent my minutes after the meeting directly to greg. Sorry,
> couldn't remember marshalls mail.
>
> Appended.
>
> Cheers
>    Toerless
>
>
> Agenda:
>
> Drafts:
>
> Problem statement draft
>
> Framework for IPv4/IPv6 Multicast Translation
>
> Multicast Proxy in IPv4/IPv6 Transition
>
> Agenda
>
> Welcome/Agenda bash/Minutes
>
> Stig:  Item missing.
>
> Marshall: This is multicast IPv4 to IPv4 transition BOF, NOT TRANSLATION.
>
> Greg: less people here in BOF than last time.
>
> Alain Durand: lot of this work has been done in Softwire
> Greg: but this is transition, not translation.
>
> Framework for IPv4/IPv6 Multicast Translation : Stig Venaas
>  draft-venaas-behave-v4v6mc-framework-03.txt
>
>  Slide 2: Overview:
>  - behave did a unicast translation framework, RFC6144
>  - this draft started as a multicast version of that
>  - ...
>
>  Slide 3: Scenarios
>  - IPv4/IPv6 network/sender/receiver <->
>
>  Slide 4: Multicast and translation
>
>  Slide 5: IPv6 nework receiving multicast from IPv4 Internet
>
>  Slide 6: IPv6 network receiving multicast from IPv4 Internet
>
>  Slide 7: Well-known multicsat prefix(es)?
>
>  Slide 8: IPv4 network receiving multicast from IPv6 Internet
>
>  Slide 9: New signaling mechanisms
>
>  Greg: TOS translation ?
>  Stig: Should probably match the unicast translation itis using.
>
>  DaveT(haler): Want mapping to be the same as unicast mapping if
>  unicast packets are sent to the source. Problem is slightly harder
>  than the simplre unicast case. Unicast: How do you get the  address.
>  Unicast addresses can be learned via DNS. In multicast you are usually
>  joined with literal addresses.
>
>  Greg: This is an SSM question.
>  Greg: It is less a translation than a location.
>  Dave: Right, eg: follow the default-route.
>
>  Stig: Document has case where unicast translation is different from
>  multicast translation for example when paths are different.
>  Dave: Have an idea here, but depends on what is needed by use cases.
>
>  Ron Bonica: You said stateful is almost impossible. This needs some
>  qualification. Eg: limiting the groupa address  space makes this
>  fairly simple. Even the IPv4 address space is much larger than what's
>  needed, so only a small address range may need to be mapped.
>
>  Stig: Agreed if you can limit yourself to known prefixes. For example
>  as a content provider.
>
>  Ron: Given how new IPv6 multicast is, we should hopefully be able to enforce
>  this addressing limitation.
>
>  Sue Hares: Did i understand correctly that only small set of addresses
>  are mapped ? This is the address translation function only ?
>
>  Dave: Summary unicast of BEHAVE: Statefull and stateless. A small
>  range of v6 can be mapped to v4 stateless, otherwise statefull is needed.
>
>  Ron: Translator can work in two ways: Statically join to everything
>  or only join dynamically.
>
>  Stig: For dynamic mode you first need the joins to reach you, so you may
>  need to be an RP if ASM is used.
>
>  Ron: DM do not need to talk about, but SM is interesting.
>
>  Chairs: Primary use case is SSM.
>
>  Unintelligble discussion about how sources vs. groups are discovered
>  (both in SDP).
>
>  Hitoshi: Question: SDP related. Thinks it is not really a good idea
>  to change SDP. Should not change data in it.
>
>  Second question: is there for translation  negotiation ?
>  Stig: difficult.
>
>  Toerless: SDP is translated also in unicast solutions.
>
> Use Cases : China Telecom : Oian Wang : 15 minutes
>
>  Slide 1: 6-6-4 Case
>  Slide 2: 6-4-6-4 Case
>
>    Marc Blanchet: for 6-4-6-4 was there an IPv4 network that was replaced by an
>         IPv6 network.
>    Presenter: Actually dual-core network.
>    Marc Blanchet: Why then use IPv6 transport instead of native IPv4
>    Presenter: ...
>
>    Tina: This is the IPTV network, IPv6 only.
>
>    Dave: blue on the let and right connected by non IPv4 mcast should
>    mean 6 over 4 across the non mcast capable ipv4 network.
>
>    Ron: Special case of first case.
>
>    Tina: explains old equipment causing secon
>
>    Toerless: On first slide, what additional signaling/data goes between
>    v4 source and v6 network ? RTCP, SDP, RTSP, EPG, anything else.
>
>    Presenter: Need to get back to you.
>
>    Dave: was this all the use cases ?
>
>    Tina: Just the use-cases from china telecom. SOmewhat more generalized
>    from actual customer case.
>
> Use Cases : France Telecom : Christian Jacquenet
>
>  Slide 1: Context
>    - Choose to deploy DSliste for new STB that can't get a unique IPv4
>      address anymore.
>  Slide 2: 4-6-4
>
>    Toerless: SSM ? - Yes
>
>    Stig: WIll there also be IPv6 receivers ? - Yes
>     Stig: So tunneling is not a good option.
>
>    Ron: DSlite means tunneling through the v6 network ??? - No!
>      Christian: No tunneling anywhere
>
>      specific use case detail: DSlite required.
>      otherwise same use case as china telekom ?
>
>    Toerless: USe case definition should more explicitly include
>     descriptoin also of native receivers to make sure it is taken into
>     account (not only the receivers requring translation/transition).
>
>    Marshall: Asking whether static translation is done.
>    Christian: This is just use case, not solution, but that exactly
>    is discussed as addition for multicast to DSlite.
>
>    Marshall: How about additional IPv6 sources intot he IPv6 cloud,
>    this would complicate the problem.
>
>    Christian: Yes, when there are IPv6 sources, there should not be any
>    more DSlite then anymore, but only native IPv6 service.
>    Only want to address very short term constraints. Just because of
>    insufficicent short term roadmaps of STB vendors.
>
>    Marshall: I can also see solutions if there are IPv6 sources in the
>    network.
>
>    Christian: But we want to avoid that context.
>
>    Marc: Very similar to cases in before.
>
>    Stig: possible solution: Lets make all IPv6 sources send to well
>    defined IPv4 prefixes that map to IPv4.
>
>    Christian: There is a demo of this in the terminal room.
>
>    Dave Thaler: Is there a requirement that the addressing after two
>    times translation is again the same as the original ?
>
>    Marshall: there is a difference between requirement and having this
>    be done as an option.
>
>    Dave: Has to do a lot with how the receiver learns about the source/group.
>    Would constrain set of options if it was a requirement for addresses to
>    be the same.
>
>    Spencer Dawkin: ...
>
> Multrans Issues : Eubanks : 20 minutes
>
>  Network example 1: IPvX-IPvY-IPvY
>
>    Toerless: do we really need this, this is transition, so the
>    evolution of the network is v4 to v6.
>
>    Marshall: There can be a lot of combination of v4 to v6 or vice versa
>    along the path.
>
>    Ron: Find it easy to believe to add v6 receivers. Find it easy to
>    believe v6 network to v4 receivers.  Have hard time to consider adding
>    v4 receivers to v6 sources/v6 network.
>
>    Marshall: Want to flesh this out. Have representation of two operators.
>    Christian: agree with ROns comments. Can constrain the set of options.
>
>    Stig: Y=4 is most useful for now. Also important to have support for
>    mix of receivers.
>
>    Alain Durand: Reality is that there is a very popular vendor of
>    sources with no plan to go to IPv6. Receiver today are now IPv4.
>    There may be v6 receivers in the future
>
>    Marc: Have taled about this for days and days and days. I am a firm
>    believe that we continue to talk about this. Need much more time
>    to agree on scenario. Just consider it may take a long time.
>
>    Dan Wing: It took BEHAVE 5 hours to just conclude on the set of
>    cases and then prioritize.
>
>  Content walk thhrough
>
>    DaveT: Setp 0 is missing. How do you figure out the channel that
>    had to be put into step 1.
>
>  Content Distribution walk thhrough
>
>  Slide 6: Issues (1)
>
>    Stig: Key thing is that it should be a standard mapping.
>
>    Ron: Given how all sources start as v4, we should use stateless model.
>
>  Slide 7: Issues (2)
>
>    Stig: Should not assume the translation is an ALG.
>
>    Discussion about AF and ALG terminology.
>
>    Dave: AF and ALG boxes may not need to be the same box. Is that what
>    was meant by Stig in before ?
>
>    Dan Wing: ALG - Application Layer Gateway: Examining and Modifying
>    application layer payload in signaling. The more complex it is the
>    harder the ALG job becomes.
>
>    Marshal: Is multicast immune to this problem ? Classical signaling ?
>
>    Dan: How classical do we become here ? SAP ? HTTP, HTTPs ?
>
>    Ron: We probably don't tal about an ALG here. Just relays data-plane
>    between v4/v6.
>
>    Stig: DOn't want to argue too much but keep it open what the AF
>    function is doing.
>
>    Spencer: ... ?
>
>    Hitoshi: ...
>
>    Toerless: Difficult part is when addresses in EPG need to be changed
>    or otherwise application backends need to be aware of mapping of
>    v4/v6 addresses.
>
>    Dave: The primary issue you haven't gotten to is how to learn
>    T(S) and T(G). Possible answers: a) proprietary -> non IETF.
>    b) assume signle discovery protocol, eg: DNS in Unicast. And then
>    do ALG for that protocol. c) most likely: STB also have no plans
>    to move to IPv6. Information receiver gets is exactly what the source
>    thinks. Even if it is in a different address family than the source,
>    and make that work.
>
>    Marshal: back up. v4 source, v6 receiver. Application gets v4 address
>    information. Receiver then needs to apply magic.
>
>    Dave: In category 3 either the application needs to do this magic
>    or the OS/stack.
>
>    Marshal: yes.
>
>    Dave:
>
>    Toerless: category 4 ? Eg: can't change the app on the client, can't
>    change the stack, so mayube instead of then actually having an
>    IPv6 only receiver, we make it a dual stack client behind eg: DSlite,
>    and IPv4 is only used to receive multicast.
>
>    Discussion Marshal/Dave. Not clear what is fully in scope.
>    Marshall: DOn't want to discuss web design.
>    Dave: This excludes case a)
>
>    Marshal: What makes it proprietaary to use a web-page ?
>    Dave: Because of the required ALG.
>
>    Marc: May actually want to device SDP ALG.
>
>    Dave: SDP my itself is not a protocol, it's just a data-model that
>    needs to be carried in a transport. And then yes, this could be
>    category a) or b).
>
>    Marshal: not supposed to solve this.
>
>  Network Example 2: IPvX-IPvY-IPvX
>
>    Marshal: Should this not done via a mechanism like softwires ?
>
>    Toerless/Dave: Discuss unicast only use case of china telecom,
>    agree AMT would be appropriate, but this may not even need to
>    be in scope for this BOF/WG ?
>
>    Marc: Are we ever getting to discuss whether to make a owrking group ?
>
> Room discussion : Proposed Multrans Charter and nex steps : Remaining time
>
>  Marshal: There seems to be energy to work on this. Raise hand if
>   you are willing to work on this.
>  18 in room +1 on jabber raise hand.
>
>  Alain: There is already work chartered in another working group
>  softwires.
>
>  Dave: This BOF is a spinoff of the BEHAVE working group. Needs NAT
>  and multicast experts together. This work would not overlap with BEHAVE.
>
>  Alain is chair of softwires.
>
>  Marshal: Is this overlapping with softwires.
>
>  Alain: Very large overlap.
>
>  Stig: Softwires is limited to only encapsulation.
>
>  Greg: There is also the mesh draft which is not encapsulation.
>
>  Greg: We need to collect what's missing from the work of other WGs.
>
>  Marshal: Do we feel there is sufficient difference between softwires
>  and what could be worked on in a to be formed WG ?
>
>  Dave: Suggest different question: Do people have enough information
>  if this a tractable problem. Primarily discovery is the biggest problem.
>  Fairly good confidence that data translation solution can be worked out.
>
>  Greg: DSlite, softwires, right. Data is not the issue.
>
>  Marc: Focussing on which use case to work on requires dedicated time.
>  after that is done, we will have a good idea whether we need a WG.
>
>  Stig: This work could be first done in MBONED WG.
>
>  Alain: One bit in softwires that is not fully fleshed is the translation
>  piece. What was not discussed/figured out is discovery.
>
>  Toerless: Start discussing use-cases in mboned, review, recommend
>  solution elements for them. Take existing work in other WGs into account
>  (softwires). Figure out missing pieces. SImple pieces like translation
>  could even be done in MBONED.
>
>  Greg: Alain suggesting interim meeting of dedicated group of people
>  doen by chair of group hosting work (eg: Alain -> softwires).
>  Identify piece missing, then forward those to MBONED.
>
>  Greg: Interim meeting did not do multicast work. Suggest to do a
>  multicast-only interim softwires WG.
>
>  Alain: Yes.
>
>  Ron: Suggests joint interim softwires/mboned meting, parse out which
>  parts are to be resolved where.
>
>  Tina: Work here is related to many WGs.a Better to have a single dedicated
>  working group.
>
>  Stig: Work wostly limited to mboned.
>
>  Ron: WOuld likely need STB people involved.
>
>  Greg: Will not have all technical people if it's only done in mboned.
>
>  Stig: Issue is how to get right people together. Need people who are
>  not in mboned involved. Need to get enough time for this, can't not be
>  pushed off.
>
>  Greg: Interim meeting to come up with conclusion.
>
>  Tina: can we go through four slides of proposed charter.
>   - walking through four proposed goals
>     - requirements
>     - alg
>     - translation
>     - configuration and management
>
>  Alain: To early because we are not forming a WG.
>
>  Dave: vote for webex, primarily mboned, also behave, see little
>  overlap with softwires. encap is softwires expertise.
>
>  Alain: Expertise of softwires is use cases described by Christian.
>
>  Dave: would like to see at least to se one internet draft on how
>  the discovery is done before forming a working group. Even if it's
>  not the best idea, but proof of exstance of a possible solution to the
>  discovery would be needed first.
>
>  Tina: work coming from group of people taking multicast work identified
>  out of behave, then derived the use cases etc. and figured that it
>  touches multiple areas and that's why they feel this justifies a WG.
>
>  Marc: proposes the interim. ALso a believer that after the focus
>  session not everything will be done. Also fear that it will spread
>  all over the place. A dedicated working group could help to keep
>  the architecture in one place. Otherwise we will get a puzzle solution.
>
>  Christian: Second comment. interim with softwires. mboned and softwires
>  are natural placeholders and need to be involved in interim.
>
>
>  Ron: One draft about address mapping could be taken through AD sponsor.
>
>  Ron: There is no requirement that there is a BOF before a WG. There
>  is the requirement it is a tractable problem and that there is
>  energy and maybe some commercial demand and that it fits in the area.
>  If we had an interim meeting hosted by other WGs and we find it is
>  a tractable problem, and we feel we do not have a good enough umbrella
>  in other WGs then we can spin off a WG.
>
>  Tina: If we think about interrim before Paris - little time
>  Dave: Webex.
>
>  Alain: Not interrested in repeat of this BOF. Instead figure out the
>  gaps, what's missing. Having a discussing at end of interim about
>  charter would be recipe for desaster.
>
>  Opinion poll:
>    a) Form a working group according to proposed charter
>       9 (room) + 1 jabber.
>    b) interim webex, mboned + softwires (+ behave)
>       maybe february time frame.
>       10
>    c) go home, do nothing
>       0
>
>   Who is opposed to interrim: 0
>   Who would participate in interrim: 15
>   Opposed to WG now: 10
>
>   Ron: IETF is consenus based organization. Consensus in the room is fine,
>   With the current status in the room where 50% think we need an
>   interrim to see whether the work is tractable would be counted as
>   non sufficient consensus.
>
>   Greg: Let's have the interrim.
>
>
>