Re: Take ISP BB scenarios as WG document?

[Salman Asadullah <sasad@cisco.com>]

At 12:04 PM 1/31/2005 +0200, Pekka Savola wrote:
> On Fri, 21 Jan 2005, Pekka Savola wrote:
> > "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.
>
> (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.

Thanks for your recommendation and detailed feedback again !

We will review all the feedback (yours and others) we have received and
integrate in our next revision.

We will get back to you for any clarifications off the list.

Regards,
Salman


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