[Softwires] Fwd: RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt

[Jacni Q <[e-mail]>]

Sorry, this one [e-mail]?

---------- Forwarded message ----------
From: Jacni Q <[e-mail]>
Date: Thu, Jan 12, 2017 at 2:55 PM
Subject: Re: RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt
To: Stig Venaas <[e-mail]>
Cc: [e-mail], [e-mail],
[e-mail], [e-mail]


Re-,

Thanks Stig for the comments, inline please.


On Thu, Jan 12, 2017 at 2:22 AM, Stig Venaas <[e-mail]> wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> Document: draft-ietf-softwire-dslite-multicast-14.txt
> Reviewer: Stig Venaas
> Review Date: 2017-01-11
> IETF LC End Date: 2017-01-12
> Intended Status: Standards Track
>
> Summary:
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
> Comments:
> The document is fairly easy to read, and the solution is technically
> sound and is well described. But a couple of statements are
> technically wrong and need to be corrected. A few more details could
> be added in some places, and there are a couple of very minor issues
> that make it less readable.
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
>
> In 3 places the documents talks about the MLD querier where it instead
> should have said PIM Designated Router, or PIM DR.
>
> ​[Q]: Yes, we borrowed the "Querier" terminology heavily from RFC 3810.
can we simply replace it with "router" or just remove it somewhere like
"... into the IPv6 network"? Since as you mentioned there may be querier, DR
and other routers receiving the message.
 ​

> In section 2 we have this definition:
> ​​
>    Multicast B4 (mB4):  a functional entity which supports an IGMP-MLD
>       interworking function (refer to Section 6.1) that relays
>       information conveyed in IGMP messages by forwarding the
>       corresponding Multicast Listener Discovery (MLD) messages towards
>       the MLD Querier in the IPv6 network.  In addition, the mB4
>       decapsulates IPv4-in-IPv6 multicast packets.
>
> ​[Q]:

-New-
​Multicast B4 (mB4):  a functional entity which supports an IGMP-MLD
interworking function (refer to Section 6.1) that relays
information conveyed in IGMP messages by forwarding the
corresponding Multicast Listener Discovery (MLD) messages into
the IPv6 network.  In addition, the mB4 decapsulates
IPv4-in-IPv6 multicast packets.​



> It is the DR, not the querier that needs the reports. The reports are
> sent by multicast to the all MLDv2-capable routers address though,
> which means that DR, querier (they may be the same), and potentially
> other routers on the link will get the report. Maybe you can skip some
> details and just say that mB4 sends an MLD report.
>
> In 4.2 we have this paragraph:
>
> ​​
> The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
>    corresponding MLD Report message.  The mB4 sends the Report message
>    towards the MLD Querier in the IPv6 network.  The MLD Querier (which
>    usually acts as the PIMv6 Designated Router too) receives the MLD
>    Report message and sends the PIMv6 Join to join the IPv6 multicast
>    distribution tree.  The MLD Querier can send either PIMv6 Join (*,G6)
>    in ASM or PIMv6 Join (S6,G6) in SSM to the mAFTR.
>
> It should just say DR here as well.
>
> ​[Q]:

-New-
The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
corresponding MLD Report message.  The mB4 sends the Report message
into the IPv6 network.  The MLD router which acts as the PIMv6
Designated Router too, receives the MLD Report message and sends
the PIMv6 Join to join the IPv6 multicast distribution tree.
The router can send either PIMv6 Join (*,G6) in ASM or PIMv6
Join (S6,G6) in SSM to the mAFTR.
​


> Also in In 6.1 it says:
>
> ​​
> MLD messages are forwarded natively towards the MLD Querier
>    located upstream in the IPv6 network (i.e., the first hop IPv6
>    router).
> It should refer to the PIM DR here as well, and figure 2 should be updated.
>
> ​[Q]:

-New-
​

​MLD messages are forwarded natively towards the MLD router
located upstream in the IPv6 network (i.e., the first hop IPv6
router).
​

> More discussion about SSM vs ASM would be useful. In the last
> paragraph of section 1 you have some text about SSM versus ASM. would
> be good to point out that SSM and ASM IPv4 groups should be mapped to
> SSM and and ASM IPv6 groups respectively. That is, if an IPv4 group is
> an SSM group, then I believe the respective IPv6 group needs to be SSM
> as well. The same for ASM.
>
> ​[Q]: The quote here is just intent to express the preference of SSM.
We can remove
"
the
operation of the translation mechanism is also simplified when SSM is
used, e.g., considerations for placement of the IPv6 the Rendezvous
Point (RP) are no longer relevant.
"
from the last sentence to make it simple.
​


> In 4.2 it says:
>
> ​​
> The mAFTR acts as the IPv4 DR to which the uPrefix64-derived S6 is
>    connected.
> Shouldn't it say that the mAFTR acts as the IPv6 DR?
>
> ​[Q]: Yes.
​


>
> Nits:
> I found a number of nits.
>
> In the abstract we have:
>    This document specifies a solution for the delivery of IPv4 multicast
>    services to IPv4 clients over an IPv6 multicast network.  The
>    solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
>    and uses the IPv6 multicast distribution tree to deliver IPv4
>    multicast traffic.  The solution is particularly useful for the
>    delivery of multicast service offerings to DS-Lite serviced
>    customers.
>
> This make it sounds like a single IPv6 multicast tree is used for
> delivery of all IPv4 multicast. It would be better changing this to
> plural (or possible say an IPv6 multicast distribution tree).
>
> ​[Q]:Ok, maybe "an IPv6 multicast distribution tree".
​


> In first paragraph of section 1:
>    DS-Lite [RFC6333] is a technique that rationalizes the usage of the
>    remaining global IPv4 addresses during the transition period by
>    sharing a single IPv4 address with multiple users.
> Rationalize is the wrong word here I believe. Perhaps it should say
> rations, limits or reduces?
>
> ​[Q]: not native, so no comment on it :-)
​


> In second paragraph of section 2, [RFC7597] is not marked correctly as
> a reference, it is just text.
>
> In 4.2 we have this text:
>
> ​​
> The mAFTR advertises the route of uPrefix64 with an IPv6 Interior
>    Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6
>    source in the IPv6 multicast network, and to run the Reverse Path
>    Forwarding (RPF) check procedure on incoming multicast traffic.
>
> It might sound like mAFTR is the router doing the RPF check. It might
> be good to clarify that it is announced to allow other IPv6 routers to
> perform RPF check.
>

​[Q]:
​

-
​New-
The mAFTR advertises the route of uPrefix64 with an IPv6 Interior
Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6
source in the IPv6 multicast network, and for IPv6 multicast
routers to run the Reverse Path Forwarding (RPF) check procedure
on incoming multicast traffic.
​


> In 6.2 you have this example:
>    As an illustration, if a packet is received from source
>    2001:db8::192.0.2.33 and needs to be forwarded to group
>    ff3x:1000::233.252.0.1
>
> Note that the latter is not a valid unicast prefix-based multicast
> address. It would be better to use something like
> ff3x:20:2001:db8::233.252.0.1. This is also the case in 7.4.
>
> ​[Q]: Ok.
​


> In 6.5 there is an issue with the example. It has the address
> ff0e::db8::233.252.0.1. You cannot use :: twice.
>
> ​[Q]: Thanks.
​


> The section 7.5 heading is TTL/Scope, but it only discusses Scope. It
> might make sense to recommend copying the TTL value from the IPv4
> packet to the IPv6 packet, and perhaps copying it back after
> decapsulation.
>
> I don't understand section 8.1.1 about co-locating MLD querier with
> the mAFTR. Doesn't that mean that the mAFTR is on the same link as the
> mB4? If that is the case, do you need IPv6 encapsulation at all?
>
> ​[Q]: Co-locating means on the same node, running the two sorts of
functionalities.
​


> Would it make sense to consider the case where mB4 acts as an IPv6 PIM
> router, avoiding sending MLD reports?
>
> ​[Q]: That's possible.
​


> Appendix B discusses issues with mismatch of group membership
> protocols at mB4. The real issue, which is not mentioned, is if mB4
> receives source specific (SSM) reports from IPv4 receivers, and the
> upstream IPv6 MLD router only supports MLDv1.
>
> ​[Q]: We have talked about this in the next paragraph.

Thanks again for your review.

​


> Regards,
> Stig
>


-- 
Cheers,
-Q



-- 
Cheers,
-Q