[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft on ISP broad-band deployment scenarios
Pekka,
First we would like to thank you for the detailed comments and suggestions
made on this draft. They are very appreciated!
Please find in line our response and questions. We are looking forward to
your response.
Regards,
Chip
At 01:17 PM 8/24/2004 +0300, Pekka Savola wrote:
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.
@@@
Pekka, to put this document in perspective, here are some elements of our
original intent:
- focus on production type deployments. We did not intend to discuss tunneling
unless it is the only alternative currently available due to limitations of
a given access
technology (cable).
- present the possible deployment scenarios and identify the major elements
for each one in terms of enabling IPv6 services.
- highlight changes that have to be made in the deployment process and some
issues that the SP has to keep in mind while planning such a deployment.
As you can see, the document is rather large as it is so we did not consider
going into more detail then we already did. We did want however to underline
topics that should be kept in mind during deployment, even items that should be
further investigated. We believe that this approach is what you mentioned above
but maybe we need to highlight more some aspects of the document. Could you
clarify
your comment above so that we make sure we properly understand the changes you
suggest? We would like to make this work as useful as possible.
@@@
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?
@@@
This is a good point that we should elaborate on. It is also true that
while in some cases simple provisioning is available (use of autoconfig or
DHCP-PD) in others there might not be a solution available today. In such
cases,
based on your comment above, it looks like you would like to see us clearly
identify such limitations and possibly open the door for further work. Is this
correct?
The tunnel case might be an unfortunate example as it might be a temporary
solution
until an updated DOCSIS allows a more practical approach.
@@@
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.
@@@
Again, it is a case very specific to the current state of Cable access.
Nevertheless
we could probably offer more detail for this case. For example, one
solution would
be to have the box that is doing the NAT for the user also terminate the
tunnel.
This is another point that we need to clarify however, the Gateway Router
(GWR) can
be SP owned but also it can be customer owned and in that case it would
reflect a
customer deployed equipment like a box that does NAT for v4.
@@@
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.
@@@
Before writing the document we actually discussed this topic amongst
ourselves. Our
thought is that some items might seem similar between sections but they
might not be
in all their details. Moreover, we did want to provide each Access
Technology section
a certain completeness and independence in order to make the sections more
readable,
without having to send the reader very far through referencing. Even if we
were to compress
the repeated subsections we doubt that the document will shrink to only 30
pages.
We received pro and con arguments on this topic so for now we would like to
keep it
in this format as it might even be easier to further flesh out some
sections based on the
feedback received. As the document evolves we can revisit the formatting if
it proves
advantageous.
@@@
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? :-)
@@@
Agreed, good idea, we will work on this item.
@@@
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?
]]
@@@
We will add some clarification in where the snooping is applied. Your
comment is valid, the
bridged-mode cable modem systems act similar to the bridged-mode DSL.
@@@
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.
@@@
Agreed, we will add this point.
@@@
==> 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 would be worth pointing out that in this document we went not only for
describing some scenarios already deployed but also some that could be
deployed.
We wanted to present as complete of a list as possible.
@@@
...
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).
@@@
We will underline this point even thought it might be apparent from the
addressing sections.
@@@
==> actually, the current recommendation (RFC 3177) is even larger: a /48
per home :-). This should probably be mentioned..
@@@
True. We sort of touched on that with our DHCP-PD recommendations. There
are also
SPs that might assign prefixes between /48 and /64 with the intent of charging
for address space.
@@@
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.
@@@
These are deployment issues that we could elaborate a bit more on. The
provider usually
is not responsible for the additional equipment added by the customer and
under the
constraints of a service deployment that is limited by the current state of
DOCSIS it is likely that
the provider will have to provide a new device to the subscriber. We will
add a note on this
topic.
@@@
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?
@@@
The CM will still be a Layer 2 bridge and will bridge IPv4 and IPv6
traffic. Therefore the CM
does NOT need to support IPv6. Changes to the DOCSIS specification will
need to be made
in order for the CM to support IPv6 unicast and multicast traffic.
@@@
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.)
@@@
We will discuss provisioning in more detail and hopefully this question
will be answered in
that context. It is worthwhile to note that we don't advocate the use of a
specific tunneling
mechanism for this temporary solution for Cable Networks. We will more
clearly identify
items to be considered when making the selection for the tunnel but the
selection will
be left to the person planning the deployment.
@@@
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....
@@@
This is a valid point. We need to provide more context to the statement,
but it is worthwhile
to note that it is a current practice in IPV4 networks where business
customer do run RIPv2
between the CM/GWR and the CMTS. Those customer routes are redistributed in
the ISP's IGP.
@@@
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?
@@@
We probably used too few words. We wanted to say that while configuring IPv6
ACLs, one has to make sure that the ACLs do not stop IPv6 specific controll
plane traffic (like ND, DHCP-PD etc).
@@@
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...
@@@
Same comment as above.
@@@
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.
@@@
Yes, we are aware of this work and we will reference it. We didn't really
want to get into a model other then SSM despite the fact that there are
feasible
ways for ASM. The idea was that SPs will be more inclined to go for an SSM
model
at first (maybe even on a longer run) because of the business model of content
delivery (video/audio). Probably we should however have a discussion on the
topic.
Do you see the ASM discussion important beyond referencing the draft you
mentioned?
@@@
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?
@@@
Could you please clarify this comment?
@@@
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.
@@@
Why would you see it as a bad practice having the router acquire via stateless
autoconfig an address for the uplink to the provider? We should probably
discuss
all options for completeness purposes.
@@@
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.
@@@
We believe that such a feature is important to all SPs that deploy mcast
services
for video and audio streaming. Maybe this is not critical at the start of
the service
but would be when the service offering solidifies. Such a feature offers more
granularity in controlling and charging a customer then the key proposal.
With the key
proposal the user would have access to possibly a predefined package of
channels while
with proper MLD AAA the user can select any channel, any time and be
charged only for
that use.
@@@
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..
@@@
We referenced this work repeatedly in the draft and that in itself would
suggest that
it would be good to recognize the authors in the acknowledgments section.
Good point.
@@@
@@@
We will include all editorial comments you made below.
@@@
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