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

[Chongfeng Xie <[e-mail]>]

Hi Robert,

Thank you for your comments, please see my comments inline.

 
From: Robert Raszuk
Date: 2023-01-25 18:46
To: Chongfeng Xie
CC: idr-chairs; idr; xing
Subject: Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt
Hi,
 
[Chongfeng]: Let's make a preliminary quantitative analysis, suppose the size of IPv4 BGP table of Internet is R, and that of IPv6 is S, the values of R and S are about 1M and 200k respectively now. Just from the perspective of IPv6 BGP routing, introduction of new address-family will have new cost, but from the perspective of the network as a whole, this is equal to move IPv4 reachability information into IPv6 domains by mapping, there will be no native IPv4 reachability information table in multi-domain networks anymore. 
And that is exactly one fundamental problem with your proposal. 

Assume you have PEs with attached sites which will need to connect to IPv4 Internet. So in order to provide this you will need to *DUPLICATE* entire 1M of IPv4 routes into your new SAFI so now the capacity of your control plane doubles. 

[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.  

If sites do not need to connect to the Internet there are other proposals which do not require a new BGP mapping SAFI. 

Example: 

https://datatracker.ietf.org/doc/draft-mishra-idr-v4-islands-v6-core-4pe/  ** 

** I do have concerns about language of this draft or it's place in IDR, but I am bringing it here to illustrate that what you are proposing is much heavier and complex control plane wise. 
[Chongfeng]: Can you be more specific how heavy and complex it is?  

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?


[Chongfeng]: I agree with you that it is local configuration to place mapped address as source in the outer encapsulation.  But it is not true for destination address, the creation of outer IPv6 destination address needs to get the IPv6 mapping prefix of remote end-point in advance, which needs the coordination of different nodes.
Not really. 

Destination address used as egress tunnel endpoint can be /96. So remaining bits if needed can be filled with IPv4 destination. 

IPv4 to IPv6 mapping is algorithmic and does not need to be signalled. The routing to egress will still be done based on /96. 

[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. 

That alone is highly questionable as such mapping's algorithm is well known
and each node can do the mapping by itself. All it needs to know is the
AFI/SAFI 1/1 and tunnel endpoint. There is no magic to it. This really
proves no justification to invent new SAFI for it.[Chongfeng]: Can you show which draft or RFC specifies the technology or procedure to get the mapping prefix of remote-end? 

https://www.rfc-editor.org/rfc/rfc4291 

Section 2.5.5

[Chongfeng]： Section 2.5.5 of RFC4291 is just about 2 types of IPv6 Addresses with embedded IPv4 Addresses, it does not provide any approaches to get the mapping prefix of remote-end, so it is unrelated to my draft.

[Chongfeng]：As I mentioned before, this is the first time to submit this draft, it needs more modification as usual, and we welcome any improvement, including optimizing the cost, etc. I also hope to receive more suggestions from you.


Regards,
R.


Thanks
Chongfeng