IETF Logo Mail Archive

Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 05 August 2020 16:48 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92003A0CD7 for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 09:48:52 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Eb-BwM8mQSQX for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 09:48:49 -0700 (PDT)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB8E3A0CE6 for <idr@ietf.org>; Wed, 5 Aug 2020 09:48:47 -0700 (PDT)
Received: from [240.0.0.1] (unknown [111.194.51.107]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 0CBA24736B; Thu, 6 Aug 2020 00:48:43 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-575B8134-1816-42F9-BC44-1357E97D48F7"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Thu, 06 Aug 2020 00:48:42 +0800
Message-Id: <D2259017-50C8-4481-AC3B-BA7FB7D4DA60@tsinghua.org.cn>
References: <CAOj+MMHzritvnTE=wbojZJz52Ww38CPz32oY=cDEM9zcPUPgfQ@mail.gmail.com>
Cc: Keyur Patel <keyur@arrcus.com>, idr <idr@ietf.org>, wangw36@chinatelecom.cn
In-Reply-To: <CAOj+MMHzritvnTE=wbojZJz52Ww38CPz32oY=cDEM9zcPUPgfQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (17F80)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZH0hNGRkeSh5OSxkeVkpOQk1NT01KSUhKT05VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hKTFVKS0tZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OE06PTo4NT8ZPUtMTgk0Dx0z FjdPCyJVSlVKTkJNTU9NSklITktKVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU5KVUpLTFlXWQgBWUFPQ05INwY+
X-HM-Tid: 0a73bf86662f9865kuuu0cba24736b
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_w3fJ_7IURBLcxr3rHYGFzEX5C8>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 16:48:53 -0000

Hi, Robert:

Aijun Wang
China Telecom

> On Aug 6, 2020, at 00:14, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> 
>> [WAJ] The VPN routes imported in these VRFs can’t use the same RD, or else, the VPN prefixes in different VRFs will collision on RR.
> 
> Nothing will "collide" on RRs. 
> 
> NLRI = RD+Prefix  not just the RD. 

[WAJ] The prefix part can be overlap in different VRF. If the RD is same, RD+Prefix will also be overlap.
We must make sure different VRF use different RD to make the VPN prefixes unique within the domain.
> 
> So you may have completely different prefixes sourced by the same VRF going to completely different VRFs on same or different PEs. 
> 

[WAJ] This situation is for extraVPN communication, and should be designed carefully to avoid the address collision. 
If the address space in different VRF need to be considered in such manner, putting them in one VRF may be more straightforward.

> Kind regards,
> R.
> 
> 
> 
> 
> 
>

v2.23.0 | Report a Bug | By Email