[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
Yes, indeed. That is clear Thanks! From: Rishabh Parekh Sent: Monday, January 19, 2026 17:18 To: Metz, Eduard Cc: [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. All CPs of an SR-P2MP policy result in SR-P2MP trees as specified in draft-ietf-pim-sr-p2mp-policy. There is no way to specify a CP with say MLDP or RSVP-TE P2MP etc. This implies SR-MPLS or SRv6 P2MP tunnel type for all CPs, and by extension for an SR-P2MP Policy. -Rishabh On Mon, Jan 19, 2026 at 2:07 AM mailto:[email protected]>> wrote: Agree that in practice the tunnel types will be same, given they are part of the same domain as you pointed out below. I assume it doesn't really break things if different tunnel types would be used in different CPs? If not, no additional clarification is needed I guess. Might even be a "feature" in transition from Sr-MPLS to SRv6? Though that type of use would probably require some additional description. cheers, Eduard From: Rishabh Parekh mailto:[email protected]>> Sent: Tuesday, January 13, 2026 21:21 To: Metz, Eduard mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[email protected]>> Subject: Re: [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 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 mailto:[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 mailto:[email protected]>> Sent: Tuesday, January 13, 2026 18:58 To: Metz, Eduard mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[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 mailto:[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) mailto:[email protected]>> Sent: Monday, January 12, 2026 10:57 To: [email protected]<mailto:[email protected]> mailto:[email protected]>> Cc: '[email protected]<mailto:[email protected]
[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
Eduard. All CPs of an SR-P2MP policy result in SR-P2MP trees as specified in draft-ietf-pim-sr-p2mp-policy. There is no way to specify a CP with say MLDP or RSVP-TE P2MP etc. This implies SR-MPLS or SRv6 P2MP tunnel type for all CPs, and by extension for an SR-P2MP Policy. -Rishabh On Mon, Jan 19, 2026 at 2:07 AM wrote: > Agree that in practice the tunnel types will be same, given they are part > of the same domain as you pointed out below. > > I assume it doesn't really break things if different tunnel types would be > used in different CPs? If not, no additional clarification is needed I > guess. > Might even be a "feature" in transition from Sr-MPLS to SRv6? Though that > type of use would probably require some additional description. > > cheers, > Eduard > > > -- > *From:* Rishabh Parekh > *Sent:* Tuesday, January 13, 2026 21:21 > *To:* Metz, Eduard > *Cc:* [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, > 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 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 > *Sent:* Tuesday, January 13, 2026 18:58 > *To:* Metz, Eduard > *Cc:* [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 > 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) > > *Sent:* Monday, January 12, 2026 10:57 > *To:* [email protected] > *Cc:* '[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 > > > > > > 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]
[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
Agree that in practice the tunnel types will be same, given they are part of the same domain as you pointed out below. I assume it doesn't really break things if different tunnel types would be used in different CPs? If not, no additional clarification is needed I guess. Might even be a "feature" in transition from Sr-MPLS to SRv6? Though that type of use would probably require some additional description. cheers, Eduard From: Rishabh Parekh Sent: Tuesday, January 13, 2026 21:21 To: Metz, Eduard Cc: [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, 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 mailto:[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 mailto:[email protected]>> Sent: Tuesday, January 13, 2026 18:58 To: Metz, Eduard mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[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 mailto:[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) mailto:[email protected]>> Sent: Monday, January 12, 2026 10:57 To: [email protected]<mailto:[email protected]> mailto:[email protected]>> Cc: '[email protected]<mailto:[email protected]>' mailto:[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 Thanks in advance, Stephane ___ BESS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ___ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
Rishabh: Thank you for your quick response. I am shepherd for draft-ietf-idr-sr-p2mp-policy. I want to make sure it was orthogonal. Cheerily, Sue From: Rishabh Parekh Sent: Wednesday, January 14, 2026 7:28 PM To: Susan Hares Cc: [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 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 mailto:[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 mailto:[email protected]>> Sent: Tuesday, January 13, 2026 3:22 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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 mailto:[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 mailto:[email protected]>> Sent: Tuesday, January 13, 2026 18:58 To: Metz, Eduard mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[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 mailto:[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) mailto:[email protected]>> Sent: Monday, J
[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
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 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 > *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 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 > *Sent:* Tuesday, January 13, 2026 18:58 > *To:* Metz, Eduard > *Cc:* [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 > 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) > > *Sent:* Monday, January 12, 2026 10:57 > *To:* [email protected] > *Cc:* '[email protected]' > *Subject:* [bess] WG review requested on > draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending
[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
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 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 NkdkJdXPPEBannerStart Be Careful With This Message From (Rishabh Parekh )<https://godaddy2.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f14b197f8b88b186bc7e9a9cb5b7b2e715c5c0e268e291694b841126094f4f8eebf6dfe9eeef20f1955ac06018f93fe1be6d1002eed0925c1b02eb830a6040fdb50103004800641b04ae0632c622cc6fb868dfee03a14448f503ca7c6a8d7cedf5a94ff03a8e7e4333ec428daea8b03a1d5606d95a5d2b5492ebedf229ac95883ce4dcea9acd3be9803d1b6f550cd61f1a19436990d1fd50728ea76abc6b681c01b343cc5118103e77073dea8be77a516fbee778041a2a33a881a8166367ada8a0d7ae9b1ab6d16eb946417d34ba1d7733e713a31a456dcb9> Learn More<https://godaddy2.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f14b197f8b88b186bc7e9a9cb5b7b2e715c5c0e268e291694b841126094f4f8eebf6dfe9eeef20f1955ac06018f93fe1be6d1002eed0925c1b02eb830a6040fdb50103004800641b04ae0632c622cc6fb868dfee03a14448f503ca7c6a8d7cedf5a94ff03a8e7e4333ec428daea8b03a1d5606d95a5d2b5492ebedf229ac95883ce4dcea9acd3be9803d1b6f550cd61f1a19436990d1fd50728ea76abc6b681c01b343cc5118103e77073dea8be77a516fbee778041a2a33a881a8166367ada8a0d7ae9b1ab6d16eb946417d34ba1d7733e713a31a456dcb9> Potential Impersonation The sender's identity could not be verified and someone may be impersonating the sender. Take caution when interacting with this message. NkdkJdXPPEBannerEnd 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 mailto:[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 mailto:[email protected]>> Sent: Tuesday, January 13, 2026 18:58 To: Metz, Eduard mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[email protected]>>; [email protected]<mailto:[email protected]> mailto:[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 mailto:[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
[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 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 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 > *Sent:* Tuesday, January 13, 2026 18:58 > *To:* Metz, Eduard > *Cc:* [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 > 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) > > *Sent:* Monday, January 12, 2026 10:57 > *To:* [email protected] > *Cc:* '[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 > > > > > > 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]
[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
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 Sent: Tuesday, January 13, 2026 18:58 To: Metz, Eduard Cc: [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 mailto:[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) mailto:[email protected]>> Sent: Monday, January 12, 2026 10:57 To: [email protected]<mailto:[email protected]> mailto:[email protected]>> Cc: '[email protected]<mailto:[email protected]>' mailto:[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 Thanks in advance, Stephane ___ BESS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ___ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
[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 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) > > *Sent:* Monday, January 12, 2026 10:57 > *To:* [email protected] > *Cc:* '[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 > > > > > > 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]
[bess] Re: WG review requested on draft-ietf-bess-mvpn-evpn-sr-p2mp-17, ending Monday 19th
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)" 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. 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? cheers, Eduard From: Stephane Litkowski (slitkows) Sent: Monday, January 12, 2026 10:57 To: [email protected] Cc: '[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 Thanks in advance, Stephane ___ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
