Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt

Chongfeng Xie <xiechf@chinatelecom.cn> Sat, 28 January 2023 00:48 UTC

Return-Path: <xiechf@chinatelecom.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 B7BE2C14CE33; Fri, 27 Jan 2023 16:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.889
X-Spam-Level:
X-Spam-Status: No, score=-6.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkJ-t8DzDfT9; Fri, 27 Jan 2023 16:48:42 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id 62026C14CE22; Fri, 27 Jan 2023 16:48:40 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.218:39690.656562390
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-10.133.8.6 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 9ABDB2800AF; Sat, 28 Jan 2023 08:48:30 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([10.133.8.6]) by app0025 with ESMTP id 5a6095df79af4498a7fb3c41723a7dda for robert@raszuk.net; Sat, 28 Jan 2023 08:48:36 CST
X-Transaction-ID: 5a6095df79af4498a7fb3c41723a7dda
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 10.133.8.6
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Sat, 28 Jan 2023 08:48:30 +0800
From: Chongfeng Xie <xiechf@chinatelecom.cn>
To: robert <robert@raszuk.net>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, idr <idr@ietf.org>, xing <xing@cernet.edu.cn>
References: <202301250747459386600@chinatelecom.cn>, <2023012517403527261033@chinatelecom.cn>, <CAOj+MMGyr8uowrY2oJKTncKJ25Ey0Y7otq2iqRzutd8u7Dk=ow@mail.gmail.com>, <2023012708023871817347@chinatelecom.cn>, <CAOj+MMGXHWf=gLOMJ1mRF_xaPapCC6ZhCzz4NEwDH9fMVQhQMg@mail.gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.24.96[cn]
Mime-Version: 1.0
Message-ID: <2023012808483046168910@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart872131523470_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GCFwlOQrkVjsP2FYGrW__Yr74GY>
Subject: Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 28 Jan 2023 00:48:46 -0000

Hi Robert,
Thank you for your comments, my feedback inline please.


xiechf@chinatelecom.cn
 
From: Robert Raszuk
Date: 2023-01-27 08:32
To: Chongfeng Xie
CC: idr-chairs@ietf.org; idr; xing
Subject: Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt
Hi,
 
[Chongfeng]: It is not about the "duplicate" of the routing information, it is just about the mapping of IPv4 routes into IPv6 domain on the basis of address mapping rule, so the capacity of the control plane will not double.  

The control plane size will not double but quadruple as you are using new SAFI and new NLRIs with IPv4-mapped-IPv6 addresses . 

Just look at 128 bits for 1M nets vs 32 bits for the very same amount of 1M nets. 

You are forgetting that the strongest friend in the control plane and the data plane is indirection. 

【Chongfeng】: I agree with you, introducing IPv4 routes into IPv6 domain will increase the size of control plane, but I think this is normal, you have mentioned RFC5549/8950 several times, RFC5549/8950  also adopts new SAFI value, and specifies the extensions necessary to allow the advertising of IPv4 NLRI with a next-hop IPv6 address, herein 128-bits of next IPv6 address will be used for all IPv4 routes. My proposal is basically the same as RFC5549/8950 in terms of the scale, the difference is that my draft use IPv6 mapping prefix instead of specific next-hop IPv6 address.  In addition, my draft is about IPv6-only deployment for the network. IPv6-only will run after dual-stack as a whole. At that time, IPv6 will be the main stream, and the use of IPv4 will be less, and the overall quantity of IPv4 routes may be reduced hopefully.

Furthermore, the forwarding of IPv4 services in P routers will be based on IPv6 FIB, the size of which is 
In all cases forwarding in P routers will be based on IPv6 FIB so I do not understand why you are highlighting it here. 
[Chongfeng]:   You mentioned the cost issue before, and IPv6-only in multi-domain networks can reduce the cost of data forwarding, so I highlighted it.  BTW, What does "in all cases" here mean?


Your statement sounded like what I am describing would not be forwarded based on IPv6 FIB so I commented on it. 
【Chongfeng】:OK

[Chongfeng]:  In large-scale networks, it is not enough to achieve IPv4/IPv6 packet conversion only through local algorithmic computing. To convert an IPv4 address to an IPv6 address in PE, it needs to obtain the IPv6 address prefix of remote-end to identify the location of the IPv4 address block in the IPv6 network in advance. 
In addition, I think the/96 prefix you mentioned is about the choice of prefix length, which can be considered in the future. 


I disagree. Irrespective of network scale you can algorithmically and consistently insert a bit string into a packet. 

And the algorithm we are talking about it well know so there is no issue what so ever. 
【Chongfeng】: Can you tell me which RFC the algorithm is in? MAP-T/MAP-E?  or something else? 

I am not talking about some local domain mapping. 

Thx,
R.

Thanks!
Chongfeng