--- 1/draft-ietf-mboned-ipv6-multicast-issues-00.txt	2006-02-05 00:20:04.000000000 +0100
+++ 2/draft-ietf-mboned-ipv6-multicast-issues-01.txt	2006-02-05 00:20:04.000000000 +0100
@@ -1,17 +1,17 @@
 
 MBONE Deployment WG                                            P. Savola
 Internet-Draft                                                 CSC/FUNET
-Expires: February 9, 2005                                August 11, 2004
+Expires: March 3, 2005                                 September 2, 2004
 
                     IPv6 Multicast Deployment Issues
-             draft-ietf-mboned-ipv6-multicast-issues-00.txt
+             draft-ietf-mboned-ipv6-multicast-issues-01.txt
 
 Status of this Memo
 
    This document is an Internet-Draft and is subject to all provisions
    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
    author represents that any applicable patent or other IPR claims of
    which he or she is aware have been or will be disclosed, and any of
    which he or she become aware will be disclosed, in accordance with
    RFC 3668.
 
@@ -24,21 +24,21 @@
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on February 9, 2005.
+   This Internet-Draft will expire on March 3, 2005.
 
 Copyright Notice
 
    Copyright (C) The Internet Society (2004).
 
 Abstract
 
    This memo describes known issues with IPv6 multicast, and provides
    historical reference of how some earlier problems have been resolved.
 
@@ -286,27 +286,28 @@
 
    One should note that as Embedded RP does not require MSDP peerings
    between the RPs, it's possible to deploy more RPs in a PIM domain.
    For example, the scalability and redundancy could be achieved by
    co-locating RP functionality in the DRs: each major source, which
    "owns" a group, could have its own DR act as the RP.  This has about
    the same redundancy characteristics as using SSM -- so there may not
    be an actually very urgent need for Anycast-RP if operational methods
    to include fate-sharing of the groups is followed.
 
-   In any case, a "cold failover" variant of anycast-RP, without state
-   sharing, applicable for long-term redundancy, is still an option.  In
-   this mechanism, multiple routers would be configured with the RP
-   address, but only one would be active at the time: if the main RP
-   goes down, another takes its place.  However, the multicast state
-   stored in the RP would be lost, unless it is synchronized by some
-   out-of-band mechanism.
+   In any case, "cold failover" redundancy without state sharing is
+   still an option.  This does not offer any load-balancing of RPs or
+   shared trees, but provides only long-term redundancy.  In this
+   mechanism, multiple routers would be configured with the RP address
+   (with appropriate unicast metrics), but only one of them would be
+   active at any time: if the main RP goes down, another takes its
+   place.  However, the multicast state stored in the RP would be lost,
+   unless it is synchronized by some out-of-band mechanism.
 
 4.1.2  Embedded RP and Control Mechanisms
 
    With ASM and MSDP deployment, the ISPs can better control who is
    using their RPs.
 
    With Embedded RP, anyone could use a third-party RP to host their
    groups unless some mechanisms, for example access-lists, are in place
    to control the use of the RP [I-D.ietf-mboned-embeddedrp].