Re: [Idr] Please discuss the use cases for draft-xie-idr-mpbgp-extention-4map6

[Jeffrey Haas <[e-mail]>]

Chongfeng,


> On Jan 26, 2024, at 12:52 AM, Chongfeng Xie <[e-mail]> wrote:
> Thank you for your comments, suggestions and questions. Based on your suggestions, I’d like to make some revisions to the draft as below,
> 
> 1) P router does not need to do route selection and the term of Distance metric is removed.

This will be quite helpful in making incremental deployment of the feature safer.

> 2) The IPv4 prefix will be given only one IPv6 mapping prefix (Network Specific Prefix) in IPv6 network and advertised in a mapping route.
> 3) The approach in the draft mainly focuses on controlled environment, for instance, the network of one carrier.

These clarifications will significantly address the scalability concerns and help readers of the document better understand the scope of the proposal.

>  
>> Scaling Considerations:
> 
>  
> 
> [Chongfeng]:  This draft proposes to map the IPv4 BGP route to the BGP route of IPv6 networks for transmission, that is called IPv6 mapping route, as you mentioned earlier, the prefix of NLRI is composed of IPv6 mapping prefix, denoted by M6, and IPv4 Network, denoted by N4. With this structure, M6 can identify the position of IPv4 network N4 at the edge of IPv6 network. 
> 
> Based on your suggestion, the proposal will be changed that the IPv4 prefix will be given ONLY one IPv6 mapping prefix for its advertisement in IPv6 network, even if it may be advertised by multiple PEs from difference places. We can discuss its implementation and feasibility based on the types of PE in actual networks, the devices at the edge of the operator's network can be divided into two types. 

It's less critical that the proposal change to support exactly one mapping prefix and more that the considerations when more than one such prefix is in use is understood.

draft-ietf-v6ops-framework-md-ipv6only-underlay helps us understand that two possible scenarios are the well-known-prefix and the network-specific-prefix.  If the common use case is the WKP scenario, that can help address scaling considerations.  Discussing WKP in multi-provider scenarios might be good text to add in the document if this is the direction the proposal goes.

> 
> One is the edge devices that are not interconnected with the external IPv4 network. They are configured with the operator's own IPv4 address block, such as BNG, and assigning an IPv6 address mapping prefix identify the location of the IPv4 network at the edge of the IPv6 network, generally, one mapping prefix for each IPv4 network is ok.  

For such situations, it seemed that NSP mode would be fine.  However, this highlights the cases where more than one service provider provides a mapping for that IPv4 address block under a different NSP.  This could be a misconfiguration.  This could be a hijack.

For situations that resemble hijacks, technologies such as RPKI origin validation or IRR filtering are able to help prevent this.  Applying such technologies to the proposed mapping mechanism would mean that BGP prefix policy would need to be able to be applied to the embedded IPv4 networks.  Currently such technologies don't exist as they would require all routers that desire to do such filtering to be able to parse the proposed mapped NLRI format.

I realize your intended deployment scenario is a small closed network of cooperating providers.  However, it is necessary to also analyze how the general IPv6 Internet would react to such routes if they either accidentally leave the closed network, or were intentionally injected as a hijacking mechanism.
> 
> Another type is router devices that are interconnected with the external IPv4 Internet, such as CRs, and there are usually multiple CRs in the network, distributed in different geographical locations. As CR devices receive IPv4 routing of N4 and announce it to the IPv6 network after mapping, they need to be assigned an IPv6 mapping prefix. It is recommended that all CRs share the same IPv6 mapping prefix, so that regardless of which CRs announce N4 to the IPv6 network, the prefixes of the NLRI they generate are the same, and the advantage of this is that IPv6 routers can select and transmit according to conventional IPv6 routing methods, such as combining next-hop information. 
> 
> When each IPv4 network uses only one IPv6 mapping prefix in the network, the RIB table of IPv6 will not expand, and the scalability issue will be solved.

I agree!

> FIB Implications:
>  
>> One interpretation of this sentence is it is your intent that when a IPv6
>> BGP Speaker receives a mapping prefix, perhaps identified by having the
>> 4map6 Path Attribute, that it should not install that IPv6/unicast NLRI in
>> the FIB.  Is that your intent?
> 
> [Chongfeng]: Yes, the R router should not install that IPv6/unicast NLRI in the FIB.
>  
>> If so, there are two issues with this desired procedure:
>> 1. Only routers that understand this feature would be able to perform the
>>    optimization to avoid installing the mapping prefix into its IPv6 FIB.
>> 2. As we had discussed in our previous emails, if the 4map6 Path Attribute
>>    were accidentally (or intentionally) removed, IPv6 FIB resources would be used.
>>  
>> It should be noted that many routers currently size the space of their IPv4
>> and IPv6 FIBs differently.  Significant redistribution of IPv4 Internet into
>> this mechanism can result in IPv6 FIB exhaustion.  If more than one service
>> provider distributes mapping prefixes for the same IPv4 networks, this issue
>> is compounded.
>>  
>> This is perhaps not the expected operational model or impact.  If that's the
>> case, some text emphasizing the scaling considerations may be helpful.
>> (If it hurts, don't do that!)
> 
> [Chongfeng]: This problem can be solved in two ways, one is through operational means. As the IPv6 prefix of NLRI generated through mapping is longer than that of regular IPv6 routes, the sum of the lengths of M6len and N4len is generally greater than 64. But in IPv6 BGP routing of carrier network, the prefix of NLRI is required to be less than a certain length, such as 48 bits. If a device that does not recognize this attribute or the attribute is accidentally lost, the router can filter it out or reject it. Another approach is to apply for a specific SAFI value for the approach in this draft, which is more conducive to the correct identification and judgment of routers. This proposal has been discussed before.

I understand your desired operational model.

For a closed network of cooperating providers, the IPv6 mapping prefix/prefixes can be provisioned to not be installed in the FIB of participating routers.  

For routers that aren't intentionally participating in this mechanism, perhaps via routing leak, or routers that do not have this FIB install rule, scaling may be impacted.  It would be good to call out this case operationally if the mechanism remains in its current form.

If we are willing to consider a new SAFI, this does create opportunities for safer procedures.  As we discussed in-person at IETF 118, if the deployment model is able to change from not having the mapping routes distributed in the existing IPv6/unicast Internet routes, we can consider other options.  In particular, instead of overloading the IPv6 format of the NLRI, the new SAFI could use IPv4 NLRI and carry the IPv6 mapping prefix as an attribute wholly.  Perhaps instead of needing a new path attribute, the mapping prefix can be included in the existing Tunnel Encapsulation Attribute.

The primary impact of moving to a new SAFI is that distribution of mapping prefixes ceases to be done on a hop-by-hop basis.  However, since the use case is "tunnel across the IPv6 forwarding infrastructure", very little changes in the forwarding portion of the proposal.

 
>> Route Selection and Route Propagation Considerations:
>>  
>> I suspect Section 3.3 needs to be deleted, but that depends if my
>> understanding of your intent in the next sections is correct.
> 
> [Chongfeng]: I agree, Section 3.3 will be deleted in the next version.
This removes a significant concern of the proposal.  Thanks.

>> The draft then says:
>>  
>> "Advertise the updated content of the entry found in the form of
>> MP_REACH_NLRI update information to IPv6 peer routers."
>>  
>> If I am understanding this correctly, your intention is that the receiving
>> BGP Speaker only will propagate BGP Routes that are the best entry in the
>> mapping database.  Is this correct?
> 
> [Chongfeng]: I will change this part. In IPv6 network BGP routes for a given IPv6 mapping prefix have not major difference to that of native IPv6 route, I think this can follow the typical BGP process of native IPv6 routes, in addition, "route selection" in P router will be removed.  
Again, this removes a significant concern of the proposal. Thanks.

> [Chongfeng]: I will change this procedure, we will not use the mapping database entry selection. When P router receives a mapping route, it processes it in the way same to that of native IPv6 routing, The metric distance is not used for route selection any longer, this term will be deleted from the draft as well.

> [Chongfeng]: Although this is a management and operational issue, for operators, it is important to promptly identify and resolve this issue to avoid any impact on the external IPv6 Internet. But if it does happen, due to its use of longer NLRI Prefix, the general purpose BGP router will filter out these routing advertisements.

In the well-known-prefix form of the proposal, it becomes very easy for operators to understand common practice for filtering such routes.

For the other cases, while very long prefix lengths are often good reasons to filter routes, there is no guarantee that such practices are consistently implemented right now.  Additionally, other clever protocol developers may wish to have other reasons for longer routes.  For example, SRv6 use cases.
> Again thank you so much for raising so many questions and comments. Even though I have tried to answer them, I am not sure whether I have completely understood all of them and given adequate and reasonable feedback, if not, please raise them and we can continue our discussion.
I understand your answers and look forward to reviewing the next iteration of the proposal.

-- Jeff