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/

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.

Regards,
R.

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 <robert@raszuk.net>
> *Date:* 2023-01-17 20:07
> *To:* Chongfeng Xie <xiechf@chinatelecom.cn>
> *CC:* idr-chairs <idr-chairs@ietf.org>; idr <idr@ietf.org>; donggz
> <donggz@chinatelecom.cn>; xing <xing@cernet.edu.cn>
> *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 <xiechf@chinatelecom.cn>
>> *Date:* 2023-01-17 19:33
>> *To:* internet-drafts <internet-drafts@ietf.org>
>> *CC:* donggz <donggz@chinatelecom.cn>; xing <xing@cernet.edu.cn>;
>> idr-chairs <idr-chairs@ietf.org>
>> *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 <internet-drafts@ietf.org>
>> *Date:* 2023-01-17 19:17
>> *To:* Chongfeng Xie <xiechf@chinatelecom.cn>; Guozhen
>> <donggz@chinatelecom.cn>; Guozhen Dong <donggz@chinatelecom.cn>; Xing Li
>> <xing@cernet.edu.cn>
>> *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
>>
>