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

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jun 2011 16:13:52 -0400

Attached are the charts I propose should be presented on the "issues" 
topic at the MULTRANS BoF. Comments in advance are welcome.

Tom Taylor

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Jun 2011 16:25:36 -0400

To the degree that this would be a working group to coordinate work in 
other working groups, I have to say based on experience that  such is a 
difficult path, prone to lots of problems and ineffectiveness.

Yours,
Joel

On 6/27/2011 4:13 PM, Tom Taylor wrote:
> _______________________________________________
> multrans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multrans

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jun 2011 16:47:18 -0400

I'm not advocating for such a group. My first proposal would be for a WG 
that takes on responsibility for all the documents as work items, but 
coordinates with other WGs as necessary. The alterantive would be some 
sort of cross-Area Multicast Directorate to do the coordination, with 
the work items going to specific WGs according to their content.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Jun 2011 15:29:48 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Taylor
> Sent: Monday, June 27, 2011 1:14 PM
> To: Multicast Transition
> Subject: [multrans] Issues charts for presentation at the BoF
> 

slide 3:  RFC5135 was done in BEHAVE, so multicast is not new nor out
of scope of BEHAVE.  This slide implies otherwise. 

slide 4: I like that slide a lot

slide 5: in addition to listing standard protocols (SIP, HTML, SAP),
it should also be described that proprietary electronic program
guides also provide 'channel' information.  (at least, that is my
understanding.)

slide 6: for IPv4, does "IGMP" encompass IGMPv1, v2, and v3?  That is,
the list of interworking issues may be greater than described.

slide 10:  regarding the point: "Hence operating source in dual stack 
mode is undesirable", can you make a diagram showing examples of the 
desired architecture and the undesired architecture?

-d

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 27 Jun 2011 22:59:58 +0000

The undesirable scenario is building two MDT for the same content. The desirable scenario could be building a MDT with IPvX and translate to IPvY at the edge.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 27 Jun 2011 23:03:07 +0000

I agree multicast isn't new. The objective of the BoF is to see we have people thinking this is in fact an important problem and willing to work on it.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Jun 2011 16:21:24 -0700

> From: Lee, Yiu [mailto:[email-masked]]
> Sent: Monday, June 27, 2011 4:00 PM
> To: Dan Wing
> Cc: Tom Taylor; Multicast Transition
> Subject: Re: [multrans] Issues charts for presentation at the BoF
> 
> The undesirable scenario is building two MDT for the same content. The
> desirable scenario could be building a MDT with IPvX and translate to
> IPvY at the edge.

A picture is worth 1000 words.

-d

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jun 2011 21:27:29 -0400

I'm happy to do the charts. These slides were actually distilled from a 
more extensive presentation where the charts were available. I actually 
had in mind doing the charts as backup slides, in the interest of 
minimizing presentation time unless people had questions. I suppose 
"haste makes waste".

On 27/06/2011 7:21 PM, Dan Wing wrote:
>> On Jun 27, 2011, at 18:29, "Dan Wing"<[email-masked]>  wrote:
>>

---

From: Jacni Qin <[email-masked]>
Date: Tue, 28 Jun 2011 09:27:39 +0800

Dan,

> the list of interworking issues may be greater than described.

Jacni>: Yes, for example, one case of the interworking function IGMPv2 -
MLDv2

Cheers,
Jacni

---

From: Jacni Qin <[email-masked]>
Date: Tue, 28 Jun 2011 10:45:21 +0800

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.

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.

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

Cheers,
Jacni

On Tue, Jun 28, 2011 at 4:13 AM, Tom Taylor <[email-masked]> 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
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Jun 2011 08:53:52 -0400

Thank you for your comments. Responses below.

> 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.
> Mesh is a different use case, the mesh approaches do not apply to DS-Lite or

