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

Linda Dunbar <linda.dunbar@futurewei.com> Fri, 23 August 2019 23:13 UTC

Return-Path: <linda.dunbar@futurewei.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 7FB4412001E; Fri, 23 Aug 2019 16:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 IL8LNKe9iCWI; Fri, 23 Aug 2019 16:13:55 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740109.outbound.protection.outlook.com [40.107.74.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF9C12002E; Fri, 23 Aug 2019 16:13:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oop/+N5Y0bq3EuX2QMBkrtaikM1yBK4AZBmw3H8DF/YWr+L8rRBuFqZQBa04PSsBZ0Z53AfAuKdhA8n5ilBanxcM0eEQtNgGc6I8MiugSMfD7F2kyQOd5EvWioC7lm0ftOtTgXwh2IX8/Sxe2MUbzMs+yy7PTWZmcszl+mP6wZ5+MUk3ZJGxO9Q8kjlCnT8vI0tqh2DBUo2AtiE30dSOs1R6L4B5L9QrGKqCUGrV//KjpvWZQ6yLPKvzcwPyOax5IkMF8W7yH15JhZQKP8msUqIY9BiAoQ+AbXdNLtY2Fn3N+G1dLbNCACXvIyQA2H/LdP92Y1F+abiehybtxWBvZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yjVDSP0VFqsFrDENglXZzkgwH/cFfuJ275gOoVhF7Vo=; b=egrUjDqCG52NE6MoIk08fDGyUfbiDe0oqOQ7jjB39REO8mkP1F2TKQOsCp1yFAywewL2c4dj2lxFYwL6A29i6j8WNW4G80DLnl8K0Axr+T1a0jAvPGGAuK0tANUbqkpSfZGPxU0JB/RCMT+BywkY5bR65hV9x+AAkbx8EbyJ8TKZGF+//Z0LaYtMrd3cjCwNiRDBR6dc1cUV0kOHTuKuT/HJTJSmz2Mk8TZDoOym/nkD52edrWg2DkdnkQrpQIc+welkJPdiyIjFD3Xm3TsvbZpt079gI3gHwDYPUVPuwqgTHn+0+1g4lG1Jtp9trL+yPNo/uOMP6kanCV4k8XDupA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yjVDSP0VFqsFrDENglXZzkgwH/cFfuJ275gOoVhF7Vo=; b=Hr1BEP6/IPgsf+Zk8xTbVvH/oNJxY77npeAqKZcqPTHvvm39dO8ClbSw2WLpTHALqLK68ZucgesO/j2AtWq7hzhNlWEcfDc9RF42m2+XFg5PHj0p8cgj7ryQCnqMyGPKebGuzM83ylCD4fh5JToN+F4QfdG/5+EpTy8Ru51tlVk=
Received: from MN2PR13MB3582.namprd13.prod.outlook.com (10.255.238.139) by MN2PR13MB3421.namprd13.prod.outlook.com (10.255.236.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.11; Fri, 23 Aug 2019 23:13:52 +0000
Received: from MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::58f2:cd97:428:c167]) by MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::58f2:cd97:428:c167%6]) with mapi id 15.20.2199.011; Fri, 23 Aug 2019 23:13:52 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.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: AdVTYqP7HEGobTyKRLSJ6VQT3MRf2gAYBovQAB1dsAABc/lCEA==
Date: Fri, 23 Aug 2019 23:13:52 +0000
Message-ID: <MN2PR13MB3582277CF6EEFF42FB02350A85A40@MN2PR13MB3582.namprd13.prod.outlook.com>
References: <1E61161D6E31D849BEA887261DB609348C8F2E20@nkgeml514-mbx.china.huawei.com> <MN2PR13MB3582C3C7ACB93D4E610B068C85AC0@MN2PR13MB3582.namprd13.prod.outlook.com> <1E61161D6E31D849BEA887261DB609348C8F3B7F@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <1E61161D6E31D849BEA887261DB609348C8F3B7F@nkgeml514-mbx.china.huawei.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=linda.dunbar@futurewei.com;
x-originating-ip: [12.111.81.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ff39d67c-c85f-4e59-543a-08d7281f9071
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR13MB3421;
x-ms-traffictypediagnostic: MN2PR13MB3421:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR13MB3421B37DEA4E26BB502C8F1A85A40@MN2PR13MB3421.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0138CD935C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39850400004)(346002)(366004)(136003)(376002)(199004)(189003)(66446008)(44832011)(478600001)(66066001)(229853002)(55016002)(6306002)(86362001)(81156014)(25786009)(76176011)(8936002)(8676002)(81166006)(236005)(74316002)(7696005)(9686003)(66946007)(54896002)(76116006)(6436002)(53936002)(7736002)(186003)(71190400001)(71200400001)(33656002)(26005)(6116002)(52536014)(4326008)(5660300002)(14454004)(6506007)(53546011)(99286004)(53946003)(446003)(2501003)(102836004)(110136005)(11346002)(66574012)(476003)(486006)(6246003)(316002)(3846002)(790700001)(2906002)(66476007)(66556008)(64756008)(256004)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB3421; H:MN2PR13MB3582.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4Kh3NCgHZ4gcMXVb0/6vWlmXdaaVqgjxdUriqRphOA3zQ40ZI+foDSNsFa6MrFwa/kB0Us+zliGqqmNYrWqOraJCGjdNlX/QfIKIKhwaTGKjs9jgNaVbc7IEpb3+ZbVJQiv9KEVmzWj3RgDRbPB30zCB+zPLaF4PNHQE7/G6O3aIUcq1JBXEECIhkhyDRuC3qmmAupcswkHfBR55Ua272r+i1bdT3Akj0b2gBtThBOAgpwUO1ryYG24QQJ/jcz8MvqnTrwayOPvyFjns2y+yBvyoxXaFLI4U0A2N/IAudSPxpzS6MNWQyqubWEE6nnxg++Kiy1yH2easBsoMOZdnIFYJMeijG2U6qmMz5kWz7DMrmh4bfAz+DIEJ4ZL9SdTVvV3a4hcSpmFLqYkwhc4siFSsNeB75F+I2nzkRr6fR8s=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3582277CF6EEFF42FB02350A85A40MN2PR13MB3582namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ff39d67c-c85f-4e59-543a-08d7281f9071
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 23:13:52.8328 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kk1Gh3FtpDzQ3P1cDSs+MGbbSOI/rKP8XJ4eEgDi1WB5OE3PUzqODb4tHGzECGbkYoEym437WUlEXCJozUNfHw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3421
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CLUe9IlftHevMQ8q15jvkkO55YI>
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, 23 Aug 2019 23:13:59 -0000

Can putting them in two  <global> create two public BGP instances? Although still not be able to associate the vrf to the public bgp instance (waiting for another YANG module?)

<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>100</as>
</global>

<global>
  <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>
</as>200</as>
</global>

Linda


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

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<mailto:rainsword.wang@huawei.com>>; draft-ietf-idr-bgp-model@ietf.org<mailto:draft-ietf-idr-bgp-model@ietf.org>
Cc: idr@ietf.org<mailto: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