Mailing List Archive

On 04/06/2014 16:57, James Small wrote:

> 1)There is no MSDPv6 and probably never will be. Of course you have SSM
> and Embedded RP but that doesn’t cover all cases. For example – if you
> have a partnership with another organization and only want to share
> select multicast groups/sources then in IPv4 you use MSDP and MSDP
> filters. However, I don’t see how to do this with IPv6 multicast.

Well, in IPv4 on IOS you want both MSDP filtering and "ip multicast
boundary", which filters both PIM control and data-plane traffic.

Sadly it would appear IOS has dropped ACLs for boundary on PIM6, and
assumed that the IPv6 mcast scope is sufficient for all use-cases!

NX-OS has "ipv6 pim jp-policy" and "match ipv6 multicast" options in
route-map, but this seems to be lacking from IOS.

JunOS of course has it.

It seems you can't do this right now on Cisco IOS?

Thanks Phil.

What about inter-domain IPv6 multicast? It's SSM, Embedded-RP, or bust?
That seems rather limiting but maybe that's how it is.

Also - if you can't really have multiple PIM domains (or can't live with
above restrictions) do you just use one gigantic PIMv6-Anycast domain? Is
that the best practice and you rely on Anycast to keep traffic "local?"

--Jim

> -----Original Message-----
> From: ipv6-ops-bounces+jim.small=mail.com@lists.cluenet.de [mailto:ipv6-
> ops-bounces+jim.small=mail.com@lists.cluenet.de] On Behalf Of Phil Mayers
> Sent: Wednesday, June 04, 2014 2:52 PM
> To: ipv6-ops@lists.cluenet.de
> Subject: Re: Large IPv6 Multicast Domains
>
> On 04/06/2014 16:57, James Small wrote:
>
> > 1)There is no MSDPv6 and probably never will be. Of course you have SSM
> > and Embedded RP but that doesn't cover all cases. For example - if you
> > have a partnership with another organization and only want to share
> > select multicast groups/sources then in IPv4 you use MSDP and MSDP
> > filters. However, I don't see how to do this with IPv6 multicast.
>
> Well, in IPv4 on IOS you want both MSDP filtering and "ip multicast
> boundary", which filters both PIM control and data-plane traffic.
>
> Sadly it would appear IOS has dropped ACLs for boundary on PIM6, and
> assumed that the IPv6 mcast scope is sufficient for all use-cases!
>
> NX-OS has "ipv6 pim jp-policy" and "match ipv6 multicast" options in
> route-map, but this seems to be lacking from IOS.
>
> JunOS of course has it.
>
> It seems you can't do this right now on Cisco IOS?

Hi Jim and list,

first off, I've done some IPv6 multicast routing but I've never been
unlucky enough not to deal with it over IPv4.

> 1)      There is no MSDPv6 and probably never will be.  Of course you
> have SSM and Embedded RP but that doesn’t cover all cases.  For
> example – if you have a partnership with another organization and only
> want to share select multicast groups/sources then in IPv4 you use
> MSDP and MSDP filters.  However, I don’t see how to do this with IPv6
> multicast.

Would it work if you used one of the available (unnamed) scopes for that
job? Agree on a scope that gets routed with your partner organization
and set up your border multicast routers accordingly.

> 2)      Often I see different multicast domains with MSDP between them
> (including filters).  Do organizations just do one huge PIMv6-Anycast
> domain and leave it at that?

I'm not sure what you mean with "PIMv6-Anycast domain", but if I
understand your question correctly, then the answer is yes: One
(possibly anycasted) RP or set of RPs for all "multicast domains" (which
is a concept that doesn't really apply to IPv6) and matching scopes to
filter between the domains. (And yes, there may be constellations where
you actually run out of scopes...)

If there is no direct connection between the domains, either use some
sort of VPN (which you'll likely have anyway) or possibly just a simple
GRE or configured 6in4 tunnel.


Cheers,

Benedikt

--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/

Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

Hi Benedikt,

> Hi Jim and list,
>
> first off, I've done some IPv6 multicast routing but I've never been
> unlucky enough not to deal with it over IPv4.
>
> > 1) There is no MSDPv6 and probably never will be. Of course you
> > have SSM and Embedded RP but that doesn’t cover all cases. For
> > example – if you have a partnership with another organization and only
> > want to share select multicast groups/sources then in IPv4 you use
> > MSDP and MSDP filters. However, I don’t see how to do this with IPv6
> > multicast.
>
> Would it work if you used one of the available (unnamed) scopes for that
> job? Agree on a scope that gets routed with your partner organization
> and set up your border multicast routers accordingly.

Agreed - this is a viable approach.

> > 2) Often I see different multicast domains with MSDP between them
> > (including filters). Do organizations just do one huge PIMv6-Anycast
> > domain and leave it at that?
>
> I'm not sure what you mean with "PIMv6-Anycast domain", but if I

Basically something compliant with RFC 4610. With IPv4 I would use the approach described in RFC 3446. With IPv6 it seems like the replacement is "Anycast-RP using PIM" as described in 4610. My concern was using this approach for a large global backbone, but sounds like that's the only option.

> understand your question correctly, then the answer is yes: One
> (possibly anycasted) RP or set of RPs for all "multicast domains" (which
> is a concept that doesn't really apply to IPv6) and matching scopes to

So essentially I should stop thinking local "domains" and think globally for any IPv6 multicast deployment?

> filter between the domains. (And yes, there may be constellations where
> you actually run out of scopes...)
>
> If there is no direct connection between the domains, either use some
> sort of VPN (which you'll likely have anyway) or possibly just a simple
> GRE or configured 6in4 tunnel.

Coming from an IPv4 Multicast background, I'm having a hard time accepting that my only Inter-domain RP option is embedded RP. I understand the issues with MSDP and why it wasn't extended to support IPv6. However, it still feels like there should be some kind of inter-domain RP communication/synchronization option. Perhaps I have not fully grokked IPv6 Multicast yet?

Thanks,
--Jim

HI Jim and list,

"James Small" <jim.small@mail.com> writes:

> Basically something compliant with RFC 4610.
> With IPv4 I would use the approach described in RFC 3446.

OK, now I understand why I didn't understand your initial question.
I assumed with "anycast RP" you were talking about anycast within a
single subnet...

> With IPv6 it seems like the
> replacement is "Anycast-RP using PIM" as described in 4610. My
> concern was using this approach for a large global backbone, but
> sounds like that's the only option.

OK again; I was thinking about the scale of a large enterprise with
multiple sites connected via VPNs, MPLS, or whatever.

> So essentially I should stop thinking local "domains" and think
> globally for any IPv6 multicast deployment?

I think so, but I'm not sure; so far I admittedly haven't had to deal
with that sort of setup.

> Coming from an IPv4 Multicast background, I'm having a hard time
> accepting that my only Inter-domain RP option is embedded RP.

Well, there are usually two possible explanations for this: Either IPv6
has managed to get rid of some legacy approaches and/or workarounds for
IPv4-specific limitations, or it is still missing some sort of feature.
In this case however I guess it's the first case.

And when it comes to the combination of scopes and embedded RPs, at
least in the environments I've come into contact with, that's a *huge*
advantage over IPv4 multicast routing; especially so if your multicast
routing setup is somewhat fluctuating all the time.

> I understand the issues with MSDP and why it wasn't extended to
> support IPv6. However, it still feels like there should be some kind
> of inter-domain RP communication/synchronization option. Perhaps I
> have not fully grokked IPv6 Multicast yet?

Well, who has? However, since I've only done any multicast routing with
IPv6 really, I find the term or concept of a "domain", or rather that of
"inter-domain multicast routing" somewhat unclear myself. Unless I
misunderstand RFC 4610, the entire domain concept, or at least the idea
of "inter-domain" is gone; instead, what is called a domain in there is
the "reach" (not an official term) of whatever multicast group, and that
"reach" is preferably defined by a suitably defined/chosen scope that
is then encoded in the multicast group's scope nibble.

But again, I haven't yet dealt with this at an ISP level, really; my
focus was entirely at the enterprise scale.


Cheers,

Benedikt

--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/

Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

Hi,

On Thu, Jun 05, 2014 at 09:32:08PM -0400, James Small wrote:
> > If there is no direct connection between the domains, either use some
> > sort of VPN (which you'll likely have anyway) or possibly just a simple
> > GRE or configured 6in4 tunnel.
>
> Coming from an IPv4 Multicast background, I'm having a hard time accepting that my only Inter-domain RP option is embedded RP. I understand the issues with MSDP and why it wasn't extended to support IPv6. However, it still feels like there should be some kind of inter-domain RP communication/synchronization option. Perhaps I have not fully grokked IPv6 Multicast yet?

Point is, RP synchronization is only necessary if different PIM speakers
have different ideas who "the RP" is. So your routers talk to your RP,
their routers talk to their RP, and the RPs synchronize with MSDP.

In IPv4, you could configure your routers to use "their RP" for a given
multicast group, and not use MSDP - but nobody does that as it's manual
work.

With the embedded RP, all routers know which is the right (and only) RP for
a given group, so there is nothing left to synchronize...

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 6 June 2014 22:23:24 BST, Gert Doering <gert@space.net> wrote:

>With the embedded RP, all routers know which is the right (and only) RP
>for
>a given group, so there is nothing left to synchronize...
>
>Gert Doering
> -- NetMaster

But anycast rp for resilience of nothing else is not uncommon. What's the mechanism for anycast embedded rp sync?
--
Sent from my phone with, please excuse brevity and typos

Hi,

On Fri, Jun 06, 2014 at 10:45:06PM +0100, Phil Mayers wrote:
> On 6 June 2014 22:23:24 BST, Gert Doering <gert@space.net> wrote:
>
> >With the embedded RP, all routers know which is the right (and only) RP
> >for
> >a given group, so there is nothing left to synchronize...
>
> But anycast rp for resilience of nothing else is not uncommon. What's the mechanism for anycast embedded rp sync?

Now that is a very good question. I have no answer to that - that used
to be done with MSDP, MSDP is gone...

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 07/06/14 08:12, Gert Doering wrote:

>> But anycast rp for resilience of nothing else is not uncommon.
>> What's the mechanism for anycast embedded rp sync?
>
> Now that is a very good question. I have no answer to that - that
> used to be done with MSDP, MSDP is gone...

I must own up to being slightly rhetorical here; RFC 4610 describes
using PIM for RP-RP sync, and we in fact use that on JunOS to implement
anycast RP without MSDP.

I guess the real question is, is there a PIM6 version of 4610, and is it
widely supported. I know JunOS has it, and docs suggest NX-OS does, but
not sure about IOS, and not sure about any of them for IPv6.

I can confirm that IOS (and assuming NX-OS) supports Anycast RP using PIMv6
(RFC 4610). However, I haven't tested this for Embedded RP so not sure if
that throws a curve ball. The challenge with Embedded RP is it become a new
application requirement. From the network perspective it's not a big deal.
However, from the application owner perspective it could be. I can't speak
to that because I'm not a developer. It is a change from IPv4 though which
means it needs to be sold to the App-Dev group.

--Jim

> -----Original Message-----
> From: ipv6-ops-bounces+jim.small=mail.com@lists.cluenet.de [mailto:ipv6-
> ops-bounces+jim.small=mail.com@lists.cluenet.de] On Behalf Of Phil Mayers
> Sent: Saturday, June 07, 2014 4:00 AM
> To: Gert Doering
> Cc: ipv6-ops@lists.cluenet.de
> Subject: Re: Large IPv6 Multicast Domains
>
> On 07/06/14 08:12, Gert Doering wrote:
>
> >> But anycast rp for resilience of nothing else is not uncommon.
> >> What's the mechanism for anycast embedded rp sync?
> >
> > Now that is a very good question. I have no answer to that - that
> > used to be done with MSDP, MSDP is gone...
>
> I must own up to being slightly rhetorical here; RFC 4610 describes
> using PIM for RP-RP sync, and we in fact use that on JunOS to implement
> anycast RP without MSDP.
>
> I guess the real question is, is there a PIM6 version of 4610, and is it
> widely supported. I know JunOS has it, and docs suggest NX-OS does, but
> not sure about IOS, and not sure about any of them for IPv6.

On 07/06/14 20:40, James Small wrote:
> I can confirm that IOS (and assuming NX-OS) supports Anycast RP using PIMv6

Sorry, I was unclear:

NX-OS definitely has commands for "ip pim anycast-rp" and, now that I
look after enabling "feature pim6", "ipv6 pim anycast-rp". I haven't
tried them (our RPs are on JunOS boxes) but I assume they more or less
work ;o)

You say it's supported under IOS, which sounds good, but I see no sign
of any specific command syntax under 15.1SY on 6500, for v4 or v6. Which
IOS versions support this, and what's the command syntax?

> (RFC 4610). However, I haven't tested this for Embedded RP so not sure if
> that throws a curve ball. The challenge with Embedded RP is it become a new
> application requirement. From the network perspective it's not a big deal.
> However, from the application owner perspective it could be. I can't speak
> to that because I'm not a developer. It is a change from IPv4 though which
> means it needs to be sold to the App-Dev group.

I don't understand this last bit at all.

Embedded RP just entails using a specific group range. There's no work
for the application to do at all, other than have some way to configure
in the group it uses (well, and use IPv6 multicast of course, but if it
doesn't, embedded RP doesn't apply so the point is moot).

I can't see any reason anycast-rp wouldn't work with embedded RP; it's a
pretty simple mechanism (replicate PIM register messages). I doubt the
mechanism cares.

Hi

On 6/8/2014 2:13 AM, Phil Mayers wrote:
[...]
> I can't see any reason anycast-rp wouldn't work with embedded RP; it's a
> pretty simple mechanism (replicate PIM register messages). I doubt the
> mechanism cares.

Yes, this should work fine.

Regarding domains with different RPs and synchronizing state. I think it
is generally a bad idea to have multicast source activity in one domain
pushed out to every other domain, even if they are not interested. There
are generally operational issues with MSDP and I don't think another way
of doing it would be better. I'm hoping SSM will be the way to go for
interdomain in general. Embedded-RP is a pretty good solution though.

Stig

On Thursday, June 19, 2014 08:17:07 PM Stig Venaas wrote:

> I'm
> hoping SSM will be the way to go for interdomain in
> general.

Agree - prefer SSM also.

Mark.

On 20/06/14 07:11, Mark Tinka wrote:
> On Thursday, June 19, 2014 08:17:07 PM Stig Venaas wrote:
>
>> I'm
>> hoping SSM will be the way to go for interdomain in
>> general.
>
> Agree - prefer SSM also.

Who doesn't - app coders AFAICT? ;o)

On Fri, Jun 20, 2014 at 10:09:44AM +0100, Phil Mayers wrote:
>> Agree - prefer SSM also.
> Who doesn't - app coders AFAICT? ;o)

Well, it would be a good start if the Windows firewall didn't block SSM joins
by default.

(Last testet March last year)

/* Steinar */
--
Software Engineer, Google Switzerland

> On Jun 20, 2014, at 5:09 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
>
>> On 20/06/14 07:11, Mark Tinka wrote:
>>> On Thursday, June 19, 2014 08:17:07 PM Stig Venaas wrote:
>>>
>>> I'm
>>> hoping SSM will be the way to go for interdomain in
>>> general.
>>
>> Agree - prefer SSM also.
>
> Who doesn't - app coders AFAICT? ;o)

There are specific use cases for ASM (in IPv4) in distributed monitoring (many->few traffic flows) It sure would be a shame for that to go away...

David

On 20/06/14 13:08, David Barak wrote:

> There are specific use cases for ASM (in IPv4) in distributed
> monitoring (many->few traffic flows) It sure would be a shame for
> that to go away...

Well, I doubt it will go away. Presumably embedded RP will serve those
needs in the v6 world.

But IME transition from (*,g) to (s,g) and RP-tree flooding is where a
lot of PIM-related issues occur, so I am totally on board with
preferring SSM where possible.

On Friday, June 20, 2014 02:10:55 PM Phil Mayers wrote:

> But IME transition from (*,g) to (s,g) and RP-tree
> flooding is where a lot of PIM-related issues occur, so
> I am totally on board with preferring SSM where
> possible.

In NG-MVPN's, you have two options for transition; RTP-SPT
which is typical (*,G) to (S,G) or SPT-only, which is (S,G).
SPT-only breaks typical PIM behaviour, but it's very
efficient.

Mark.

Hi

On 6/20/2014 5:08 AM, David Barak wrote:
>
>> On Jun 20, 2014, at 5:09 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
>>
>>> On 20/06/14 07:11, Mark Tinka wrote:
>>>> On Thursday, June 19, 2014 08:17:07 PM Stig Venaas wrote:
>>>>
>>>> I'm
>>>> hoping SSM will be the way to go for interdomain in
>>>> general.
>>>
>>> Agree - prefer SSM also.
>>
>> Who doesn't - app coders AFAICT? ;o)
>
> There are specific use cases for ASM (in IPv4) in distributed monitoring (many->few traffic flows) It sure would be a shame for that to go away...

But do you need that across multiple domains?

ASM is pretty much the only solution when it comes to autoconfig
and discovery where you don't want to hard code source addresses
and some device has no knowledge. But that is typically relevant
on a single link, or in a site. I can't think of any interdomain
cases.

Applications that need to discover remote sources for SSM would
need to have their own discovery mechanism. There are various
possible schemes. A device with no info might need to use DHCP
or something to learn how to reach a server, or maybe have some
fixed multicast group to discover some kind of local server that
has more info.

But yes, it is easier for application developers to assume ASM
works inter-domain. Embedded-RP works though, but you would
probably not want to hardcode a group addresses with an embedded
RP address in a device.

Stig


> David
>

> On Jun 26, 2014, at 7:05 PM, Stig Venaas <stig@venaas.com> wrote:
>
> Hi
>
>> On 6/20/2014 5:08 AM, David Barak wrote:
>>
>>>> On Jun 20, 2014, at 5:09 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
>>>>
>>>>> On 20/06/14 07:11, Mark Tinka wrote:
>>>>> On Thursday, June 19, 2014 08:17:07 PM Stig Venaas wrote:
>>>>>
>>>>> I'm
>>>>> hoping SSM will be the way to go for interdomain in
>>>>> general.
>>>>
>>>> Agree - prefer SSM also.
>>>
>>> Who doesn't - app coders AFAICT? ;o)
>>
>> There are specific use cases for ASM (in IPv4) in distributed monitoring (many->few traffic flows) It sure would be a shame for that to go away...
>
> But do you need that across multiple domains?

Define "domain" in that context- do you mean PIM domain, or do you mean administrative control, ASN, MSDP relationship, or what? The answer to most of these would be "yes", although to varying degrees.

>
> ASM is pretty much the only solution when it comes to autoconfig
> and discovery where you don't want to hard code source addresses
> and some device has no knowledge. But that is typically relevant
> on a single link, or in a site. I can't think of any interdomain
> cases.

Distributed sensor networks are a specific example of a multi-site use case for ASM.

>
> Applications that need to discover remote sources for SSM would
> need to have their own discovery mechanism. There are various
> possible schemes. A device with no info might need to use DHCP
> or something to learn how to reach a server, or maybe have some
> fixed multicast group to discover some kind of local server that
> has more info.
> But yes, it is easier for application developers to assume ASM
> works inter-domain. Embedded-RP works though, but you would
> probably not want to hardcode a group addresses with an embedded
> RP address in a device.
>
I'm looking at perfectly functioning ASM networks in IPv4, and hoping the functionality doesn't go away or become a lot harder because v6 multicast is over designed. Right now, an app needs its own source address and the group or groups to send to, *and that's it*. Am I stuck with embedded-rp if we move to v6? What if (Heaven forfend) I want to change the rp address, or use BSR or something?


David Barak
Sent from a mobile device, please forgive autocorrection.