Subject: [multrans] link to meeting slides for multrans BoF

From: Tina TSOU <[email-masked]>
Date: Fri, 11 Nov 2011 19:24:35 +0000

Dear all,
Here is the link to meeting slides for multrans BoF.
http://www.ietf.org/proceedings/82/agenda/multrans.txt
http://www.ietf.org/proceedings/82/slides/multrans-0.pdf
http://www.ietf.org/proceedings/82/slides/multrans-1.ppt
http://www.ietf.org/proceedings/82/slides/multrans-2.ppt
http://www.ietf.org/proceedings/82/slides/multrans-3.ppt

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

---

From: Tom Taylor <[email-masked]>
Date: Fri, 11 Nov 2011 15:10:37 -0500

The current set of "Issues" charts is at multrans-2. Do people have 
comments?

On 11/11/2011 2:24 PM, Tina TSOU wrote:
> _______________________________________________
> multrans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multrans
>
>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 11 Nov 2011 22:22:19 +0000

Tom,
Per discussion with Stig yesterday, the framework draft considers a single translator, which he think is a useful scenario not in the current version of issues slides.

Best Regards,
Tina TSOU

---

From: Tom Taylor <[email-masked]>
Date: Fri, 11 Nov 2011 18:58:05 -0500

I can add the slide, but Stig, what additional issues are currently missing?

On 11/11/2011 5:22 PM, Tina TSOU wrote:
> Tom, Per discussion with Stig yesterday, the framework draft
> considers a single translator, which he think is a useful scenario
> not in the current version of issues slides.
>
>
> Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Tom Taylor Sent:
> Friday, November 11, 2011 12:11 PM To: [email-masked] Subject: Re:
> [multrans] link to meeting slides for multrans BoF
>
>> Dear all, Here is the link to meeting slides for multrans BoF.
>> Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html
>>
>>
>>
>> _______________________________________________ multrans mailing
>> list [email-masked]
> _______________________________________________ multrans mailing
> list [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 12 Nov 2011 08:20:37 +0800

> Sent: Saturday, November 12, 2011 4:11 AM
> To: [email-masked]

Slide 7 says "Assuming AF1 is an ALG".  My comment:  don't build a system
requiring an ALG.

Slide 8:  yes, IPv6 and IPv4 on the access network is infeasible.  I mean,
isn't the access network where everybody has insufficient bandwidth for
carrying the same traffic on both IPv6 and IPv4, isn't it?

Slide 9, on Join Permanently.  This appears to be an optimization purely for
multicast, and appears to have nothing to do with the scope of the MultTrans
BoF.

-d

---

From: Simon Perreault <[email-masked]>
Date: Sat, 12 Nov 2011 09:52:16 -0500

> Slide 7 says "Assuming AF1 is an ALG".  My comment:  don't build a system

We need to be careful here. There are two types of ALGs: transparent and
non-transparent (from RFC2101). Only the transparent ALG is "evil". A
non-transparent ALG, one that operates within the boundaries of an application
protocol (e.g. a SIP B2BUA, an HTTP proxy), can be a fine, recommendable
transition mechanism.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Tom Taylor <[email-masked]>
Date: Sat, 12 Nov 2011 19:57:20 -0500

Below.

>> Sent: Saturday, November 12, 2011 4:11 AM
...
> carrying the same traffic on both IPv6 and IPv4, isn't it?
[PTT] Sorry, I don't get the linkage between this and what the slide says.
>...

---

From: Jacni Qin <[email-masked]>
Date: Mon, 14 Nov 2011 09:06:20 +0800

hi,

In multran-1, about the "IPv4 Access Network (not mcast capable)", do 
you mean Layer2 or Layer3?

Cheers,
Jacni

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Nov 2011 10:15:43 +0800

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Sunday, November 13, 2011 8:57 AM
> To: Dan Wing
> Cc: [email-masked]
> >> From: [email-masked] [mailto:[email-masked]]
> On
> >> Behalf Of Tom Taylor

The slide said something like "is it infeasible to run both IPv6
and IPv4 on the access link" -- or, at least, that is what I
interpreted the slide to mean.

If my interpretation is not the intent of the slide, the slide
should probably be made clearer.

-d

---

From: Tom Taylor <[email-masked]>
Date: Sun, 13 Nov 2011 21:58:33 -0500

Oops, I'll think about how to fix that up. The intended question was:
   - is it infeasible to have AF1 at the provider edge?
   - is it infeasible to have AF1 at the customer edge?
   - does one have an advantage over the other?

---

From: Tom Taylor <[email-masked]>
Date: Sun, 13 Nov 2011 21:59:20 -0500

As I understand it: Layer 3.

---

From: Jacni Qin <[email-masked]>
Date: Mon, 14 Nov 2011 11:10:44 +0800

Re-,

Sorry, I don't understand that, even in the native context, will it be 
used to deliver multicast services?

Cheers,
Jacni

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Nov 2011 11:14:56 +0800

> Sent: Monday, November 14, 2011 10:59 AM
> To: Dan Wing
> Cc: [email-masked]

Will there be a mix of customers with, and without, AF1?  E.g., "legacy"
customers who have not purchased or have not installed AF1?  The answer to
that question influences the answer to your question significantly.

-d

> >>> Slide 8:  yes, IPv6 and IPv4 on the access network is infeasible.
> I
> >> mean,

---

From: Tom Taylor <[email-masked]>
Date: Sun, 13 Nov 2011 22:17:37 -0500

They'll be delivered over the access network in unicast form.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 15 Nov 2011 00:33:23 -0800

> I can add the slide, but Stig, what additional issues are currently

I'm sorry for not having had time to check the list and follow up on
this. I'm not sure if I see any issues missing, it's more that all
the scenarios appear to have at least 2 AFs, although I believe the
most needed scenario is just a single AF where the source is of one
address family, and the receivers can be a mix.

Something like this:

IPv4 Receiver -----
                     \ ...... IPv4 source
                     /
IPv6 Receiver - - AF

When presenting this, I think it might be good to explain this most
simple scenario before the more complex ones.

Stig