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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Thu, 27 June 2019 11:37 UTC

Return-Path: <rajiva@cisco.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 A360A1200FB; Thu, 27 Jun 2019 04:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Jip0nXUz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Cb+M6F9w
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 B6BL6qqbEKkJ; Thu, 27 Jun 2019 04:37:08 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBE11200B8; Thu, 27 Jun 2019 04:37:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21429; q=dns/txt; s=iport; t=1561635428; x=1562845028; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WxeTLRafBVUab4styfq1bTKwid2dnPd9Jlyl5epwHik=; b=Jip0nXUzeDLdpJ1ITSuNC00HYtYsK5oQnNB5C+Hr+xBhydbkwcB1Zlw6 MmWkBSTUeCorceF9wK3YbjaZp4N+S+l2IvDB1bDeG+eAv+PrhMte6xM8G a/VaQ8lcCOVCeQ7chfbtnnenSbxlzpoL6EPTSKm2T2WSwpMN0l2caZJQf w=;
IronPort-PHdr: =?us-ascii?q?9a23=3A6Wup4BZpi9Z/CtwXlp6X57z/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q6bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwZi47As1qX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADWqRRd/5JdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgRQvJAUnA2pVIAQLKAqED4NHA4RSigm?= =?us-ascii?q?CW4lLiSCEVIEugSQDVAkBAQEMAQEYAQoKAgEBg3pGAheCaCM0CQ4BAwEBBAE?= =?us-ascii?q?BAgEFbYo3DIVKAQEBAwEBARARHQEBLAsBBAsCAQgRBAEBJAQDAgICHwYLFAk?= =?us-ascii?q?IAgQOBSKDAAGBHU0DDg8BDppiAoE4iGBxgTKCeQEBBYUIDQuCEQmBNAGLXhe?= =?us-ascii?q?BQD+BEScfgh4uPoEEgRZHAQGBGl4WCYJUMoImi2gjM4FxL4R7iFmNOT8JAoI?= =?us-ascii?q?XkASDcRuCK49khU+OWYd4jXYCBAIEBQIOAQEFgVA4gVhwFTsqAYJBCYI4EQc?= =?us-ascii?q?LFG8BDYI9hRSFP3KBKYxiAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.63,423,1557187200"; d="scan'208,217";a="581652709"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jun 2019 11:37:06 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x5RBb6Mr003905 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jun 2019 11:37:06 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 06:37:05 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 06:37:05 -0500
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Jun 2019 06:37:05 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WxeTLRafBVUab4styfq1bTKwid2dnPd9Jlyl5epwHik=; b=Cb+M6F9w8FERPFJY6yJQRP6Ipw+FWbpN2G4uDvQgM8+246SpDXS8zxw40xLwn52VS9d4fv6ItMQzjd53XqZA+mMRPa/ska6Xg5HWRDQ+XtWV3gbINLPuwD69NtyY8eKEn42kldfnRcH9nJxPmZMvmZjODpo2GpU8+GSOcj1vJoM=
Received: from BL0PR11MB3268.namprd11.prod.outlook.com (10.167.234.208) by BL0PR11MB3508.namprd11.prod.outlook.com (20.177.205.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.17; Thu, 27 Jun 2019 11:37:04 +0000
Received: from BL0PR11MB3268.namprd11.prod.outlook.com ([fe80::e44b:fbb:8687:d682]) by BL0PR11MB3268.namprd11.prod.outlook.com ([fe80::e44b:fbb:8687:d682%7]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 11:37:04 +0000
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
CC: Xiejingrong <xiejingrong@huawei.com>, Alexander Okonnikov <alexander.okonnikov@gmail.com>, "softwires@ietf.org" <softwires@ietf.org>, "draft-dawra-bess-srv6-services@ietf.org" <draft-dawra-bess-srv6-services@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Softwires] [Idr] [bess] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549
Thread-Index: AQHVLMjsMhfZ3AbVJUeH/2nUOHoJ4KavUnMAgAANQ7I=
Date: Thu, 27 Jun 2019 11:37:04 +0000
Message-ID: <D0303A72-81D1-486D-8DE9-5060205079B7@cisco.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>, <CAOj+MMGQ36AUbk45L6=N-ATwc+sXfyb3a7esu8-NxZgrj7y0GA@mail.gmail.com>
In-Reply-To: <CAOj+MMGQ36AUbk45L6=N-ATwc+sXfyb3a7esu8-NxZgrj7y0GA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rajiva@cisco.com;
x-originating-ip: [136.56.51.227]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aa491ea3-3346-413f-3ae5-08d6faf3c70f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR11MB3508;
x-ms-traffictypediagnostic: BL0PR11MB3508:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BL0PR11MB350834AA8E10D607B75D4F4CC7FD0@BL0PR11MB3508.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 008184426E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(366004)(396003)(51914003)(199004)(189003)(606006)(76176011)(6506007)(53546011)(966005)(478600001)(14454004)(3846002)(6116002)(86362001)(53936002)(71200400001)(71190400001)(6306002)(54896002)(6436002)(6486002)(6512007)(236005)(229853002)(316002)(66066001)(14444005)(256004)(54906003)(25786009)(6916009)(99286004)(68736007)(5070765005)(4326008)(11346002)(2616005)(476003)(81156014)(81166006)(8936002)(446003)(36756003)(8676002)(486006)(76116006)(73956011)(91956017)(2906002)(66946007)(33656002)(66476007)(66556008)(64756008)(66446008)(102836004)(26005)(5660300002)(7736002)(6246003)(186003)(518174003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3508; H:BL0PR11MB3268.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: pTj8oBCNE6gYrW5xNJ9sIzu1RT/QYwmNzzNOLgXEnQwPejO36piM8siLWbvD/ynW7qUZf81zy4ieNm4mj/HJqoqQKUPEcq82LnxioD+IqLat33WxhIxK+PN1ktDJ1340xe9nJsCgHsQeempkXjjU23UaMYWcEKdPyYVH9lJJDv9mi8JmYbwehvGFKybDP61VwKb/fkUG1BynH6Bg0LCHny4CROWFAJvPbvzZPJElSEzeZilAzmfwagOIMMAZAwGwp5BQgTA+1r69AdvKsxByz4BdROEYK71omVzCyS2UosZ9RBJ788I324+XvqPOfutIXwCPUsqnyy+TmWmO0rs7n5jkeHmdQ//snZBQ2rSj+wn7vRzyIWRiC39CUbc20hjDQvdnHytWr9E8XYQMCCyuqN5V0CBnv09Kti2doH88U4M=
Content-Type: multipart/alternative; boundary="_000_D0303A7281D1486D8DE95060205079B7ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aa491ea3-3346-413f-3ae5-08d6faf3c70f
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 11:37:04.0516 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rajiva@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3508
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/6GDQ8Dx3LJ05Xs9uRzQhCJlYobM>
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:37:11 -0000

I agree and sometimes flexibility becomes an unwanted necessity (as is the case here with option (a)).

IMO, option (b) length based check for NH should be preferred, since it works for all AFI/SAFIs with an assumption that NH could be one IPv4 or IPv6 prefix. Very reasonable option.

Option (a) AFI/SAFI based interpretation doesn’t work for all AFI/SAFIs that don’t distribute non-routing information  e.g. policy, capabilities, LS etc.

Cheers,
Rajiv


On Jun 27, 2019, at 6:50 AM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

> 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.

When elements of BGP UPDATE message are being parsed code must know what to expect. Note that we are dealing here with deployed SAFI 128 for nearly 20 years.

So today there are two ways to know what format of next hop is in MP_REACH:

a) Inferring it from AFI/SAFI per section 3 of RFC4760

or (in addition to the above coarse assumption)

b) Inferring it from the discrete value of next hop length field as defined in section 3 of RFC5549

Note that if we would be defining new SAFI we can write anything we like to the rules of constructing the update message. But here again we are dealing with something which is deployed so sort of operating on the plane in flight.

If implementation can infer next hop type from length we are safe to define all sections to have next hop length = 16 octets and be done. But if there are some implementations which would only take AFI/SAFI to check if the next hop is correct or even further to check if the next hop length is correct then we have a problem.

/* Btw this notion of next hop length = 32 is bizarre ! I have never seen any BGP implementation sending two next hops (global IPv6 address followed by link local IPv6 address) not I am able to find any docs describing how any BGP stack would handle it. IMHO we should move this 32 next hop length to historic asap. */

To the msg from Martin,

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

I would vote to reject the errata. There is no value of stuffing 8 octet of zeros in the next hop field. If the RFC got defined in 2012 that really means that most implementations are capable of inferring next hop format from the length field - which is very good. Accepting the errata would be a step backwords.

Thx,
R.

On Thu, Jun 27, 2019 at 11:15 AM Xiejingrong <xiejingrong@huawei.com<mailto:xiejingrong@huawei..com>> wrote:
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!



_______________________________________________
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires