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

Chongfeng Xie <xiechf@chinatelecom.cn> Wed, 18 January 2023 01:30 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 E72A5C14CE3E; Tue, 17 Jan 2023 17:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 0VQagIDv8V1v; Tue, 17 Jan 2023 17:30:56 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id 69090C14F739; Tue, 17 Jan 2023 17:30:55 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.48:47978.329814179
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-122.97.174.106 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 71D2E2800C6; Wed, 18 Jan 2023 09:30:30 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([122.97.174.106]) by app0024 with ESMTP id 1318f9cebd0641ec9f05c8a7c8a36201 for robert@raszuk.net; Wed, 18 Jan 2023 09:30:53 CST
X-Transaction-ID: 1318f9cebd0641ec9f05c8a7c8a36201
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 122.97.174.106
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Wed, 18 Jan 2023 09:30:48 +0800
From: Chongfeng Xie <xiechf@chinatelecom.cn>
To: Robert Raszuk <robert@raszuk.net>
Cc: idr-chairs <idr-chairs@ietf.org>, idr <idr@ietf.org>, donggz <donggz@chinatelecom.cn>, xing <xing@cernet.edu.cn>
References: <202301171936571355178@chinatelecom.cn>, <CAOj+MMGpuK51jZo-9+DOLS7u3wX7K9RBoXzw1dO5ns-sB7Jfvw@mail.gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.23.121[cn]
Mime-Version: 1.0
Message-ID: <2023011809303660331810@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart212322137630_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-GWYj59H6IahZ8DSkLLAWL6IMSM>
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: Wed, 18 Jan 2023 01:31:00 -0000


Hi Robert,

Thank you for your comments. Please see my feedback below.

The purpose of the new draft is to support end-to-end IPv4 service delivery within and across IPv6-only domains, herein 'end-to-end' means there is no IPv4/IPv6 conversion in the middle of the data-path between the ingress and egress.   

The untilization of RFC5549 with tunnle generally use the BGP next-hop address as the tunnel endpoint address, as stated in RFC5560, "when IPv4 traffic is to be tunneled over an IPv6 backbone, it is necessary to  encode the "BGP next hop" for an IPv4 route as an IPv6 address, and vice versa.  The method for  encoding an IPv6 address as the next hop for an IPv4 route is  specified in [RFC5549]".   In multi-AS networks, the endpoints of the tunnel are PEs attached to different ASes, the PE at the remote endpoint of a tunnel is not the BGP next-hop, so the mechanism does not work in this case. This has been mentioned in RFC5560.  Another option is to setup multiple tunnels from the ingress to egress, which is not end-to-end.

The second issue is that the meachanism defined in RFC5549 does not support translation, which is another kind of IPv6-only apporach, translation-based IPv6-only approach has been deployed in mobile networks.  

The approach in the new draft decouples tunnel function from the next-hop address, there is no specific physical end-point address on PE, the tunnel endpoint address is generated dynamically by appending IPv4 address to the IPv6 mapping prefixes. In this way, the ingress PE can convert IPv4 packets into IPv6 packets and send them into IPv6-only network.  Moreover, encapsulation and translation are both supported by the MP-BGP extension defined in this draft.

Best regards
Chongfeng



 
From: Robert Raszuk
Date: 2023-01-17 20:07
To: Chongfeng Xie
CC: idr-chairs; idr; donggz; xing
Subject: Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt
Hi,

May I ask what is the point of introducing this much new complexity if encoding proposed in RFC5549 seems sufficient ? Underlay transport wise RFC5549 it can be used with Tunnel Encapsulation Attribute and the overall requirement is solved. 

Moreover RFC5549 works both within and interdomain naturally with zero additional hacks needed. 

In case of new NLRI, new attribute etc ... a lot of additional reverse translation needs to happen if one is expecting an IP transit to work. 

Thx,
Robert

On Tue, Jan 17, 2023 at 12:37 PM Chongfeng Xie <xiechf@chinatelecom.cn> wrote:

Hello, everyone, 
We have just submitted a new draft, which is about MP-BGP extension for multi-domain IPv6-only neworking. Since this is its first submission, there must be many defects in it, we look forward to receiving more comments, suggestions and even criticism.

Best regards
Chongfeng

From: Chongfeng Xie
Date: 2023-01-17 19:33
To: internet-drafts
CC: donggz; xing; idr-chairs
Subject: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt

Hello, everyone, 
We have just submitted a new draft, which is about MP-BGP extension for multi-domain IPv6-only neworking. Since this is its first submission, there must be many defects in it, we look forward to receiving more comments, suggestions and even criticism.

Best regards
Chongfeng

 
From: internet-drafts
Date: 2023-01-17 19:17
To: Chongfeng Xie; Guozhen; Guozhen Dong; Xing Li
Subject: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt
 
A new version of I-D, draft-xie-idr-mpbgp-extention-4map6-00.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.
 
Name: draft-xie-idr-mpbgp-extention-4map6
Revision: 00
Title: MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement
Document date: 2023-01-15
Group: Individual Submission
Pages: 13
URL:            https://www.ietf.org/archive/id/draft-xie-idr-mpbgp-extention-4map6-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xie-idr-mpbgp-extention-4map6/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-idr-mpbgp-extention-4map6
 
 
Abstract:
   This document defines NLRI with specific AFI/SAFI combination, a new
   BGP path attribute known as the "4map6" and a set of related
   procedures, which can be used for transferring IPv4/IPv6 address
   mapping rule to support IPv4 service delivery in multi-domain
   IPv6-only underlay networks.
 
                                                                                  
 
 
The IETF Secretariat
 
 
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr