Re: [Idr] draft-ietf-idr-bgp-model

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Fri, 16 August 2019 13:41 UTC

Return-Path: <rainsword.wang@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AAB120154; Fri, 16 Aug 2019 06:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 NsjUwq6HU_eb; Fri, 16 Aug 2019 06:41:07 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BD9BA120048; Fri, 16 Aug 2019 06:41:06 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 67D2D6881FD21A4B9CA4; Fri, 16 Aug 2019 14:41:04 +0100 (IST)
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 16 Aug 2019 14:41:03 +0100
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 16 Aug 2019 14:41:03 +0100
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 16 Aug 2019 14:41:03 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Fri, 16 Aug 2019 21:40:47 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, "draft-ietf-idr-bgp-model@ietf.org" <draft-ietf-idr-bgp-model@ietf.org>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-ietf-idr-bgp-model
Thread-Index: AQHVU8LgqmlTOA5+kkSWmUezRhvlvKb9xJsA
Date: Fri, 16 Aug 2019 13:40:46 +0000
Message-ID: <1E61161D6E31D849BEA887261DB609348C8F3B7F@nkgeml514-mbx.china.huawei.com>
References: <1E61161D6E31D849BEA887261DB609348C8F2E20@nkgeml514-mbx.china.huawei.com> <MN2PR13MB3582C3C7ACB93D4E610B068C85AC0@MN2PR13MB3582.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB3582C3C7ACB93D4E610B068C85AC0@MN2PR13MB3582.namprd13.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.185]
Content-Type: multipart/alternative; boundary="_000_1E61161D6E31D849BEA887261DB609348C8F3B7Fnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Wk9DxouWBHfM6qMM_uooI8haVec>
Subject: Re: [Idr] draft-ietf-idr-bgp-model
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 13:41:10 -0000

Hi Linda,

Thanks for your repy.
But I think your example is multiple bgp neighbors with different local-as, not multiple bgp public instance.

For multiple bgp public instance , each of them is separate with others, and the routes is also separate with other bgp public instance routes.

For example,
bgp instance 1 as 100, it receive a route 1:1:10.1.1.0/24 from its l3vpn-ipv4 neighbor 1.1.1.1
bgp instance 2 as 200, it also receive a route 1:1:10.1.1.0/24 from its l3vpn-ipv4 neighbor 2.2.2.2

The two routes are separate with each other, they will be do their own routing selection and other process.
But when they are in one bgp instance, they must do routing selection between them, because they are same prefix.

As described in RFC8022, the control-plane-protocol can be multiple ,
   +--rw routing
      +--rw router-id?
      +--rw control-plane-protocols
      |  +--rw control-plane-protocol* [type name]
      |     +--rw type
      |     +--rw name
      |     +--rw description?
so it may create multiple bgp with different name, for example one bgp for instance 1, and one bgp for instance 2,
and each of them can set their own bgp parameters.

But my question is that , how to associate  the vrf to the public bgp instance, as I wrote below.
Because bgp doesn’t like ospf and isis. Each vrf’s bgp must associate to a publice bgp instance.
They will use some address-family such as l3vpn-ipv4, l2vpn-evpn to send routes.

Regards,
Haibo

From: Linda Dunbar [mailto:linda.dunbar@futurewei.com]
Sent: Friday, August 16, 2019 7:41 AM
To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>; draft-ietf-idr-bgp-model@ietf.org
Cc: idr@ietf.org
Subject: RE: [Idr] draft-ietf-idr-bgp-model

Disclaimer:  I am not the author for this draft.

The document does say:
Additional modules or submodules to handle other aspects of BGP configuration,
including policy, VRFs, VPNs, and additional address families are also expected

Does it mean that VRF VPN1 for AS 100 and VRF VPN2 for AS200 can’t yet be specified until the respective YANG Model document is specified?

I would think the following can be used to “realize the multiple BGP public instances” (missing the VPN part) as you requested?

<global>
   <as>100</as>
     <neighbor>
       <remote-address>2.2.2.2</remote-address>
       <afi-safis>
         <afi-safi>
           <afi-safi-name
            xmlns:bt="urn:ietf:params:xml:ns:yang:ietf-bgp-types">bt:l3vpn-ipv4-unicast
           </afi-safi-name>
        </afi-safi>
       </afi-safis>
    <neighbor>


  <as>200</as>
     <neighbor>
       <remote-address>3.3.3.3</remote-address>
       <afi-safis>
         <afi-safi>
           <afi-safi-name
            xmlns:bt="urn:ietf:params:xml:ns:yang:ietf-bgp-types">bt:l3vpn-ipv4-unicast
           </afi-safi-name>
        </afi-safi>
       </afi-safis>
    <neighbor>

</global>

Linda Dunbar


From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Wanghaibo (Rainsword)
Sent: Thursday, August 15, 2019 7:32 AM
To: draft-ietf-idr-bgp-model@ietf.org<mailto:draft-ietf-idr-bgp-model@ietf.org>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] draft-ietf-idr-bgp-model

Hi authors,

I have some question about the bgp model.

In current model, the bgp module will augment to routing,
     /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol:
And the routing will schema mount to network-instance.

In this model, how to realize the multiple bgp public instance, like that

bgp instance 1 as-number 100
  neighbor 2.2.2.2
address-family vpn-ipv4
  vrf vpn1
neighbor 11.1.1.1
  address-family ipv4

bgp instance 2 as-number 200
  neighbor 3.3.3.3
address-family vpn-ipv4
  vrf vpn2
neighbor 12.1.1.1
  address-family ipv4

Bgp doesn’t like ospf or isis, the vrf’s bgp will associate to public bgp’s special address family.
I’m not find how to describe the associate in current model

Best regards,
Haibo