Re: [pim] PIM WG recharter

[Haoweiguo <[e-mail]>]

The MCAST WG will be responsible for protocol development for both multicast overlays and underlays unless otherwise specified in another working group. When multicast related specifications occur outside the MCAST WG, the MCAST WG will provide guidance.



[weiguo]: I also agree the above recharter text. It can ensure all multicast related solution find its home in IETF. PIM WG has many multicast experts, it's an ideal place to design novel multicast solutions not specified in other working groups.



Thanks,

weiguo

________________________________
From: pim [[e-mail]] on behalf of Jeff Tantsura [[e-mail]]
Sent: Sunday, January 25, 2015 3:54
To: <[e-mail]>
Cc: [e-mail]
Subject: Re: [pim] PIM WG recharter

Same here!

Regards,
Jeff

On Jan 24, 2015, at 9:44 AM, Greg Shepherd <[e-mail]<mailto:[e-mail]>> wrote:

On Sat, Jan 24, 2015 at 9:24 AM, Mike McBride <[e-mail]<mailto:[e-mail]>> wrote:
PIM is renamed MCAST with a new charter. We are left with MCAST and MBONED. Pretty much what we have today with PIM and MBONED. Just officially expanding the scope beyond pim protocol.

I was expecting PIM to become the new mcast catch-all for those bit which don't have their own WG, OR mcast bits from other WGs that need mcast expert input and review. But I wouldn't expect all mcast work to fall into a single WG anymore than I'd expect all unicast work to have one WG.

Greg


mike

> On Jan 24, 2015, at 8:14 AM, "Dino Farinacci" <[e-mail]<mailto:[e-mail]>> wrote:
>
> So are you adding a new WG called the MCAST WG and the PIM and MBONED WGs still exist?
>
> Dino
>
>> On Jan 23, 2015, at 9:06 PM, Mike McBride <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Yes, sorry if we weren't clear in the last mboned and pim meeting. We don't have any current plans to merge the wg's but we can certainly consider that. I feel its good to continue having a multicast protocol wg and a separate multicast operations wg. But continue meeting back to back, when possible, in the face to face meetings. That was successful in Honolulu.
>>
>> WRT the text I added for the MCAST WG, how about we modify it to "The MCAST WG will be responsible for protocol development for both multicast overlays and underlays unless otherwise specified in another working group. When multicast related specifications occur outside the MCAST WG, the MCAST WG will provide guidance." ???
>>
>> This should protect you Greg from the MCAST WG stepping on BIERs toes. And allows other WGs to punt to MCAST as needed.
>>
>> mike
>>
>> -----Original Message-----
>> From: pim [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Dino Farinacci
>> Sent: Friday, January 23, 2015 5:15 PM
>> To: Alia Atlas
>> Cc: Greg Shepherd; [e-mail]<mailto:[e-mail]>
>> Subject: Re: [pim] PIM WG recharter
>>
>>
>>> To consider if it made sense, which is different from being urged to.
>>> :-)
>>
>> Well that is maybe the way it was transmitted, but it was recieved by this receiver differnently.  ;-)
>>
>> Dino
>>
>>>
>>> Alia
>>>
>>> On Jan 23, 2015 7:22 PM, "Dino Farinacci" <[e-mail]<mailto:[e-mail]>> wrote:
>>> I thought the consensus from last PIM working group was to combine both PIM and MBONED working groups.
>>>
>>> I think we were a bit urged to do so from the ADs.
>>>
>>> Dino
>>>
>>>
>>>> On Jan 23, 2015, at 2:48 PM, Greg Shepherd <[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>> Sorry, but I disagree. It should NOT be responsible for all mcast protocol development. That's too much for one WG. It could provide technical review and oversight for multi point solutions, at most.
>>>>
>>>> Greg
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Jan 23, 2015, at 17:29, Mike McBride <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>
>>>>> Thanks Dino, good idea. I'll add "The MCAST WG will be responsible for requirement definition and protocol development for both multicast overlays and underlays."
>>>>>
>>>>> mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dino Farinacci [mailto:[e-mail]<mailto:[e-mail]>]
>>>>> Sent: Friday, January 23, 2015 9:20 AM
>>>>> To: Mike McBride
>>>>> Cc: [e-mail]<mailto:[e-mail]>
>>>>> Subject: Re: [pim] PIM WG recharter
>>>>>
>>>>> Is there a way to add to the charter that the MCAST WG will be responsible for requirement definition and protocol development for both multicast overlays as well as multicast underlays?
>>>>>
>>>>> Because there exists working groups today (nvo3 wg that has multicast requirements, LISP wg that designs overlays for unicast and multicast, BIER wg that designs multicast underlays, etc) that do part of this but the MCAST WG is a good place to coordinate and take a holistic view.
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Jan 22, 2015, at 11:30 PM, Mike McBride <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> Stig and I hope you had a wonderful start to your new year.
>>>>>>
>>>>>> We hope to have a wonderful start for pim in 2015 as well. We've discussed rechartering for the past year and Stig and I have made a first pass below. Thanks to Bill Atwood and Lucy Yong in providing edits to this draft. Please review and comment on this proposed new charter and wg renaming. Through the MCAST WG (Protocols) and the MBONED WG (Operations) we should be able to more effectively standardize multicast technologies.
>>>>>>
>>>>>> Thanks,
>>>>>> mike
>>>>>>
>>>>>> New:
>>>>>>
>>>>>> Charter for Working Group
>>>>>>
>>>>>> The standardization of PIM was completed with RFC 4601 within the PIM WG. The MCAST 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, along with extensions to PIM-SSM and PIM-BIDIR. These multicast extensions will involve reliability, resiliency, scalability, management, mobility and security. The MCAST WG will continue to work on developing the IGMP/MLD protocols as needed to achieve the robustness needed, particularly in mobile environments.
>>>>>>
>>>>>> As other WGs determine that support for multicast in their domains requires multicast specific extensions to PIM, IGMP/MLD, IGPs, or other yet to be invented multicast specific protocols, then such extensions should be developed within the MCAST WG. Additional work on existing PIM-BIDIR, BSR and SSM drafts may also be necessary by the WG as these drafts progress through Standards Track.
>>>>>>
>>>>>> The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The MCAST WG will work on proposals that update or extend the existing MIB modules and will develop YANG modules for multicast protocols.
>>>>>>
>>>>>> The MCAST 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. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable multicast, pim join attributes and authentication.
>>>>>>
>>>>>> There is a significant number of errata that need to be addressed in order to advance RFC4601 to Internet Standard. The MCAST WG will correct the errata and update RFC4601.
>>>>>>
>>>>>> The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required.
>>>>>>
>>>>>> Current:
>>>>>>
>>>>>> Charter for 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 will involve reliability, resiliency, scalability, management, and security.
>>>>>>
>>>>>> If L2VPN or L3VPN WGs determine that support for multicast in
>>>>>> L2VPNs and/or L3VPNs requires extensions to PIM, then such
>>>>>> extensions will be developed within the PIM WG.
>>>>>>
>>>>>> Additional work on the PIM-BIDIR and BSR drafts may also be
>>>>>> necessary by the WG as these drafts progress through Standards Track.
>>>>>>
>>>>>> The working group has produced MIB modules for PIM in RFC 5060 and
>>>>>> RFC 5240. The working group currently has no plans to do further
>>>>>> work on management for PIM. If proposals are brought forward to
>>>>>> update or extend the existing MIB modules or to develop YANG
>>>>>> modules, the working group will be rechartered.
>>>>>>
>>>>>> 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.
>>>>>> We will accomplish these enhancements by submitting drafts, to the
>>>>>> IESG, involving reliable pim, pim join attributes and pim
>>>>>> authentication.
>>>>>>
>>>>>> The working group primarily works on extensions to PIM, but may
>>>>>> take on work related to IGMP/MLD.
>>>>>>
>>>>>> There is a significant number of errata that need to be addressed
>>>>>> in order to advance RFC4601 to Draft Standard. The PIM WG will
>>>>>> correct the errata, as necessary, and update RFC4601.
>>>>>>
>>>>>> The working group will initiate a new re-chartering effort if it
>>>>>> is determined that a Version 3 of PIM is required.
>>>>>>
>>>>>> _______________________________________________
>>>>>> pim mailing list
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/pim
>>>>>
>>>>> _______________________________________________
>>>>> pim mailing list
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/pim
>>>
>>> _______________________________________________
>>> pim mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/pim
>>
>> _______________________________________________
>> pim mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/pim
>

_______________________________________________
pim mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pim