Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

"Acee Lindem (acee)" <acee@cisco.com> Wed, 03 April 2019 11:55 UTC

Return-Path: <acee@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDB91200EC; Wed, 3 Apr 2019 04:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, 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=QWmYCx0J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Hg6RZIvj
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 F_tRnmCeRYt2; Wed, 3 Apr 2019 04:55:06 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C745C1200D5; Wed, 3 Apr 2019 04:55:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32399; q=dns/txt; s=iport; t=1554292505; x=1555502105; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PUgU8c07CD6UHg0eMXAMfvDgrjgXtfzAjzFaEoX9dKg=; b=QWmYCx0JR7XFr0VHGelmGcYucJWiX/JDlogW6GQbwS3MyFvSIoAQxznm XB7Ajsk/vKAPKKthGcsmsfwxGKTiCbWpPIORdnRvEymZ+rJZTiAdXeoJg Vv3MB3QXTmbNdiZKjqFoNopSPpvNExsF5C46OdEiVGZ7Rq7Zvr3eQ7PDy Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ad+b0OBQ4TELL8q2wnEtC2j1ys9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUANfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5NksAKh0olCc+BB1f8KavjZCE3NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADpnaRc/4cNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQ4vUANodAQLJwqEBINHA48ggleXEYE?= =?us-ascii?q?uFIEQA1QOAQEjCYRAAheFLSI1CA0BAQMBAQkBAwJtHAyFSgEBAQEDIwoTAQE?= =?us-ascii?q?3AQ0CAgEIEQMBAQEhBwMCAgIUHBQJCAEBBAENBYMiAYERTAMVAQ6iLQKKFHG?= =?us-ascii?q?BL4J5AQEFgTUCgQ+CORiCDAMFBYEqAYsyF4F/gREnH4IeLj6BBIFdAQEDgSs?= =?us-ascii?q?BEgEmBwkJDQkCglIxgiaKOoJRhCiUMwkCh3yBJopUGoIFhhKDWohVi0uGGo1?= =?us-ascii?q?OAgQCBAUCDgEBBYFOATZlcXAVOyoBgkGCCgwMCxODOIUUhT9ygSiMWYEfAYE?= =?us-ascii?q?eAQE?=
X-IronPort-AV: E=Sophos;i="5.60,304,1549929600"; d="scan'208,217";a="457727656"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2019 11:55:04 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x33Bt4wS020557 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Apr 2019 11:55:04 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Apr 2019 06:55:03 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Apr 2019 06:55:03 -0500
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Apr 2019 06:55:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PUgU8c07CD6UHg0eMXAMfvDgrjgXtfzAjzFaEoX9dKg=; b=Hg6RZIvjKwCBzAJPO+gn5KLx0D0l9QTJWySf4DJJ3ZwCPsxTe3mgdF7VH9/FuxOTiPB2x9MNB8UENiJBa75u1Dg2I4/KnBzGoCN2E9dDOngCEe4ropPnyA4mRRI5sd+aHPrhxFVtHoY1l9V7UmGiU38BIbvpxR+yimbWJNVRMW4=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2180.namprd11.prod.outlook.com (10.174.116.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Wed, 3 Apr 2019 11:55:00 +0000
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1%8]) with mapi id 15.20.1750.017; Wed, 3 Apr 2019 11:55:00 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "lhotka@nic.cz" <lhotka@nic.cz>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)
Thread-Index: AdTpW2iLlm1nfHS0SZq0IWkeRjQi6P//7NcA//7QGDCAAnFRgA==
Date: Wed, 3 Apr 2019 11:55:00 +0000
Message-ID: <FCC5A317-6AA2-43FC-808A-0766F6090678@cisco.com>
References: <AM0PR03MB3828CD6E93236076142079109D560@AM0PR03MB3828.eurprd03.prod.outlook.com> <399C7547-D8A6-4938-B5F2-9F6F7DFA795B@cisco.com> <AM0PR03MB38286521B6CDFD36D173C6889D570@AM0PR03MB3828.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB38286521B6CDFD36D173C6889D570@AM0PR03MB3828.eurprd03.prod.outlook.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=acee@cisco.com;
x-originating-ip: [173.38.117.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8b2a4a0e-5aa1-4888-c38c-08d6b82b336f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BN6PR1101MB2180;
x-ms-traffictypediagnostic: BN6PR1101MB2180:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BN6PR1101MB2180EBACCEC9AB7E63618CACC2570@BN6PR1101MB2180.namprd11.prod.outlook.com>
x-forefront-prvs: 0996D1900D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(376002)(346002)(39860400002)(189003)(199004)(53754006)(51874003)(81156014)(7736002)(81166006)(8676002)(6246003)(82746002)(53936002)(478600001)(2501003)(4326008)(25786009)(66066001)(236005)(14444005)(83716004)(26005)(102836004)(486006)(76176011)(256004)(14454004)(6506007)(11346002)(86362001)(446003)(36756003)(2616005)(476003)(71190400001)(186003)(71200400001)(53546011)(8936002)(6116002)(3846002)(316002)(110136005)(54906003)(5660300002)(6486002)(229853002)(33656002)(2906002)(6306002)(54896002)(6512007)(9326002)(97736004)(606006)(105586002)(106356001)(99286004)(6436002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2180; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: Gnj6FdB7NOaOFIkwWI1cWCJZnDHZYQ2KJNch1Z+bxpRMfmb4xk4Oaspy8sZQY9DR3hozMVnTjvI/nsM4DglLwlgOaMjAZz6BX1/R5uT6pOGpi1tmRCkJ0C4eLLOcreDXnl1G/xTmMaTN8LN00i5G6XNduksLdWT6hB4ky1p3+4iLY71JFgQUU4NIOx8ueTaeRB88AnClVGp93/cIgGy+YBcwpanNjlU9oEn8JcDPhTUobVsmHWmip5UexX9Jkrw7SYw5tXUxJR0FUSZbPZ/+EGTBnZqE8nEPFeVxxU48/TlBUW5rbQypt86e0vbQ1/dnpfMKlKn78MHL3IV5cq123j3ZJhfVmwOZ5Tbv6sSQ+OPHKA3/C37FyXtpM85S6KdjJB2BR5jkB0yjO+gkvOuBKHDY9kMDMkZVG2lhqJsD1oI=
Content-Type: multipart/alternative; boundary="_000_FCC5A3176AA243FC808A0766F6090678ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b2a4a0e-5aa1-4888-c38c-08d6b82b336f
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 11:55:00.3359 (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-Transport-CrossTenantHeadersStamped: BN6PR1101MB2180
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OipxgTxXVaXB2k_Lbsx6WlZYppo>
Subject: Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 11:55:09 -0000

Hi Sasha,
Although we are providing the same or better functionality, we never had mimicking the RFC 4292 MIB structure as a requirement. IMO, this would be a mistake since SNMP doesn’t allow nesting of tables while YANG, OTOH, supports arbitrary nesting of schema. We really must exploit this key advantage in our models.

Thanks,
Acee

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;
Date: Wednesday, April 3, 2019 at 3:14 AM
To: Acee Lindem <acee@cisco.com>;, Ladislav Lhotka <lhotka@nic.cz>;
Cc: Routing WG <rtgwg@ietf.org>;, "netmod@ietf.org"; <netmod@ietf.org>;
Subject: RE: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Acee,
Lots of thanks for a prompt response with a highly relevant pointer.

I will read draft-ietf-rtgwg-yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-extend-01> and probably send more questions.

Meanwhile, could you please explain the rationale for changing the data model that has been defined in RFC 4292 (where both the destination prefix and the next hop have been parts of the index in the appropriate MIB table) ?

The side effect of this change is  that it is not backward-compatible with multiple existing RFC 4292-compliant RIB implementations:

-          Retrieval of such a RIB using YANG requires a stateful mapper that merges multiple RIB entries with the same destination prefix and different “simple” NH into a single entry with the next-hop-list

-          Configuration of a single static route that uses the next-hop-list requires a mapper that splits such a list into multiple 4292-compliant routes (simpler than merge, but still non-trivial IMHO).

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Acee Lindem (acee) <acee@cisco.com>;
Sent: Tuesday, April 2, 2019 7:45 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;; lhotka@nic.cz
Cc: rtgwg@ietf.org; netmod@ietf.org
Subject: Re: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Hi Sasha,
You are correct that there is no per-next-hop preference in the current model. However, this is included in the augmentation in draft-ietf-rtgwg-yang-rib-extend.
Thanks,
Acee

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Date: Tuesday, April 2, 2019 at 9:53 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, Ladislav Lhotka <lhotka@nic.cz<mailto:lhotka@nic.cz>>
Cc: Routing WG <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

Hi all,
I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the same problem.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: 'acee@cisco.com'; <acee@cisco.com<mailto:acee@cisco.com>>; 'lhotka@nic.cz'; <lhotka@nic.cz<mailto:lhotka@nic.cz>>
Cc: 'rtgwg@ietf.org'; <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>; 'netmod@ietf.org'; <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Doubts about static routes in RFC 8022
Importance: High

Acee, Ladislav and all,
I have serious doubts regarding the data model for static routes in RFC 8022.

As I see it, the data model defined in this document does not support multiple routes with common destination, different next hops and different route preferences.

This is because only route destination is considered as the key in the RIB in Appendix A of RFC 8022., while route preference is a per-route read-only leaf in the data model.

In particular (and this was my original problem) , it is possible to configure a static route with multiple next hops (using the next-hop-list construct) using the data model defined in RFC 8022, but all the next hops in this construct would have the same preference. AFAIK, many (if not all) deployed implementations support ability to configure static routes with the same destination, different next hops and different preferences, so that one of these next hops would act as a protection of the other.

For the reference, this problem does not exist in the standard MIB for the RIB (RFC 4292), because it includes both the route destination and its next hop in the list  of indices in the corresponding MIB.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________