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

[Salman Asadullah <sasad@cisco.com>]

Hello,

Thanks for Margaret's feedback.

We have integrated her feedback and should appear in -05 of the draft.

Please see our comments below.

Regards,
Salman


On 5/26/06 11:04 AM, "Fred Baker" <fred@cisco.com> wrote:

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

Removed section 2.

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

Good catch :-) Corrected it.

  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?

Yes you are correct. One would use one type of the filter or other, not both
at the same time.

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

Removed the above paragraph as recommended.

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

Done.

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


We have deleted the following from the above section as recommended.


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)



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


IPv4 has the same issue but with IPv6 we are suggesting that we could work
on coming up with betters schemes.

==========
==========