[Idr] 答复: draft-ietf-idr-bgp-model

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Mon, 18 November 2019 16:49 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 F3D561208B8; Mon, 18 Nov 2019 08:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RnZrb7rYhzUz; Mon, 18 Nov 2019 08:49:26 -0800 (PST)
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 7FD8D120983; Mon, 18 Nov 2019 08:49:26 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D1FAB8C32597F68292F0; Mon, 18 Nov 2019 16:49:22 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Nov 2019 16:49:22 +0000
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; Tue, 19 Nov 2019 00:49:11 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: "draft-ietf-idr-bgp-model@ietf.org" <draft-ietf-idr-bgp-model@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-ietf-idr-bgp-model
Thread-Index: AQHVngAITL9qmcpxHE+mw9GI+TfeqKeRHvUw
Date: Mon, 18 Nov 2019 16:49:11 +0000
Message-ID: <1E61161D6E31D849BEA887261DB609348C9DC694@nkgeml514-mbx.china.huawei.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: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.40.143]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KFapx3HNE00oikCoH3VZe0FwOyU>
Subject: [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: Mon, 18 Nov 2019 16:49:29 -0000

Hi Jeff,

	My question is similar to "how do you bind a given routing instance (e.g. VRF) to a given BGP session?"

    Now multiple vendors have implemented this feature. 
    They don't bind a vrf to a given BGP session, but bind to different public bgp instance. 

	For example:
    bgp instance 1 as 100
      neighbor A remote-as 100
       address-family ipv4-vpn, evpn enabled
      neighbor B remote-as 200
       address-family ipv4-vpn enabled
    bgp instance 2 as 200
      neighbor C remote-as 200
       address-family evpn enabled
    vrf vrf1
      bgp instance-toCE1 as 65001
       neighbors ...
    vrf vrf2 
      ospf instance-toCE2
       areas...

    Vrf1 bind to bgp instance 1
    Vrf1's VPN routes will advertised through bgp instance 1's neighbor A&B, through VPNv4 or EVPN family
    Vrf2 bind to bgp instance 2
    Vrf2's VPN routes will advertised through bgp instance 2's neighbor C, through EVPN family.
	The two bgp instance are separate from each other.

    It seems like vrf1 bind to neighbor A&B, vrf2 bind to neighbor C.
    But the neighbors are contained in a bgp instance. ( neighbor A&B in bgp instance 1, neighbor C in bgp instance2)
    
	According to RFC8022, we can create multiple bgp instance for public routing.
    But now we cannot specify one vrf how to bind to one bgp instance's according to current bgp model.

Regards,
Haibo

-----邮件原件-----
发件人: Jeffrey Haas [mailto:jhaas@pfrc.org] 
发送时间: 2019年11月18日 19:09
收件人: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
抄送: draft-ietf-idr-bgp-model@ietf.org; idr@ietf.org
主题: Re: [Idr] draft-ietf-idr-bgp-model

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