Re: WG last call: draft-ietf-l3vpn-ppvpn-mcast-reqts-03

[Marshall Eubanks <marshall.eubanks at gmail.com>]

Hello;

On 1/18/06, Thomas Morin <thomas.morin at rd.francetelecom.com> wrote:
> Hi Marshall,
>
> Marshall Eubanks:
> > > >    The use of globally unique means of multicast-based service
> > > >    identification at the scale of the domain where such services are
> > > >    provided SHOULD be recommended.  If the ASM model is used, this
> > > >
> > > > tme> SSM also has source scoping, 239/8 can be used with either SSM or ASM. Therefore
> > > > tme> s/If the ASM model is used, this/For IPv4 multicasts, this/
> > >
> > > I rephrased as follows:
> > >
> > > "For IPv4 multicast, this implies the use of the multicast
> > > administratively scoped range, (239/8 as defined by [RFC2365]) for
> > > services which are to be used only inside the VPN, and of or SSM-range
> >
> > s/of or SSM-range/of either global SSM-range/
> >
> > to correct a typo and to make it clear that 232 is intended for global
> > scope SSM.
>
> Agreed.
>
> > > >    Unwanted multicast traffic (e.g. multicast traffic that may be sent
> > > >    by a source located somewhere in the Internet and for which there is
> > > >    no interested receiver connected to a given VPN infrastructure) MUST
> > > >    NOT be propagated within a multicast-enabled VPN.
> > > >
> > > > tme> Is this consistent with Section 5.2.2.3. ? It seems to me that this
> > > > tme> should be a SHOULD NOT to allow for sub-optimal solutions
> > >
> > >
> > > While it might be acceptable (for provider-side scalability) that some
> > > traffic reaches a PE even if this is not needed, it would not be
> > > acceptable that such traffic be propagated toward the CE, inside the
> > > customer network.
> > >
> > > Isn't this reasonable ?
> >
> > Reasonable, but in normal multicast it is common to get multiple
> > packets when trees switch over.
>
> A bit of misunderstanding here: we are just mandating that, in the same
> way that traffic from a VPN doesn't reach another VPN, Internet
> multicast traffic won't be routed inside a VPN that didn't make any such
> multicast subscription.
>
> In normal multicast, you are not supposed to route @G traffic to
> somebody who only subscribed to @G' and @G'', right ?
>

Yes, I agree. I was misunderstanding your meaning.

I think it is necessary to see the whole document again with the
various corrections to be sure these are all correct.

> -Thomas
>

Marshall

>