Re: [v6ops] I-D Action: draft-ietf-v6ops-framework-md-ipv6only-underlay-01.txt

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Chongfeng and authors,

This document says the following in rev-01:  “At the ingress/egress an IPv4 forwarding function is needed to forward to the right egress network node (via encapsulation / translation) or right interface towards an external network.”

I don’t understand why “IPv4 forwarding function” is suitable for “egress” node.

Suppose a topology { CE1---->PE1---->P---->PE2---->CE2 } and a packet is originated from CE1 to CE2 (and thus PE1 is ingress PE and PE2 is egress PE to this packet flying):
--PE1 is receiving an IPv4 packet ,and thus “IPv4 forwarding function” is the overall behavior it executes, no matter the 4-6-4 translation or 4over6 encapsulation.
--PE2 is receiving an IPv6 packet, and thus the behavior it executes should not be called “IPv4 forwarding function”, but instead, should be called “IPv6 forwarding function” ?


Given this, I would further consider that, one 4map6 rule may need to be divided into 2 unidirectional rules,  because of the difference between the ingress and egress nodes. Explained below (only considering the translation of DA):
--PE1 is receiving an IPv4 packet from CE1, it executes an IPv4 FIB lookup on IPv4 DA, matches an FIB4 entry (IPv4 DA Covering Prefix), and gets the (IPv6 DA Covering Prefix), but there may be multiple (IPv6 DA Covering Prefix)!
--PE2 is receiving the IPv6 packet from PE1, it executes an IPv6 lookup on IPv6 DA, matches an FIB6 entry (IPv6 DA Covering Prefix), and gets the (IPv4 DA Covering Prefix), but there may be only one (IPv4 DA Covering Prefix)!
--The reason why there may be multiple (IPv6 DA Covering Prefix) mapped to a single (IPv4 DA Covering Prefix) is that, the (IPv4 DA Covering Prefix) advertised by PE2 may also be advertised by PE2b in multi-home case.


The above-mentioned division of one bidirectional mapping rule to 2 unidirectional rules may also impact the control-plane,
because PE2 and PE2b will need to advertise 2 unidirectional rules, one using the IPv4 DA Covering Prefix as KEY (NLRI), and the other one using the IPv6 DA Covering Prefix as KEY (NLRI).


Thanks,
Jingrong


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: v6ops [mailto:[e-mail]] On Behalf Of Chongfeng Xie
Sent: Saturday, February 4, 2023 7:54 AM
To: list <[e-mail]>; V6Ops-Chairs <[e-mail]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-framework-md-ipv6only-underlay-01.txt


Hi folks,
We have submitted a new version of this draft. During the call for adoption process, many comments have been received, we really appreciate that, most of them has been accepted and revisions have been made as below,

1）Nits fixed
- s/considerations with security/security considerations/
- s/As per 2022/As of 2022/
- s/when IPv6 usage is being the dominant/when IPv6 usage is dominant/
- s/should not succeed two/should not exceed two/
- s/transporation/transport
- s/Addtess/Address
- s/Specificially/Specifically
- s/User-ralated/ User-related

2) Two terms are optimized as below,
RM-->RP (Rule Processing Layer)
RP--> RT (Rule Transport Layer)

3）In order to be shorter, the header title has been changed to “Multi-domain IPv6-only Underlay”.

4) The following terms has been expanded on first use,
    - eBGP
    - XLAT
    - CLAT
    - PLAT
    - AFBR
     -ASBR

5) The following terms have been modified,
Cloud-data center-->Data center
VM-->instance
IPv6 transfer capability--> IPv6 forwarding capability

5) Integration with a transition mechanism at the UE/CPE has been put in a separate section, i.e., section 7.

6)The term “IPv4-IPv6” in the following statement has been changed to “IPv6-IPv4”.

 “From UE to egress, the packets of IPv4 service can be translated (or encapsulated) into IPv6 packets within the UE or CPE, and there should be no IPv4-IPv6 conversion before they reach the egress of the network.”

7) The following sentence is added in section 5.
“At the ingress/egress an IPv4 forwarding function is needed to forward to the right egress network node (via encapsulation / translation) or right interface towards an external network.”

8) The format of IPv4-Embedded IPv6 address in section 6.1 has been corrected, an example of the new format is 2001:db8:100::192.0.2.33.

9) In section 2, “underlay” is added to the definition of IPv6-only network.

Thank you for your support during the past, we are looking forward to receiving more comments and suggestions in the way ahead.

Best regards
Chongfeng
on behalf of all the co-authors

________________________________
[e-mail]<mailto:[e-mail]>

From: internet-drafts<mailto:[e-mail]>
Date: 2023-02-04 07:48
To: [e-mail]<mailto:[e-mail]>
CC: v6ops<mailto:[e-mail]>
Subject: [v6ops] I-D Action: draft-ietf-v6ops-framework-md-ipv6only-underlay-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Framework of Multi-domain IPv6-only Underlay Networks and IPv4-as-a-Service
        Authors         : Chongfeng Xie
                          Chenhao Ma
                          Xing Li
                          Gyan Mishra
                          Mohamed Boucadair
                          Thomas Graf
  Filename        : draft-ietf-v6ops-framework-md-ipv6only-underlay-01.txt
  Pages           : 23
  Date            : 2023-02-03

Abstract:
   For the IPv6 transition, dual-stack deployments require both IPv4 and
   IPv6 forwarding capabilities to be deployed in parallel.  IPv6-only
   is considered as the ultimate stage where only IPv6 bearer
   capabilities are used while ensuring global reachability for both
   IPv6 and IPv4 service(usually known as IPv4aaS).  This document
   proposes a general framework for deploying IPv6-only in multi-domain
   underlay networks.  It discusses the requirements of service traffic,
   major components and interfaces, IPv6 mapping prefix allocation,
   typical procedures for service delivery.  The document also discusses
   related security considerations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-framework-md-ipv6only-underlay-01

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-v6ops-framework-md-ipv6only-underlay-01


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops