[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft on ISP broad-band deployment scenarios
Hi,
Sorry for delay in sending in a few personal comments...
On Thu, 19 Aug 2004, Pekka Savola wrote:
> Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a
> lot of work in a very short time and produced a really extensive
> scenarios document discussing the IPv6 deployment scenarios for
> broadband (DSL, cable, etc.).
A couple of general observations:
0) is the document aiming to only describe the scenarios, or is the
goal to also provide analysis where potential gaps have been
identified, and where e.g., a tunneling mechanism would be needed? If
the latter, it probably needs to be expanded a bit.
1) the doc seems to be lacking large-scale v6 enablement
considerations, w/o customer interaction and manual config. That is,
at least in section 5, I got the impression that for the customer to
enable v6 over a tunnel, the customer and the ISP would have to do
some manual configuration. This seems unscalable and unfeasible.
Shouldn't we try to have mechanisms where the nodes automatically
detect if IPv6 is available through a tunnel, and activate it if so?
2) the document seems to make some assumptions e.g., when it specifies to
use 6to4 e.g., for cable. Are all of the networks using public v4
addresses? What if the customer has deployed a NAT box so that the public
address is consumed by that box? Further, I'm not sure whether the
situation where the customer has deployed some equipment has been considered
throughout the document.
3) there's duplicated text in very many of the sections which applies
to about all the scenarios, for example:
Depending on the design of the edge portion of the ISP network, some
Edge Routers might have to run iBGP for IPv6. In this case it is
expected that two peer sessions are established between the Edge
Router and a pair of redundant Route Reflectors.
.. instead of duplication, would there be a good logical place to put
all the "generic considerations" wrt. access networks (e.g., about
prefix summarization, etc.) into a dedicated section? -- And just
describe the access-network -specific issues under the access
network.. that might remove duplicate text and make the document more
concise.
This might force the reader to think about the generic issue and how they
map to the specific access network scenario a bit more, but it would
probably improve the readability and correctness.
The tradeoff of course is that each access network description would no
longer be readable on its own without reading the rest, but that should
probably be acceptable ... as it is, there seems to be significant overlap
with the sections, especially with DSL, Ethernet, and WLAN, but a bit
otherwise as well.
If that was done, it might be possible to push down from 60 pages to
20-30 pages, and even increase the amount of unique content in the
process.
4) the doc could probably include a summary section just before
Acknowledgements (btw, Security Considerations section needs to be
added), which could list action items for the IETF standardization (if
any gaps were identified), or some other summary of issues which still
need to be taken care of -- or is it just a matter of implementation
and deployment? :-)
substantial
-----------
5.2.1 Deploying IPv6 in a Bridged CMTS Network
In IPv4 the CM and CMTS act as Layer-2 bridges and forward all data
traffic to/from the hosts and the ER. The hosts use the ER as their
Layer-3 next hop. If there is a GWR behind the CM it can acts as a
next hop for all hosts and forward data traffic to/from the ER.
==> doesn't this seem in conflict with 5.2.1.3 which says that the equipment
is doing a significant amount of snooping? How much of this is required to
support v6 bridging? The doc should be very clear where this support is
needed...
[[ I wrote the below before I read 5.2.1.3:
Do the bridged-mode cable modem systems use something like the
bridged-mode DSL to make it look like that the customers share the LAN and
are bridged, but actually aren't? (see draft-melsen-mac-forced-fwd-02.txt)
If yes, that snooping functionality needs to be upgraded to v6. If not,
does that mean that all the ARP/ND traffic is flooded to everyone, and
ARP/ND spoofing/hijacking is trivial?
]]
semi-editorial
--------------
2. IPv6 Based BB Services
At this point IPv6 based services are seen as a differentiator
that enables SPs to take advantage of the large IPv6 address
space and allows them to better position themselves against the
competition. Another reason of IPv6 being very popular in some
countries is the government driven financial incentives and
favorable legislation to the ISPs who are deploying IPv6.
==> one thing possibly worth mentioning here is that some ISPs might see
IPv6 as a way to drive down customer support costs (I've heard this from one
SP at least), because NATs which break apps and in general behave in strange
ways would disappear.
==> maybe add after this paragraph something along the lines:
Below, we illustrate a few deployed cases for IPv6-based BB services.
It is not an exhaustive list.
...
It should be noticed that
where a home user generally gets a single IPv4 address (dynamic
or static), the IPv6 service provides a full subnet (/64).
==> actually, the current recommendation (RFC 3177) is even larger: a /48
per home :-). This should probably be mentioned..
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's site.
==> is this necessarily this simple? What is the cable operator already has
deployed v4-only GWR for other purposes? Does it need to be upgraded to
dual-stack? Or what if the user has added a box of its own, e.g., a
firewall/NAT/wireless router? I guess it again needs to be upgraded.
4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS support
IPv6
In this scenario there is a standalone GWR connected to the CM.
Since the IPv6 functionality exists on the GWR the CM does not need
to be dual-stack. The CMTS is upgraded to dual-stack and it can
incorporate the ER functionality. This scenario may also require HW
and SW changes on the GWR and CMTS.
==> I don't really understand the cable architecture very well, so this may
be an obvious point .. but I don't see how just upgrading GWR and CMTS could
be enough, if the CM doesn't support v6? Does that require some sort of
tunneling, or..? But in that case, v6 support shouldn't be needed in CMTS
in the first place?
5.2.2.2.4 Routing
For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route
can be manually configured on the GWR with the IPv6 address of the ER
as the next hop. A similar IPv6 route will need to be configured on
the ER pointing back to the GWR at customer site.
==> does that require manual configuration at ER for each customer?
Hopefully not! (AFAICS, there's nothing needed for 6to4, but manual
tunneling would need it.)
If using maunual tunneling, the GWR and ER can use static routing or
they can also configure RIP-ng. The RIP-ng updates can be transported
over a manual tunnel, which does not work when using 6to4 tunneling.
==> is there a particular usage case for RIP-ng over cable modem to the GWR?
I can't see any valid scenario for doing so....
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).
==> I don't understand what you mean by the last sentence?
5.2.2.5.4 Routing
The CM/GWR can use a static defaul route pointing to the CMTS/ER or
it can run a routing procotol 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.
==> are there really any customers or ISPs which would be allowing running a
dynamic routing protocol across the cable modem fabric? I'd be surprised to
see this...
In IPv6, with [RFC3306] there is a better mechanism available for ASM
IPv6 address allocation than in IPv4. This reduces the problems of
using ASM in IPv6 to some degree. On the other hand, the protocol MSDP
standard with PIM-SM is not currently defined for IPv6. In general,
SSM for IPv6 is also considered to be the protocol to promote for the
majority of future interdomain IP multicast applications and it is
less complex solution to operate.
==> you might want to check out and refer to
draft-ietf-mboned-ipv6-multicast-issues-00.txt which discusses exactly this
issue, and solutions if you'd still need ASM.
6.2.1 POINT-TO-POINT MODEL
==> this model has the built-in assumption that ATM is used as
point-to-point. Is this strictly necessary, or could you just use any other
media as well?
If a Customer Router is present:
[...]
- it dynamically acquires through 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.
==> s/present/present, either:/
==> the router doesn't autoconfigure the address unless it has been
configured to act as a host on its upstream interface... which would
probably be bad practice.. so either the upstream link has no global
addresses (which would be OK), or it could just use a subnet from the
DHCP-PD prefix.
MLD authentication, authorization and accounting is usually
configured on the edge router in order to enable the ISP to do
controll the subbscriber access of the service and do billing for
the content provided.
==> the non-standardized methods for adding AAA to IGMP/MLD have been
proposed, but they're generally considered very broken models, and I'm not
sure how much text we should have about them, at least without disclaimers.
The right thing to do would probably be to encrypt the data, and provide the
decryption key only to those who pay (or whatever for the stream.
9. Acknowledgements
==> would it be appropriate to refer to the earlier work by C. Mickles et
al., here? Depends on how much it has influenced your work, I guess..
editorial
---------
==> some lines go over the maximum of 72 chars/line
==> you should spell out the acronyms when they're first used like "Service
Provider (SP)".
==> there are a couple of non-ascii characters, like the apostrophe in
"IPv6's" in the second paragraph of section 1, in 2nd para of sect 2, etc.
that are currently deployed, and discussed in this draft. In this
==> s/draft/memo/ (also later in section 3, and later on)
[[ "memo" is a more generic term which also applies when/if a draft becomes
RFC ]]
For instance in Japan, Cable TV and dish services are not very
==> s/Cable/where Cable/
Provider's network namely Cable/HFC, BB Ethernet, xDSL and WLAN.
==> s/network/network,/
This drafts briefly discusses the other elements of a provider's
==> s/drafts/memo/
Following important pieces such as:
==> reword to something like: "We'll consider at least the following
important steps:" ?
IPv6 deployment is signficant.
==> s/sign/signi/
A. IPv6 Tunneling: As a temporrary solution, the Access Provider can
==> s/rrary/rary/
least impact on the Access Provider network however it is not suitable
==> s/however/, however,/
C. MPLS 6PE Deployment: If the Access Provider is running MPLS in its
IPv4 core it could use 6PE to forward IPv6 traffic over its MPLS core.
==> add reference to the 6PE draft?
In an IPv4 routed CMTS network the CM still acts as a Layer-2
device and bridges all data traffic between its Ethernet interface
and cable interface
==> the line ended abruptly, is something missing or was this just an
unnecessary line break?
When deploying IPv6 in a routed CMTS network, the CM will still acts
==> remove "will" or s/acts/act/
In this scenario the CMTS isupgraded to dual-stack to support IPv4
==> s/is/is /
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
6to4 tunnel
==> s/6to4/IPv6-over-IPv4/ (to be more generic..?)
messges on its downstream interface which will be used by the hosts to
==> s/mess/messa/
In this case the cable operator can offer IPv6 services to it's
==> s/it's/its/ (similar elsewhere)
The CM/GWR can use a static defaul route pointing to the CMTS/ER or
==> s/defaul/default/
enhance security. The Privacy extenssions for autoconfiguration should
==> s/extens/exten/
valid customer controll traffic such as: Router and Neighbor
==> s/controll/control/
Router for that subsrciber's PVC. The hosts can use stateless or
==>s/rc/cr/
DHCP-PD should be planned in a maner that allows as much summarization
==> s/maner/manner/
should be planned in a maner that allows maximu summarization BRAS.
==> same here, + s/maximu/maximum/
[[there were a large number of other typos I didn't correct, as a lot
of them were duplicated across the document]]
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings