Subject: mboned: Re:WGLC for draft-ietf-mboned-auto-multicast-04.txt

From: Venketesan <[email-masked]>
Date: Sun, 10 Apr 2005 20:25:49 -0600

Hi,

I am not clear about the following points about AMT:
1. I agree with john on the point that AMT may be having restrictions 
on the usage of the multicast addresses in SSM mode (Also AMT does not 
support sending to ASM groups). 

2. Abstraction of a "source" for SSM is an AMT gateway. It seems in a 
domain, even if there are more than one source they are treated as a 
single S in <S,G> by receivers external to the domain i.e. all the 
sources within an AMT gateway are represented by the same AMT GW.

Consider an example, say the unicast address of the AMT gateway is 
a.b.c.d and the anycast address prefix allotted to it is x.y/16, then 
the usable SSM address range by the hosts within the AMT gateway's 
domain is 232.c.d/24. The S in <S,G> is already fixed as x.y.a.b, 
hence the address space is <x.y.a.b, 232.c.d.(0-255)> with a size of 
2*8.     

3.How does AMT support receiving ASM traffic? it is said that the 
gateways announce the groups they are interested in
to a relay and the relay maintains a list of gateway_ips-groups. So it 
sends multicast traffic it "receives" to all these
gateways downstream. Now how does the AMT relay receive the traffic? 
does it forward/flood some kind of a join to other 
relay? Is DVMRP running between relays in the MBONE and is it scalable?

4. Does AMT in ASM mode force all traffic to go through the relays in 
the MBONE thus bypassing/overiding the connectivity 
between the RPs of the domains formed by MSDP/MBGP. I mean how does 
AMT incorporate MSDP and MBGP. My understanding is this is the 
reason "AMT does not support sending to non-SSM groups" as stated in 
the draft.

5.This is a question about the progressive deplotyment capability of 
AMT
Suppose an initial connectivity is as shown below
------------
AMT gateway |---------------
------------		    |	
			------------
			|AMT relay  |--------MBONE
			------------	
------------		    |	
AMT gateway |----------------
------------	
subsequently another AMT gateway is added higher in the domain 
(towards MBONE) of the existing gateways as shown below:

------------
AMT gateway |---------------
------------		    |---------------------	
			------------	        --|---------
		        |AMT gateway |-------- | AMT Relay |----- MBONE
			------------	        ----------- 
------------		    |---------------------|	
AMT gateway |----------------
------------	
Now although a new AMT gateway has been added the nearest relay 
remains the same for the
existing gateways. How to ensure that all the traffic is sent from the 
relay 
the new gateway that duplicates it to the old gateways, instead of 
sending two copies to the existing gateways.
meaning u no more need the connectivity between the original gateways 
and the relay

regards,
venkat

----- Original Message -----
From: John Zwiebel <[email-masked]>
Date: Sunday, April 10, 2005 10:04 am
Subject: Re: mboned: WGLC for draft-ietf-mboned-auto-multicast-04.txt

