Subject: mboned: Solicited review of draft-ietf-mboned-routingarch-03.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jun 2006 08:27:47 +0300 (EEST)

FYI,

I solicited review of draft-ietf-mboned-routingarch-03.txt from 
Spencer, and also asked if he could take a look at the addrarch 
document later on.

I'll respond to the comments in a follow-up mail.

---------- Forwarded message ----------
Date: Sun, 25 Jun 2006 15:27:59 +0900
From: Spencer Dawkins <[email-masked]>
To: Pekka Savola <[email-masked]>
Subject: Solicited review of draft-ietf-mboned-routingarch-03.txt

Pekka,

Let me begin by saying that I liked the stuff I skipped over.

I wish more IETF groups were taking this kind of care of their document 
inventories...

Thanks,

Spencer

p.s. When do you need a review of the addressing arch document? I'm pretty 
slammed this week - could deliver it if you needed it, but wouldn't mind 
waiting until next week if you don't need it immediately - thanks!

What I noticed:

1.  Introduction

   This memo obsoletes and re-classifies to Historic [RFC2026] Border
   Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast
   OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and
   [RFC1585].  The purpose of the re-classification is to give the
   readers (both implementors and deployers) an idea what the status of
   a protocol is; there may or may not be legacy deployments of these

Spencer - go ahead and say "there may be" - I'd like for us to get comfortable 
with the idea that we can obsolete protocols that are still deployed (they're 
just obsolete, right?)

   protocols, which are not affected by this reclassification.  See
   Section 2.1 for more on each protocol.

1.1.  Multicast-related Abbreviations

   PIM     Protocol Independent Multicast

Spencer - since your audience is specifically people who don't have exposure to 
multicast, these three abbreviations are confusing (not entirely clear where 
the abbreviation stops and the expansion starts!). Saying "Protocol Independent 
Multicast - Dense Mode", etc. would work. Using a colon between the 
abbreviation and the definiton would work. Other things would work.

   PIM-DM  PIM - Dense Mode
   PIM-SM  PIM - Sparse Mode
   PIM-SSM PIM - (Source-specific) Sparse Mode

Spencer - you guys are the experts, but 
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-pim-sm-v2-new-12.txt 
seems to talk about "PIM - Source-Specific Multicast" - are you talking about 
something else here, or am I confused? Not sure this abbreviation is correct.

2.1.2.  PIM-DM

   PIM-DM may be some fit in small and/or simple networks, where setting

Spencer - "may be an acceptable fit"?

   up an RP would be unnecessary, and possibly in cases where a large
   number of users is expected to be able to wish to receive the

Spencer - "a large percentage of users"? it seems like the point is that almost 
everyone is listening, not that there are a lot of people listening.

   transmission so that the amount of state the network has to keep is
   minimal.  Therefore PIM-DM has typically only been used in special
   deployments, never currently in, e.g., ISPs' networks.

Spencer - not a comment, but I'm curious. If you could add a phrase ("special 
deployments, like MANETs" or wherever you have seen PIM-DM deployed - 
obviously, I made up MANETs), that might be useful.

   PIM-DM never really got popular due to its reliance of data plane and

Spencer - "never really became popular due to its reliance on data plane" (and 
I'm still not quite sure what the last bit means)

   potential for loops, and the over-reliance of the complex Assert
   mechanism.  Further, it was a non-starter with high-bandwidth
   streams.

Spencer - again, you don't have to add anything, but if you could say "streams, 
because ...", that might be helpful.

2.1.3.  Bi-directional PIM

   Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined
   PIM-SM operation, without data-driven events and data-encapsulation,
   inside a PIM-SM domain.  The usage of bi-dir PIM may be on the
   increase especially inside sites leveraging multicast.

Spencer - not clear to me what "sites leveraging multicast" covers.

2.1.4.  DVMRP

   Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075]
   [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first
   protocol designed for multicasting, and to get around initial
   deployment hurdles, it also included tunneling capabilities which

Spencer - "hurdles. It also"

   were part of its multicast topology functions.

2.1.5.  MOSPF

   MOSPF [RFC1584] was implemented by several vendors and has seen some
   deployment in intra-domain networks.  However, since it does not

Spencer - perhaps "since it is based on intra-domain OSPF and does not..."?

   scale to the inter-domain case, operators have found it is easier to
   deploy a single protocol for use in both intra-domain and inter-
   domain networks and so it is no longer being actively deployed.

2.1.6.  BGMP

   BGMP [RFC3913] did not get sufficient support within the service
   provider community to get adopted and moved forward in the IETF
   standards process.  There were no reported production implementations
   and no production deployments.

Spencer- OK, you probably have a limited amount of time and energy for this, 
but - you're writing what will probably become the collective wisdom of the 
ages on these protocols (I'm slightly kidding) - if you have any words that 
might say "seemed reasonable but wasn't adopted" or "because of problems with 
..." on any of these dead-ends, that might be useful in case someone wakes up 
in five years and says "hey, we could use OSPF for multicast routing", etc.

2.1.7.  CBT

   CBT [RFC2201] was an academic project that provided the basis for PIM
   sparse mode shared trees.  Once the shared tree functionality was
   incorporated into PIM implementations, there was no longer a need for
   a production CBT implemention.  Therefore, CBT never saw production
   deployment.

Spencer - this is exactly what I'm talking about - the "because"s. Even the 
books on multicast treat all of them as reasonable alternatives, last I 
checked.

2.1.8.  Interactions and Summary

   It is worth noting that is it is possible to run different protocols
   with different groups ranges (e.g., treat some groups as dense mode

Spencer - "group ranges"? but "multicast group ranges" would probably help with 
clarity here. (Do you think people understand the whole "multicast addresses = 
multicast groups" idea at this point in the document? I wasn't sure)

   in an other-wise PIM-SM network; this typically requires manual
   configuration of the groups) or interact between different protocols
   (e.g., use DVMRP in the leaf network, but PIM-SM upstream).  The
   basics for interactions among different protocols have been outlined
   in [RFC2715].

2.2.  Distributing Topology Information

   This subsection introduces these protocols.

Spencer- I'm lost here (as a reader) - I'm not sure I understand clearly the 
relationship between the protocols in 2.1 and the protocols in 2.2. Would I 
expect to run PIM-SM AND MBGP for multicast? I think I'm a sentence or two 
short of a clue, but I'm short of a clue. Would there be a sentence like "the 
following protocols are used in addition to PIM-SM" lurking in your mind?

2.2.1.  Multi-protocol BGP

   These extensions are in widespread use wherever BGP is used to
   distribute unicast topology information.  Those having multicast
   infrastructure and using BGP should use Multiprotocol BGP to
   distribute multicast reachability information explicitly even if the
   topologies are congruent.  A number of significant multicast transit
   providers even require this, by doing the RPF lookups solely based on
   explicitly advertised multicast address family.

Spencer - it wasn't clear to me whether the "should use Multiprotocol BGP" is 
because of RPF lookups, or if there were additional reasons to distribute 
explicitly.

2.2.2.  OSPF/IS-IS Multi-topology Extensions

   It is worth noting that interdomain incongruence and intradomain
   incongruence are orthogonal, so one doesn't require the other.
   Specifically, interdomain incongruence is quite common, while
   intradomain incongruence isn't, so you see much more deployments of

Spencer - either "much more deployment" or "many more deployments", I think.

   MBGP than MT-ISIS/OSPF.  Commonly deployed networks have managed well
   without protocols handling intradomain incongruence.  However, the
   availability of multi-topology mechanisms may in part replace the
   typically used workarounds such as tunnels.

2.2.3.  Issue: Overlapping Unicast/multicast Topology

   Different implementations deal with this using different means.

Spencer - I would say "in different ways", but that's just me.

   One implemented approach is to just look up the information in the

Spencer - I got lost here. Is this "Another alternative approach ..."? or is 
this one way that the previous paragraph is implemented? "One" wasn't enough to 
guide me :-)

   unicast routing table, and provide the user capabilities to change
   that as appropriate, using for example copying functions discussed
   above.

2.3.  Learning (Active) Sources

   Typically, multicast routing protocols must either assume that the
   receivers know the IP addresses of the (active) sources for a group a

Spencer - your language is correct but just looks weird. "a multicast group, a 
priori, ..."? It's the two "a"s that are being used differently, so close 
together.

   priori, possibly using an out-of-band mechanism (SSM), or the sources
   must be discovered by the network protocols automatically (ASM).

2.3.1.  SSM

   Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also
   referred to as "single-source Multicast") does not count on learning
   active sources in the network; it is assumed that the recipients know
   these using out of band mechanisms, and when subscribing to an (S,G)
   channel indicate toward which source(s) the multicast routing
   protocol should send the Join messages.

Spencer - WOW, this just went into the next level of detail. Is it possible to 
describe this without quite so much terminology? Or do you think the readers 
should understand what (S,G) means and what a Join message actually does? 
(Actually - if there are any prerequisites for reading this document, it might 
be nice to list them in a separate section, early in the document. Ordinarily 
we don't do this, but you're writing something between a BCP and a tutorial.)

2.3.2.  MSDP

   MSDP is also used to share the state about sources between multiple
   RPs in a single domain for, e.g., redundancy purposes [RFC3446].
   There is also work in progress to achieve the same using PIM

Spencer - "a work-in-progress to achieve the same objective using ..."

   extensions [I-D.ietf-pim-anycast-rp].  See Section 2.5 for more.

Spencer - "for more information"?

   There is no intent to define MSDP for IPv6, but instead use only SSM
   and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues].

2.3.3.  Embedded-RP

   The model works by defining a single RP for a particular group for
   all of the Internet, so there is no need to share state about that
   with any other RPs (except, possibly, for redundancy purposes with
   Anycast-RP using PIM).

Spencer - it seems like you should be saying something here about whether 
having a single RP for a particular group for all of the Internet seems wise or 
not - that would be consistent with previous discussion.

2.4.1.  Manual Configuration with an Anycast Address

   With such design, an anycast RP uses a "portable" address, which is
   configured on a loopback interfaces of the routers currently acting
   as RPs, as described in [RFC3446].

Spencer - hmm. Is "portable" a clearly defined concept? "Portable IP addresses" 
just seem scary!

2.4.2.  Embedded-RP

   Embedded-RP provides the information about the RP's address in the
   group addresses which are delegated to those who use the RP, so
   unless no other ASM than Embedded-RP is used, one only needs to

Spencer - "the network administrator only needs to"

   configure the RP routers themselves.

2.4.3.  BSR and Auto-RP

   It is worth noting that both Auto-RP and BSR were deployed before the
   use of a manually configured anycast-RP address became relatively
   commonplace, and there is actually relatively little use for them

Spencer - "little need for them"

   today.

2.5.1.  Anycast RP

   There is also work in progress to achieve the same using PIM
   extensions [I-D.ietf-pim-anycast-rp].  This is a required method to
   be able to use Anycast RP with IPv6.

Spencer - I'm starting to wonder if there's a short table that says "IPv4 
only"/"IPv6 only"/"IPv4-IPv6" for the protocols and mechanisms mentioned in 
this document...

2.5.3.  Bi-directional PIM

   Bi-directional PIM (see Section 2.1.3) uses less state than PIM-SM,
   implying a better total convergence.  On the other hand, PIM-SM or
   SSM may be faster especially in scenarios where bi-directional needs

Spencer - "may converge more quickly, especially ..."?

   to re-do the Designated Forwarder election.

2.6.1.  Hosts Sending Multicast

   Hosts don't need to do any signalling prior to sending multicast to a
   group; they just send the packets to the link-layer multicast
   address, and the designated router will receive all the multicast
   packets and start forwarding them as appropriate.

Spencer - I get what you're saying, but would it be useful to say "After 
choosing a multicast group through a variety of means, hosts just send ..."?

2.7.2.  Host/Router Flooding Reduction

   IEEE specifications mention Group Address Resolution Protocol (GARP)
   [GARP] as a link-layer method to perform the same functionality.  The
   implementation status is unknown.

Spencer - It might be nice to ask our IEEE liaison if 802.1 has any clue about 
implementations.

   IGMP snooping [I-D.ietf-magma-snoop] appears to be the most widely

Spencer - sorry for not saying this sooner - "snooping" may not be quite common 
usage, although it's common in the multicast community. Maybe think about 
"eavesdropping"? But "snoop" is used a bunch of places in the document.

   implemented technique.  IGMP snooping requires that the switches
   implement a significant amount of IP-level packet inspection; this
   appears to be something that is difficult to get right, and often the
   upgrades are also a challenge.  To allow the snooping switches to
   identify at which ports the routers reside (and therefore where to
   flood the packets) instead of requiring manual configuration,

Spencer - "without requiring manual configuration"

   Multicast Router Discovery protocol is being specified [RFC4286].

Spencer - "is being specified"? Is there additional spec work underway, beyond 
the RFC, or is this "is being implemented" or "is being deployed"?

   IGMP proxying [I-D.ietf-magma-igmp-proxy] is sometimes used either as
   a replacement of a multicast routing protocol on a small router, or
   to aggregate IGMP/MLD reports when used with IGMP snooping.

3.  Acknowledgements

   Tutoring a couple multicast-related papers, the latest by Kaarle

Spencer - it wasn't clear to me whether this was a good thing or not (easy to 
read it as "Kaarle wrote a paper that stinks because the document he used 
stinks"). Was this tutoring, or reviewing, or ...? Just confused - sorry.

   Ritvanen [RITVANEN] convinced the author that the up-to-date
   multicast routing and address assignment/allocation documentation is
   necessary.

6.1.  Normative References

Spencer- it wasn't clear what the normative-informative split was based on here 
(not an easy thing to do for a specification like this anyway). I might guess 
that Normative is the list of stuff you think is useful, and the historic stuff 
is Informative, but I don't know if that's true or not.

   [I-D.ietf-pim-sm-v2-new]
              Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode PIM-SM):
              Protocol Specification  (Revised)",
              draft-ietf-pim-sm-v2-new-11 (work in progress),
              October 2004.

Spencer - version 12 of I-D.ietf-pim-sm-v2-new was approved and is in the RFC 
Editor queue (I'm not really OCD enough to check all your references, I 
happened to be the Gen-ART reviewer for this one).

A.1.  Reliable Multicast

   One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208].
   This does not require support from the routers, bur PGM-aware routers
   may act as helpers delivering missing data.

Spencer - is "helpers" PGM terminology? If yes, I'd put it in quotes, if not, 
perhaps "local retransmitters" or something reasonable. "Help" is pretty 
vague...
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jun 2006 12:47:52 +0300 (EEST)

Spencer,

Thanks for thorough read.  You raised many points which weren't clear 
enough, at at least one of them wasn't clear enough to myself either 
(and I couldn't understand what the contributed text really meant to 
reword it), so I'll make a separate thread out of it.  Hopefully the 
-04 version (some excerpts of it below) which I'm submitting right now 
would be more readable to the rest of the IETF :-)

Basically I took almost all your comments as is or clarified the 
unclear.  The only thing I didn't do was a table about IPv4/IPv6/both 
status of various protocols which I didn't see necessary, but if you 
(or someone else) feels strongly about it, I'm willing to reconsider.

Inline for the details,

On Mon, 26 Jun 2006, Pekka Savola wrote:
> Spencer - go ahead and say "there may be" - I'd like for us to get 
> comfortable with the idea that we can obsolete protocols that are still 
> deployed (they're just obsolete, right?)

I made this "there may be .. some of these protocols" because the 
original intent was to say that only some of those were deployed.

> Spencer - since your audience is specifically people who don't have exposure 
> to multicast, these three abbreviations are confusing (not entirely clear 
> where the abbreviation stops and the expansion starts!). Saying "Protocol 
> Independent Multicast - Dense Mode", etc. would work. Using a colon between 
> the abbreviation and the definiton would work. Other things would work.

I added another TAB after the abbreviation to make this more obvious.

> something else here, or am I confused? Not sure this abbreviation is correct.

Good catch, changed to be in accordance to sm-v2-new spec.

> Spencer - "may be an acceptable fit"?

OK.

> Spencer - "a large percentage of users"? it seems like the point is that 
> almost everyone is listening, not that there are a lot of people listening.

That's better.

> obviously, I made up MANETs), that might be useful.

I removed this, but if folks want to add something, I'm all ears.

Now I'm just saying:

    PIM-DM has been used to transition to PIM-SM but it is no
    longer in widespread use.

> Spencer - "never really became popular due to its reliance on data plane" 
> (and I'm still not quite sure what the last bit means)
>
> Spencer - again, you don't have to add anything, but if you could say 
> "streams, because ...", that might be helpful.

Both of these are good points.  I just took text that was offered 
without really understanding it myself.. thanks for keeping me honest. 
I'll put in a separate thread to clarify the data plane reliancy.  The 
text now reads:

    PIM-DM never became popular due to its reliance on data plane and
    potential for loops, and the over-reliance of the complex Assert
    mechanism.  Further, it was a non-starter with high-bandwidth streams
    due to its flooding paradigm.

> Spencer - not clear to me what "sites leveraging multicast" covers.

I removed that sentence as it seemed assumptive, now it says:

    Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined
    PIM-SM operation, without data-driven events and data-encapsulation,
    inside a PIM-SM domain.  As it doesn't keep source-specific state, it
    may be a lucrative approach especially in sites with a large number
    of sources.

> Spencer - "hurdles. It also"

OK.

> Spencer - perhaps "since it is based on intra-domain OSPF and does not..."?

OK.

> in five years and says "hey, we could use OSPF for multicast routing", etc.

Yes, I'm painfully aware of that problem.  More historic gold nuggets 
would be excellent.  But folks haven't sent text as I have no 
first-hand experience myself...

> books on multicast treat all of them as reasonable alternatives, last I 

Totally agree that such would be very helpful.  Maybe I should try to 
get a greybeard in the corner at the IETF, write some provocative text 
and see if anyone yells :-)

> Spencer - "group ranges"? but "multicast group ranges" would probably help 
> with clarity here. (Do you think people understand the whole "multicast 
> addresses = multicast groups" idea at this point in the document? I wasn't 
> sure)

Reworded.  I'll assume the readers know at least some multicast 
basics, but not necessarily about routing.  I wonder if there is a 
good (IETF) reference to point to.

> following protocols are used in addition to PIM-SM" lurking in your mind?

Yes, you need both.  One gives you the topology you want to use, the 
other sets up the state.

I added a sentence at the end of the first paragraph to clarify this:

    When unicast and multicast topologies are the same ("congruent"),
    i.e., use the same routing tables (routing information base, RIB), it
    has been considered sufficient just to distribute one set of
    reachability information to be used in conjunction with a protocol
    that sets up multicast forwarding state (e.g., PIM-SM).

> because of RPF lookups, or if there were additional reasons to distribute 

It's basically just for RPF and topology information.  I've expanded 
this a bit.

    These extensions are in widespread use wherever BGP is used to
    distribute unicast topology information.  Multicast-enabled networks
    that use BGP should use Multiprotocol BGP to distribute multicast
    reachability information explicitly even if the topologies are
    congruent to make an explicit statement about multicast reachability.
    A number of significant multicast transit providers even require
    this, by doing the RPF lookups solely based on explicitly advertised
    multicast address family.

> Spencer - either "much more deployment" or "many more deployments", I think.

I took the former.

> Spencer - I would say "in different ways", but that's just me.

Your suggestion is much better :-)

> this one way that the previous paragraph is implemented? "One" wasn't enough 
> to guide me :-)

I replaced "one" with "another" so it should be clear now.

> Spencer - your language is correct but just looks weird. "a multicast group, 
> a priori, ..."? It's the two "a"s that are being used differently, so close 
> together.

I did s/a priori/in advance/.

> Spencer - WOW, this just went into the next level of detail. Is it possible 
> to describe this without quite so much terminology? Or do you think the 
> readers should understand what (S,G) means and what a Join message actually 
> does? (Actually - if there are any prerequisites for reading this document, 
> it might be nice to list them in a separate section, early in the document. 
> Ordinarily we don't do this, but you're writing something between a BCP and a 
> tutorial.)

There are no specific prerequisites, but I've assumed the reader is 
aware of generic multicast and routing concepts.  Whether "(S,G)" or 
"(*,G)" belongs to those is on the borderline..

Thanks for noticing this.  I'm blind to these myself already :-)
I've reworded this:

    Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also
    referred to as "single-source Multicast") does not count on learning
    active sources in the network.  Recipients need to know the source IP
    addresses using an out of band mechanism which are used to subscribe
    to the (source, group) channel.  The multicast routing uses the
    source address to set up the state and no further source discovery is
    needed.

> Spencer - "a work-in-progress to achieve the same objective using ..."

Reworded as it was approved already..

> Spencer - "for more information"?

Yep.

> having a single RP for a particular group for all of the Internet seems wise 
> or not - that would be consistent with previous discussion.

I wasn't sure whether your point was that a signle RP could be bad 
e.g. from redundancy perspective, or that it could be bad due to other 
reasons (which aren't clear to me, but that may be because that spec 
was written by me).  If former, this should be clearer.

    The model works by defining a single RP address for a particular
    group for all of the Internet, so there is no need to share state
    about that with any other RPs.  If necessary, RP redundancy can still
    be achieved with Anycast-RP using PIM.

> Spencer - hmm. Is "portable" a clearly defined concept? "Portable IP 
> addresses" just seem scary!

Removed the word as it didn't seem necessary here.

> Spencer - "the network administrator only needs to"

Good point.. I've always wanted to make these kinds of things clear 
myself..

> Spencer - "little need for them"

OK.

> only"/"IPv6 only"/"IPv4-IPv6" for the protocols and mechanisms mentioned in 

I've clarified the current text, but didn't create an IPv4/IPv6 table 
of these protocols, as I didn't think it would be interesting enough 
and the list is long.  The main thing is that MSDP is v4-only and that 
ripples into many parts of the spec.  Conversely, Embedded-RP is 
v6-only, but others (except the historic ones) should be IP-agnostic.

> Spencer - "may converge more quickly, especially ..."?

OK, I reworded the whole paragraph due to other comments:

    Because bi-directional PIM (see Section 2.1.3) does not switch to
    shortest path tree (SPT), the final multicast tree is built faster
    and converges faster after failures.  On the other hand, PIM-SM or
    SSM may converge more quickly especially in scenarios where bi-
    directional needs to re-do the Designated Forwarder election.

> choosing a multicast group through a variety of means, hosts just send ..."?

Yes, maybe that's more straightforwarded, adopted that..

> Spencer - It might be nice to ask our IEEE liaison if 802.1 has any clue 
> about implementations.

Good point.  I'll add that as a discussion item for the next IETF or 
just go for it in any case.

> Spencer - sorry for not saying this sooner - "snooping" may not be quite 
> common usage, although it's common in the multicast community. Maybe think 
> about "eavesdropping"? But "snoop" is used a bunch of places in the document.
>

Yes, actually the whole paragraph got reworded a bit so this 
disappeared:

    IGMP snooping [RFC4541] appears to be the most widely implemented
    technique.  IGMP snooping requires that the switches implement a
    significant amount of IP-level packet inspection; this appears to be
    something that is difficult to get right, and often the upgrades are
    also a challenge.  Snooping switches also need to identify the ports
    where routers reside (and therefore where to flood the packets) using
    Multicast Router Discovery protocol [RFC4286], looking at certain
    IGMP queries [RFC4541], or by manual configuration.  IGMP proxying
    [I-D.ietf-magma-igmp-proxy] is sometimes used either as a replacement
    of a multicast routing protocol on a small router, or to aggregate
    IGMP/MLD reports when used with IGMP snooping.

> Spencer - "is being specified"? Is there additional spec work underway, 
> beyond the RFC, or is this "is being implemented" or "is being deployed"?

It was just a search-and-replace issue with I-D -> RFC substitution. 
It's reworded as above.  I'm not aware of implementations, but I don't 
speculate about that either.

>  multicast routing and address assignment/allocation documentation is

The point was that when I tutored (and reviewed) those papers, they 
were bad at first, because there was no current information available. 
I had to make the folks dig really deep to find anything that would 
make the paper up-to-date.  The referred paper is OK because we spent 
a lot of time to make it right.  I didn't change the text because I 
couldn't figure out how to say it better, but if you have a 
suggestion, I can change that in the next rev.

> Spencer- it wasn't clear what the normative-informative split was based on 
> here (not an easy thing to do for a specification like this anyway). I might 
> guess that Normative is the list of stuff you think is useful, and the 
> historic stuff is Informative, but I don't know if that's true or not.

I've put the most important ones under normative, as well as those 
I-Ds that this spec should block on because if they don't get approved 
the text needs to be taken out of reworded.

> happened to be the Gen-ART reviewer for this one).

Automatically updated :-)

> perhaps "local retransmitters" or something reasonable. "Help" is pretty 

"router assist" function is the official term, so this is now:

    One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208].
    This does not require support from the routers, bur PGM-aware routers
    may act in router assistance role in the initial delivery and
    potential retransmission of missing data.

-- 
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/