Subject: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

From: Michael McBride <[email-masked]>
Date: Tue, 14 Jan 2020 00:25:24 +0000

Happy New Year PIMers,

Today begins a two week call for adoption of draft-voyer-pim-sr-p2mp-policy-00 involving p2mp tree construction in a segment routing domain.

This draft has been presented in our face to face meetings, including most recently in Singapore, and the authors have asked for a call for adoption.

https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-00

Please read the draft and let the wg know if you think it's ready, or not, for adoption.

thanks,
mike

---

From: Rishabh Parekh <[email-masked]>
Date: Wed, 15 Jan 2020 16:46:13 -0800

Support as a co-author.

Thanks,
Rishabh

On Mon, Jan 13, 2020 at 4:25 PM Michael McBride
<[email-masked]> wrote:
> Please read the draft and let the wg know if you think it’s ready, or not, for adoption.
>
>
>
> thanks,
>
> mike
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 16 Jan 2020 01:12:56 +0000

Support as co-author.
Unaware of undisclosed IPRs.

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Rishabh Parekh
Sent: Thursday, January 16, 2020 9:46 AM
To: Michael McBride <[email-masked]>
Cc: [email-masked]
Subject: Re: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

Support as a co-author.

Thanks,
Rishabh

On Mon, Jan 13, 2020 at 4:25 PM Michael McBride <[email-masked]> wrote:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-voyer-pi
> m-sr-p2mp-policy-00__;!!NEt6yMaO-gk!TzGNXE8sA1TTRTyMHxyNtN-zy5boHVemwB
> 9hEikcYhm0Qhfd19JFLoV8xkPfsjgL$
>
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim_
> _;!!NEt6yMaO-gk!TzGNXE8sA1TTRTyMHxyNtN-zy5boHVemwB9hEikcYhm0Qhfd19JFLo
> V8xqwiiWHO$

_______________________________________________
pim mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!TzGNXE8sA1TTRTyMHxyNtN-zy5boHVemwB9hEikcYhm0Qhfd19JFLoV8xqwiiWHO$

---

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 16 Jan 2020 01:14:07 +0000

I support adoption.

The document lays out the architecture of P2MP Policy quite well. Having this adopted and work progressed will help with the related SPRING and PCE building blocks required to satisfy this architecture.

Thanks
Andrew

________________________________
From: pim <[email-masked]> on behalf of Michael McBride <[email-masked]>
Sent: Monday, January 13, 2020 7:25 PM
To: [email-masked] <[email-masked]>
Subject: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

Happy New Year PIMers,

thanks,

mike

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 15 Jan 2020 17:19:52 -0800

yes/support, good starting point

Cheers,
Jeff

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Thu, 16 Jan 2020 01:23:03 +0000

Support .

Mankamana
________________________________
From: pim <[email-masked]> on behalf of Michael McBride <[email-masked]>
Sent: Monday, January 13, 2020 16:25
To: [email-masked]
Subject: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

Happy New Year PIMers,

thanks,
mike

---

From: <[email-masked]>
Date: Thu, 16 Jan 2020 09:46:07 +0800 (CST)

Support the adoption.

Sandy

原始邮件

发件人：MichaelMcBride <[email-masked]>
收件人：[email-masked] <[email-masked]>;
日 期 ：2020年01月14日 08:25
主 题 ：[pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

Happy New Year PIMers,

 

 

 

 

thanks,

mike

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 16 Jan 2020 15:36:07 +0000

Support as co-author.

Regards

Hooman

From: pim <[email-masked]> On Behalf Of Michael McBride
Sent: Monday, January 13, 2020 7:25 PM
To: [email-masked]
Subject: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

Happy New Year PIMers,

thanks,
mike

---

From: "Kundu, Tanmoy (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 17 Jan 2020 18:24:21 +0000

I support the draft for WG adoption.

Thanks,
Tanmoy

From: pim <[email-masked]> On Behalf Of Michael McBride
Sent: Monday, January 13, 2020 4:25 PM
To: [email-masked]
Subject: [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00

Happy New Year PIMers,

thanks,
mike

---

From: "Mehta, Dhaval (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 20 Jan 2020 23:03:27 +0000

I support.

Thank you,
Dhaval

Happy New Year PIMers,

thanks,
mike

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 20 Jan 2020 18:18:10 -0500

Authors

I support but do have a few comments and questions on the draft below.

This draft documents the data plane aspects of instantiation of P2MP trees
for ASM and SSM or MP2MP for PIM Birdir over SR-MPLS via centralized PCE
controller. Does this model support distributed and hybrid models of tree
instantiation.  That is not mentioned in the draft.  Please point out where
mentioned if it is so.  If this draft does not support hybrid or
distributed instantiation please explain why.

The document mentions SR but does not state SR-MPLS.  There are two flavors
of SR via SR-MPLS reusing MPLS dataplane or SRv6 using IPv6 dataplane.

I am guessing SRv6 MDT instantiation is out of scope of this document which
should be mentioned.

Does this draft use reuse the MVPN procedures defined in RFC 6513 and 6514
instantiation of UI-PMSI MI-PMSI inclusive Default MDT and S-PMSI selective
Data MDT.  In the draft I don’t see mention of reuse of the BGP MVPN
procedures.

This document does not talk about fast reroute of MDT in the context of
SR-MPLS SR-TE.

Kind regards

Gyan

On Mon, Jan 20, 2020 at 6:03 PM Mehta, Dhaval (Nokia - US/Mountain View) <
[email-masked]> wrote:

> I support.
>
>
>
> Thank you,
>
> Dhaval
>
>
>
> *From:* pim <[email-masked]> *On Behalf Of * Michael McBride
> *Sent:* Monday, January 13, 2020 4:25 PM
> *To:* [email-masked]
> *Subject:* [pim] Call for adoption: draft-voyer-pim-sr-p2mp-policy-00
>
>
>
> Happy New Year PIMers,
>
>
>
> Today begins a two week call for adoption of
> draft-voyer-pim-sr-p2mp-policy-00 involving p2mp tree construction in a
> segment routing domain.
>
>
>
> This draft has been presented in our face to face meetings, including most
> recently in Singapore, and the authors have asked for a call for adoption.
>
>
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Rishabh Parekh <[email-masked]>
Date: Tue, 21 Jan 2020 10:30:48 -0800

Gyan,

>This draft documents the data plane aspects of instantiation of P2MP trees for ASM and SSM or MP2MP for PIM Birdir over SR-MPLS via centralized PCE controller. Does this model support distributed and hybrid models of tree instantiation.  That is not >mentioned in the draft.  Please point out where mentioned if it is so.  If this draft does not support hybrid or distributed instantiation please explain why.

This draft do not cover distributed tree building protocols since
these are already specified for both IP and MPLS.

>The document mentions SR but does not state SR-MPLS.  There are two flavors of SR via SR-MPLS reusing MPLS dataplane or SRv6 using IPv6 dataplane.
>I am guessing SRv6 MDT instantiation is out of scope of this document which should be mentioned

Trees using SRv6 data plane can also be instantiated using SR-PCE,
similar to SR-MPLS. This would be added in future revision of the doc.

>Does this draft use reuse the MVPN procedures defined in RFC 6513 and 6514 instantiation of UI-PMSI MI-PMSI inclusive Default MDT and S-PMSI selective Data MDT.  In the draft I don’t see mention of reuse of the BGP MVPN procedures.

This draft is just for tree instantiation.
draft-parekh-bess-mvpn-sr-p2mp-01 documents use of such trees for
MVPN.

>This document does not talk about fast reroute of MDT in the context of SR-MPLS SR-TE

There is a brief mention of FRR in Section 4.4.1

Thanks,

-Rishabh

On Mon, Jan 20, 2020 at 3:18 PM Gyan Mishra <[email-masked]> wrote:
> This draft documents the data plane aspects of instantiation of P2MP trees for ASM and SSM or MP2MP for PIM Birdir over SR-MPLS via centralized PCE controller. Does this model support distributed and hybrid models of tree instantiation.  That is not mentioned in the draft.  Please point out where mentioned if it is so.  If this draft does not support hybrid or distributed instantiation please explain why.
>
> The document mentions SR but does not state SR-MPLS.  There are two flavors of SR via SR-MPLS reusing MPLS dataplane or SRv6 using IPv6 dataplane.
>
> I am guessing SRv6 MDT instantiation is out of scope of this document which should be mentioned.
>
> Does this draft use reuse the MVPN procedures defined in RFC 6513 and 6514 instantiation of UI-PMSI MI-PMSI inclusive Default MDT and S-PMSI selective Data MDT.  In the draft I don’t see mention of reuse of the BGP MVPN procedures.
>
> This document does not talk about fast reroute of MDT in the context of SR-MPLS SR-TE.
>
>
> Kind regards
>
> Gyan
>
> On Mon, Jan 20, 2020 at 6:03 PM Mehta, Dhaval (Nokia - US/Mountain View) <[email-masked]> wrote:
>>
>> I support.
>>
>>
>>
>> Thank you,
>>
>> Dhaval
>>
>>
>>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 21 Jan 2020 17:53:32 -0500

Hi Rishabh

Response in-line

Kind regards

Gyan

On Tue, Jan 21, 2020 at 1:31 PM Rishabh Parekh <[email-masked]> wrote:

> Gyan,
>
> >This draft documents the data plane aspects of instantiation of P2MP
> trees for ASM and SSM or MP2MP for PIM Birdir over SR-MPLS via centralized
> PCE controller. Does this model support distributed and hybrid models of
> tree instantiation.  That is not >mentioned in the draft.  Please point out
> where mentioned if it is so.  If this draft does not support hybrid or

    Gyan>I believe the main goal of this draft is introducing the P2MP MDT
instantiation root Tree-SID and leaf replication-SID over SR-MPLS.  Is this
the first draft that introduces these two new SIDs for multicast?

Gyan> Distributed tree building protocols over SR-MPLS would also use the
same MVPN procedures in RFC 6513 and 6514 ; however for P2MP trees to be
instantiation they would need the root tree-sid and leaf replication-sid
and use of binding sid for SR policy to steer traffic into the P2MP p-tree
as described in this draft.    What is sister draft if it exists that talks
about this very topic of  SR-MPLS P2MP p-tree instantiation using tree-sid
and replication-sid in a  distributed or hybrid model?

> >The document mentions SR but does not state SR-MPLS.  There are two
> flavors of SR via SR-MPLS reusing MPLS dataplane or SRv6 using IPv6
> dataplane.
> >Does this draft use reuse the MVPN procedures defined in RFC 6513 and
> 6514 instantiation of UI-PMSI MI-PMSI inclusive Default MDT and S-PMSI
> selective Data MDT.  In the draft I don’t see mention of reuse of the BGP
> MVPN procedures.
>

 Gyan>  From the MVPN draft appears all the MVPN procedures are the same
for P2MP tree instantiation over SR using the new tree-sid and
replication-sid.  As far as the p-tree tunnel id  types that would be
supported I am guessing only IR (ingress replication)
and all the PIM trees for Rosen tunnels.  Anything RSVP TE or mLDP based
would not be supported.  I am guessing PIM Birdir c-multicast over p-tree
would not be supported since MP2MP would now not be possible over SR due to
lack of mLDP MP2MP LSP.  Im

Gyan>As far as MVPN since mostly there is no change for instantiation of
trees are the route types numbering 1-7 am guessing stays the same.  Not
sure if that is vendor specific with the MVPN route type numbering.

Gyan>Would BIER (bit indexes replication) for stateless trees be supported
with this draft or future updates?  I believe BIER supports MP2MP MDT trees
so If SR supports BIER then that could provide support for MP2MP.

> SR-MPLS SR-TE
> Gyan>With FRR I see 1:1  backup  but would facility backup be supported
> N:1 .  Since SR-MPLS reused the ldp data plane with label stack traffic
> steering I think N:1 facility backup is still relevant. There maybe a
> future separate draft  on SR-TE P2P LSP unicast protection and P2MP MDT
> tree protection.

> > This draft documents the data plane aspects of instantiation of P2MP
> trees for ASM and SSM or MP2MP for PIM Birdir over SR-MPLS via centralized
> PCE controller. Does this model support distributed and hybrid models of
> tree instantiation.  That is not mentioned in the draft.  Please point out
> where mentioned if it is so.  If this draft does not support hybrid or
> > The document mentions SR but does not state SR-MPLS.  There are two
> flavors of SR via SR-MPLS reusing MPLS dataplane or SRv6 using IPv6
> dataplane.
> >
> > Does this draft use reuse the MVPN procedures defined in RFC 6513 and
> 6514 instantiation of UI-PMSI MI-PMSI inclusive Default MDT and S-PMSI
> selective Data MDT.  In the draft I don’t see mention of reuse of the BGP
> MVPN procedures.
> >
> >> This draft has been presented in our face to face meetings, including
> most recently in Singapore, and the authors have asked for a call for
> adoption.
> >>
> >>
> >>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Rishabh Parekh <[email-masked]>
Date: Tue, 21 Jan 2020 16:45:21 -0800

Gyan>I believe the main goal of this draft is introducing the P2MP MDT
instantiation root Tree-SID and leaf replication-SID over SR-MPLS.  Is
this the first draft that introduces these two new SIDs for multicast?

To be precise, this draft is about building a tree by stitching
Replication Segments (see draft-voyer-spring-sr-replication-segment)
using a PCE. Tree-SID is just a special case where the
Replication-SIDs of all the Replicatoin Segments of the tree are
identical. Effectively, there is only one new SID, the Replication-SID
and that is defined by the Replicatoin Segment draft.

Gyan> Distributed tree building protocols over SR-MPLS would also use
the same MVPN procedures in RFC 6513 and 6514 ; however for P2MP trees
to be instantiation they would need the root tree-sid and leaf
replication-sid and use of binding sid for Gyan> SR policy to steer
traffic into the P2MP p-tree as described in this draft.    What is
sister draft if it exists that talks about this very topic of  SR-MPLS
P2MP p-tree instantiation using tree-sid and replication-sid in a
distributed or hybrid model?

I am not sure I understand your question completely, but let me try to
answer. Think of Tree-SID as an alternate option to PIM, mLDP, RSVP-TE
P2MP and IR. You don't need Tree-SID to use these distributed
protocols in SR domain; if desired they can run as "ships in the
night" with unicast SR.

Gyan> From the MVPN draft appears all the MVPN procedures are the same
for P2MP tree instantiation over SR using the new tree-sid and
replication-sid.  As far as the p-tree tunnel id  types that would be
supported I am guessing only IR (ingress Gyan> replication) and all
the PIM trees for Rosen tunnels.  Anything RSVP TE or mLDP based would
not be supported.

Again, I don't unsderstand the above text. I hope my earlier response
about Tree-SID being a distinct (and stand alone) opton to other
P-Tree distributed technologies is suffciently clear to address the
above.

Gyan>I am guessing PIM Birdir c-multicast over p-tree would not be
supported since MP2MP would now not be possible over SR due to lack of
mLDP MP2MP LSP.  Im

Not necessarily. For example, some concepts from RFC 7740 (Simulting
MP2MP using IR) can be used, but we will have to look at the details.

Gyan>As far as MVPN since mostly there is no change for instantiation
of trees are the route types numbering 1-7 am guessing stays the same.
Not sure if that is vendor specific with the MVPN route type
numbering.

Yes, MVPN route types remain unchanged. A new Tunnel Type for Tree-SID
is defined in PMSI Tunnel Attribute.

Gyan>Would BIER (bit indexes replication) for stateless trees be
supported with this draft or future updates?  I believe BIER supports
MP2MP MDT trees so If SR supports BIER then that could provide support
for MP2MP.

BIER is an orthogonal discussion wrt to this draft. It is a distinct
P-Tree technology by itself and therefore not needed to be addressed
in this draft.

-Rishabh

On Tue, Jan 21, 2020 at 2:53 PM Gyan Mishra <[email-masked]> wrote:
>     Gyan>I believe the main goal of this draft is introducing the P2MP MDT instantiation root Tree-SID and leaf replication-SID over SR-MPLS.  Is this the first draft that introduces these two new SIDs for multicast?
>
> Gyan> Distributed tree building protocols over SR-MPLS would also use the same MVPN procedures in RFC 6513 and 6514 ; however for P2MP trees to be instantiation they would need the root tree-sid and leaf replication-sid and use of binding sid for SR policy to steer traffic into the P2MP p-tree as described in this draft.    What is sister draft if it exists that talks about this very topic of  SR-MPLS P2MP p-tree instantiation using tree-sid and replication-sid in a  distributed or hybrid model?
>
>>
>  Gyan>  From the MVPN draft appears all the MVPN procedures are the same for P2MP tree instantiation over SR using the new tree-sid and replication-sid.  As far as the p-tree tunnel id  types that would be supported I am guessing only IR (ingress replication)
> and all the PIM trees for Rosen tunnels.  Anything RSVP TE or mLDP based would not be supported.  I am guessing PIM Birdir c-multicast over p-tree would not be supported since MP2MP would now not be possible over SR due to lack of mLDP MP2MP LSP.  Im
>
> Gyan>As far as MVPN since mostly there is no change for instantiation of trees are the route types numbering 1-7 am guessing stays the same.  Not sure if that is vendor specific with the MVPN route type numbering.
>
> Gyan>Would BIER (bit indexes replication) for stateless trees be supported with this draft or future updates?  I believe BIER supports MP2MP MDT trees so If SR supports BIER then that could provide support for MP2MP.
>>
>>
>>
>> Gyan>With FRR I see 1:1  backup  but would facility backup be supported N:1 .  Since SR-MPLS reused the ldp data plane with label stack traffic steering I think N:1 facility backup is still relevant. There maybe a future separate draft  on SR-TE P2P LSP unicast protection and P2MP MDT tree protection.
>>
>>
>> Thanks,
>>
>> -Rishabh
>>
>>
>>
>>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 22 Jan 2020 01:29:47 -0500

> and that is defined by the Replicatoin Segment draft.

   Gyan>. Understood.  The replication-SID allows for stitching all the
 leaf branches with binding SID to the root Tree-SID using the same MVPN
procedures for tree instantiation.  Makes sense and I fully support the
draft concept.  With SR-MPLS you also have the option of using Sandy’s BGP
based multicast for building multicast distribution trees and LHR source
discovery.

https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast/

> protocols in SR domain; if desired they can run as "ships in the

   Gyan> With SR-MPLS for c-multicast signaling over p-tree  ; the only P
tunnel that can be instantiated  prior to this draft is IR, PIM Rosen trees
using existing MVPN procedures or BIER.  Sandy’s BGP multicast draft above
also provides another method of tree instantiation prior to this draft.  So
you are stating that those P tunnel models can the distributed model today
which is why they are not mentioned in this draft.  So now this draft
provides yet another P tree type that now that uses SR natively that can be
instantiated.  What is the benefit of using this draft for tree
instantiation over the other pre existing options.  With this draft you are
natively doing the replication in the forwarding plane with
replication-SID.  Would this drafts tree building method be more
efficient??    SR-MPLS with ldp and RSVP TE removed from the core ; now
reusing the existing MPLS data plane for SR label stacking SRGB labels ;
indexes or absolute labels.  So mLDP is RSVP TE is no longer an alternative
with SR of course once a customer is completely migrated to SR-MPLS.  That
would be the real world SR-MPLS end state use case then an intermediate
migration two ships in the night use case with SR-MPLS and ldp are
coexisting and now the other P tunnel options exist.   I was thinking of
the “SR prefer” option where you shutdown and eventually remove ldp.   I
think you are thinking of  SR-MPLS w/ ldp interworking - with overlay paths
that exist to prefix SID FEC destination or  for an LDP LSP and exist as
two ships in the night - ldp has FEC binding as well for a different prefix
loopback on the egress PE.  So with SR with ldp interworking both SR-MPLS
and ldp can coexist as two ships in the night.  Draft below shows the
SR-MPLS and LDP interoperability within the same MPLS domain as two ships
in the night.  I have not tried overlay of ldp and SR on the same nodes and
having a different FEC loopback for SR from ldp ; so both SR and LDP LSPs
can coexist in the same nodes and same links along the same paths with
different FEC label bindings.  I believe it is possible. For SRv6 and
SR-MPLS also the same can coexist and so really per the drafts below all
three can coexist as 3 ships in the night.  I think with all 3 ; if you do
different nodes and different paths or same nodes different links and
paths,  that will definitely work ; but not sure if you can do same nodes
same paths with different FEC binding for all three flavors.

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-15

https://datatracker.ietf.org/doc/draft-agrawal-spring-srv6-mpls-interworking/

> MP2MP using IR) can be used, but we will have to look at the details.

   Gyan> Makes sense to use IR in both direction for PIM Birdir trees where
each branch is root and leaf.  Why can’t you do the same IR replication
process methodology with this draft ; same concept and extent the
replication-sid stitching to MP2MP in which case you would not have a
tree-SID since both left and right side of tree would now be MP leaf
branches.  You could use the MVPN type 4 leaf-ad from leaf to discover the
MP branch on the left and right side and do the replication-sid stitching
in both directions to support MP2MP MDTs.  What do you think ; is that a
possibility?

> is defined in PMSI Tunnel Attribute.

  Gyan> I saw the new tunnel codepoint - TBD

IANA to assign a codepoint [[CREF2: TBD]] for "P2MP tree" in the
   "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types"
   registry.

https://tools.ietf.org/html/draft-parekh-bess-mvpn-sr-p2mp-01

> P-Tree technology by itself and therefore not needed to be addressed

  Gyan> Understood.  Agreed.

> >     Gyan>I believe the main goal of this draft is introducing the P2MP
> MDT instantiation root Tree-SID and leaf replication-SID over SR-MPLS.  Is
> the same MVPN procedures in RFC 6513 and 6514 ; however for P2MP trees to
> be instantiation they would need the root tree-sid and leaf replication-sid
> supported with this draft or future updates?  I believe BIER supports MP2MP
> MDT trees so If SR supports BIER then that could provide support for MP2MP.
> >>
> >>
> >>
> >> >> This draft has been presented in our face to face meetings,
> including most recently in Singapore, and the authors have asked for a call
> for adoption.
> >> >>
> >> >>
> >> >>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Michael McBride <[email-masked]>
Date: Tue, 28 Jan 2020 23:36:28 +0000

Hello,

We have solid support to adopt this draft. Thank you all for the replies.

Authors, we are waiting to hear back from the spring chairs as to the wg status of the local replication draft of which your draft is dependent. So please hold off on submitting the new draft-ietf-pim-sr-p2mp-policy until they give us the green light.

Thanks!
mike

Happy New Year PIMers,

https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-pim-sr-p2mp-policy-00&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7Ced7ea956ae67438ac8cf08d79888461b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637145583381587919&sdata=dMzjV40W%2BS16qqE3cxvweHRZ%2BTbSyLYDxq81ettCsM0%3D&reserved=0>

thanks,
mike