Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt
Chongfeng Xie <xiechf@chinatelecom.cn> Thu, 19 January 2023 03:29 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 D9A8CC1524A4; Wed, 18 Jan 2023 19:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 D-bTW_VxWvu6; Wed, 18 Jan 2023 19:29:41 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id 531E4C1522D5; Wed, 18 Jan 2023 19:29:40 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.48:41684.996091576
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-117.37.71.12 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id E7D9A2800E6; Thu, 19 Jan 2023 11:29:28 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([117.37.71.12]) by app0024 with ESMTP id 4bdb59c703534fbea01a82f6b75568b2 for robert@raszuk.net; Thu, 19 Jan 2023 11:29:31 CST
X-Transaction-ID: 4bdb59c703534fbea01a82f6b75568b2
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 117.37.71.12
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Thu, 19 Jan 2023 11:29:29 +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>, <2023011809303660331810@chinatelecom.cn>, <CAOj+MMGgmkjJegJs0ONDvLG0WUZO98Mz988oDQsEsb-hwf8M1Q@mail.gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.23.121[cn]
Mime-Version: 1.0
Message-ID: <2023011911292890875314@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart382121245752_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0DHAMXvpFLCBGwe53zXX47ozfmM>
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: Thu, 19 Jan 2023 03:29:44 -0000
Hi Robert, Thank you for your feedback, The new subject draft is related to draft-ietf-v6ops-framework-md-ipv6only-underlay From the perspective of network operation, IPv4 service delivery over IPv6-only multi-domain networks should be end-to-end. Take the encapsulation as an example, the tunnel should span from the ingress PE to egress PE without IPv4/IPv6 decapsualtion/encapsulation at the intermediate node, because excessive IPv4-IPv6 conversion in the network will lead to complexity of network and CAPEX increasing. . This has been illustrated in section 4 of draft-ietf-v6ops-framework-md-ipv6only-underlay. In addition,it should be compatible to both encapsulation and translation. however, this draft is not to define a new encapsulation or translation protocol. please see my feedback inline, xiechf@chinatelecom.cn From: Robert Raszuk Date: 2023-01-18 16:34 To: Chongfeng Xie CC: idr-chairs; idr; donggz; xing Subject: Re: Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt Hi, > The untilization of RFC5549 with tunnle generally use the BGP next-hop address as the tunnel endpoint address, And that is why I specifically hinted for use of Tunnel Encapsulation Attribute: https://datatracker.ietf.org/doc/rfc9012/ [Chongfeng]: Some existing mechanisms, such as RFC5560 and RFC5549, use BGP next-hop address as the tunnl end-point, as stated in section 1.3 of RFC9012, "In order for R1 to encapsulate P for transport to R2, R1 must know what encapsulation protocol to use for transporting different sorts of packets to R2. R2 is the BGP-next hop router". For a given IPv4 BGP update, the next-hop address change hop-by-hop. When the tunnel end point is binded to BGP next-hop address, the outer IPv6 address may change hop-by-hop, which is equal to IPv4/IPv6 decapsualtion/encapsulation at the intermediate node, that's not we want. I see nothing in the subject draft nor in your reply which would be missing to accomplish required service by using a combination of RFC5549 & RFC9012. [Chongfeng]: Another issue with the combination of RFC5549 & RFC9012 is that it does not support translation. Translation mechanism such as stateless NAT64 has been widely implemented in user's devices and operated by large-scale operators. IPv6-only mechanism at the multi-domain transit core should consider this scenario, that's another reason we put forward this draft. Regards, R. [Chongfeng]: I don't know wheter I have answered your concerns. We can continue to discuss. Best regards Chongfeng On Wed, Jan 18, 2023 at 2:30 AM Chongfeng Xie <xiechf@chinatelecom.cn> wrote: 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
- [Idr] Fw: Re: New Version Notification for draft-… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Gyan Mishra
- Re: [Idr] Fw: Re: New Version Notification for dr… Gyan Mishra
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie
- [Idr] Fw: Re: New Version Notification for draft-… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie
- Re: [Idr] Fw: Re: New Version Notification for dr… Xiejingrong (Jingrong)
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Xiejingrong (Jingrong)
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Xiejingrong (Jingrong)
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Jeffrey Haas
- Re: [Idr] Fw: Re: New Version Notification for dr… Robert Raszuk
- Re: [Idr] Fw: Re: New Version Notification for dr… Richard Huang
- Re: [Idr] Fw: Re: New Version Notification for dr… Jeffrey Haas
- Re: [Idr] Fw: Re: New Version Notification for dr… Chongfeng Xie