Subject: comment on draft-ietf-v6ops-bb-deployment-scenarios-01.txt on the cabe modem section

From: Alain Durand <[email-masked]>
Date: Fri, 08 Apr 2005 16:58:10 -0700

I have some comments on the cable modem scenario.

- the various sub-scenarios have a lot in common. The way there are 
described in full one by one makes
that there is a lot of redundant text. Grouping commonalities in one 
section and ten, for each sub-case,
describing what is different would make the document easier to read.

- There is something not obvious on why IGMPv3/MLDv2 is needed.
   the CM amd CMTS are L2 bridges, so they could just forward any 
multicast traffic.
   This is especially true for the CM, which has only 2 interfaces. I 
reckon it may be
    different for the CMTS is one wants to make sure multicast traffic 
for one customer
    does not accidentally flows to another. In any case, I'd like to see 
some more
    text why MLD is needed. Actually the current text is a bit 
ambiquous, it some
    places it says that MLD is mandatory, in other it just says that the 
absence of MLD "could"
    break ND...

- If a cable operator decides to roll out v6 for management purpose, 
then all the scenarios
  about using tunnels are moot, unless the home GWR does not support v6.

- If v6 multicast is important, support for MLD proxy or PIM-SM is critical
  in the GWR. If it is not there, is there a work around?

    - Alain.

---

From: Adeel Ahmed <[email-masked]>
Date: Tue, 12 Apr 2005 17:39:53 -0500

Hello Alain,

Thank you for reviewing our draft and providing feedback. Please see my 
responses inline with @@@@@:

>describing what is different would make the document easier to read.

@@@@@
This issue has been discussed in the past and per agreement from the WG we 
would like to keep the format of the different sections as is.
@@@@@

>    different for the CMTS is one wants to make sure multicast traffic for 
> one customer
>    text why MLD is needed. Actually the current text is a bit ambiquous, 
> it some

@@@@@
We will add more text to explain why IGMPv3/MLDv2 or v1 snooping is needed 
on the CM. Basically the DOCSIS specification mandates use of IGMPv2 
snooping on the CM in order to track join/leave messages from hosts 
connected to its LAN interface. The CM is not allowed to pass any multicast 
traffic from its cable interface to the LAN interface unless there is  a 
host on its LAN interface which is part of that multicast group. This 
breaks IPv6 ND in cable networks. For IPv6 the CM will need to support 
IGMPv3/MLDv2 or v1 snooping for ND to work.
@@@@@

>- If a cable operator decides to roll out v6 for management purpose, then 
>all the scenarios

@@@@@
The native IPv6 solution is valid as long as the cable operator wants to 
manage only the CM. The CM management traffic does not face the DOCSIS 
limitations regarding IPv6. The native solution is not feasible in managing 
IPv6 devices behind the CM. This later case, as discussed in the cable case 
studies, is not possible today with native IPv6 deployment and can be 
implemented only with the help of tunnels.
@@@@@

>  in the GWR. If it is not there, is there a work around?

@@@@@
It is recognized that the GWR is a device with limited resources and it 
supports a limited set of features. For this reason two options were 
offered for it in order to support a multicast service: PIM-SM or MLD 
Proxy. If neither is supported by the GWR then the user interested in the 
multicast service has two options: 1. Change the GWR to one that supports 
one of the two features, 2. Remove the GWR and use an appliance (behind the 
CM)  to handle the control aspects of the multicast service.
@@@@@

Kind Regards,
Adeel.

---

From: Alain Durand <[email-masked]>
Date: Tue, 12 Apr 2005 16:56:25 -0700

On Apr 12, 2005, at 3:39 PM, Adeel Ahmed wrote:

>  Hello Alain,
>
>  Thank you for reviewing our draft and providing feedback. Please see 
> my responses inline with @@@@@:
>
>  This issue has been discussed in the past and per agreement from the 
> WG we would like to keep the format of the different sections as is.
>  @@@@@

I understand that you'd like to keep the different sections as 
independent ones.
My comment is targeted at the cable section itself and its sub-sections.
I will strongly encourage you and the wg to revisit your position as
this particular section is real hard to read as it is now.

	- Alain.