Sue, This draft is about MVPN and EVPN services in SR-MPLS/SRv6 domain using SR-P2MP Policy or Ingress Replication and is orthogonal to draft-ietf-idr-sr-p2mp-policy-00.
draft-ietf-idr-sr-p2mp-policy-00 is about using BGP for signalling of a SR-P2MP tree (computed from a SR-P2MP Policy) from a controller (PCE) to devices in SR domain. This is similar to draft-ietf-pce-sr-p2mp-policy which specifies PCEP signalling. This draft does not replace either of the above drafts, but needs one of them for a complete solution. -Rishabh. On Wed, Jan 14, 2026 at 3:34 PM Susan Hares <[email protected]> wrote: > Rishabh: > > > > Ae you still considering the work in draft-ietf-idr-sr-p2mp-policy-00? > > > > Or does this draft replace it? > > > > Sue > > > > > > *From:* Rishabh Parekh <[email protected]> > *Sent:* Tuesday, January 13, 2026 3:22 PM > *To:* [email protected] > *Cc:* [email protected]; [email protected]; [email protected] > *Subject:* [bess] Re: WG review requested on > draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th > > > > Eduard, SR P2MP Policy draft does not have the text since it does not deal > with MVPN/EVPN. All the CPs of an SR-P2MP Policy result in SR P2MP trees > computed and instantiated in an SR domain. Therefore, it is obvious if > SR-P2MP Policy is used > > Eduard, > > SR P2MP Policy draft does not have the text since it does not deal with > MVPN/EVPN. > > > > All the CPs of an SR-P2MP Policy result in SR P2MP trees computed and > instantiated in an SR domain. Therefore, it is obvious if SR-P2MP Policy is > used for MVPN./EVPN, the P-tunnel type for these SR-P2MP trees will be > SR-MPLS or SRv6 P2MP P-tunnel type. But if you think this document requires > some text to clarify this, I can add it in the next revision. > > > > Regards, > > Rishabh > > > > On Tue, Jan 13, 2026 at 11:56 AM <[email protected]> wrote: > > Thanks! > > > > [RP] All the P-tunnels instantiated by different Candidate Paths of an SR > P2MP Policy have either SR-MPLS P2MP Tree or SRv6 P2MP Tree. > > > > I was looking for something like this. Is this defined somewhere (maybe in > the policy draft, I did not check)? If not, is it worth adding? > > > > cheers, > > Eduard > > > > > ------------------------------ > > *From:* Rishabh Parekh <[email protected]> > *Sent:* Tuesday, January 13, 2026 18:58 > *To:* Metz, Eduard <[email protected]> > *Cc:* [email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]> > *Subject:* Re: [bess] Re: WG review requested on > draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th > > > > Eduard, > > Thanks for the review. Comments inline @ [RP] > > > > On Tue, Jan 13, 2026 at 7:03 AM <[email protected]> > wrote: > > For what it's worth, the change in structure I think has improved > readability. > > > > Few small points I noted: > > There is a type in section 3.1.3: "carried in AFI/SAFI 1/129 (MVPN-IPv4) > or 1/129 (MVPN-IPv6)", should be "... 2/129 (MVPN-IPv6)" > > > > [RP] Good catch. Will fix it in the next revision. > > > > > > In section 3.2.1 is stated: > > "For segmented P-tunnels, each segment can be instantiated by a different > technology." > > > > Instead of "different technology" would it be better to state "different > tunnel type"? I assume at least this refers to the tunnel type. > > > > [RP] Good suggestion. We will change the text in the next revision. > > > > Related to this, should some similar text be included for regular, > non-segmented tunnels? Are the tunnel-types of all CPs and tunnel instances > in a policy assumed to be the same, or could these be different? > > > > [RP] All the P-tunnels instantiated by different Candidate Paths of an SR > P2MP Policy have either SR-MPLS P2MP Tree or SRv6 P2MP Tree. > > > > Segmented P-tunnels are segmented and stitched at a boundary, say an ASBR > or ABR (for seamless MPLS like deployments). The first segment can be SR > P2MP P-tunnel type, the second segment can be Ingress Replication P-tunnel > type, the third can be MLDP P-tunnel type and so on. OTOH, non-segmented > P-tunnels have one P-tunnel of a given type (across the boundary devices). > I hope this clarifies the distinction between these two ways to instantiate > P-tunnels. > > > > > > cheers, > > Eduard > > > > > > > ------------------------------ > > *From:* Stephane Litkowski (slitkows) <[email protected] > > > *Sent:* Monday, January 12, 2026 10:57 > *To:* [email protected] <[email protected]> > *Cc:* '[email protected]' <[email protected]> > *Subject:* [bess] WG review requested on > draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th > > > > Hi WG, > > > > As result of the IESG review, draft-ietf-bess-mvpn-evpn-sr-p2mp has been > modified significantly. > > We would like to ensure that there is still consensus on the document text > after these changes. > > > > Please carefully read the document and provide any objection/comment by > January 19th. > > > > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-sr-p2mp-15&url2=draft-ietf-bess-mvpn-evpn-sr-p2mp-17&difftype=--html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl1-3Ddraft-2Dietf-2Dbess-2Dmvpn-2Devpn-2Dsr-2Dp2mp-2D15-26url2-3Ddraft-2Dietf-2Dbess-2Dmvpn-2Devpn-2Dsr-2Dp2mp-2D17-26difftype-3D-2D-2Dhtml&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=XUBtIoxj9yqTSWyGUZQrPoeF8BDlbDNgUfhcpMBmoUNrWxVn8pt-YLjg42PQBkSI&s=w66XfjmX-7qvrtwp1osapW-gh_cb4ThJKMCyKrAlsk0&e=> > > > > > > Thanks in advance, > > > > Stephane > > _______________________________________________ > BESS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
