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

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

> -----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.

-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