> 
> On Apr 8, 2005, at 9:05 AM, David Meyer wrote:
> 
> >
> > 	This Last Call will end on 22 Apr 2005 at 1400 PDT (UTC/GMT-7).
> >
> > 	Thanks,
> >
> 
> I went through it for the first time.
> There were a couple of places that I got lost in the context switch
> of which system is the relay and which is the gateway -- not that
> I didn't understand where they were in the network, but there was
> confusion about which system was doing what.
> 
> I guess my main concern is the gateway definition doesn't explain
> how to handle PIM joins received by the gateway from a multicast
> island that the gateway is suppose to be serving.  And the 
restriction
> on the source/group address that a gateway can use seems to make
> it impossible for a source within a multicast island to send SSM,
> perhaps I missed the sentence that says, "only a gateway can source
> multicast traffic to other gateways and/or relays to be forwarded to
> the rest of the multicast enabled network."?
> 
> FWIW: perhaps its because I've been around forever, but the MBONE is,
> IMHO, dead.  The MBONE used DVMRP tunnels to extend multicast as an
> overlayed logical network across the internet.  Now that most 
> providersdo multicast natively, there is no need for the MBONE.  
> Using a term
> that has a certain meaning in a new context happens all the time,
> but there are some terms (IMHO, MBONE being one) that have been
> so strongly defined that trying to morph them into something else is
> a mistake.  Of course, I should be willing to provide an alternative,
> but I don't have one.
> 
> For example, when IPv6 is deployed almost everywhere, are we still
> going to connect to the 6-bone?  and what is the internet now?  
> the 
> 4-bone?
> If we're going to communicate with one another, we need to be
> explicit in our definitions and terms.
> 
> Following is other notes that includes comments on missing commas 
etc.
> Mostly though its a request for some clarity on certain portions 
where
> I found myself thinking of at least two ways to interpret what I was
> reading.
> 
> Intro:
>    2. Allowing isolated sites/hosts to transmit the SSM flavor of
>       multicast.
> > after reading this entire thing, I see how an isolated host 
> that is
> also configured as an AMT gateway can transmit SSM, but I do not see
> how a host within an isolated site can transmit SSM.
> 
> Page 5: extra paren
>  This requires the relay to keep state for each
>    gateway which has joined a particular group or (source, group) 
> pair).
> 
> Page 5:
>  Since an AMT gateway may be a host,
>    and hosts typically do not implement routing protocols, 
> gateways will
>    use IGMP/MLD as described in Section 5 below.
> 
> John says: I think that there are plenty of FreeBSD/Linux systems 
> available to
> 	do PIM.  Is this draft primarily to be implemented on a host 
(eg a
> 	Windows PC)
> 
> Para 4.1.1: what happens if a relay has too many tunnels?  How 
> does the
> 	AMT gateway find a new relay?
> 
> 
> 5.5.  AMT Membership Update
> 
>    "An AMT Membership Update is sent from the originator to the
>    respondent containing the original IGMP/MLD Membership/Listener
>    Report or Leave/Done received over the AMT pseudo-interface.  It
>    echoes the Response MAC received in the AMT Membership Query 
> so the
>    respondent can verify return routability to the originator."
> 
> John says: the IGMP/MLD report... isn't this -generated- by the 
> AMT 
> Gateway or Relay?
> 	And isn't it really a report sent because the Gateway/Relay 
wants to
> 	receive multicast traffic and so should be equivalent to 
sending 
> a PIM
> 	join (on a router) or sending a IGMP/MLD report (from a 
host)?  
> Are you
> 	suggesting that there are separate entities on the gateway?  
The
> 	switch from talking about the gateway to talking about the 
interface
> 	on the gateway was totally missed.
> 
> 
> Para 6.4: I'd like some kind of a note that says something like
> 	"as opposed to forward 	multicast traffic for a source inside
> 	the domain it serves".  I'm getting confused between a host 
that has
> 	no native multicast support and acts as its own AMT gateway and
> 	a router that is providing AMT gateway service for a multicast
> 	domain.
> 
> Para 6.5: "ditto"  This only makes sense to me if this is a host 
> acting	as its own gateway.  Explicitly stating this fact will 
> clear up
> 	confusion.  And explicitly stating that "e" is any value the 
host
> 	wants to append will also help.  (Since if I'm not guessing 
right...)
> 
> 
> 6.6.  Receiving IGMPv3/MLDv2 Reports at the Gateway
> 
>    When an AMT Request is received by the gateway, it follows the 
> same    3-way handshake procedure a relay would follow if it 
> received the AMT
>    Request.
> 
> John says: HUH?  Let's just say I read this 3 times, then 
> cut-and-pasted it before
> 	I figured out what you meant.  Put the period before "follow" 
and 
> delete
> 	the rest.
> 
> inside of 6.6 it says:
>    If S is not the AMT Gateway Anycast Address, the packet is 
> dropped.    If G does not contain the low bits of the global 
> unicast address (as
>    described above), the packet is also dropped.
> 
> So now I'm really, really confused because the beginning of this 
draft
> suggested that we are dealing with a Gateway that could support an
> entire multicast island (domain).  Suddenly it appears that we have
> a bunch of restrictions on the group addresses that can be used
> for sources inside of that island and I totally missed that there 
> wouldhave to be some kind of NAT performed (or address 
> translation) by
> the AMT gateway to achieve this support.  If it was there, it 
> needs to
> be emphasized.
> 
> "7.3...
>  When data arrives for that group, "
> 
> From where?  One assumes that it comes in on any interface other 
> than 
> the
> AMT interface, but its helpful to be explicit.
> 
> Para 7.4: again, how do you deal with the multicast island?
> 
> 
> 8.  IANA Considerations
> 
>    The IANA should allocate a prefix dedicated to the public AMT 
> Relays    to the native
> 
> > It isn't -just- the relays.  Or is it...
> 
>    Furthermore, to support sourcing SSM traffic from AMT 
> gateways, the
>    IANA should allocate a subnet prefix dedicated to the AMT link.
> 
> John says: Let's see, I understood this was suppose to emulate a 
> NBMA 
> network?
>     ie, this is a single subnet on which both gateways and relays 
> reside.
>     and /32 routes are advertised.  Where did I miss this?
>     OIC now... FWIW I think the terms "link-layer" and "NBMA" are 
> used     in a misleading context because it sounds as if these are 
> suppose     to emulate being on the same subnet.  This is not 
> true.  There is
>     a subnet for all the AMT relays and a subnet for all the AMT 
> gateways.
>     Or did I get something else wrong?
> 
> 
> I don't think PIMSM should refer to RFC2362.  The newer draft should
> be used since there have been significant changes.
> 
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
> 
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/