Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-behave-translated-multicast-01

From: Stig Venaas <[email-masked]>
Date: Tue, 01 Feb 2011 10:42:44 -0800

Hi

I have some comments on this draft.

First of all I'm trying to understand the difference between
this and ID.venaas-mcast46. It looks like you are doing double
translation or tunneling, as opposed to a single translation, right?

The main question I have, is whether you need stateful mapping
and mapping lookups etc. for the 4-6-4 case (for 6-4-6 it is
more useful). I understand that it buys some flexibility, but
at a high cost.

What are the benefits over using a /96 IPv6 prefix and just
appending the IPv4 address? If you do this, then all that is
needed is to learn the prefix, unless it is a well-known
standardized prefix. It becomes a bit more complex for SSM
of course.

The proposed mapping function might work if there is a
single provider between the HMAF and BMAF. If you need to
traverse multiple networks, they would either need to agree
on mappings and exchange state, or you need to re-translate
on the networks' borders.

Section 3.1 (How It Works) seems to only cover the SSM
case. ASM is a bit interesting in that the BMAF will need
to request mappings for the unicast addresses of the source
traffic it receives. This happens without the HMAF requesting
a mapping.

One interesting thing to consider in this case is whether it
is worth using a single (S,G') for say (S1,G) and (S2,G).
Assuming that all ASM hosts joining G wants all the sources,
this can reduce the amount of state and the pool of unicast
addresses needed.

Note that one could in fact consider doing SSM with a
single (S,G') in the provider network for an ASM group G
and all its sources.

You may need to consider multiple BMAFs if the provider
is multihomed or connects to multiple content providers.
I think the mapper would determine which BMAF to use when
the HMAF makes the request.

Stig

On 1/31/2011 12:29 PM, Tom Taylor wrote:
> I added a section giving numerical examples.
>
> Tom T
>
> -------- Original Message --------
> Subject: New Version Notification for
> draft-tsou-behave-translated-multicast-01
> Date: Thu, 27 Jan 2011 18:55:07 -0800 (PST)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> CC: [email-masked],[email-masked],[email-masked]
>
>
> A new version of I-D, draft-tsou-behave-translated-multicast-01.txt has
> been successfully submitted by Tom Taylor and posted to the IETF
> repository.
>
> Filename: draft-tsou-behave-translated-multicast
> Revision: 01
> Title: A Generic Approach to Multicast Translation In Support of IPv6
> Transition
> Creation_date: 2011-01-28
> WG ID: Independent Submission
> Number_of_pages: 12
>
> Abstract:
> Consider a situation which will arise in many IPv6 transition
> scenarios, where Network A, to which a host is attached, supports one
> IP version, but the host and Network B support a different IP
> version. Suppose that the host wishes to access a multicast group
> which is rooted or sourced in Network B. This document specifies a
> stateful translation mechanism whereby the host can obtain its
> desired access using the native multicast capabilities of Network A.
>
>
>
>
> The IETF Secretariat.
>
>
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave