Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt

[Jeff Tantsura <[e-mail]>]

+1

Cheers,
Jeff
On Mar 20, 2019, 7:57 AM -0700, Acee Lindem (acee) <[e-mail]>, wrote:
> I agree – the BGP hierarchy is wrong. Address-family is generally higher both abstractly and in implementations.
> Thanks,
> Acee
>
> From: Idr <[e-mail]> on behalf of Xufeng Liu <[e-mail]>
> Date: Wednesday, March 20, 2019 at 10:30 AM
> To: Mahesh Jethanandani <[e-mail]>
> Cc: IDR List <[e-mail]>
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt
>
> Hi Mahesh,
>
> On Tue, Mar 19, 2019 at 6:48 PM Mahesh Jethanandani <[e-mail]> wrote:
> > Hi Xufeng,
> >
> >
> > > On Mar 19, 2019, at 6:31 AM, Xufeng Liu <[e-mail]> wrote:
> > >
> > > Hi Mahesh,
> > >
> > > Thanks for the update.
> > >
> > > I'd like to comment on the new changes at a high level:
> > >
> > > 1) rib extension
> > > This paradigm is inconsistent with other protocol models like ospf and isis, where the protocol specific routes are kept under the protocol instance tree, not under the /rt:routing/rt:ribs. Based on RFC8349, the /rt:routing/rt:ribs tree is used to model the routes per routing instance, which is better mapped to the Route Manager (whose name varies depending on the implementations).
> > >
> >
> > While that might be true, routes in the BGP model currently are maintained at the per-address family level.
>
> It is fine that routes are maintained at per-address family level, which is also done by other routing protocols. The question is how the tree hierarchy is structured.
> OSPF model has the following:
>
> module: ietf-routing
>   +--rw routing
>   |  +--rw control-plane-protocols
>   |  |  +--rw control-plane-protocol* [type name]
>   |  |     +--rw ospf:ospf
>   |  |        +--ro ospf:protected-routes {fast-reroute}?
>   |  |        |  +--ro ospf:af-stats* [af prefix alternate]
>   |  |        |     +--ro ospf:af   iana-rt-types:address-family
>   |  |        +--ro ospf:unprotected-routes {fast-reroute}?
>   |  |        |  +--ro ospf:af-stats* [af prefix]
>   |  |        |     +--ro ospf:af        iana-rt-types:address-family
>   |  |        +--ro ospf:local-rib
>   |  |        |  +--ro ospf:route* [prefix]
>   |  |        |     +--ro ospf:prefix        inet:ip-prefix
>   |  |        |     +--ro ospf:next-hops
>   |  |        +--ro ospf:statistics
>   |  |        +--ro ospf:database
>   |  |        |  +--ro ospf:as-scope-lsa-type* [lsa-type]
>
> ISIS model has the following:
>
> module: ietf-routing
>   +--rw routing
>   |  +--rw control-plane-protocols
>   |  |  +--rw control-plane-protocol* [type name]
>   |  |     +--rw isis:isis
>   |  |        +--rw isis:interfaces
>   |  |        |  +--rw isis:interface* [name]
>   |  |        |     +--rw isis:name   if:interface-ref
>   |  |        +--ro isis:database
>   |  |        |  +--ro isis:level-db* [level]
>   |  |        |     +--ro isis:level    level-number
>   |  |        |     +--ro isis:lsp* [lsp-id]
>   |  |        |        +--ro isis:decoded-completed?   boolean
>   |  |        |        +--ro isis:raw-data?     yang:hex-string
>   |  |        |        +--ro isis:lsp-id        lsp-id
>   |  |        +--ro isis:local-rib
>   |  |        |  +--ro isis:route* [prefix]
>   |  |        |     +--ro isis:prefix       inet:ip-prefix
>   |  |        |     +--ro isis:next-hops
>
>
> This BGP model uses operational state sub-tree mostly from the OpenConfig model, but OpenConfig does not augment ietf-routing and uses separate global tree. If we keep the OpenConfig sub-tree, it would be better to structure the BGP rip as following:
>
> module: ietf-routing
>   +--rw routing
>   |  +--rw control-plane-protocols
>   |  |  +--rw control-plane-protocol* [type name]
>            +--rw bgp:bgp
>               +--rw global!
>               +--rw neighbors
>               |  +--rw neighbor* [neighbor-address]
>               +--rw peer-groups
>                  +--rw peer-group* [peer-group-name]
>               +--ro bgp-rib
>                  +--ro attr-sets
>                  |  +--ro attr-set* [index]
>                  |     +--ro index                   uint64
>                  +--ro afi-safis
>                     +--ro afi-safi* [afi-safi-name]
>                        +--ro afi-safi-name       identityref
>                        +--ro ipv4-unicast
>                        |  +--ro loc-rib
>                        |  |  +--ro routes
>                        |  |     +--ro route* [prefix origin path-id]
>                        +--ro ipv6-unicast
>                        |  +--ro loc-rib
>                        |  |  +--ro routes
>                        |  |     +--ro route* [prefix origin path-id]
>                        +--ro ipv4-srte-policy
>                        |  +--ro loc-rib
>                        |  |  +--ro routes
>                        |  +--ro neighbors
>                        |     +--ro neighbor* [neighbor-address]
>                        +--ro ipv6-srte-policy
>                           +--ro loc-rib
>                           |  +--ro routes
>
> Thanks,
> - Xufeng
>
> > > 2) module ietf-bgp is missing
> > > Is it intentional to remove the main module ietf-bgp? The description says that bgp model augments the ietf-routing, but there is no such an augment statement in the draft. I assume that the augment statement is in the main module ietf-bgp.
> > >
> >
> > That was indeed a cut-and-paste error. The next version of the draft will have the ietf-bgp module.
> >
> > Thanks.
> >
> >
> > >
> > > Thanks,
> > > - Xufeng
> > >
> > > On Tue, Feb 26, 2019 at 1:20 PM Mahesh Jethanandani <[e-mail]> wrote:
> > > > This update of the draft adds support for:
> > > >
> > > > - augmentation of the Routing Management Model.
> > > > - augmentation of the routing policy model
> > > > - support for RIB
> > > >
> > > > Comments welcome.
> > > >
> > > > > On Feb 26, 2019, at 10:16 AM, [e-mail] wrote:
> > > > >
> > > > >
> > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > > > This draft is a work item of the Inter-Domain Routing WG of the IETF.
> > > > >
> > > > >        Title           : BGP YANG Model for Service Provider Networks
> > > > >        Authors         : Keyur Patel
> > > > >                          Mahesh Jethanandani
> > > > >                          Susan Hares
> > > > >       Filename        : draft-ietf-idr-bgp-model-04.txt
> > > > >       Pages           : 138
> > > > >       Date            : 2019-02-26
> > > > >
> > > > > Abstract:
> > > > >   This document defines a YANG data model for configuring and managing
> > > > >   BGP, including protocol, policy, and operational aspects based on
> > > > >   data center, carrier and content provider operational requirements.
> > > > >
> > > > >
> > > > > The IETF datatracker status page for this draft is:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/
> > > > >
> > > > > There are also htmlized versions available at:
> > > > > https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-04
> > > > >
> > > > > A diff from the previous version is available at:
> > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-model-04
> > > > >
> > > > >
> > > > > Please note that it may take a couple of minutes from the time of submission
> > > > > until the htmlized version and diff are available at tools.ietf.org.
> > > > >
> > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > >
> > > > > _______________________________________________
> > > > > Idr mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/idr
> > > >
> > > > Mahesh Jethanandani
> > > > [e-mail]
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Idr mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/idr
> >
> > Mahesh Jethanandani
> > [e-mail]
> >
> >
> >
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr