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

[Susan Hares <[e-mail]>]

 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