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

From: "Dale W. Carder" <[email-masked]>
Date: Fri, 1 Mar 2019 13:21:59 -0600

Hi Mahesh,

On a quick glance through, it looks like there is no support for rfc5082?

And as a side note, is there a reference as to how divergent this is to
the openconfig model?

best,
Dale

Thus spake Mahesh Jethanandani ([email-masked]) on Tue, Feb 26, 2019 at 10:19:58AM -0800:
> 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, [email-masked] 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/idr
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 19 Mar 2019 09:31:23 -0400

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).

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.

Thanks,
- Xufeng

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 19 Mar 2019 15:48:08 -0700

Hi Xufeng,

> On Mar 19, 2019, at 6:31 AM, Xufeng Liu <[email-masked]> wrote:
> 
> Hi Mahesh,
> 
> Thanks for the update. 
> 
> 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.
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> > On Feb 26, 2019, at 10:16 AM, [email-masked] <mailto:[email-masked]> wrote:
> > 
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ <https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/>
> > 
> > https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04 <https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04>
> > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-04 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-04>
> > 
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-model-04 <https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-model-04>
> > 
> > 
> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> > 
> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 19 Mar 2019 15:58:49 -0700

Hi Dale,

> On Mar 1, 2019, at 11:21 AM, Dale W. Carder <[email-masked]> wrote:
> 
> 
> Hi Mahesh,
> 

That is correct. Support for TTL security check is considered an optional feature, and is left to each vendor to decide whether they want to support it or not. 

What the model can do is to add a feature statement in the model, and leave it each vendor to decide if and how they want to support it.

> And as a side note, is there a reference as to how divergent this is to

Good question. I have not looked at the Openconfig BGP YANG model of late, so cannot say how divergent it is. One major difference is that this YANG model has support for NMDA.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 20 Mar 2019 10:29:14 -0400

Hi Mahesh,

> 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

> On Tue, Feb 26, 2019 at 1:20 PM Mahesh Jethanandani <
> [email-masked]> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 20 Mar 2019 14:56:42 +0000

I agree – the BGP hierarchy is wrong. Address-family is generally higher both abstractly and in implementations.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Xufeng Liu <[email-masked]>
Date: Wednesday, March 20, 2019 at 10:30 AM
To: Mahesh Jethanandani <[email-masked]>
Cc: IDR List <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Xufeng,

On Mar 19, 2019, at 6:31 AM, Xufeng Liu <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mahesh,

Thanks for the update.

1) rib extension

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

module: ietf-routing
  +--rw routing

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

Thanks,
- Xufeng

Thanks.

Thanks,
- Xufeng

On Tue, Feb 26, 2019 at 1:20 PM Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:
This update of the draft adds support for:

Comments welcome.

> On Feb 26, 2019, at 10:16 AM, [email-masked]<mailto:[email-masked]> wrote:
>
>
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>
> [email-masked]<mailto:[email-masked]>

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

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

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 20 Mar 2019 15:04:26 +0000

Indeed.

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

--
Cheers,
Rajiv

From: Idr <[email-masked]> on behalf of "Acee Lindem (acee)" <[email-masked]>
Date: Wednesday, March 20, 2019 at 10:57 AM
To: Xufeng Liu <[email-masked]>, Mahesh Jethanandani <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt

Hi Mahesh,

Hi Mahesh,

Thanks for the update.

1) rib extension

module: ietf-routing
  +--rw routing

module: ietf-routing
  +--rw routing

module: ietf-routing
  +--rw routing

Thanks,
- Xufeng

Thanks.

Thanks,
- Xufeng

Comments welcome.

Mahesh Jethanandani

Mahesh Jethanandani

---

From: tom petch <[email-masked]>
Date: Wed, 20 Mar 2019 16:17:57 +0000

----- Original Message -----
From: "Rajiv Asati (rajiva)" <[email-masked]>
To: "Acee Lindem (acee)" <[email-masked]>; "Xufeng Liu"
<[email-masked]>; "Mahesh Jethanandani"
<[email-masked]>
Cc: <[email-masked]>
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

> I agree – the BGP hierarchy is wrong. Address-family is generally
higher both abstractly and in implementations.
> On Tue, Mar 19, 2019 at 6:48 PM Mahesh Jethanandani
<[email-masked]<mailto:[email-masked]>> wrote:
> Hi Xufeng,
>
>
>
> On Mar 19, 2019, at 6:31 AM, Xufeng Liu
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.
> 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:
> 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.
> On Tue, Feb 26, 2019 at 1:20 PM Mahesh Jethanandani
<[email-masked]<mailto:[email-masked]>> wrote:
> > On Feb 26, 2019, at 10:16 AM,
> [email-masked]<mailto:[email-masked]>

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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 20 Mar 2019 11:06:25 -0700

+1

Cheers,
Jeff
On Mar 20, 2019, 7:57 AM -0700, Acee Lindem (acee) <[email-masked]>, wrote:
> On Tue, Mar 19, 2019 at 6:48 PM Mahesh Jethanandani <[email-masked]> wrote:
> > Hi Xufeng,
> >
> >
> > > On Tue, Feb 26, 2019 at 1:20 PM Mahesh Jethanandani <[email-masked]> wrote:

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 21 Mar 2019 19:02:22 -0700

The next version of the draft (-05) to be posted on Monday, will update the model to mirror the structure similar to OSPF and IS-IS.

> On Mar 20, 2019, at 7:29 AM, Xufeng Liu <[email-masked]> wrote:
> 
> Hi Mahesh,
> 
> On Tue, Mar 19, 2019 at 6:48 PM Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Xufeng,
> 
>> On Mar 19, 2019, at 6:31 AM, Xufeng Liu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Mahesh,
>> 
>> Thanks for the update. 
>> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 22 Mar 2019 15:26:20 -0700

Hi Acee,

How do you propose to change the hierarchy? 

Keep in mind that it is not just implementation, but other factors that should guide the layout. For example, how are routes accessed, or how are routes going to be cleared. I will need specifics on what the hierarchy should look like, and what are the keys going to be in each of the lists. 

For example, in the current outlay (see attached file), the address-family is how the tree is divided. Then within each address-family, the routes are keyed on prefix, origin, and path-id.

Thanks

> On Mar 20, 2019, at 7:56 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> From: Idr <[email-masked] <mailto:[email-masked]>> on behalf of Xufeng Liu <[email-masked] <mailto:[email-masked]>>
> To: Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>
> Cc: IDR List <[email-masked] <mailto:[email-masked]>>
Mahesh Jethanandani
[email-masked]