IETF Logo Mail Archive

RE: Automatically connecting to stub networks...

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 03 December 2020 14:58 UTC

Return-Path: <vasilenko.eduard@huawei.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 262BA3A0D75 for <ipv6@ietfa.amsl.com>; Thu, 3 Dec 2020 06:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuOxBKy9pVzo for <ipv6@ietfa.amsl.com>; Thu, 3 Dec 2020 06:58:13 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2C63A0D6B for <6man@ietf.org>; Thu, 3 Dec 2020 06:58:12 -0800 (PST)
Received: from fraeml713-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CmzQh13Lkz67LdY for <6man@ietf.org>; Thu, 3 Dec 2020 22:55:08 +0800 (CST)
Received: from msceml701-chm.china.huawei.com (10.219.141.159) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 3 Dec 2020 15:58:09 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 3 Dec 2020 17:58:08 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2106.002; Thu, 3 Dec 2020 17:58:08 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ted Lemon <mellon@fugue.com>
CC: 6MAN <6man@ietf.org>
Subject: RE: Automatically connecting to stub networks...
Thread-Topic: Automatically connecting to stub networks...
Thread-Index: AQHWVoMEIcqKzTjvV0WEUOTb/0Lf36nmAtVggAAc+wCAADOIgP//0VcAgAAAaICAADYLEA==
Date: Thu, 03 Dec 2020 14:58:08 +0000
Message-ID: <0e27fa81f69d47219b7d7a3101fe8524@huawei.com>
References: <824E0042-44E7-4C56-8411-E917F9E22D05@fugue.com> <6C299891-EB14-47BF-92EB-22264B0C1043@fugue.com>
In-Reply-To: <6C299891-EB14-47BF-92EB-22264B0C1043@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.198.234]
Content-Type: multipart/alternative; boundary="_000_0e27fa81f69d47219b7d7a3101fe8524huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XqkiD32S0sM6Qy0q9qwocvk-G_o>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 03 Dec 2020 14:58:16 -0000

Ted,
This WG did half of the step (or ¾) to solve MHMP problem for general case.
Intentions are well specified in RFC 8028. ND, SASA and source routing for site networks are not corrected properly.
Nothing is enforced in MUST language. No one vendor has even considering to change host IP stack.

You try to specify corner case with MHMP.
It is inevitable that you have stepped into this problem.
You had no chance to pass by.
It is just the topic you chosen.
Eduard
From: Ted Lemon [mailto:mellon@fugue.com]
Sent: 3 декабря 2020 г. 17:40
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: 6MAN <6man@ietf.org>
Subject: Re: Automatically connecting to stub networks...

Oh, do you mean source address selection for hosts on the stub network?  That’sa good point.


On Dec 3, 2020, at 09:38, Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:

Eduard, you still haven’t actually describe the problem you think you see. Can you explain why source address selection matters in this case and what specifically could go wrong?


On Dec 3, 2020, at 09:31, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:

You do discuss how RFC 4191 would help.
This RFC is not needed at all if source address chosen 1st
Because after source address selection it is trivial to decide about next hop
Without any tweaking of routing tables on the host.

Hence, You stick to the current mode of host operation: next hop is decided 1st.

I agree with RFC 8028 that it should be changed.
RFC 8028 is the only comprehensive solution now for the general MHMP case.

Ed/
From: Ted Lemon [mailto:mellon@fugue.com]
Sent: 3 декабря 2020 г. 17:21
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>
Cc: 6MAN <6man@ietf.org<mailto:6man@ietf.org>>
Subject: Re: Automatically connecting to stub networks...

On Dec 3, 2020, at 5:01 AM, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
It is the very principal question what should happen 1st on the host: next hop or source address choice?

Can you explain why you think there’s a conflict here? I’m not seeing it.

v2.23.0 | Report a Bug | By Email