Re: [multrans] Multrans Miniutes

[Tina TSOU <[e-mail]>]

">    Dave: was this all the use cases ?
>
>    Tina: Just the use-cases from china telecom. SOmewhat more generalized
>    from actual customer case."
What I said exactly is
">    Tina: The slides here are the use-cases from China Telecom and France Telecom. SOmewhat more generalized
>    from actual customer case. The complete and having commercial demand generalized use cases are in the problem statement and use case draft and the issues slides."



Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: Tina TSOU 
Sent: Tuesday, November 22, 2011 4:45 PM
To: '[e-mail]'; [e-mail]
Cc: [e-mail]; Susan Hares
Subject: RE: [multrans] Multrans Miniutes

Sure, thank you for cc the list. I appreciate it.
Happy Thanksgiving!


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Greg Shepherd
Sent: Tuesday, November 22, 2011 4:42 PM
To: Tina TSOU; [e-mail]
Cc: [e-mail]; Susan Hares
Subject: Re: [multrans] Multrans Miniutes

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.
>
>
>
_______________________________________________
multrans mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/multrans