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)

Mach Chen <mach.chen@huawei.com> Mon, 27 June 2016 08:38 UTC

Return-Path: <mach.chen@huawei.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 8621512B050 for <i2rs@ietfa.amsl.com>; Mon, 27 Jun 2016 01:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Level:
X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 IMIIizfnnGsS for <i2rs@ietfa.amsl.com>; Mon, 27 Jun 2016 01:38:30 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858A512B014 for <i2rs@ietf.org>; Mon, 27 Jun 2016 01:38:29 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRO46776; Mon, 27 Jun 2016 08:38:26 +0000 (GMT)
Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 27 Jun 2016 09:38:25 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Mon, 27 Jun 2016 16:38:19 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Edwin Cordeiro <edwinsc@gmail.com>
Thread-Topic: [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)
Thread-Index: AQHRzFpn2C0gJVAqEEO0WgKgn0ozkp/31qRQgAFvz4CAA1NscP//27sAgACKo3A=
Date: Mon, 27 Jun 2016 08:38:19 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC876C4@SZXEMA510-MBX.china.huawei.com>
References: <CAERpkxAbLVf5OkGPOkixGh9xi3qMutqp1puJzTbZzvn+VhOhqg@mail.gmail.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC869E0@SZXEMA510-MBX.china.huawei.com> <CAERpkxBM+UgN-Y2nq=xQ1qRxUVtS0F0QrZDj9WNy9FWyf6TWbA@mail.gmail.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC874DA@SZXEMA510-MBX.china.huawei.com> <CAERpkxD_LA1qQXqaVgFkG18CPoBVYLwU1u8Wak8nSoh7BQBTYQ@mail.gmail.com>
In-Reply-To: <CAERpkxD_LA1qQXqaVgFkG18CPoBVYLwU1u8Wak8nSoh7BQBTYQ@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.135]
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC876C4SZXEMA510MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5770E603.00B9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 85887bbc74ddfac191c856d165953bcf
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/ozfOU2xWDuun6fdOvSDk6eeafQo>
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: Mon, 27 Jun 2016 08:38:33 -0000

Hi Edwin,

OK, thanks for the clarification!

We will add a nexthop list under the rib node in the next revision.  Then with the nh-add/delete , route-add/delete, and route-update RPCs, an implementation can flexibly operate the route and nexthop.

Hope this addresses your concern.

Best regards,
Mach

From: Edwin Cordeiro [mailto:edwinsc@gmail.com]
Sent: Monday, June 27, 2016 4:02 PM
To: Mach Chen
Cc: i2rs
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)

Hi Mach,

I mean the RIB should have a group of a nexthops and a group of routes and while the draft stated nexthop as part of the route.

I my understanding each route would indicate which of the existing nexthops it uses, allowing a nexthop to be shared by multiple routes without having multiple copies of the same next hop.

I don't think my statement contradicts your understand.

Best Regards,


Edwin Cordeiro

On Mon, Jun 27, 2016 at 4:22 AM, Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>> wrote:
Hi Edwin,

Could you elaborate more about the mean of “nexthops should be handled separated to routes” ?

In my understanding, the nexthop-add/delete RPC s are designed to operate the nexthop separately.  Of cause, a nexthop list node should be added to the rib, hence to maintain the added nexthops.

Best regards,
Mach

From: Edwin Cordeiro [mailto:edwinsc@gmail.com<mailto:edwinsc@gmail.com>]
Sent: Saturday, June 25, 2016 3:25 PM
To: Mach Chen
Cc: i2rs
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)

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<mailto: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<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