Re: [netmod] Doubts about static routes in RFC 8349

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 03 April 2019 11:27 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 ABEEA1200B7; Wed, 3 Apr 2019 04:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
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 7hOxyRDWUEas; Wed, 3 Apr 2019 04:27:38 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.66]) (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 EFCE3120033; Wed, 3 Apr 2019 04:27:37 -0700 (PDT)
Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.eu-west-1.aws.symcld.net id 3C/10-23323-7A894AC5; Wed, 03 Apr 2019 11:27:35 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa2xLYRjH9/ac053Ryqsbe9QlVnwwTq01dAs JPkgjwcQHCRtO7Wgb7dn0tHQiWCLBljKxZdcaU8a6YrNI3S+Ja7AZQpYZszFlS8wwVNCzM7cv b37v8/+/z+XNQxOq+3I1zbmdnINnbRr5EDJ5dIObOVriS0+6d3G6YX/PAcLQVOOVG/LzX0cbK h/kUoam7jAxlzIWhusoo8/3VWasf9iKjHXfDpNp5ArKypuy3Gsoy/XeciI7yLgD4UZqO+qemo diaBJXEfD0xtY8NIRW4QIZPK/yIunShuD6pzPRokuO50C9/5lc5Dg8CTrPBkjRROC9CIJ3C5A oxOLZ4A15ZXmIjpjmQMH5BMk/H057rhJStYlQ+sE/kFOJM+Bbn58SWYXLZdD3QiNyDJ4HbeF2 UmSER0L/nVqZyASOh5bOygEGjMF3oZGQeASEOn5Qkt8Ez18dQlI8AUraKqIlHgvNlfmD8UWwq zQoF9sEPAEa3mSIowBuQRAqrh70JELZiXeDrIb+jt7BPDYoDBXJJR4DRwJBJD32yOF4RTEpDb MWblX0kZJpHNR42knJ1ETAp+qLhFiZwJPh5LlpBSix7J/Zyv4qUjgBCvPbo8sGvms43C7tJA8 isgYZTA6r2eK0s1Ybo0tKYnQ6PaNLSWH0eoOW3cyYtJyL2cQJTkanZTcJWiHHvtaWqeU5Zz2K 7FNm9s3OIPqZZ76GRtEyzQjlzK2+dNUwU1ZmjoUVLKsdLhsnXENjaFoDSkVxRBvu4Myce53VF lnK3zLQCk2cMlAUkZVCNmsXrGZJuoNS6CtV7V6C3lP3OnL2XO3yEiqSz+I5dbwyWcyHxQcWF/ 8n3e81b0Zj1bFKFBUVpVJkcw671fm//hbF00gTqxwvZlFYeeefqm8jDckiDRlclWJDTvavpN6 OqFefF8a2TN55hm0u7/JHzZidW65Ympri+FJPNS5vqFp4yr9hyrucuFrz948xB8in6nS+Vp2R VnQo6VL/+sVLFvSkdXmMlP7R+1kb6SdbXC+3BbqHLkjGZG71Lq9nKb+SeXwsbA8to1v3rd6/q iTV2dt2Wf+lgzrdsKMvdffEI62tGlKwsLpEwiGwvwAKxLY54QMAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-17.tower-287.messagelabs.com!1554290851!6104039!1
X-Originating-IP: [52.27.180.120]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.31.5; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 4506 invoked from network); 3 Apr 2019 11:27:34 -0000
Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-17.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 3 Apr 2019 11:27:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r5DZ3FTKE5hbQeLSn74zMU/y2IXxTD7aLxNAbFyNPcs=; b=DgejnBdzMiRPrjMRZ/zuu7h8MEHL+JrlgxjBLjPIe+5uERQZA6dvQITWFZ+mhHgKUisv6X8lot8XmMldzIgkP3fx7yfythfTTl80Sl5q2tswM1xo58NW7zipVzCWCHcdSOYNERijI4Qa5OHcrZiwJHRICgNR0LMtUfczZYLoEo0=
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB5683.eurprd03.prod.outlook.com (20.179.254.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Wed, 3 Apr 2019 11:27:29 +0000
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7946:b505:a799:7a25]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7946:b505:a799:7a25%3]) with mapi id 15.20.1750.017; Wed, 3 Apr 2019 11:27:29 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "acee@cisco.com" <acee@cisco.com>, "lhotka@nic.cz" <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Thread-Topic: [netmod] Doubts about static routes in RFC 8349
Thread-Index: AQHU6gi44Fd6CRdD2EKrt3tqeszW8aYqPwHQgAAHFACAAAJfsA==
Date: Wed, 3 Apr 2019 11:27:29 +0000
Message-ID: <AM0PR03MB382867F5B62ABF6A1AB447C29D570@AM0PR03MB3828.eurprd03.prod.outlook.com>
References: <AM0PR03MB38286521B6CDFD36D173C6889D570@AM0PR03MB3828.eurprd03.prod.outlook.com> <20190403.123345.1599705387341112249.mbj@tail-f.com> <AM0PR03MB38281F7C5CF7C09C32066FB69D570@AM0PR03MB3828.eurprd03.prod.outlook.com> <20190403.130458.1547365482806443643.mbj@tail-f.com>
In-Reply-To: <20190403.130458.1547365482806443643.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 544eb173-c5d5-453d-d321-08d6b8275b22
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB5683;
x-ms-traffictypediagnostic: AM0PR03MB5683:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <AM0PR03MB5683AB7D60D586FBF7E068F69D570@AM0PR03MB5683.eurprd03.prod.outlook.com>
x-forefront-prvs: 0996D1900D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(376002)(39860400002)(346002)(13464003)(51874003)(199004)(189003)(51444003)(97736004)(229853002)(2906002)(8936002)(25786009)(14454004)(93886005)(8676002)(76176011)(54906003)(99286004)(7696005)(68736007)(105586002)(53546011)(71190400001)(3846002)(6116002)(106356001)(6506007)(102836004)(72206003)(81166006)(81156014)(74316002)(71200400001)(26005)(86362001)(14444005)(55016002)(186003)(6916009)(256004)(33656002)(66066001)(6436002)(4326008)(5660300002)(305945005)(446003)(6246003)(316002)(11346002)(7736002)(486006)(9686003)(6306002)(476003)(52536014)(53936002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5683; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 0AKKZM3YkPoUcja9tlUM58x53ovgw6HvoieUIGf1YvpuLxxPnO93VAgK8AbDtwJ5f+yE9honIfu5VW1aZtT9LYxZxFpnBlUgZ6Lb5xgsR9TiuRuMKkC70UEYKq/QDUT6HpnY3Jd3jV+PfQDlZ1BQumXTRS/uv7cwrtp6fq7XVXA8XD3C0a+FhThkr4QN54PeItuCxXEA+/Nn+amrTImF1cGEAy6CaE6nWkug9UPWQ0I996EKkj1hDm5WwYQlCTePHujQF+mq4HwmHZjQqwoO8PianwIXf9PsRIFgI0MqyALhVuOw4SVJ3Mi7t1x8RZIqxmZ55uX8cRnAP/0YcieXsaSoG7Y2sIT4a7kee1fIzwH7C1RiB8SooNxs2K6aclK9gztS5ZWG+3HtAl7C6y9yVnGX0z+QwKQAzFU6c9/oeA8=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 544eb173-c5d5-453d-d321-08d6b8275b22
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 11:27:29.1317 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5683
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hzj4iKB2pqvzPBSPO-o7pcoFgWo>
Subject: Re: [netmod] Doubts about static routes in RFC 8349
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:27:41 -0000

Martin,
Lots of thanks for a prompt response.

My reading of your response is that, if you need multiple static routes with the same destination but different next hops, you configure them as a single route with next-hop-list, but what you see when you retrieve the RIB may be multiple individual routes, each with its own simple next hop. Or it may be something else, since no keys have been defined in the read-only representation of the RIB.

Is my reading correct? 

Regards, and lots of thanks in advance,
Sasha

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


-----Original Message-----
From: Martin Bjorklund <mbj@tail-f.com>; 
Sent: Wednesday, April 3, 2019 2:05 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;
Cc: acee@cisco.com; lhotka@nic.cz; netmod@ietf.org; rtgwg@ietf.org
Subject: Re: [netmod] Doubts about static routes in RFC 8349

Hi,


Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; wrote:
> Martin,
> 
> Lots of thanks for an interesting input.
> 
> I have noticed that Appendix A in RFC
> 8349<https://tools.ietf.org/html/rfc8349#appendix-A>  defines the key 
> for static IPv4 and IPv6 unicast routes as “destination-prefix”.

Right (to be precise, the key is defined in the YANG models in section
8 and 9).


> draft-ietf-rtgwg-
> yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-
> extend-01> claims that it augments the model defined in 8349, 
> therefore, to the best of my understanding, it uses the same key for 
> station IPv4 and
> IPv6 unicast routes.

Correct.


> At the same time Appendix A in this draft does not define any keys for 
> the read-only RIB.
> 
> Can you explain this controversy?

Not sure there's a controversy.  The static route list is how you configure static routes, and the RIB is the operational state of all routes (static and others).  Two different things.

The MIB had a single table to show routes and write routes.  I don't think the persistency of the routes you wrote into the MIB was defined; perhaps these can be viewed as being "static".


/martin


> 
> 
> 
> Regards, and lots of thanks in advance,
> 
> Sasha
> 
> 
> 
> Office: +972-39266302
> 
> Cell:      +972-549266302
> 
> Email:   Alexander.Vainshtein@ecitele.com
> 
> 
> 
> -----Original Message-----
> From: Martin Bjorklund <mbj@tail-f.com>;
> Sent: Wednesday, April 3, 2019 1:34 PM
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;
> Cc: acee@cisco.com; lhotka@nic.cz; netmod@ietf.org; rtgwg@ietf.org
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
> 
> 
> 
> Hi,
> 
> 
> 
> Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote:
> 
> 
> 
> [...]
> 
> 
> 
> > 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
> 
> 
> 
> Note that the "route" list in the rib doesn't have any keys.  This means that you can report several entries with the same destination prefix.  So I think that this design is compatible with the MIB design.
> 
> 
> 
> 
> 
> 
> 
> /martin
> 
> ______________________________________________________________________
> _____
> 
> 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.
___________________________________________________________________________