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

Hi Sue, 

Thank you for your reply, it doesn't matter for me to wait for some time.  We are very willing to receive Jeff's questions and work with him to improve the draft.

Best regards

Chongfeng

chongfeng.xie@foxmail.com

From: Susan Hares
Date: 2023-12-14 22:37
To: Chongfeng Xie; jhaas
CC: idr
Subject: RE: Re: [Idr] draft-xie-idr-mpbgp-extension-4map6 error handling considerations for 4map6 attribute
Chongfeng: 

Thank you for your patience in awaiting further details about this adoption.  As I mentioned in private email, during my discussion with Jeff Haas  on 12/1/2023,  Jeff Haas believed he had additional questions.  Jeff had holiday vacation during the week after (~12/8) – so Jeff may still be trying to get through his email queue.  

The IDR chair team (IDR chairs + secretary) meet on Friday mornings.  I’ll obtain the last status from Jeff at that time.  

If we start a new email thread to discuss points on the adoption, I’ll send a note to you on this thread. 

Cheerily, Sue 

From: Chongfeng Xie <chongfeng.xie@foxmail.com> 
Sent: Monday, November 20, 2023 9:59 PM
To: jhaas <jhaas@pfrc.org>
Cc: idr <idr@ietf.org>; Susan Hares <shares@ndzh.com>
Subject: Re: Re: [Idr] draft-xie-idr-mpbgp-extension-4map6 error handling considerations for 4map6 attribute

Hi IDR chairs,

Since the beginning IETF 118,  you IDR chairs have raised several issues or questions for  draft-xie-idr-mpbgp-extension-4map6, including those of Jeff and Sue , and we authors have tried to answer them, I wonder if our answers have clarified your concerns? Is there anything missed that needs futher clarification?

Best regards

Chongfeng  

From: Jeffrey Haas
Date: 2023-11-06 21:39
To: Robert Raszuk
CC: Chongfeng Xie; draft-xie-idr-mpbgp-extension-4map6; idr
Subject: Re: [Idr] draft-xie-idr-mpbgp-extension-4map6 error handling considerations for 4map6 attribute
Robert,

On Nov 6, 2023, at 13:31, Robert Raszuk <robert@raszuk.net> wrote:

Hi,

> However, isn't a key value of your draft that intermediate IPv6 nodes 
> that are not performing the mapping operation will use the routes for 
> forwarding purposes toward the egress?

IMO (the way I am reading this proposal) P nodes or even transit ASBRs would never need those mapping routes. Only the ingress and egress would be the consumers. 

Your interpretation while valid would result in quite severe consequences on the network design. If transit nodes are to use those mapping for forwarding simply enabling dual stack may be much more efficient solution. 

Indeed, and partly why I’m raising these points. 

— Jeff

Many thx,
Robert

On Mon, Nov 6, 2023 at 1:23 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
Chongfeng,

On Mon, Nov 06, 2023 at 06:50:56PM +0800, Chongfeng Xie wrote:
> Thank you for raising the error handling scenario, which is indeed worth considering. I think this issue is easy to handle.  At present, the SAFI in the draft is 1, but I also consider to apply for a dedicated SAFI to dea with issue. The node that receives the BGP message, i.e. the receiver, can determine based on this that this is not a regular IPv6 route. When the network filters out the 4map6 attribute, the receiver can determine that an error has occurred and not continue to transmit it. I don't know if this has answered your question? If so, we can add the considerations for this scenario in the next version.

A separate SAFI would address the error consideration below.  However, isn't
a key value of your draft that intermediate IPv6 nodes that are not
performing the mapping operation will use the routes for forwarding purposes
toward the egress?

Similarly, you're also leveraging Internet-scoped route distribution to
carry these routes.  A separate afi/safi means either all of the
intermediate networks participate, or a mesh of multihop ebgp sessions for
this mapping are created.

If you move to such a multhop mesh of ebgp sessions for distributing the
mappings, Robert's discussed point of using existing IPv4 routes with RFC 5549 
procedures and new tunnel encapsulation information to carry the map start
making more sense.

-- Jeff

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

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