Re: [Idr] draft-xie-idr-mpbgp-extension-4map6 error handling considerations for 4map6 attribute

Hi Jeff，

For the case of attribute handling you mentioned, my feedback is as follows, 

My document mainly focuses on IPv6 deployments in multi-domain network under a single or multiple operators collaborations, which are controllable. If 4map6 attribute is filtered out, whether intentionaly or unintentionally,it will have some effect on the routing. On the receiving ingress PE, IPv4 routing cannot be instantly extracted and exists in the form of IPv6 native routing. Furthermore, the ingress PE can not find the mapping rule for  for the destination address corresponding to the IPv4 packets arriving at the ingress PE. To deal with this situation, an entity called default egress PE gateway has also been imlemented in the IPv6-only underlay framework. IPv4 packets that have not found mapping rules at the ingress PE can be forwarded to the default egress PE gateway by using the default mapping rules, which is illustrated in draft-ietf-v6ops-framework-md-ipv6only-underlay. From the pespective of network operation, In the multi-domain network scenario,  filtering out 4map6 attribute can be detected and handled, and the operator will generally correct this event. It also should be noted that, due to that network is controllable, this kind of event will not have any impact on the global Internet routing. 

In addition, this scenario you mentioned also indirectly demonstrates the necessity of 4map6 attribute in IPv6 deployment.

Best regards

Chongfeng

From: Jeffrey Haas
Date: 2023-11-06 17:58
To: draft-xie-idr-mpbgp-extension-4map6; idr
Subject: [Idr] draft-xie-idr-mpbgp-extension-4map6 error handling considerations for 4map6 attribute
Authors,

I'm reviewing the draft-xie-idr-mpbgp-extension-4map6-07. As part of my
review, I have two questions for error handling scenarios.

When the 4maps6 attribute has an error, treat-as-withdraw behavior is done.
This is reasonable!

One consideration that should be considered is what happens if, for some
reason, an IPv6 unicast route serving to carry IPv4/IPv6 mapping
advertisements has its 4map6 attribute removed/stripped.  

While BGP Path Attribute filtering is not generally recommended due to its
harm on incremental deployment of BGP features, it does happen.[1]

If the 4map6 attribute has been stripped, it's not possible to execute the
procedures appropriately on the route.  In the absence of this attribute,
it's not readily apparent that this isn't a simple 4map6 route and is only
an ipv6 unicast route for forwarding.  While this appears to be the intended
behavior in networks that are not participating in
encapsulation/decapsulation, it's problematic for the networks that need to
do this work.

What error handling would the authors recommend for this scenario?

Note that attr-set stripping considerations may also be important.

-----

Please note that I have flagged scaling and route selection considerations
in my response to Robert.  Tersely repeating them here:

1. When multiple domains are advertising the same IPv4 addresses for
encapsulation, this increases the IPv6 scaling load to carry these unique
destinations.  This has impact on the FIB and RIB.

2. The mapping database metric, when receiving IPv4 networks, does not
perform normal BGP route selection on those tunneled IPv4 networks.  I have
concerns that this has the possibility to cause issues for IPv4 forwarding,
potentially loops, because the IPv4 as-path information may not be congruent
with the IPv6 route that contains it.

The authors may wish to consider if, instead of a "mapping database" that
IPv4 BGP RIB entries are reconstructed using the tunneled IPv4 attributes
contained in the attr-set.  Then, normal route selection can be utilized. 
This was part of my motivation to suggest the feature during a previous IETF.

-- Jeff

[1] https://datatracker.ietf.org/doc/html/draft-haas-idr-bgp-attribute-escape-00#name-explicit-permit-lists-and-t

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr