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

["Lee, Yiu" <[e-mail]>]

Hi Stig,

Thanks for reviewing the draft. Comments inline.

Thanks,
Yiu

On 1/12/17, 6:40 PM, "Stig Venaas" <[e-mail]> wrote:

    Hi
    
    Please see comments inline. I see you posted a new revision, but I
    still have some remaining concerns.
    
    On Wed, Jan 11, 2017 at 11:55 PM,  <[e-mail]> wrote:
    > Hi Stig,
    >
    > Thank you for the review.
    >
    > Please see inline.
    >
    > Cheers,
    > Med
    >
    >> -----Message d'origine-----
    >> De : Stig Venaas [mailto:[e-mail]]
    >> Envoyé : mercredi 11 janvier 2017 19:23
    >> À : [e-mail]; [e-mail]
    >> Cc : [e-mail]; [e-mail]
    >> Objet : RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt
    >>
    >> 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.
    >>
    >> 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.
    >>
    >> 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.
    >
    > [Med] That definition was drawn from an MLD perspective. OK with your proposal to skip these details. I made this modification:
    >
    > OLD:
    >       the corresponding Multicast Listener Discovery (MLD) messages
    >       towards the MLD Querier in the IPv6 network.
    >
    > NEW:
    >       the corresponding Multicast Listener Discovery (MLD) messages
    >       towards the IPv6 network.
    
    This is OK, but I see it says "forwarding the corresponding...". The MLD
    message is originated by mB4. "Forwarding" is not quote correct. Also,
    the message only goes to the IPv6 routers that are on the same link as
    mB4, it may sound like it gets forwarded, but MLD messages are never
    forwarded. So just think about whether there is a more precise way of
    saying it.

[YL] I understand your concerns of the correctness of the protocol behavior. The mB4 translates and generate the corresponding MLD message. Strictly speaking, no forwarding hs involved. If we change this to:

NEW:
   Multicast B4 (mB4):  a functional entity which supports an IGMP-MLD
         interworking function (refer to Section 6.1) that translates the
         IGMP messages into the corresponding Multicast Listener 
         Discovery (MLD) messages, and send the MLD messages
         to the IPv6 network.  
    
    >>
    >> 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.
    >>
    >
    > [Med] Same as for the previous comment. I suggest the following:
    >
    > OLD:
    >    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.
    >
    > 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
    >    towards 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 message to join the IPv6 multicast distribution
    >    tree.  It can send either PIMv6 Join (*,G6) in ASM or PIMv6 Join
    >    (S6,G6) in SSM to the mAFTR.
    
    The Querier is entirely out of the picture, so I would just write "The
    PIMv6 Designated Router receives the MLD Report message and sends"...
    If you want a reference, maybe see the beginning of
    https://tools.ietf.org/html/rfc7761#section-3.1

[YL] I see your point. We should remove MLD Querier.
    
    >> 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.
    >>
    >
    > [Med] This one is really specific to IGMP/MLD. The use of Querier in the text and the figure are correct. I suggest to maintain the details.
    
    I believe this is incorrect. At least the MLD reports sent by mB4 are
    processed by the PIM DR, not the MLD querier. They can be the same
    router, but it is always the router functioning as PIM DR that is
    responsible for acting on the MLD report. In the text you are talking
    about the MLD report/message sent by mB4. One option could be to
    replace querier with IPv6 router? Note that "first hop IPv6 router" is
    also confusing. For multicast, the term "first hop" is used for the
    router connected to the source. While the router receiving MLD reports
    (the DR) is the "last hop" router.
    
    I would replace this text "MLD messages are forwarded natively towards
    the MLD Querier located upstream in the IPv6 network (i.e., the first
    hop IPv6 router)" with something like "MLD messages are sent natively
    to the directly connected IPv6 multicast routers (it will be processed
    by the PIM DR)."

[YL] Thanks. We will update this.
    
    >> 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.
    >>
    >
    > [Med] We already have this text in Section 5.1 to cover this point:
    >
    > The
    >    mPrefix64 MUST be derived from the corresponding IPv6 multicast
    >    address space (e.g., the SSM_mPrefix64 must be in the range of
    >    multicast address space specified in [RFC4607]).
    
    Sorry, you're right.
    
    [some quoted text deleted]
    >> 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?
    >
    > [Med] Encapsulation can be used in the last hop between the mAFTR and mB4 in this case.
    
    The MLD querier is on the same link as mB4, right? They must be
    connected to the same layer 3 link (subnet). So if you say you
    co-locate MLD querier with the mAFTR, then I believe the mAFTR is on
    the same link as mB4. Which means that you IPv6 encapsulate between
    two routers that are on the same layer 3 link. Is this useful? Or am I
    missing something?
    
[YL] Yes, the mB4 and mAFTR are on the same link. In the case the source is IPv4, mAFTR will still need to encap the corresponding IPv4 multicast packets into IPv6 multicast packets and send toward to the mB4.

    >>
    >> Would it make sense to consider the case where mB4 acts as an IPv6 PIM
    >> router, avoiding sending MLD reports?
    >
    > [Med] Yes, but this is really deployment-specific.
    >
    >>
    >> 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.
    >
    > [Med] Isn't this covered by this text?
    >
    >    If IGMPv2 operates on the IPv4 receivers while MLDv2 operates on the
    >    MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1
    >                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >    operates on the MLD Querier, the version mismatch issue will be
    >    encountered.
    
    I understand that you're saying that you downgrade to IGMPv2 if the
    IPv6 querier is MLDv1. That is fine. But it might be good to point out
    that you cannot support SSM in that case. To support IPv4 SSM, you
    need to have MLDv2 in your IPv6 network. Maybe it is obvious, but it
    might be worth pointing it out.
    
[YL] We will add this in next version.

    Stig