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

"Acee Lindem (acee)" <acee@cisco.com> Fri, 13 December 2019 14:51 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 E58D012011D; Fri, 13 Dec 2019 06:51:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.255
X-Spam-Level:
X-Spam-Status: No, score=-13.255 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=M8/lwhMe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=re2WLbS1
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 d2aL7n6UdCHh; Fri, 13 Dec 2019 06:51:00 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F82D12009E; Fri, 13 Dec 2019 06:51:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49711; q=dns/txt; s=iport; t=1576248660; x=1577458260; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mok3qCrvGvo8aBqWhwFwqWgxikd3WAlp3gnZ6jfIuR0=; b=M8/lwhMeWPR/Hcv/s2rwcN/AMjchao7cnhkamHAgNczAzhrznzK4nSnJ GFHYN1R2g4NlWOSjXTjcaK7FtFj1EuGRDCmp2+pJeANYBucX2Oyaqr6Dp bIosUsvyQvlYQeW51hdWLRXGr8gs4wtO8ScDj6qnpWGVPQidROY/qXttr Q=;
X-IPAS-Result: =?us-ascii?q?A0CPAACQpPNd/4ENJK1lGQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QEBAQEBAQEBAQEBgX6BHC9QBWxYIAQLKAKEA4NGA4sMgjolgwSGV44rglIDV?= =?us-ascii?q?AkBAQEMAQEYAQoKAgEBgydFVAIXKIFQJDgTAgMBAQEDAgMBAQEBBAEBAQIBB?= =?us-ascii?q?QRthTcMhV4BAQEBAwEBEBEdAQEJASILAQsEAgEGAhECAQEBAQEgAQYDAgICH?= =?us-ascii?q?wQCCxQJCAIEDgUigwABgXlNAy4BAgyRDZBkAoE4iGF1gTKCfgEBBUY8AYQLD?= =?us-ascii?q?QuCFwmBNowYGoIAgRABJwwUgU5+PoIbSQEBA4FAAQE1CQYHCYJaMoIsj3U5h?= =?us-ascii?q?VQkmApDCoIwhySKMoQjG4JCh3aEQYtIlxeCF4tzg2cCBAIEBQIOAQEFgT8qI?= =?us-ascii?q?oFYcBU7KgGCQQlHERSNEgwFEoNQhRSDGYImdAGBJ4xBgjIBAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3AeHugIBZiCoPp/rnW3WFVnDz/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuJfXnYgQxHd9JUxlu+HToeREPStzzbFDTvHC+qCUKFE?= =?us-ascii?q?WjZyxyIOm9WpbIiNi63Pyz/JuVZBhUgD26YvV5KxDk5Q7QrcIRx4BlL+49zR?= =?us-ascii?q?bS6n1PZ6xayHhpKlSagxuZhI+o8YRm8jhMtv5p7MNGXajgN6Q/VqBDTTk=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.69,195,1571702400"; d="scan'208,217";a="400942216"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Dec 2019 14:50:58 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xBDEow9n027045 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Dec 2019 14:50:58 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Dec 2019 08:50:58 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Dec 2019 09:50:55 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 13 Dec 2019 09:50:55 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CxUxJF8JccTbIJiWl3WZLwQg8/2SFl9kvSvktNPtvWqAC6bQ1dz5V1f5tyUji3hQhp9yMy2J4MwZmKnV/ZgF9+cZVmHVoMBWktlBbaHPeiGh5ArF2VC+yDui5G49QQfOVjf22iDGas1v1uiZSSmPtOPRt9NJUzJlEg7z1wZPNTnQFxVasDOarRmL5oCyUyrYjuOGmYkYGXpcsPFtYOFj+59Lifomq7m3eu8dJHQOaBeQFgc/NEDwFs62GqjRSNbfMTLJ7vUTOah/ngbKxZN9JkDgt7jlSXewpvWkbGXU1SyB62wDv1lARgwA74deBHxAaAUxVAHcMq8HYEmk0vE18w==
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=mok3qCrvGvo8aBqWhwFwqWgxikd3WAlp3gnZ6jfIuR0=; b=joDrR+GylByIWhT6HFGPngrsfOcxuWiygah9MTNXkFUFLEKKXFFCHcyIqJmLg1bZY7wbgtCgQ+qnk3Q7qCID49L11s6saYLxYPFhvvW7/cCPjuNH5a2IF55gEPMDOF8DJgJ6MxpXkkn34aE0qb2AkrSfUjbBYO87P97sNga5cF+A6pfquteLdb6Fgzmn486ukKihRNfP8cHWR9Dtom10MSIfEAYfGjI95HulXUK+ii9obPkO6fIkWfbGqsls+K71v47ydGCQcOTatpF4yX6zoUC6oJGhROSn6fVHbidxXzU2o+yKImsQv6jUrduMvvr33A26TQKXAe1l90Ja7VyUKw==
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=mok3qCrvGvo8aBqWhwFwqWgxikd3WAlp3gnZ6jfIuR0=; b=re2WLbS1iIzQeo3yHuDmKnBe4uT/1saOAsLjel5FZQNk8unF3ZwYbX/JM4t1FWXuJX1mm7eDuPI3vo/8vjux7Fkt2EZbYf8qrRw54LUHLw/DPDWLyZpletxMiEArQmHyY7R6xodaLkXvBXMnT/jl9CTpT3u5AZFC016mCEM+D9o=
Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB4495.namprd11.prod.outlook.com (52.135.37.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Fri, 13 Dec 2019 14:50:54 +0000
Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::f065:2931:17b6:7b5d]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::f065:2931:17b6:7b5d%3]) with mapi id 15.20.2538.017; Fri, 13 Dec 2019 14:50:54 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
CC: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>, Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-rtgwg-ni-model@ietf.org" <draft-ietf-rtgwg-ni-model@ietf.org>, "draft-ietf-idr-bgp-model@ietf.org" <draft-ietf-idr-bgp-model@ietf.org>
Thread-Topic: [Idr] draft-ietf-idr-bgp-model
Thread-Index: AdVTYqP7HEGobTyKRLSJ6VQT3MRf2gI66BIAAA6vHoAQXeODgATEa24AABTqVAAACE8ZgAAM8ngA//+/xAA=
Date: Fri, 13 Dec 2019 14:50:54 +0000
Message-ID: <5244E163-9546-4C16-B633-2DC6E8303E53@cisco.com>
References: <1E61161D6E31D849BEA887261DB609348C8F2E20@nkgeml514-mbx.china.huawei.com> <20190826203850.GH24671@pfrc.org> <1E61161D6E31D849BEA887261DB609348C90DB78@nkgeml514-mbx.china.huawei.com> <20191118110851.GK21134@pfrc.org> <38672C45-991E-42F6-8D2A-E001C7F0D75A@cisco.com> <1E61161D6E31D849BEA887261DB609348CA1D40F@nkgeml514-mbx.china.huawei.com> <78B89452-BCF8-4941-B9BB-352C4477AF2C@cisco.com> <CAOj+MMHxMM3ThQy4pKusFbFGXGDJOAXA6iBM6N3UePT4LwjVFg@mail.gmail.com>
In-Reply-To: <CAOj+MMHxMM3ThQy4pKusFbFGXGDJOAXA6iBM6N3UePT4LwjVFg@mail.gmail.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=acee@cisco.com;
x-originating-ip: [2001:420:c0c4:1006::8f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 64e91be6-35f5-40be-d3e1-08d77fdbdae1
x-ms-traffictypediagnostic: MN2PR11MB4495:
x-microsoft-antispam-prvs: <MN2PR11MB44953DE98FCFD2035643ACDAC2540@MN2PR11MB4495.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0250B840C1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6019001)(376002)(136003)(346002)(366004)(396003)(39860400002)(279900001)(189003)(199004)(13464003)(5660300002)(8936002)(33656002)(966005)(2616005)(316002)(6506007)(66946007)(86362001)(2906002)(36756003)(478600001)(66556008)(54906003)(6916009)(81156014)(6486002)(76116006)(186003)(4326008)(9326002)(66574012)(81166006)(71200400001)(66446008)(6512007)(66476007)(53546011)(8676002)(64756008)(1549645003)(256605007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4495; H:MN2PR11MB4221.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: rTmSs6a7LgaqijcD/l3Gm5fL29XbHvsAIHCWCmJfW2B5oJgZ5O5qG/vlGQ2aUsPpsJlqGaYLsf5L2xmBUPi5547ArFQjvwmtytW86WAu7OAzgqG0dJgOUE8jPbpKw593SnL9U9yt3l2FzuNGCK8X+RMAKSuElcnC0QZ+8B2lMdmGnuBI0hMD9WxDM/bs9irkNetV8br5V/9kWY61o3AAOTwRxPtpQxnGKQ/VmkYgZi5K2V2+iLkL/Rbkg2m+O3iwqUcDxLWcmzVf92hNIs9w+B9h8I1bwKOkFCcuS46zKrV1TB0b8H6eVKYM0CuSIMsN7GT3LUK12vA7GSI+DmuMx85fGdTQcXUU+mP8rPy7wHXGH8n+6b9csekG+L+mcr9T0SjYjwRlwx+l0Iy52l98inZx6yXghzVju8D7MN7+kQQMjNdg0hQSwTxPYEGPj34DPdm5DW2tOQFlLtpbUvaC8VvehwPWCpHUISvuYeBxWCGx8lZWXOwYB562jhbLrxK0Em0WKIPgnkTymOHLaBPTp5KwSsM/nEM8RGkZ7N39hprRXW/Hw+VLGFypL/MikpKs2tGKiPraY84mIDcKSTb45Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_5244E16395464C16B6332DC6E8303E53ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 64e91be6-35f5-40be-d3e1-08d77fdbdae1
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 14:50:54.1163 (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: 2ipq6JZK0Zk4WPwtTjD1Zf9lvWBx1iNr7XKDFLJVUd3NMNoy11y99YlCQPimQwBR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4495
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6f8Mv2bW1LDBdiDPGIQz3E_btOU>
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, 13 Dec 2019 14:51:04 -0000

Hi Robert,



From: Robert Raszuk <robert@raszuk.net>
Date: Friday, December 13, 2019 at 8:41 AM
To: Acee Lindem <acee@cisco.com>
Cc: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>om>, Jeff Haas <jhaas@pfrc.org>rg>, IDR List <idr@ietf.org>rg>, "draft-ietf-rtgwg-ni-model@ietf.org" <draft-ietf-rtgwg-ni-model@ietf.org>rg>, "draft-ietf-idr-bgp-model@ietf.org" <draft-ietf-idr-bgp-model@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-bgp-model
Resent-From: <alias-bounces@ietf.org>
Resent-To: <lberger@labn.net>et>, Christian Hopps <chopps@chopps.org>rg>, Acee Lindem <acee@cisco.com>om>, Dean Bogdanovic <ivandean@gmail.com>om>, <xufeng_liu@jabil.com>
Resent-Date: Friday, December 13, 2019 at 8:41 AM

Hi Acee,

Please observe that BGP instance being discussed here is orthogonal to L3VPN services. It is not BGP context per VRF. There may not be any VRFs at all while there are valid needs to run multiple BGP instances on a box - just there are for ISIS :)

Support of that should be reflected in the Yang model I am afraid.

While it doesn’t happen often, I’m in complete agreement with you 😉 There is nothing in the network-instance YANG model that precludes this.

Thanks,
Acee


Best,
R,.


On Fri, Dec 13, 2019 at 1:30 PM Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Hi Wanghaibo,
The MPLS VPN support (RFC 4364), is confined to the default networking instance. However, you could additional use BGP as a PE-CE protocol in the non-default network instance (aka, VRFs).
Thanks,
Acee

On 12/12/19, 10:37 PM, "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>> wrote:

    Hi, Acee

    RFC 4364 does not describe the use of multiple instances on the public network, but now multiple vendors have supported such functions,

    Eg

    router bgp 100 instance a1       // one bgp instance here
     bgp router-id 12.12.12.12
     address-family vpnv4 unicast
     !
     neighbor 121.1.1.1
      remote-as 100
      address-family vpnv4 unicast   //and its vpnv4 unicast neighbor, support service for vrf-a1
      !
     !
     vrf vrf-a1                    //vrf-a1 here
      rd auto
      address-family ipv4 unicast
       redistribute static
      !
     !
    !
    router bgp 200 instance a2      // another bgp instance here
     bgp router-id 13.1.1.1
     address-family vpnv4 unicast
     !
     address-family ipv6 unicast
     !
     address-family l2vpn evpn
     !
     neighbor 122.1.1.1
      remote-as 100
      address-family vpnv4 unicast  //and its vpnv4 unicast neighbor,support service for a3
      !
      address-family l2vpn evpn
      !
     !
     vrf a3                     //a3 here
      rd 13.1.1.1:2<http://13.1.1.1:2>
      address-family ipv4 unicast
      !
     !

    Regards,
    Haibo

    -----Original Message-----
    From: Acee Lindem (acee) [mailto:acee@cisco.com<mailto:acee@cisco.com>]
    Sent: Friday, December 13, 2019 6:33 AM
    To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>; Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
    Cc: idr@ietf.org<mailto:idr@ietf.org>; draft-ietf-idr-bgp-model@ietf.org<mailto:draft-ietf-idr-bgp-model@ietf.org>; draft-ietf-rtgwg-ni-model@ietf.org<mailto:draft-ietf-rtgwg-ni-model@ietf.org>
    Subject: Re: [Idr] draft-ietf-idr-bgp-model

    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<mailto:idr-bounces@ietf.org> on behalf of jhaas@pfrc.org<mailto: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<mailto:jhaas@pfrc.org>]
        > Sent: Tuesday, August 27, 2019 4:39 AM
        > To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>>
        > Cc: draft-ietf-idr-bgp-model@ietf.org<mailto:draft-ietf-idr-bgp-model@ietf.org>; idr@ietf.org<mailto: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<mailto:Idr@ietf.org>
        https://www.ietf.org/mailman/listinfo/idr




_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr