Subject: [pim] New PIM Charter rev3

From: Mike McBride <[email-masked]>
Date: Thu, 1 Feb 2007 22:12:43 -0800 (PST)

All comments, both on and off list, have been addressed in the following 
revised Charter/Milestones. Thank you for you feedback. Please review this 
latest revision:

Description of Working Group:

The Protocol Independent Multicast (PIM) Working Group has completed the 
standardization of PIM with RFC 4601. The WG has determined there is 
additional work to be accomplished and is chartered to standardize 
extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse 
Mode. These PIM extensions could involve reliability, resiliency, 
scalability, management, and security.

The PIM WG will also consider implications of VPN service on PIM when it's 
a component of that service or when PIM interfaces with that service at a 
VPN edge. If L2VPN or L3VPN WGs determine that support for multicast in 
L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions 
could be developed within the PIM WG.

Additional work on PIM-BIDIR and BSR may also be necessary.

The working group will continue to specify the MIBs required for PIM and 
its enhancements.

The PIM WG will further enhance RFC4601 as an even more 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 is required.

Goals and Milestones:

Mar    2007     Ratify new WG charter and milestones
Jul    2007     Submit the BSR MIB as a Proposed Standard
Nov    2007     Propose a more reliable pim solution which includes 
refresh reduction
Nov    2007     Submit a generic TLV PIM Join Attribute Proposed Standard 
draft
Nov    2007     Submit RPF Vector (use of PIM Join Attribute) as a 
Proposed Standard
Nov    2007     Submit a mechanism to authenticate PIM link local messages 
as PS
Nov    2007     Submit an Informational PIM last hop threats document.

thanks,
mike

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

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 2 Feb 2007 07:20:15 -0800 (PST)

How about widening the scope a bit more?  With the deaths of such WGs as 
Magma and IDMR, there is no WG that handles mcast routing and group 
membership protocols outside of PIM anymore.  Currently, Mboned is used as 
the catch-all WG for these issues.  However, protocol development is 
explicitly out of scope for Mboned.  What about renaming the PIM WG the 
Mcast Routing Protocols WG, and it would then be responsible for all mcast 
routing and group membership protocol developments.  Specifically, it 
would include PIM, IGMP, MLD, MSDP, BGMP, etc.  The amount of IGMP, MLD, 
MSDP and BGMP development is quite minimal at this time, but it does 
occasionally occur, and it would be good for it to have an appropriate and 
welcome home.

Mboned would still handle deployment issues, addressing and transition, 
and the protocols that support each (AMT, MADCAP, etc).

In any event, I do think it would be worthwhile to formally bifurcate 
deployment and routing protocols into 2 separate WGs.

Any thoughts?

-Lenny

On Thu, 1 Feb 2007, Mike McBride wrote:

-) All comments, both on and off list, have been addressed in the following
-) revised Charter/Milestones. Thank you for you feedback. Please review this
-) latest revision:
-) 
-) Description of Working Group:
-) 
-) The Protocol Independent Multicast (PIM) Working Group has completed the
-) standardization of PIM with RFC 4601. The WG has determined there is
-) additional work to be accomplished and is chartered to standardize extensions
-) to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These
-) PIM extensions could involve reliability, resiliency, scalability,
-) management, and security.
-) 
-) The PIM WG will also consider implications of VPN service on PIM when it's a
-) component of that service or when PIM interfaces with that service at a VPN
-) edge. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs
-) and/or L3VPNs requires extensions to PIM, then such extensions could be
-) developed within the PIM WG.
-) 
-) Additional work on PIM-BIDIR and BSR may also be necessary.
-) 
-) The working group will continue to specify the MIBs required for PIM and its
-) enhancements.
-) 
-) The PIM WG will further enhance RFC4601 as an even more 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 is required.
-) 
-) Goals and Milestones:
-) 
-) Mar    2007     Ratify new WG charter and milestones
-) Jul    2007     Submit the BSR MIB as a Proposed Standard
-) Nov    2007     Propose a more reliable pim solution which includes refresh
-) reduction
-) Nov    2007     Submit a generic TLV PIM Join Attribute Proposed Standard
-) draft
-) Nov    2007     Submit RPF Vector (use of PIM Join Attribute) as a Proposed
-) Standard
-) Nov    2007     Submit a mechanism to authenticate PIM link local messages as
-) PS
-) Nov    2007     Submit an Informational PIM last hop threats document.
-) 
-) thanks,
-) mike
-) 
-) _______________________________________________
-) pim mailing list
-) [email-masked]
-) https://www1.ietf.org/mailman/listinfo/pim
-)

---

From: Brian Haberman <[email-masked]>
Date: Fri, 02 Feb 2007 11:08:48 -0500

Hey!  I wouldn't call MAGMA dead, we are just resting. :)

Seriously, the group is still open since we have not published all of
our documents yet.  My intent is to keep the list open for the
discussion of group management related issues.

Regards,
Brian

---

From: Mike McBride <[email-masked]>
Date: Fri, 2 Feb 2007 13:41:40 -0800 (PST)

Good to hear Brian. So the necessary wg's exist for multicast. For new 
multicast protocols we (MBONED particularly) need to ensure we are in sync 
about the requirements and then consider new wg to close out that work.

I recommend we continue with the pim wg rechartering effort and review 
rev3.

mike