Subject: [MBONED] AMT Sourcing

From: Greg Shepherd <[email-masked]>
Date: Thu, 25 Mar 2010 10:25:35 -0700

Tom and I had a good conversation right after the meeting which
clarified some of the disconnect in the source discussion, namely over
what constitutes a Gateway and a Relay.

It was my assumption that a Gateway is a device that initiates a
connection to the multicast infrastructure on behalf of either senders
or receivers.

Tom's definition was that a Gateway is a device that initiates joins
to the multicast infrastructure.

Our epiphany was when he offered that I was desiring a bidirectional
AMT tunnel. I had always assumed a Gateway innitiated tunnel is
bidirectional.

I don't believe there's anything solid in the draft that specifies one
or the other, but just that the current solution seems to word things
with a particular assumption.

So, as Tom articulated, yes, I would like to see a Gateway initiated
tunnel to allow but sourcing and receiving, AND to do so using a
single tunnel to maintain the efficiencies of mcast.

The draft erroneously points to RFC3503 as the solution for Tunnel
Brokers but that is a v6-only draft. Dave suggested that we may need
to author a v4 version of this but I feel this is way out of scope for
AMT. We already have a tunnel mechanism and it already handles
automatic discovery of the u/m boundaries. All we need is an hooks in
AMT to allow a sourcing GW to request sourcing and/or an address to
use for all sourced mcast packets, and a means to notify the sourcing
GW that there is OIF state for the S,G and to begin sending packets.

Before I go into any details of any solution I'd like to hear some
feedback on the above discussion to ensure we're all talking the same
language now. ;-)

Thanks!,
Greg

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 29 Mar 2010 14:24:16 -0700

Greg,

During the meeting, I had a bit of trouble following along with what 
exactly was the problem with the sourcing solution in the spec and why it 
was broken.  I suspect I wasn't alone.  Do you have a brief description, 
or even a picture, that would explain what's broken?

IMO, sourcing behind a GW is nice to have (as is the philosophical 
question of bidirectionality), but isn't worth holding up the spec.  I 
don't think any of the implementations out there support sourcing, and not 
sure if any plan to anytime soon.  If the solution specified in the spec 
is broken, it should definitely be fixed.  Or we could just punt it out of 
the spec and leave it up to another draft in the future to figure it out.  
Maybe if you could elaborate on what "hooks" you think should be left in 
and how it's different than what's in there now.

So I'd be more interested in the practical elements of the problem and 
solution before reaching a conclusion on bidirectionality.

-Lenny

On Thu, 25 Mar 2010, Greg Shepherd wrote:

-) Tom and I had a good conversation right after the meeting which
-) clarified some of the disconnect in the source discussion, namely over
-) what constitutes a Gateway and a Relay.
-) 
-) It was my assumption that a Gateway is a device that initiates a
-) connection to the multicast infrastructure on behalf of either senders
-) or receivers.
-) 
-) Tom's definition was that a Gateway is a device that initiates joins
-) to the multicast infrastructure.
-) 
-) Our epiphany was when he offered that I was desiring a bidirectional
-) AMT tunnel. I had always assumed a Gateway innitiated tunnel is
-) bidirectional.
-) 
-) I don't believe there's anything solid in the draft that specifies one
-) or the other, but just that the current solution seems to word things
-) with a particular assumption.
-) 
-) So, as Tom articulated, yes, I would like to see a Gateway initiated
-) tunnel to allow but sourcing and receiving, AND to do so using a
-) single tunnel to maintain the efficiencies of mcast.
-) 
-) The draft erroneously points to RFC3503 as the solution for Tunnel
-) Brokers but that is a v6-only draft. Dave suggested that we may need
-) to author a v4 version of this but I feel this is way out of scope for
-) AMT. We already have a tunnel mechanism and it already handles
-) automatic discovery of the u/m boundaries. All we need is an hooks in
-) AMT to allow a sourcing GW to request sourcing and/or an address to
-) use for all sourced mcast packets, and a means to notify the sourcing
-) GW that there is OIF state for the S,G and to begin sending packets.
-) 
-) Before I go into any details of any solution I'd like to hear some
-) feedback on the above discussion to ensure we're all talking the same
-) language now. ;-)
-) 
-) Thanks!,
-) Greg
-) _______________________________________________
-) MBONED mailing list
-) [email-masked]
-) https://www.ietf.org/mailman/listinfo/mboned
-)

---

From: Dave Thaler <[email-masked]>
Date: Tue, 30 Mar 2010 16:39:35 +0000

In the existing spec, a Gateway is a device that initiates joins
to the multicast infrastructure on behalf of receivers, and 
can also act as a sender itself (it can't do so on behalf of other
senders behind it).

Allowing senders behind it to source traffic would be outside the
scope of AMT as Greg mentions, and would be in scope for a separate
IPv4 Tunnel Broker document (or AMT extension if you prefer to call
it that).

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Greg Shepherd
> Sent: Thursday, March 25, 2010 10:26 AM
> To: [email-masked]
> Subject: [MBONED] AMT Sourcing
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 30 Mar 2010 10:32:54 -0700

> can also act as a sender itself (it can't do so on behalf of other

Thanks.

The current address allocation mechanism described in the current
draft, section 7.2 potentially requires multiple tunnels (section
7.5-7.7) even when there is native mcast connectivity between relays.
This is what I'm trying to address.

If we remove the address allocation mechanism from the draft but just
not that the relay which the sourcing gateway is connected - IF it
supports sourcing - will need to allocate a globally unique unicast
address, reachable through the relay, to be assigned to the sourcing
gateway's pseudo-interface. In this way mcast joins will follow any
native topology to the relay providing sourcing services to the
connected gateway.

I don't feel we need to specify how the address is allocated but we
may want a message to request an address, for which a null-response
would indicate the relay does not support sourcing. Additionally, we
do not want the sourcing gateway to send sourced mcast packets on its
pseudo-interface unless the connected relay has populated OIF state
for the gateway's S,G. This may also require a clear-to-send message
from the relay to the sourcing gateway, or perhaps just a membership
report would do.

Is this making any more sense? I can try to provide pictures later
this week if necessary.

> IPv4 Tunnel Broker document (or AMT extension if you prefer to call

I have no interest in pursuing this.

Greg