Subject: mboned: AMT spec and suggestions

From: Tom Pusateri <[email-masked]>
Date: Thu, 13 May 2004 13:48:26 -0700

It seems that with some minor changes, AMT could be used to connect
two multicast clouds together across a non-multicast cloud. Currently,
the description of a gateway allows for the gateway to act as an
IGMP proxy to forward locally attached group membership reports
from directly connected subnets.

If a router at the edge of a PIM cloud receives a PIM join but there
is no PIM neighbor for the upstream router based on the MRIB, then
the PIM join just gets dropped.

If this edge router were also an AMT gateway, it could translate the
pim join into an AMT join. This also means that not all RPs within
a domain must also be gateways as the current spec says.

For bi-directional connectivity, the same edge router would act
as both a gateway and a relay.

I would also like to see a routing domain identifier in the AMT messages
for the VPN case.

Would it make sense for me to send changes from the -02 spec or
is there a newer version being passed around with the gateway/relay
NONCE handshake changes in it that I could start from?

Thanks,
Tom
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: [email-masked]
Date: Thu, 13 May 2004 17:10:24 -0700 (PDT)

Thanks Tom!! More inside..

> I would also like to see a routing domain identifier in the AMT messages

Agreed!! But I think the current defined mechanism of an anycast prefix 
may not work for the above two cases, and I'm not totally confident it 
would support more than just a novilty deployment of AMT. 

We need a solution which is automatic, works independent of the boxes in 
the path between the reciever and the mcast-edge, AND I would hope is 
easily deployable to increase the mcast radius incrementally.

Greg