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

[Xufeng Liu <[e-mail]>]

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]
>
>
>
>