Hi Stig,
Thanks a lot for your comments.
On 7/14/2012 Saturday 4:57 AM, Stig Venaas wrote:
On 7/12/2012 8:20 PM, Jacni Qin wrote:
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.
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.
We're trying to figure out what we can do on this.
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.
Fine.
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.
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)"
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.
A note has been added, which says,
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.
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.
Could you help on this to propose some text? Thanks a lot.
Apart from this I had only minor comments which hopefully will be
addressed in the next version.
Thanks for your comments, surely we'll try.
Cheers,
Jacni
Stig
----------------------------------------------------
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 protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
