Subject: [Pce] Some commetns/responses for draft-chen-pce-pcc-ted

From: Huaimo Chen <[email-masked]>
Date: Tue, 7 Mar 2017 19:23:37 +0000

Hi Everyone,

    The following is a summary of comments received during/after IETF 97 with responses.

Comments 1. Link id. Even though there is no IGP, I think that the user may still configure the link ID, which can be uint32. It is the user's (or management system's) responsibility to make sure the number is not conflict with the other TE link IDs.
[Response]: We will update the draft accordingly.

Comments 2. Do you want to include SRLG also?
[Response]: Yes, we will add some text to include SRLG.

Comments 3. Can you change the title of the draft to Static PCEP Link State?
[Response]: We will consider this.

Best Regards,
Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 15 Mar 2017 17:54:49 +0000

Hi Everyone,

    The following is a summary of thoughts/discussions about Hierarchical PCE discovery during/after IETF 96.

    After an operator configure a PCE hierarchy, i.e., parent PCE and child PCE relations in a PCE system,  do we need to determine (or discover) the PCE hierarchy in the PCE protocol level?

    After an operator configures a parent PCE and a child PCE over a session, this parent-child PCE relationship needs to be determined (or discovered) in the PCE protocol level. This is similar to existing OSPF and BGP protocol regarding to OSPF adjacency and BGP peer determination (or discovery).

    After an expected adjacency between two OSPF routers is configured by an operator, the OSPF protocol (refer to RFC 2328, Section 7) will determine whether the adjacency is allowed based on the parameters configured, and forms the OSPF adjacency after the determination accordingly. If some parameters configured on two ends of the expected adjacency do not match, the OSPF protocol will detect the mismatch and will not form the expected adjacency.

    After an expected peer relation between two BGP routers is configured by an operator, the BGP protocol (refer to RFC 4271, Section 8) will determine whether the expected peer relationship is allowed based on the parameters configured, and forms the BGP peer relation after the determination accordingly.

    Only after determining that the parent-child PCE relation can be formed and has been formed, a child PCE can send its parent PCE the information about the child PCE.  This is also similar to existing OSPF and BGP protocol regarding to OSPF link state information advertisement over an OSPF adjacency and BGP route distribution over a BGP peer session.

    Why not use auto-discovery for Hierarchical PCE?

    There are security concerns in some cases.

    For two PCEs belonging to two different service providers, there are security concerns for automatically discovering the parent-child PCE relation between them without any configuration.

    For PCEs belonging to the same service providers, it is possible for some auto-discovery to discover the parent-child PCE relations among these PCEs with minimum configurations. But some rules for determining/selecting which PCEs will be parent PCEs and which PCEs are child PCEs need to be defined first.

    Why use term "discovery"? Determination seems better.

    The hierarchy of PCEs in a hierarchical system is configured first, and then is determined or confirmed in the PCE protocol level. Using term "discovery" of Hierarchical PCE seems not fit well. Term "determination" seems better.

Best Regards,
Huaimo