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 11:22 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 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/softwires/fr060wycMvcgEtz23oASHFLwDmI>
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 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>om>; Alexander Okonnikov <alexander.okonnikov@gmail.com>om>; Robert Raszuk <robert@raszuk.net>et>; 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>om>; Xiejingrong 
> <xiejingrong@huawei.com>om>; 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
>