IETF Logo Mail Archive

Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Xiejingrong <xiejingrong@huawei.com> Thu, 27 June 2019 09:15 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469E612007C; Thu, 27 Jun 2019 02:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Pq1OkykatAxB; Thu, 27 Jun 2019 02:15:22 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329CB1200CE; Thu, 27 Jun 2019 02:15:22 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 75C0E87CAD619D603122; Thu, 27 Jun 2019 10:15:20 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 10:15:19 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Jun 2019 10:15:19 +0100
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 27 Jun 2019 10:15:19 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Thu, 27 Jun 2019 17:15:09 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: "softwires@ietf.org" <softwires@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-dawra-bess-srv6-services@ietf.org" <draft-dawra-bess-srv6-services@ietf.org>
Thread-Topic: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
Thread-Index: AdUoywhLB5bsk43hQOStVculmHkjLwBd2P6AAD3Bi8D//9e/gP/+KOEAgAMxxYCAABRggIAABJkAgAABYQCAAAL9AP/+Mcjw
Date: Thu, 27 Jun 2019 09:15:08 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB8D7E66@nkgeml514-mbx.china.huawei.com>
References: <19AB2A007F56DB4E8257F949A2FB9858E5BDBB89@NKGEML515-MBS.china.huawei.com> <9DB8FCD5-DD04-4EB1-AEA5-A33B5B6F1BC4@gmx.com> <19AB2A007F56DB4E8257F949A2FB9858E5BE201C@NKGEML515-MBS.china.huawei.com> <B577834D-4010-42DF-AF28-690A1BD2A5AC@telekom.de> <16253F7987E4F346823E305D08F9115AAB8D61CE@nkgeml514-mbx.china.huawei.com> <CAOj+MMGdoi1ROTmbuFu8eXWix6JfYwO1TCPUakyOEdTU01-1zA@mail.gmail.com> <B17A6910EEDD1F45980687268941550F4D87EC92@MISOUT7MSGUSRCD.ITServices.sbc.com> <8E1E4882-7850-4BF4-82EC-82BDFE9BF408@gmail.com> <CAOj+MMGKN9drVzJgrE6WVkF6k43Vqe6TNwK9VpHpFbJTafKUdA@mail.gmail.com> <880939EA-32A0-4869-A272-0E7416DED534@gmail.com>
In-Reply-To: <880939EA-32A0-4869-A272-0E7416DED534@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB8D7E66nkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/pLV-t_tp3ZCDduZr0hBOOyHfdB8>
Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 09:15:25 -0000

Thanks for the RFC historical lessons.
--there was historically some assumption that next hop must be of the same AF as prefix.
--RFC 2858 says that Next Hop field should match AFI. On the other hand, RFC 4760 says that Next Hop Field should match combination of AFI/SAFI.
--authors of RFC 4364 were trying to make it consistent with 4760.
--Also, drafts of RFC 4364 and RFC 4760 were being developed practically at the same time period.

The problem is clear, the nexthop field has been inconsistent between different L3VPN/MVPN scenarios and different implementations in the long history.

<draft-dawra-bess-srv6-services-00> is the latest draft, but it has different nexthop in section 3.1 to 3.4, in the year 2019.

Back to my suggestion: implementation should interpret nexthop RD+IPv4 and nexthop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.

I think it may be helpful for <draft-dawra-bess-srv6-services-00> to add the above text, and update RFC4364/4659/4760/5549, to eliminate the worries about interoperation. ----is there any worries about interoperation ?

Thanks
Jingrong


From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com]
Sent: Wednesday, June 26, 2019 9:38 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: UTTARO, JAMES <ju1738@att.com>; Xiejingrong <xiejingrong@huawei.com>; softwires@ietf.org; idr@ietf.org; ian.farrer@telekom.de; bess@ietf.org; ianfarrer@gmx.com
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

Hi Robert,

Sorry, I was not so precise :-) Of course, RD part in Next Hop is not copied from RD of NLRI, but zeroed. I was trying to explain why Next Hop field in RFC 4364 and RFC 4659 has format RD:IP (VPNvX address) rather than just IP.

Thank you!

v2.23.0 | Report a Bug | By Email