Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction

From: "Aijun Wang" <[email-masked]>
Date: Tue, 27 Jul 2021 15:19:08 +0800

Hi, Susan and all:

Update one hyperlink on the contents, please refer to this mail for comments
responses.

From: [email-masked] <[email-masked]> On Behalf Of Aijun Wang
Sent: Tuesday, July 27, 2021 12:04 PM
To: 'Susan Hares' <[email-masked]>; [email-masked]
Cc: 'idr-chairs' <[email-masked]>; 'pce-chairs' <[email-masked]>
Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt

Hi, Susan:

Thanks for your reviews, let me first address your current questions and
wait for the further discussions on the overall solution.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <pce-bounces@ietf.
org <mailto:[email-masked]> > On Behalf Of Susan Hares
Sent: Tuesday, July 27, 2021 7:19 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: 'idr-chairs' <[email-masked] <mailto:[email-masked]> >;
'pce-chairs' <[email-masked] <mailto:[email-masked]> >
Subject: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt

Greetings: 

Thank you for your work on draft-ietf-pce-pcep-extension-native-ip-14.txt.

This comment should be consider feedback from me as a WG member of IDR and
PCE.  I have posted this information also on the  

This draft takes a step toward auto-configuration of BGP peers.  IDR has
created a set of requirements for BGP auto-configuration for Data Centers
at: 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/

[WAJ] Yes, I have also reviewed this document and attended some discussions
on it. The autoconf document tries to build the BGP from scratch without 3rd
party(for example, PCE) assistance. It considers mainly the direct connected
BGP peer setup process automatically and does not involve the prefix
advertisement and explicit route setup. 

I think the aim of these two drafts is different but we can refer to some
designed considerations from it.

I’ve put a copy of these comments at: 

https://trac.ietf.org/trac/idr/wiki/pce-pcep-extension-native-ip%20Hares%20c
omments

Cheers, Sue 

Comments on draft-ietf-pce-pcep-extension-native-ip-14

=================================================

Overview of errors 

1) section 6 description of BGP routers needs clarification 

(sections 6.1, 6.2, and 6.3) for RR and RR Clients 

[WAJ] Please see the replies inline below.

2) BGP Session Establish Procedures – are these restrict to RR and RR
Clients?  

[WAJ] Yes. The BGP session is established between RR and its clients in
large network. It can also be established between two nodes directly.(as
described in https://datatracker.ietf.org/doc/html/rfc8821#section-3)

3) Explicit routes [section 6.2] – Is ECMP support as well as 1 prefix/1
next Hop?  

[WAJ] Yes, ECMP is supported. PCE needs to send two EPR(Explicit Peer Route)
objects, with the same “Destination Adress” and “Route Priority”, but
different “Next Hop Address”

4) IPv4/IPv6 restrictions [section 6.3] – are you restricting the peer
session or the AFI/SAFI supported by the Peer session? 

[WAJ] AFI/SAFI supported by the peer session.

5) Sections 7, 9, and 10 – may need to change based on your answers to
questions 1-4? 

Detailed questions 

---------------------

1. Section 6 – sub sections 6.1, 6.2 and 6.3. 

Problem: 

The text that describe the BGP peers and the diagram needs clarification on
the BGP peering between BGP peers:  R1, R7, and R3. If R1 and R7 are Route
Reflector clients (RR clients) are attached to the R3 then it is important
to indicate this point. 

[WAJ] Yes, R1 and R7 is RR clients.

If you are using classic route reflection, then R1, R3 and R7 would need to
be in the same Autonomous system. 

[WAJ] Yes, certainly.

The RR (R3) determines what routes are sent to the RR clients.  

This problem impacts the text in section 6.1, 6.2, and 6.3 

2.) Text change for Section 6.1 – if R1 and R7 are RR clients. 

Here’s a change if R1 and R7 are Router Reflector Clients.  

Current text: /

   The PCInitiate message should be sent to PCC which acts as BGP router

  and route reflector(RR).  In the example in Figure 1, it should be

   sent to R1(M1), R3(M2 & M3) and R7(M4), when R3 acts as RR./

Improved text: /

   The PCInitiate message should be sent to PCC which acts as 

    BGP router reflector or a route reflector client. In the 

   example in Figure 1, it should be

   sent to the route reflector clients R1(M1) and R7 (M4), and 

  the route reflector R3 (M1 or M4).    /

[WAJ] Has updated the draft with the following contents(almost same as your
suggestions):

The PCInitiate message should be sent to PCC which acts as BGP router and/or
route reflector(RR). In the example in Figure 1, it should be sent to route
reflector clients R1(M1) and R7(M4), and the route reflector R3(M2 & M3)
when R3 acts as RR. PCInitiate message creates an auto-configuration
function for these BGP peers providing the indicated Peer AS and the
Local/Peer IP Address.

3) Section 6.1 – BGP Session Establishment Procedure 

Question: Does the PCEInitiate (message and report) require the RR and RR
client structure? 

[WAJ] No. not necessary.  The BGP session setup procedures is same between
RR and its clients.

If so, the PCInitiate should have a parameter indicate what type of BGP peer
(RR or RR client) each receiving BGP peer should be.   

4) Section 6.2 – Explicit Route Establishment Procedure 

Problem: It is unclear what the impact to the routing system of the setting
of explicit route.  

Basic Details: (1 Route with 1 Next Hop)

If R1 and R7 are RR clients and the Explicit route operates as static route
installed by the PCIntiate, then BGP peer will reflected these static routes
R3. 

[WAJ] No, the explicit route is only installed on the aimed PCC nodes and
such information will not be advertised via the BGP session between RR and
its clients.

[R1 (explicit route [static route]) à R3] 

[R1 (explicit route [static route]) à R3] 

Setting or clearing the Explicit route seem to map to a setting/clear a
static route on the node.  If this is true, then this section needs to be
rework to clear describe the process. 

[WAJ] Yes, it is similar with the static route on the node. The purpose of
these explicit routes are to influence the final recursive forwarding path
for prefixes advertised by BGP peer.

Your setting the route on the pathway hop by hop is similar to
netconf/restconf setting routes in a pathway.   

[WAJ] Yes, it is similar.

ECMP Details: (1 Route with multiple Next Hop) 

If the explicit route is a ECMP route with multiple next hop paths, the next
hop for a route installed in could be R5 or R2. 

[WAJ] Yes. For ECMP routes, the PCE needs to send two EPR objects to PCC(in
Figure2, on R1), with the “Destination Address” are both set to R7, but
the “Nexthop Address” is set differently(for example, R2, R5 as you
mentioned.).  The “Route Priority” field in EPR object should also be the
same.

If ECMP is allowed, then you need to decide if:

a) adding this route allows the route to be installed if only some of the
next hops are valid (for example R5 is valid, but R2 is not)

b) delete routing allows the route to be deleted if both next hops were not
installed. 

[WAJ]  Adding the description “The PCC should verify that the next hop
address is reachable.”  before the sentence “Upon the error occurs, the
PCC SHOULD send the corresponding error via PCErr message, with an error
information… …。

5) Section 6.3 

Problem:  You do not clear indicate the status of BGP peer routers. 

If R1 and R7 are BGP route reflector clients, then R1 and R7 will send the
route to R3 which will reflect the route to other RR clients (if policy
allows). 

[WAJ] The propagation of BGP prefixes is the same as the traditional BGP
procedures. The “Peer Address” in PPA objects indicates which peer the
prefixes will be sent to.

6.) Section 6.3 

Problem:  It is unclear why there is a restriction for IPv4 prefix to be
sent only via a IPv4 BGP section, and the IPv6 prefix only via a IPV6
section. 

Details: I think the author is trying to describe the peers support for a
particular set of AFI/SAFIS for NLRI sent rather than the peering.  However,
it is unclear. 

[WAJ] What we want to express is that the IPv4 BGP Peer session will
advertise/receive only IPv4 prefixes(AFI/SAFI is 1/1 ), and IPv6 BGP Peer
session will advertise/receive IPv6 prefixes(AFI/SAFI is 2/1)

7.) Sections 7.2 and 7.3 

All of these issues on the intent of the protocol need to be answered before
I can provide additional feedback on the PCEP objects.  

The initial shape of the PCE discussion are reasonable, but working through
the details requires clarity in sections 6.1 to 6.3.  For example, support
for ECMP in the explicit routes may cause sections 7.3 and 7.4 to be
rewritten. 

8.) Section 9 – 

The error handling must consider the RR to RR client distribution of routes.

[WAJ] The route distribution process between the RR and RR clients is
unchanged.

Also, if one PCE overwrites another multiple route are sent from a RR client
to the RR.  The policy in the RR must be set-up to handle errors. 

[WAJ] The information from EPR object is not advertised by the RR client
back to the RR.

This section needs a bit of rethinking. 

8.) Section 10 - BGP Considerations -  

The content of the BGP consideration sections seems reasonable, but it
should be reviewed again after all the remainder of the document has been
clarified. 

[WAJ] Wish to receive your more through considerations for the current
solution.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 27 Jul 2021 17:58:10 -0400

Aijun: 

Thank you for your quick response.  

I’ve answered questions below.  Would you let me know when you update your
draft?  I’ll re-read the sections that changed and make additional
suggestions.  If you think it would be useful to add 2 (or more) next hops
per EPR, please let me know. 

I’m glad to keep reviewing your changes. 

Cheers, Sue 

From: Aijun Wang [mailto:[email-masked]] 
Sent: Tuesday, July 27, 2021 3:19 AM
To: 'Susan Hares'; [email-masked]
Cc: 'idr-chairs'; 'pce-chairs'
Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with
HyperLink Correction

Hi, Susan and all:

Hi, Susan:

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Susan Hares
Sent: Tuesday, July 27, 2021 7:19 AM
To: [email-masked]
Cc: 'idr-chairs' <[email-masked]>; 'pce-chairs' <[email-masked]>
Subject: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt

Greetings: 

[Sue] You have understood that the bgp auto-configuration works on peer
set-up. 

          I simply wanted you to know that your PCE work linked that that
work in BGP. 

 

Cheers, Sue 

Overview of errors 

The point –to-point (P2P) Peering was clear in RFC8821. 

[Sue] It would be useful to revise the draft to clearly define this is a
single AS,

RR location, and RR client locations. 

[Sue] – it is possible to be more effective in the EPR by including 2 (or
more)

Next Hops.  Have you consider this choice in PCE? 

[Sue] Again – it would be helpful to clearly state AFI/SAFI. 

Detailed questions 

---------------------

Problem: 

[Sue] Please make this fact clear in your next revision. 

[WAJ] Yes, certainly.

[Sue] Please make that clear in your document. 

Current text: /

Improved text: /

route reflector (RR). In the example in Figure 1, it should be sent to route

[Sue] Thank you.  Did you submit your updated draft? 

[Sue]: If you use the PCEInitiate message with another structure, it would
be useful

To include an example in your document of multiple peers. 

[R1 (explicit route [static route]) à R7] [note my error]  

                [Sue] If a route is installed in the RR clients, why is it
not updated to the BGP

               Peer web (R1-RR-R7). I thought the purpose of adding it to
the RR client. 

                If it is not the purpose, why is this included in the BGP
section? 

[Sue] Then is the purpose to send it from 1 RR client (for example R1), and 

 Have it redistribute to R3 (RR) and R7 (RR client). 

[Sue] Thank you.  At least I got one detail correct [smile]. 

[Sue] Thank  you for the explanation.  Do you think it is useful to allow 2
Next-Hops 

 In the same EPR object. 

[Sue]:  This is a wonderful addition. 

5) Section 6.3 

[Sue] If you have trio of 2 RR clients and RR, then simply indicate you
follow RR-RRclient rules. 

6.) Section 6.3 

[WAJ] What we want to express is that the IPv4 BGP Peer session will
advertise/receive only IPv4 prefixes(AFI/SAFI is 1/1 ), and IPv6 BGP Peer
session will advertise/receive IPv6 prefixes(AFI/SAFI is 2/1).

                 [Sue]: Why did you make this restriction?  Is it from PCE
requirements? 

7.) Sections 7.2 and 7.3 

8.) Section 9 – 

[Sue] What prevents the EPR object from being sent to the RR via BGP. 

Is the EPR object not installed in the BGP RIBs to be sent? 

I think I am missing something simple here. 

[Sue] Thank you for the discussion.  Could you provide updates

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 28 Jul 2021 15:42:27 +0800

Hi, Susan, Mike and All other experts:

I have just upload the updated version of this draft, would you like to
review it again to refine it?

And you can also refer the presentation on this IETF meeting for additional
update
introduction(https://datatracker.ietf.org/meeting/111/materials/slides-111-p
ce-sessa-21-native-ip-00.pdf).

Thanks in advance.

Best Regards

Aijun Wang

China Telecom

From: Susan Hares <[email-masked]> 
Sent: Wednesday, July 28, 2021 5:58 AM
To: 'Aijun Wang' <[email-masked]>; [email-masked]
Cc: 'idr-chairs' <[email-masked]>; 'pce-chairs' <[email-masked]>
Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with
HyperLink Correction

Aijun: 

[WAJ] Adding 2 (or more) next hops per EPR is one viable solution to achieve
the ECMP effects, but it seems that the current format is more flexible and
extensible? For example, if we want to add the UCMP features, as Mike
proposed, we can add some information within the “Optional TLV” field of
the EPR to indicate what percentage traffic should be allocated to each
nexthop.

Cheers, Sue 

To: 'Susan Hares'; [email-masked] <mailto:[email-masked]> 

Hi, Susan and all:

From: [email-masked] <mailto:[email-masked]>  <pce-bounces@ietf.
org <mailto:[email-masked]> > On Behalf Of Aijun Wang
Sent: Tuesday, July 27, 2021 12:04 PM
To: 'Susan Hares' <[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 
Cc: 'idr-chairs' <[email-masked] <mailto:[email-masked]> >;
'pce-chairs' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt

Hi, Susan:

Best Regards

Aijun Wang

China Telecom

Greetings: 

 

Cheers, Sue 

Overview of errors 

[WAJ] Has added some text as below. Actually, the procedures described in
this draft is not limited to one AS, it can be applied to inter-AS scenario
simultaneously. 

“In the example in Figure 1, if the router R1 and R7 are within one AS and
R3 acts as the route reflector, PCInitiate message should be sent to route
reflector clients R1(M1) and R7(M4), and the route reflector R3(M2 & M3)
respectively. For inter-AS scenario, such message can be sent directly to
the ASBR router to build EBGP session.”

[WAJ] As I answered in the begin of this email, it seems to encode one
single hop per EPR is more clear, extensible and flexible?

[WAJ] Has updated the draft accordingly, as “The allowed AFI/SAFI for the
IPv4 BGP session should be 1/1(IPv4 prefix) and the allowed AFI/SAFI for the
IPv6 BGP session should be 2/1(IPv6 prefix). If mismatch occur, an
error(Error-type=TBD6, Error-value=TBD18, BPI/PPR address family mismatch)
should be reported via PCErr message.”

Detailed questions 

---------------------

Problem: 

[WAJ] Done

[WAJ] Yes, certainly.

[WAJ] Done

Current text: /

Improved text: /

[WAJ] Done

[WAJ] The BPI(BGP Peer Info) object is sent only to the two BGP peers, will
not be sent to multiple peers (>2) simultaneously. 

          The PPA(Peer Prefix Advertisement) object is sent only to the
prefixes source node(for example, R1 or R7 in Figure 4). The RR needs not
receive such instructions. RR will receive the advertised prefix and forward
it to its other clients, based on the normal RR behavior.

Then, there is no differences for the BPI and PPA messages to RR, or its
clients.

[WAJ] EPR object is different with BPI and PPA objects.  EPR object is just
used to indicate/influence how to get the BGP nexthop.  Such information
does not spread via the BGP mechanism, it is deployed by the PCEP protocol
directly.

[WAJ] No, it is not redistribute to R3. EPR object is deployed directly via
the PCEP protocol. The spread of such information is different from PPA,
which is via the BGP control plane.

[WAJ] It’s my responsibility to describe the mechanism more clearly.

 In the same EPR object. 

[WAJ] Currently, I think one next-hop per EPR maybe more clear, extensible
and flexible. If there is any other strong advantages, we can modify it
later.

5) Section 6.3 

[WAJ] The PPA(Peer Prefixes Advertisement) object need only be sent to the
source node, then such prefixes information will be flooded based on the
regular BGP RR mechanism. We need not send PPA object to all of the RR’s
clients.

6.) Section 6.3 

[WAJ] Just want to simplify the management of network and less error-prune.

7.) Sections 7.2 and 7.3 

8.) Section 9 – 

[WAJ] EPR object is deployed along the optional path via PCEP protocol, it
will be installed in the RIB of node, but not the BGP RIB of the node.

[WAJ] The EPR object is described between BPI and PPA object section, maybe
this lead to your impression that it is also related to the BGP. If
necessary, we can adjust the description sequences of these objects later.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 29 Jul 2021 17:50:27 -0400

Aijun:

I apologize for missing PCE session today.  I re-injured a knee just before
the session.  Let me provide you suggestions for sections 6.1, 6.2, and 6.3
that may resolve some of the issues.  

This specification provides one mechanism for BGP auto-configuration.  I’m
happy to continue to review this draft and provide suggestions.  

Cheerily, Susan Hares

Section 6.1

=============

Old text:/

    The procedures for establishing the BGP session between two peers

     By using the PCInitiate and PCRpt message pair is show below: /

New text:/

    The PCInitiate message can be used to configure the parameters for 

    a BGP peer session using the PCInitiate and PCRpt message pair.

    This pair of PCE messages is exchanged with a PCE function 

    Attached to each BGP peer which needs to be configured.  

    After the BGP peer session has been configured 

    via this pair of PCE messages the BGP session establishment process 

    operates in a normal fashion.  

    All BGP peers are configured for peer to peer communication whether the

    peers are E-BGP peers or I-BGP peers.   One of the IBGP topologies
requires

    that multiple I-BGPs peers operate in a route-reflector I-BGP peer
topology.

    The example below shows 2 I-BGP route reflector clients interacting

    with one Route Reflector (RR), but Route Reflector topologies may have

    up to 100s of clients.  Centralized configuration via PCE provides 

    mechanisms to scale auto-configuration of small and large topologies.  

old text:/

    In the example in Figure 1, if the routers R1 and R7 are within one AS

    and R3 acts as a router reflector.  PCInitiate message should be sent 

    to route reflector clients R1 (M1) and R7 (M4),a nd the route reflector

    clients (R3 M2 & M3) respectively.  For inter-AS scenario, such message

    can be sent directly to ASBR router to build EBGP session./ 

New text:/

    The route reflector topology for a single AS is shown in Figure 1. 

    The BGP routers R1, R3, and R7 are within a single AS.  R1 and R7

    are BGP router-reflector clients, and R3 is a Route Reflector. 

     The PCInitiate message should be sent all of the BGP routers that

     need to be configured R1 (M3), R3 (M2 & M3), and R7 (M4). / 

---------------------------

Section 6.2.  

My understanding for your email is that the explicit route 

establishment procedures are installing a static route 

which is not to be redistributed via BGP peer. 

If this understanding is correct, please clearly state this 

fact and modify the diagrams to indicate a static route

A suggestion for text for this case is: 

Old text: /

The detail procedures for the explicit route establishment

procedures are show below. / 

New text: /

The explicit route establishment procedures can be used

to install a route via PCE in the PCC/BGP Peer.

Based on BGP policy, these routes may or may not 

be redistributed by the BGP peers.  PCE explicit routes 

operate similar to static routes installed

by network management protocols (netconf/restconf) 

but the  routes are associated with the PCE routing module.   

An example of the use case where the of the use case where 

explicit route installed by PCE is redistributed by BGP is 

described in section 6.3.  An example of the procedure 

where the explicit route installed by PCE is not redistributed

by BGP is described in this section (see figure 2 below for the 

topology).   Explicit route installations (like NM static routes) 

must carefully install and uninstall static routes in an specific

order so that the pathways are established without loops. /

----------------

Section 6.3 

Old text:/

The detailed procedures for BGP prefix advertisement are shown 

Below using PCInitiate and PCRpt message pair./

New Text:/

The explicit route establishment procedures can be used

to install a route via PCE in the router that is both

a PCC and BGP Peer.  Based on BGP policy, these routes   

may be redistributed by the BGP peers (or may not be distributed).  

This section provides an example  of the 

PCInitiate and PCRpt messages for the use case when 

routes installed via PCE are redistributed within an IBGP 

cloud with RR and RR clients when a I-BGP policy allows

PCE explicit routes to be originated within the I-BGP cloud. 

The E-BGP use case and the IBGP use case without

route reflectors are not shown in this example.  

The redistribution via BGP of PCE explicit routes

based on the BGP policy is similar to redistribution 

of static routes installed by network management 

protocols (netconf/restconf) are redistributed by BGP.  

However, in this use case configured routes are 

associated with the PCE routing module and BGP 

policy must handle the redistribution of these routes. / 

==========

 

Sent: Wednesday, July 28, 2021 3:42 AM

Thanks in advance.

Best Regards

Aijun Wang

China Telecom

Aijun: 

Cheers, Sue 

Hi, Susan and all:

Hi, Susan:

Best Regards

Aijun Wang

China Telecom

Greetings: 

 

Cheers, Sue 

Overview of errors 

Detailed questions 

---------------------

Problem: 

[WAJ] Done

[WAJ] Yes, certainly.

[WAJ] Done

Current text: /

Improved text: /

[WAJ] Done

 

 In the same EPR object. 

5) Section 6.3 

6.) Section 6.3 

7.) Sections 7.2 and 7.3 

8.) Section 9 –

---

From: Aijun Wang <[email-masked]>
Date: Fri, 30 Jul 2021 21:07:50 +0800

Hi, Susan:
Thanks for your review!
Detail responses are inlines below.

Aijun Wang
China Telecom

> On Jul 30, 2021, at 05:50, Susan Hares <[email-masked]> wrote:
> 
> 
> Aijun:
>  
> I apologize for missing PCE session today.  I re-injured a knee just before the session.  Let me provide you suggestions for sections 6.1, 6.2, and 6.3 that may resolve some of the issues.  
>  
> This specification provides one mechanism for BGP auto-configuration.  I’m happy to continue to review this draft and provide suggestions. 
>  
> Cheerily, Susan Hares
>  
>  
> Section 6.1
> =============
> Old text:/
>     peers are E-BGP peers or I-BGP peers.   One of the IBGP topologies requires
>     that multiple I-BGPs peers operate in a route-reflector I-BGP peer topology.
[WAJ] Will update the draft later accordingly to your suggestions.
>      need to be configured R1 (M3), R3 (M2 & M3), and R7 (M4). /
[WAJ]  Will update the draft later accordingly to your suggestions.
[WAJ] Yes, the information deployed via EPR object will not redistributed via BGP.
> to install a route via PCE in the PCC/BGP Peer.
[WAJ] Correct.
> be redistributed by the BGP peers.
[WAJ] Such info will not be redistributed via BGP. The BGP session that established via BPI object will only advertise Prefixes that included in the PPA object.
>  PCE explicit routes
[WAJ]Correct
> described in section 6.3. 
[WAJ] No. The information in EPR object is not redistributed by BGP.  Section 6.3 describes how to deploy the prefixes that should be advertised by BGP session that established via BPI object.
The information within PPA has no relation with the information in EPR object.

> An example of the procedure
> topology).  
[WAJ]I think this sentence should be omitted.

>  Explicit route installations (like NM static routes)
[WAJ] Will update the draft later accordingly.

[WAJ] The above description is not correct. Wish my explanation can help you to review it again.
Wait for your updated suggestions.

> Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
>  
> I have just upload the updated version of this draft, would you like to review it again to refine it?
> And you can also refer the presentation on this IETF meeting for additional update introduction(https://datatracker.ietf.org/meeting/111/materials/slides-111-pce-sessa-21-native-ip-00.pdf).
> Thanks in advance.
>  
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
>  
> Aijun:
>  
> I’ve answered questions below.  Would you let me know when you update your draft?  I’ll re-read the sections that changed and make additional suggestions.  If you think it would be useful to add 2 (or more) next hops per EPR, please let me know.
> [WAJ] Adding 2 (or more) next hops per EPR is one viable solution to achieve the ECMP effects, but it seems that the current format is more flexible and extensible? For example, if we want to add the UCMP features, as Mike proposed, we can add some information within the “Optional TLV” field of the EPR to indicate what percentage traffic should be allocated to each nexthop.
>  
> Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
>  
> Hi, Susan and all:
>  
> Update one hyperlink on the contents, please refer to this mail for comments responses.
>  
> Thanks for your reviews, let me first address your current questions and wait for the further discussions on the overall solution.
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> This comment should be consider feedback from me as a WG member of IDR and PCE.  I have posted this information also on the  
>  
> This draft takes a step toward auto-configuration of BGP peers.  IDR has created a set of requirements for BGP auto-configuration for Data Centers at:
> [WAJ] Yes, I have also reviewed this document and attended some discussions on it. The autoconf document tries to build the BGP from scratch without 3rd party(for example, PCE) assistance. It considers mainly the direct connected BGP peer setup process automatically and does not involve the prefix advertisement and explicit route setup.
> I think the aim of these two drafts is different but we can refer to some designed considerations from it.
>  
> [Sue] You have understood that the bgp auto-configuration works on peer set-up.
>           I simply wanted you to know that your PCE work linked that that work in BGP.
>  
> https://trac.ietf.org/trac/idr/wiki/pce-pcep-extension-native-ip%20Hares%20comments
>  
>  
> Cheers, Sue
>  
> 2) BGP Session Establish Procedures – are these restrict to RR and RR Clients?  
> [WAJ] Yes. The BGP session is established between RR and its clients in large network. It can also be established between two nodes directly.(as described in https://datatracker.ietf.org/doc/html/rfc8821#section-3)
>  
> [Sue] It would be useful to revise the draft to clearly define this is a single AS,
> [WAJ] Has added some text as below. Actually, the procedures described in this draft is not limited to one AS, it can be applied to inter-AS scenario simultaneously.
> “In the example in Figure 1, if the router R1 and R7 are within one AS and R3 acts as the route reflector, PCInitiate message should be sent to route reflector clients R1(M1) and R7(M4), and the route reflector R3(M2 & M3) respectively. For inter-AS scenario, such message can be sent directly to the ASBR router to build EBGP session.”
>  
> 3) Explicit routes [section 6.2] – Is ECMP support as well as 1 prefix/1 next Hop?  
> [WAJ] Yes, ECMP is supported. PCE needs to send two EPR(Explicit Peer Route) objects, with the same “Destination Adress” and “Route Priority”, but different “Next Hop Address”
> [Sue] – it is possible to be more effective in the EPR by including 2 (or more)
> [WAJ] As I answered in the begin of this email, it seems to encode one single hop per EPR is more clear, extensible and flexible?
>  
> 4) IPv4/IPv6 restrictions [section 6.3] – are you restricting the peer session or the AFI/SAFI supported by the Peer session?
> [WAJ] Has updated the draft accordingly, as “The allowed AFI/SAFI for the IPv4 BGP session should be 1/1(IPv4 prefix) and the allowed AFI/SAFI for the IPv6 BGP session should be 2/1(IPv6 prefix). If mismatch occur, an error(Error-type=TBD6, Error-value=TBD18, BPI/PPR address family mismatch) should be reported via PCErr message.”
>  
> 5) Sections 7, 9, and 10 – may need to change based on your answers to questions 1-4?
>  
> Detailed questions
> ---------------------
> The text that describe the BGP peers and the diagram needs clarification on the BGP peering between BGP peers:  R1, R7, and R3. If R1 and R7 are Route Reflector clients (RR clients) are attached to the R3 then it is important to indicate this point. 
> If you are using classic route reflection, then R1, R3 and R7 would need to be in the same Autonomous system.
> [WAJ] Yes, certainly.
> [WAJ] Has updated the draft with the following contents(almost same as your suggestions):
> The PCInitiate message should be sent to PCC which acts as BGP router and/or route reflector (RR). In the example in Figure 1, it should be sent to route reflector clients R1(M1) and R7(M4), and the route reflector R3(M2 & M3) when R3 acts as RR. PCInitiate message creates an auto-configuration function for these BGP peers providing the indicated Peer AS and the Local/Peer IP Address.
> Question: Does the PCEInitiate (message and report) require the RR and RR client structure?
> [WAJ] No. not necessary.  The BGP session setup procedures is same between RR and its clients.
> [Sue]: If you use the PCEInitiate message with another structure, it would be useful
> [WAJ] The BPI(BGP Peer Info) object is sent only to the two BGP peers, will not be sent to multiple peers (>2) simultaneously.
>           The PPA(Peer Prefix Advertisement) object is sent only to the prefixes source node(for example, R1 or R7 in Figure 4). The RR needs not receive such instructions. RR will receive the advertised prefix and forward it to its other clients, based on the normal RR behavior.
> Then, there is no differences for the BPI and PPA messages to RR, or its clients.
>  
> If so, the PCInitiate should have a parameter indicate what type of BGP peer (RR or RR client) each receiving BGP peer should be.   
>  
> Problem: It is unclear what the impact to the routing system of the setting of explicit route. 
>  
> If R1 and R7 are RR clients and the Explicit route operates as static route installed by the PCIntiate, then BGP peer will reflected these static routes  R3.
> [WAJ] No, the explicit route is only installed on the aimed PCC nodes and such information will not be advertised via the BGP session between RR and its clients.
>                 [Sue] If a route is installed in the RR clients, why is it not updated to the BGP
>                Peer web (R1-RR-R7). I thought the purpose of adding it to the RR client.
>                 If it is not the purpose, why is this included in the BGP section?
> [WAJ] EPR object is different with BPI and PPA objects.  EPR object is just used to indicate/influence how to get the BGP nexthop.  Such information does not spread via the BGP mechanism, it is deployed by the PCEP protocol directly.
>                               
>  
> Setting or clearing the Explicit route seem to map to a setting/clear a static route on the node.  If this is true, then this section needs to be rework to clear describe the process.
> [WAJ] Yes, it is similar with the static route on the node. The purpose of these explicit routes are to influence the final recursive forwarding path for prefixes advertised by BGP peer.
>  
> [WAJ] No, it is not redistribute to R3. EPR object is deployed directly via the PCEP protocol. The spread of such information is different from PPA, which is via the BGP control plane.
>  
> Your setting the route on the pathway hop by hop is similar to netconf/restconf setting routes in a pathway.   
> If the explicit route is a ECMP route with multiple next hop paths, the next hop for a route installed in could be R5 or R2.
> [WAJ] Yes. For ECMP routes, the PCE needs to send two EPR objects to PCC(in Figure2, on R1), with the “Destination Address” are both set to R7, but the “Nexthop Address” is set differently(for example, R2, R5 as you mentioned.).  The “Route Priority” field in EPR object should also be the same.
> [Sue] Thank  you for the explanation.  Do you think it is useful to allow 2 Next-Hops
>  In the same EPR object.
> [WAJ] Currently, I think one next-hop per EPR maybe more clear, extensible and flexible. If there is any other strong advantages, we can modify it later.
>  
> a) adding this route allows the route to be installed if only some of the next hops are valid (for example R5 is valid, but R2 is not)
> b) delete routing allows the route to be deleted if both next hops were not installed.
> [WAJ]  Adding the description “The PCC should verify that the next hop address is reachable.”  before the sentence “Upon the error occurs, the PCC SHOULD send the corresponding error via PCErr message, with an error information… …。
> If R1 and R7 are BGP route reflector clients, then R1 and R7 will send the route to R3 which will reflect the route to other RR clients (if policy allows).
> [WAJ] The propagation of BGP prefixes is the same as the traditional BGP procedures. The “Peer Address” in PPA objects indicates which peer the prefixes will be sent to.
> [Sue] If you have trio of 2 RR clients and RR, then simply indicate you follow RR-RRclient rules.
> [WAJ] The PPA(Peer Prefixes Advertisement) object need only be sent to the source node, then such prefixes information will be flooded based on the regular BGP RR mechanism. We need not send PPA object to all of the RR’s clients.
>  
> 6.) Section 6.3
> Problem:  It is unclear why there is a restriction for IPv4 prefix to be sent only via a IPv4 BGP section, and the IPv6 prefix only via a IPV6 section.
>  
> Details: I think the author is trying to describe the peers support for a particular set of AFI/SAFIS for NLRI sent rather than the peering.  However, it is unclear.
> [WAJ] What we want to express is that the IPv4 BGP Peer session will advertise/receive only IPv4 prefixes(AFI/SAFI is 1/1 ), and IPv6 BGP Peer session will advertise/receive IPv6 prefixes(AFI/SAFI is 2/1).
>                  [Sue]: Why did you make this restriction?  Is it from PCE requirements?
> All of these issues on the intent of the protocol need to be answered before I can provide additional feedback on the PCEP objects.  
>  
> The initial shape of the PCE discussion are reasonable, but working through the details requires clarity in sections 6.1 to 6.3.  For example, support for ECMP in the explicit routes may cause sections 7.3 and 7.4 to be rewritten.
>  
> 8.) Section 9 –
> [WAJ] The route distribution process between the RR and RR clients is unchanged.
>  
> Also, if one PCE overwrites another multiple route are sent from a RR client to the RR.  The policy in the RR must be set-up to handle errors.
> [WAJ] The information from EPR object is not advertised by the RR client back to the RR.
> [WAJ] EPR object is deployed along the optional path via PCEP protocol, it will be installed in the RIB of node, but not the BGP RIB of the node.
> [WAJ] The EPR object is described between BPI and PPA object section, maybe this lead to your impression that it is also related to the BGP. If necessary, we can adjust the description sequences of these objects later.
>  
> The content of the BGP consideration sections seems reasonable, but it should be reviewed again after all the remainder of the document has been clarified.
> [WAJ] Wish to receive your more through considerations for the current solution.           
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 30 Jul 2021 09:28:34 -0400

Aijun: 

Thank you for your kind response.   Just a brief word on these comments.  

[Sue] Based on BGP policy, these routes may or may not be redistributed by the BGP peers. 

[Sue2] May I suggest then you add the following text if the PCE-BGP interface should not send the route: 

“Although the BGP policy might redistribute the routes installed by explicit route, the PCE-BGP implementation needs to prohibit the redistribution of the explicit route” distributed by …. 

I look forward to your next draft.  I will provide reviews of sections 6 to the end of the draft.  

I’m pleased you are working on this draft as part of BGP auto-configuration efforts.  I hope that you will consider a short presentation at the IDR interim on 10/11 regarding your efforts in PCE. 

Cheers, Sue  

From: Aijun Wang [mailto:[email-masked]] 
Sent: Friday, July 30, 2021 9:08 AM
To: Susan Hares
Cc: [email-masked]; idr-chairs; pce-chairs
Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction

Hi, Susan:

Thanks for your review!

Aijun Wang

China Telecom

Aijun:

Cheerily, Susan Hares

Section 6.1

=============

Old text:/

New text:/

 

old text:/

New text:/

 

Section 6.2.  

 

Old text: /

New text: /

[WAJ] Correct.

 PCE explicit routes 

[WAJ]Correct

topology).  

----------------

Section 6.3 

Old text:/

New Text:/

==========

 

Thanks in advance.

Best Regards

Aijun Wang

China Telecom

Aijun: 

Cheers, Sue 

Hi, Susan and all:

Hi, Susan:

Best Regards

Aijun Wang

China Telecom

Greetings: 

 

Cheers, Sue 

Overview of errors 

Detailed questions 

---------------------

Problem: 

[WAJ] Done

[WAJ] Yes, certainly.

[WAJ] Done

Current text: /

Improved text: /

[WAJ] Done

 

 In the same EPR object. 

5) Section 6.3 

6.) Section 6.3 

7.) Sections 7.2 and 7.3 

8.) Section 9 –