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

From: David Meyer <[email-masked]>
Date: Fri, 8 Apr 2005 09:05:04 -0700

Folks

	This note starts the WG Last Call for comments on
	draft-ietf-mboned-auto-multicast-04.txt, "Automatic IP
	Multicast Without Explicit Tunnels (AMT)". It can be
	found on  
	
	 ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-04.txt

	Please review the document carefully, and send your
	feedback to the list.  Please also indicate whether or
	not you believe that this document is ready to go to the
	IESG. 

	This Last Call will end on 22 Apr 2005 at 1400 PDT (UTC/GMT-7).

	Thanks,

	Dave

---

From: John Zwiebel <[email-masked]>
Date: Sun, 10 Apr 2005 09:04:32 -0700

> 	This Last Call will end on 22 Apr 2005 at 1400 PDT (UTC/GMT-7).

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 providers
do 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 would
have 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/

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Apr 2005 14:43:48 +0300 (EEST)

> 	This Last Call will end on 22 Apr 2005 at 1400 PDT (UTC/GMT-7).

I believe this is very important work (which also means it the 
time-to-market is important, so we should be finished with this soon) 
in making multicast available to everyone, but I think this still 
needs about 1-2 revisions (below).

Dave M., what is the intended category?  Experimental or Proposed 
Standard?  This requires extensive work for PS, but I could be 
convinced that if we go for Experimental first the document might not 
need to be as good at this point.  The most important thing, in the 
end, is creating a sufficiently stable spec and making the IANA prefix 
assignments so this can be deployed.

My comments to -03 (sent on the list on November 2004) have not been 
responded or integrated; I guess they were lost.  They are below.

Also, many comments to -02 weren't discussed or adopted either; I've 
included these at the end as well (removing the obsolete ones).

new issues
----------

1) MAC calculation also includes the source port in the calculation. 
However, note that the relays must not do so for the packets received 
from gateways because if there is NAT in the path, the source address 
and port will be changed and MAC does not verify.  Maybe the spec 
should be clearer which how to create and verify the MAC (from 
different nodes' perspectives)?

2) the document should be clearer about how this interoperates with 
NATs, i.e., in which cases the gateway can be behind a NAT.  If the 
traffic between gateways is sent directly (this is a MAY), the sender 
cannot be behind a NAT, at least, because otherwise NAT translation 
state does not exist and the IGMP join is discarded by the NAT.  So, 
as NAT traversal requires much more than just using UDP and tuning 
IGMP/MLD intervals, for example the following requires clarification:

    All multicast packets (data and control) are encapsulated in unicast
    packets.  To work across NAT's, the encapsulation is done over UDP
    using a well-known port number [TBD IANA].

substantial
-----------

==> the document does not sufficiently early spell out how it works (or
rather does not work under certain modes) with NATs.  Easy fix would be
s/isolated/isolated non-NAT/ below:

...

    Each gateway has an AMT pseudo-interface that serves as a default
    multicast route.  Requests to join a multicast session are sent to
    this interface and encapsulated to a particular relay reachable
    across the unicast-only infrastructure.

==> it's required to have some discussion here about locally-scoped groups,
or global groups which should not be propagated inter-domain (like service
discovery etc.) because the relay will be in a different administrative
domain.  Should the gateway recognize those and not unnecessarily
send those upstream?  Should the relay be configured to ignore them?

[...]
    Finally, to support sourcing traffic to SSM groups by a gateway with
    a global unicast address, the AMT Subnet Prefix is treated as the
    subnet prefix of the AMT pseudo-interface, and an anycast address is
    added on the interface.  This anycast address is formed by
    concatenating the AMT Subnet Prefix followed by the high bits of the
    gateway's global unicast address.  For example, if IANA assigns the
    IPv4 prefix x.y/16 as the AMT Subnet Prefix, and the gateway has
    global unicast address a.b.c.d, then the AMT Gateway's Anycast
    Address will be x.y.a.b.  Note that multiple gateways might end up
    with the same anycast address assigned to their pseudo-interfaces.

==> here and in many places as well you discuss how v4 prefix tricks
are to be used, but you should also be discussing how the
manipulations/assignments would be done for v6.

6.3.  Responding to Relay Changes

    When a gateway determines that its current relay is unreachable
    (e.g., upon receipt of a ICMP Unreachable message [ICMP] for the
    relay's unicast address), it may need to repeat relay address
    discovery.  However, care should be taken not to abandon the current
    relay too quickly due to transient network conditions. Some
    implementations may find it difficult to send a discovery packet to
    the anycast relay address while the gateway has an address configured
    on the AMT pseudo-interface on the same anycast prefix. Therefore, it
    may be necessary to tear down the AMT pseudo-interface to rediscover
    a new relay.

==> why would it be difficult to do that on some implementations?  because
the anycast address is onlink with the interface?  But remember that the
prefix should not be configured on-link, as it's used only for the purposes
of discovering the local unicast address, thus should never be configured
on the interface, right ?

    The IANA should also allocate an Autonomous System ID which can be
    used as a pseudo-AS when advertising routes to the above prefix.
...
    An autonomous system number dedicated to a pseudo-AS for multicast is
    already in use today (AS 10888), and so it is expected that no
    additional AS number is required for this prefix.

==> aren't these in conflict ?

==> there is an important issue which needs to be discussed.  Who will
maintain the prefix/AS records in RADB/RIPE/.. etc. whois databases?

    Within the native MBGP infrastructure, there is a risk that a rogue
    router or a rogue AS could introduce a bogus route to the AMT Subnet
    Prefix, and thus divert joins and cause RPF failures of multicast
    traffic.  Again, network managers have to guarantee the integrity of
    the MBGP routing to the AMT subnet prefix in much the same way that
    they guarantee the integrity of all other routes in the M-RIB.

==> this seems insufficient, because it's saying "just do it like you do for
unicast" -- but these prefixes are ANYCAST, also with their own AS number
which anyone can add to their own AS-macro, and even if you did everything
you can using unicast, you could not (completely) protect against
illegitimate hijacking.  This anycast speciality should be discussed in a
paragraph of its own.

    Gateways and relays will accept and decapsulate multicast traffic
    from any source from which regular unicast traffic is accepted. If
    this is for any reason felt to be a security risk, then additional
    source address based packet filtering MUST be applied:

==> this is totally bogus way to specify this, it's saying like "if the
implementor thinks it makes sense, do X", effectively creating a loophole
where you can be compliant with the spec but not do the checks.  Just say
that implementations MUST do these.

semi-editorial
--------------

    day) to re-resolve the unicast address of a close relay.  The gateway
    also initializes a timer used to send periodic membership reports to

==> s/initalizes/SHOULD initialize/ ?

editorial
---------

==> ToC should be just before the Introduction.  I suggest using tools where
this is trivial to achieve ;-)

The protocol introduced in this
    specification is deployed in a few strategically-placed network nodes
    and in user-installable software modules [...]

==> s/is deployed/can be deployed/ ? :-)

    3. Allowing isolated sites/hosts to receive general multicast (ISM
       [RFC1112]).

==> why not use "ASM" instead of "ISM" ?

    a AMT Relay Discovery message to the AMT Relay Anycast Address, and

==> s/a AMT/an AMT/

=======================================================
comments to -02 which apparently haven't been addressed
=======================================================

substantial
-----------

    2. The AMT Subnet Prefix is advertised for RPF reachability in the
    M-RIB by relays and gateways.

    3. Relays or gateways that receive a join for a source/group pair
    use information encoded in the address pair to rebuild the address

==> only relays need to do these, AFAICS. (should be clearer)

    The solution above will scale to an arbitrary number of relays, as
    long at the number of relays requiring multicast traffic from a
    given AMT site remains reasonable enough to not overly burden the
    site's gateway.

==> umm, e.g. with 10 or 15 recipients, with reasonably large packets,
slower links (such as those used by typical AMT deployers) would already be
highly congested -- and what's worse, all the transmissions would always be
simultaneous.

Luckily enough this is not a *huge* problem, as the sites are only likely
recipients, not senders.  But the problem is just changed the other way
around, to the relays, which might need to encapsulate, simultaneously, to
even 100 or 1000 sites.  This could be pretty high as well, especially if
the encapsulation is done in the slow router CPU..

    Finally, to support sourcing traffic to SSM groups by a gateway with
    a global unicast address, the AMT Subnet Prefix is treated as the

==> this wording, the same later in section 6.3, seems to be ignoring the
possibility that gateway is not necessarily the host sending/receiving.

==> further, it might be important to say a few words on the multicast
address assignment procedures which you're relying on here.  As it is, the
apps and hosts must know somehow that they use the correct group addresses...

6.3. Responding to Relay Changes

    When a gateway determines that its current relay is unreachable
    (e.g., upon receipt of a ICMP Unreachable message for the relay's
    unicast address), it immediately repeats the unicast address
    resolution step by sending a UDP encapsulated ICMP Echo Request to
    the AMT Relay Anycast Address, and storing the source address of the
    UDP encapsulated ICMP Echo Response as the new unicast address to
    use as a "link-layer" destination.

==> s/a ICMP/an ICMP/
==> there seem to be some remnants of ICMP here, which should be AMT Relay
Discovery process, I guess.
==> If there are existing joins (or transmissions) when the relay is
changed, should there be some text to suggest that the join should be
resent, or the transmission stopped until a new join is received (or the
like)

6.7. Sending data to SSM groups

[...]

    If the group address is an SSM group, then the packet is unicast
    encapsulated to each remote node from which the gateway has received
    an IGMPv3 report for the packet's (source, group) pair.

==> this seems to create an implicit requirement for "MSNIP--"
functionality: the AMT code must know whether there have been any joins to
the group, before sending out anything.  Regular multicast implementation would
just toss all the packets to the relay...

9. Security Considerations

==> there are at least [one] issue which need description:
  1) SSM (S,G) joins from native multicast to AMT gateway -- describe how
these are secured.

editorial
---------

    to exchange multicast traffic with the native multicast
    infrastructure (MBone) and does not require any manual

==> please eradicate any references to "MBone".  Such thing doesn't really
exist anymore :-)

This discovery should be done periodically (e.g., once a
    day) to re-resolve the unicast address of a close relay.

==> should this last "should" be upper-cased?

  The gateway MUST also advertise itself as the default
    route for multicast in the M-RIB (or it must be the default unicast
    router if unicast and multicast topologies are congruent).

==> would it make sense to clarify that this advertisement is only needed in
the site's internal topology?

   If S is not the AMT Gateway Anycast Address of the gateway, the
    packet is dropped.

==> s/dropped/silently discarded/ (everywhere) ?

[References]
==> as MBGP is mentioned so many times, a suitable reference should be added
here, I think.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: David Meyer <[email-masked]>
Date: Wed, 13 Apr 2005 07:18:25 -0700

> Standard?  This requires extensive work for PS, but I could be 

	Experimental.

	Dave