Subject: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast

From: Ian Farrer <[email-masked]>
Date: Thu, 7 Apr 2016 11:58:40 -0300

Hi,

This document has been around for some time, but has not received any substantive reviews. Can I ask for volunteers who are willing to provide reviews?

Thanks,
Ian

---

From: [email-masked]
Date: Sat, 9 Apr 2016 04:16:39 +0200

Are there any implementations of this?

Ole

> On 07 Apr 2016, at 16:58, Ian Farrer <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Mingwei Xu" <[email-masked]>
Date: Sun, 10 Apr 2016 09:15:23 +0800

Hi, Ole,

Yes, we implemented the draft in a click-based router. It was also implemented in the routers of a vendor, which were deployed in CERNET2. 

Mingwei

------------------				 
Mingwei Xu
2016-04-10

-------------------------------------------------------------
发件人：otroan
发送日期：2016-04-09 10:16:55
收件人：Ian Farrer
抄送：softwires
主题：Re: [Softwires] Call for reviewersdraft-ietf-softwire-mesh-multicast

Ole

---

From: "Lishan Li" <[email-masked]>
Date: Sun, 17 Apr 2016 22:02:11 +0800 (CST)

Dear All,

I have reviewed the mesh multicast draft. In general, I think that this document is mature enough to move forward. 
Some minor mistakes of the draft:
1. In section 1 1. Introduction, there is no hyperlink for RFC4925;
2. In section 3.2 IPv6-over-IPv4, "IPv6 - to - IPv4 address mapping" should be "IPv6-to-IPv4 address mapping".

Best Regards,
Lishan

---

From: "Mingwei Xu" <[email-masked]>
Date: Mon, 18 Apr 2016 09:00:38 +0800

Thank you, Lishan.

We will modify the draft according to your comments.

Mingwei

2016-04-18 

Mingwei Xu 

发件人： Lishan Li 
发送时间： 2016-04-17  22:08:32 
收件人： Ian Farrer 
抄送： softwires 
主题： Re: [Softwires] Call for reviewersdraft-ietf-softwire-mesh-multicast 
 
Dear All,

Best Regards,
Lishan

---

From: [email-masked]
Date: Mon, 18 Apr 2016 22:41:08 +0800

Hi Ian,

    I would like to review this draft. I think it is very useful for 
multicast implementation in transition scenarios.

Thanks,
Wei

"Softwires" <[email-masked]> 写于 2016/04/07 22:58:40:

> Ian Farrer <[email-masked]> 
> 发件人:  "Softwires" <[email-masked]>
> 
> 2016/04/07 22:58
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> 主题
> 
> [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast
> 
> Hi,
> 
> This document has been around for some time, but has not received 
> any substantive reviews. Can I ask for volunteers who are willing to
> provide reviews?
> 
> Thanks,
> Ian
> 
>

---

From: Ian Farrer <[email-masked]>
Date: Tue, 19 Apr 2016 21:53:01 +0200

Hi,

Here is my review of the draft.

Best regards,
Ian

Pg 5 - states a 'dual-stack' router. The AFBR is not really dual-stack here. It has two single stack interfaces and implements a transition technology. Suggest removal of dual-stack.

Section 4.1
The translation between the IPv4 and IPv6 PIM messages seems underspecified. It would be useful to provide some examples showing how the new addresses are used in the different translations into the PIM message formats (RFC7741 Section 4.1).

Section 4.2
The term ‘MPREFIX64’ is not defined in RFC7371. As there are a number of different formats for multicast prefixes in RFC7371, it would be useful to point to the relevant section to avoid confusion.

Why was the name MPREFIX64 chosen for 4in6 multicast? In other Softwire docs (e.g. RFC7598), ’46’ is used to denote 4 in 6 functions and 64 for 6 in 4. As the addressing and mechanism for 4in6 differs for 6in4, it would make sense to differentiate this in the naming of the fields (i.e. use MPREFIX46, uPrefix46 for 4in6 and uPrefix64 for 6in4).

Section 6.3
Section 6 overall defines requirements for the control plane. Sections 6.1. and 6.2 are MUST requirements. 6.3 uses ‘should’ in defining the behaviour. Can the mechanism work without implementing sec 6.3 and in which situations is it acceptable not to?

Section 6.5
This introduces the encapsulation of messages, but doesn’t provide any information about what type of encapsulation is used. Figure 7 shows UDP. Is this part of the encapsulation? As this is necessary for the mechanism to work and needs to be implemented on the AFBRs, there needs to be references and requirements language on what needs to be implemented.

s/we do insure/it is ensured/

Section 7.2
Are there options on the kind of tunnel encapsulation that can be used? It would be useful to enumerate some of these and for interoperability one of them needs to be mandatory to implement.

References
RFC2119 Needs to have a normative reference
RFC4601 has been obsoleted by RFC7761

General - 
The document doesn’t contain the ‘Conventions/Requirements Language’ boilerplate pointing to RFC2119 that needs to be in a standards track document. (The key words "MUST", "MUST NOT”, …)

The use of RFC2119 language and the case of the words throughout the document is not consistent (there are a number of lower case ‘must’ etc, that probably should be uppercase).

The term ‘should’ (lower case) is used in a number of places that make the functionality of the mechanism seem uncertain (e.g. Figure 1 - 'Multicast packets should get across the I-IP transit core'. Sec 4.1 'it should be translated back’).

There are some points that would seem to need MUST requirements that are missing - e.g. Section 4.4 'every uPrefix64 that AFBR announces should be different either, and uniquely identifies each AFBR’. If two AFBRs are announcing the same uPrefix64, surely there will be problems.

Suggest that the use of RFC2119 language is revised throughout the document to avoid these problems and to tighten up the specification as a whole.

The document needs the language and grammar checking throughout.

> On 7 Apr 2016, at 16:58, Ian Farrer <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Mingwei Xu" <[email-masked]>
Date: Wed, 20 Apr 2016 08:46:48 +0800

Hi, Ian,

Thank you very much! We will modify the draft according to your valuable comments.

Mingwei

2016-04-20 

Mingwei Xu 

发件人： Ian Farrer 
发送时间： 2016-04-20  03:53:13 
收件人： draft-ietf-softwire-mesh-multicast; softwires 
抄送： 
主题： Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast 
 
Hi,

Best regards,
Ian

Section 4.1

Section 4.2

Section 6.3

Section 6.5

Section 7.2

References

General - 

Hi,

Thanks,
Ian

---

From: <[email-masked]>
Date: Mon, 25 Apr 2016 08:16:37 +0000

Hi Ian, all,

I have the following comments about this draft:

* This draft covers two cases: IPv4-over-IPv6 and IPv6-over-IPv4. I see a potential overlap with draft-ietf-softwire-dslite-multicast (that passed the WGLC) for the IPv4-over-IPv6 case. Unless there are some differences between these two documents for this case, I suggest to scope draft-ietf-softwire-mesh-multicast to focus on the IPv6-over-IPv4 and add a pointer to draft-ietf-softwire-dslite-multicast. Otherwise, it would be helpful to identify the differences between the two documents. 

* The following section points to RFC7371. I think the authors meant https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-06.   

==
4.2.  Group Address Mapping

   For IPv4-over-IPv6 scenario, a simple algorithmic mapping between
   IPv4 multicast group addresses and IPv6 group addresses is supported.
   [RFC7371] has already defined an applicable format.  Figure 4 is the
   reminder of the format:

     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 0-------------32--40--48--56--64--72--80--88--96-----------127|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                    MPREFIX64                  |group  address |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

           Figure 4: IPv4-Embedded IPv6 Multicast Address Format

   The MPREFIX64 for SSM mode is also defined in [RFC7371] :

   o  ff3x:0:8000::/96 ('x' is any valid scope)
==  

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Softwires [mailto:[email-masked]] De la part de Ian
> Farrer
> Envoyé : jeudi 7 avril 2016 16:59
> À : [email-masked]
> Objet : [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast
> 
> Hi,
> 
> This document has been around for some time, but has not received any
> substantive reviews. Can I ask for volunteers who are willing to provide
> reviews?
> 
> Thanks,
> Ian
> 
>

---

From: <[email-masked]>
Date: Mon, 25 Apr 2016 08:32:27 +0000

Hi Ian,

I agree with your comment «The term ‘MPREFIX64’ is not defined in RFC7371.”. FWIW, MPREFIX64 was defined in https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-06#section-3

Also,
* The set of multicast-related provisioning parameters for the IPv4-over-IPv6 delivery case are defined in https://tools.ietf.org/html/rfc7678#section-2.5, not RFC7371.
* These parameters are consistent with those defined in https://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-10 (that passed the WGLC).

Note that having a dependency on the mboned draft is not required.

Cheers,
Med

De : Softwires [mailto:[email-masked]] De la part de Ian Farrer
Envoyé : mardi 19 avril 2016 21:53
À : [email-masked]; [email-masked]
Objet : Re: [Softwires] Call for reviewers draft-ietf-softwire-mesh-multicast

Hi,

Best regards,
Ian

Section 4.1

Section 4.2

Section 6.3

Section 6.5

Section 7.2

References

General -

On 7 Apr 2016, at 16:58, Ian Farrer <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks,
Ian

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: 杨术 <[email-masked]>
Date: Tue, 26 Apr 2016 10:42:32 +0800 (GMT+08:00)

Hi, Dear Mohamed,

Thank for you advices!

> * This draft covers two cases: IPv4-over-IPv6 and IPv6-over-IPv4. I see a potential overlap with draft-ietf-softwire-dslite-multicast (that passed the WGLC) for the IPv4-over-IPv6 case.
Our draft focus on the mesh 4over6 case mentioned in rfc 4925. The "hub and spoke" scenario is different with the ds-lite 4over6 case in rfc 6333.

> * The following section points to RFC7371. I think the authors meant https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-06.   
We will update the references.

Shu Yang

> 发件人：mohamed.boucadair
> 发送日期：2016-04-25 16:27:33
> 收件人：Ian Farrer; [email-masked]
> 抄送：
> .

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Apr 2016 11:36:01 -0500

> Our draft focus on the mesh 4over6 case mentioned in rfc 4925. The "hub and spoke" scenario is different with the ds-lite 4over6 case in rfc 6333.

This seems to be correct.
This draft is based on what I call weird definition of mesh problem in
RFC 4925. I don't think it was followed up much afterwards.
If we look back, I think this draft has taken up the precious
multicast space and as a result, no space was left for much more
important edge multicast transition protocols.
Sigh.

Regards,

Behcet