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

[Adeel Ahmed <adahmed@cisco.com>]

Hello Alain,

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

At 04:58 PM 4/8/2005 -0700, Alain Durand wrote:
> 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.

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


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

@@@@@
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
>  about using tunnels are moot, unless the home GWR does not support
> v6.

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

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

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


>    - Alain.