[bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

2025-07-07 Thread Stephane Litkowski (slitkows)
Thanks, I’ll move the document forward.

Stephane


From: Rishabh Parekh 
Sent: Monday, July 7, 2025 9:21 PM
To: Stephane Litkowski (slitkows) 
Cc: [email protected]; [email protected]; 
[email protected]; [email protected]
Subject: Re: [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

Stephane,
PIM and BESS WG drafts have been updated with suggested change from "PCE" to 
"controller".

-Rishabh

On Mon, Jul 7, 2025 at 10:42 AM Rishabh Parekh 
mailto:[email protected]>> wrote:
Stephane,
RFC 9524, the base for both the PIM and BESS WG drafts, only uses the term 
"PCE" in the text, but PCE is just used as an example of a control plane to 
establish Replication segments. Let me see how I can incorporate the 
"controller" replacement in PIM and BESS drafts.

-Rishabh

On Mon, Jul 7, 2025 at 8:33 AM Stephane Litkowski (slitkows) 
mailto:[email protected]>> wrote:
Thanks Rishabh.


From: Rishabh Parekh mailto:[email protected]>>
Sent: Monday, July 7, 2025 4:48 PM
To: [email protected]<mailto:[email protected]>
Cc: Stephane Litkowski (slitkows) 
mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
Subject: Re: [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

Stephane,
I prefer the second option i.e. "Controller/PCE". However it maybe cumbersome 
to read this frequently in the documents, so I think we should use "Controller" 
and describe PCE as an example. I will edit both of the drafts for this change.

Regards,
Rishabh

On Mon, Jul 7, 2025 at 1:33 AM 
mailto:[email protected]>> wrote:
(Adding PIM chairs so they are informed)

Hi Rishabh,

I discussed offline with PCE chairs, and they agree that it’s better to use 
“Controller” or “Controller/PCE” as PCE notion is tied now to PCEP protocol.
Likely the PIM draft needs to be updated too.

Brgds,

Stephane



From: Rishabh Parekh mailto:[email protected]>>
Sent: Friday, June 27, 2025 6:55 PM
To: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Cc: 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>
Subject: [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

Stephane,

Inline @ [RP]

On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows) 
mailto:[email protected]>> wrote:
Hi authors,

Please find below my chair/shepherd’s review of 
draft-ietf-bess-mvpn-evpn-sr-p2mp.


Introduction:


  *   “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via a PCE”

 *   I would use the name controller instead of PCE. PCE is really tied to 
PCEP protocol IMO. If we agree, then you should change it across the doc. I 
appears in other sections too.

[RP] This draft is based on the PIM WG SR P2MP policy draft 
https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ which describes 
use of PCE to compute P2MP trees. Section 4.4 of that draft clarifies that 
various protocols, such as PCEP, BGP etc. can be used between PCE and PCC. IMO, 
it is appropriate to use PCE in this draft.

Section 2:

  *   “A Replication segment of a SR P2MP tree can be instantiated…”

 *   Shoudln’t you provide informational refs here ?

[RP] The preceding text provides references for both Replication segments (RFC 
9524) SR P2MP tree (draft-ietf-pim-sr-p2mp-policy). Isn't that sufficient.

Section 3:

  *   I would enhance the tunnel-type description with a list, something like

“   *   Tunnel Type:
• 0x0c for SR-MPLS P2MP tree
• TBD for SRv6 P2MP Tree
“

Section 3.1.2
s/”Domain- wide”/”Domain-wide” (remove space)


Section 4.1.1

Use an XML reference for RFC6514 Section 9.1.1 instead of hardcoding in text. 
(same in 4.1.2, 4.2.1, 4.2.2, 4.3.2…).

[RP] These are "external" (eref as described in 
https://datatracker.ietf.org/doc/html/rfc7991#section-2.24)  references, which 
are rendered appropriately as URI links in HTML format and with URI text in TXT 
format.

When you refer to “condition (c)”, it’s not clear, where it’s defined.

[RP] Added reference to Section 9.1.1 RFC 6514



Section 10

Please fix last name of Luc Andre (there are two “t” instead of t, it should be 
Burdet).

[RP] Fixed.



Thanks,

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: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

2025-07-07 Thread Rishabh Parekh
Stephane,
PIM and BESS WG drafts have been updated with suggested change from "PCE"
to "controller".

-Rishabh

On Mon, Jul 7, 2025 at 10:42 AM Rishabh Parekh  wrote:

> Stephane,
> RFC 9524, the base for both the PIM and BESS WG drafts, only uses the term
> "PCE" in the text, but PCE is just used as an example of a control plane to
> establish Replication segments. Let me see how I can incorporate the
> "controller" replacement in PIM and BESS drafts.
>
> -Rishabh
>
> On Mon, Jul 7, 2025 at 8:33 AM Stephane Litkowski (slitkows) <
> [email protected]> wrote:
>
>> Thanks Rishabh.
>>
>>
>>
>>
>>
>> *From:* Rishabh Parekh 
>> *Sent:* Monday, July 7, 2025 4:48 PM
>> *To:* [email protected]
>> *Cc:* Stephane Litkowski (slitkows) ;
>> [email protected]; [email protected];
>> [email protected]
>> *Subject:* Re: [bess] Re: Chair review of
>> draft-ietf-bess-mvpn-evpn-sr-p2mp
>>
>>
>>
>> Stephane,
>>
>> I prefer the second option i.e. "Controller/PCE". However it maybe
>> cumbersome to read this frequently in the documents, so I think we should
>> use "Controller" and describe PCE as an example. I will edit both of the
>> drafts for this change.
>>
>>
>>
>> Regards,
>>
>> Rishabh
>>
>>
>>
>> On Mon, Jul 7, 2025 at 1:33 AM  wrote:
>>
>> (Adding PIM chairs so they are informed)
>>
>>
>>
>> Hi Rishabh,
>>
>>
>>
>> I discussed offline with PCE chairs, and they agree that it’s better to
>> use “Controller” or “Controller/PCE” as PCE notion is tied now to PCEP
>> protocol.
>>
>> Likely the PIM draft needs to be updated too.
>>
>>
>>
>> Brgds,
>>
>>
>>
>> Stephane
>>
>>
>>
>>
>>
>>
>>
>> *From:* Rishabh Parekh 
>> *Sent:* Friday, June 27, 2025 6:55 PM
>> *To:* Stephane Litkowski (slitkows) 
>> *Cc:* [email protected]; [email protected]
>> *Subject:* [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp
>>
>>
>>
>> Stephane,
>>
>>
>>
>> Inline @ [RP]
>>
>>
>>
>> On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows) > [email protected]> wrote:
>>
>> Hi authors,
>>
>>
>>
>> Please find below my chair/shepherd’s review of
>> draft-ietf-bess-mvpn-evpn-sr-p2mp.
>>
>>
>>
>>
>>
>> Introduction:
>>
>>
>>
>>- “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via
>>a PCE”
>>
>>
>>- I would use the name controller instead of PCE. PCE is really tied
>>   to PCEP protocol IMO. If we agree, then you should change it across the
>>   doc. I appears in other sections too.
>>
>>
>>
>> [RP] This draft is based on the PIM WG SR P2MP policy draft
>> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ which
>> describes use of PCE to compute P2MP trees. Section 4.4 of that draft
>> clarifies that various protocols, such as PCEP, BGP etc. can be used
>> between PCE and PCC. IMO, it is appropriate to use PCE in this draft.
>>
>>
>>
>> Section 2:
>>
>>- “A Replication segment of a SR P2MP tree can be instantiated…”
>>
>>
>>- Shoudln’t you provide informational refs here ?
>>
>>
>>
>> [RP] The preceding text provides references for both Replication segments
>> (RFC 9524) SR P2MP tree (draft-ietf-pim-sr-p2mp-policy). Isn't that
>> sufficient.
>>
>>
>>
>> Section 3:
>>
>>- I would enhance the tunnel-type description with a list, something
>>like
>>
>>
>>
>> “   *   Tunnel Type:
>>
>> · 0x0c for SR-MPLS P2MP tree
>>
>> · TBD for SRv6 P2MP Tree
>>
>> “
>>
>>
>>
>> Section 3.1.2
>>
>> s/”Domain- wide”/”Domain-wide” (remove space)
>>
>>
>>
>>
>>
>> Section 4.1.1
>>
>>
>>
>> Use an XML reference for RFC6514 Section 9.1.1 instead of hardcoding in
>> text. (same in 4.1.2, 4.2.1, 4.2.2, 4.3.2…).
>>
>>
>>
>> [RP] These are "external" (eref as described in
>> https://datatracker.ietf.org/doc/html/rfc7991#section-2.24)  references,
>> which are rendered appropriately as URI links in HTML format and with URI
>> text in TXT format.
>>
>>
>>
>> When you refer to “condition (c)”, it’s not clear, where it’s defined.
>>
>>
>>
>> [RP] Added reference to Section 9.1.1 RFC 6514
>>
>>
>>
>>
>>
>>
>>
>> Section 10
>>
>>
>>
>> Please fix last name of Luc Andre (there are two “t” instead of t, it
>> should be Burdet).
>>
>>
>>
>> [RP] Fixed.
>>
>>
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>>
>> 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: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

2025-07-07 Thread Rishabh Parekh
Stephane,
RFC 9524, the base for both the PIM and BESS WG drafts, only uses the term
"PCE" in the text, but PCE is just used as an example of a control plane to
establish Replication segments. Let me see how I can incorporate the
"controller" replacement in PIM and BESS drafts.

-Rishabh

On Mon, Jul 7, 2025 at 8:33 AM Stephane Litkowski (slitkows) <
[email protected]> wrote:

> Thanks Rishabh.
>
>
>
>
>
> *From:* Rishabh Parekh 
> *Sent:* Monday, July 7, 2025 4:48 PM
> *To:* [email protected]
> *Cc:* Stephane Litkowski (slitkows) ;
> [email protected]; [email protected];
> [email protected]
> *Subject:* Re: [bess] Re: Chair review of
> draft-ietf-bess-mvpn-evpn-sr-p2mp
>
>
>
> Stephane,
>
> I prefer the second option i.e. "Controller/PCE". However it maybe
> cumbersome to read this frequently in the documents, so I think we should
> use "Controller" and describe PCE as an example. I will edit both of the
> drafts for this change.
>
>
>
> Regards,
>
> Rishabh
>
>
>
> On Mon, Jul 7, 2025 at 1:33 AM  wrote:
>
> (Adding PIM chairs so they are informed)
>
>
>
> Hi Rishabh,
>
>
>
> I discussed offline with PCE chairs, and they agree that it’s better to
> use “Controller” or “Controller/PCE” as PCE notion is tied now to PCEP
> protocol.
>
> Likely the PIM draft needs to be updated too.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
>
>
> *From:* Rishabh Parekh 
> *Sent:* Friday, June 27, 2025 6:55 PM
> *To:* Stephane Litkowski (slitkows) 
> *Cc:* [email protected]; [email protected]
> *Subject:* [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp
>
>
>
> Stephane,
>
>
>
> Inline @ [RP]
>
>
>
> On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows)  [email protected]> wrote:
>
> Hi authors,
>
>
>
> Please find below my chair/shepherd’s review of
> draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>
>
>
>
> Introduction:
>
>
>
>- “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via
>a PCE”
>
>
>- I would use the name controller instead of PCE. PCE is really tied
>   to PCEP protocol IMO. If we agree, then you should change it across the
>   doc. I appears in other sections too.
>
>
>
> [RP] This draft is based on the PIM WG SR P2MP policy draft
> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ which
> describes use of PCE to compute P2MP trees. Section 4.4 of that draft
> clarifies that various protocols, such as PCEP, BGP etc. can be used
> between PCE and PCC. IMO, it is appropriate to use PCE in this draft.
>
>
>
> Section 2:
>
>- “A Replication segment of a SR P2MP tree can be instantiated…”
>
>
>- Shoudln’t you provide informational refs here ?
>
>
>
> [RP] The preceding text provides references for both Replication segments
> (RFC 9524) SR P2MP tree (draft-ietf-pim-sr-p2mp-policy). Isn't that
> sufficient.
>
>
>
> Section 3:
>
>- I would enhance the tunnel-type description with a list, something
>like
>
>
>
> “   *   Tunnel Type:
>
> · 0x0c for SR-MPLS P2MP tree
>
> · TBD for SRv6 P2MP Tree
>
> “
>
>
>
> Section 3.1.2
>
> s/”Domain- wide”/”Domain-wide” (remove space)
>
>
>
>
>
> Section 4.1.1
>
>
>
> Use an XML reference for RFC6514 Section 9.1.1 instead of hardcoding in
> text. (same in 4.1.2, 4.2.1, 4.2.2, 4.3.2…).
>
>
>
> [RP] These are "external" (eref as described in
> https://datatracker.ietf.org/doc/html/rfc7991#section-2.24)  references,
> which are rendered appropriately as URI links in HTML format and with URI
> text in TXT format.
>
>
>
> When you refer to “condition (c)”, it’s not clear, where it’s defined.
>
>
>
> [RP] Added reference to Section 9.1.1 RFC 6514
>
>
>
>
>
>
>
> Section 10
>
>
>
> Please fix last name of Luc Andre (there are two “t” instead of t, it
> should be Burdet).
>
>
>
> [RP] Fixed.
>
>
>
>
>
>
>
> Thanks,
>
>
>
> 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: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

2025-07-07 Thread Stephane Litkowski (slitkows)
Thanks Rishabh.


From: Rishabh Parekh 
Sent: Monday, July 7, 2025 4:48 PM
To: [email protected]
Cc: Stephane Litkowski (slitkows) ; 
[email protected]; [email protected]; [email protected]
Subject: Re: [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

Stephane,
I prefer the second option i.e. "Controller/PCE". However it maybe cumbersome 
to read this frequently in the documents, so I think we should use "Controller" 
and describe PCE as an example. I will edit both of the drafts for this change.

Regards,
Rishabh

On Mon, Jul 7, 2025 at 1:33 AM 
mailto:[email protected]>> wrote:
(Adding PIM chairs so they are informed)

Hi Rishabh,

I discussed offline with PCE chairs, and they agree that it’s better to use 
“Controller” or “Controller/PCE” as PCE notion is tied now to PCEP protocol.
Likely the PIM draft needs to be updated too.

Brgds,

Stephane



From: Rishabh Parekh mailto:[email protected]>>
Sent: Friday, June 27, 2025 6:55 PM
To: Stephane Litkowski (slitkows) 
mailto:[email protected]>>
Cc: 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>
Subject: [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

Stephane,

Inline @ [RP]

On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows) 
mailto:[email protected]>> wrote:
Hi authors,

Please find below my chair/shepherd’s review of 
draft-ietf-bess-mvpn-evpn-sr-p2mp.


Introduction:


  *   “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via a PCE”

 *   I would use the name controller instead of PCE. PCE is really tied to 
PCEP protocol IMO. If we agree, then you should change it across the doc. I 
appears in other sections too.

[RP] This draft is based on the PIM WG SR P2MP policy draft 
https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ which describes 
use of PCE to compute P2MP trees. Section 4.4 of that draft clarifies that 
various protocols, such as PCEP, BGP etc. can be used between PCE and PCC. IMO, 
it is appropriate to use PCE in this draft.

Section 2:

  *   “A Replication segment of a SR P2MP tree can be instantiated…”

 *   Shoudln’t you provide informational refs here ?

[RP] The preceding text provides references for both Replication segments (RFC 
9524) SR P2MP tree (draft-ietf-pim-sr-p2mp-policy). Isn't that sufficient.

Section 3:

  *   I would enhance the tunnel-type description with a list, something like

“   *   Tunnel Type:
• 0x0c for SR-MPLS P2MP tree
• TBD for SRv6 P2MP Tree
“

Section 3.1.2
s/”Domain- wide”/”Domain-wide” (remove space)


Section 4.1.1

Use an XML reference for RFC6514 Section 9.1.1 instead of hardcoding in text. 
(same in 4.1.2, 4.2.1, 4.2.2, 4.3.2…).

[RP] These are "external" (eref as described in 
https://datatracker.ietf.org/doc/html/rfc7991#section-2.24)  references, which 
are rendered appropriately as URI links in HTML format and with URI text in TXT 
format.

When you refer to “condition (c)”, it’s not clear, where it’s defined.

[RP] Added reference to Section 9.1.1 RFC 6514



Section 10

Please fix last name of Luc Andre (there are two “t” instead of t, it should be 
Burdet).

[RP] Fixed.



Thanks,

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: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

2025-07-07 Thread Rishabh Parekh
Stephane,
I prefer the second option i.e. "Controller/PCE". However it maybe
cumbersome to read this frequently in the documents, so I think we should
use "Controller" and describe PCE as an example. I will edit both of the
drafts for this change.

Regards,
Rishabh

On Mon, Jul 7, 2025 at 1:33 AM  wrote:

> (Adding PIM chairs so they are informed)
>
>
>
> Hi Rishabh,
>
>
>
> I discussed offline with PCE chairs, and they agree that it’s better to
> use “Controller” or “Controller/PCE” as PCE notion is tied now to PCEP
> protocol.
>
> Likely the PIM draft needs to be updated too.
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
>
>
> *From:* Rishabh Parekh 
> *Sent:* Friday, June 27, 2025 6:55 PM
> *To:* Stephane Litkowski (slitkows) 
> *Cc:* [email protected]; [email protected]
> *Subject:* [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp
>
>
>
> Stephane,
>
>
>
> Inline @ [RP]
>
>
>
> On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows)  [email protected]> wrote:
>
> Hi authors,
>
>
>
> Please find below my chair/shepherd’s review of
> draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>
>
>
>
> Introduction:
>
>
>
>- “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via
>a PCE”
>
>
>- I would use the name controller instead of PCE. PCE is really tied
>   to PCEP protocol IMO. If we agree, then you should change it across the
>   doc. I appears in other sections too.
>
>
>
> [RP] This draft is based on the PIM WG SR P2MP policy draft
> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ which
> describes use of PCE to compute P2MP trees. Section 4.4 of that draft
> clarifies that various protocols, such as PCEP, BGP etc. can be used
> between PCE and PCC. IMO, it is appropriate to use PCE in this draft.
>
>
>
> Section 2:
>
>- “A Replication segment of a SR P2MP tree can be instantiated…”
>
>
>- Shoudln’t you provide informational refs here ?
>
>
>
> [RP] The preceding text provides references for both Replication segments
> (RFC 9524) SR P2MP tree (draft-ietf-pim-sr-p2mp-policy). Isn't that
> sufficient.
>
>
>
> Section 3:
>
>- I would enhance the tunnel-type description with a list, something
>like
>
>
>
> “   *   Tunnel Type:
>
> · 0x0c for SR-MPLS P2MP tree
>
> · TBD for SRv6 P2MP Tree
>
> “
>
>
>
> Section 3.1.2
>
> s/”Domain- wide”/”Domain-wide” (remove space)
>
>
>
>
>
> Section 4.1.1
>
>
>
> Use an XML reference for RFC6514 Section 9.1.1 instead of hardcoding in
> text. (same in 4.1.2, 4.2.1, 4.2.2, 4.3.2…).
>
>
>
> [RP] These are "external" (eref as described in
> https://datatracker.ietf.org/doc/html/rfc7991#section-2.24)  references,
> which are rendered appropriately as URI links in HTML format and with URI
> text in TXT format.
>
>
>
> When you refer to “condition (c)”, it’s not clear, where it’s defined.
>
>
>
> [RP] Added reference to Section 9.1.1 RFC 6514
>
>
>
>
>
>
>
> Section 10
>
>
>
> Please fix last name of Luc Andre (there are two “t” instead of t, it
> should be Burdet).
>
>
>
> [RP] Fixed.
>
>
>
>
>
>
>
> Thanks,
>
>
>
> 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: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

2025-07-07 Thread slitkows.ietf
(Adding PIM chairs so they are informed)

 

Hi Rishabh,

 

I discussed offline with PCE chairs, and they agree that it’s better to use 
“Controller” or “Controller/PCE” as PCE notion is tied now to PCEP protocol.

Likely the PIM draft needs to be updated too.

 

Brgds,

 

Stephane

 

 

 

From: Rishabh Parekh  
Sent: Friday, June 27, 2025 6:55 PM
To: Stephane Litkowski (slitkows) 
Cc: [email protected]; [email protected]
Subject: [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

 

Stephane,

 

Inline @ [RP]

 

On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows) 
mailto:[email protected]> > 
wrote:

Hi authors,

 

Please find below my chair/shepherd’s review of 
draft-ietf-bess-mvpn-evpn-sr-p2mp.

 

 

Introduction:

 

*   “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via a 
PCE”

*   I would use the name controller instead of PCE. PCE is really tied to 
PCEP protocol IMO. If we agree, then you should change it across the doc. I 
appears in other sections too.

 

[RP] This draft is based on the PIM WG SR P2MP policy draft 
https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ which describes 
use of PCE to compute P2MP trees. Section 4.4 of that draft clarifies that 
various protocols, such as PCEP, BGP etc. can be used between PCE and PCC. IMO, 
it is appropriate to use PCE in this draft. 

 

Section 2:

*   “A Replication segment of a SR P2MP tree can be instantiated…”

*   Shoudln’t you provide informational refs here ?

 

[RP] The preceding text provides references for both Replication segments (RFC 
9524) SR P2MP tree (draft-ietf-pim-sr-p2mp-policy). Isn't that sufficient.

 

Section 3:

*   I would enhance the tunnel-type description with a list, something like

 

“   *   Tunnel Type:

* 0x0c for SR-MPLS P2MP tree

* TBD for SRv6 P2MP Tree

“

 

Section 3.1.2

s/”Domain- wide”/”Domain-wide” (remove space)

 

 

Section 4.1.1

 

Use an XML reference for RFC6514 Section 9.1.1 instead of hardcoding in text. 
(same in 4.1.2, 4.2.1, 4.2.2, 4.3.2…).

 

[RP] These are "external" (eref as described in 
https://datatracker.ietf.org/doc/html/rfc7991#section-2.24)  references, which 
are rendered appropriately as URI links in HTML format and with URI text in TXT 
format.

 

When you refer to “condition (c)”, it’s not clear, where it’s defined.

 

[RP] Added reference to Section 9.1.1 RFC 6514 

 

 

 

Section 10

 

Please fix last name of Luc Andre (there are two “t” instead of t, it should be 
Burdet).

 

[RP] Fixed. 

 

 

 

Thanks,

 

Stephane

 

___
BESS mailing list -- [email protected] <mailto:[email protected]> 
To unsubscribe send an email to [email protected] 
<mailto:[email protected]> 

--- Begin Message ---
Hi Stephane, 

Apologies for the delay in reply! I agree with Julien. If I was in authors 
shoes I would use the term Controller or maybe or PCE/Controller. 

Thanks! 
Dhruv

On Fri, Jul 4, 2025 at 9:02 PM mailto:[email protected]> > wrote:


Hi Dhruv,

 

May you have some opinion ?

 

Thanks,

 

Stephane

 

 

From: [email protected] <mailto:[email protected]>  
mailto:[email protected]> > 
Sent: Monday, June 30, 2025 3:48 PM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: Re: FW: [bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

 

Hi Stéphane,

Thanks for raising this question.

1. For PCE, I would consider 2 definition variations:
  a- The history one, coming from the PCE architecture (RFC  4655) which was a 
prerequisite to PCEP specification, pointing to the path computation function;
  b- The server-side of a PCEP session, which nowadays supports more feature 
than path request/response (e.g., push states).
In the IETF context, 1.b is now the typical meaning. The usages falling under 
1.a are mostly used outside the IETF and sometimes they don't even expand the E 
as "Element" (Opendaylight says "Engine"...).

2. For PCC, it's similar:
  a- Originally, it was a path requester entity;
  b- It now has expanded to point to the host at the end of the a PCEP session 
receiving operations orders/states to install.
I have never seen the use of the PCC acronym out of the PCEP context.

It seems clear to me that as soon as you remove PCEP, only definitions X.a 
could apply (though uncommon). As a result, I would preclude the use of PCE, 
and even more of PCC, if there is no PCEP communication involved.

My 2 cents (Dhruv may have more ;-) ),

Julien



On 30/06/2025 15:20:18  <mailto:[email protected]> 
, wrote:

 

Hi folks,

 

I’m reaching out to you to get some clarification.

In our WG draft mentioned in the title, authors use vocabulary of PCC/PCE to 
refer to any “controller” whatever i

[bess] Re: Chair review of draft-ietf-bess-mvpn-evpn-sr-p2mp

2025-06-27 Thread Rishabh Parekh
Stephane,

Inline @ [RP]

On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows)  wrote:

> Hi authors,
>
>
>
> Please find below my chair/shepherd’s review of
> draft-ietf-bess-mvpn-evpn-sr-p2mp.
>
>
>
>
>
> Introduction:
>
>
>
>- “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via
>a PCE”
>   - I would use the name controller instead of PCE. PCE is really
>   tied to PCEP protocol IMO. If we agree, then you should change it across
>   the doc. I appears in other sections too.
>
>

[RP] This draft is based on the PIM WG SR P2MP policy draft
https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ which
describes use of PCE to compute P2MP trees. Section 4.4 of that draft
clarifies that various protocols, such as PCEP, BGP etc. can be used
between PCE and PCC. IMO, it is appropriate to use PCE in this draft.


> Section 2:
>
>- “A Replication segment of a SR P2MP tree can be instantiated…”
>   - Shoudln’t you provide informational refs here ?
>
>
>
[RP] The preceding text provides references for both Replication segments
(RFC 9524) SR P2MP tree (draft-ietf-pim-sr-p2mp-policy). Isn't that
sufficient.


> Section 3:
>
>- I would enhance the tunnel-type description with a list, something
>like
>
>
>
> “   *   Tunnel Type:
>
>- 0x0c for SR-MPLS P2MP tree
>- TBD for SRv6 P2MP Tree
>
> “
>
>
>
> Section 3.1.2
>
> s/”Domain- wide”/”Domain-wide” (remove space)
>
>
>
>
>
> Section 4.1.1
>
>
>
> Use an XML reference for RFC6514 Section 9.1.1 instead of hardcoding in
> text. (same in 4.1.2, 4.2.1, 4.2.2, 4.3.2…).
>

[RP] These are "external" (eref as described in
https://datatracker.ietf.org/doc/html/rfc7991#section-2.24)  references,
which are rendered appropriately as URI links in HTML format and with URI
text in TXT format.

>
>
> When you refer to “condition (c)”, it’s not clear, where it’s defined.
>

[RP] Added reference to Section 9.1.1 RFC 6514

>
>
>
>
>
>
> Section 10
>
>
>
> Please fix last name of Luc Andre (there are two “t” instead of t, it
> should be Burdet).
>

[RP] Fixed.

>
>
>
>
>
>
> Thanks,
>
>
>
> 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]