Subject: [pim] New PIM Charter

From: Mike McBride <[email-masked]>
Date: Fri, 6 Oct 2006 14:10:26 -0700 (PDT)

Here is a first pass at pimwg rechartering text. Please review and 
comment. We'll plan on having a new charter (including goals and 
milestones) soon after San Diego.

"The Protocol Independent Multicast (PIM) Working Group is chartered to 
standardize and promote extensions to RFC 4601 - Protocol Independent 
Multicast Version 2 - Sparse Mode, Bidirectional PIM, and BSR. These PIM 
extensions may involve multipoint label switching, reliability, 
resiliency, scalability, management, security and VPNs. The working group 
will specify the MIBs required for PIM and its enhancements. The PIM WG 
will promote RFC 4601 as a scalable, efficient and robust multicast 
routing protocol, which is capable of supporting thousands of groups, 
different types of multicast applications, and all major underlying 
layer-2 subnetwork technologies. The working group will determine if a 
Version 3 of PIM-SM is required."

thanks,
mike

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

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 6 Oct 2006 14:41:03 -0700 (PDT)

I do not believe the WG should promote BSR.  I find this to be analogous 
to promoting MSDP for IPv6- there are other existing, better ways to 
tackle the problem.

Specifically, in the case of IPv4, there exists today 2 ways to provide RP 
mapping: Anycast RP and Anycast PIM.  In the case of IPv6, Anycast PIM is 
available.  The Anycast mechanisms offer more functionality and better 
availability and are vastly simpler than BSR.

IMO, we have spent a great deal of time developing and attempting to fix 
an unnecessary and technically inferior mechanism in BSR.

Thanks,
Lenny 

On Fri, 6 Oct 2006, Mike McBride wrote:

-) Here is a first pass at pimwg rechartering text. Please review and comment.
-) We'll plan on having a new charter (including goals and milestones) soon
-) after San Diego.
-) 
-) "The Protocol Independent Multicast (PIM) Working Group is chartered to
-) standardize and promote extensions to RFC 4601 - Protocol Independent
-) Multicast Version 2 - Sparse Mode, Bidirectional PIM, and BSR. These PIM
-) extensions may involve multipoint label switching, reliability, resiliency,
-) scalability, management, security and VPNs. The working group will specify
-) the MIBs required for PIM and its enhancements. The PIM WG will promote RFC
-) 4601 as a scalable, efficient and robust multicast routing protocol, which is
-) capable of supporting thousands of groups, different types of multicast
-) applications, and all major underlying layer-2 subnetwork technologies. The
-) working group will determine if a Version 3 of PIM-SM is required."
-) 
-) thanks,
-) mike
-) 
-) _______________________________________________
-) pim mailing list
-) [email-masked]
-) https://www1.ietf.org/mailman/listinfo/pim
-)

---

From: Nidhi Bhaskar <[email-masked]>
Date: Fri, 6 Oct 2006 15:33:09 -0700 (PDT)

> mapping: Anycast RP and Anycast PIM.  In the case of IPv6, Anycast PIM is

Anycast RP is not an approach to provide RP mappings, but to provide
fast RP failover. And Anycast PIM is a way to use Anycast RP without
using MSDP.

The RP mapping itself is provided either via static configuration or
via a dynamic mapping protocol like AutoRP or BSR. In other words, you
could use BSR or AutoRP to distribute an anycast RP address.  In
addition to the advantages of dynamic vs static RP config, the in
built scoping support in BSR/AutoRP are a plus.

I'm not disagreeing that Anycast RP is a great mechanism for RP
fail-over. But I think there is still use for a dynamic mapping
distribution protocol... So if the PIM WG would continue to be a place
to discuss any improvements we may want to make to these, that would
be a good thing in my opinion.

Thanks,
Nidhi.

---

From: John Zwiebel <[email-masked]>
Date: Fri, 6 Oct 2006 15:52:14 -0700

> be a good thing in my opinion.

FWIW:  I've found a well-implemented BSR to be effective.
It works very well.

At this point, there are very few deployments that I'm aware of
which use a distribution of RPs.  It may be that one RP-address
is more than adequate.  I do not think we have arrived at that
point yet.

If anyone cares, I'm an SSM/Bidir freak myself and think PIM-SM
should be killed.  And in such a "universe" RP distribution for
bidir groups should become very important.  So having a well-defined
BSR protocol could help a lot in making this happen.

Perhaps "someone" might figure out a way of doing a dykstra on the
receivers who have joined to a group to determine the optimum location
for the RP -- especially since the RP is just an arbitrary point in  
space.
In such a 'universe' the ability to quickly distribute RP information
will become important.

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 6 Oct 2006 20:19:55 -0700 (PDT)

On Fri, 6 Oct 2006, Nidhi Bhaskar wrote:

-) > I do not believe the WG should promote BSR.  I find this to be analogous
-) > to promoting MSDP for IPv6- there are other existing, better ways to
-) > tackle the problem.
-) > 
-) > Specifically, in the case of IPv4, there exists today 2 ways to provide RP
-) > mapping: Anycast RP and Anycast PIM.  In the case of IPv6, Anycast PIM is
-) 
-) Anycast RP is not an approach to provide RP mappings, but to provide
-) fast RP failover. And Anycast PIM is a way to use Anycast RP without
-) using MSDP.
-) 
-) The RP mapping itself is provided either via static configuration or
-) via a dynamic mapping protocol like AutoRP or BSR. In other words, you
-) could use BSR or AutoRP to distribute an anycast RP address.  In
-) addition to the advantages of dynamic vs static RP config, the in
-) built scoping support in BSR/AutoRP are a plus.
-) 

Sorry if I was unclear by not mentioning Anycast RP|PIM with static RP 
config, as I assumed this would be obvious.  Certainly, you can use 
Anycast with AutoRP/BSR, but no one does that and it wouldn't really buy 
you anything.  Since the RP address is anycast, there is no real benefit 
to having a dynamic one.

As for scoping, I would question the benefit and usefulness.  The 
landscape of mcast is littered with lots of complex mechanisms and 
protocols that took years to develop that no one used.  BSR scoping would 
seem to fit that description.  As another example, in AMT it was 
eventually agreed that the costs of complexity of allowing sources behind 
gateways was not worth the benefit, so the effort was largely abandoned.

-) I'm not disagreeing that Anycast RP is a great mechanism for RP
-) fail-over. But I think there is still use for a dynamic mapping
-) distribution protocol... So if the PIM WG would continue to be a place
-) to discuss any improvements we may want to make to these, that would
-) be a good thing in my opinion.
-) 
-) Thanks,
-) Nidhi.
-) 
-) 
-) > available.  The Anycast mechanisms offer more functionality and better
-) > availability and are vastly simpler than BSR.
-) > 
-) > IMO, we have spent a great deal of time developing and attempting to fix
-) > an unnecessary and technically inferior mechanism in BSR.
-) > 
-) > 
-) > Thanks,
-) > Lenny
-) > 
-) > On Fri, 6 Oct 2006, Mike McBride wrote:
-) > 
-) > -) Here is a first pass at pimwg rechartering text. Please review and
-) > comment.
-) > -) We'll plan on having a new charter (including goals and milestones) soon
-) > -) after San Diego.
-) > -)
-) > -) "The Protocol Independent Multicast (PIM) Working Group is chartered to
-) > -) standardize and promote extensions to RFC 4601 - Protocol Independent
-) > -) Multicast Version 2 - Sparse Mode, Bidirectional PIM, and BSR. These PIM
-) > -) extensions may involve multipoint label switching, reliability,
-) > resiliency,
-) > -) scalability, management, security and VPNs. The working group will
-) > specify
-) > -) the MIBs required for PIM and its enhancements. The PIM WG will promote
-) > RFC
-) > -) 4601 as a scalable, efficient and robust multicast routing protocol,
-) > which is
-) > -) capable of supporting thousands of groups, different types of multicast
-) > -) applications, and all major underlying layer-2 subnetwork technologies.
-) > The
-) > -) working group will determine if a Version 3 of PIM-SM is required."
-) > -)
-) > -) thanks,
-) > -) mike
-) > -)
-) > -) _______________________________________________
-) > -) pim mailing list
-) > -) [email-masked]
-) > -) https://www1.ietf.org/mailman/listinfo/pim
-) > -)
-) > 
-) > _______________________________________________
-) > pim mailing list
-) > [email-masked]
-) > https://www1.ietf.org/mailman/listinfo/pim
-) > 
-)

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 6 Oct 2006 20:37:11 -0700 (PDT)

On Fri, 6 Oct 2006, John Zwiebel wrote:

-) 
-) On Oct 6, 2006, at 3:33 PM, Nidhi Bhaskar wrote:
-) 
-) > 
-) > I'm not disagreeing that Anycast RP is a great mechanism for RP
-) > fail-over. But I think there is still use for a dynamic mapping
-) > distribution protocol... So if the PIM WG would continue to be a place
-) > to discuss any improvements we may want to make to these, that would
-) > be a good thing in my opinion.
-) 
-) FWIW:  I've found a well-implemented BSR to be effective.
-) It works very well.
-) 

Would a well-implemented MSDPv6 result in further development, 
standardization and promotion of this protocol in MBoned?

-) At this point, there are very few deployments that I'm aware of
-) which use a distribution of RPs.  It may be that one RP-address
-) is more than adequate.  I do not think we have arrived at that
-) point yet.
-) 
-) If anyone cares, I'm an SSM/Bidir freak myself and think PIM-SM
-) should be killed.  And in such a "universe" RP distribution for
-) bidir groups should become very important.  So having a well-defined
-) BSR protocol could help a lot in making this happen.
-) 
-) Perhaps "someone" might figure out a way of doing a dykstra on the
-) receivers who have joined to a group to determine the optimum location
-) for the RP -- especially since the RP is just an arbitrary point in space.
-) In such a 'universe' the ability to quickly distribute RP information
-) will become important.
-) 

Good point about Bidir.  I forgot to mention that Anycast can also be used 
in the Bidir world.  By assigning multiple routers the same RP address, 
and tweeking IGP metrics to the RPA such that 1 RPA is always primary and 
is the closest reachable address in the domain, while a given backup would 
have it's IGP metric (for its RPA) so high that it would only be used (by 
all routers in a domain) if the primary was down.  This simple IGP hack 
would create a poor-man's-anycast address such that instead of multiple 
routers being active at the same time, only one would be active, but you'd 
get the same failover.