Re: MSR6 BOF 1st Issue Category: What is the meaning of “native IPv6"

Yisong Liu <liuyisong@chinamobile.com> Wed, 28 September 2022 08:04 UTC

Return-Path: <liuyisong@chinamobile.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CBCC152718; Wed, 28 Sep 2022 01:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 oktE-yfAFnjU; Wed, 28 Sep 2022 01:04:24 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id DC0FDC152715; Wed, 28 Sep 2022 01:04:22 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee363340004ab4-16343; Wed, 28 Sep 2022 16:04:21 +0800 (CST)
X-RM-TRANSID: 2ee363340004ab4-16343
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCCPC (unknown[223.104.39.50]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee163340003790-c1d8f; Wed, 28 Sep 2022 16:04:20 +0800 (CST)
X-RM-TRANSID: 2ee163340003790-c1d8f
From: Yisong Liu <liuyisong@chinamobile.com>
To: joel.halpern@ericsson.com
Cc: msr6@ietf.org, ipv6@ietf.org, gjshep@gmail.com, gregimirsky@gmail.com
References:
In-Reply-To:
Subject: Re: MSR6 BOF 1st Issue Category: What is the meaning of “native IPv6"
Date: Wed, 28 Sep 2022 16:04:18 +0800
Message-ID: <013301d8d310$e9c79be0$bd56d3a0$@chinamobile.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01D8D353.F7EC3B70"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdjTCz0qyt9yCaXaTAG0+7g+TIZomg==
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O-KuAahl1aXi3RW8xoErbTqT_mU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2022 08:04:30 -0000

Hi Joel,

 

Thanks for your response!

To your further question: “Your descriptions here do not explain why using
a new routing header is better than using BIER, or any of the other
approaches that are being proposed for enhancing multicast handling.  It
still requires that the replication devices be enhanced with new forwarding
plane capabilities.” Here is some response:

MSR6 is a stateless multicast based on IPv6 data plane by using explicit
encoding the destination nodes and optionally the intermediate nodes along
the path to these destination nodes in the IPv6 extension header(s). MSR6 is
designed for SP or network domain which uses IPv6 rather than MPLS or other
data plane.

Besides the MSR6-TE case, here are the core benefits comparing to the BIER
work.: 

1.  Allocation and management of IPv6 addresses. 

2.  Simplify the Service identifier by using IPv6 address without further
requiring VXLAN/GENEVE

3.  Securing the Service Provider network based on the IPv6 address
management mentioned above. 

4.  Reusing IPv6 extension header and the corresponding function, e.g.,
ESP;

All these benefits coming from building on IPv6 data plane, and re-using the
architecture of SRv6. And the benefits have already been discussed and
agreed (in some degree especially with the SP who are willing to deploy
IPv6) in SRv6 .

 

Best Regards

Yisong Liu

 

发件人: Yisong Liu <liuyisong@chinamobile.com> 
发送时间: 2022年9月21日 15:49
收件人: 'msr6@ietf.org' <msr6@ietf.org>
抄送: 'ipv6@ietf.org' <ipv6@ietf.org>; 'gjshep@gmail.com'
<gjshep@gmail.com>; 'gregimirsky@gmail.com' <gregimirsky@gmail.com>;
'joel.halpern@ericsson.com' <joel.halpern@ericsson.com>
主题: MSR6 BOF 1st Issue Category: What is the meaning of “native IPv6"

 

Hi all

 

Here are the responses for the 1st Issue Category: What is the meaning of
“native IPv6”?, including issue 1-3.

 

 <https://github.com/MSR6-community/MSR6-Issue-List/issues/1> What do you
mean by native IPv6? #1 

[Response] We use native IPv6 to describe IPv6 packet running on some media
(or data-link layer). E.g., RFC2529 mentions “native IPv6 over most media /
ATM” and “IPv6 over IPv4 tunnels” , the latter is treated as opposite
concept of “native IPv6”.It is also mentioned in the discussion: “if you
are using new forwarding information, this is not native. Putting multicast
forwarding information in an IPv6 EH is not native”. IPv6 EH brings extra
forwarding behavior, and it is explained in the next response.

 

 <https://github.com/MSR6-community/MSR6-Issue-List/issues/2> What is
alternative to native IPv6? IPv6 includes IPv6 EH and SRv6? #2

[Response] As in the answer to issue #1, the alternative to native IPv6 is
IPv6 over some kind of tunnel. E.g, IPv6 over IPv4 tunnel, or IPv6 over MPLS
tunnel. In our understanding, IPv6 header and IPv6 header with EH, as SRv6,
both belong to “native IPv6”, as long as it is not running over some
tunnel. E.g., RFC8200 says, “The changes from IPv4 to IPv6 fall primarily
into the following categories ... Improved Support for Extensions and
Options.”

 

 <https://github.com/MSR6-community/MSR6-Issue-List/issues/3> Don’t like
hearing this is called “native IPv6”. Because this also involves a
different encapsulation and is not existing IPv6 encapsulation and parse
process #3

[Response] Yes, MSR6 also involves encapsulating an original multicast
packet into an IPv6 header with an extension header. As the response in the
previous 2 questions, we think it is in the scope of “native IPv6”, over
no tunnel .If people still have any concern of using “native IPv6”, maybe
we could consider to modify the term to for example “ solution based on
IPv6 data plane” ?

 

If you have further comments, please let us know.

 

 

Best Regards

Yisong Liu