[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call draft-ietf-v6ops-bb-deployment-scenarios*
Thanks for the comments Pekka.
We'll address the comments and get in touch with you offline if
needed.
Please send those couple of pointers you mentioned, to us.
Regards,
Salman
At 10:40 AM 6/17/2005 +0300, Pekka Savola wrote:
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