Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case draft

From: Maglione Roberta <[email-masked]>
Date: Tue, 1 Nov 2011 18:20:47 +0100

Hello Tina,
   in this version of the document it seems to be missing the 6-4-6 Network Scenario where both the receivers and
   the source are IPv6 capable, but the IPv6 connectivity among them is
   provided over an IPv4-Only Network running Multiprotocol Label
   Switching (MPLS).
We discussed this scenario on list some weeks ago, I was wondering why you did not include it in the document.

Best Regards
Roberta
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Tina TSOU [[email-masked]]
Sent: Monday, October 31, 2011 8:49 PM
To: [email-masked]
Subject: [multrans] Update of Multrans Problem Statement and Use Case draft

Dear all,
Version -03 of the Multrans Problem Statement and Use Case draft has
been submitted. By agreement amongst the authors, the diagrams and
updated descriptions from draft-tsou-multrans-use-cases-00 have been
absorbed into the problem statement and use case draft.

https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now
presents the following use cases, all within the agreed context of IPTV:

1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4)

2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4
Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network
(6-4-6-4)

3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6)

4. IPv6 Receiver and IPv4 Source (6-4)

5. IPv4 Receiver and IPv6 Source (4-6)

The diagrams and accompanying text show a potential solution to the
problem of differing IP versions through the use of nodes embodying
"adaptation functions". The Multrans BoF was negotiated on the basis of
solutions where these adaptation functions consisted of application
layer gateways (ALGs). Comments on this assumption and how it should
work are invited.

B. R.
Tina
+1-408-859-4996
_______________________________________________
multrans mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multrans

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Nov 2011 17:32:19 +0000

Hi Roberta,

We describe 6-4-6 in Section 3.3. This is very generic scenario and does
not mention MPLS in the IPv4 networks. IMHO, MPLS would create an
abstraction which makes the underneath network irrelevant. Do you suggest
we need to describe 6-MPLS-6?

B.R.,
Yiu

On 11/1/11 1:20 PM, "Maglione Roberta" <[email-masked]>
wrote:

>Hello Tina,
>   in this version of the document it seems to be missing the 6-4-6
>Network Scenario where both the receivers and
>Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
>persone indicate. La diffusione, copia o qualsiasi altra azione derivante
>dalla conoscenza di queste informazioni sono rigorosamente vietate.
>Qualora abbiate ricevuto questo documento per errore siete cortesemente
>pregati di darne immediata comunicazione al mittente e di provvedere alla
>sua distruzione, Grazie.
>
>This e-mail and any attachments is confidential and may contain
>privileged information intended for the addressee(s) only. Dissemination,
>copying, printing or use by anybody else is unauthorised. If you are not
>the intended recipient, please delete this message and any attachments
>and advise the sender by return e-mail, Thanks.
>

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 1 Nov 2011 18:50:02 +0100

Hi Yiu,
 I saw you mentioned 6-4-6 in Section 3.3 in a generic way, however the reason why I believe IPv4 network with IP/MPLS is a particular case is because for unicast there is a specific solution (6PE) for the 6-4-6 with MPLS in the IPv4 network. For multicast at the moment there is no equivalent for 6PE.

Please see the text below, I proposed some time ago on the list for this scenario:

  RFC 4798 tackles the unicast angle of the problem and it explains how
   to interconnect IPv6 islands over a Multiprotocol Label Switching
   (MPLS)-enabled IPv4 cloud by using Multiprotocol Border Gateway
   Protocol (MP-BGP) to exchange the IPv6 reachability information
   transparently.  The devices implementing this mechanism are called
   IPv6 Provider Edge routers (6PE).  The 6PE technique is currently
   deployed for unicast traffic in several Service Provider's networks.

   A similar approach would be useful for multicast services too, in
   order to allow the Service Providers to start offering IPv6 multicast
   contents (from its own multicast sources or provided by external
   Content Providers) to new IPv6 customers.  This mechanism would allow
   the Service Providers to replicate for multicast contents, the same
   architectural model currently deployed for unicast traffic with 6PE
   method.  In addition as this model does not require any translation
   or interworking function it is expected it would be able to preserve
   the service quality and the integrity of contents.

Thanks
Best regards,
Roberta

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]]
Sent: martedì 1 novembre 2011 18.32
To: Maglione Roberta; Tina TSOU; [email-masked]
Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case draft

Hi Roberta,

B.R.,
Yiu

---

From: Tina TSOU <[email-masked]>
Date: Tue, 01 Nov 2011 20:41:59 +0000

Ciao Roberta,
Sorry, it was oversight.

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

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2011 10:50 AM
To: 'Lee, Yiu'; Tina TSOU; [email-masked]
Subject: RE: [multrans] Update of Multrans Problem Statement and Use Case draft

Hi Yiu,

Thanks
Best regards,
Roberta

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]]
Sent: martedì 1 novembre 2011 18.32
To: Maglione Roberta; Tina TSOU; [email-masked]
Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case draft

Hi Roberta,

B.R.,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 2 Nov 2011 17:49:05 +0000

Hi Roberta,

Is it the similar problem the mesh software trying to solve (multicast  
over tunnel)?

Yiu

On Nov 1, 2011, at 1:50 PM, "Maglione Roberta" <[email-masked] 

> Hi Yiu,
> I saw you mentioned 6-4-6 in Section 3.3 in a generic way, however  
> the reason why I believe IPv4 network with IP/MPLS is a particular  
> case is because for unicast there is a specific solution (6PE) for  
> the 6-4-6 with MPLS in the IPv4 network. For multicast at the moment  
> there is no equivalent for 6PE.
>
> On 11/1/11 1:20 PM, "Maglione Roberta" <[email-masked] 
> >
> wrote:
>
>> Hello Tina,
>> We discussed this scenario on list some weeks ago, I was wondering  
>> why
>> you did not include it in the document.
>>
>> Best Regards
>> Roberta
>> From: [email-masked] [[email-masked]] On  
>> Behalf Of
>> Tina TSOU [[email-masked]]
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente  
> alle persone indicate. La diffusione, copia o qualsiasi altra azione  
> derivante dalla conoscenza di queste informazioni sono rigorosamente  
> vietate. Qualora abbiate ricevuto questo documento per errore siete  
> cortesemente pregati di darne immediata comunicazione al mittente e  
> di provvedere alla sua distruzione, Grazie.
>
> privileged information intended for the addressee(s) only.  
> Dissemination, copying, printing or use by anybody else is  
> unauthorised. If you are not the intended recipient, please delete  
> this message and any attachments and advise the sender by return e- 
> mail, Thanks.
>