Subject: Re: Take ISP BB scenarios as WG document?

From: Pekka Savola <[email-masked]>
Date: Sat, 5 Feb 2005 19:08:12 +0200 (EET)

Hi,

(co-chair hat on)

There seems to be consensus to take this as WG items.  Authors, please 
submit the next version as 
draft-ietf-v6ops-bb-deployment-scenarios-00.txt

Thanks, and keep the reviews coming!

(hat off)

On Fri, 21 Jan 2005, Pekka Savola wrote:
> (co-chair hat on)
>
> The authors have asked if the following document would be adopted as WG item:
>
> "ISP IPv6 Deployment Scenarios in Broadband Access Networks"
> http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt
>
> Please say what you think.  Silence DOES NOT indicate consent.  If new work 
> items are to be adopted, there must be active support for doing it, and there 
> must be people willing to review and work on the draft.
>
> The deadline for comments is in 2 weeks, on February 4th.
>
> (hat off)
>
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Salman Asadullah <[email-masked]>
Date: Sun, 06 Feb 2005 10:16:38 -0800

Hello Pekka & All,

We would like to thank you and every one in the work group who have helped 
us to make this draft better and finally approving it.

We will work on integrating all the new comments/feedback and submit the 
next version soon.

We would appreciate any more feedback.

Regards,
Salman

At 07:08 PM 2/5/2005 +0200, Pekka Savola wrote:
>submit the next version as draft-ietf-v6ops-bb-deployment-scenarios-00.txt
>
>>items are to be adopted, there must be active support for doing it, and 
>>there must be people willing to review and work on the draft.
>>

---

From: Ciprian Popoviciu <[email-masked]>
Date: Mon, 14 Feb 2005 13:50:09 -0500

Hello Pekka,

First of all, once again thank you for your thorough review and 
suggestions. We integrated most of the suggestions you and the other folks 
on the list made and submitted the updated version of the draft last night: 
draft-ietf-v6ops-bb-deployment-scenarios-001.txt

There are a few items you highlighted that we are still investigating. We 
should have everything clarified soon and we will send a complete response 
to all your suggestions and the suggestions we received from other people 
on the list. We did not consolidate some of the sections yet as you 
proposed because we feel like we need a bit more time to find the best way 
to do this. We agree that in some areas this will optimize the draft but we 
want to make sure that we do not loose the correlation between the 
information presented and the context in which it was presented. This is 
something we are still working on.

So please stay tuned for our detailed reply. Thank you everyone for the 
valuable feedback provided.

Chip

At 12:04 PM 1/31/2005 +0200, Pekka Savola wrote:
>>Please say what you think.  Silence DOES NOT indicate consent.  If new 
>>work items are to be adopted, there must be active support for doing it, 
>>and there must be people willing to review and work on the draft.
>>
>(personal comments, without any hats, of course)
>
>First, I'd like to thank the authors for this important work.  I support 
>this being taken as WG item and moved forward.
>
>I'll note that I've personally felt that the document would be better split
>to separate documents, but WG participants felt otherwise, so it's OK
>because this was not a big issue for me as long as the document is kept 
>consistent.
>
>I also thought that it would be useful to merge some text in a "generic" 
>section, which the other sections could then refer and add to if 
>necessary.  There was also some pushback for this, but because I feel this 
>is important, let me try to state this again:
>  a) subsctions "Multicast, QoS, Security Considerations and Network
>Management" are 95% common across all the scenarios and could be better put
>in one "Generic" section, and referred to and expanded in the
>scenario-specific sections.
>  b) Some parts of different deployment models could possibly be put in such a
>generic section.  This is a much trickier to get right, of course.. but in
>"Addressing" and "Routing" subsubsections there is a lot of common text.
>
>Maybe a) at least is worth considering?
>
>substantial
>-----------
>
>0) I've sent some comments off-list; the most important of them was that 
>there is some work needed especially with DSL RBE-like approach to provide 
>means for sane bulk DSL usage.  Currently you have to configure each 
>interface for each customer separately, instead of using a template.  This 
>will require an implementation modification to generate a RA prefix based 
>on the VLAN or PVC id.  This should be discussed in the memo.
>
>1) Many different scenarios talk about dual-stacking (or not) of the edge
>router.  Is it sufficiently clear in the text that if the SP so desires, it
>can use separate edge routers for v4 and v6?
>
>2) One thing that struct me that is missing as an access network is HomePNA
>(sigh).  I don't think this is a major deployment model though, so it's OK
>to leave it out as well.  I think it is basically the same as Ethernet,
>except Instead of access swithch, you have a HomePNA switch.  I don't know
>to which degree those would need to be IPv6-aware; probably not at all
>unless one would want it to snoop multicast.
>
>3) The draft refers extensively to draft-mickles-v6ops-isp-cases-05.txt
>(probably at my badly worded suggestion), which is not going to be
>published.  So, you should not depend on text in that document -- everything
>that should be known by the reader should be available here.  However, it is
>still a good idea to keep the reference still in the Acknowledgements
>section.
>
>4) In WLAN scenario, the document should probably talk a bit about host
>authentication at hotspots.  If done with 802.11x, then this probably needs
>little with Ipv6.  If done with web redirection, those services obviously
>would need to support IPv6 hijacking as well...
>
>
>semi-editorial
>--------------
>
>    B. Native IPv6 Deployment: The Access Provider routers are upgraded
>    to support IPv6 and can become dual-stack. In a dual-stack network
>    an IPv6 IGP such as OSPFv3 or IS-IS is enabled, usually mapping the
>    IGP deployed for IPv4. The most important thing to remember in this
>    case is that the device resources are now shared between IPv4 and
>    IPv6 processes. This problem could be elimnated with the use of
>    ISIS-MT (multi-topology) where a single database and SPF is used for
>    IPv4 and IPv6.
>
>==> the last part of the sentence is slightly inaccurate, and potentially
>confusing.  As this has been discussed extensively in the soon-to-be-RFC,
>maybe th ewhole discussion of which IGP to select and what thay might imply
>should be just referred to the other document?
>
>    The native approach has the advantage of supporting IPv6
>    multicast traffic but it implies a significant impact on the IPv4
>    operational network from software, configuration and possibly
>    hardware upgrade perspective.
>
>==> s/implies/may imply/ -- whether this is the case depends a lot on your
>hardware, your current status of software, etc.!
>
>    multicast or not), routing protocols used (GRE is the only tunnel
>    type which can transport layer 2 messages as well), manage-ability
>    and scalability (dynamic versus static tunnels).
>
>==> well, I guess in principle you could do L2TP as well, so being 100%
>accurate, the statement about GRE is not entirely true.  Minor tweaking?
>
>
>    Some of the factors that hinder deployment of native IPv6 in current
>    cable networks include:
>
>==> it is not 100% clear which of these apply in the bridged cmts model, and
>which in the routed cmts model.  Clarify.
>
>    A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These
>    devices rely on IGMP join messages to track membership of hosts that
>    are part of a particular IP Multicast group. In order to support ND
>    the CM and CMTS will need to support IGMPv3/MLDv2 snooping.
>
>==> the last sentence is not entirely true.  For ND, you just need MLDv1
>snooping, though MLDv2 would be preferable for SSM support.  But as said,
>you only need MLDv1 .. and that only in those devices which actually would
>otherwise block the v6 multicasts..?
>
>    C. Changes need to be made to the DOCSIS specification to include
>    support for IPv6 on the CM and CMTS. This is imperative for
>    deploying native IPv6 over cable networks.
>
>==> this is not clear.  The only reason I could think of is to be able to
>manage CM/CMTS over v6, which seems hardly imperative, so there must be
>something else.  Clarify?
>
>6.2.1.2.2 IP Addressing for Hosts
>
>    If there is no GWR connected to the CM, all the hosts behind the CM
>    will belong to the same /64 subnet that is assigned using stateless
>    auto-configuration or DHCPv6.
>
>==> this is slightly confusing, because if DHCPv6 is used, these hosts don't
>need to belong ti the same subnet?  Actually, I would prefer tailing down
>this paragraph, as the next ones more accurately describe the situation.
>
>.2.1.3 Data Forwarding
>
>    The CM and CMTS must be able to bridge native IPv6 unicast and
>    multicast traffic. The CMTS must provide IP connectivity between
>    hosts attached to CMs and must do so in a way that meets the
>    expectation of Ethernet attached customer equipment. In order to do
>    that, the CMTS must either forward Neighbor Discovery (ND) packets
>    or provide a proxy ND service.
>
>==> the good question to ask here would be, "why wouldn't you then enable
>IPv6 on CMTS? instead of proxying?"  This requires no changes to _DOCSIS_
>part of CMTS -- just that it implements basic v6 router functionality..
>(in many places)
>
>
>   Communication between hosts behind different CMs is always forwarded
>    by the CMTS.
>
>==> as the CMTS is layer 2 (right?) maybe this should be "forwarded
>through" or "bridged through" ?
>
>    In order to support IPv6 multicast applications across DOCSIS cable
>    networks, the CM and bridging CMTS need to support IGMPv3/MLDv2
>    snooping. MLD is identical to IGMP in IPv4, only the name and numbers
>    are changed.
>
>==> I'd reword the latter sentence to like, "MLD is almost identical to IGMP
>in IPv4". (many places)
>
>6.2.1.4 Routing
>
>    The hosts install a default route that points to the ER or the GWR.
>    No routing protocols are needed on these devices which have
>    limited resources. If there is a GWR present it will also use static
>    default route to the ER.
>
>==> I suggest removing "on these devices which have limited resources". 
>That is pretty subjective.  The same under all the scenarios.
>
>==> further, in these sections, I'd be a bit more informative about how
>exactly the default route is configured.  Typically learned from DHCPv4, I'd
>guess.
>
>    2. IPv4 Cable (HFC) Network, GWR at Customer Site
>
>    In this case the cable network, including the CM and CMTS remain
>    IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This
>    scenario is also easy to deploy since the cable operator just needs
>    to add GWR at the customer site.
>
>==> easy to deploy, but also typically unfeasible to deploy :-/... because
>this requires investment and deployment/maintance of/on a new IPv6-capable
>GWR.  For larger deployments, this would probably be a non-starter, and it
>might be better to try to either to tunnel to hosts directly (cheaper ;-),
>or just dual-stack the existing box.
>
>6.2.2.1.2 Addressing
>
>    The only device that needs to be assigned an IPv6 address at customer
>    site is the host. Host address assignment can be done statically as
>    there is no mechanism to transport ND messages or DHCPv6 messages
>    over the IPv4 cable network.
>
>==> As you're suggesting using tunneling here, I'd suspect getting IPv6
>addresses is tunneling mechanism specific; depending on the mechanism, this
>might be automatic or it might require manual configuration.
>
>    The host will use its IPv4 address to source the tunnel to the
>    ER. All IPv6 traffic will be forwarded to the ER, encapsulated in
>    IPv4 packets. The intermediate IPv4 nodes will forward this traffic
>    as regular IPv4 packets. The ER will need to terminate the tunnel
>    and/or provide other IPV6 services [for example 6to4 relay, tunnel
>    broker etc.].
>
>==> see the substantial issue above -- is it clear enough that the tunnel
>box need not be the (v4) ER?.  s/IPV6/IPv6/, and remove the stuff in []'s.
>
>    The GWR will use its global IPv4 address to source the tunnel to
>    the ER. The tunnel endpoint will be the IPv4 global address of the
>    ER. All IPv6 traffic will be forwarded to the ER, encapsulated in
>    IPv4 packets. The intermediate IPv4 nodes will forward this traffic
>    as regular IPv4 packets. In case of 6to4 tunneling, the ER will need
>    to support 6to4 relay functionality in order to provide IPV6
>    Internet connectivity to the GWR and hence the hosts connected to the
>    GWR.
>
>==> "global address" is assumptive of deployment, and see the comment above
>on service support on ER..
>
>    If using manual tunneling, the GWR and ER can use static routing or
>    they can also configure RIPng. The RIPng updates can be transported
>    over a manual tunnel, which does not work when using 6to4 tunneling.
>
>    Customer routes can be carried to the ER using RIPng updates. The ER
>    can advertise these routes in its IGP. Prefix summarization should be
>    done at the ER.
>
>==> this is the only section that still mentions RIPng, and it should IMHO
>be removed.  Really. :-)
>
>6.2.2.3.1 IPv6 Related Infrastructure Changes
>
>    Since the CM still acts as a Layer-2 bridge, it does not need to
>    be dual-stack. The CM will need to support bridging of IPv6 unicast
>    and multicast traffic and IGMPv3/MLDv2 snooping which requires
>    changes in the DOCSIS specification.
>
>==> as said before, MLDv2 snooping is not a strict requirement :)
>
>    The hosts can receive their IPv6 address via DHCPv6 with the CMTS
>    acting as a DHCPv6 relay agent. If address assignment on hosts is
>    done via stateless autoconfiguration,
>
>==> this is phrased in an odd way.  I'd say that the assumption is that
>statless address autoconfiguration is used almost always, and DHCPv6 is the
>exception (except when you delegate a prefix.)  This applies to all the
>access types, and could use maybe switching the order of sentences and
>tuning the text a bit. (In many places..)
>
>    If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The
>    host and CM/GWR will receive IPv6 addresses from pools of /64
>    prefixes configured on the DHCPv6 server. The CMTS will need to glean
>    pertinent information from the DHCP Offer messages, sent from the
>    DHCP server to the DHCP clients (host and CM/GWR), much like it does
>    today in DHCPv4. All CM/GWR connected to the same cable interface on
>    the CMTS belong to same /64 prefix. The hosts connected to the same
>    cable interface on the CMTS may belong to different /64 prefixes as
>    the CMTS will have multiple /64 prefixes configured under its cable
>    interfaces.
>
>==> I'm not sure what to make of this, due to the different assumption above
>about the usage of DHCPv6.
>
>Currently the DHCP-PD functionality cannot be
>    implemented if the DHCP-PD server is not the Edge Router. If the
>    DHCP-PD messages are relayed, the Edge Router does not have a
>    mechanism to learn the assigned prefixes and thus install the proper
>    routes to make that prefix reachable. Work is being done to address
>    this issue, one idea being to provide the Edge Router with a snooping
>    mechanism.
>
>==> it is worth considering, however, whether a solution is *really* needed
>here (maybe this problem could be shorter in the sections, and longer in the
>gap analysis).  I mean, why would one even want to have DHCPv6 server
>somewhere else?  It's nicely fate-sharing with the service if it's at ER,
>and using Radius you can separate the user policy from the server.  The only
>point is that if the ER does not offer DHCPv6 functionality, but in that
>case, I'd be doubtful if it offered this snooping hack either...
>
>6.2.2.5.4 Routing
>
>    The CM/GWR can use a static default route pointing to the CMTS/ER or
>    it can run a routing protocol such as RIP-ng or OSPFv3 between itself
>    and the CMTS. Customer routes from behind the CM/GWR can be carried
>    to the CMTS using routing updates.
>
>    If DHCP-PD is used for address assignment a static route is
>    automatically installed on the CMTS/ER for each delegated /48 prefix.
>    The static routes need to be redistributed into the IGP at the
>    CMTS/ER so there is no need for a routing protocol between the
>    CMTS/ER and the GWR.
>
>==> the end of 1st para is RIPng fragment and should be removed IMHO. In any
>case, this seems to be conflicting with the end of the 2nd paragraph :)
>
>ASM is however an option that is
>    discussed in section 7.3.1. The "SSM safe reporting" problem for IPv4
>    does not exist in IPv6 multicast because the use of SSM in IPv6 is
>    well defined and uses un-contentious address ranges.
>
>==> I'm not sure what you mean by "SSM safe reporting", so it would be good
>if you could add a reference here.
>
>The CM, GWR and
>    CMTS/ER will need to be enabled with PIM-SSM, which requires the
>    definition and support for IGMPv3/MLDv2 snooping, in order to track
>    join/leave messages from the hosts. The Layer 3 next hop for the
>    hosts support MLD.
>
>==> this appears to be slightly mixed up.  If CM acts as a bridge, it won't
>need any support for PIM-SSM.  Likely CM does not even need MLD snooping
>because it should probably just pass everything through (depending on
>whether non-joined flooded multicast traffic in the ethernet segment is
>considered a problem or not).
>
>    The CMTS/ER should protect the ISP network and the other subscribers
>    against attacks by one of its own customers. For this reason uRPF and
>    ACLs should be used on all interfaces facing subscribers. Filtering
>    should be implemented with regard for the operational requirements of
>    IPv6 (ICMPv6 types).
>
>==> spell out and refer to uRPF (e.g., RFC3704).
>==> spell out what exactly you mean with the latter.  It seems you are
>vaguely saying "you should figure out which kind of ACLs are OK, in
>particular, which ICMPv6 types are really needed and should not be
>filtered".  This is rather vague, though I'm not sure whether this is the
>right place to specify what to filter or not...
>
>     DSL Modem: It can be a stand alone device, it can be incorporated
>     in the host, and it can incorporate router functionalities.
>
>     Customer Premises Router: It is used to provide layer 3 services
>     for customer premises networks. It is usually use to provide
>     firewalling functions and segment broadcast domains for a Small
>     business.
>
>==> maybe it would be worth saying that VERY often, DSL modem includes the
>capbility to act as CPE router (whether it does or not is a matter of
>configuration, i.e., whether it runs in bridged or routed mode).
>
>    C. Terminate the PVC at layer 3, each PVC has its own prefix. This is
>    the approach that seems more suitable for IPv6 and presented in 7.2.1
>    In none of these cases the CPE (DSL Modem) has to be upgraded.
>
>==> you're assumingi that the CPE would not have router functionalities, but
>would be just a bridge, yes?
>
>    B. It dynamically acquires through stateless autoconfiguration the
>    address for the link between itself and the Edge Router. This step
>    is followed by a DHCP-PD [RFC 3633] request for a prefix shorter then
>    /64 that in turn is divided in /64s and assigned to its interfaces
>    connecting the hosts on the customer site.
>
>==> the first sentence is interesting, and there were already comments about
>this.  Maybe this should be put last in this paragraph with a bit of
>rewording.  Actually, there is nothing requiring the router to do this
>stuff.. it can run DHCPv6 very well without a global address in its upstream
>interface!  So, AFAIK, the whole suggestion could be removed, but if it
>isn't, it should be put in proper perspective. (In very many places..)
>
>    The Edge Router has a /64 prefix configured for each subscriber VLAN.
>
>==> in a couple of places, you talked about PVCs, and some others, VLANs. 
>Maybe synch the terminology a bit?
>
>7.2.3.1 IPv6 Related Infrastructure Changes
>
>    In this scenario the BRAS is layer-3 aware and it has to be upgraded
>    to support IPv6.
>
>==> it was not clear to me why in this case it is required to update BRAS. 
>You know, at least based on the figures, the PPP sessions go straight
>through it, and it shouldn't be knowing anything about v6.. or...?
>
>  This allows the ERs
>    (LNSs) to aggregate the addresses handed out to the customers. In the
>    case of IPv6, an important constraint that likely will be enforced is
>    that the customer should keep its own address regardless of the ER
>    (LNS) it connects to. This could significantly reduce the prefix
>    aggregation capabilities of the ER (LNS).
>
>
>==> this seems to have the hidden assumption that v6 addresses/prefixes will
>be stable, while v4 addresses are currently dynamic.  I welcome that
>situation personally, but if you describe this as an issue, you probably
>should spell out this assumption about different deployment models.
>
>    In some cases service providers manage equipment located on
>    customers LANs.
>
>==> this appears to be mentioned a couple of times, and is IMHO redundant
>and out of scope for this draft.  If you really really want to say
>something, maybe at most "The management of equipment at customers' LANs is
>out of scope of this memo."
>
>    WLAN enables subscribers to connect to the Internet from various
>    locations without the restriction of staying indoors.  WLAN is
>    standardized by IEEE 802.11x.
>
>==> the last sentence is wrong, maybe the wrong letter?  11x is just the
>authentication part of it..
>
>   offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b
>    offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps.
>
>==> maybe mention 11g as well, because that's getting pretty popular at the
>expense of 11a..
>
>     C. Section 7 stated that current RBE based IPv4 deployment might not
>     be the best approach for IPv6. The addressing space available gives
>     the SP the opportunity to separate the users on different subnets.
>     If however, support is found for a deployment similar to IPv4,
>     and if the SP chooses to let subscribers talk amongst themselves
>     directly, then special consideration should be give to the ND
>     operation at the Edge Router.
>
>==> this should probably be a bit clearer what is the gap here, and what
>would need more work.
>
>
>
>
>
>
>editorial
>---------
>
>    As the number of devices per BB users increase exponentially
>
>==> s/users/user/ ?
>
>    range [RFC 3513] of IPv6. Other benefits of IPV6 include the
>
>==> s/IPV6/IPv6/
>
>    IPv6 where possible. Deployment of tunneling solutions are simpler,
>    easier and more economical to start the IPv6 services, as they
>
>==> s/are/is/ ?
>
>    At this point IPv6 based services are seen as a differentiator that
>...
>    this year for its ADSL and FTTH subscribers, under the name of ...
>    network and at this point does not provide connectivity to the
>
>==> when this doc ages, 'this' may no longer be accurate.
>
>    The Access Provider can deploy a Layer2 network and perform no
>
>==> s/Layer2/Layer 2/ ?
>
>    core can involve various technologies such as Ethernet, ATM and etc.
>
>==> remove "and" ?
>
>    C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS
>    in its IPv4 core it could use 6PE to forward IPv6 traffic over its.
>    In this case only a subset of routers close to the edge of the
>    network needs to be IPv6 aware. With this approach BGP becomes
>    important in order to support 6PE. Its deployment will most likely
>    leverage the Route Reflector structure used with the IPv4 deployment.
>
>==> the last sentence seems to be out of scope for this draft, and maybe
>should be removed?
>
>    is planed. As an example, 6to4 tunnels do not support IPv6 multicast
>
>==> s/planed/planned/
>
>   1. Bridged CMTS Network
>
>   In this scenario, both the CM and CMTS bridge all data traffic.
>   Traffic to/from host devices is forwarded through the cable network
>   to the ER. The ER then routes traffic through the ISP network to the
>   Internet. The CM and CMTS support some Layer-3 functionality for
>   management purposes.
>
>==> would it be easy to indent paragraphs like this by a couple of spaces
>(would increase the readability a lot)
>==> s/some/a certain degree of/ ?
>
>    Layer-3 next hop. If there is a GWR behind the CM it can acts as a
>
>==> s/can acts/can act/ (in many places)
>
>    connected to the MSO network for management functions. During the
>
>==> spell out MSO ?
>
>    Implementation work on CM/CMTS should be minimal because the only
>    significant difference between IPv4 IGMPv3 and IPv6 MLDv2 are the
>    longer addresses in the protocol.
>
>==> "difference" in singular, so s/are/is/ ?
>
>    In today cable networks the CM receives a private IPv4 address
>
>==> s/today/today's/ (a couple of times)
>
>    Security in a DOCSIS cable network is provided using Baseline Privacy
>    Plus (BPI+). The only part that is dependent on IP addresses is
>    encrypted multicast. Semantically, multicast encryption would work
>    the same way in an IPv6 environment as in the IPv4 network. However,
>    appropriate enhancements will be needed in the DOCSIS specification
>    to support encrypted IPv6 multicast. The other aspect of security
>    enhancement is mandated IPSec support in IPv6. The IPv6
>
>==> split to next paragraph at "The other aspect".
>
>    through statefull DHCPv6 [RFC 3315] and stateless DHCPv6 [RFC 3736].
>
>==> s/statefull/stateful/ (in very many places)
>
>    and PPPoE [RFC 2516]). The PPP sessions are initiated by Customer
>    Premise Equipment and it is terminated at the BRAS. The BRAS
>
>==> sessions ... it is -- singular/plural?
>
>
>    The operation of PPPoE is similar to PPPoA with the exception that
>    with PPPoE multiple session can be supported over the same PVC thus
>
>==> s/session/sessions/
>
>
>    The PPP session can be initiated by a host or by a Customer Router.
>    In the later case, once the session is established with the Edge
>
>==> s/later/latter/
>
>    It is important to note here a signifcant difference between this
>
>==> s/signif/signifi/
>
>7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model
>
>    The coexistence of the two PPP based models, PTA and LAA, is
>    relatively straight forward. It is a straight forward overlap of the
>    two deployment models. The PPP sessions are terminated on
>    different network devices for the IPv4 and IPv6 services.
>
>==> the middle sentence appears to be mostly redundant.. the only novel word
>there is "overlap" :)
>
>    Subscribers might use a set-top box that is responsible for the
>    control piece of the multicast service (does group joins/leaves).
>    The subscriber hosts can also join desired multicast groups as long
>    as they are enabled to support MLDv1 or MLDv2. If a customer premise
>    router is used then it has to be enabled to support MLDv1 and MLDv2
>
>    in order to process the requests of the hosts. It has to be enabled
>    to support PIM-SSM in order to send PIM joins/leaves up to its
>    Layer-3 next hop whether it is the BRAS or the Edge router. When
>    enabling this functionality on a customer premises router, its
>    limited resources should be taken into consideration.
>
>    The router that is the Layer-3 next hop for the subscriber (BRAS in
>    the PTA model or the Edge router in the LAA and Point-to-Point
>    model) has to be enabled to support MLDv1 and MLDv2 in order to
>    process the requests coming from subscribers without customer
>    premises routers. It has to be enabled for PIM-SSM in order to
>    receive joins/leaves from customer routers and send joins/leaves
>    to the next hop towards the multicast source (Edge router or the
>    NSP core).
>
>==> remove the extra empty line (this happened in a couple of places AFAIR).
>==> there appears to be a fair amount of duplication in these paragraphs?
>
>    On the BRAS or the Edge Router the subscriber facing interfaces have
>    to be configure to police the inbound customer traffic and shape the
>
>==> s/configure/configured/
>
>    network management tools that could provide trace-ability of the
>
>==> s/trace-/trace/
>
>          +--------+ |  +------+ |
>                     +--+Agg E | |
>          +--------+    |Switch+-+
>+-----+  |Access| +--+      |
>|Hosts|--+Switch  +-+  +------+
>
>==> figure 8.1 is a bit screwed up..
>
>    In order to maintain the deployment concepts and business models
>    proven and used with existent revenue generating IPv4 services,
>
>==> it is questionable how much revenue these BB services generated in
>highly competed markets, and it's irrelevant to this draft in any case, so
>suggest rewording /existent revenue generating/existing/
>
>This deployment
>    types do not fit in the typical Hot Spot concept but they rather
>    address fixed customers.
>
>==> in this kind of document, "address" in this context may be slightly
>confusing, so rewording it might be useful.
>
>
>    The IETF draft [IPv6 over 802.11] mentions some of the concerns
>    related to running IPv6 multicast over WLAN links.  Potentially
>    these are same kind of issues when running any Layer3 protocol
>    over a WLAN link that has a high loss-to-signal ratio, certain
>    frames that are multicast based are dropped when settings are not
>    adjusted properly.
>
>==> s/The/An/
>==> s/certain/where certain/ ?
>
>[RFC 3041]
>    T. Narten and R. Draves, "Privacy Extensions for Stateless Address
>    Autoconfiguration in IPv6," RFC 3041, April 2001.
>
>==> s/[RFC 3041]/[RFC3041]/ (for consistency)
>
>[6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4
>    Clouds with BGP:, draft-ietf-ngtrans-bgp-tunnel-04.txt, July 2002
>
>==> the latest version is draft-ooms-v6ops-bgp-tunnel (AFAIR)
>
>    Savola, P. "IPv6 Multicast Deployment Issues",
>    draft-savola-v6ops-multicast-issues-03.txt, February 2004
>
>==> draft-mboned-ipv6-multicast-issues now
>
>--