Subject: WG Last Call draft-ietf-v6ops-bb-deployment-scenarios*

From: [email-masked]
Date: Mon, 6 Jun 2005 06:00:29 -0700 (PDT)

Folks

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>

It may be found on

	 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-02.txt

The document's proposed status is Informational.

Please review the document carefully, and send your feedback to the
list. Please also indicate whether or not you believe that this
document is ready to go to the IESG.

This Last Call will end two weeks from today at Close of Business PDT.

Thanks,

Fred

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Jun 2005 10:40:40 +0300 (EEST)

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

---

From: Salman Asadullah <[email-masked]>
Date: Wed, 22 Jun 2005 11:44:31 -0700

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:
>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
>-----------
>
>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.
>
>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?
>
>==> 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.)
>
>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.
>
>references; please use normal ()'s instead, e.g., ([2], [3]) - in section 
>5.1 and 5.2, s/Tunnels-Customers/Tunnels - Customers/