Re: [Softwires] Review of draft-ietf-softwire-mesh-multicast-17

" Mingwei Xu " <xmw@cernet.edu.cn> Mon, 25 September 2017 09:43 UTC

Return-Path: <xmw@cernet.edu.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9658133210; Mon, 25 Sep 2017 02:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level:
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-dNUvs3RWw0; Mon, 25 Sep 2017 02:43:01 -0700 (PDT)
Received: from tsinghua.edu.cn (smtp29.tsinghua.edu.cn [101.6.4.53]) by ietfa.amsl.com (Postfix) with ESMTP id 267BF1331DD; Mon, 25 Sep 2017 02:42:59 -0700 (PDT)
Received: from win7-PC (unknown [166.111.68.231]) by app-1 (Coremail) with SMTP id DwQGZQAHqPWez8hZgPEqAA--.2902S2; Mon, 25 Sep 2017 17:42:56 +0800 (CST)
Date: Mon, 25 Sep 2017 17:42:56 +0800
From: Mingwei Xu <xmw@cernet.edu.cn>
Reply-To: xmw@cernet.edu.cn
To: Ian Farrer <ianfarrer@gmx.com>, Softwires list <softwires@ietf.org>, draft-ietf-softwire-mesh-multicast <draft-ietf-softwire-mesh-multicast@ietf.org>
References: <63E87706-D676-415A-AD80-463F7A53F9B8@gmx.com>
Message-ID: <201709251742487268914@cernet.edu.cn>
X-mailer: Foxmail 6, 15, 201, 26 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon441850704784_====="
X-CM-TRANSID: DwQGZQAHqPWez8hZgPEqAA--.2902S2
X-Coremail-Antispam: 1UD129KBjvJXoWxKr47CrWUXw43Jr4fKrWfKrg_yoW3AF43pF W5KFW2kwn7Jry8A348Zw17ur1FvFWrKa9FkFykK34jv398Gas7tF1SkryYya9rGr4kZa1j vr4jyrZ8W3WDZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Eb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k0 8I80eVWUJVW8JwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lYx0E2I x0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r4j6F4UMcvjeVCFs4IE7xkEbVWUJVW8 JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxMxAIw28IcxkI7VAKI48JMx C20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAF wI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20x vE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v2 0xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267 AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU5ga9DUUUUU==
X-CM-SenderInfo: x0pzquphuqv3oohg3hdfq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/A_t8DMo3nboALTP2CO9cn0qhqtU>
X-Mailman-Approved-At: Wed, 27 Sep 2017 23:57:49 -0700
Subject: Re: [Softwires] Review of draft-ietf-softwire-mesh-multicast-17
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2017 09:43:05 -0000

Hi, Ian,

Thank you very much for your comments. We have updated our draft according to your comments, and published as draft-ietf-softwire-mesh-multicast-18.

Please see inline the reply for your comments.

Best regards,

Mingwei


2017-09-25 



Mingwei Xu 



发件人: Ian Farrer 
发送时间: 2017-09-18  16:39:23 
收件人: Softwires list; draft-ietf-softwire-mesh-multicast 
抄送: 
主题: Re: [Softwires] Review of draft-ietf-softwire-mesh-multicast-17 
I had to forward this to the list separately as the original message was too large. I’ve removed any points which have been resolved.


Cheers,
Ian


------

Hi Mingwei,

Please see inline below.

One additional comment that I found from reading —17:

Section 4.4 - This states that the the AFBR MUST implement route redistribution for IPv4 multicast in BGP. As I read it, this means that the AFBR must implement RFC4760. Is this correct? If so, a normative reference is needed.

Reply: We added a normative reference in the latest version. 


Best regards,
Ian


On 4. Aug 2017, at 10:43, Mingwei Xu <xmw@cernet.edu.cn> wrote:


Dear Ian,
 
We just posted a new version (draft-ietf-softwire-mesh-multicast-17.txt ). The following text is responds to the questions raised recently.
 


Q2:Instead of (re)specifying the behavior it would be more appropriate to refer to draft-ietf-softwire-dslite-multicast (RFC8114) when it makes sense (e.g., AFBR behavior, address mapping, CP, DP, etc.). 

[if - The original comment (as I understand it - it was raised by Med) is that there are a number of similarities between what is described in this draft and RFC8114 in the relevant sections. Rather than re-specifying what is in RFC8114, a comparison needs to be made between the two documents. Where behaviour is already specified in RFC8114, softwire-mesh multicast should reference it. Where it differs, describe the differences.

One example I found from a cursory comparison:

The AFBR data plane behaviour described in Section 6.1. The text here is currently quite unclear - especially the use of encapsulate/decapsulate (e.g. could be construed that a v6 packet gets encapsulated in v4). Does this data plane behaviour differ from RFC8114 Sec 7.4? If not, a reference would be better. If it is different, then the text needs to be cleared up and describe the differences.
]


 The document says the following: The mPrefix46 for SSM mode is also defined in Section 4.1 of [RFC7371]. This is not true. RFC7371 is about flag bits not MPREFIX64.  Instead of referring to RFC7371, adding a pointer to Section 5 of draft-ietf-softwire-dslite-multicast would make sense. 
 

