Re: [v6ops] WG Call For Adoption: draft-xie-v6ops-framework-md-ipv6only-underlay-05

[Eduard Metz <[e-mail]>]

Support adoption of this draft, some review comments below.

cheers,
  Eduard

General
I interpreted the document as a framework for transport / transit networks,
based e.g on Figure 1. Section 7, case 2 however describes the integration
with a transition mechanism at the UE/CPE. I would think these are
decoupled and integration is an (optional) optimization, but not
necessarily an integral component of the framework. Also some requirements
are towards integration.

What use-case is (or multiple) are being targeted with the framework? I
still assume it is transport, in which case I would suggest a decoupling
from CPE/UE based mechanisms and maybe have a separate chapter on
optimization regarding / integration with common IPv4aaS  and IPv6
transition mechanisms.


Terminology
Not all terminology is explained / abbreviations are expanded, for example:
- IPv6 underlay; what is meant with this?
- ADPT; described but not expanded? Seems to be introduced in this document?


Introduction
"This document does not introduce any new IPv6 transition mechanisms nor
 IPv4aaS".
Doesn't the multi-domain solution described in the document constitute a
new solution?

Section 4
"Therefore, there is an urgent need for multi-domain IPv6-only solution
..".
I assume the framework/solution described also applies to single domain?

Section 5
Requirement 1: beneficial to wider IPv6 adoption
Reduction of IPv4 address consumption is not a requirement for this
specific case I assume, ease the introduction of IPv6 is.

Requirement 3: optimized end-to-end
“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.”
Should this state “no IPv6-IPv4” conversion? (instead of IPv4-IPv6?)

Also, is the UE/CPE in scope? According to figure 1 it is not?

Requirement 4: support of double translation and encapsulation
There appears to be a lot of “solution description” in this requirement.
Is the requirement to have conversion functions only at the edge and to
have a single solution/concept for encapsulation and translation?

Section 6.2.3:
“Multi-domain IPv6-only networks need to support both translation and
encapsulation technologies for IPv4 data delivery”
At the ingess/egress also an IPv4 forwarding function is needed to forward
to the right egress network node (via encap / mapping) or right interface
towards an external network.

Section 7
I understood case 1 to be the scope of this framework, case 2 to me defines
a different scope.


On Fri, Nov 18, 2022 at 10:54 PM Ron Bonica <rbonica=
[e-mail]> wrote:

> Folks,
>
>
>
> This message initiates a WG call for adoption for
> draft-xie-v6ops-framework-md-ipv6only-underlay-05. To accommodate the
> American holiday, the call for adoption will end on December 9, 2022.
>
>
>
>                                                        Ron
>
>
>
> Juniper Business Use Only
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>