Re: [multrans] Issues charts for presentation at the BoF

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Tina Tsou [mailto:[e-mail]]
> Sent: Tuesday, June 28, 2011 10:13 AM
> To: 'Dan Wing'; 'Tom Taylor'; 'Jacni Qin'
> Cc: 'Multicast Transition'
> Subject: RE: [multrans] Issues charts for presentation at the BoF
> 
> 
> 
> 
> We keep our promises with one another – no matter what!
> 
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Dan Wing
> Sent: Tuesday, June 28, 2011 9:58 AM
> To: 'Tom Taylor'; 'Jacni Qin'
> Cc: 'Multicast Transition'
> Subject: Re: [multrans] Issues charts for presentation at the BoF
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Tom Taylor
> > Sent: Tuesday, June 28, 2011 5:54 AM
> > To: Jacni Qin
> > Cc: Multicast Transition
> > Subject: Re: [multrans] Issues charts for presentation at the BoF
> >
> > Thank you for your comments. Responses below.
> >
> > On 27/06/2011 10:45 PM, Jacni Qin wrote:
> > > hi Tom,
> > >
> > > Some comments,
> > >
> > > Page 8:
> > > Issue: translation of a given address tends to happen
> > > at multiple nodes, and at different stages within the
> > > same node.
> > > ● Need the same mapping or its inverse, as applicable, to be
> > > used each time a given address is translated. Implies inter-
> > > nodal coordination in some form.
> > >
> > > Jacni>: The coordination is probably required in the stateful
> > > translation. While in some stateless cases, maybe not.
> >
> > [PTT] I agree there is less coordination for stateless, but at least
> > the
> > different nodes have to be provisioned with the special prefix being
> > used to construct IPv4-embedded IPv6 addresses in this network.
> 
> They need not necessarily be 'provisioned' (configured).  They could
> learn the network's prefix for multicast translation.
> draft-ietf-behave-nat64-learn-analysis discussed a bunch of techniques
> for learning unicast NAT64; I expect almost all of those could be
> useful for multicast NAT64 (or multicast NAT46) and have pros/cons.
> [Tina: So what changes do you want to see from Page 8?]


how about:

OLD:
Issue: translation of a given address tends to happen
at multiple nodes, and at different stages within the
same node.
● Need the same mapping or its inverse, as applicable, to be
used each time a given address is translated. Implies inter-
nodal coordination in some form.

NEW:
Issue: translation occurs in multiple nodes, and different
stages within a single node
● Stateful translation:  nodes need to coordinate
● Stateless translation:  nodes need same transformation algorithm


(overall, in my opinion, the entire presentation could benefit from a 50% reduction of its word count.  This makes a better presentation because the audience won't be tempted to read the slides, and the speaker won't be tempted to read the slides to the audience.  Instead, the speaker provides additional detail to the main points on the slide.).

-d


> -d
> 
> 
> > > Page 9:
> > > Jacni>: I do agree with that the original design of DS-Lite or 6rd
> > > (unicast-based tunnel)
> > > should not be used for multicast delivery, but that can NOT lead to
> > the
> > > conclusion stated in the second bullet ("Possible to use
> > encapsulation in
> > > the form of a softwire mesh between multicast routers.").
> > > Mesh is a different use case, the mesh approaches do not apply to
> DS-
> > Lite or
> > > 6rd cases either.
> >
> > [PTT] I can drop the term "softwire mesh" and say simply that it is
> > possible to use tunnels between the multicast routers, if you want.
> But
> > isn't a mesh required to support the routing of the PIM signalling? I
> > thought I was using the term in the same sense as
> > draft-xu-softwire-mesh-multicast-01.
> > >
> > >
> > > Page 10:
> > > Jacni>: The discussions about dual-stack network are a little
> > confusing. The
> > > network may be dual-stack enabled from the device connected to
> > headends, to
> > > the IGMP/MLD Querier.
> > > Or the network may be partially dual-stack enabled. The latter one
> is
> > > "native transport + translation", and can be simplified as a
> > translation
> > > case.
> > > Please refer to the -01 of the PS draft, maybe some text in the
> > Section 3.3
> > > can be reused:
> > > http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-
> 01#page-
> > 8
> > >
> > [PTT] Page 10 deals with the specific case of a single dual stack
> > network between the sources and the receivers. I actually have mixed
> > versions in mind at both ends, although I know that IPv6 sources have
> > lower priority. So the intention is to indicate some strategies for
> > network operations under those particular assumptions.
> >
> > I think you are saying that this is not the use case that you are
> > pointing at in section 3.3 of the problem statement. I did not intend
> > it
> > to be so. What I should do is expand this page to two charts, giving
> > the
> > assumptions I just stated and adding the diagrams Dan suggested.
> > >
> > > Cheers,
> > > Jacni
> > >
> > > On Tue, Jun 28, 2011 at 4:13 AM, Tom Taylor<[e-mail]>
> > wrote:
> > >
> > >> Attached are the charts I propose should be presented on the
> > "issues" topic
> > >> at the MULTRANS BoF. Comments in advance are welcome.
> > >>
> > >> Tom Taylor
> > >>
> > >> _______________________________________________
> > >> multrans mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/multrans
> > >>
> > >>
> > >
> > _______________________________________________
> > multrans mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/multrans
> 
> _______________________________________________
> multrans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multrans