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

From: Fred Baker <[email-masked]>
Date: Fri, 26 May 2006 09:04:26 -0700

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: [email-masked]'; [email-masked]'
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?

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 29 May 2006 09:17:24 -0400

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 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Friday, May 26, 2006 12:04 PM
> To: Adeel Ahmed ((adahmed)); [email-masked]; 
> [email-masked]; Pekka Savola; Salman Asadullah ((sasad))
> Cc: [email-masked]; 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.
> 
> 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 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
> 
> 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.
> 
> 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?
> 
> This paragraph should be removed, as it mainly provides 
> marketing, not operational, advice to SPs.
> 
> 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
> 
>     the CMTS and CM would need to be IPv6 capable.  This 
> includes support
> 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.
>

---

From: Salman Asadullah <[email-masked]>
Date: Wed, 31 May 2006 17:46:28 -0500

Thanks Jim.

We have removed the section 2.

Regards,
Salman

---

From: Salman Asadullah <[email-masked]>
Date: Wed, 31 May 2006 18:37:35 -0500

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 SPs specific products and services.

Removed section 2.

> 33:33:xx:xx:xx:xx, right?

Good catch :-) Corrected it.

  But other MAC addresses may be other lengths,
> filter for IPv6-specific multicast addresses would be needed.  Can you

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

> operational, advice to SPs.

Removed the above paragraph as recommended.

> state which version is the "current version" that has these limitations.

Done.

> not currently work, rather than just stating that DOCSIS should change

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

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

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