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

"Acee Lindem (acee)" <acee@cisco.com> Thu, 12 December 2019 22:33 UTC

Return-Path: <acee@cisco.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 D19FE1200A4; Thu, 12 Dec 2019 14:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=UOhwWYvN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w8iyMbSe
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 yTSeqkdxlD_Z; Thu, 12 Dec 2019 14:33:21 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750B0120025; Thu, 12 Dec 2019 14:33:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8778; q=dns/txt; s=iport; t=1576190001; x=1577399601; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Due1To4Mpsg34w6qYBqQHfA66NhwmkIaZgKWJnQ2o9M=; b=UOhwWYvNoLo/r1fs+1UG5lAbOu3UbaNrZ7ooly1f7NugeM2pMpUDD/GY 09upZiTLdtq82RG/jxfOoRDzqTUKGt4VmMMUulboTkCxFR9B2+aMYRPUf CxNPyI0MmTsiO8/gpkq2HgY7YC6+6Bgt0RrczEtvK/W8nyx6MKDneIJ9f Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3AtwIBGRME9wY724jvsnYl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQAEb2IdbhbjcxG4JJU1o2t3w=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AADiv/Jd/51dJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgW0BAQEBAQELAQGBSVAFbFggBAsqhAO?= =?us-ascii?q?DRgOLDYJfmAaCUgNUCQEBAQwBARgLCgIBAYRAAheBcyQ3Bg4CAw0BAQQBAQE?= =?us-ascii?q?CAQUEbYU3DEIWAYUFAQEBAQMBARAREQwBASwLAQsEAgEIDgMEAQEBAgIjAwI?= =?us-ascii?q?CAiULFAEICAEBBAENBSKDAAGCRgMuAQIMo1kCgTiIYXWBMoJ+AQEFRoRCGII?= =?us-ascii?q?XAwaBDigBjBcaggCBEAEnIIJMPoJkAQEDgUABAR4mgmoygiyQLoV4mE0KgjC?= =?us-ascii?q?HJI5VG4JCjDeLSI5LiEyOCoNnAgQCBAUCDgEBBYFoI4FYcBU7KgGCQVARFI0?= =?us-ascii?q?SDAUSg1CFFIMZgiZ0gSiIAYRAgjIBAQ?=
X-IronPort-AV: E=Sophos;i="5.69,307,1571702400"; d="scan'208";a="683745181"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Dec 2019 22:33:20 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xBCMXKBj013011 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2019 22:33:20 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Dec 2019 16:33:19 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Dec 2019 17:33:18 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Dec 2019 16:33:18 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XSkvgLJ/cZGpDA11lsI/WXaHuIgVW1qw4fe/NSqieU48xS2ikH1NCSDguqQCnGXs3HF3YSqyYTK3KJmgvP7lfTj5sF6ssyg/sXPVWZzgxrQd9O9NwReLtoxg1AnrxBP/51rS2ejPu6ly4iWcp/oIs7L7/atIJPHQrjUJ8tuOWiIAuNSECLQNDXEyxFZXJ7ncjTtCgHHNEMQ7RsCS8CLJL/UfyFZCgIAMHBQEJXYe+hjTcU9BAAVtssW8izV/8j2b/PI/4tDrz68YKv10PSwOs6IkYhy8pGlC9NrdWYQ3ltPCPeKpZsbWsKVK47maDC7Ipicy1Kn13lSQcHZbg97OeQ==
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=Due1To4Mpsg34w6qYBqQHfA66NhwmkIaZgKWJnQ2o9M=; b=Upreh5HFyopPHuO5PnQy8+A3CZcDMRK3pc+DyKmqnaQ94AObWZbRPoS51JVKnJnaPinVjj+OQeUU082eR0o9aYTK6ibHkYgI38FRa2FL+kEZ5U0ioWuoawMD54cvsURTuy+4VI136nbAnLf0LCGEVFPf94LmG64AZeXUT+SDzZgpEqCACs7hAv413YW+HfdX12eiJONCGvjMJLdIrHcjDC3vyF67ENJ6UPs1+Arifchnm+7bt718WCYwgfNGGWB1Jt8oA/ljw8J8frP0ZdrRneRFxPqhxrZw0lUV1+k10YhJFN+bs+L+9EHjCWGWrHUio+8uAogn2Z8eIQ2z1VlYJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Due1To4Mpsg34w6qYBqQHfA66NhwmkIaZgKWJnQ2o9M=; b=w8iyMbSe2aeHZ7/jYh2/zCc+srpuiQm25Nn+eTJKjbvvT8dNZ890S/UODGtrp3M+43pHrjWjln/D70MJLWcCqaZQK2PaxL82KvlHoGKLCB7U9fMpGcoDtFDHrFl6iYw6jsNI50pwyS9V3i21VMEcfhR8sSs9lGlWVVwwarQTvGA=
Received: from BY5PR11MB4210.namprd11.prod.outlook.com (52.132.253.29) by BY5PR11MB3893.namprd11.prod.outlook.com (10.255.72.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Thu, 12 Dec 2019 22:33:17 +0000
Received: from BY5PR11MB4210.namprd11.prod.outlook.com ([fe80::51d6:76d:3ab8:563f]) by BY5PR11MB4210.namprd11.prod.outlook.com ([fe80::51d6:76d:3ab8:563f%3]) with mapi id 15.20.2516.018; Thu, 12 Dec 2019 22:33:17 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
CC: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-bgp-model@ietf.org" <draft-ietf-idr-bgp-model@ietf.org>, "draft-ietf-rtgwg-ni-model@ietf.org" <draft-ietf-rtgwg-ni-model@ietf.org>
Thread-Topic: [Idr] draft-ietf-idr-bgp-model
Thread-Index: AdVTYqP7HEGobTyKRLSJ6VQT3MRf2gI66BIAAA6vHoAQXeODgATEa24A
Date: Thu, 12 Dec 2019 22:33:17 +0000
Message-ID: <38672C45-991E-42F6-8D2A-E001C7F0D75A@cisco.com>
References: <1E61161D6E31D849BEA887261DB609348C8F2E20@nkgeml514-mbx.china.huawei.com> <20190826203850.GH24671@pfrc.org> <1E61161D6E31D849BEA887261DB609348C90DB78@nkgeml514-mbx.china.huawei.com> <20191118110851.GK21134@pfrc.org>
In-Reply-To: <20191118110851.GK21134@pfrc.org>
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: [2001:420:c0c4:1001::29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d7a73a29-4c89-4ea6-78b1-08d77f5348cd
x-ms-traffictypediagnostic: BY5PR11MB3893:
x-microsoft-antispam-prvs: <BY5PR11MB38934E8FF52D5D5F0DF2C722C2550@BY5PR11MB3893.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0249EFCB0B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(396003)(136003)(366004)(13464003)(189003)(199004)(54906003)(91956017)(66574012)(6506007)(66946007)(66556008)(76116006)(110136005)(64756008)(6486002)(966005)(66446008)(33656002)(6512007)(8936002)(36756003)(53546011)(316002)(2906002)(4326008)(8676002)(86362001)(478600001)(81166006)(186003)(71200400001)(81156014)(2616005)(66476007)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB3893; H:BY5PR11MB4210.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: BCL:0;
x-microsoft-antispam-message-info: ZRZZC6fnIeI9nwmhzLDI94rLvt9vPADID/uBeb0OQW50AlMrA5WQu+GUfDeb/3uax8+UBuikr/A+8mtfe4Gtrr5MPhuc39CHDkXtTQCOB6OrHm+TsRWJ8MeFyN3QAie2d2duajNWGOfWlVxhwoXYtBS0KsHGtJ18neVIfmTqtonQ9O6L6SUaWsA/zXkt6HZbWE6SFZ6WnMdr80INprAttk3e4IPaykJbsiVAt99FkKu69RhqYtcKG5GypFPtHdx2plTRoMpkEfkstYB3Gwln5r6ZFyPGaQrDYRf9d63Yto8ACYXY7yosTdzJRhOAyux4J7uYk4td99ioMjup4n5GNdZpgYcN9QjFZo3eZP45JxNHYmvjd42ZKxb2umYuhA2YMtP30Hd3Ut2Y0j2Q/CLtNhQ8om7NVrz7X8POPQ3pqE7gH0ETrwt0rcGRRTXdHvCKU0TaFkXb8HfQN0rd21lH6SXPFF7NJsabhKtCA3l3WEtn+uVnT2b8RRE+jy+zlUBKgXOyZf/evQX+gl85PDp56r6fS4h40JA2e0J42SGNKjQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A7CA1E56C66C674CADD8DA6EC19C8CC3@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d7a73a29-4c89-4ea6-78b1-08d77f5348cd
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2019 22:33:17.5323 (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-CrossTenant-userprincipalname: MoYSSJISvxw3WLgkUgPrbB2C+xynw3gJD2yAr6HMTycG2jv/5GiVkqEG48ZyZbgO
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3893
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_F22vz3PHg8dGNieoMYlGJGdNIE>
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: Thu, 12 Dec 2019 22:33:24 -0000

I don’t think there is any ambiguity here. For BGP VPN configuration (e.g., RFC 4364), the BGP configuration will augment control-plane-protocols in the default network instance. References to other network instances, should use a leafref with an xpath pointing to the network-instance name.  A BGP instance may also be configured as a control-plane protocol within a network-instance - either as a PE-CE protocol or simply for routing within the routing domain corresponding to the network-instance. 
Thanks,
Acee

On 11/18/19, 6:06 AM, "Idr on behalf of Jeffrey Haas" <idr-bounces@ietf.org on behalf of jhaas@pfrc.org> wrote:

    Per IDR mic comment, copying once again to IDR since I mis-laid the mail.
    My apologies, Haibo.
    
    If I understand your comment correctly, your question is "how do you bind a
    given routing instance (e.g. VRF) to a given BGP session?"
    
    If so, I think you are correct.  We do not have a clean way to specify this.
    It may also have impacts on the network instancing model in general.  Let us
    raise the issue with netmod working group.
    
    -- Jeff
    
    On Tue, Aug 27, 2019 at 03:39:17AM +0000, Wanghaibo (Rainsword) wrote:
    > Hi Jeff,
    >  
    >  Thanks for your reply. 
    > 
    >  I have read this example. But it doesn't solve my doubts. 
    >  If I have two public bgp instance like this:
    >     "ietf-routing:routing": {
    >        "router-id": "192.0.2.1",
    >        "control-plane-protocols": {
    >          "control-plane-protocol": [
    >            {
    >              "type": "ietf-routing:bgp",
    >              "name": "bgp0",
    >              "description": 
    >                "Bgp for CustomerA.",
    >              "bgp": {
    > 			 "neighbors":{
    > 			  "neighbor":[
    > 			    {
    > 				 "remote-address":"192.0.2.1",
    >                    "peer-as":"64497"
    > 	               "afi-safis":{
    >                      "afi-safi":[
    >                        "afi-safi-name":"bt:l3vpn-ipv4-unicast"
    >                       ]
    >                     }
    > 			    }	
    > 			   ]
    > 		      }
    >               }
    >            }
    > 		 ]
    >          "control-plane-protocol": [
    >            {
    >              "type": "ietf-routing:bgp",
    >              "name": "bgp1",
    >              "description":
    >                "Static routing is used for the internal network.",
    >              "bgp": {
    > 			 "neighbors":{
    > 			  "neighbor":[
    > 			    {
    > 				 "remote-address":"192.0.3.1",
    >                    "peer-as":"64497"
    > 	               "afi-safis":{
    >                      "afi-safi":[
    >                        "afi-safi-name":"bt:l2vpn-evpn"
    >                       ]
    >                     }
    > 			    }	
    > 			   ]
    > 		      }
    >               } 
    >             }
    >          ]
    >        },
    >    
    >  And I have two vrf instance like :
    >     "ietf-network-instance:network-instances": {
    >       "network-instance": [
    >         {
    >           "name": "vrf-old",
    >            ...
    >         }
    >        ]
    >       }
    >     "ietf-network-instance:network-instances": {
    >       "network-instance": [
    >         {
    >           "name": "vrf-new",
    >            ...
    >         }
    >        ]
    >       }
    > 
    >   I want to specify the vrf-old use bgp0 to advertise routes using l3vpn-ipv4-unicast, and use bgp1 for vrf-new to advertise routes using l2vpn-evpn with type5.
    >   So how can I do this ?
    > 
    > Regards,
    > Haibo
    > 
    > -----Original Message-----
    > From: Jeffrey Haas [mailto:jhaas@pfrc.org] 
    > Sent: Tuesday, August 27, 2019 4:39 AM
    > To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
    > Cc: draft-ietf-idr-bgp-model@ietf.org; idr@ietf.org
    > Subject: Re: [Idr] draft-ietf-idr-bgp-model
    > 
    > On Thu, Aug 15, 2019 at 12:32:01PM +0000, Wanghaibo (Rainsword) wrote:
    > > 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
    > 
    > The bgp model uses NMDA:
    >   augment "/rt:routing/rt:control-plane-protocols/"
    >         + "rt:control-plane-protocol" {
    > 
    > You may find this example from RFC 8349 helpful:
    > 
    > https://tools.ietf.org/html/rfc8349
    > 
    > : Appendix D.  Data Tree Example
    > : [...]
    > : 
    > : 
    > :      "ietf-routing:routing": {
    > :        "router-id": "192.0.2.1",
    > :        "control-plane-protocols": {
    > :          "control-plane-protocol": [
    > :            {
    > :              "type": "ietf-routing:static",
    > :              "name": "st0",
    > :              "description":
    > :                "Static routing is used for the internal network.",
    > :  
    > 
    > The definition of control plane protocols permits multi-instancing via name:
    > 
    > :        container control-plane-protocols {
    > :          description
    > :            "Support for control-plane protocol instances.";
    > :          list control-plane-protocol {
    > :            key "type name";
    > :            description
    > 
    > -- Jeff
    
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr