FW: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt

[Fred Baker <fred@cisco.com>]

FYI. Margaret's original message seems to have not made it to v6ops,  
or at least through it to me and reportedly several of you.

-----Original Message-----
From: Margaret Wasserman
Sent: Thursday, May 25, 2006 11:16 AM
To: 'v6ops@ops.ietf.org'; 'iesg@ietf.org'
Subject: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt


Hi All,

While I was in a mood to review v6ops documents, I also reviewed
draft-ietf-v6ops-bb-deployment-scenarios-04.txt.  IMO, this is a very
good document that is full of useful information, and it is nearly
suitable for publication.

I only found one serious issue in the document, and it non-technical.
I think that section 2 should be removed from the document, because I
don't think it is appropriate for the IETF to publish documents that
indicate how SPs should differentiate their services and/or to comment
on SPs specific products and services.

I have a couple of other comments (see below), but nothing else that
Should block publication of this document, IMO.

Margaret

---

1.1.  Common Terminology

Add "BB" which is used throughout the document to mean Broadband?

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 to the
   extent that subscribers get up to fixed /48 prefixes versus the
   single, temporary IPv4 addresses.  Such resources allow the SPs to
   better position themselves against the competition.  The IPv6
   deployments can be seen as a driver for lower service support costs
   by eliminating NAT with its negative impact on applications and its
   complex behavior.  Another reason of IPv6 being popular in some
   countries might be the government driven financial incentives and
   favorable legislation towards the ISPs who are deploying IPv6.


I would remove this entire seciton (section 2) from the document.  I
don't think that the IETF is qualified to comment on business
differentiators in the SP industry, and even if we were qualified to do
so, I don't why we would want to do so.  I don't think it is appropriate
to mention specific companies' products and services, and timely
information about what is currently deployed, including the limitations
of those deployments, will probably be outdated by the time this
document is published.


If you don't remove this section, I think it will need a lot of work, as
it mentions individual company names and product names without any
disclaimers and/or indication of whether those companies have approved
of what we are saying about their products, and without including such
legal niceties as trademarks, etc.

   The network is transparent to the Layer 3 protocol.  The only
   possible changes would come with the intent of filtering and
   monitoring IPv6 traffic based on layer 2 information such as IPv6
   Ether Type Protocol ID (0x86DD) or IPv6 multicast specific MAC
   addresses (3333.xxxx.xxxx).

What format of MAC address is this?  I have most often seen Ethernet
addresses represented at xx:xx:xx:xx:xx:xx, so this would be
33:33:xx:xx:xx:xx, right?  But other MAC addresses may be other lengths,
such as EUI-64 identifiers.  Also, if one filters on an EtherType of
0x86DD, one will see all IPv6 traffic.  I am not sure why an additional
filter for IPv6-specific multicast addresses would be needed.  Can you
explain?

   It is important to note that the customers of a Service Provider can
   choose to establish tunnels to publicly available and free tunnel
   services.  Even though the quality of such services might not be
   high, they provide free IPv6 access.  In designing their IPv6
   services, the SPs should take into considerations such options
   available to their potential customers.  The IPv6 deployment should
   support services (like multicast, VoIPv6 etc) and a level of quality
   that would make the access through the SP worthwhile to potential
   subscribers.

This paragraph should be removed, as it mainly provides marketing, not
operational, advice to SPs.

6.  Broadband Cable Networks

   This section describes the infrastructure that exists today in cable
   networks providing BB services to the home.  It also describes IPv6
   deployment options in these cable networks.

   DOCSIS standardizes and documents the operation of data over Cable
   Networks.  The current version of DOCSIS has limitations that do not
   allow for a smooth implementation of native IPv6 transport.  Some of
   these limitations are discussed in this section.  For this reason,
   the IPv6 deployment scenarios discussed in this section for the
   existent Cable Networks are tunnel based.  The tunneling examples
   presented here could also be applied to the other BB technologies
   described in sections 7, 8, 9 and 10.

You should expand the DOCSIS acronym, add a reference for DOCSIS and
state which version is the "current version" that has these limitations.

6.2.4.  IPv6 QoS

   IPv6 will not change or add any queuing/scheduling functionality
   already existing in DOCSIS specifications.  But the QoS  
mechanisms on
   the CMTS and CM would need to be IPv6 capable.  This includes  
support
   for IPv6 classifiers, so that data traffic to/from host devices can
   be classified appropriately into different service flows and be
   assigned appropriate priority.  Appropriate classification criteria
   would need to be implemented for unicast and multicast traffic.

   In order to classify IPv6 traffic the following classifiers would
   need to be modified in the DOCSIS specification to support the 128-
   bit IPv6 address:

   A. IP source address

   B. IP source mask

   C. IP destination address

   D. IP destination mask

   E. IP traffic class (DSCP)

   The following classifiers would be new for IPv6:

   A. IP version

   B. Flow label (optional)

   Traffic classification and marking should be done at the CM for
   upstream traffic and the CMTS/ER for downstream traffic in order to
   support the various types of services: data, voice, video.  The same
   IPv4 QoS concepts and methodologies should be applied for IPv6 as
   well.

   It is important to note that when traffic is encrypted end-to-end,
   the traversed network devices will not have access to many of the
   packet fields used for classification purposes.  In these cases
   routers will most likely place the packets in the default classes.
   The QoS design should take into consideration this scenario and try
   to use mainly IP header fields for classification purposes.

I am not certain about the purpose of this section...  Are we trying to
tell DOCSIS what they would need to change in their specifications in
order to support IPv6 QoS?  If so, I don't think that this belongs in a
document that is telling SPs how to support IPv6 in their networks, does
it?

I think you should make it clearer here and in later sections what will
not currently work, rather than just stating that DOCSIS should change
things.

7.2.1.2.  Addressing

   The Hosts or the Customer Routers have the Edge Router as their  
Layer
   3 next hop.

   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
   auto-configuration 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 PVC (or some other customer-specific
   information) to an IPv6 subnet prefix, and advertise the customer-
   specific prefix to all the customers with minimal configuration.

How is this done in IPv4?  Why does it need to be different in IPv6?