Subject: [pim] draft-wijnands-pim-source-discovery-bsr call for adoption

From: Mike McBride <[email-masked]>
Date: Fri, 25 Oct 2013 15:07:59 -0700

The authors of draft-wijnands-pim-source-discovery-bsr-03 have requested
that we initiate a call for adoption of their draft which they presented in
our last meeting in Berlin. Notes from that presentation are below. Please
comment over the next week (before ietf week) on your interest/non-interest
with adoption of this draft.

http://www.ietf.org/id/draft-wijnands-pim-source-discovery-bsr-03.txt

thanks,
mike

draft-wignands-pim-source-discovery-bsr-03 (Ice)
==============================================
highly redudant mcast network without single point of failure.
Jeffrey: Of the 10k flows how many groups?
Ice: the sources are what's relevant. 10k s,gs. Not introducing a new
routing protocol.
Jeffrey: Could use mospf. pim bidir is another viable approach. With
bidir, while the RPA canbe an address that is not tried to any router
(the address would be associated with a LAN), the LAN that the RPA is
on could become partitioned. When that happens, traffic cannot be
exchanged on the LAN between the partitions, affecting lots of
receivers. That's the problem using PIM-BIDIR instead of BSR flooing.
However, that can be easily resolved by a protocol extension. I should
be able to publish it for the next IETF meeting. With that resolved,
PIM bidir will be a better solution for the targeted deployment
scenario.
stig: one issue with bidir is you don't have the optimal path.
operator DT: I like the use case and support.
Hitoshi: flooding is not typically optimal.
Ice: its only using mechanisms that exist today with bsr.
jeffrey: the amount of information is more with today.
Hitoshi: Why not use SAP (I'm not a fan of SAP though)? Whats the
meaning of flooding. Use MSDP if interdomain?
lighthouse networks: you mentioned dns, why can't you use that?
Ice; this is a case where you don't know the source. bsr based
flooding. not inter domain discussion. Enterprise network.
Mike: applaud any efforts to make multicast more simple. But flooding
may be a problem.

1 room interested. 2 operators on draft interested. Mike will poll on list.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 28 Oct 2013 04:37:43 +0000

Hi Mike,

Support.

Cheers,
Jeff

From: Mike McBride <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 25, 2013 3:07 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [pim] draft-wijnands-pim-source-discovery-bsr call for adoption

The authors of draft-wijnands-pim-source-discovery-bsr-03 have requested that we initiate a call for adoption of their draft which they presented in our last meeting in Berlin. Notes from that presentation are below. Please comment over the next week (before ietf week) on your interest/non-interest with adoption of this draft.

thanks,
mike

draft-wignands-pim-source-discovery-bsr-03 (Ice)
==============================================
highly redudant mcast network without single point of failure.
Jeffrey: Of the 10k flows how many groups?
Ice: the sources are what's relevant. 10k s,gs. Not introducing a new routing protocol.
Jeffrey: Could use mospf. pim bidir is another viable approach. With bidir, while the RPA canbe an address that is not tried to any router (the address would be associated with a LAN), the LAN that the RPA is on could become partitioned. When that happens, traffic cannot be exchanged on the LAN between the partitions, affecting lots of receivers. That's the problem using PIM-BIDIR instead of BSR flooing. However, that can be easily resolved by a protocol extension. I should be able to publish it for the next IETF meeting. With that resolved, PIM bidir will be a better solution for the targeted deployment scenario.
stig: one issue with bidir is you don't have the optimal path.
operator DT: I like the use case and support.
Hitoshi: flooding is not typically optimal.
Ice: its only using mechanisms that exist today with bsr.
jeffrey: the amount of information is more with today.
Hitoshi: Why not use SAP (I'm not a fan of SAP though)? Whats the meaning of flooding. Use MSDP if interdomain?
lighthouse networks: you mentioned dns, why can't you use that?
Ice; this is a case where you don't know the source. bsr based flooding. not inter domain discussion. Enterprise network.
Mike: applaud any efforts to make multicast more simple. But flooding may be a problem.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 28 Oct 2013 13:27:14 +0000

Hi,

We should not rush to a decision before the IETF week.

The drawbacks of the solution have been discussed before.

The draft has two aspects:

1.       Source information flooding in an environment with high resilience requirement

2.       Should we extend BSR to a generic flooding mechanism

For both of them, PIM-Bidir is a very good alternative - after the RP resilience problem is resolved.

In Vancouver I will present a simple enhancement to PIM-Bidir procedures (no signaling extension is required) to address that - http://tools.ietf.org/html/draft-zzhang-pim-bidir-rpl-resiliency-00.

Thanks.
Jeffrey

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike McBride
Sent: Friday, October 25, 2013 6:08 PM
To: [email-masked]
Subject: [pim] draft-wijnands-pim-source-discovery-bsr call for adoption

---

From: Tom Taylor <[email-masked]>
Date: Mon, 28 Oct 2013 10:55:56 -0400

Support.

Tom Taylor

> http://www.ietf.org/id/draft-wijnands-pim-source-discovery-bsr-03.txt
...

---

From: Mike McBride <[email-masked]>
Date: Mon, 28 Oct 2013 15:10:12 +0000

Agreed. No rush. But we should be able to receive enough wg feedback, before our meeting, to make a decision.

I will interpret your feedback as not necessarily being opposed to this work but that we need to be aware of alternatives which may be better. Looking forward to your presentation.

Thanks,
mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Monday, October 28, 2013 6:27 AM
To: Mike McBride; [email-masked]
Subject: Re: [pim] draft-wijnands-pim-source-discovery-bsr call for adoption

Hi,

Thanks.
Jeffrey

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike McBride
Sent: Friday, October 25, 2013 6:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pim] draft-wijnands-pim-source-discovery-bsr call for adoption

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 28 Oct 2013 12:08:08 -0700

I think this is a pointless step in the wrong direction.  The last 15 
years have shown us that network-based source discovery was a bad idea- we 
should be deprecating ASM and pushing SSM as the way forward.

This proposal is a marginal improvement over the existing RP/shared tree 
mechanism from a simplicity standpoint, but it can't possibly scale for 
interdomain/large deployments.  Maybe, this might have been a useful 
conversation in 1996.  But today, this is a solution in search of a 
problem.

We already have a solution that eliminates RPs, shared trees and doesn't 
scale: PIM-DM.  We don't another.

-Lenny

On Fri, 25 Oct 2013, Mike McBride wrote:

-) The authors of draft-wijnands-pim-source-discovery-bsr-03 have requested
-) that we initiate a call for adoption of their draft which they presented in
-) our last meeting in Berlin. Notes from that presentation are below. Please
-) comment over the next week (before ietf week) on your interest/non-interest
-) with adoption of this draft.
-) 
-) http://www.ietf.org/id/draft-wijnands-pim-source-discovery-bsr-03.txt
-) 
-) thanks,
-) mike
-) 
-) draft-wignands-pim-source-discovery-bsr-03 (Ice)
-) ==============================================
-) highly redudant mcast network without single point of failure.
-) Jeffrey: Of the 10k flows how many groups?
-) Ice: the sources are what's relevant. 10k s,gs. Not introducing a new
-) routing protocol.
-) Jeffrey: Could use mospf. pim bidir is another viable approach. With
-) bidir, while the RPA canbe an address that is not tried to any router
-) (the address would be associated with a LAN), the LAN that the RPA is
-) on could become partitioned. When that happens, traffic cannot be
-) exchanged on the LAN between the partitions, affecting lots of
-) receivers. That's the problem using PIM-BIDIR instead of BSR flooing.
-) However, that can be easily resolved by a protocol extension. I should
-) be able to publish it for the next IETF meeting. With that resolved,
-) PIM bidir will be a better solution for the targeted deployment
-) scenario.
-) stig: one issue with bidir is you don't have the optimal path.
-) operator DT: I like the use case and support.
-) Hitoshi: flooding is not typically optimal.
-) Ice: its only using mechanisms that exist today with bsr.
-) jeffrey: the amount of information is more with today.
-) Hitoshi: Why not use SAP (I'm not a fan of SAP though)? Whats the
-) meaning of flooding. Use MSDP if interdomain?
-) lighthouse networks: you mentioned dns, why can't you use that?
-) Ice; this is a case where you don't know the source. bsr based
-) flooding. not inter domain discussion. Enterprise network.
-) Mike: applaud any efforts to make multicast more simple. But flooding
-) may be a problem.
-) 
-) 1 room interested. 2 operators on draft interested. Mike will poll on list.
-)

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 28 Oct 2013 20:44:46 +0100

Hi Jeffrey,

> For both of them, PIM-Bidir is a very good alternative – after the RP resilience problem is resolved.
>  

"Simple" is in the eye of the beholder ;-)

I've just read your draft, I would not say this is simple. When a phantom RP is not owned by any particular router, this is a new can of worms. It opens the door for loops because multiple routers may temporality claim ownership of the phantom address at the same time. The phantom address works well if the network where the phantom address is located is the root of the networks that connect to it. There are operators that are discarding Bidir how it is today due to the risk of creating transient loops, so lets be very careful when making the RP even more random.

The problem we are solving would require all the routers in the network to participate in the functionality you describe in your draft. Its great to explore this idea in IETF, but this idea if far from cooked to be considered as alternative to draft-wijnands-pim-source-discovery-bsr. Either-way, I'm not against if it does, the market will decide.

Thx,

Ice.

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 28 Oct 2013 20:00:42 +0000

Ice,

> -----Original Message-----
> From: IJsbrand Wijnands [mailto:[email-masked]]
> Sent: Monday, October 28, 2013 3:45 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Mike McBride; [email-masked]
> > In Vancouver I will present a simple enhancement to PIM-Bidir
> procedures (no signaling extension is required) to address that -
> http://tools.ietf.org/html/draft-zzhang-pim-bidir-rpl-resiliency-00.
> 
> I've just read your draft, I would not say this is simple. When a
> phantom RP is not owned by any particular router, this is a new can of
> worms. It opens the door for loops because multiple routers may
> temporality claim ownership of the phantom address at the same time.

If the RPL partitions, the (entire) network will have several RPLs, leading to isolation but should not cause loops. The draft actually address that existing problem by electing an active RPL partition.

> The phantom address works well if the network where the phantom address
> is located is the root of the networks that connect to it. There are
> operators that are discarding Bidir how it is today due to the risk of
> creating transient loops, so lets be very careful when making the RP
> even more random.
> 
> The problem we are solving would require all the routers in the network
> to participate in the functionality you describe in your draft. Its

Just the routers on the RPL need to participate. For comparison, BSR flooding source information requires every router to do it :-)

Thanks.
Jeffrey

> great to explore this idea in IETF, but this idea if far from cooked to
> be considered as alternative to draft-wijnands-pim-source-discovery-bsr.
> Either-way, I'm not against if it does, the market will decide.
> 
> Thx,
> 
> Ice.
> 
> >
> > Thanks.
> > Jeffrey
> >
> > The authors of draft-wijnands-pim-source-discovery-bsr-03 have
> requested that we initiate a call for adoption of their draft which
> they presented in our last meeting in Berlin. Notes from that
> presentation are below. Please comment over the next week (before ietf
> week) on your interest/non-interest with adoption of this draft.
> >

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 28 Oct 2013 21:04:22 +0100

Hi Lenny,

> should be deprecating ASM and pushing SSM as the way forward.

We've been saying that for at least 10 years now. However, solutions are still being developed to support PIM-SM, like draft-rekhter-mpls-pim-sm-over-mldp, which according to your statement above is a step in the wrong direction. I don't disagree with that.

> interdomain/large deployments.  Maybe, this might have been a useful 

Agreed, and that is not the intention of this draft. This solves a very specific problem for sub-set of the customers, but it solves a real problem

> conversation in 1996.  But today, this is a solution in search of a 

Lets not give the customer a solution to a problem that he does not need to solve, like Inter-domain.

Thx,

Ice.

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 28 Oct 2013 13:52:27 -0700

How about the last point: if you want to avoid shared trees, RPs, register 
messages and don't want something that scales, why is dense mode not 
sufficient?  With state refresh, you flood the source info.

On Mon, 28 Oct 2013, IJsbrand Wijnands wrote:

-) Hi Lenny,
-) 
-) > I think this is a pointless step in the wrong direction.  The last 15 
-) > years have shown us that network-based source discovery was a bad idea- we 
-) > should be deprecating ASM and pushing SSM as the way forward.
-) 
-) We've been saying that for at least 10 years now. However, solutions are still being developed to support PIM-SM, like draft-rekhter-mpls-pim-sm-over-mldp, which according to your statement above is a step in the wrong direction. I don't disagree with that.
-) 
-) > This proposal is a marginal improvement over the existing RP/shared tree 
-) > mechanism from a simplicity standpoint, but it can't possibly scale for 
-) > interdomain/large deployments.  Maybe, this might have been a useful 
-) 
-) Agreed, and that is not the intention of this draft. This solves a very specific problem for sub-set of the customers, but it solves a real problem
-) 
-) > conversation in 1996.  But today, this is a solution in search of a 
-) > problem.
-) 
-) Lets not give the customer a solution to a problem that he does not need to solve, like Inter-domain.
-) 
-) Thx,
-) 
-) Ice.
-) 
-) 
-)

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 29 Oct 2013 10:30:42 +0100

Jeffrey,

An phantom RP is useful if the RPA is on an RPL that is an Ethernet, or even better, a cloud, like MPLS for example. In your proposal it seems there is very little benefit since you have no view on the topology how the ad-hoc network is going to look like, and if there will be any ethernet links to begin with. Since the allocation and activation of the Active Partition is not pre-determind (I believe ultimately based on lowest IP address), there is no guarantee that this will provide you any additional protection. If the Active partition is over a P2P link, and one of the routers goes down, the link goes down too. This is just as good/bad as if you would be using a real RPA. Would your proposal not be simplified if we define the following rule; "The lowest /32 (Router ID) in the Routing Table is the RPA"?

> If the RPL partitions, the (entire) network will have several RPLs, leading to isolation but should not cause loops. The draft actually address that existing problem by electing an active RPL parti…

And what if the network heals? The fact that the Active partitioned can move around the network and is based on election procedures, it looks to me that opens up additional race conditions to create loops. 

> Just the routers on the RPL need to participate. For comparison, BSR flooding source information requires every router to do it :-)

That is not a good comparison, BSR flooding a packet is not the same as participating in election procedures when a link/node goes down.

While I think your proposal could work, you still run into issues due to PIM Bidir, and will not provide the same level of  redundancy we're looking for in a ad-hoc network.

The location of the Active partitioned (Phantom RPA) can end up in a part of the network that is very inefficient. This goes back to the ever lasting question, where do I place the RP, but this time is pretty much random. The RPA (or router to the RPL) goes down, existing flows are effected and traffic is interrupted. This is because Bidir traffic flows along the path to the RPA. This is a single point of failure. With traditional PIM-SM, if the RPA goes down, this does not nessesarily effect existing forwarding since its along the shortest path (assuming the RPA is not in the path). Only new senders are effected for the time the RP is down and re-elected.

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 29 Oct 2013 10:43:00 +0100

Lenny,

> sufficient?  With state refresh, you flood the source info.

When BSR flooding the Source information, intermediate routers don't need to create state if there are no directly connected receivers. They will just BSR flood the messages.

PIM-DM State-Refresh is still dense-mode in the way you have to periodically refresh the Prune state. I think its a better model to refresh the Join state, as this will only involve routers that are on the shortest path.

PIM-DM State-Refresh has been dead for 13 years, and never made it through the IETF process (draft-ietf-pim-refresh-02.txt).

As soon as the egress PIM routers learns about the Source, the PIM procedures are like SSM. In that respect, I think we all like that. Regarding BSR flooding, IMO, advertising a mapping between a Group and a RP is not very different from mapping a Group to a Source.

Thx,

Ice.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 30 Oct 2013 13:24:54 +0000

Ice,

> Sent: Tuesday, October 29, 2013 5:31 AM
> An phantom RP is useful if the RPA is on an RPL that is an Ethernet, or
> even better, a cloud, like MPLS for example. In your proposal it seems
> there is very little benefit since you have no view on the topology how
> the ad-hoc network is going to look like, and if there will be any
> ethernet links to begin with. Since the allocation and activation of
> the Active Partition is not pre-determind (I believe ultimately based
> on lowest IP address), there is no guarantee that this will provide you
> any additional protection. If the Active partition is over a P2P link,
> and one of the routers goes down, the link goes down too. This is just
> as good/bad as if you would be using a real RPA. Would your proposal
> not be simplified if we define the following rule; "The lowest /32
> (Router ID) in the Routing Table is the RPA"?

Because a phantom RP does not have the risk of the RP going down, the draft currently focus on phantom RP, even though the same idea can be applied to a real RPA. In fact, the reason to use lowest IP address (instead of highest) is for future consideration of real RPs (need to resolve some details).

We do not want just any router to become the RPA - so we did not go with "the lowest /32 in the routing table is the RPA". 

Even if a network only has p2p links, phantom RP may still be used. A set of routers could have a loopback interface configured with a subnet (instead of a host address) and a phantom address on that subnet can be the phantom RP. There will be no adjacencies on the subnet so only one of the routers will be elected to represent the "active partition" and advertise the host route to the RPA and it becomes the only router on the RPL. If that router dies, another router will take over after IGP convergence.

This does give some control where the active partition ends up.

> > If the RPL partitions, the (entire) network will have several RPLs,
> leading to isolation but should not cause loops. The draft actually
> address that existing problem by electing an active RPL partition.
> 
> And what if the network heals? The fact that the Active partitioned can
> move around the network and is based on election procedures, it looks
> to me that opens up additional race conditions to create loops.

If the network heals, there will be one partition and that is the RPL. The election result should be deterministic. It does not move around unless the entire network has partitioned.

> > Just the routers on the RPL need to participate. For comparison, BSR
> flooding source information requires every router to do it :-)
> 
> That is not a good comparison, BSR flooding a packet is not the same as
> participating in election procedures when a link/node goes down.

What is the concern with those routers on the RPL participating in the election? I had thought you were concerned with software upgrade for all routers.

> 
> While I think your proposal could work, you still run into issues due
> to PIM Bidir, and will not provide the same level of  redundancy we're
> looking for in a ad-hoc network.
> 
> The location of the Active partitioned (Phantom RPA) can end up in a
> part of the network that is very inefficient. This goes back to the
> ever lasting question, where do I place the RP, but this time is pretty
> much random.

Is your target network ad hoc in that routers will move around? That's the only situation I can think of where you may not have control (with currently proposed election) that a disadvantaged partition becomes the active partition.

> The RPA (or router to the RPL) goes down, existing flows
> are effected and traffic is interrupted. This is because Bidir traffic
> flows along the path to the RPA. This is a single point of failure.

Only traffic that needs to cross that failure point need to be rerouted.

Jeffrey

> With traditional PIM-SM, if the RPA goes down, this does not
> nessesarily effect existing forwarding since its along the shortest
> path (assuming the RPA is not in the path). Only new senders are
> effected for the time the RP is down and re-elected.
> 
> Thx,
> 
> Ice.
> 
> >
> > Thanks.
> > Jeffrey
> >
> >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >> Mike McBride
> >>> 1 room interested. 2 operators on draft interested. Mike will poll
> on
> >> list.
> >>>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 30 Oct 2013 19:34:49 +0100

Jeffery,

> We do not want just any router to become the RPA - so we did not go with "the lowest /32 in the routing table is the RPA". 

But in the ad-hoc network we are looking at, this is exactly what we would need. There is no way to predetermine the best location of the RP since we don't know what the network is going to look like. For that reason depending on an RP is bad to begin with. You can also simply add an attribute in OSPF/ISIS to flag the /32's that it can be used as RP. But, the next questions will be, can we assign different RP's for different group addresses to share the load, which makes it less attractive.

> Even if a network only has p2p links, phantom RP may still be used. A set of routers could have a loopback interface configured with a subnet (instead of a host address) and a phantom address on th…

Sure, but my point is that this is not any better than Anycast RP. 

> Is your target network ad hoc in that routers will move around? That's the only situation I can think of where you may not have control (with currently proposed election) that a disadvantaged parti…

Yes.

> Only traffic that needs to cross that failure point need to be rerouted.

If the RPA moves from one router to the other, the tree has to be rebuild. This is not only impacting the failure point.

Thx,

Ice.

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 30 Oct 2013 13:04:27 -0700

On Tue, 29 Oct 2013, IJsbrand Wijnands wrote:

-) Lenny,
-) 
-) > How about the last point: if you want to avoid shared trees, RPs, register 
-) > messages and don't want something that scales, why is dense mode not 
-) > sufficient?  With state refresh, you flood the source info.
-) 
-) When BSR flooding the Source information, intermediate routers don't 
-) need to create state if there are no directly connected receivers. They 
-) will just BSR flood the messages.
-) 
-) PIM-DM State-Refresh is still dense-mode in the way you have to 
-) periodically refresh the Prune state. I think its a better model to 
-) refresh the Join state, as this will only involve routers that are on 
-) the shortest path.
-) 
-) PIM-DM State-Refresh has been dead for 13 years, and never made it 
-) through the IETF process (draft-ietf-pim-refresh-02.txt).

This is perhaps a revealing data point on the usefulness of a scheme that 
floods (and refloods to refresh) source info for all routers in the domain 
in order to obviate the need for RPs.  The fact that DM is not very widely 
used and development has been abandoned certainly provides me skepticism 
that this is indeed a real world problem that folks are clamoring to 
solve.  This just seems like DM by a different name.

-) 
-) As soon as the egress PIM routers learns about the Source, the PIM 
-) procedures are like SSM. In that respect, I think we all like that. 

And pretty similiar functionally to DM...

-) Regarding BSR flooding, IMO, advertising a mapping between a Group and 
-) a RP is not very different from mapping a Group to a Source.

There's a HUGE difference!  The group-RP mapping is in many/most 
deployments a single 224/4 mapping.  The s-g mapping includes every single 
mcast stream.  The number of s-g mappings is  >>>> group-RP mappings.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 30 Oct 2013 21:12:25 +0100

Lenny,

> solve.  This just seems like DM by a different name.

Re-read the part above you did not comment on, this solution does not create state in the network where it is not needed. If you think this is the same as DM, we have a different view on what DM is.

> mcast stream.  The number of s-g mappings is  >>>> group-RP mappings.

We already discussed the scalability and applicability aspect of it.

Thx,

Ice.

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 30 Oct 2013 13:38:16 -0700

Ice,

-) > This is perhaps a revealing data point on the usefulness of a scheme that 
-) > floods (and refloods to refresh) source info for all routers in the domain 
-) > in order to obviate the need for RPs.  The fact that DM is not very widely 
-) > used and development has been abandoned certainly provides me skepticism 
-) > that this is indeed a real world problem that folks are clamoring to 
-) > solve.  This just seems like DM by a different name.
-) 
-) Re-read the part above you did not comment on, this solution does not 
-) create state in the network where it is not needed. If you think this 
-) is the same as DM, we have a different view on what DM is.
-) 

>From the draft:

5.  Processing SG messages

   A router that receives an SG message should parse the message and
   store the SG mappings with a holdtimer started with the advertised
   holdtime for that group.  If there are directly connected receivers
   for that group this router should send PIM (S,G) joins for all the SG
   mappings advertised in the message.  The SG mappings are kept alive
   for as long as the holdtimer for the source is running.  Once the
   holdtimer expires a PIM (S,G) prune must be sent to remove itself
   from the tree.

I read this mean these SG messages are flooded to all routers in the 
domain, and every router then stores this information in the event that he 
has a local receiver that wants to join a group, so it knows the source 
for every group and knows how/where to send the s,g join.  Am I 
misinterpreting this?  Are you suggesting that only the LHRs should be 
storing this source info, and the non-LHRs should ignore this source info?  
If so, how does a router know he is a LHR or not?

---

From: Stig Venaas <[email-masked]>
Date: Thu, 31 Oct 2013 10:40:17 -0700

Hi

On 10/30/2013 1:38 PM, Leonard Giuliano wrote:
[...]
> If so, how does a router know he is a LHR or not?

This can be an administrative decision. If you know that a router will
not function as a LHR, it can be configured to only forward the
messages. If you have a deployment where most routers only function as
a LHR for a few selected groups, then the routers only need to store
state for those.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 31 Oct 2013 10:44:03 -0700

Hi

> should be deprecating ASM and pushing SSM as the way forward.

This proposal is IMO the closest you can get to SSM without requiring
IGMPv3 and application source discovery. Once application figure out
the source discovery, then I would certainly want them to use SSM as
well. SSM is great, but doesn't fit all.

> scale: PIM-DM.  We don't another.

DM is being used in some environments where this solution is desired.
We would like to move away from DM though. I think this proposal is a
move in the right direction. From PIM point of view, this is pretty
much SSM (we just need the source discovery).

Stig

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 31 Oct 2013 11:34:57 -0700

-) > > From the draft:
-) > 
-) > 5.  Processing SG messages
-) > 
-) >     A router that receives an SG message should parse the message and
-) >     store the SG mappings with a holdtimer started with the advertised
-) >     holdtime for that group.  If there are directly connected receivers
-) >     for that group this router should send PIM (S,G) joins for all the SG
-) >     mappings advertised in the message.  The SG mappings are kept alive
-) >     for as long as the holdtimer for the source is running.  Once the
-) >     holdtimer expires a PIM (S,G) prune must be sent to remove itself
-) >     from the tree.
-) > 
-) > I read this mean these SG messages are flooded to all routers in the
-) > domain, and every router then stores this information in the event that he
-) > has a local receiver that wants to join a group, so it knows the source
-) > for every group and knows how/where to send the s,g join.  Am I
-) > misinterpreting this?  Are you suggesting that only the LHRs should be
-) > storing this source info, and the non-LHRs should ignore this source info?
-) > If so, how does a router know he is a LHR or not?
-) 
-) This can be an administrative decision. If you know that a router will
-) not function as a LHR, it can be configured to only forward the
-) messages. If you have a deployment where most routers only function as
-) a LHR for a few selected groups, then the routers only need to store
-) state for those.

Stig- thanks for the clarification.  I read the draft over a few times, 
and saw nothing about this.  As the draft is written today, it appears 
that all routers will flood all source info and cache all of that state.  
I guess you are saying that an unmentioned option is for the non LHRs to 
flood but not cache.  OK, but you have to somehow know who is a LHR, and 
who isn't.  Which you seem to be implying that this can be done via 
config.  Or, I suppose to you could just look and see if you have any 
local igmp state to figure out if you are a LHR.  But that would lead to 
join latency of 1-60s when the joins come after the source starts up, and 
I can't imagine any use case where 30s avg join latency is acceptable.

