Re: [Pce] Follow up about my question on the mic

Aijun Wang <wangaj3@chinatelecom.cn> Wed, 28 July 2021 04:06 UTC

Return-Path: <wangaj3@chinatelecom.cn>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B734F3A1ABA; Tue, 27 Jul 2021 21:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYrtb6WReM60; Tue, 27 Jul 2021 21:06:49 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id 385B33A1AB8; Tue, 27 Jul 2021 21:06:49 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.218:44830.638668711
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.75 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 1C7E52800AC; Wed, 28 Jul 2021 12:06:44 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.218]) by app0025 with ESMTP id 6de5f4a6cbe94fdb804baa0af1ccc8f1 for draft-ietf-pce-pcep-extension-native-ip@ietf.org; Wed Jul 28 12:06:46 2021
X-Transaction-ID: 6de5f4a6cbe94fdb804baa0af1ccc8f1
X-filter-score:
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: wangaj3@chinatelecom.cn
From: "Aijun Wang" <wangaj3@chinatelecom.cn>
To: <mkoldych@cisco.com>, "'Aijun Wang'" <wangaijun@tsinghua.org.cn>, "'Mike Koldychev \(mkoldych\)'" <mkoldych=40cisco.com@dmarc.ietf.org>, <draft-ietf-pce-pcep-extension-native-ip@ietf.org>
Cc: <pce@ietf.org>
References: <DM6PR11MB38021A1CCCC2C52CA2DA8B94D3E89@DM6PR11MB3802.namprd11.prod.outlook.com> <06fc01d78292$c9b30df0$5d1929d0$@tsinghua.org.cn> <DM6PR11MB3802710090963651BCCA21F0D3E99@DM6PR11MB3802.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB3802710090963651BCCA21F0D3E99@DM6PR11MB3802.namprd11.prod.outlook.com>
Date: Wed, 28 Jul 2021 12:06:41 +0800
Message-ID: <013b01d78365$fa34d160$ee9e7420$@chinatelecom.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_013C_01D783A9.085C3010"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKyElImyex3doVSjRo34cevJ3RDqwMEdkp9Ar+ll1KpdIT7EA==
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/GpXml83Du8cau5Y7sW3zt2-DQ5c>
Subject: Re: [Pce] Follow up about my question on the mic
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jul 2021 04:06:56 -0000

Hi, Mike:

 

Thanks for your suggestions. I have added the following sentences in section
6.2 as:

 

"To accomplish ECMP effects, the PCE can send multiple EPR objects to the
same node, with the same route priority and peer address value but different
next hop addresses."

 

Will update the draft later together with the comments from Susan.

Thanks for your comments, would like to see your more suggestions on the
solution.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: mkoldych@cisco.com <mkoldych@cisco.com> 
Sent: Tuesday, July 27, 2021 8:41 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>cn>; 'Mike Koldychev (mkoldych)'
<mkoldych=40cisco.com@dmarc.ietf.org>rg>;
draft-ietf-pce-pcep-extension-native-ip@ietf.org
Cc: pce@ietf.org
Subject: RE: [Pce] Follow up about my question on the mic

 

Hi Aijun,

 

Thanks for clarifying Q1.

 

Regarding Q2, you can probably mention that in the draft. Multiple EPR
objects MAY be sent for the same destination, which results in ECMP to that
destination.

 

Thanks,

Mike.

 

From: Pce <pce-bounces@ietf.org <mailto:pce-bounces@ietf.org> > On Behalf Of
Aijun Wang
Sent: Monday, July 26, 2021 10:55 PM
To: 'Mike Koldychev (mkoldych)' <mkoldych=40cisco.com@dmarc.ietf.org
<mailto:mkoldych=40cisco.com@dmarc.ietf.org> >;
draft-ietf-pce-pcep-extension-native-ip@ietf.org
<mailto:draft-ietf-pce-pcep-extension-native-ip@ietf.org> 
Cc: pce@ietf.org <mailto:pce@ietf.org> 
Subject: Re: [Pce] Follow up about my question on the mic

 

Hi, Mike:

 

Thanks for your questions. Please see the replies inline.

If you have more questions based on the followings answers, we can discuss
them accordingly.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: pce-bounces@ietf.org <mailto:pce-bounces@ietf.org>
<pce-bounces@ietf.org <mailto:pce-bounces@ietf.org> > On Behalf Of Mike
Koldychev (mkoldych)
Sent: Tuesday, July 27, 2021 6:36 AM
To: draft-ietf-pce-pcep-extension-native-ip@ietf.org
<mailto:draft-ietf-pce-pcep-extension-native-ip@ietf.org> 
Cc: pce@ietf.org <mailto:pce@ietf.org> 
Subject: [Pce] Follow up about my question on the mic

 

Hi Authors,

 

Just following up about my 2 questions during the PCE WG session about
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-i
p-14.

 

Question 1: Is every prefix going to be advertised (via the RR) to every
node in the native-ip domain, even if those nodes are never on-path for that
prefix? 

[WAJ] Yes, the behavior of RR is unchanged.

If my understanding is correct, the "BGP peer nodes" (R1 & R7 in Figure 4)
would receive the PPA (Prefixes) and would inject these prefixes into the
RR. The RR would then flood these prefixes (as regular BGP IP routes) to
every single node in the domain (R2, R4, R5, R6) with the next-hop being set
to R1 or R7. Please let me know if my understanding is correct or am I
missing something. So even though R5 and R6 in this example are off-path,
they would receive the prefix route from the RR?

[WAJ] Yes, R5 and R6 will also receive such prefix advertisements via the
normal RR behavior. But on router R5&R6, the route to the BGP nexthop
(R1&R7) is learned from the IGP protocol, not from the EPR(Explicit Peer
Route) Object. Then after the recursive process, the forwarding path on
R5&R6 will be along the normal non-optimal path.

 

Question 2: Have you thought about ECMP/UCMP (Equal/Unequal Cost Multipath)?
How would you implement it in your protocol?

[WAJ] Currently, we consider only the ECMP application. If PCE wants to
deploy multiple ECMP paths between two adjacent nodes, it can send two EPR
Objects to the corresponding PCC, with the "Route Priority" field be set to
the same value.

 

Thanks,

Mike.