Answer: We refer to RFC8114 in section 4.2, and add a pointer to Section 5 of draft-ietf-softwire-dslite-multicast when defining mPrefix46 for SSM mode.

[if - This also refers to the above comment.

The mPrefix64 addressing format is given in Section 5 of RFC8114. The text in section mesh-multicast 4.2 has a pointer to section 2 of RFC8114. Note that RFC8114 is defining mPrefix64, not mPrefix46. Suggest that the line

The mPrefix46 for SSM mode is also defined in Section 2 of [RFC8114].

Is replaced with:
The construction of the mPrefix46 for SSM is the same as the construction of the mPrefix64 described in Section 5 of [RFC8114].
]

Reply: In the latest version, we made comparison with RFC8114 and re-edit Section 4.2, Section 5 and Section 6.1.





Q4:  5.5 Inter-AFBR Signaling This section states that an RP' SHOULD NOT process messages on it's incoming interface, by introducing an interface agent. However, at this point the text becomes vague as to whether it is mandatory to have an interface agent implementation. If you are saying that you should not do something then it would follow there needs to be an equivalent statement of  what you should do instead.
 Also the functionality of the interface agent is only described as how it MAY work. This also seems vague. It would be better to describe what the behavior is with RFC2119 language, and then state something along the lines of 'the mechanism used to achieve this is left to the implementation, the following diagram provides a possible solution', or words to that effect.
 
Answer: We use the word ‘SHOULD’ because there may exist valid reasons in particular circumstances (when there is only one downstream router) to ignore the implementation. In the lastest version, we added an equivalent statement of  what we should do instead as following: RP’ SHOULD prune S from the RPT of group G when no downstream AFBR is subscribed to receive multicast data of (S,G) along the RPT.
In the latest version, we edited the sentence as following: The mechanism used to achieve this is left to the implementation, the following diagram provides a possible solution that  "interface agent" MAY be implemented.

 

[if- OK, but the resulting text has become quite complicated. What about the following re-wording, including text for the exception to the SHOULD?

To solve this problem, we introduce an  "interface agent" to process all the encapsulated (S,G,rpt) messages the upstream AFBR receives. The interface agent's RP' SHOULD prune S from the RPT of group G when no downstream AFBR is subscribed to receive multicast data of (S,G) along the RPT.

In this way, we ensure that downstream AFBRs will not miss any multicast data that they need. The cost of this is that multicast data of (S,G) will be duplicated along the RPT received by SPT-switched-over downstream AFBRs, if at least one downstream AFBR  exists that has not yet sent Prune(S,G,rpt) messages to the upstream AFBR.

In certain deployment scenario’s (e.g. if there is only a single downstream router), the interface agent function is not required.

The mechanism used to achieve this is left to the implementation. The following diagram provides one possible solution for an "interface agent" implementation:
]

Reply: Thank you for your suggestions, we have already changed the words in the latest version.




 Q20: I'm not sure what 'SHOULD still take effect' is meant to mean in this context.
 

 Answer: We have reworded it as ‘SHOULD keep alive’.

[if - The resulting text is not very clear:

NOTICE: It is possible that an E-IP neighbor of RP' that has joined
   the RPT of G, so the per-interface state machine for receiving E-IP
   Join/Prune (S,G,rpt) messages SHOULD keep alive.

The text reads that the state machine process should 'keep alive’ (not crash?). I guess that the intended meaning is that the current state in the state machine should be preserved.]

Reply: We change the sentence to: It is possible that an E-IP neighbor of RP' that has joined the RPT of G, so the per-interface state machine for receiving E-IP Join/Prune (S,G,rpt) messages SHOULD be preserved.



 Q21: Suggest 'expresses its interest' is replaced with a less anthromorpic term.
 

 Answer: Thank you for your suggestion. Because the term is used in RFC 4601, we also used it  in this documents.

[if - Just checked RFC4601, yes it makes sense to use consistent terminology]




 Q23: Is the language strong enough here? 'some AFBRs may not' - If two AFBRs are not using the same tunnelling technology, it will not work. 'may' suggests there's a chance that it will.
 

 Answer: We changed ‘may’ to ‘SHALL’.

[if - This answer seems to be related to the now defunct Section 6.2. The current wording of Section 8 is OK]




 Q25: This section differs from the guidance in the section "Selecting a Tunneling Technology" above.
 

 Answer: In the section “Selection a Tunneling Technology”, we re-edited the text as following, "It is REQUIRED that all AFBRs use the same technology”, so both section express the same meaning.

[if - ? In this version, only Section 8 deals with this. I think the current text is OK here.]








Mingwei