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

[Salman Asadullah <sasad@cisco.com>]

Thanks Jim.

We have removed the section 2.

Regards,
Salman


On 5/29/06 8:17 AM, "Bound, Jim" <Jim.Bound@hp.com> wrote:

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