Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
Xiejingrong <xiejingrong@huawei.com> Thu, 27 June 2019 11:22 UTC
Return-Path: <xiejingrong@huawei.com>
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 3EB091200B8; Thu, 27 Jun 2019 04:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1sv71L7d1i_C; Thu, 27 Jun 2019 04:22:42 -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 F0E57120043; Thu, 27 Jun 2019 04:22:41 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8CBBF83DF73F22AC1460; Thu, 27 Jun 2019 12:22:39 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 12:22:37 +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 19:22:26 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>, Alexander Okonnikov <alexander.okonnikov@gmail.com>, Robert Raszuk <robert@raszuk.net>, "bess@ietf.org" <bess@ietf.org>
CC: "softwires@ietf.org" <softwires@ietf.org>, "idr@ietf.org" <idr@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/+McjwgAMt6YD//26tcA==
Date: Thu, 27 Jun 2019 11:22:25 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB8D7F17@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> <16253F7987E4F346823E305D08F9115AAB8D7E66@nkgeml514-mbx.china.huawei.com> <9670cbbf-9b35-7ac4-b809-529ab59f18a9@nokia.com>
In-Reply-To: <9670cbbf-9b35-7ac4-b809-529ab59f18a9@nokia.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZaShzXe5oR_6BBQAdonqwJriOL0>
Subject: Re: [Idr] [bess] [Softwires] 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 11:22:44 -0000
Please reject this erratum. RFC6515 is mandatory to require 4/16 bytes nexthop, and mandatory to reject 12/24 bytes nexthop. Thanks. Jingrong. -----Original Message----- From: Vigoureux, Martin (Nokia - FR/Paris-Saclay) [mailto:martin.vigoureux@nokia.com] Sent: Thursday, June 27, 2019 6:37 PM To: Xiejingrong <xiejingrong@huawei.com>; Alexander Okonnikov <alexander.okonnikov@gmail.com>; Robert Raszuk <robert@raszuk.net>; bess@ietf.org Cc: softwires@ietf.org; idr@ietf.org Subject: Re: [Idr] [bess] [Softwires] 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] > *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! > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
- Re: [Idr] [Softwires] Regarding the Next Hop Netw… Xiejingrong
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… UTTARO, JAMES
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Alexander Okonnikov
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Alexander Okonnikov
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Xiejingrong
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Vigoureux, Martin (Nokia - FR/Paris-Saclay)
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Xiejingrong
- Re: [Idr] [Softwires] [bess] Regarding the Next H… Rajiv Asati (rajiva)
- Re: [Idr] [Softwires] [bess] Regarding the Next H… Zhuangshunwan
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Xiejingrong
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Zhuangshunwan
- Re: [Idr] [Softwires] [bess] Regarding the Next H… ian.farrer
- Re: [Idr] [bess] [Softwires] Regarding the Next H… stephane.litkowski
- Re: [Idr] [bess] [Softwires] Regarding the Next H… stephane.litkowski
- Re: [Idr] [bess] [Softwires] Regarding the Next H… Robert Raszuk
- Re: [Idr] [bess] [Softwires] Regarding the Next H… stephane.litkowski