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

["Acee Lindem (acee)" <[e-mail]>]

Since each protocol has its own AF specific constructs and local RIB with varying applicable route attributes, I don’t think more consolidation is desirable.
Thanks,
Acee

From: Susan Hares <[e-mail]>
Date: Monday, March 25, 2019 at 9:50 PM
To: Tom Petch <[e-mail]>, "Rajiv Asati (rajiva)" <[e-mail]>, Acee Lindem <[e-mail]>, Xufeng Liu <[e-mail]>, Mahesh Jethanandani <[e-mail]>
Cc: IDR List <[e-mail]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt

 Tom:

Thank you for pointing out the problems with a common address family.   During the lifetime of this draft, it has been one challenges.

In your opinion, do any of the options help with NMDA?

Sue

On Wednesday 20/03/2019 at 12:18 pm, tom petch wrote:

----- Original Message -----
From: "Rajiv Asati (rajiva)" <[e-mail]>
To: "Acee Lindem (acee)" <[e-mail]>; "Xufeng Liu"
<[e-mail]>; "Mahesh Jethanandani"
<[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, March 20, 2019 3:04 PM
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt



Indeed.

It would be useful to have routing protocol independent structure for
address-family and minimize the duplication in abstraction (and
implementations).

If you can agree what an address family is.

I know it as part of BGP and then came across it in other YANG modules
and ended up concluding that there was no common ground as to what an
address family is. I think that RFC8349 got it wrong in its use of
address family.

So, define an address family and I will show you why it does not apply
in all cases!

Tom Petch


--
Cheers,
Rajiv

From: Idr <[e-mail]> on behalf of "Acee Lindem (acee)"
<[e-mail]>

Date: Wednesday, March 20, 2019 at 10:57 AM
To: Xufeng Liu <[e-mail]>, Mahesh Jethanandani
<[e-mail]>

Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt

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]<mailto:[e-mail]>> wrote:

Hi Xufeng,



On Mar 19, 2019, at 6:31 AM, Xufeng Liu
<[e-mail]<mailto:[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]<mailto:[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]<mailto:[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<http://tools.ietf.org/>.


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>



_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>





------------------------------------------------------------------------
--------



_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr