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

Yingzhen Qu <yingzhen.ietf@gmail.com> Tue, 19 November 2019 06:05 UTC

Return-Path: <yingzhen.ietf@gmail.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 B1F88120834; Mon, 18 Nov 2019 22:05:51 -0800 (PST)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fRY__AmaPd1K; Mon, 18 Nov 2019 22:05:44 -0800 (PST)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D042C120829; Mon, 18 Nov 2019 22:05:43 -0800 (PST)
Received: by mail-io1-xd2c.google.com with SMTP id i13so21849399ioj.5; Mon, 18 Nov 2019 22:05:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sDtnYiq8lv+Qp+hnDznXkQ1x5tzpswBWzxBr1mGo3cw=; b=e5EzZJi8zk/uwgtfLUMpmzQ7xRq2umFu2waH67OpiLwnT/g+2tyRluCjbndYM7PhOb bZEl+7Hv8edIMqd5QCoiTMea+48aYF+f/RckOjPOhUGrgoNvLNgzmsez/J2pKVVZo77F ET5vUykRyMaQ/dJ8NfRmiykstiK7/SA32km0LDygPdO0hGj94RVFq3SvNhB9iKXn60m3 I++m431EQOvrRtr0iAMvlavOOpEmyfqdhQxKg8jjkBdc0j1Vx38xtRmhw/l4systR7Yi VDBcHnlNZ3Jq/49QDJ+d44VX1chWXSlPE7BRvwdMLJZNSab5hvurFrJd+Gl9rSI6OdgI NjtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sDtnYiq8lv+Qp+hnDznXkQ1x5tzpswBWzxBr1mGo3cw=; b=mbA6PwhD3Bi64Ws0ZDHd+Ih2jcKUzpYEOYg2K11Tt9MaDuPm6b0Rkw93nDuXnAo/k0 pX2dxhb2dnx1URuUDf16l/YSJ8HMWH0dMq/Giu/bjPWmzjdR7CvQRZwQu5kPhtDer2Mo 2YcBtMnwOT73xmFKwjUxq1mPC8aPYwReg6ZcB1GUH8JG+96JS74CccFpFpEOXAGWgABI fPyZJFZe1cxErmqVFmiiv94lyRFbhPQV7UUPPQ8O7164PkCpwKs/XvbNOemX10i5LLAF zwJIvr5u+rAlKfpVFwh+SW1wH/99J6uE/1P7iRRjoRzmCwlj7oJ90ZYdwxurs6aT78Dx fAhA==
X-Gm-Message-State: APjAAAVDpRjLab2tSLvVkTShfzeRM5LCt8FZnMhxNdOGznn4mZzlKPiH MafkJkgpPuLxd10dmFQnYJ48AJX1j/2TACM3XQ==
X-Google-Smtp-Source: APXvYqx46OxdZOhR/f+vKP1El9t5Tdx6hPUYgf6iXTOyOJZswZgW0tAeqZy5h+Z09NcF0+il6M93WyB5/R/Hee8gfZs=
X-Received: by 2002:a6b:9204:: with SMTP id u4mr15400222iod.99.1574143542831; Mon, 18 Nov 2019 22:05:42 -0800 (PST)
MIME-Version: 1.0
References: <1E61161D6E31D849BEA887261DB609348C8F2E20@nkgeml514-mbx.china.huawei.com> <20190826203850.GH24671@pfrc.org> <1E61161D6E31D849BEA887261DB609348C90DB78@nkgeml514-mbx.china.huawei.com> <20191118110851.GK21134@pfrc.org> <1E61161D6E31D849BEA887261DB609348C9DC694@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <1E61161D6E31D849BEA887261DB609348C9DC694@nkgeml514-mbx.china.huawei.com>
From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Date: Mon, 18 Nov 2019 22:03:54 -0800
Message-ID: <CABY-gOM=YDN8gQUAXW2KeiGdXMxBUKiiZAkCiFEGG5SQUaNoXA@mail.gmail.com>
To: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-bgp-model@ietf.org" <draft-ietf-idr-bgp-model@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b230780597acdab2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NK_EXSHjZbEidWEcwPrQe_PI5BM>
Subject: Re: [Idr] =?utf-8?b?562U5aSNOiBkcmFmdC1pZXRmLWlkci1iZ3AtbW9kZWw=?=
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: Tue, 19 Nov 2019 06:05:52 -0000

Hi Jeff,

I would think it makes more sense to do this binding in BGP module because
it is sort of a special case related with BGP, but I'm not sure what's the
best way to do it.

possible solutions:
1. add a reference
2. add a configuration
3.  ...

Thanks,
Yingzhen

On Mon, Nov 18, 2019 at 8:49 AM Wanghaibo (Rainsword) <
rainsword.wang@huawei.com>; wrote:

> 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
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>