Ultimately, the added state isn't so horrible to me.  In most practical 
cases it doesn't really matter that some routers carry the state and 
others don't.  Besides, you seem to be implying that the use case you have 
in mind doesn't have that many sources, so I guess that's OK.  But you 
still end up with flooding of source info across the domain.  That is 
functionally what DM does- flood source info across the domain (and 
reflood periodically) so that you can build SPTs and not need RPs.  The 
message names are different (refreshing prune state and sending grafts to 
join on the SPT vs refreshing sg messages and sending s,g's to join the on 
the SPT), but the functionality is the same.

I'm not trying to wave the DM banner, but rather to suggest that there 
appears to be no desire by anyone to use DM these days- tough to imagine 
anyone proposing new drafts to develop DM now.  I think that provides 
pretty clear evidence for the utility of another proposal that 
functionally does the same thing under a different name: flood source info 
across the domain (and reflood periodically) so that you can build SPTs 
and not need RPs.

And as for the claim that this is more like SSM- this is no more 
SSM-friendly than DM.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 31 Oct 2013 12:54:44 -0700

Hi

> I can't imagine any use case where 30s avg join latency is acceptable.

I'm not talking about dynamic state here. Obviously it is dynamic
whether a router is a LHR or not. What I'm saying is that with a typical
network design, you have transit routers that you know will never be a
LHR (except perhaps for some specific groups like NTP or something, but
the admin would know which groups). Then you have edge routers that are
potential LHRs. If you know that a router will never be the LHR for all
or certain groups, then you could configure it to not store that state.

> anyone proposing new drafts to develop DM now.  I think that provides

I don't want DM either, I would rather have existing DM users move to
SM, and this solution would make that easier. Basically there are
deployments that only use DM because there is no central point of
failure etc. and with this solution we can provide some of those
properties without using DM. Allowing them to move to SM.

> And as for the claim that this is more like SSM- this is no more

It looks a lot like SSM from routing perspective. We're using SM with
only SPTs and no RPs, just like with SSM. The only difference is where
the source discovery is done.

Stig

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 31 Oct 2013 13:27:27 -0700

-) > And as for the claim that this is more like SSM- this is no more
-) > SSM-friendly than DM.
-) 
-) It looks a lot like SSM from routing perspective. We're using SM with
-) only SPTs and no RPs, just like with SSM. The only difference is where
-) the source discovery is done.
-) 

All you are doing is changing the name of the protocol, not the behavior.  
You are just making SM act like DM and saying it is better bc it is now SM 
and not DM. The problem with PIM-DM is not the name "PIM-DM"; the problem 
is that it floods source data across the domain.  If you just just make SM 
start flooding source info, that isn't any better.  If you can live with a 
solution that floods source data across the domain so that you can use 
SPTs only and don't care about scale, what's the difference between this 
solution and DM, besides the names of the protocols/messages?

If it looks like a duck, swims like a duck, and quacks like a duck, then 
it probably is a duck. (http://en.wikipedia.org/wiki/Duck_test)

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 Oct 2013 17:14:33 -0700

Oh boy...

Short version:
 I support the adoption of this idea wholeheartedly

Long version:
 Long set of rants below, some of which might hopefully be convertable into
 useful explanatory text for the draft:

a) Beneft:

   Ice may have also other use cases in mind (that i am just missing out
   on right now), but IMHO the biggest ones are the cases where PIM-SM/MSDP is
   the best solution today: Not SSM (for apps that can't and will never be able
   to do SSM) and no source-scale issue (eg: no Bidir-case).

   These standard PIM-SM/MSDP deployments provide great but redundant
   job security for vendor consultants and customer architects  to breed,
   feed, cocker and babysit RPs and MSDP: Placement, platform selection,
   redundancy, performance, configuration, troubleshooting, partitioning
   effects and the like. This complexity is 90% of the cost of running
   ASM multicast. And IMHO it is 95% of the reason why multicast is not
   deployed in more eg: enterprises.

   So, yes, this proposal could put me out of one of my jobs because
   i am giving exactly this type of "how to care for your RPs" talk to
   customers - *sob* ;-)

   Oh, and i forgot the lovely breed of DRs and RPs: Lots and lots of
   register tunnels which have even trickled into HW implementations
   because chip designers couldn't find a better feature to waste ASIC
   real estate - and admittedly because customers had real problems without
   that HW accelerateion in some key situations.

   So yes, this proposal would remove the revenues for companies even
   selling register tunnel HW acceleration as an add-on in their
   boxes *sob* *sob* ;-)

b) What happened that this idea came up:

   1. We took a decade to explore all SSM transition options. The customers who
     understand and can, will go to SSM, and use things like SSM
     mapping only as a migration solution - as intended.
     
     But there is a frightning number of customers who are so annoyed
     by PIM-SM/RP/MSDP that they even consider SSM-mapping deployments to
     be better than PIM-SM/RP/MSDP even if there is clearly no way to get
     the apps towards native SSM.

     And we even had asks for SSM mappings in DC-cluster environments
     where one out of 40 sources would send to a group, but with static
     SSM mapping you would have 40 times as much state as with PIM-SM.
     That says a lot about the complexity of RP/MSDP operations.

   2. Multicast trees IMHO are getting denser.  In the 90th it was hip to
     use multicast for any app because you could, now you predominantly
     see new multicast deployments of multicast for apps that can't live 
     without it. And those are apps with a lot of replication == large
     set of receivers.
   
   3. ASM to do source discovery is becoming less relevant. Traditional
     one-off-hacky service discovery was like this: app developers goes
     to IANA asks for a multicast group, and programs it's app clients
     to send a multicast request packet to the group, and have his app
     groups listen to that. Luckily we're getting over that and that
     eliminites the real painful set of bursty-source-apps.

c) Why this solution
   
   b.1) clearly indicates that SSM operationally in the network is
   very successfull with operators. It's even successfull to the extend
   that they consider going way beyond the usefulness of SSM mapping,
   and we should really stop that to happen (with this proposal) because
   that will cause backlash againt SSM in some future when it starts to
   fails to be manageable under change/expansion.

   b.1) + b2) to me means that we want a solution that effectively
   automates SSM mapping. It also means that for the key class of
   deployments, its not a problem to have some control plane flooding
   of Source-Active state into places where it's not needed. The total
   number of states we flood is limited by by the total number of 
   forwarding states we could build. I would guess that >= 90% of
   enterpride PIM deployments have less than 10,000 multicast states
   and with IPv6 and timeouts that's less than half a megabye of memory
   without even trying any optimizations on how we store SAs. And a
   very high likley that all these SAs are useful for the router anyhow
   (b.2).
   
   b.3) also means that it wouldn't leave a lot of PIM-SM apps behind 
   that can not use this solution, so this proposal has a real good chance
   to replace PIM-SM in the mayority of deployments with something that's
   simpler: purely based on SSM forwarding plus the most lightweight way
   to keep ASM apps running.
   
   To rephrase: The original goal of SSM to simplify deployment did not
   happen because SSM could only be added to PIM-SM/RP/MSDP because of
   all the ASM leftover apps. With this proposal we could really have a large
   set of deployments avoid having ever to learn or worry about RPs, MSDP,
   register tunnels and all their associated care.

d) Why not PIM-DM

   PIM-DM might have been quite on-par with PIM-SM in the late 90th,
   but i think since then it has deteriorated. It still is as encumbered by
   data-triggered events as it ever was.

   HW implementations in routers most certainly will not have optimized
   for that in the same way as the optimziations done for PIM-SM/SSM in
   platforms (can't of course speak for all vendors). If i remember correctly,
   assert is still different between DM and SM/SSM (SM/SSM using the same).

   State refresh was never finalized as an RFC. PIM-DM itself is not
   standards track. We never fixed the limitations DM even had vs.
   DVMRP. There are even important products not supporting DM at all,
   and those who do will have more interop issues than PIM-SM/SSM interop.

   Fixing up that badly, incompletely specified and mostly legacy
   implemented DM router hardware forwarding plane as opposed to using the
   PIM-SSM forwarding plane plus one tiny bit from PIM-SM (first hop router
   new (S,G) discovery) is the best choice to maintain all the HW/implementation
   benefits of what we have been using in most deployments in the last
   10 years AND to strip down the complexity in the forwarding plane to the
   minimum needed to suport a form of SSM that be be zero-config for
   the mayority of deployments.

   Last but not least: Maybe i remember DM incorrectly, but i thought
   that even with SR it was necessary to have on all routers (S,G)
   forwarding-plane ("prune") state. That's a totally different problem
   from <= 0.5MByte control plane memory.

   Last but not last: As i mentioned in any rant: I want an SSM network,
   so i want customers to have only the need to do SSM forwarding and
   control plane debugging and as little more as possible. With PIM-DM
   i wold continue to have a totally orthogonal forwading plane and
   control plane that just shares the name "PIM", but that's really double
   effort. With this poposal i have SSM for everything plus some add-on
   for ASM-apps, where i have no idea how we could do the ASM-add on
   any easier.

Cheers
    Toerless