Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

From: Jacni Qin <[email-masked]>
Date: Tue, 05 Jun 2012 10:13:50 +0800

hi simon,

Sorry for the late reply, please see below,

On 5/28/2012 Monday 10:11 PM, Simon Perreault wrote:
> On 2012-05-27 10:34, Yong Cui wrote:
>> This is a wg last call on draft-ietf-softwire-dslite-multicast-02.
>
> Section 6.1 introduces IGMP/MLD translation, but I fear it is very 
> underspecified. Our own effort at specifying IGMP/MLD translation is 
> in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite 
> multicast would be better served by referencing our draft instead.
>
Thanks for your comments, while as stated in the text, the Interworking 
function is a combination of proxying (RFC4605) and translation 
(draft-ietf-mboned-64-multicast-address-format, sorry the reference was 
lost, we'll fix it).
The implementations vary, and we are trying to avoid deeply diving into 
that since it is sufficient for the implementers, and those should be 
detailed in some deployment document if needed. Anyway, please list what 
you think is missing, we can add more text to further clarify it. Thanks 
a lot!

Cheers,
Jacni

> So I would suggest replacing section 6.1 by a reference to the draft 
> above, which we hope to have adopted in the PIM WG shortly.
>
> Thanks,
> Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 05 Jun 2012 09:09:47 -0400

> (draft-ietf-mboned-64-multicast-address-format, sorry the reference was

I understand that. But note that this is an important new function. 
AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft 
would be underspecifying it IMHO, possibly leading to interoperability 
issues.

I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation.

> you think is missing, we can add more text to further clarify it. Thanks

At IETF 83 I showed this list to the PIM working group to demonstrate 
that IGMP/MLD translation is not as simple as people think it is. It's a 
list of things our draft (draft-perreault-mboned-igmp-mld-translation) 
specifies:

- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of 
proxy so as not to mess with Querier elections.
- Router Alert
   - IPv4 option ↔ Hop-by-Hop IPv6 extension header
   - Send on output IFF it was received on input.
   - Set value to zero unconditionally.
- Reports with unspecified source address need to be handled differently 
for IGMP vs MLD.
- Allocation of a “Translated” bit in IGMPv3 and MLDv2 Queries and Reports.
- Formulas for the conversion of MRD↔MRT with or without loss of precision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.

I don't want to argue this list in SOFTWIRE because I think it's the 
wrong forum. My point is that IGMP/MLD translation needs to be correctly 
specified, and it needs to be done in PIM. Any SOFTWIRE protocol that 
requires IGMP/MLD translation needs to refer to something coming from PIM.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 6 Jun 2012 15:43:26 +0200

+1
The IGMP/MLD translation is the key piece of this draft and needs to be
thorough.

In addition a general observation: This draft appears to have very little
in common with DS-Lite (nothing except use of IPinIP on my reading), and
using that reference and the AFTR terms is confusing. The fact that
technically it features an address family mapped multicast transport, which
alongside with the IGMP/MLD translation makes it anything but transparent
tunneling. A change of title would be also useful, as well as general
decoupling from the ds-lite architecture: The mAFTR device can, and likely
will be a often a dedicated multicast device that plays no part in unicast
forwarding.

-Woj.

On 5 June 2012 15:09, Simon Perreault <[email-masked]> wrote:

>>> in draft-perreault-mboned-igmp-**mld-translation. I feel that DS-Lite
>> (draft-ietf-mboned-64-**multicast-address-format, sorry the reference was
>> lost, we'll fix it).
>>
>
> I understand that. But note that this is an important new function. AFAIK
> IGMP/MLD translation doesn't exist in any other RFC. Your draft would be
> underspecifying it IMHO, possibly leading to interoperability issues.
>
> At IETF 83 I showed this list to the PIM working group to demonstrate that
> IGMP/MLD translation is not as simple as people think it is. It's a list of
> things our draft (draft-perreault-mboned-igmp-**mld-translation)
> specifies:
>
> I don't want to argue this list in SOFTWIRE because I think it's the wrong
> forum. My point is that IGMP/MLD translation needs to be correctly
> DTN made easy, lean, and smart --> http://postellation.viagenie.**ca<http://postellation.viagenie.ca>
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 6 Jun 2012 11:26:03 -0500

On Wed, Jun 6, 2012 at 8:43 AM, Wojciech Dec <[email-masked]> wrote:
> In addition a general observation: This draft appears to have very little in
> common with DS-Lite (nothing except use of IPinIP on my reading), and using
> that reference and the AFTR terms is confusing. The fact that technically it
> features an address family mapped multicast transport, which alongside with
> the IGMP/MLD translation makes it anything but transparent tunneling. A
> change of title would be also useful, as well as general decoupling from the
> ds-lite architecture: The mAFTR device can, and likely will be a often a
> dedicated multicast device that plays no part in unicast forwarding.
>

You mean, in order to be DS-Lite related it has to be tunneling based?

Actually, I did have a draft with such a solution.
Some people argued that we should not go for a tunneling solution
because there is already an inherent tunneling. So this draft was
chosen as the solution approach.

The philosophical question here is why do we have DS-Lite which does
tunneling on top of the inherent tunnel?

Behcet

---

From: <[email-masked]>
Date: Thu, 7 Jun 2012 14:51:03 +0200

Hi Simon,

We tried in this document to avoid as much as possible including implementation details but instead we focused on the external behaviour of the interworking functions. Let me recall there are already available implementations based on the specification of draft-ietf-softwire-dslite-multicast. A demo has been organized in one of the previous IETF meetings.

Now for your comment, we can see the IGMP/MLD IWF is basically RFC4605 + address translation (draft-ietf-mboned-64-multicast-address-format). Among the use cases of high priority identified in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.6, the IGMP/MLD IWF is only required for the use case described in draft-ietf-softwire-dslite-multicast. As such, does-it really make sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be efficient to have this elaborated in draft-ietf-softwire-dslite-multicast? I personally vote for the second option. Of course, if this approach is maintained, the document should be LCed also in PIM and MBONED.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Simon Perreault
>Envoyé : lundi 28 mai 2012 16:11
>À : Yong Cui
>Cc : [email-masked]
>Objet : Re: [Softwires] WG last call on 
>draft-ietf-softwire-dslite-multicast-02
>
>underspecified. Our own effort at specifying IGMP/MLD 
>translation is in 
>draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite 
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires
>

---

From: <[email-masked]>
Date: Thu, 7 Jun 2012 15:07:54 +0200

Hi Woj,

DS-Lite terminology is used in the sense that an IPv4 receiver is delivered (IPv4) multicast content (from an IPv4 source) over an IPv6 network.

The generic use case as described in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.1 is called 4-6-4. I personally agree to change the title to reflect this.

The document does not make any assumption about the location of AFTR and mAFTR: deployment considerations are out of scope. FWIW, mAFTR is defined as follows:

   o  Multicast AFTR (mAFTR): is a functional entity which supports
      IPv4-IPv6 multicast interworking function (refer to Figure 3).  It
      receives and encapsulates the IPv4 multicast packets into IPv4-in-
      IPv6 packets and behaves as the corresponding IPv6 multicast
      source for the encapsulated IPv4-in-IPv6 packets.

If you still think mAFTR terminology is confusing, we can change it to mBR (for multicast Border Router), 64mBR (IPv6/IPv4 Multicast Border Router), mIXF (multicast Interconnection Function), etc.

Cheers,

Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Wojciech Dec
Envoyé : mercredi 6 juin 2012 15:43
À : Simon Perreault
Cc : [email-masked]; Yong Cui
Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

In addition a general observation: This draft appears to have very little in common with DS-Lite (nothing except use of IPinIP on my reading), and using that reference and the AFTR terms is confusing. The fact that technically it features an address family mapped multicast transport, which alongside with the IGMP/MLD translation makes it anything but transparent tunneling. A change of title would be also useful, as well as general decoupling from the ds-lite architecture: The mAFTR device can, and likely will be a often a dedicated multicast device that plays no part in unicast forwarding.

-Woj.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Jun 2012 09:47:21 -0400

On 2012-06-07 08:51, [email-masked] wrote:
> Among the use cases
> of high priority identified in
> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.6,
> the IGMP/MLD IWF is only required for the use case described in
> draft-ietf-softwire-dslite-multicast.

The DS-Lite case is one instance of the 4-6-4 use case where 
encapsulation is used. Another instance of the 4-6-4 use case makes use 
of translation instead. That is not covered by the softwire draft.

The 6-4-6-4 use case is also high priority, requires IGMP/MLD 
translation, and is not covered by the softwire draft.

So we're looking at at least three use cases of IGMP/MLD translation, 
possibly more, of which only one is covered by the softwire draft.

> As such, does-it really make
> sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be
> efficient to have this elaborated in
> draft-ietf-softwire-dslite-multicast? I personally vote for the
> second option. Of course, if this approach is maintained, the
> document should be LCed also in PIM and MBONED.

I think IGMP/MLD translation should stand on its own for the reasons 
above, and it should be a PIM document.

Simon

---

From: <[email-masked]>
Date: Thu, 7 Jun 2012 16:00:37 +0200

Re-,

See inline. 

Cheers,
Med 

>De : Simon Perreault [mailto:[email-masked]] 
>Envoyé : jeudi 7 juin 2012 15:47
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Yong Cui; [email-masked]

Med: It was there; see http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-00#appendix-A.1. I failed to find back why we removed it in -01 of the draft. BTW, this is not a diffrent use case, only the way data is handled differs.

>translation, and is not covered by the softwire draft.

Med: I'm not sure there is a consenus about the urgency of 6-4-6-4 scenario. I knwo there is an operator representative voicing for it, but I always failed to understand that use case.

>possibly more, of which only one is covered by the softwire draft.

Med: I failed to count the three use cases..

>above, and it should be a PIM document.

Med: There is no PIM WG document  to cite at this stage. What is wrong with LCing this in PIM and MBONED?

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Jun 2012 10:08:17 -0400

> Med: There is no PIM WG document  to cite at this stage. What is wrong with LCing this in PIM and MBONED?

That could work. If PIM and MBONED say that this document is fine as it 
is, then that will settle it.

Simon

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Jun 2012 12:08:54 -0500

On Thu, Jun 7, 2012 at 8:07 AM,  <[email-masked]> wrote:
> Hi Woj,
>
> DS-Lite terminology is used in the sense that an IPv4 receiver is delivered
> (IPv4) multicast content (from an IPv4 source) over an IPv6 network.
>
> The generic use case as described in
> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.1 is
> called 4-6-4. I personally agree to change the title to reflect this.
>
> The document does not make any assumption about the location of AFTR and
> mAFTR: deployment considerations are out of scope. FWIW, mAFTR is defined as
> follows:
>
> If you still think mAFTR terminology is confusing, we can change it to mBR
> (for multicast Border Router), 64mBR (IPv6/IPv4 Multicast Border Router),
> mIXF (multicast Interconnection Function), etc.
>

So you are saying that this draft does not correspond to
Multicast extensions for DS-Lite?

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Thu, 07 Jun 2012 10:43:28 -0700

Here are my last call comments. I think substantial changes are
needed to the draft.

I understand that this draft is focusing on dslite. But it appears that
it is a generic solution. As it says in the draft:

    An IPv4 receiver accesses IPv4 multicast contents over an IPv6-
    only multicast-enabled network.

Based on this, I think the scope of the draft, the title and
introduction etc should be updated to actually show that it is
a generic approach. And then instead list dslite as one of the
scenarios where this is needed.

Since it is a generic approach, I think it should also be reviewed,
perhaps an additional WGLC, in mboned. pim wg may also have some
interest in reviewing it. There are some errors regarding pim in
this document.

In particular, it discussed translation of IGMP/MLD. This is a
topic that has been discussed in mboned/pim, and there is also
another draft discussing this.

It refers to draft-ietf-mboned-64-multicast-address-format-01. If that
is to stay, I think this draft needs to wait to see what happens with
the address-format draft in 6man. Changes may be needed in this draft
depending on what happens. If only minor changes, the examples in this
draft may need to be updated.

Technical issue:

In 4.2 it says:
    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
    to the MLD Querier in the IPv6 network.  The MLD Querier (typically
    acts as the PIMv6 Designated Router) 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.

As is noted, the MLD querier and the DR may be different routers.
It is the DR and not the MLD Querier (if they are different) that
sends the PIM join. Also note that they are often different. If
there are two routers, then the one with the lowest address is the
MLD querier, while the one with the highest address (unless DR
priority is configured) is the DR.

Near the end of 4.2:

    A branch of the multicast distribution tree is then grafted,
    comprising both an IPv4 part (from the mAFTR upstream) and an IPv6
    part (from mAFTR downstream to the mB4).

It says "is then grafted". So it sounds like the branch is added
to the tree after the procedure has finished. But basically it is
being added to the tree bit by bit as the joins are sent hop by
hop. Maybe it could say "is in this way grafted" or something.
I'm also a bit unsure whether "grafted" is a good term, as "graft"
has a specific meaning for PIM Dense Mode.

At the end of 4.2:

   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.

Yes, probably in the IGP. Perhaps say more explicitly that there must
be a route due to PIM's use of RPF. I see this is mentioned in 7.1
though.

In 6.1 it talks about IGMP messages being translated to MLD. I would
argue that this is not necessarily how this would be done.

If you look at a pure MLD proxy, you build state for various (*,G)
or (S,G) based on the reports you receive. Then based on this state
you create reports that you send upstream. It is not the message
from downstream that is just sent upstream. In this case, when
receiving downstream IGMP reports, they could be used to create the
IPv6 state. And then independent of whether the state was created
due to IGMP or MLD reports, reports are sent upstream, created from
that state. If you do this, messages are not translated.

In 7.1 it says:

    information to discover the source.  In order to pass the Reverse
    Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on the
    interfaces which has the shortest path to the uPrefix64.

Note that the shortest path might change due to topology changes, links
going down or coming up etc. So one would typically enable PIM on all
the routers. If one wants to constrain multicast to only some of the
topology, there are ways to build a separate multicast RIB for those
routers, and then enable PIM on all of them.

In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB
is something different. I think it should say TIB. Check the terms
MRIB and TIB in RFC 4601.

The draft assumes PIM-SM is used. I think the approach could also
be used with e.g. PIM Bidir (RFC 5015).

7.5 talks about scope, and mentions E and 8. Then it says that
this specification does not specify which scope to use. I would
perhaps not mention E and 8 then, it seems now to indicate that
those are the only alternatives.

The security considerations should probably be extended a bit.
E.g. what about scoping? Can one traverse a scoped boundary by
say joining a v4 scoped group using a join for a global v6
prefix?

The draft should point out that it is just plain IPv4 in IPv6. At
least that seems to be the intention. However, one might use the
same solution with other tunnel types, e.g. GRE.

Minor nits:

  o  PIMv4: refers to PIM when deployed in an IPv4 infrastructure
       (i.e., IPv4 transfer capabilities are used to exchange PIM
       messages).

    o  PIMv6: refers to PIM when deployed in an IPv6 infrastructure
       (i.e., IPv6 transfer capabilities are used to exchange PIM
       messages).

Replace transfer with transport?

Section 6.4 starts with this:

    If the mB4 function is implemented in the host which is directly
    connected to an IPv6-only network.  If an IPv4 application running in

I'm not exactly sure what the first "if" refers to. This needs to be
reformulated.

Also in 6.4 there is this typo: "implemntation".

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 07 Jun 2012 10:48:57 -0700

On 6/7/2012 10:08 AM, Behcet Sarikaya wrote:
> On Thu, Jun 7, 2012 at 8:07 AM,<[email-masked]>  wrote:
>> Hi Woj,
>>

I sent a separate review, but anyway, it is not an extension to
DS-Lite as I see it. It is a completely generic approach for
tunneling v6 through v4. It can certainly be deployed in DS-Lite
scenarios, but it is much more generic. I would like the title and
the text to reflect that.

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Jun 2012 13:20:24 -0500

> the text to reflect that.

So it means that this draft does not correspond to Softwire charter
item and we discover this quite late in the process.

My recommendation to the chairs is to read and double check the draft
before making an adoption call, especially if there is choice.

As I mentioned in my mboned mail, in multicast transition I think the
right approach is to agree to the fact that most of the host's
communication will be unicast. For unicast, v4-v6 transition has
already been well analyzed and several protocols have been specified.
Multicast extensions to those protocols are what we need.

Regards,

Behcet

---

From: <[email-masked]>
Date: Fri, 8 Jun 2012 07:38:45 +0200

Dear all,

>Multicast extensions for DS-Lite?
 
No.
 
This draft is designed to provide multicast services to DS-Lite serviced customers. This is the main mission of the draft.

But, the proposed approach can be applied for any other 4-6-4 use case (as defined in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00). 

Cheers,
Med

>De : Behcet Sarikaya [mailto:[email-masked]] 
>Envoyé : jeudi 7 juin 2012 19:09
>Cc : Wojciech Dec; [email-masked]; Yong Cui

---

From: <[email-masked]>
Date: Fri, 8 Jun 2012 07:48:34 +0200

Re-,

May I re-iterate:

* The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. 
* The draft proposes multicast extensions and not unicast ones.

Cheers,
Med

>Envoyé : jeudi 7 juin 2012 20:20
>À : Stig Venaas
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]; Yong Cui

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 8 Jun 2012 09:57:00 +0200

Hello Med,

there is no dependency here on ds-lite, ie This has all the hallmarks of a
standalone solution, which will almost certainly be implemented as such,
and one that will work with or without ds-lite for unicast.

Regards,
Woj.

---

From: <[email-masked]>
Date: Fri, 8 Jun 2012 10:43:09 +0200

Hi Woj,

Your comment is valid.

The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people.

Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft.

Cheers,
Med

________________________________
De : Wojciech Dec [mailto:[email-masked]]
Envoyé : vendredi 8 juin 2012 09:57
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]; Stig Venaas; [email-masked]; Yong Cui
Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

Hello Med,

there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast.

Regards,
Woj.

On 8 June 2012 07:48, <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

May I re-iterate:

Cheers,
Med

>De : Behcet Sarikaya [mailto:[email-masked]<mailto:[email-masked]>]
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]<mailto:[email-masked]>; Yong Cui
>On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas <[email-masked]<mailto:[email-masked]>> wrote:
>>> On Thu, Jun 7, 2012 at 8:07
>AM,<[email-masked]<mailto:[email-masked]>>  wrote:
>>>>
>
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Jacni Qin <[email-masked]>
Date: Fri, 08 Jun 2012 22:39:30 +0800

Re-,

> would be underspecifying it IMHO, possibly leading to interoperability 

To be honest, we've ever considered a separate draft to specify that 
function, but we finally dropped it in the last moment before 
submitting, since we realized during the preparation for the Demo in 
Taipei that it's actually not a new function, nor needs to be 
standardized anywhere, but more belongs to the scope of implementation.

The implements vary, one example could be: have both IPv4 and IPv6 
membership database maintained, then just synchronize the two through 
the address translation, all other things can be handled by the Proxying 
functionality (RFC4605).

> that IGMP/MLD translation is not as simple as people think it is. It's 
> a list of things our draft 
> (draft-perreault-mboned-igmp-mld-translation) specifies:
>
>   - IPv4 option ? Hop-by-Hop IPv6 extension header
> - Reports with unspecified source address need to be handled 
> differently for IGMP vs MLD.
> - Allocation of a "Translated" bit in IGMPv3 and MLDv2 Queries and 
> Reports.
> - Formulas for the conversion of MRD?MRT with or without loss of 
> precision.

You are doing a protocol translation, which is just one possible kind of 
implementations, and it's true that what you list above are required if 
you want to go this way, IMHO it is a complicated one.
As mentioned earlier, RFC4605 plus the address translation can also do 
that. And most columns you list will be avoid.

While I'm happy to see a deployment document to discuss the issues of 
implementations.

Cheers,
Jacni

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Jun 2012 10:34:49 -0500

Hi Med,

I agree with Woj.

I do not favor moving this draft to somewhere else.

Instead this draft should be revised to make it
Multicast extensions to DS-Lite as in the charter.

There is enough time to do it.

Regards,

Behcet

On Fri, Jun 8, 2012 at 3:43 AM,  <[email-masked]> wrote:
> Hi Woj,
>
> Your comment is valid.
>
> The point I wanted to make is to recall the initial motivation of this
> draft: solve an issue raised by DS-Lite people.
>
> Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This
> will be reflected in the updated version of the draft.
>
> Cheers,
> Med
>
> standalone solution, which will almost certainly be implemented as such, and
> one that will work with or without ds-lite for unicast.
>
> Regards,
> Woj.
>
>> >AM,<[email-masked]>  wrote:
>> >>>>
>> >

---

From: Stig Venaas <[email-masked]>
Date: Fri, 08 Jun 2012 09:58:48 -0700

> There is enough time to do it.

As this draft shows though, one can provide multicast in a DS-Lite
environment in an entirely generic way. I think that is great. It's
much better to have a general solution.

But this means the draft should be modified to reflect that. It is
great to have a draft describing this. Whether charter or not or
where it belongs is something I'm sure can be figured out. Right
now I'm more concerned about getting a good document.

Stig

>
> Regards,
>
> Behcet
>
> On Fri, Jun 8, 2012 at 3:43 AM,<[email-masked]>  wrote:
>> Hi Woj,
>>
>> Your comment is valid.
>>
>> On 8 June 2012 07:48,<[email-masked]>  wrote:
>>>
>>> Re-,
>>>
>>> May I re-iterate:
>>>
>>>> On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas<[email-masked]>  wrote:

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Jun 2012 12:58:00 -0500

On Fri, Jun 8, 2012 at 11:58 AM, Stig Venaas <[email-masked]> wrote:
> great to have a draft describing this.

A "general" solution using translation won't simply cut it for DS-Lite
which is a tunneling protocol.
No matter how hard you try.

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Fri, 08 Jun 2012 11:49:36 -0700

On 6/8/2012 10:58 AM, Behcet Sarikaya wrote:
> On Fri, Jun 8, 2012 at 11:58 AM, Stig Venaas<[email-masked]>  wrote:

This draft specifies a general solution using tunneling, and it looks
like a good solution to me. It also seems this general solution is
what at least the authors think is suitable in a DS-Lite environment.

This is all good. My main issue is that even though the draft specifies
a general solution, the draft pretends it is a DS-Lite specific
solution.

Stig

---

From: <[email-masked]>
Date: Mon, 11 Jun 2012 08:15:50 +0200

Hi Behcet,

I failed to understand the point you are trying to make.

The current situations is:

* this document provides multicast extension to deliver multicast to DS-Lite serviced customers
* we rely on multicast capabilities, as such no AMT-like considerations are included
* the proposed solution is generic and can be deployed in any 4-6-4 use case

What should be revised?

Thanks for your help.

Cheers,
Med 

>Envoyé : vendredi 8 juin 2012 17:35
>Cc : Wojciech Dec; Stig Venaas; [email-masked]; Yong Cui
>>> * The draft is designed to allow the delivery of multicast 
>services to
>>> DS-Lite serviced customers.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Jun 2012 11:08:19 -0500

Hi Med,

Thanks for your kind reply. I was talking about

http://tools.ietf.org/html/draft-sarikaya-softwire-dslite6rdmulticast-00
(which is now expired, I'll explain why below)

Profiting the occasion, let me clarify that the chairs, Alain
initially asked the two drafts to be merged.
We favored the merger but Med was against.

draft-ietf-softwire-dslite-multicast-02 presents a generic v4 to v6
multicast translation technique and as has been indicated such an
approach has nothing to do with DS-Lite, i.e. DS-Lite does not
translate unicast v4 packets into unicast v6 packets. I hope this is
well understood.

As such, draft-ietf-softwire-dslite-multicast-02 is suitable for
NAT64, (remind you that there is already a multicast solution draft
for NAT64).

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Mon, 11 Jun 2012 12:07:20 -0700

> * this document provides multicast extension to deliver multicast to DS-Lite serviced customers

But not only DS-Lite.

> * the proposed solution is generic and can be deployed in any 4-6-4 use case

Agree it is generic, and I think the draft should be revised to reflect 
that.

Stig

---

From: Tina TSOU <[email-masked]>
Date: Mon, 11 Jun 2012 20:21:16 +0000

If we r looking for a generic encapsulation for multicast transition, here it is.
http://datatracker.ietf.org/doc/draft-tsou-softwire-encapsulated-multicast/

Tina
408-859-4996

On Jun 11, 2012, at 12:08 PM, "Stig Venaas" <[email-masked]> wrote:

> Agree it is generic, and I think the draft should be revised to reflect that.
> 
> Stig
> 
>> What should be revised?
>> 
>> Thanks for your help.
>> 
>> Cheers,
>> Med
>>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 11 Jun 2012 13:31:29 -0700

> http://datatracker.ietf.org/doc/draft-tsou-softwire-encapsulated-multicast/

In a way, your draft is even more generic Tina. There are also some
differences.

You're talking about a stateful mapping function and a protocol for
requesting mappings. This is avoided here by using a stateless mapping.

But roughly speaking, I think your general description Tina, may also
include what this draft does.

Stig

> Tina
> 408-859-4996
>
> On Jun 11, 2012, at 12:08 PM, "Stig Venaas"<[email-masked]>  wrote:
>

---

From: Jacni Qin <[email-masked]>
Date: Tue, 12 Jun 2012 16:34:10 +0800

Dear Woj, all,

Sorry, my mail box's filter function got some problems, so I missed most 
of the discussions.

I echo Med's comments, it's been stated cleared as below, the scope and 
the reason why we use that title, thanks!

Cheers,
Jacni

On 6/8/2012 Friday 4:43 PM, [email-masked] wrote:
> Evidently, the proposed approach can be deployed in any 4-6-4 
> scenario. This will be reflected in the updated version of the draft.
> Cheers,
> Med
>
>     ------------------------------------------------------------------------
>     *De :* Wojciech Dec [mailto:[email-masked]]
>     *Envoyé :* vendredi 8 juin 2012 09:57
>     *À :* BOUCADAIR Mohamed OLNC/NAD/TIP
>     *Cc :* [email-masked]; Stig Venaas; [email-masked]; Yong Cui
>     *Objet :* Re: [Softwires] WG last call on
>     there is no dependency here on ds-lite, ie This has all the
>     hallmarks of a standalone solution, which will almost certainly be
>     implemented as such, and one that will work with or without
>     ds-lite for unicast.
>
>     Regards,
>     Woj.
>
>     On 8 June 2012 07:48, <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Re-,
>
>         May I re-iterate:
>
>         services to DS-Lite serviced customers.
>         >AM,<[email-masked]
>         <mailto:[email-masked]>>  wrote:
>         >>>>
>         >
>         [email-masked] <mailto:[email-masked]>

---

From: Jacni Qin <[email-masked]>
Date: Tue, 12 Jun 2012 16:34:20 +0800

Hi Stig,

Sorry I missed the discussion, and your comments, inline please, hope it 
won't be too late.

> draft may need to be updated.
Thanks, it's true. We'll wait for the comments from 6man, and update it 
accordingly if needed.

> priority is configured) is the DR.
I understand your concern. I guess the Proxying spec solved this issue.

> has a specific meaning for PIM Dense Mode.
Thanks for your suggestion, we'll reword it, and make it clarified.

> be a route due to PIM's use of RPF. I see this is mentioned in 7.1
Ok.

> argue that this is not necessarily how this would be done.
Right, I agree with you. Please see my response to Simon, we can update 
the text to clarify that.

> routers, and then enable PIM on all of them.
The text just focuses on the special configuration, I understand your 
concern that it's a little confusing.
Maybe we can add some text like "... as prerequisites, basic multicast 
related configurations should be done accordingly ..."

> MRIB and TIB in RFC 4601.
I'll check the terms again.

> be used with e.g. PIM Bidir (RFC 5015).
Ok, we'll discuss this and come back to you on this point.

> those are the only alternatives.
Fine.

> say joining a v4 scoped group using a join for a global v6
Ok, we'll consider that.

> same solution with other tunnel types, e.g. GRE.
We have a similar intention as the DS-Lite spec., we can some text.

> Minor nits:
Thanks, done.

> Also in 6.4 there is this typo: "implemntation".

Thanks again for your careful review and comments.

Cheers,
Jacni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Jun 2012 15:11:07 -0500

I think that a decision should be made on this draft. If it is going
to present a generic solution it could be fine but then such a draft
does not meet Softwire charter item so it can not stay in Softwire.

My suggestion is to make it specific to DS-Lite so that it stays in
Softwire and meets the charter item.

I believe this was Alain's intention when he asked the two drafts to be merged.

Regards,

Behcet

On Tue, Jun 12, 2012 at 3:34 AM, Jacni Qin <[email-masked]> wrote:
> Right, I agree with you. Please see my response to Simon, we can update the
> text to clarify that.
>
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 12 Jun 2012 16:16:04 -0400

Well, it is still in the Softwires domain if it tunnels the multicast 
data, is it not?

> I believe this was Alain's intention when he asked the two drafts to be merged.
...

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Jun 2012 15:30:37 -0500

On Tue, Jun 12, 2012 at 3:16 PM, Tom Taylor <[email-masked]> wrote:
> Well, it is still in the Softwires domain if it tunnels the multicast data,
> is it not?

It is not the case in the draft currently, check Sections 4.3 & 6.2.

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Tue, 12 Jun 2012 13:46:15 -0700

> Softwire and meets the charter item.

What do you mean by making it specific to DS-Lite? Are you talking
about a different technical solution, or just wording? Right now the
technical solution is generic, and I think that is great. While the
wording seems DS-Lite specific to me.

I don't like the idea of doing something DS-Lite specific, unless one
can come up with a better technical solution that way.

I think the technical solution in this draft is fine. Please let's not
change it into a poor technical solution just to satisfy possible
charter considerations.

Stig

> On Tue, Jun 12, 2012 at 3:34 AM, Jacni Qin<[email-masked]>  wrote:
>> Hi Stig,
>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 12 Jun 2012 20:56:07 +0000

Hi Behect, 

You confuse me. 4.3 said this:

"When the mAFTR receives an IPv4 multicast packet, it will encapsulate
   the packet into an IPv6 multicast packet using the IPv4-embedded IPv6
   multicast address as the destination address and an IPv4-embedded
   IPv6 unicast address as the source address."

The data packets are tunneled over IPv6 hub by hub. That said, the tunnel
isn't end-to-end.

Thanks,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 12 Jun 2012 21:49:27 +0000

+1

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Jun 2012 17:22:49 -0500

Hi Yiu,

The solution in this draft is generic, it simply leaves DS-Lite aside
and builds its own stuff.
I think this fact has been alluded to by the co-authors.

This should change. Saying that a solution that integrates with
DS-Lite is technically poor solution is saying that DS-Lite is
technically poor solution.

Behcet

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 08:04:09 +0200

Behcet,

What is wrong with those sections? 
Can you provide the excerpt you are referring to? Thanks.

The section you are pointing to describes exclusively encapsulation/decapsulation.

Cheers,
Med 

>[mailto:[email-masked]] De la part de Behcet Sarikaya
>Envoyé : mardi 12 juin 2012 22:31
>À : Tom Taylor
>Cc : [email-masked]
>>> I believe this was Alain's intention when he asked the two 
>drafts to be
>>> merged.
>>>
>>> Regards,
>>>
>>> Behcet
>>>
>> ...

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 08:54:05 +0200

Behcet,

If you are suggesting we need get rid of multicast capabilities and use unicast between the AFTR and B4, I still claim this is a bad design choice. The rationale for the design documented in the draft is as follows (excerpt from the draft):

"
   If customers have to access IPv4 multicast-based services through DS-
   Lite environment, Address Family Transition Router (AFTR) devices
   will have to process all the IGMP Report messages [RFC2236] [RFC3376]
   that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels.
   From that standpoint, AFTR devices are likely to behave as a
   replication point for downstream multicast traffic.  And the
   multicast packets will be replicated for each tunnel endpoint where
   IPv4 receivers are connected to.

   This kind of DS-Lite environment raises two major issues:

   1.  The IPv6 network loses the benefits of the multicast traffic
       forwarding efficiency because it is unable to deterministically
       replicate the data as close to the receivers as possible.  As a
       consequence, the downstream bandwidth in the IPv6 network will be
       vastly consumed by sending multicast data over a unicast
       infrastructure.

   2.  The AFTR is responsible for replicating multicast traffic and
       forwarding it into each tunnel endpoint connecting IPv4 receivers
       that have explicitly asked for the corresponding contents.  This
       process may greatly consume AFTR's resources and overload the
       AFTR.

   This document specifies an extension to the DS-Lite model to deliver
   IPv4 multicast services to IPv4 clients over an IPv6 multicast-
   enabled network.
"

For me, DS-Lite model is not only what is documented in RFC6333 but covers also stateless A+P including MAP and 4rd. 

Hope this clarifies your concern.

Cheers,
Med 

>Envoyé : mercredi 13 juin 2012 00:23
>À : Lee, Yiu
>Cc : [email-masked]

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 09:03:44 +0200

Re-,

Did you read draft-ietf-softwire-dslite-multicast? 

I have some doubts given your message below. 

Cheers,
Med

>Envoyé : lundi 11 juin 2012 18:08
>>>hallmarks of a

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Jun 2012 15:18:21 -0500

Hi Med,

>   IPv4 multicast services to IPv4 clients over an IPv6 multicast-

There is a price for this. Many operators are willing to deploy IPv6
unicast only. If they deploy both unicast multicast IPv6 then they
prefer to deploy dual stack network in which case there is no
transition problem, see the discussion on Mboned list.

> For me, DS-Lite model is not only what is documented in RFC6333 but covers also stateless A+P including MAP and 4rd.

Well, that is a different problem that requires a different solution.

You are confirming again that your draft does not care about DS-Lite.
You are looking at anything else but DS-Lite.

> Hope this clarifies your concern.

If you don't like unicast DS-Lite solution, it is not the job of
multicast DS-Lite solution to resolve it.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Jun 2012 13:23:34 -0500

Folks,

We have published revised version of our draft on multicast extensions
to DS-Lite at

http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt

We think that this draft should be part of draft-ietf-softwire-dslite-multicast.

Regards,

Behcet

---

From: Jacni Qin <[email-masked]>
Date: Mon, 25 Jun 2012 14:09:01 +0800

Hi Behcet, all,

> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt

It's been discussed on the list and in the 81st meeting, and concluded 
quite clearly by the WG why this is abandoned.
It tunnels the IGMP packets upwards, replicates the multicast traffic 
"per tunnel", opposite to the property of multicast technology. And 
these are problems we're trying to solve.

There is no necessity to initiate that kind of discussion once again.

Cheers,
Jacni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Jun 2012 13:50:32 -0500

On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin <[email-masked]> wrote:
> It's been discussed on the list and in the 81st meeting, and concluded quite
> clearly by the WG why this is abandoned.
> It tunnels the IGMP packets upwards, replicates the multicast traffic "per
> tunnel", opposite to the property of multicast technology. And these are
> problems we're trying to solve.
>

 draft-ietf-softwire-dslite-multicast-02 has nothing to do with
DS-Lite and therefore it is not a DS-Lite multicast extensions
document as the charter requires.
OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates
multicast into DS-Lite tunnel.

It is not against multicast technology.

> There is no necessity to initiate that kind of discussion once again.

I did not start this discussion. Please check the list.

Regards.

Behcet

---

From: Jacni Qin <[email-masked]>
Date: Tue, 26 Jun 2012 07:36:41 +0800

Re-,

On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote:
> On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin<[email-masked]>  wrote:
>> Hi Behcet, all,
>>
>>
In this way, the efficiency is lost. If operators put the AFTR box 
deeply in the network, far from the end users, as you process the 
singling messages and replicate of traffic per tunnel, the network and 
the box will crash because of the huge burden.

> I did not start this discussion. Please check the list.

Again please see above, or check the archive and the offlist messages 
where we've explained it to you in detail.

Cheers,
Jacni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 27 Jun 2012 10:30:59 -0500

On Mon, Jun 25, 2012 at 6:36 PM, Jacni Qin <[email-masked]> wrote:
>>> "per
> In this way, the efficiency is lost. If operators put the AFTR box deeply in
> the network, far from the end users, as you process the singling messages
> and replicate of traffic per tunnel, the network and the box will crash
> because of the huge burden.
>

That's a big IF. Not everybody has to do it the same way.

The solution in draft-ietf-softwire-dslite-multicast-02
builds itself something without considering what DS-Lite is doing.
As I told you before, DS-Lite unicast is a tunneling technology. If
you don't like it it is not DS-Lite multicast to fix this.
How many times this should be reminded to you?

> Again please see above, or check the archive and the offlist messages where
> we've explained it to you in detail.

I also had explained to you that the chairs wanted the two drafts
merged in detail.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 27 Jun 2012 13:08:17 -0700

FWIW, here is my take on this.

On 6/27/2012 8:30 AM, Behcet Sarikaya wrote:
[...]
> How many times this should be reminded to you?

draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing
specific to DS-Lite, and I've been saying that the draft should be
updated to reflect that.

However, even though it is generic, I think it is a good solution for
use in DS-Lite deployments (in addition to many other deployments).

Whether additional solutions are needed for DS-Lite is something the
WG should consider. Maybe it already has, I haven't paid enough
attention.

Stig

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Jun 2012 22:18:03 +0200

+1

The name and references to ds-lite terminology in the draft are misleading
and should be revised.

On 27 June 2012 22:08, Stig Venaas <[email-masked]> wrote:

>> The solution in draft-ietf-softwire-dslite-**multicast-02
> draft-ietf-softwire-dslite-**multicast-02 is a generic solution, nothing

---

From: Jacni Qin <[email-masked]>
Date: Thu, 28 Jun 2012 12:35:22 +0800

> That's a big IF. Not everybody has to do it the same way.
No, even you distribute AFTRs in the networks, e.g., co-locate the boxes 
beside BRAS/BNGs, the problems are still there.

> builds itself something without considering what DS-Lite is doing.
Not true, please see below.

> How many times this should be reminded to you?
Let's remind you again,
What you described in your approach ("Simply enabling multicast based on 
RFC6333") is the problem that needs to be solved.
You're running multicast inside the UNICAST tunnels between B4s and AFTR.

By contrast, we considered it.
If following your approach to run multicast in the DS-Lite deployment 
(as stated earlier, we just consider this scenario), there will be 
problems (e.g., lost of efficiency of multicast, burden of network and 
devices, ... please see above).
That is what we're trying to solve in draft-ietf-softwire-dslite-mulitcast.

> I also had explained to you that the chairs wanted the two drafts
No, it's been clarified during the meeting and previous discussions, 
that your approach is the problem that needs to be solved.

Cheers,
Jacni

---

From: Jacni Qin <[email-masked]>
Date: Thu, 28 Jun 2012 13:24:21 +0800

Hi Stig,

Thanks for you comments and support, please see below inline.

> use in DS-Lite deployments (in addition to many other deployments).
As discussed in the previous messages of the thread, our motive is solve 
the problems
for those who want multicast in their DS-Lite deployment.
So we limited the scope. Where the DS-Lite is not deployed, it doesn't 
apply.

If some pieces of the approach can be reused in the future, to solve the 
multicast issues in
other deployments, that'd be good.
While personally, I'd prefer we stay focus on the currently scenario.
Extensions if needed, may be raised respectively for other deployments.
More are detailed in, 
http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00.

Cheers,
Jacni

---

From: Tom Taylor <[email-masked]>
Date: Thu, 28 Jun 2012 03:53:23 -0400

My view has been similar to yours, with a twist: that the generic 
document could be followed up by documents that describe how the generic 
architecture relates to specific transition architectures like that of 
DS-Lite.

Tom Taylor

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Jun 2012 10:20:48 -0700

> So we limited the scope. Where the DS-Lite is not deployed, it doesn't

I understand that the motive is to have a solution for DS-Lite, but IMO
the key part is the solution itself. I think you should focus on the
solution and then discuss how it can be used in several scenarios, where
DS-Lite is one of them.

Wouldn't it be a shame if people have a need for your solution, but are
not aware of it, or doesn't consider it because they think it only
applies to DS-Lite?

Don't you agree that we should generally find good generic solutions and
describe them as such? We don't want to write basically identical docs
for each scenario. And in the worst case instead of having a single good
solution, having solutions that are only almost identical, maybe
requiring multiple slightly different implementations to solve each of
the problems, where a single solution and a single implementation would
be sufficient?

As a general principle when you come up with a solution to a problem,
don't you try to see what else it can solve, and try to present it as
a solution to all the problems? At least that is always my thinking.

It looks like we may disagree on this. I'm hoping I can make people see
the merits of making general solutions and presenting them as such. At
least for me, that seems like a good thing to strive for.

I know I've been repeating myself several times in emails to the list.
I feel strongly about this as a general principle. I don't know what
more I can say to stress my point though.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 28 Jun 2012 10:27:27 -0700

> architecture relates to specific transition architectures like that of

That sounds reasonable. But unless there are additional technical
considerations for how it applies to DS-Lite that need to be considered,
then I think it can be sufficient in the doc for the generic solution,
to state that it can be used in scenarios such as DS-Lite.

All I'm asking for is changing the title, and a bit of the abstract and
introduction to make it generic. As long as it doesn't look like just a
DS-Lite solution, I don't mind if there is some discussion of how it
applies to DS-Lite in the same doc. It could even say that the work
started out as a way of solving multicast for DS-Lite, but that this
generic solution was seen as the best approach.

Stig