Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03 (fwd)

[Pekka Savola <pekkas at netcore.fi>]

Re-sending as this was probably accidentally rejected by the list
administrator (for the policy, see
http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt).

---------- Forwarded message ----------
Date: Mon, 16 Jan 2006 18:58:43 +0200 (EET)
From: Pekka Savola <pekkas at netcore.fi>
To: Thomas Morin <thomas.morin at rd.francetelecom.com>
Cc: l3vpn at ietf.org
Subject: Re: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03

On Mon, 16 Jan 2006, Thomas Morin wrote:
> Well, AFAIK, IPv6 support for PPVPN solution seems to be more the
> exception than the rule: v6 support is in l3vpn charter,
> draft-ietf-l3vpn-bgp-ipv6 is in "IESG Evaluation" state. Dunno about VR.

It'd be interesting to hear more comments on this.

> > > > 5.1.11.  RP Engineering
> > > >
> > > >     When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer
> > > >     side, the location of the RP has to be chosen.  In some cases this
> > > >     engineering problem is not trivial: for instance, if sources and
> > > >     receivers are located in VPN sites that are different than that of
> > > >     the RP, then traffic may flow twice through the SP network and the
> > > >     CE-PE link of the RP (from source to RP, and then from RP to
> > > >     receivers) ; this is obviously not ideal.  A multicast VPN solution
> > > >     SHOULD propose a way to help on solving this RP engineering issue.
> > > >
> > > > ==> I'm not sure if this specific problem exists in practice.  If the
> > > > RP sends Register-Stop, the multicast traffic is forwarded natively,
> > > > and the data will short-cut inside the site without going to the RP
> > > > and then back.  I.e., there should not be two times traffic once the
> > > > forwarding is native.
> > >
> > > Well...
> > > 1) even such transient peaks may not be something that you'll want
> > > 2) what if you lose connectivity to the remote site hosting the RP, are
> > > you happy to lose local multicast on every other site?
> > > 3) what if you want to stick with RPT ?
> > >   [okay, maybe not so relevant, but what if the VPN customer wants to
> > >    do this ?]
> >
> > I should have been more specific.  I agree that the "RP engineering"
> > problem exists: deciding where to put the RP has many different
> > tradeoffs to consider -- there isn't a one-size-fits-all approach.
> >
> > I was commenting on the double traffic issue specifically, 1) above.
> > I don't think it really exists for valid configurations.  RPs tend to
> > send Register-Stop *immediately* so you shouldn't see even a transient
> > peak (longer than less than a second that is) due to this.
>
> Sorry, but isn't "a second" (even a very short one), transient ?
> Also, what does "immediately" mean (especially across a multicast VPN
> and a provider core) ?

When the RP receives a Register message, it will (basically) send a 
Register-Stop immediately, see section 4.4.2 of the new PIM-SM spec. So, we're 
talking about 1 RTT between the DR and the RP.  I doubt this is a major problem 
-- the other RP engineering decisions are probably much more pressing.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings