Subject: [MBONED] Multicast Transition Overview

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 Dec 2011 16:13:16 -0500

Folks,

The following are a few questions that we should probably address in the multicast transition overview. 

1) In addition to translation, will the AF function be capable of encapsulation?

2) Will the transition mechanism support SSM, ASM or both?

3) Will unicast source addresses traverse the AF boundary?

4) If the unicast source address will traverse the AF boundary, will there be any addressing constraints place upon IPv6 sources (e.g., it must be possible to map the IPv6 address to an IPv4 address).

It might be helpful to discuss these issues on the list before publishing the first version of the overview document. 

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: Tina TSOU <[email-masked]>
Date: Wed, 28 Dec 2011 18:06:11 +0000

Tina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, December 27, 2011 1:13 PM
To: MBONED WG
Subject: [MBONED] Multicast Transition Overview

Folks,

1) In addition to translation, will the AF function be capable of encapsulation?
With respect to content, depending on deployment, the AF2 either encapsulates or translates the headers of incoming packets of multicast content before forwarding them toward the receiver.

Both.

Possibly.

I think so.

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 28 Dec 2011 15:16:40 -0500

Hi Tina,

Lots of comments inline.....

                  Ron

From: Tina TSOU [mailto:[email-masked]]
Sent: Wednesday, December 28, 2011 1:06 PM
To: Ronald Bonica; MBONED WG
Subject: RE: Multicast Transition Overview

Tina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, December 27, 2011 1:13 PM
To: MBONED WG
Subject: [MBONED] Multicast Transition Overview

Folks,

Ø    Why?

Ø    In the case where the intermediate network is not multicast aware, the answer is obvious. However, in that case, adequate multicast encapsulation techniques exist. There is no need for the AF to be involved.

Ø    In the case where the intermediate network is multicast aware, encapsulation adds complexity and overhead. What is the benefit beyond that of translation on the way in and again on the way out?

Ø

Ø    Do IPTV providers use ASM today? If so, do they do it because multiple sources may contribute to a single multicast group? Or do they use ASM because the receiver doesn't know the unicast address of the single source that originates a multicast group?

Ø    Having thought about it for two more seconds, the answer is "yes". Unicast source addresses may traverse the AF boundary on the control plane. But they *definitely will* traverse the AF boundary on the data plane. So, Question #4 applies.

Ø    I agree. That means that even if you are sourcing multicast traffic from the IPv6 side of the fence, you must source it from an IPv4-mappable IPv6 unicast address. We need to catch this detail in the Overview document.

Ø         Ron

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf<http://www.bonica.org/ron/ronbonica.vcf>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 28 Dec 2011 23:37:49 +0000

Tina

From: Ronald Bonica [mailto:[email-masked]]
Sent: Wednesday, December 28, 2011 12:17 PM
To: Tina TSOU; MBONED WG
Subject: RE: Multicast Transition Overview

Hi Tina,

                  Ron

Tina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, December 27, 2011 1:13 PM
To: MBONED WG
Subject: [MBONED] Multicast Transition Overview

Folks,

Ø    Why?

Ø  The authors of [draft-ietf-softwire-dslite-multicast] chose to use encapsulation because, it reduces the workload of the mB4 (their AF1) and also ensures that any requirement not to modify the payload for IPR reasons is met. They may also have been inspired by the fact that they were fitting their work into an encapsulation-oriented unicast environment. I and my colleagues note the extra administrative effort required to coordinate adaptation function instances (the AF1 and AF2 in the DS-Lite case) and the awkwardness of the evolution toward pure IPv6 when encapsulation is used.

Ø

Ø         Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 29 Dec 2011 12:02:14 -0500

It appears that the transition mechanism will have to support ASM because many IPTV receivers don't support IGMPv3. However, it will also need to support SSM because:

-          SSM is more simpler, cheaper and more efficient

-          Some IPTV receivers do support IGMPv3

-          Some IPTV providers translate ASM to SSM at the first hop router through static mapping

Thanks to Mike McBride for bringing this question to the NANOG list to solicit informed operator input.

                                                                              Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 29 Dec 2011 12:28:11 -0500

Tina,

I'm afraid that you haven't answered the question. On the one hand, you agree that the coordination of encapsulation endpoints adds operational complexity. However, you don't say what benefit, beyond that which is derived from translation, can be derived from encapsulation.

You say that  draft-ietf-softwire-dslite-multicast  chose encapsulation because it reduces the workload on mB4. Is reducing the workload on the AF a goal in the current effort? And even if it is, are you sure that encapsulation is less resource intensive than translation.

I can't parse the IPR argument at all. If it's OK for the AF to modify headers sometime, it should be OK for the AF to modify those same headers all of the time.

                                                                                                                                           Ron

Ø   Why?

Ø

---

From: Tina TSOU <[email-masked]>
Date: Thu, 29 Dec 2011 19:45:10 +0000

Ron,
I gave you all the information I had available. I myself am not in a position to defend encapsulation. Note that mB4 workload may matter because we are talking about customer equipment in the DS-Lite scenario, and putting more horsepower into the customer equipment could make it too expensive.

Cheers from New York,
Sent from my iPad

On Dec 29, 2011, at 12:28 PM, "Ronald Bonica" <[email-masked]<mailto:[email-masked]>> wrote:

Tina,

I’m afraid that you haven’t answered the question. On the one hand, you agree that the coordination of encapsulation endpoints adds operational complexity. However, you don’t say what benefit, beyond that which is derived from translation, can be derived from encapsulation.

I can’t parse the IPR argument at all. If it’s OK for the AF to modify headers sometime, it should be OK for the AF to modify those same headers all of the time.

                                                                                                                                           Ron

Ø   Why?

Ø

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 29 Dec 2011 19:26:53 -1000 (HST)

On Thu, 29 Dec 2011, Ronald Bonica wrote:

> It appears that the transition mechanism will have to support ASM 
> because many IPTV receivers don't support IGMPv3. However, it will also 
> need to support SSM because:

And global scalability of ASM isn't really supported in IPv6.  IPv6 
multicast uses Embedded RP.

Antonio Querubin
e-mail:  [email-masked]
xmpp:  [email-masked]

---

From: Simon Leinen <[email-masked]>
Date: Sat, 31 Dec 2011 12:08:39 +0100

Antonio Querubin writes:
>> because many IPTV receivers don't support IGMPv3. However, it will
>> also need to support SSM because:

> multicast uses Embedded RP.

Did you mean to say "[...] isn't really supported in IPv4.  IPv6 [...]"?
To me, Embedded RP seems more scalable than what we have in IPv4 (MSDP).
-- 
Simon.