Re: [Idr]

"UTTARO, JAMES" <> Fri, 17 July 2020 14:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 775213A0B96 for <>; Fri, 17 Jul 2020 07:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vBcU4zJQkS9T for <>; Fri, 17 Jul 2020 07:17:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE68C3A0B8B for <>; Fri, 17 Jul 2020 07:17:17 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 06HEGuxm000584; Fri, 17 Jul 2020 10:17:06 -0400
Received: from ( []) by with ESMTP id 32as3935f9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jul 2020 10:17:05 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 06HEH489000856; Fri, 17 Jul 2020 10:17:04 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 06HEGtJC000364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jul 2020 10:16:57 -0400
Received: from ( []) by (Service) with ESMTP id C30754009E76; Fri, 17 Jul 2020 14:16:55 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 9D5684009E61; Fri, 17 Jul 2020 14:16:55 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 17 Jul 2020 10:16:55 -0400
Received: from ([]) by ([]) with mapi id 15.01.2044.004; Fri, 17 Jul 2020 10:16:55 -0400
From: "UTTARO, JAMES" <>
To: Aijun Wang <>, "'Robert Raszuk'" <>
CC: "'Aijun Wang'" <>, "'idr@ietf. org'" <>
Thread-Topic: [Idr]
Thread-Index: AQHWWtV431jKqmW4IkmqC8LVyT5dHakJwlEAgABKUYCAADaCAIABZO8AgAArt5A=
Date: Fri, 17 Jul 2020 14:16:54 +0000
Message-ID: <>
References: <> <003c01d65b1a$777b60a0$667221e0$> <> <> <003001d65c0d$58b92ff0$0a2b8fd0$>
In-Reply-To: <003001d65c0d$58b92ff0$0a2b8fd0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 5A64AA8FC7F10C11FD4FE4D2147CC87C8ACCBCBF62765FFECA15E0B4DD9366852
Content-Type: multipart/alternative; boundary="_000_b6dba4dcf9ce4d80a2eeaadfcf6d7f84attcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-17_06:2020-07-17, 2020-07-17 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 adultscore=0 mlxscore=0 malwarescore=0 clxscore=1015 impostorscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 priorityscore=1501 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007170103
Archived-At: <>
Subject: Re: [Idr]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jul 2020 14:17:22 -0000


              What do you mean “to control the overwhelmed VPN prefix routes” ? What is being overwhelmed PE? RR Control Plane?

              Jim Uttaro

From: Aijun Wang <>
Sent: Friday, July 17, 2020 3:39 AM
To: UTTARO, JAMES <>om>; 'Robert Raszuk' <>
Cc: 'Aijun Wang' <>cn>; 'idr@ietf. org' <>
Subject: RE: [Idr]

Hi, Jim:

RT is not as precise as RD to reflect the specific VRF.  RD is to make the prefix unique, it is certainly unique for one VRF.
Then using RTC is not as simple and reliable as using RD-ORF to control the overwhelmed VPN prefixes routes.

Best Regards

Aijun Wang
China Telecom

Sent: Thursday, July 16, 2020 10:27 PM
To: Robert Raszuk <<>>; Aijun Wang <<>>
Cc: Aijun Wang <<>>; idr@ietf. org <<>>
Subject: RE: [Idr]<>

A combination of RTs can identify a VPN customer regardless of topologies being deployed. Our systems are able to figure out which paths belong to which customers. RD is used to make a prefix unique.  Using RT Constrain reduces the scope of an advertisement to interested topologies or subsets of topologies based upon the distribution of a set of VRFs.  Not sure what you want to do here.

              Jim Uttaro

From: Idr <<>> On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 3:06 AM
To: Aijun Wang <<>>
Cc: Aijun Wang <<>>; idr@ietf. org <<>>
Subject: Re: [Idr]<>

> It can also be used to identify the VPN customer.

Sorry but no.

Best practice for number of reasons is to make RD unique per VRF and not per VPN. We should not standardize something which is a pretty bad idea to start with.

Kind regards,

On Thu, Jul 16, 2020 at 4:40 AM Aijun Wang <<>> wrote:
Hi, Robert:

Thanks for your reviews and comments.
As you said, RD is to make the VPN prefix unique within the VPN’s domain.. It can also be used to identify the VPN customer.
The usage of RT, just as you said, is to control what routes are distributed where, that is to say, to control the customer’s VPN topology. RT can’t be used to identify one VPN customer.

The scenarios/problems described in this draft(<>) are not for the VPN topology control, but for the VPN prefix limit management, which is signed along with the agreement with the VPN customer.
This is the reason that we select the RD-based ORF control mechanism.

More detail reply are inline below. Wish to get more your comments/suggestions on them.

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

From:<> [<>] On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 2:26 AM
To:<>; Aijun Wang <<>>
Cc: idr@ietf. org <<>>
Subject: [Idr]<>

Dear Aijun & Wei,

I have read your draft as per subject.

I think there is a serious misunderstanding on what RD's role is in RFC4364.

RDs MUST never be used to signal anything which would in any way influence what routes are distributed where. Their sole role is to make the VPN prefix unique across given VPN's domain.
【WAJ】RD can be used to identify one VPN customer

It is RTs which are used to import routes to VRFs on PEs. What you are trying to do is exactly why we have defined some time back RTC (RFC4684). Applications from section 5.1 and 5.2 can be happily addressed with use of RTC.
【WAJ】RT is used to control VPN topology, same as the mechanism of RTC(4684). But the application described in section 5.1 and 5.2 of this draft is not for VPN topology control, but for VPN route-limit management, which is based on customer/RD.

Informationally let me also point out that RFC7543 has defined extensions to ORF to signal RTs for reducing size VPN RIBs in specific Hub & Spoke topologies..
【WAJ】RFC7543 is to pull the prefix that cover one specific host address, to get the more optimal route information from the Hub, not the same scenarios as described in the current draft.

Last your proposal calls for treating ORF as a transitive message without any loop protection. That is not a good idea.
【WAJ】ORF messages are exchanged within only the directed BGP sessions. Such Messages will be regenerated when it is needed to send to another BGP peer.  Would you like to describe more for the loop scenarios?

I recommend to protect your PEs from being overwhelmed by VPN routes by prefix limit instead.
【WAJ】Prefix Limit mechanism can be used for Option –A, but not for Option B/C, as that described in the draft.

Kind regards,

PS. Did we have any discussion in IDR or BESS on this proposal ?