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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 03 April 2019 12:20 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 9F6F4120100; Wed, 3 Apr 2019 05:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 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, 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=O8o5dpzt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iVqMUu2P
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 RDCMvCdvQ3bd; Wed, 3 Apr 2019 05:20:54 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463E81200D6; Wed, 3 Apr 2019 05:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10490; q=dns/txt; s=iport; t=1554294054; x=1555503654; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E8yEnY9HTW3iJOchkuHTModbcdPTXt5cKddzT9cKY2A=; b=O8o5dpztiolOwBffO4I1XnDr8JBQb4DU9PipGjGl7wK/9NuU8HdD6CtC yvNnId9Jwyfbd5vBTC1lXZfmv9W9ncP6cgzBawFfC9CpDMqQm2k+YtuXS m5NNnMj3ShJQUr3At3dOJxnA4ELsKuPHZuZZUJ3apavxIhPRwsu8BWHtc A=;
IronPort-PHdr: =?us-ascii?q?9a23=3AjKn+PBfTezRJvjEEthcExWqhlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFl?= =?us-ascii?q?cejNkO2QkpAcqLE0r+effhYiESF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAADHo6Rc/4kNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBPVADaHQECycKhASDRwOPIYJXlxGBLhSBEAN?= =?us-ascii?q?UDgEBIwmEQAIXhS0iNgcNAQEDAQEJAQMCbRwMhUoBAQEBAgEjEQwBATcBCwI?= =?us-ascii?q?CAgEIDgMEAQEBAgIjAwICAhQcFAEICAIEDgWDIgGBXQMNCAEOoiQCihRxgS+?= =?us-ascii?q?CeQEBBYR/GIIMAwUFgQYkAYsyF4F/gTgfgh4uPoEEgV0BAQIBgSsBEgEmECE?= =?us-ascii?q?CglAxgiaKOoJRmFsJAod8gSaKVBqCBYYSg1qIVZFliyiCJgIEAgQFAg4BAQW?= =?us-ascii?q?BUwExZXFwFTsqAYJBggoYg1aFFIU/coEojFmBHwGBHgEB?=
X-IronPort-AV: E=Sophos;i="5.60,304,1549929600"; d="scan'208";a="532226708"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2019 12:20:52 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x33CKqxq009083 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Apr 2019 12:20:52 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Apr 2019 07:20:51 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Apr 2019 08:20:50 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Apr 2019 07:20:50 -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=E8yEnY9HTW3iJOchkuHTModbcdPTXt5cKddzT9cKY2A=; b=iVqMUu2P/gWdlJib2n9og/G8y4Qn9Z1CuE30+ETqCOnZJkpDkgz37viOQ3KGiCuhj+gmuDEHGHyrUI97VL0N8OE1XrCl90re6N8mKWSx5O6TlAg0jKwFqFSkgr8AYqQzOsFcpIjSqZcBoUKWqEzpLTRUluEWo9B7kyqzdbndBF0=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2291.namprd11.prod.outlook.com (10.174.113.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.22; Wed, 3 Apr 2019 12:20:48 +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 12:20:48 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "Alexander.Vainshtein@ecitele.com" <Alexander.Vainshtein@ecitele.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: AQHU6gjERYkTL9wT6kGTOa3NgxSQBKYqQkmAgAADzACAAAZKgP//vnMAgABJvYD//8OmgA==
Date: Wed, 3 Apr 2019 12:20:48 +0000
Message-ID: <C5679342-DC67-40E0-ABFB-6A57C09F6A7C@cisco.com>
References: <20190403.130458.1547365482806443643.mbj@tail-f.com> <AM0PR03MB382867F5B62ABF6A1AB447C29D570@AM0PR03MB3828.eurprd03.prod.outlook.com> <ED286AC7-41CD-4510-A416-9A3FD6418CE0@cisco.com> <20190403.135647.1188699688177530452.mbj@tail-f.com>
In-Reply-To: <20190403.135647.1188699688177530452.mbj@tail-f.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: b3d357a8-c54e-4a3b-ff43-08d6b82ece33
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BN6PR1101MB2291;
x-ms-traffictypediagnostic: BN6PR1101MB2291:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BN6PR1101MB2291318832D6A10D502BE536C2570@BN6PR1101MB2291.namprd11.prod.outlook.com>
x-forefront-prvs: 0996D1900D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(396003)(39860400002)(366004)(13464003)(51874003)(51444003)(189003)(199004)(14454004)(6306002)(86362001)(81156014)(2616005)(25786009)(11346002)(476003)(106356001)(6512007)(446003)(105586002)(54906003)(7736002)(81166006)(305945005)(99286004)(8936002)(26005)(4326008)(6246003)(93886005)(316002)(8676002)(186003)(5660300002)(53546011)(76176011)(6506007)(102836004)(68736007)(33656002)(2906002)(486006)(97736004)(53936002)(14444005)(256004)(66066001)(36756003)(82746002)(71190400001)(6486002)(6916009)(3846002)(6436002)(6116002)(229853002)(478600001)(83716004)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2291; 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: kem2gOW7YYMd9N3d4wnNzQ7buPDuNniznyLrlmdmaj1ddYGRw9u8umdGb5ER4j3T+UO/WgT/Zww5atqidFLVUcqIgrd09nRpGZt4lLY5n5jKMIL9O+rK9ZEMC/C0u41M8HE1BO5lHD5PdhRSG1JM5DOCMpnt2ZKHI4f9qzJfwqV90QMqElEzry8nCaV244fMPHq/FWvDvstHq6wXob96mkrrfPtEIVapjBfThYQbGgtRRSAUz27KxfL8VsMfbbOqt+S0mfri6RB8MqKLEPDauHUByOhfBZ6uw3U8Etd4OxsIHZUQJVfULXkOaN2wbku5/dOioqMhSTWj8B5CsGz7FvLIP09KzwW59hdIiXYBuEk2hwXKqYBjjTDBBWJOUmQYApncrndfzYK6U0L+zFkg8nF452JY07yyjVJTbbKubgA=
Content-Type: text/plain; charset="utf-8"
Content-ID: <019D75188B677440BA6B48B926F15D09@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b3d357a8-c54e-4a3b-ff43-08d6b82ece33
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 12:20:48.5042 (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: BN6PR1101MB2291
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/D_Vge2AQbv1dhQgTSvofVPDUf54>
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 12:20:58 -0000

Hi Martin, 

On 4/3/19, 7:57 AM, "Martin Bjorklund" <mbj@tail-f.com>; wrote:

    "Acee Lindem (acee)" <acee@cisco.com>; wrote:
    > Hi Sasha, 
    > 
    > On 4/3/19, 7:27 AM, "Alexander Vainshtein"
    > <Alexander.Vainshtein@ecitele.com>; wrote:
    > 
    >     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?
    > 
    > No - you'd see a single route and next-hop-list with the alternatives
    > when it is retrieved.
    
    Do you think it would be a violation of the spec if an implementation
    expanded this into several route entries?  If yes, is this specified?

Normally, a given RIB client, e.g., static,  would install a single route with one or more next-hops in the global RIB. If present, multiple routes for the same destination would come from different RIB clients. The RIB active route the is the route with the lowest preference value (more preferred). Since the read-only lists do not have indices, I don't see how'd we'd enforce this. However, an implementation supporting any other structure would be highly irregular. 

Thanks,
Acee
    
    
    /martin
    
    
    
    >  
    > Thanks,
    > Acee
    >  
    >     
    >     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.
    >     ___________________________________________________________________________
    >     
    >