Subject: Re: [Softwires] draft-ietf-softwire-mesh-multicast-05.txt

From: Shu Yang <[email-masked]>
Date: Tue, 16 Jul 2013 21:03:04 +0800

Dear Behcet,

> If Softwire mesh means packets from the host to
> one CE are directly routed to the destination CE, I
> am puzzled how multicast can be supported in such a network?

In Softwire mesh multicast, packets from source host are first
routed to AFBR (address family border router), using multicast.
Then packets travel through the core towards another AFBR
(as the core runs MPBGP), with either unicast or multicast.
At last, packets are routed to the destination, with multicast
again.

Your further review and comments are more than welcome.

Best Regards,
Shu Yang

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 16 Jul 2013 14:07:58 -0500

Dear Shu,

Please see inline.

Regards,

Behcet

> At last, packets are routed to the destination, with multicast
My question is not about how you propose to support multicast.

But my question is a very fundamental  one. I think that mesh architecture
is a very specific architecture. It seems that it will work only for
unicast.

As to your approach, of course you can do things like that but that would
also work for non mesh architecture, right?

---

From: Shu Yang <[email-masked]>
Date: Wed, 17 Jul 2013 22:46:20 +0800

Hi, Dear Behcet,

> But my question is a very fundamental  one. I think that mesh architecture is
> a very specific architecture. It seems that it will work only for unicast.

In Section 11 of RFC5565,  it's recommended that softwire multicast be supported
within the mesh framework.

Best Regards,
Shu Yang

On Wed, Jul 17, 2013 at 3:07 AM, Behcet Sarikaya <[email-masked]> wrote:
> But my question is a very fundamental  one. I think that mesh architecture is a very specific architecture. It seems that it will work only for unicast.
>
> As to your approach, of course you can do things like that but that would also work for non mesh architecture, right?
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Jul 2013 11:47:51 -0500

Hi Shu,

I was referring to the mesh mode as opposed to hub and spoke mode (in
http://tools.ietf.org/html/draft-ietf-softwire-map-07).

I think that mesh mode and the softwire mesh (in RFC 5565) are two
different things. I must admit that I don't know the mesh architecture you
are talking about and don't have time to study it these days.

Regarding your draft, you define AFBR. I checked other Softwire transition
protocols, I could not find such an entity.
It is puzzling to me.

Regards,

Behcet

On Wed, Jul 17, 2013 at 9:46 AM, Shu Yang <[email-masked]> wrote:

> > But my question is a very fundamental  one. I think that mesh
> architecture is a very specific architecture. It seems that it will work
> only for unicast.
> >
> > As to your approach, of course you can do things like that but that
> would also work for non mesh architecture, right?
> >
> >

---

From: Shu Yang <[email-masked]>
Date: Thu, 18 Jul 2013 23:40:35 +0800

Hi, Dear Behcet,

> http://tools.ietf.org/html/draft-ietf-softwire-map-07).
In my memory, the two modes were also defined in RFC 4925, which
defined the softwire problem, including softwire mesh and softwire hub
and spoke. Then RFC 5565 provided the framework for softwire mesh. We
are motivated by multicast routing within softwire mesh.

> protocols, I could not find such an entity.
AFBR was defined in RFC 5565.

Best Regards,

Shu Yang

On Thu, Jul 18, 2013 at 12:47 AM, Behcet Sarikaya
<[email-masked]> wrote:
> I think that mesh mode and the softwire mesh (in RFC 5565) are two different
> things. I must admit that I don't know the mesh architecture you are talking
> about and don't have time to study it these days.
>
>> > architecture is