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

> the tunnel should span from the ingress PE to egress PE without IPv4/IPv6
decapsualtion/encapsulation at the intermediate node

And this is EXACTLY what using combination of RFC5549 & RFC9012 allows to
do _today_.

Rgs,
R.

On Thu, Jan 19, 2023 at 4:29 AM Chongfeng Xie <xiechf@chinatelecom.cn>
wrote:

>
>
> 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 <robert@raszuk.net>
> *Date:* 2023-01-18 16:34
> *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: 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 <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
>>>
>>