Subject: Take ISP BB scenarios as WG document?

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Jan 2005 09:25:09 +0200 (EET)

Hi,

(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: "Alan Chang" <[email-masked]>
Date: Fri, 21 Jan 2005 16:32:57 +0800

Hi,

I have read 01 revision and just focus what I'm interested in 02.

At page 26,

   If a Customer Router is present:

   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.

Does this mean the router can do stateless autoconfiguration?
From what I can remember, a node can be only a host (receive RA) or a router
(send RA).

Thanks.

-Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pekka Savola
Sent: Friday, January 21, 2005 3:25 PM
To: [email-masked]
Subject: Take ISP BB scenarios as WG document?

Hi,

(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-scen
arios-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.

(hat off)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jan 2005 11:36:39 +0100

I think this is useful work
    Brian

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 22 Jan 2005 16:04:06 +0900

>>>>> On Fri, 21 Jan 2005 16:32:57 +0800, 
>>>>> "Alan Chang" <[email-masked]> said:

>> From what I can remember, a node can be only a host (receive RA) or a router

(I've not gone through the document, so I may miss something in the
context, but) isn't the autoconfigured address (between the "Customer
Router" and the "Edge Router") a link-local address?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

p.s. I happen to find a typo in the original text: in the sentence
beginning with "This step is ...", "shorter then /64" should be
"shorter than /64". (i.e., s/then/than/)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 22 Jan 2005 21:36:19 +0100

I agree, this work should be a WG item.

I'm still trying to find some time to add PLC considerations, hopefully in
1-2 weeks maximum.

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 21 Jan 2005 09:25:09 +0200 (EET)
> Para: "[email-masked]" <[email-masked]>
> Asunto: Take ISP BB scenarios as WG document?
> 
> Hi,
> 
> (co-chair hat on)
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Alan Chang" <[email-masked]>
Date: Mon, 24 Jan 2005 12:02:09 +0800

Hi,

I think the term "stateless autoconfiguration" refers to RFC 2642.

My questions are:
If yes, does this mean the router can do stateless autoconfiguration?
If no, how does a CPE router set its address and default route except using
manual configuration.

Thanks.

-Alan 

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
Sent: Saturday, January 22, 2005 3:04 PM
To: Alan Chang
Cc: [email-masked]
Subject: Re: Take ISP BB scenarios as WG document?

>>>>> On Fri, 21 Jan 2005 16:32:57 +0800, "Alan Chang" 
>>>>> <[email-masked]> said:

>> From what I can remember, a node can be only a host (receive RA) or a 

(I've not gone through the document, so I may miss something in the context,
but) isn't the autoconfigured address (between the "Customer Router" and the
"Edge Router") a link-local address?

					JINMEI, Tatuya

p.s. I happen to find a typo in the original text: in the sentence beginning
with "This step is ...", "shorter then /64" should be "shorter than /64".
(i.e., s/then/than/)

					JINMEI, Tatuya

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 24 Jan 2005 16:29:33 +0100 (CET)

Hi All,

On Fri, 21 Jan 2005, Pekka Savola wrote:

> Hi,
>
> (co-chair hat on)
>
> The authors have asked if the following document would be adopted as WG item:
>

It is a very good architectural review about the IPv6 deployment scenarios 
for Access networks. I recommend to move forward.

However I have question regarding the document or IPv6 access architecture 
itself.

In the 7.2.3.1 section the document states that BRAS Layer 3 aware in the 
L2TP Access Aggregation (LAA) Model scenario. I don't really understand 
why BRAS should be Layer 3 aware (or IPv6 enabled).

1. The CPE initiates the connection to BRAS via PPPoA or PPPoE. 
2. The PPP starts the negotiation phase, but since the the PPP belongs to 
a different domain the PPP session forwarded and terminated at the LNS via 
L2TP. IPCP and IPV6CP done between CPE and LNS.
3. The responsibility of the BRAS only to encapsulate the PPP packets 
to L2TP packets and forward to LNS.
4. LNS decapsulates the L2TP and PPP protocol and the final protocol (in 
the case of IPv6 - the IPv6 packet)
5. If BRAS gets a packet encapsulated into an L2TP tunnel it has to remove 
the L2TP tunnel header and  encapsulate into a PPPoE or PPPoA 
packet the rest of the packet and forward to the CPE.

I don't see any L3 awareness of BRAS (or LAC) here. Where I miss a point?

Kindest Regards,

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

---

From: Gert Doering <[email-masked]>
Date: Tue, 25 Jan 2005 13:57:22 +0100

Hi,

> If no, how does a CPE router set its address and default route except using

Existing router implementations can indeed do stateless autoconfiguration.

cisco25(config-if)#ipv6 address ?
  WORD                General prefix name
  X:X:X:X::X          IPv6 link-local address
  X:X:X:X::X/<0-128>  IPv6 prefix
  autoconfig          Obtain address using autoconfiguration

but the question remains "how useful is this feature?".  

Yes, the router can autoconfigure its "external" IPv6 address, but 
it cannot use stateless autoconfiguration to setup his "internal"
network interface(s), and thus provide stateless autoconf to 
network clients.  

For that part, one could use DHCP prefix delegation, though, and with
the combination of both, you can get a fully autoconfiguring IPv6 (CPE)
router.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  71007  (66629)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Gert Doering <[email-masked]>
Date: Tue, 25 Jan 2005 14:03:29 +0100

Hi,

> I don't see any L3 awareness of BRAS (or LAC) here. Where I miss a point?

Eventually it might be desireable to run L2TP over IPv6.  

But I'm not sure whether this is what the original authors aim at.

Gert Doering
        -- NetMaster

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 25 Jan 2005 15:08:09 +0100 (CET)

> Eventually it might be desireable to run L2TP over IPv6.
Hi,
 	I think this is an option if Network Access Providers upgrading 
their networks to support IPv6. Thanks for the comment.

Regards,

 	Janos Mohacsi

---

From: Adeel Ahmed <[email-masked]>
Date: Tue, 25 Jan 2005 13:26:38 -0600

Hi Alan,

Thanks for reviewing the document.

Yes, the customer router should be able to do stateless autoconfiguration 
as already pointed out by Gert Doering.

Kind Regards,
Adeel Ahmed.

---

From: Adeel Ahmed <[email-masked]>
Date: Tue, 25 Jan 2005 13:30:49 -0600

Hi Jinmei,

The autoconfigured address on the link between Customer Router and Edge 
Router is intended to be a global IPv6 address.

We will also correct the typo you pointed out. Thanks for reviewing this 
document and providing feedback.

Kind Regards,
Adeel Ahmed.

At 04:04 PM 1/22/2005 +0900, JINMEI Tatuya /

---

From: Adeel Ahmed <[email-masked]>
Date: Tue, 25 Jan 2005 15:34:36 -0600

Hello Janos, Gert,

Section 7.2.3.1 does state that the L2TPv2 tunnel between the LAC and LNS 
could run over IPv6 or IPv4.

Obviously we would like to encourage providers to upgrade their networks to 
support IPv6, this will also enable them to run IPv6 IGP between the BRAS 
and the Edge Router.

Thanks for reviewing this document and providing feedback.

Kind Regards,
Adeel.

---

From: "Alan Chang" <[email-masked]>
Date: Wed, 26 Jan 2005 10:14:59 +0800

Hi Gert & Adeel,

Thanks for your detail explanation.
I know the mechanism of stateless autoconfiguration and DHCP-PD.

I just wonder if this (a node can send/receive RA simultaneously) obeys any
RFC.
Thanks.

-Alan

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Tuesday, January 25, 2005 8:57 PM
To: Alan Chang
Cc: 'JINMEI Tatuya / ?????F?v'; [email-masked]; [email-masked]
Subject: Re: Take ISP BB scenarios as WG document?

Hi,

On Mon, Jan 24, 2005 at 12:02:09PM +0800, Alan Chang wrote:
> If no, how does a CPE router set its address and default route except 
> using manual configuration.

Yes, the router can autoconfigure its "external" IPv6 address, but it cannot
use stateless autoconfiguration to setup his "internal"
network interface(s), and thus provide stateless autoconf to network
clients.  

For that part, one could use DHCP prefix delegation, though, and with the
combination of both, you can get a fully autoconfiguring IPv6 (CPE) router.

Gert Doering
        -- NetMaster

---

From: "Alan Chang" <[email-masked]>
Date: Wed, 26 Jan 2005 10:20:38 +0800

Hi,

I think the work is solid and valuable for deployment of IPv6 broadband
access networks.

-Alan

-----Original Message-----

Hi,

(co-chair hat on)

(hat off)

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 26 Jan 2005 13:25:13 +0100 (CET)

Dear All,
 	I strongly recommend to adopt this document as a WG document. It 
has lots of important architectural insights.

 	Regards,

Janos Mohacsi

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Jan 2005 14:54:58 +0200 (EET)

Hi,

On Tue, 25 Jan 2005, Adeel Ahmed wrote:
> support IPv6, this will also enable them to run IPv6 IGP between the BRAS and 
> the Edge Router.

Maybe the document needs to spell out a bit more for which reasons 
IPv6 support is needed in those pieces of equipment.  (In this case, 
the optional L2TP over IPv6?)

That way, the reader can better judge whether IPv6 is really, really 
needed in their particular case right now, or longer down the road.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 31 Jan 2005 12:04:07 +0200 (EET)

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

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?

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

---

From: Salman Asadullah <[email-masked]>
Date: Mon, 31 Jan 2005 11:19:33 -0800

At 12:04 PM 1/31/2005 +0200, Pekka Savola wrote:
>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

>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:
>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.
>
>   this year for its ADSL and FTTH subscribers, under the name of ...