[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call draft-ietf-v6ops-bb-deployment-scenarios*
On Mon, 6 Jun 2005 fred@cisco.com wrote:
This note starts the WG Last Call for comments on
"ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman
Asadullah, 31-May-05,
<draft-ietf-v6ops-bb-deployment-scenarios-02.txt>
I did not read the document carefully, because I've already read it
many times. However, I think there are still a couple of (relatively
minor) issues which require one revision. However, I'd like to keep
it at one, and try to get this out for IESG evaluation before Paris
IETF, so we could discuss comments (if any) before then.
substantial
-----------
==> There have been at least a couple of recent scientific papers
describing some shortcomings in IPv6 BB deployment. I don't think
these are available in the web, or are very credible, but I think the
authors need to read them and understand why the people felt that
there was a shortcoming (and proposed their own fixes). While some of
these may be true, most are probably not -- those which are not could
probably be more clearly described in this document so we can point
folks here. I'll send a couple of pointers off-list.
==> during the 01 -> 02 revision, acknowledgements and contributors
sections went missing, please restore these.
If there is no Customer Router all the hosts on the subscriber site
belong to the same /64 subnet that is statically configured on the
Edge Router for that subscriber PVC. The hosts can use stateless
autoconfiguration or stateful DHCPv6 based configuration to acquire
an address via the Edge Router.
....
(In gap analysis)
This approach changes the provisioning methodologies that were used
for IPv4. Static configuration of the IPv6 addresses for all these
links on the Edge Routers or Access Routers might not be a scalable
option. New provisioning mechanisms or features might need to be
developed in order to deal with this issue.
==> this is related to the point I was making earlier, but I think it
should still be made much more explicit. How about rewording:
If there is no Customer Router all the hosts on the subscriber site
belong to the same /64 subnet that may be statically configured on the
Edge Router for that subscriber PVC. The hosts can use stateless
autoconfiguration or stateful DHCPv6 based configuration to acquire
an address via the Edge Router.
However, as manual configuration for each customer is a provisioning
challenge, implementations are encouraged to develop mechanism(s) which
automatically map the VLAN (or some other customer-specific information)
to an IPv6 subnet prefix, and advertise the customer-specific prefix
to all the customers with minimal configuration.
(and something similar in the gap analysis.)
...
10.2 Deploying IPv6 in IPv4 PLC/BPL
The most simplistic and efficient model, considering the nature of
the PLC/BPL networks, is to see the network as a point-to-point one
to each customer. Even if several customers share the same physical
media, the traffic is not visible among them because each one uses
different channels, which are in addition encrypted by means of 3DES.
Furthermore, if required, VLANs could also be used, as already
described for the Ethernet case.
==> PLC sections do not describe at all how IPv4 is done (compare to the
other sections). Does it use PPP (which variant)? Something like
xDSL/Ethernet point-to-point models (which variant)? For consistency and
better understand how PLC works, this should be included.
==> You mention VLANs, but while VLANs are well defined for Ethernet, I'm
not sure what PLC VLANs are? Maybe PLC is emulating Ethernet the same
way that 802.11 is, but the document just isn't clear enough about
this?
B. 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. [...]
==> shouldn't you say something like "the first router outside of the
customer premises" instead of Edge Router? (or something a bit more
compact.) As it is, at least in PLC and also in other technologies, what
you call "Edge Router" is not necessarily the CPE's next-hop (in PLC, it
seems to be the head-end), and DHCPv6-PD has to be done at that next-hop,
right?
.....
semi-editorial
--------------
If the end customer receives a private IPv4 address and needs to
initiate a tunnel through NAT, techniques like 6to4 may not work
since they rely on Public IPv4 address. In this case, unless the
existing CPE supports protocol-41-forwarding, the end user might have
to use tunnels that can operate through NATs (such as Teredo tunnel
[30]).
The customer has the option to initiate the tunnel from the device
(GWR) that performs the NAT functionality, similar to the GWR
scenario discussed in section 5.1. This will imply HW replacement or
SW upgrade and a native IPv6 environment behind the GWR. Most GWRs
support protocol-41-forwarding which means that hosts can initiate
the tunnels in which case the GWR is not affected by the IPv6
service.
==> you should provide a reference to protocol-41-forwarding.
==> The last sentence of the second paragraph seems badly placed (and
worded). The second paragraph seems to be about GWR v6 support, while the
first paragraph is about host tunneling; the sentence should be moved and
reworded to the first paragraph.
In inter-domain deployments, Multicast Source Discovery Protocol
(MSDP) [22] is an important element of IPv4 PIM-SM deployments. MSDP
is meant to be a solution for the exchange of source registration
information between RPs in different domains. This solution was
intended to be temporary. This is one of the reasons why it was
decided not to implement MSDP in IPv6 [32].
For multicast reachability across domains, Embedded RP could be used.
Despite its shortcomings, MSDP provides additional flexibility in
managing the domains that may not be matched with the protocols
available in IPv6 today. The value of such flexibility is still
under evaluation.
==> I'd maybe reword the latter paragraph to be more positive, because there
is not going to be MSDP for v6 (and IMHO there is no use portraying MSDP
in a light which might result in the ISPs start asking for it), e.g.:
For multicast reachability across domains, Embedded RP can be used.
As Embedded RP provides roughtly the equal capabilities but in a slightly
different way, the best management practices for ASM multicast with
embedded RP still remain to be developed.
....
While deploying IPv6 in the above mentioned WLAN architecture, there
are three possible scenarios as discussed below.
A. Layer 2 Switch Between AP and Edge Router
B. Access Router Between AP and Edge Router
==> these options are not exclusive and could possibly be worded a bit
better; the critical thing here seems to be where the customer's traffic is
terminated at L3. In A, it's at Service Provider; In B, it's at Access
Provider. (For example, you can certainly deploy L2 switches in B before
the access router :)
Just for information/clarification, often the PLC/BPL access networks
use hybrid layer 2 combinations either with PLC/BPL in the medium
voltage, point to point links, wireless links, satellite, etc., but
once more, this seems to be out of the scope of this document, as
those means are transparent, for the purpose of this document, to the
last half mile access network deployed with PLC/BPL.
==> I'm having difficulty understanding the relevance of this paragraph.
Remove or reword?
10.2.1 IPv6 Related Infrastructure Changes
In this scenario the RPT is layer 3 unaware, but not the Head End,
which should be upgraded to support IPv6. Similarly other devices
which have to be upgraded to dual stack: Hosts, RCPE and Edge Router.
==> just say something like:
In this scenario only the RPT is layer 3 unaware, but the other devices
have to be upgraded to dual stack: Hosts, RCPE, Head End, and
Edge Router.
10.2.3 Routing
If no routers are used on the custmer premises, the HE can simply be
configured with a default route that points to the Edge Router. If a
router is used on the customer premises (RCPE) then the HE will run
an IGP to the ER such as OSPFv3, IS-IS or even RIPng. [...]
==> whether or not there is RCPE seems independent of whether HE
should run a routing protocol towards ER? Assuming all the customers
at HE would come from the same aggregate route, static routing between
HE and ER could work just fine, even if there were RCPE(s).
(Obviously, this doesn't scale well if all the customer prefixes would
need to be statically routed, but I don't think it's exactly as black
& white as the sentence seems to state.)
10.6 IPv6 Network Management
There are no differences in terms of network management if compared
with the already described Ethernet case.
==> are you sure? In ethernet case, we have well-defined MIBs. Do the same
MIBs exist in PLC equipment as well? Do the different PLC setups require
different kind of MIBs?
[5] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
==> this could probably be replaced with [30], because mech-v2 is already in
RFC-ed queue.
editorial
---------
Note: there have been dozens of typos introduced between -00 and -02;
most of these can be reasonably easily spotted if you run the docs
through 'wdiff' (for example, in section 1, "ISP" changed to "IP".)
I've not tried to list these here.
- in the abstract, "for completion purposes" -> "for completeness"
- in the abstract, there are a lot of abbreviated terms which either need to
be spelled out or removed. IMHO, we don't need to list all of these in the
abstract; for example, just mention DSL, ethernet and cable as examples
of BB technologies covered.
- in section 4.2, s/Layer3/Layer 3/
- in section 4.2, make "RFC4029" a reference.
- in section 5.1, there were a number of abbreviated terms like NAP, SP,
GWR, etc. These should be spelled out. I'd suggest including a very short
"common terminology" subsectin 1.1, where you spell these out in one line
per each.
- in section 5.1 and elsewhere, you've used [[2], [3]] when using multiple
references; please use normal ()'s instead, e.g., ([2], [3])
- in section 5.1 and 5.2, s/Tunnels-Customers/Tunnels - Customers/
- in section 5.2, s/Public/public/
- in section 5.2, create an explicit reference for [Tunnel through IPsec]
- in section 9.1, s/IEEE 802.11a offers/IEEE 802.11a/g offer/
- in section 10.1,
Head End (HE): It is the router that connects the PLC/BPL access
network (the power grid),
==> remove "It is" (from here and subsequent terms) to be better in line
with the style of the rest of the document?
- in section 10.1, "Often is a bridge" -> "It is often a bridge"
- in figure 10.1, just replace "HE" with head end (it's short enough) ?
- in section 10.2.3, s/custmer/customer/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings