Subject: Re: [Softwires] Updates on H&S framework draft

From: "Greg Shepherd" <[email-masked]>
Date: Mon, 19 Mar 2007 10:07:27 -0700

While I agree with the mcast portion of the draft - mcast protocols run over
the tunnels - there's no mention of the protocol end-points; ie - is the hub
expected to be part of the mcast topology, replicating accordingly?

Thanks,
Greg

On 2/16/07, Bruno STEVANT <[email-masked]> wrote:
>
> Hi all,
>
> Carlos and I finally got an update on the H&S draft out yesterday.
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-
> l2tpv2-03.txt
>
> Now we ask to anyone on the list to take 10 minutes of their time and
> read this version carefully.
> Any remarks and comments are welcome ! From these feedbacks we hope
> to release a new version before the cut-off for Prague.
>
> Enjoy your read !
> --
> Bruno STEVANT - ENST Bretagne
>
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Bruno STEVANT <[email-masked]>
Date: Mon, 19 Mar 2007 18:48:52 +0100

For the Mesh framework, it makes sense to have multicast  
considerations included in the Framework document.
For the H&S framework, deploying multicast is mostly to give to the  
involved components of a Softwire a role in the multicast topology.  
No special encap., signaling, etc.
But there is still some scenarios to explore : ASM/SSM, emmitter and  
receiver between SI ... This will probably be part of a separate  
document, which will be guidelines for deployment.

Le 19 mars 07 à 18:07, Greg Shepherd a écrit :

> While I agree with the mcast portion of the draft - mcast protocols  
> run over the tunnels - there's no mention of the protocol end- 
> points; ie - is the hub expected to be part of the mcast topology,  
> replicating accordingly?
>
> Thanks,
> Greg
>

---

From: "Greg Shepherd" <[email-masked]>
Date: Mon, 19 Mar 2007 10:57:00 -0700

> No special encap., signaling, etc.

I was addressing the question as to whether the hub is part of the L3
infrastructure (and therefore running PIM) or is just an L2 dumb hub
(transiting/broadcasting PIM messages to the other spokes) - neither appear
as deployment-only issues to me. Either way it will need some mcast smarts
and should be addressed in the draft.

> document, which will be guidelines for deployment.

Again, I don't see these as deployment issues but as actual hub
functionality issues.

Greg

---

From: Bruno STEVANT <[email-masked]>
Date: Mon, 19 Mar 2007 22:31:16 +0100

Le 19 mars 07 à 18:57, Greg Shepherd a écrit :
> I was addressing the question as to whether the hub is part of the  
> L3 infrastructure (and therefore running PIM) or is just an L2 dumb  
> hub (transiting/broadcasting PIM messages to the other spokes) -  
> neither appear as deployment-only issues to me. Either way it will  
> need some mcast smarts and should be addressed in the draft.
>

The hub (or Softwires Concentrator as we call it) has one main  
connection to the IPv6 network and several tunnels.
In Phase 0, using L2TPv2, bridging between tunnel and main connection  
(Ethernet) is not possible (or am I wrong somewhere ?)
So SC is part of L3 infrastructure as a router, and indeed should  
include features to enable multicast.

Softwires Problem Statement mentions Multicast as one of the  
requirement as :
"Existing multicast solutions can be used over the softwire."

I think we addressed that requirement sufficiently with :
"Multicast protocols simply run over L2TPv2 Softwires transparently  
together with other regular IP traffic."

Now what about the SC role in the multicast infrastructure ?
We shall also ask the same question about the SI.
Should they be proxy ? Multicast router ?

I think that answering such question is already talking about  
deployment. And therefore this should be addressed in a separate  
document.
-- 
Bruno STEVANT - ENST Bretagne

---

From: "Greg Shepherd" <[email-masked]>
Date: Mon, 19 Mar 2007 15:01:58 -0700

> deployment. And therefore this should be addressed in a separate

Maybe I'm miss-understanding the use of the work "deployment". These sound
like implementation issue.

Greg

--