Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

From: Jacni Qin <[email-masked]>
Date: Fri, 13 Jul 2012 11:20:28 +0800

Hi all,

Please see below the text updated according to the comments received.
Many thanks to Stig, Simon, Shailesh, and others for their review and 
discussions.

----------------------------------------------------
4.2.  Multicast Distribution Tree Computation

...

    The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so
    as to represent the IPv4-embedded IPv6 source in the IPv6 multicast
    network, and to pass the Reverse Path Forwarding (RPF) check on
    multicast devices.

4.3.  Multicast Data Forwarding

...
/* A note is added*/

    Note: At this point, only IPv4-in-IPv6 encapsulation is defined;
    Whether or not to support other types of encapsulation is left for
    future consideration.

6.1.  IGMP-MLD Interworking Function

    The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying
    function and the address synthesizing operations.  The IGMP/MLD
    Proxying function is specified in [RFC4605].  The address
    synthesizing is stateless and MUST follow
    [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052].

    The mB4 with the IGMP-MLD Interworking Function embedded relays
    between the IGMP domain and the MLD domain.  The mB4 performs the
    host portion of the MLD protocol on the upstream interface.  The
    composition of IPv6 membership in this context is constructed through
    address synthesizing operations and MUST synchronize with the
    membership database maintained in the IGMP domain.  MLD messages will
    be forwarded natively towards the MLD Querier located upstream in the
    IPv6 network.  The mB4 also performs the router portion of the IGMP
    protocol on the downstream interface(s).  Refer to [RFC4605] for more
    details

              +----------+   IGMP  +-------+   MLD +---------+
              |   IPv4   |---------|  mB4  |---------|   MLD |
              | Receiver |         |       |         | Querier |
              +----------+         +-------+ +---------+

                       Figure 2: IGMP-MLD Interworking

    If SSM is deployed, the mB4 MUST construct the IPv6 source address
    (or retrieve the IPv4 source address) using the uPrefix64. The mB4
    may create a membership database which associates the IPv4-IPv6
    multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet)
    facing IPv4 multicast receivers.

7.2. Processing PIM Message

/* TIB is used to replace mRIB*/

7.5.  TTL/Scope

    The Scope field of IPv4-in-IPv6 multicast addresses should be valued
    accordingly (e.g, to "E", Global scope;) in the deployment
    environment.  This specification does not discuss the scope value
    that should be used.
------------------------------------------------------

Cheers,
Jacni

On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote:
> Hi folks,
>
> This is a wg last call on draft-ietf-softwire-dslite-multicast-02.
> http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/
>
> As usual, please send editorial comments to the authors and
> substantive comments to the mailing list.
>
> This wg last call will end on June 10 at 12pm EDT.
>
>
> Yong & Alain
>
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Jul 2012 13:57:17 -0700

> Many thanks to Stig, Simon, Shailesh, and others for their review and

Thanks, this addresses at least some of my concerns.

Let me try to list the issues I mentioned in my review that I think
may not be addressed.

1. Update the text to make it clear it is a generic solution, but with
    applicability to DS-Lite.

2. It refers to draft-ietf-mboned-64-multicast-address-format-01. I
    think may need to wait and see what happens to this. It depends on
    discussion in the ipv6 wg whether this format will be chosen. The
    examples in this draft may need to be updated depending on the
    format chosen.

3. In 4.2 it says "The MLD Querier (typically acts as the PIMv6
    Designated Router)", but if there are multiple routers, then the
    querier is typically not the DR.

4. Talk about what tunnel types are used. Either pick a specific type,
    or I think better, explain how this solution can be used with
    different types. E.g. IPv4 in IPv6, and GRE.

5. Security considerations should say something about scoping I think.
    How scopes for v4 and v6 may differ, and also how one can in a
    global IPv6 group specify a non-global IPv4 group... Some kind of
    filtering should be in place to protect against this.

Apart from this I had only minor comments which hopefully will be
addressed in the next version.

Stig

---

From: Jacni Qin <[email-masked]>
Date: Tue, 17 Jul 2012 00:04:59 +0800

Hi Stig,

Thanks a lot for your comments.

>    applicability to DS-Lite.
We're trying to figure out what we can do on this.

>    examples in this draft may need to be updated depending on the
Fine.

>    querier is typically not the DR.
We just wanted to include the MLD-PIM inter-operations, while to avoid the
confusion, we can remove the "(typically acts as the PIMv6 Designated 
Router)"

>    different types. E.g. IPv4 in IPv6, and GRE.
A note has been added, which says,

>    filtering should be in place to protect against this.

Could you help on this to propose some text? Thanks a lot.

> addressed in the next version.
Thanks for your comments, surely we'll try.

Cheers,
Jacni