Subject: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 19 Jan 2021 15:28:42 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-teas-pce-native-ip-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have some significant issues with this document.  While none of these raise
to the level of a DISCUSS, they result in what I consider an incomplete
document, and I would want them to be addressed before publication --
specifically points 1-5.

(1) In general, the solution presented seems to assume that there will be an
independent E2E physical path per priority group/set of prefixes.  As the
number of groups/sets increases, the probability of finding node-disjoint
paths across a network diminishes significantly.   Link-disjoint paths can
also have issues.  I would like to see a discussion about the required
disjointness, and considerations for reusing links/nodes.

(2) §6: "Different BGP sessions are used mainly for the clarification of the
network prefixes, which can be differentiated via the different BGP nexthop."
I would be interested to understand why simply advertising a different
NEXT_HOP, while maintaining a single BGP session was discarded as part of the
solution.  As you mention in this sentence, the real differentiator is the
next hop -- if the advertised prefixes are always different then changing the
NEXT_HOP should also be a valid solution.  Given that this document defines
the architecture, and that the PCEP extensions will be based on it, it would
be ideal if alternate implementations (minimally different in this case) were not precluded.

   [Disclaimer: I haven't looked at I-D.ietf-pce-pcep-extension-native-ip in
   detail, but it looks like using a single BGP session is not supported. :-(]

(3) §7.1: "the on-path router needs only to keep the specific policy routes
for the BGP next-hop of the differentiate prefixes, not the specific routes to
the prefixes themselves. ... For example, if we want to differentiate 1000
prefixes from the normal traffic, CCDR needs only one explicit peer route in
every on-path router."  You may need to expand on this concept.  As far as I
can tell, the traffic is natively transported through the network, with a
destination IP address corresponding to one of the differentiated prefixes,
not the BGP next hop.  IOW, routes to the prefixes are still needed (as
explained in §3/§4), but the steering is achieved through the individual
"explicit peer routes".  Am I missing something?

(4) §7.2: "If one node on the optimal path fails, the priority traffic will
fall over to the best-effort forwarding path."  This statement is only
true/possible if the prefixes associated with the priority traffic are also
advertised through the BGP sessions associated with the best-effort path...or
if there is an alternate path to the corresponding next-hop.  Neither of these
options is explained in §3-5.

(5) This document provides a description of the architecture, and as mentioned
in §6: "Details...are out of scope of this draft and will be described in a
separate document [I-D.ietf-pce-pcep-extension-native-ip]."  However, the
description depends on the extensions/behavior from
I-D.ietf-pce-pcep-extension-native-ip in a couple of places:

§5:
   o  PCE sends the route information to the routers (R1,R2,R4,R7 in
      Figure 3) on the forwarding path via PCEP
      [I-D.ietf-pce-pcep-extension-native-ip], to build the path to the
      BGP next-hop of the advertised prefixes.

§7.3:
   Not every router within the network needs to support the PCEP
   extension defined in [I-D.ietf-pce-pcep-extension-native-ip]
   simultaneously.

These references make I-D.ietf-pce-pcep-extension-native-ip a normative
reference because it is necessary to implement the architecture.  Please write
these two paragraphs in a solution-neutral way (using
I-D.ietf-pce-pcep-extension-native-ip as an example is ok).

(6) §5: "PCE sends the prefixes information to the PCC for advertising
different prefixes via the specified BGP session."  Specifically, I think you
mean the RR.   s/PCC/RR

(7) §7.1: "Unlike the solution from BGP Flowspec[I-D.ietf-idr-rfc5575bis]..."
This is the only place where flowspec is mentioned.  Referencing a different
potential solution without a proper comparison (either in this document or
rfc8736, where it is not even mentioned) is out of place.  Please focus on the
considerations related to this solution, and not the potential downsides of
others.

(8) §8: "See [RFC7454] for BGP security consideration."  rfc7454 is not the
best reference for BGP-specific security considerations, please use
rfc4271/rfc4272 instead (or in addition).

(9) §8: Note that even if the PCE/PCC connection is secured, a rogue PCE may
still harm the network: it may set up more BGP sessions than required
(resulting in more control traffic, routes, etc.), it may direct the BGP
speakers to advertise the wrong routes (more, less, etc.), it may instantiate
incorrect explicit routes...  While this is not a new risk, it should me
mentioned in the context of the described architecture.

(10) [nits]

§2: s/Other terms are defined in this document/Other terms are used in this document

§3: s/in simple topology/in a simple topology

§3: s/topology is comprises/topology comprises

§4: s/for example, the iBGP within one AS/for example, using iBGP within one AS

5: s/as that described in/as described in

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 21 Jan 2021 12:03:31 +0800

Hi, Alvaro:

Thanks for your review and comments.
I have updated the draft accordingly and will upload the new version together with comments from other experts.

Thanks again for your efforts.
Some discussions are detail inline below.

Wish to get your consent.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, January 20, 2021 7:29 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Lou Berger <[email-masked]>
Subject: Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

I have some significant issues with this document.  While none of these raise to the level of a DISCUSS, they result in what I consider an incomplete document, and I would want them to be addressed before publication -- specifically points 1-5.

(1) In general, the solution presented seems to assume that there will be an independent E2E physical path per priority group/set of prefixes.  As the number of groups/sets increases, the probability of finding node-disjoint
paths across a network diminishes significantly.   Link-disjoint paths can
also have issues.  I would like to see a discussion about the required disjointness, and considerations for reusing links/nodes.
[WAJ] Yes, the group/set of prefixes may have some joint nodes/links on their optimal paths, but this will not lead to some issues, because PCE can ensure such path fulfill the QoS requirements of the application, based on the existing traffic of previous assigned group/set of prefixes.
That is to say, the E2E path will be calculated independently based on the network real situation, but the path(nodes/links) may/will be shared by these prefixes set.   

The last but one paragraph in section 3 has some discussion for such scenarios as:  "If, for example, there is bi-directional priority traffic from another address pair (for example prefix PF13/PF23), and the total volume of priority traffic does not exceed the capacity of the previously provisioned physical links, one need only advertise the newly added source/destination prefixes via the BGP session 2. The bi-directional traffic between PF13/PF23 will go through the same assigned dedicated physical links as the traffic between PF12/PF22." Is that enough, or add more descriptions in section 7.1?

(2) §6: "Different BGP sessions are used mainly for the clarification of the network prefixes, which can be differentiated via the different BGP nexthop."
I would be interested to understand why simply advertising a different NEXT_HOP, while maintaining a single BGP session was discarded as part of the solution.  As you mention in this sentence, the real differentiator is the next hop -- if the advertised prefixes are always different then changing the NEXT_HOP should also be a valid solution.  Given that this document defines the architecture, and that the PCEP extensions will be based on it, it would be ideal if alternate implementations (minimally different in this case) were not precluded.

   [Disclaimer: I haven't looked at I-D.ietf-pce-pcep-extension-native-ip in
   detail, but it looks like using a single BGP session is not supported. :-(]
[WAJ] We have also discussed the solution that using only one BGP session but change the NEXT_HOP offline, and actually there is one expired draft(https://datatracker.ietf.org/doc/html/draft-huang-teas-bgp-community-pce-00) to propose this. The reason that we does not follow this direction are the followings:
A: Using different sessions is more management and understandable.
B: The traffic will always be assured bidirectional, using BGP session can easily match the source/destination pair.

(3) §7.1: "the on-path router needs only to keep the specific policy routes for the BGP next-hop of the differentiate prefixes, not the specific routes to the prefixes themselves. ... For example, if we want to differentiate 1000 prefixes from the normal traffic, CCDR needs only one explicit peer route in every on-path router."  You may need to expand on this concept.  As far as I can tell, the traffic is natively transported through the network, with a destination IP address corresponding to one of the differentiated prefixes, not the BGP next hop.  IOW, routes to the prefixes are still needed (as explained in §3/§4), but the steering is achieved through the individual "explicit peer routes".  Am I missing something?
[WAJ] Yes, there is routes to prefixes in the RIB and FIB, but such routes are derived from the recursive process of "BGP nexthop of the prefixes(information from BGP)" and "the route the BGP nexhop" (information from IGP or "explicit peer routes" ) 

(4) §7.2: "If one node on the optimal path fails, the priority traffic will fall over to the best-effort forwarding path."  This statement is only true/possible if the prefixes associated with the priority traffic are also advertised through the BGP sessions associated with the best-effort path...or if there is an alternate path to the corresponding next-hop.  Neither of these options is explained in §3-5.
[WAJ] There is an alternate path to the corresponding next-hop. Actually, such path will be learned via IGP. The "explicit peer route" from PCE has higher preference than the IGP path.
If acceptable, I can add the above description into the section 7.2

(5) This document provides a description of the architecture, and as mentioned in §6: "Details...are out of scope of this draft and will be described in a separate document [I-D.ietf-pce-pcep-extension-native-ip]."  However, the description depends on the extensions/behavior from I-D.ietf-pce-pcep-extension-native-ip in a couple of places:

§5:
[WAJ] How about change the sentence to " PCE sends the route information to the routers (R1,R2,R4,R7 in Figure 3) on the forwarding path via PCEP, for example, as that described in "I-D.ietf-pce-pcep-extension-native-ip", to build the path to the BGP next-hop of the advertised prefixes"

§7.3:
   Not every router within the network needs to support the PCEP
   extension defined in [I-D.ietf-pce-pcep-extension-native-ip]
   simultaneously.
[WAJ] How about change the sentence to " Not every router within the network needs to support the PCEP extension, for example, as that defined in [I-D.ietf-pce-pcep-extension-native-ip] simultaneously."

These references make I-D.ietf-pce-pcep-extension-native-ip a normative reference because it is necessary to implement the architecture.  Please write these two paragraphs in a solution-neutral way (using I-D.ietf-pce-pcep-extension-native-ip as an example is ok).

(6) §5: "PCE sends the prefixes information to the PCC for advertising different prefixes via the specified BGP session."  Specifically, I think you
mean the RR.   s/PCC/RR
[WAJ] Here the PCE should send the prefixes information directly to the PCC, not RR.  RR is just used to by PCC, to advertised such prefixes to other BGP peer(also PCC) 

(7) §7.1: "Unlike the solution from BGP Flowspec[I-D.ietf-idr-rfc5575bis]..."
This is the only place where flowspec is mentioned.  Referencing a different potential solution without a proper comparison (either in this document or rfc8736, where it is not even mentioned) is out of place.  Please focus on the considerations related to this solution, and not the potential downsides of others.
[WAJ] OK, I will delete the first sentence of this paragraph. It will begin with "The on-path router needs only to keep ..."

(8) §8: "See [RFC7454] for BGP security consideration."  rfc7454 is not the best reference for BGP-specific security considerations, please use
rfc4271/rfc4272 instead (or in addition).
[WAJ] Changed to refer RFC4271 and RFC4272

(9) §8: Note that even if the PCE/PCC connection is secured, a rogue PCE may still harm the network: it may set up more BGP sessions than required (resulting in more control traffic, routes, etc.), it may direct the BGP speakers to advertise the wrong routes (more, less, etc.), it may instantiate incorrect explicit routes...  While this is not a new risk, it should me mentioned in the context of the described architecture.
[WAJ] OK, will add the above description in section 8, and add one more description at the end of the description as "The authentication of PCE on the PCCs should also be considered."

(10) [nits]

[WAJ] Done

[WAJ] Done

§3: s/topology is comprises/topology comprises
[WAJ] Has changed to "The topology is composed of four devices", as proposed also by Erik Kline

§4: s/for example, the iBGP within one AS/for example, using iBGP within one AS
[WAJ] Has changed sentences to "When the priority traffic spans a large scale network, such as that illustrated in Figure 2, the multiple BGP sessions cannot be established hop by hop within one AS. For such a scenario, we propose... ...". as also comments from Murray Kucherawy.

[WAJ] Done

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 21 Jan 2021 11:12:32 -0800

On January 20, 2021 at 11:03:42 PM, Aijun Wang wrote:

Aijun:

Hi!  How are you?

> I have updated the draft accordingly and will upload the new version
> together with comments from other experts.

That's fine.  I look forward to seeing the updated text -- in the
meantime, I have some replies below.

Thanks!

Alvaro.

...
> > (1) In general, the solution presented seems to assume that there will be
> > an independent E2E physical path per priority group/set of prefixes. As
> > the number of groups/sets increases, the probability of finding node-
> > disjoint paths across a network diminishes significantly. Link-disjoint
> > paths can also have issues. I would like to see a discussion about the
> > required disjointness, and considerations for reusing links/nodes.
>
> [WAJ] Yes, the group/set of prefixes may have some joint nodes/links on
> their optimal paths, but this will not lead to some issues, because PCE can
> ensure such path fulfill the QoS requirements of the application, based on
> the existing traffic of previous assigned group/set of prefixes.
> That is to say, the E2E path will be calculated independently based on the
> network real situation, but the path(nodes/links) may/will be shared by
> these prefixes set.
>
> The last but one paragraph in section 3 has some discussion for such
> scenarios as: "If, for example, there is bi-directional priority traffic
> from another address pair (for example prefix PF13/PF23), and the total
> volume of priority traffic does not exceed the capacity of the previously
> provisioned physical links, one need only advertise the newly added source/
> destination prefixes via the BGP session 2. The bi-directional traffic
> between PF13/PF23 will go through the same assigned dedicated physical links
> as the traffic between PF12/PF22." Is that enough, or add more descriptions
> in section 7.1?

I think more should be added because the text you quoted maintains the
physical separation, which is one of the things that prompted me to
make a comment.  Being clear about the possibility of sharing links,
paths, etc. is needed.

> > (2) §6: "Different BGP sessions are used mainly for the clarification of
> > the network prefixes, which can be differentiated via the different BGP
> > nexthop."
> > NEXT_HOP, while maintaining a single BGP session was discarded as part of
> > the solution. As you mention in this sentence, the real differentiator is
> > the next hop -- if the advertised prefixes are always different then
> > changing the NEXT_HOP should also be a valid solution. Given that this
> > document defines the architecture, and that the PCEP extensions will be
> > based on it, it would be ideal if alternate implementations (minimally
> > different in this case) were not precluded.
> >
> [WAJ] We have also discussed the solution that using only one BGP session
> but change the NEXT_HOP offline, and actually there is one expired draft
> (https://datatracker.ietf.org/doc/html/draft-huang-teas-bgp-community-pce-00)
> to propose this. The reason that we does not follow this direction are the
> followings:
>

I don't agree with this point -- I think it is always relative:
multiple sessions imply management overhead, and the operator has to
be aware of the different next-hops anyway.

> B: The traffic will always be assured bidirectional, using BGP session can
> easily match the source/destination pair.

Is that a requirement?  For many applications the QoS-type
requirements are not always bidirectional, along with the load, etc.

I'm not advocating for you to change the solution, but to not
eliminate the possibility of using a single session -- if that is what
the operator wants.

...
> > (4) §7.2: "If one node on the optimal path fails, the priority traffic
> > will fall over to the best-effort forwarding path." This statement is only
> > true/possible if the prefixes associated with the priority traffic are
> > also advertised through the BGP sessions associated with the best-effort
> > path...or if there is an alternate path to the corresponding next-hop.
> > Neither of these options is explained in §3-5.
>
> [WAJ] There is an alternate path to the corresponding next-hop. Actually,
> such path will be learned via IGP. The "explicit peer route" from PCE has
> higher preference than the IGP path.

Yes.  It would be ideal if this was explained *before* §7,
specifically where the architecture is explained.

> > (5) This document provides a description of the architecture, and as
> > mentioned in §6: "Details...are out of scope of this draft and will be
> > described in a separate document [I-D.ietf-pce-pcep-extension-native-ip]."
> > However, the description depends on the extensions/behavior from
> [WAJ] How about change the sentence to " PCE sends the route information to
> the routers (R1,R2,R4,R7 in Figure 3) on the forwarding path via PCEP, for
> example, as that described in "I-D.ietf-pce-pcep-extension-native-ip", to
> build the path to the BGP next-hop of the advertised prefixes"
>
> > §7.3:
> [WAJ] How about change the sentence to " Not every router within the network
> needs to support the PCEP extension, for example, as that defined in
> [I-D.ietf-pce-pcep-extension-native-ip] simultaneously."
>
> > reference because it is necessary to implement the architecture. Please
> > write these two paragraphs in a solution-neutral way (using

After reading your proposed text, I would prefer if
I-D.ietf-pce-pcep-extension-native-ip was not mentioned in either
sentence.

> > different prefixes via the specified BGP session." Specifically, I think
> > you mean the RR. s/PCC/RR
>
> [WAJ] Here the PCE should send the prefixes information directly to the PCC,
> not RR. RR is just used to by PCC, to advertised such prefixes to other BGP
> peer(also PCC)

I see.  This is the only place where PCC is used (as part of the
description), and given the number of routers in Figure 3, it is not
clear which router you're referring to.  I think the sentence still
needs clarity.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 22 Jan 2021 10:42:37 +0800

Hi, Alvaro:

Thanks for your comments, will upload the updated version in short time for experts' final review.

Thanks for your efforts.
Detail response inline below[WAJ]

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Friday, January 22, 2021 3:13 AM
To: Aijun Wang <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; Lou Berger <[email-masked]>; [email-masked]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

Aijun:

Hi!  How are you?

> together with comments from other experts.

That's fine.  I look forward to seeing the updated text -- in the meantime, I have some replies below.

Thanks!

Alvaro.

...
> > (1) In general, the solution presented seems to assume that there 
> > will be an independent E2E physical path per priority group/set of 
> > prefixes. As the number of groups/sets increases, the probability of 
> > finding node- disjoint paths across a network diminishes 
> > significantly. Link-disjoint paths can also have issues. I would 
> > like to see a discussion about the required disjointness, and considerations for reusing links/nodes.
>
> [WAJ] Yes, the group/set of prefixes may have some joint nodes/links 
> on their optimal paths, but this will not lead to some issues, because 
> PCE can ensure such path fulfill the QoS requirements of the 
> application, based on the existing traffic of previous assigned group/set of prefixes.
> That is to say, the E2E path will be calculated independently based on 
> the network real situation, but the path(nodes/links) may/will be 
> shared by these prefixes set.
>
> scenarios as: "If, for example, there is bi-directional priority 
> traffic from another address pair (for example prefix PF13/PF23), and 
> the total volume of priority traffic does not exceed the capacity of 
> the previously provisioned physical links, one need only advertise the 
> newly added source/ destination prefixes via the BGP session 2. The 
> bi-directional traffic between PF13/PF23 will go through the same 
> assigned dedicated physical links as the traffic between PF12/PF22." 
> Is that enough, or add more descriptions in section 7.1?

I think more should be added because the text you quoted maintains the physical separation, which is one of the things that prompted me to make a comment.  Being clear about the possibility of sharing links, paths, etc. is needed.
[WAJ] Add one sentence in bullet part of the section 5, as the followings:
"The priority traffic may share some links or nodes, if passing the shared links or nodes can meet the requirement of application. When the priority traffic prefixes were changed but the total volume of priority traffic does not exceed the physical capacity of the previous E2E path, the PCE needs only change the prefixed advertised via the edge routers (R1,R7 in Figure 3)."

> > (2) §6: "Different BGP sessions are used mainly for the 
> > clarification of the network prefixes, which can be differentiated 
> > via the different BGP nexthop."
> > I would be interested to understand why simply advertising a 
> > different NEXT_HOP, while maintaining a single BGP session was 
> > discarded as part of the solution. As you mention in this sentence, 
> > the real differentiator is the next hop -- if the advertised 
> > prefixes are always different then changing the NEXT_HOP should also 
> > be a valid solution. Given that this document defines the 
> > architecture, and that the PCEP extensions will be based on it, it 
> > would be ideal if alternate implementations (minimally different in this case) were not precluded.
> >
> > [Disclaimer: I haven't looked at 
> > I-D.ietf-pce-pcep-extension-native-ip in detail, but it looks like 
> > using a single BGP session is not supported. :-(]
>
> [WAJ] We have also discussed the solution that using only one BGP 
> session but change the NEXT_HOP offline, and actually there is one 
> expired draft
> (https://datatracker.ietf.org/doc/html/draft-huang-teas-bgp-community-
> pce-00) to propose this. The reason that we does not follow this 
> direction are the
> followings:
>

I don't agree with this point -- I think it is always relative:
multiple sessions imply management overhead, and the operator has to be aware of the different next-hops anyway.
[WAJ] There is another reason for using the BGP session, not directly the nexthop-------If we want to change the nexthop of some prefixes on the existing BGP session, we should first get existing underlay BGP session info, which required other interactive process with the PCC. Define one or more new BGP sessions on the devices, will be easily deployed and less conflicted with the existing BGP session.

> B: The traffic will always be assured bidirectional, using BGP session 
> can easily match the source/destination pair.

Is that a requirement?  For many applications the QoS-type requirements are not always bidirectional, along with the load, etc.

I'm not advocating for you to change the solution, but to not eliminate the possibility of using a single session -- if that is what the operator wants.
[WAJ] Will consider later, if there is some quick/easy method to get the underlay BGP session information.   

...
> > (4) §7.2: "If one node on the optimal path fails, the priority 
> > traffic will fall over to the best-effort forwarding path." This 
> > statement is only true/possible if the prefixes associated with the 
> > priority traffic are also advertised through the BGP sessions 
> > associated with the best-effort path...or if there is an alternate path to the corresponding next-hop.
> [WAJ] There is an alternate path to the corresponding next-hop. 
> Actually, such path will be learned via IGP. The "explicit peer route" 
> from PCE has higher preference than the IGP path.

Yes.  It would be ideal if this was explained *before* §7, specifically where the architecture is explained.
[WAJ] Add related description in the bullet part of section 5, as the following:

"PCE sends the route information to the routers (R1,R2,R4,R7 in Figure 3) on the forwarding path via PCEP, for example, as described in  , to build the path to the BGP next-hop of the advertised prefixes. The path to these BGP next-hop will also be learned via the IGP protocol, but the route from the PCEP has the higher preference. Such design can assure the IGP path to the BGP next-hop can be used to protect the path assigned by PCE."

> > mentioned in §6: "Details...are out of scope of this draft and will 
> > be described in a separate document [I-D.ietf-pce-pcep-extension-native-ip]."
> [WAJ] How about change the sentence to " PCE sends the route 
> information to the routers (R1,R2,R4,R7 in Figure 3) on the forwarding 
> path via PCEP, for example, as that described in 
> "I-D.ietf-pce-pcep-extension-native-ip", to build the path to the BGP next-hop of the advertised prefixes"
>
> > §7.3:
> [WAJ] How about change the sentence to " Not every router within the 
> network needs to support the PCEP extension, for example, as that 
> defined in [I-D.ietf-pce-pcep-extension-native-ip] simultaneously."
>
> > These references make I-D.ietf-pce-pcep-extension-native-ip a 
> > normative reference because it is necessary to implement the 
> > architecture. Please write these two paragraphs in a 
> > solution-neutral way (using I-D.ietf-pce-pcep-extension-native-ip as an example is ok).

After reading your proposed text, I would prefer if I-D.ietf-pce-pcep-extension-native-ip was not mentioned in either sentence.
[WAJ] OK, will follow the advices from Deborah in another mail.

> > (6) §5: "PCE sends the prefixes information to the PCC for 
> > advertising different prefixes via the specified BGP session." 
> > Specifically, I think you mean the RR. s/PCC/RR
>
> [WAJ] Here the PCE should send the prefixes information directly to 
> the PCC, not RR. RR is just used to by PCC, to advertised such 
> prefixes to other BGP peer(also PCC)

I see.  This is the only place where PCC is used (as part of the description), and given the number of routers in Figure 3, it is not clear which router you're referring to.  I think the sentence still needs clarity.
[WAJ] Change the sentence as " PCE sends the prefixes information to the PCC(edge routers that have established BGP sessions) for advertising different prefixes via the specified BGP session."