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

["Bound, Jim" <Jim.Bound@hp.com>]

I think this to is ready to ship as RFC.  I do agree below that section
2 may have to be removed for the reasons stated.  We have to be careful
on the slippery slope of what we say in the IETF about deployment that
is not within our IETF bounds.  Naming/Commenting on specific products
is not good either.

Best,
/jim 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> Sent: Friday, May 26, 2006 12:04 PM
> To: Adeel Ahmed ((adahmed)); cpopovic@cisco.com; 
> jordi.palet@consulintel.es; Pekka Savola; Salman Asadullah ((sasad))
> Cc: v6ops@ops.ietf.org; Lindqvist Erik Kurt
> Subject: FW: Review of draft-ietf-v6ops-bb-deployment-scenarios-04.txt
> 
> 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?
> 
>