Re: [i2rs] Problem using rib-data-model RPC with rib-info-model Information (draft-ietf-i2rs-rib-data-model-05 + draft-ietf-i2rs-rib-info-model-08)

Edwin Cordeiro <edwinsc@gmail.com> Sat, 25 June 2016 07:25 UTC

Return-Path: <edwinsc@gmail.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7281912D85C for <i2rs@ietfa.amsl.com>; Sat, 25 Jun 2016 00:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8aLzqC01dOmf for <i2rs@ietfa.amsl.com>; Sat, 25 Jun 2016 00:25:11 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68BA12D7DC for <i2rs@ietf.org>; Sat, 25 Jun 2016 00:25:10 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id v199so44364580wmv.0 for <i2rs@ietf.org>; Sat, 25 Jun 2016 00:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Trlv+mFMYgajyadsjheMoV3r1q38adFswRfbTZIQ0c=; b=dA4FrejOdeApfwJn/TJhySkYv3u+Vbegu1rHrf69dI46rLw1ce37LxRaLVMgdbDwQw dzHEOCsOm22gr9y92A2ftIQ4zs3yDRfqeLmfuZLU+ueKmlk1hHjMU9XRIXHxfH+NfFYv D88zRQWktJA2c/BqTb/Y2H/QK63ToD67LNzHZfJhPUkpx/1vG8j3PSGLGnEYyvPxmAB8 DfQPxCVEdKUknwEAHWAW/RjToOdby9lOQyIBq+TjkaHcLhKUhHJCrdGmOUgBPkkVa+7j F2oASS3oJaSIKNNjXLMtKWHGMCQCf9HeML6KGBj2znWh4VAG2llexJd0LdyacAfeVUKT Nvpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Trlv+mFMYgajyadsjheMoV3r1q38adFswRfbTZIQ0c=; b=d8Fjfr1vzTu5ZArkm3kcZ7X/5clS4kzE0u2p5rJ9sJ3d2XM6kodS6WVlbSBDbr6Wyt YqNj4xluIsf0zoQA0kIY80ZTZlPYY1s736SwZ4bw7Qsge6LKl0Rntp/dIzBrsHFas/6u 6f6T8fkGTRAeSqm7S2nWerXpIF4gFCKEo4QUtbT3vJswPg1QLkMVNEI/7lYmjgeM1QPf h5XYUL6WgSj29fxXWDaOVt/pRIA5kzfyyjXBE9FBJkS4goLGz3jaXu8Jlc/eqQL5+WS8 d0QtrAfb06w/CKj+H2Hep2HIT5Pb6nB12+5Or/Rq4v72+IGH/mgCmb+HGhg+ylpecdp1 RtbA==
X-Gm-Message-State: ALyK8tKECAarcCNhMoYrIPAFNvrsoypIAZsjkm+cyEwo/VimF8b8JAN0CoojuQs/HvKA/QT+HQCMjdV+rK0w2A==
X-Received: by 10.28.18.199 with SMTP id 190mr1751400wms.66.1466839509226; Sat, 25 Jun 2016 00:25:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.113.74 with HTTP; Sat, 25 Jun 2016 00:24:39 -0700 (PDT)
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC869E0@SZXEMA510-MBX.china.huawei.com>
References: <CAERpkxAbLVf5OkGPOkixGh9xi3qMutqp1puJzTbZzvn+VhOhqg@mail.gmail.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC869E0@SZXEMA510-MBX.china.huawei.com>
From: Edwin Cordeiro <edwinsc@gmail.com>
Date: Sat, 25 Jun 2016 09:24:39 +0200
Message-ID: <CAERpkxBM+UgN-Y2nq=xQ1qRxUVtS0F0QrZDj9WNy9FWyf6TWbA@mail.gmail.com>
To: Mach Chen <mach.chen@huawei.com>
Content-Type: multipart/alternative; boundary="001a1145b088e3d9c60536152f05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/Yfff2pXLqyHxW6G4M4pWn3IEOzA>
Cc: i2rs <i2rs@ietf.org>
Subject: Re: [i2rs] Problem using rib-data-model RPC with rib-info-model Information (draft-ietf-i2rs-rib-data-model-05 + draft-ietf-i2rs-rib-info-model-08)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jun 2016 07:25:13 -0000

Hi Mach,

Thanks for the explanation. We thought that nexthops should be handled
separated to routes, but that wasn't reflected in the draft.

Best Regards,


Edwin Cordeiro

On Fri, Jun 24, 2016 at 5:08 AM, Mach Chen <mach.chen@huawei.com> wrote:

> Hi Edwin,
>
>
>
> Thanks for your great question!
>
>
>
> I think this is a bug of the current model, there should be a list in a
> rib to maintain the nexthops of the rib.
>
>
>
> Regarding your question: “How can we add a Nexthop without informing the
> parent Route?” Yes, a nexthop can be created without informing the parent
> routes. In the current design, the nexthop is decoupled from the routes. A
> nexthop can be shared by multiple routes or is dedicated to a single route.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Edwin Cordeiro
> *Sent:* Wednesday, June 22, 2016 3:44 PM
> *To:* i2rs
> *Subject:* [i2rs] Problem using rib-data-model RPC with rib-info-model
> Information (draft-ietf-i2rs-rib-data-model-05 +
> draft-ietf-i2rs-rib-info-model-08)
>
>
>
> Hello all,
>
>
>
> When trying to implement I2RS we are faced the following problem:
>
>
>
> In draft-ietf-i2rs-rib-data-model-05#section-2.5 the RPC offer the
> following Nexthop operations:
>
>       +---x nh-add
>
>       |  +---w input
>
>       |  |  +---w rib-name              string
>
>       |  |  +---w nexthop-id?           uint32
>
>       |  |  +---w sharing-flag?         boolean
>
>       |  |  +---w (nexthop-type)?
>
>       |  |     ...
>
>       |  +--ro output
>
>       |     +--ro result        uint32
>
>       |     +--ro reason?       string
>
>       |     +--ro nexthop-id?   uint32
>
>       +---x nh-delete
>
>          +---w input
>
>          |  +---w rib-name              string
>
>          |  +---w nexthop-id?           uint32
>
>          |  +---w sharing-flag?         boolean
>
>          |  +---w (nexthop-type)?
>
>          |     ...
>
>          +--ro output
>
>             +--ro result uint32
>
>             +--ro reason? string
>
>
>
> In these operations the Nexthop is directly connected to a RIB, but
> in draft-ietf-i2rs-rib-info-model-08#section-2: RIB(s) contains Route(s)
> and Route(s) contains Nexthop(s):
>
>
>
>             routing-instance
>
>             |             |
>
>             |             |
>
>       0..N  |             | 1..N
>
>             |             |
>
>         interface(s)     RIB(s)
>
>                           |
>
>                           |
>
>                           | 0..N
>
>                           |
>
>                         route(s)
>
>                         | | |
>
>               +---------+ | +----------+
>
>               |           |            |
>
>          0..N |           |            |
>
> route-attribute         match         nexthop
>
>                           |
>
>                          ...
>
>
>
> Our questions are:
>
> - How can we add a Nexthop without informing the parent Route?
>
> - Looking at the RIB grammar (draft-ietf-i2rs-rib-info-model-08#section-6)
> the Nexthop is also attached to a Route. Shouldn't Nexthop be part of RIB?
> Maybe something like:
>
>
>
>   <rib> ::= <RIB_NAME> <rib-family>
>
>                       [<route> ... ]
>
>                       [<nexthop> ...]
>
>                       [ENABLE_IP_RPF_CHECK]
>
>
>
>             routing-instance
>
>             |      |
>
>             |      |
>
>       0..N  |      | 1..N
>
>             |      |
>
>     interface(s)  RIB(s)
>
>                    |  | 0..N
>
>                    |  +--------------+
>
>               0..N |                 |
>
>                    |                 |
>
>                  route(s) ------> nexthop(s)
>
>                  | |       1..N
>
>        +---------+ |
>
>        |           |
>
>   0..N |           |
>
> route-attribute  match
>
>                    |
>
>                   ...
>
>
>
> If we misunderstood the model, could someone please explain why our
> understanding is incorrect?
>
>
>
> Best Regards,
>
>
> Edwin Cordeiro
>