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

Robert Raszuk <robert@raszuk.net> Fri, 13 December 2019 13:41 UTC

Return-Path: <robert@raszuk.net>
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 D1A96120168 for <idr@ietfa.amsl.com>; Fri, 13 Dec 2019 05:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.754
X-Spam-Level:
X-Spam-Status: No, score=-0.754 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 juZ3vL_X-hMx for <idr@ietfa.amsl.com>; Fri, 13 Dec 2019 05:41:03 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 AA167120835 for <idr@ietf.org>; Fri, 13 Dec 2019 05:41:02 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id r14so1665256qke.13 for <idr@ietf.org>; Fri, 13 Dec 2019 05:41:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZoEB2xyjBQNm3YcxEnfvf6eMKVHZJ4vqpv+65naXtOo=; b=RTuKPgtUBlwiZlGYjLucTVB1WDq8kPGftHIYxFhrBXEdCqscn1DpUVL5v5+iv4JFwP ZiKo6X3eF4tiPLMUCDwUJraPW5b2bVWwtEl+MqKUggEyelg01BT/pwzuIehaTVxVSaqC d6uGGnd9jiKVnTsK+xVclfT67HVeSYH1A8LUJIlXIoYlMlgSwBtHB+hkrIV7vCZVZ78W 5pEiVrUsPygpJKjJDi/JLd8/cPlGFddqF26rIET4T3RtwGGNJx288FjWlC2QKGhP+xSJ 30EXxI04lXZ/B/MC60ZNWg3ZdJlma4zYOMZfGjOwYgvXpe8FAwkzw/zt++fSvG4C+zgH w6dg==
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=ZoEB2xyjBQNm3YcxEnfvf6eMKVHZJ4vqpv+65naXtOo=; b=r8O7Aa7mwSGp394SqruoeMeP89rIaax7NZnAysOPPKD9bHnRsE07pGY1EUVRTGJ+YO AmGqhIxbTDtKSfW9cqx0qtUD+zhbSYeLH0eOGKZu1WXjjBMGVxStpP/KRO5RRpPyX7pt jJiGPphRKGDoq0Thn9uPbLmGb2E1pRwpIt1EM5g3rsCu0c6DccShdIGx+HjiVGCNSnZJ LoFIcGQ7RM21brvX06IrvmoFD9KdqeLV5aG0zA59V4qmJs117XSSfTunX/k6WFy9mCsA fITkEA9Y524vvOq7lWrEjfnq8vU2WiE68a311icTCq8+EldAp9BluEjgbXERJ8e+dlqC jbnA==
X-Gm-Message-State: APjAAAUapw93dd312NMzxmn8lDaBf/FDd7SB+Yx7HYTnfrmLM9x+nI2c WLbRDWvq2+hculQ66//XBFt4WrZsGeVs5LaMPrtbV5NK
X-Google-Smtp-Source: APXvYqyLwRo3m0tl+ROYeZ+1cRx45KjtKllLUY6GM6yjbHi1Avad0PwKoz+D6BG7jShV0Xh3slAj0AzoT6qtmEgSr64=
X-Received: by 2002:a37:693:: with SMTP id 141mr13412323qkg.134.1576244461439; Fri, 13 Dec 2019 05:41:01 -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> <38672C45-991E-42F6-8D2A-E001C7F0D75A@cisco.com> <1E61161D6E31D849BEA887261DB609348CA1D40F@nkgeml514-mbx.china.huawei.com> <78B89452-BCF8-4941-B9BB-352C4477AF2C@cisco.com>
In-Reply-To: <78B89452-BCF8-4941-B9BB-352C4477AF2C@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 13 Dec 2019 14:40:46 +0100
Message-ID: <CAOj+MMHxMM3ThQy4pKusFbFGXGDJOAXA6iBM6N3UePT4LwjVFg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
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>
Content-Type: multipart/alternative; boundary="0000000000003422b90599960326"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/q-e9aM5Viwa-gqoCD-UGDpCLHLU>
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 13:41:06 -0000

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.

Best,
R,.


On Fri, Dec 13, 2019 at 1:30 PM Acee Lindem (acee) <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>
> 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
>       address-family ipv4 unicast
>       !
>      !
>
>     Regards,
>     Haibo
>
>     -----Original Message-----
>     From: Acee Lindem (acee) [mailto:acee@cisco.com]
>     Sent: Friday, December 13, 2019 6:33 AM
>     To: Jeffrey Haas <jhaas@pfrc.org>; Wanghaibo (Rainsword) <
> rainsword.wang@huawei.com>
>     Cc: idr@ietf.org; draft-ietf-idr-bgp-model@ietf.org;
> 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 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
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>