Subject: [pim] PIM WG recharter

From: Mike McBride <[email-masked]>
Date: Fri, 23 Jan 2015 07:30:41 +0000

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.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Jan 2015 09:20:06 -0800

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 <[email-masked]> wrote:
> 
> Hello all,
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Mike McBride <[email-masked]>
Date: Fri, 23 Jan 2015 22:29:55 +0000

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:[email-masked]] 
Sent: Friday, January 23, 2015 9:20 AM
To: Mike McBride
Cc: [email-masked]
Subject: Re: [pim] PIM WG recharter

Dino

> Sparse Mode. These PIM extensions will involve reliability, 
> resiliency, scalability, management, and security.
> 
> 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 working group primarily works on extensions to PIM, but may take 
> on work related to IGMP/MLD.
> 
> order to advance RFC4601 to Draft Standard. The PIM WG will correct 
> the errata, as necessary, and update RFC4601.
>

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 23 Jan 2015 17:48:46 -0500

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 <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Jan 2015 16:22:33 -0800

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 <[email-masked]> wrote:
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 23 Jan 2015 19:32:27 -0500

To consider if it made sense, which is different from being urged to. :-)

Alia
On Jan 23, 2015 7:22 PM, "Dino Farinacci" <[email-masked]> 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
> >
> >> 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
> >>
> >> 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
> >>
> >>> 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:
> >>>
> >>> 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.
> >>>
> 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,
> 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.
> >>>
> order to advance RFC4601 to Internet Standard. The MCAST WG will correct
> the errata and update RFC4601.
> >>>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Jan 2015 17:14:37 -0800

> 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

---

From: Mike McBride <[email-masked]>
Date: Sat, 24 Jan 2015 05:06:08 +0000

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:[email-masked]] On Behalf Of Dino Farinacci
Sent: Friday, January 23, 2015 5:15 PM
To: Alia Atlas
Cc: Greg Shepherd; [email-masked]
Subject: Re: [pim] PIM WG recharter

Dino

> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> efficient and robust multicast routing protocol, which is capable 
> >>> of supporting thousands of groups, different types of multicast 
> >>> 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.
> >>>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Sat, 24 Jan 2015 14:05:53 +0000

I agree with Greg. A statement as below is too broad and could be understood as all multicast is done in PIM which I do not believe was the intend or wasn't it?

Andrew

Sent from my iPhone

> On Jan 23, 2015, at 5:50 PM, Greg Shepherd <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 24 Jan 2015 08:14:35 -0800

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 <[email-masked]> wrote:
>

---

From: Mike McBride <[email-masked]>
Date: Sat, 24 Jan 2015 17:24:11 +0000

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. 

mike

> On Jan 24, 2015, at 8:14 AM, "Dino Farinacci" <[email-masked]> wrote:
>

---

From: Greg Shepherd <[email-masked]>
Date: Sat, 24 Jan 2015 09:44:28 -0800

On Sat, Jan 24, 2015 at 9:24 AM, Mike McBride <[email-masked]>
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

> >> 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
> >>
> >>>>> 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
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>> 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.
> >>>>>>
> RFC 5240. The MCAST WG will work on proposals that update or extend the
> in order to advance RFC4601 to Internet Standard. The MCAST WG will correct

---

From: Mike McBride <[email-masked]>
Date: Sat, 24 Jan 2015 17:56:59 +0000

Exactly.

mike

On Jan 24, 2015, at 9:44 AM, "Greg Shepherd" <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Jan 24, 2015 at 9:24 AM, Mike McBride <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Jan 23, 2015, at 9:06 PM, Mike McBride <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From: pim [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dino Farinacci
>> Cc: Greg Shepherd; [email-masked]<mailto:[email-masked]>
>>> On Jan 23, 2015 7:22 PM, "Dino Farinacci" <[email-masked]<mailto:[email-masked]>> wrote:
>>>> On Jan 23, 2015, at 2:48 PM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>> On Jan 23, 2015, at 17:29, Mike McBride <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>>>> From: Dino Farinacci [mailto:[email-masked]<mailto:[email-masked]>]
>>>>> Cc: [email-masked]<mailto:[email-masked]>
>>>>>> On Jan 22, 2015, at 11:30 PM, Mike McBride <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 24 Jan 2015 19:54:33 +0000

Same here!

Regards,
Jeff

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

Greg

mike

---

From: Haoweiguo <[email-masked]>
Date: Mon, 26 Jan 2015 02:51:17 +0000

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 [[email-masked]] on behalf of Jeff Tantsura [[email-masked]]
Sent: Sunday, January 25, 2015 3:54
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [pim] PIM WG recharter

Same here!

Regards,
Jeff

Greg

mike

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 26 Jan 2015 10:30:41 -0800

I think that widening the focus would be useful.

For example, I submitted a first draft on my proprosal for transactional 
subset multicast addresses
to tsvwg back in September 
(http://www.ietf.org/mail-archive/web/tsvwg/current/msg12823.html)
because the proposal is clearly a transport layer issue and does not in 
anyway depend on PIM.

But with this recharter the next draft would definitely belong to MCAST.

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 29 Jan 2015 12:05:14 -0500

On 1/24/2015 12:24 PM, Mike McBride wrote:
> "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."

I don't really understand this text; what is meant by "unless otherwise
specified in another working group"?

Do you mean something like "The MCAST WG will be responsible for any
multicast protocol development that is not being done in another WG"?
Or do you mean something more specific?

The charter language should have something that clearly prevents the
MCAST WG from asserting a claim to the multicast work going on in, e.g.,
BESS and BIER.

I don't like the following text:

> 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.

This text seems to lay claim to all yet-to-be-invented multicast protocols.

And what does "will provide guidance" mean?  I don't think we want any
language to suggest that the MCAST WG has veto power over work done in
other WGs.

And a nit:

> If L2VPN or L3VPN WGs determine

No such WGs.

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 29 Jan 2015 10:45:28 -0800

> MCAST WG from asserting a claim to the multicast work going on in, e.g.,
Some working group has to be the incubator for new ideas about X. As those
ideas develop they may warrant their own working group.

So the MCAST WG would be claiming "default multicast" topics, presumably
from TSVWG, and specific multicast topics could go to more specific WGs.

I don't see any problem with that.

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 30 Jan 2015 00:38:03 -0800

> ideas develop they may warrant their own working group.

That's what the BoF process is for. The result may be either that X is
given it's own WG or it is assigned to an existing WG. But this is a
decision of the ADs and not an oversee WG.

Greg