(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 <[email protected]>
Sent: Friday, June 27, 2025 6:55 PM
To: Stephane Litkowski (slitkows) <[email protected]>
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] <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 <[email protected]
<mailto:[email protected]> > wrote:
Hi Dhruv,
May you have some opinion ?
Thanks,
Stephane
From: [email protected] <mailto:[email protected]>
<[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]>
<[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 it uses PCEP, or BGP for instance as a
protocol to program.
>From an architecture point of view, I wanted to check if the terms PCC/PCE are
>tied to PCEP protocol only or not within the overall PCE architecture which
>has been defined a long time back at IETF.
Pls let us know if it’s valid or not.
Thanks,
Stephane
From: Rishabh Parekh <mailto:[email protected]> <[email protected]>
Sent: Friday, June 27, 2025 6:55 PM
Stephane,
Inline @ [RP]
On Wed, Jun 18, 2025 at 2:01 AM Stephane Litkowski (slitkows)
<[email protected] <mailto:[email protected]> >
wrote:
Hi authors,
Please find below my chair/shepherd’s review of
draft-ietf-bess-mvpn-evpn-sr-p2mp.
Introduction:
1. “A SR P2MP tree is defined by a SR P2MP Policy and instantiated via a
PCE”
1. 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:
1. “A Replication segment of a SR P2MP tree can be instantiated…”
1. 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:
1. I would enhance the tunnel-type description with a list, something like
“ * Tunnel Type:
1. 0x0c for SR-MPLS P2MP tree
2. 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]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
--- End Message ---
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