[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.
> 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<[email-masked]>  wrote:
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Jun 2011 09:57:55 -0700

> Sent: Tuesday, June 28, 2011 5:54 AM
> To: Jacni Qin
> Cc: Multicast Transition

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

---

From: Tina Tsou <[email-masked]>
Date: Tue, 28 Jun 2011 10:13:12 -0700

We keep our promises with one another – no matter what!

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

[Tina: So what changes do you want to see from Page 8?]

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Jun 2011 10:31:56 -0700

> From: Tina Tsou [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2011 10:13 AM
> To: 'Dan Wing'; 'Tom Taylor'; 'Jacni Qin'
> Subject: RE: [multrans] Issues charts for presentation at the BoF
> 
> 
> 
> 
> Behalf Of Dan Wing

how about:

OLD:

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

> > > Mesh is a different use case, the mesh approaches do not apply to
> DS-
> > Lite or
> > > 6rd cases either.
> >
> > > http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-
> 01#page-
> > 8
> > >

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Jun 2011 14:26:19 -0400

OK, thanks.

> (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, an…
...

---

From: Tina Tsou <[email-masked]>
Date: Tue, 28 Jun 2011 15:46:01 -0700

Jacni,

We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jacni Qin
Sent: Monday, June 27, 2011 6:28 PM
To: Dan Wing
Cc: Multicast Transition
Subject: Re: [multrans] Issues charts for presentation at the BoF
 
Dan,

Jacni>: Yes, for example, one case of the interworking function IGMPv2 -
MLDv2
[Tina: what's your proposed text here?]

Cheers,
Jacni

-d

---

From: Jacni Qin <[email-masked]>
Date: Wed, 29 Jun 2011 10:42:09 +0800

hi Tom,

> draft-xu-softwire-mesh-multicast-01.
Jacni>: How about this for Page 9 ?

Encapsulation

Issue: For different use cases (e.g. DS-Lite, 6rd or Mesh), unicast
based encapsulation does not apply to multicast.

Possible to form corresponding MDT within the underneath network by
implementing interworking function of signalling.
● to guarantee the efficiency of multicast traffic forwarding.

>> http://tools.ietf.org/html/**draft-jaclee-behave-v4v6-**
>> mcast-ps-01#page-8<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.
>
> Jacni>: Yes, the IPv6 sources have lower priority, better to state that.

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

Jacni>: Ok, I can wait for your updates.

Cheers,
Jacni

>>> topic
>>> ______________________________**_________________
>>> multrans mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/multrans<https://www.ietf.org/mailman/listinfo/multrans>
>>>
>>>
>>>
>>

---

From: Jacni Qin <[email-masked]>
Date: Wed, 29 Jun 2011 10:45:40 +0800

hi,

Also the ASM-SSM issue, but to keep the slides simple, I don't want to add
more text about this point.
More information can be found in the PS, and we can disscuss that during the
presentation if there is any interest.

Cheers,
Jacni

On Wed, Jun 29, 2011 at 6:46 AM, Tina Tsou <[email-masked]> wrote:

> Jacni,****
>
> ** **
>
> ** **
>
> We keep our promises with one another – no matter what!****
>
> ** **
>
> Best Regards,****
>
> Tina TSOU****
>
> http://tinatsou.weebly.com/contact.html****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Jacni Qin
> *Sent:* Monday, June 27, 2011 6:28 PM
> *To:* Dan Wing
> *Cc:* Multicast Transition
> *Subject:* Re: [multrans] Issues charts for presentation at the BoF****
>
> ** **
>
> Dan,****
>
> On Tue, Jun 28, 2011 at 6:29 AM, Dan Wing <[email-masked]> wrote:****
>
>
>
> the list of interworking issues may be greater than described.****
>
>
> [Tina: what’s your proposed text here?]****
>
>
> Cheers,
> Jacni****
>
>
> -d****
> https://www.ietf.org/mailman/listinfo/multrans****
>
> ** **
>

---

From: Tina Tsou <[email-masked]>
Date: Tue, 28 Jun 2011 19:53:56 -0700

Hi Jacni,
As the co-author of the problem statement I-D, I understand your point.
Proposing alternative text will help people understanding you better. If
there is no alternative text, we will know it is just side comment, no
change is needed for the time being.
 
There are other presentations for the BoF. Hopefully they will also come to
the mailing list soon.

Best Regards,
Tina TSOU
 
From: Jacni Qin [mailto:[email-masked]] 
Sent: Tuesday, June 28, 2011 7:46 PM
To: Tina Tsou
Cc: Dan Wing; Multicast Transition
Subject: Re: [multrans] Issues charts for presentation at the BoF
 
hi,

Cheers,
Jacni 

Best Regards,
Tina TSOU

Dan,

Cheers,
Jacni

-d

---

From: Jacni Qin <[email-masked]>
Date: Wed, 29 Jun 2011 11:08:42 +0800

Whatever

On Wed, Jun 29, 2011 at 10:53 AM, Tina Tsou <[email-masked]> wrote:

> Hi Jacni,****
> change is needed for the time being.****
>
> ** **
>
> There are other presentations for the BoF. Hopefully they will also come
> to the mailing list soon.****
>
> ** **
>
> ** **
>
> *From:* Jacni Qin [mailto:[email-masked]]
> *Sent:* Tuesday, June 28, 2011 7:46 PM
> *To:* Tina Tsou
> *Cc:* Dan Wing; Multicast Transition
>
> More information can be found in the PS, and we can disscuss that during
> the presentation if there is any interest.
>
>
> Cheers,
> Jacni ****
>
> On Wed, Jun 29, 2011 at 6:46 AM, Tina Tsou <[email-masked]> wrote:****
>
> Jacni,****
>
>  ****
>
>  ****
>
>  ****
>  ****
>  ****
> MLDv2****
>  ****

---

From: Tom Taylor <[email-masked]>
Date: Wed, 29 Jun 2011 15:05:13 -0400

Thanks for the suggestion, but interworking is already dealt with on 
slide 6. I think chart 9 deals with a separate issue.

On 28/06/2011 10:42 PM, Jacni Qin wrote:
> hi Tom,
>
> On Tue, Jun 28, 2011 at 8:53 PM, Tom Taylor<[email-masked]>  wrote:
>
>>
>>> Page 9:

---

From: Jacni Qin <[email-masked]>
Date: Thu, 30 Jun 2011 14:49:31 +0800

Re-,

What I proposed is about how to deal with the encapsulation case, the key
point is to guarantee the efficiency of multicast forwarding.

Cheers,
Jacni

On Thu, Jun 30, 2011 at 3:05 AM, Tom Taylor <[email-masked]> wrote:

> Thanks for the suggestion, but interworking is already dealt with on slide
> 6. I think chart 9 deals with a separate issue.
>
>
>>>> DS-Lite
>>>> or
>>> draft-xu-softwire-mesh-**multicast-01.
>>>
>>>
>>>> http://tools.ietf.org/html/****draft-jaclee-behave-v4v6-**<http://tools.ietf.org/html/**draft-jaclee-behave-v4v6-**>
>>>> mcast-ps-01#page-8<http://**tools.ietf.org/html/draft-**
>>>> jaclee-behave-v4v6-mcast-ps-**01#page-8<http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-01#page-8>
>>>> >
>>>>
>>>>
>>>> network
>>> pointing
>>>>> ______________________________****_________________
>>>>> multrans mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/****listinfo/multrans<https://www.ietf.org/mailman/**listinfo/multrans>
>>>>> <https://**www.ietf.org/mailman/listinfo/**multrans<https://www.ietf.org/mailman/listinfo/multrans>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>