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

<ian.farrer@telekom.de> Thu, 27 June 2019 12:15 UTC

Return-Path: <ian.farrer@telekom.de>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D14120026; Thu, 27 Jun 2019 05:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.297
X-Spam-Level:
X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 gg6y2QXAyL0Z; Thu, 27 Jun 2019 05:15:35 -0700 (PDT)
Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 6D55D120273; Thu, 27 Jun 2019 05:15:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1561637732; x=1593173732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XvmEhvQ0+cQdS7diL/cbiGDtHs9bP3HC6jiD/OTaJbU=; b=4nzs34a6P3VXbhiUiDqPGG5kk3rRDNJpv+zQZiPTqC4XKGp2HNgMDpsq /zdDneSPPztQw77p8y5sbClvz+LmEIehLUOGsowRTXdAWxUt9T93FEfwc rhkqWlfnjhzfj3blOt+YtJet1DCM7Az4HWNGN8bqv1te/XbCYDSAjiqLF VpfWpS3B/nTkhUu8Amm0r6dklL4TfTaYjRUhR6PhEUeABHIKhM9Sreaya b246oL9dcWoa1wXl6nQVY0SUFWHv087hkh+qiBP/f/Ct4aDuRgzMBbafW 1RskstyH+wwWzkLRVXyyIzgLRk964RTkNSBmwLWJRbV1NXd+SeS/WDwJ0 g==;
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2019 14:15:27 +0200
X-IronPort-AV: E=Sophos;i="5.63,423,1557180000"; d="scan'208,217";a="312757957"
X-MGA-submission: MDHBe5rPbbMGavPa8F2biOA3qGxLybnzZCKHqRrS/eCvLKQlicdOe5oUw8H5hNZo7RyFnUqC1KmmfNKqbtrq1QbVTalungS0Kl/2QK8Ey6TeK/RMrGTQLsTubMBEQmpW65jQFMEoVPbwu07jBabFsQr/SqyMJc4nzdLewA2dbkCy5Q==
Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 27 Jun 2019 14:15:24 +0200
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 14:15:23 +0200
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Jun 2019 14:15:23 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.20) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 14:15:21 +0200
Received: from LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE (10.158.164.14) by LEXPR01MB1261.DEUPRD01.PROD.OUTLOOK.DE (10.158.165.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 12:15:23 +0000
Received: from LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE ([fe80::70a5:6b2d:cf8e:10f6]) by LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE ([fe80::70a5:6b2d:cf8e:10f6%2]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 12:15:22 +0000
From: ian.farrer@telekom.de
To: rraszuk@gmail.com, zhuangshunwan@huawei.com
CC: idr@ietf.org, alexander.okonnikov@gmail.com, softwires@ietf.org, martin.vigoureux@nokia.com, bess@ietf.org
Thread-Topic: [Softwires] [bess] [Idr] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
Thread-Index: AQHVLN7937Yo0nHTL0mZVXP0NfpWdaavi8UA
Date: Thu, 27 Jun 2019 12:15:22 +0000
Message-ID: <59FA961E-4B3B-4B74-8750-7436D29E9295@telekom.de>
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> <16253F7987E4F346823E305D08F9115AAB8D7E66@nkgeml514-mbx.china.huawei.com> <9670cbbf-9b35-7ac4-b809-529ab59f18a9@nokia.com> <19AB2A007F56DB4E8257F949A2FB9858E5BE4DA2@NKGEML515-MBS.china.huawei.com> <CA+b+ER=5oZy7TsY+UNp7x+obCu4P+XCrnpgCLXh=Cn9Pr_uW0g@mail.gmail.com>
In-Reply-To: <CA+b+ER=5oZy7TsY+UNp7x+obCu4P+XCrnpgCLXh=Cn9Pr_uW0g@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.b.190609
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.farrer@telekom.de;
x-originating-ip: [2003:1c09:21:c00:d1a5:f70a:6e79:7ed4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 75609a83-7385-424f-ceba-08d6faf9211b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEXPR01MB1261;
x-ms-traffictypediagnostic: LEXPR01MB1261:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <LEXPR01MB1261C2303C3CC33CBB23775CFCFD0@LEXPR01MB1261.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 008184426E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(346002)(136003)(396003)(13464003)(53754006)(199004)(189003)(51914003)(33656002)(52396003)(76176011)(36756003)(229853002)(606006)(7736002)(476003)(486006)(75402003)(8936002)(74482002)(2616005)(4326008)(66574012)(68736007)(6246003)(54906003)(316002)(6306002)(54896002)(236005)(58126008)(2906002)(81166006)(81156014)(110136005)(478600001)(102836004)(53936002)(14454004)(8676002)(53546011)(5660300002)(966005)(71200400001)(76116006)(86362001)(73956011)(14444005)(256004)(46003)(71190400001)(446003)(6116002)(64756008)(66446008)(66556008)(66946007)(186003)(11346002)(66476007)(518174003); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB1261; H:LEXPR01MB0189.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4AGJCMToa/m+bGI49F7j39vlwlfAHiazwFFgpkLhB2BpBlIiTa7mCW6UzBgT7WMhwO3EBGSGeHgIzXEFAImX9x/RGS5Z+8SxOEAlNm4nFaXWFBmbp/jKeS3aKekzHWcL4DCCkUf6eymyxNNuUSsuK6hnwh/HdCYdjiKuib9CmbicNV2lxZJnCgQ5waFJpsF7nU0Er9Gyj3nFhDhhmNGshIArNq3bWZogUvUjvB4cWvr1DWqrwSGyrV7TEQkzcnAnpLPm/gobvg4m3vAR/s2ZbvCZpVvZ2E6UlVrrpHFFcN1K+tUrAZIk4Q3n/jxgNpQ3gDphd8ZdO3o/uRAYX5T+RSuo8JSvu/qZYHYeYQOYV8365MmiT8yk0+6/XfnH4l0itF1SC/WxGoxcMzZCVk5M1CcCJktxTa4xJpbSdq9Iw10=
Content-Type: multipart/alternative; boundary="_000_59FA961E4B3B4B7487507436D29E9295telekomde_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 75609a83-7385-424f-ceba-08d6faf9211b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 12:15:22.8304 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ian.farrer@telekom.de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB1261
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cv5pFx2hAH9sssgDPnGIwwy29HA>
Subject: Re: [Idr] [Softwires] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 12:15:40 -0000

Hi,

(co-chair hat off)

I also vote to reject this erratum on the following grounds: The erratum text was raised as:

Section 6.2 says:
Length of Next Hop Network Address = 16 (or 32)
It should say:
Length of Next Hop Network Address = 24 (or 48)
Notes:
The lengths should include the RD length also, right ?

However, RFC5549 specifies in several places that the next-hop address is of type IPv6 address (Sections 3, 4, 6.1 and 6.2). The use of an IPv6 address as the next hop was clearly the intention of the author and the document was reviewed and published as such. The existing text in section 6.2 (Length of Next Hop Network Address = 16 (or 32)) is consistent with this and changing it as proposed in the would only introduce an inconsistency.

Thanks,
Ian

From: Softwires <softwires-bounces@ietf.org> on behalf of Robert Raszuk <rraszuk@gmail.com>
Date: Thursday, 27. June 2019 at 13:53
To: Zhuangshunwan <zhuangshunwan@huawei.com>
Cc: "idr@ietf.org" <idr@ietf.org>, Alexander Okonnikov <alexander.okonnikov@gmail.com>, "softwires@ietf.org" <softwires@ietf.org>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [Softwires] [bess] [Idr] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549


My vote - Reject.

Justification:

Irrespective if we would reject or accept the erratum implementations must be able to handle 10 years old RFC so must be able to properly recognize the next hop to be either of length 16 or 24. (I am putting aside the 32/48 invention)..

So that means that next hop length should be used to recognize format of the next hop. That with the fact that stuffing next hop address with useless 64 zeros in the front leads me to believe that if we are to produce any erratums it should be the other way around ... we should replace all documents which call for having next hops full of zeros in the front to normalize it to consist of just real IPv4 or IPv6 single address.

Thx,
R.

On Thu, Jun 27, 2019 at 1:39 PM Zhuangshunwan <zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>> wrote:
Hi all,

Can the WG reach a conclusion on how to treat that erratum related to RFC5549:

https://www.rfc-editor.org/errata/eid5253

Thanks,
Shunwan

-----Original Message-----
From: Softwires [mailto:softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org>] On Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Thursday, June 27, 2019 6:37 PM
To: Xiejingrong <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>; Alexander Okonnikov <alexander.okonnikov@gmail.com<mailto:alexander.okonnikov@gmail.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: softwires@ietf.org<mailto:softwires@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

since we are discussing that topic,

maybe the WG would like to reach a conclusion on how to treat that erratum:
http://www.rfc-editor.org/errata/eid5738

Thanks
-m

Le 2019-06-27 à 11:15, Xiejingrong a écrit :
> 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<mailto:alexander.okonnikov@gmail.com>]
> *Sent:* Wednesday, June 26, 2019 9:38 PM
> *To:* Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> *Cc:* UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>>; Xiejingrong
> <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>; softwires@ietf.org<mailto:softwires@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>;
> ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>; bess@ietf.org<mailto:bess@ietf.org>; ianfarrer@gmx.com<mailto: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!
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org<mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess