Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt

From: "Yi Yang (yiya)" <[email-masked]>
Date: Fri, 7 Mar 2014 21:52:17 +0000

One thing is missing from the data model is association with vrf.

Another concern I have is about address family. To facilitate a query
based on AFI only, or SAFI only, it seems more convenient to use two leafs
(AFI and SAFI) instead of one (AFI-SAFI).

Yi

On 1/10/14 8:30 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the NETCONF Data Modeling Language Working
>Group of the IETF.
>
>        Title           : A YANG Data Model for Routing Management
>        Author          : Ladislav Lhotka
>	Filename        : draft-ietf-netmod-routing-cfg-13.txt
>	Pages           : 95
>	Date            : 2014-01-10
>
>Abstract:
>   This document contains a specification of three YANG modules.
>   Together they form the core routing data model which serves as a
>   framework for configuring and managing a routing subsystem.  It is
>   expected that these modules will be augmented by additional YANG
>   modules defining data models for individual routing protocols and
>   other related functions.  The core routing data model provides common
>   building blocks for such extensions - routing instances, routes,
>   routing information bases (RIB), routing protocols and route filters.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-13
>
>
>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/
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 7 Mar 2014 23:29:12 +0100

> One thing is missing from the data model is association with vrf.

I agree with what Martin wrote in a parallel thread. I believe the routing module (and YANG augment statement) provide sufficient hooks for implementing VRF as a specific type of routing-instance.

I think though that other work extending the routing module is much more needed, namely vendor-neutral data models for routing protocols.

The consensus of the NETMOD WG was that these new modules should be developed by experts in the Routing Area (VRF in the MPLS WG?). The NETMOD WG and YANG Doctors will certainly help but the bulk of this work should be done by domain experts.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Alia Atlas <[email-masked]>
Date: Sat, 8 Mar 2014 11:27:39 -0500

VRF would fit better in L3VPN.  I strongly agree that we need to start
doing therouting-related  YANG models in the routing working groups.  I do
think that some hand-holding is necessary.  Personally, despite having read
the YANG RFC several times and reading YANG models and thinking about
information models, I am still hesitant about trying to write a YANG model
that has the necessary considerations & trade-offs.

Alia

On Fri, Mar 7, 2014 at 5:29 PM, Ladislav Lhotka <[email-masked]> wrote:

> I agree with what Martin wrote in a parallel thread. I believe the routing
> module (and YANG augment statement) provide sufficient hooks for
> implementing VRF as a specific type of routing-instance.
>
> I think though that other work extending the routing module is much more
> needed, namely vendor-neutral data models for routing protocols.
>
> The consensus of the NETMOD WG was that these new modules should be
> developed by experts in the Routing Area (VRF in the MPLS WG?). The NETMOD
> WG and YANG Doctors will certainly help but the bulk of this work should be
> done by domain experts.
>
> Lada
>
> >
> > On 1/10/14 8:30 AM, "[email-masked]" <[email-masked]
> >
> > wrote:
> >
> >>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 09 Mar 2014 09:35:47 +0100

Hi Yi,

sorry, I forgot to address your second concern, so here is my reply:
 
> (AFI and SAFI) instead of one (AFI-SAFI).

Due to the properties of YANG identities (derivation), it will be possible to make queries based on either AFI or SAFI, or both. However, this requires two additions that are currently being proposed for YANG 1.1:

1. XPath function derived-from() - see draft-bjorklund-netmod-yang-xpath-extensions-00

2. Multiple inheritance of identities (it is actually a good use case for this feature). For example, the "ipv4-unicast" identity would be defined like so:

identity ipv4-unicast {
  base ipv4;
  base unicast;
}

I think identities are much more elegant compared to the two enumeration leafs "afn" and "safi" that we had in older revisions, even though it might currently need some workarounds.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 09 Mar 2014 09:46:34 +0100

> that has the necessary considerations & trade-offs.

Absolutely. This issue was discussed at some length during the meeting of YANG Doctors in London, and the conclusion was that a tutorial session held at one of the forthcoming IETF meetings would be useful.

Lada

---

From: "Derek Man-Kit Yeung (myeung)" <[email-masked]>
Date: Fri, 14 Mar 2014 19:32:32 +0000

On 3/7/14 2:29 PM, "Ladislav Lhotka" <[email-masked]> wrote:

>I agree with what Martin wrote in a parallel thread. I believe the
>routing module (and YANG augment statement) provide sufficient hooks for

The draft mentioned the routing-instance could be used to represents a
logical router. 

The term "logical router" in one or more vendors mean a partition of the
physical router into multiple logical units, each could have multiple VRFs.

Does the draft intend to manage "logical router" in the above definition?
Some clarification will be useful.

- Derek

>developed by experts in the Routing Area (VRF in the MPLS WG?). The
>NETMOD WG and YANG Doctors will certainly help but the bulk of this work
>should be done by domain experts.
>
>Lada
>
>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 14 Mar 2014 20:49:51 +0100

> Some clarification will be useful.

One way to implement this is to introduce two types of routing instances, say 'logical-router’ and ‘vrf’. The ‘vrf’ type then would have another leaf linking it to a logical router. This is quite like the various methods of interface stacking, see the examples in draft-ietf-netmod-interfaces-cfg-16.

Lada

---

From: "Derek Man-Kit Yeung (myeung)" <[email-masked]>
Date: Tue, 18 Mar 2014 23:03:58 +0000

On 3/14/14 12:49 PM, "Ladislav Lhotka" <[email-masked]> wrote:

>One way to implement this is to introduce two types of routing instances,
>say 'logical-router¹ and Œvrf¹. The Œvrf¹ type then would have another
>leaf linking it to a logical router. This is quite like the various
>methods of interface stacking, see the examples in
>draft-ietf-netmod-interfaces-cfg-16.
>
>Lada

It is one way. 
However, given that current model that everything is put inside a
routing-instance, things like RIB, routing-protocols etc are no longer
needed directly under the 'logical-router'.
What needed in the 'logical router' are resources allocation like
interfaces, CPU etc.
Though routing-instance could be augmented to include 'logical router'
specific field and add new condition to restrict existing leaf that no
long apply, I think a new container above routing-instance is cleaner. It
could be a new data model that reference the definition in the current
draft.

- Derek

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Mar 2014 08:51:15 +0100

> needed directly under the 'logical-router'.

Note that RIBs are not inside "routing-instance", although an implementation may define some RIBs to be routing-instance-specific.

> What needed in the 'logical router' are resources allocation like

"interfaces" is a container inside "routing-instance", and "cpu" can be easily added by another module via augmentation.

> could be a new data model that reference the definition in the current

I guess part of the confusion stems from the name "routing-instance" which already means a particular (platform-specific) style of router virtualization. Earlier revisions of the draft used "router" list in this place but it was an specific requirement of I2RS folks to change this name to "routing-instance". Oh well ...

So please keep in mind that "routing-instance" can really mean different things depending on its type (and can be augmented in different ways depending on the type). Again, this approach is very similar to the one adopted for the "interface" list in "ietf-interfaces" module.  

Lada

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Wed, 26 Mar 2014 02:09:53 +0000

Hi Lada,

In the current model, default-ribs will exist only when feature
multiple-ribs exists. This is contradictory to what people are familiar in
the real world deployment  -- default-ribs always exist.

To reflect such an expectation, I suggest to keep default-ribs
unconditionally. Instead, move the conditions to the ribs -- if feature
multiple-ribs doesn't exist, only one rib is allowed per address family.

Yi

On 3/19/14 3:51 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>>>On 14 Mar 2014, at 20:32, Derek Man-Kit Yeung (myeung)
>>><[email-masked]>
>>>wrote:
>>>
>>>> 
>>>> 
>Note that RIBs are not inside "routing-instance", although an
>implementation may define some RIBs to be routing-instance-specific.
>
>"interfaces" is a container inside "routing-instance", and "cpu" can be
>easily added by another module via augmentation.
>
>I guess part of the confusion stems from the name "routing-instance"
>which already means a particular (platform-specific) style of router
>virtualization. Earlier revisions of the draft used "router" list in this
>place but it was an specific requirement of I2RS folks to change this
>name to "routing-instance". Oh well ...
>
>So please keep in mind that "routing-instance" can really mean different
>things depending on its type (and can be augmented in different ways
>depending on the type). Again, this approach is very similar to the one
>adopted for the "interface" list in "ietf-interfaces" module.
>
>Lada
>
>>
>> - Derek
>>
>>>
>>>> 
>>>> - Derek
>>>> 
>>>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Mar 2014 14:25:40 +0100

Hi Yi,

> the real world deployment  -- default-ribs always exist.

Note that default-ribs depends on that feature only in configuration but not in operational state data. So, the idea is that the system puts the name(s) of default RIB(s) into the default-rib list in operational state, so the client is able to learn easily what the default (and only) RIB is for each address family. But whenever the server doesn't support multiple RIBs per address family, there is no point to have default-ribs as a configuration option.

Does it make sense?

Thanks, Lada

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Wed, 26 Mar 2014 20:53:28 +0000

Hi Lada,

Aha. So when multiple-ribs is not supported, the default-ribs only exist
in the operational but not in configuration.

But in that case, should we still allow users to configure the
corresponding rib entry in the ribs?

Yi

On 3/26/14 9:25 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Note that default-ribs depends on that feature only in configuration but
>not in operational state data. So, the idea is that the system puts the
>name(s) of default RIB(s) into the default-rib list in operational state,
>so the client is able to learn easily what the default (and only) RIB is
>for each address family. But whenever the server doesn't support multiple
>RIBs per address family, there is no point to have default-ribs as a
>configuration option.
>
>Does it make sense?
>
>Thanks, Lada
>
>>
>>>>>>> routing module (and YANG augment statement) provide sufficient
>>>>>>>hooks
>>>>>>>for
>>>>>> physical router into multiple logical units, each could have
>>>>>>multiple
>>>>>>VRFs.
>>>>>> 
>>>>>>>> based on AFI only, or SAFI only, it seems more convenient to use
>>>>>>>>two
>>>>>>>> leafs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Mar 2014 14:27:31 +0100

> in the operational but not in configuration.

Right.

> corresponding rib entry in the ribs?

It is still needed for specifying route filters between a routing protocol and the default routing table. This is done via the "connected-rib" list whose keys are references to routing tables. Since YANG doesn't allow leafrefs in configuration to point to state data, it is necessary to put even the default (system-controlled) RIB to the "rib" list and then refer to it from "connected-rib".

Perhaps it could be another YANG 1.1 issue to relax this rule about references from configuration to state data. They can often be useful and, as in this case, simplify the configuration.

Lada

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Thu, 27 Mar 2014 15:17:51 +0000

Hi Lada,

Inline...

On 3/27/14 9:27 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>It is still needed for specifying route filters between a routing
>protocol and the default routing table. This is done via the
>"connected-rib" list whose keys are references to routing tables. Since
>YANG doesn't allow leafrefs in configuration to point to state data, it
>is necessary to put even the default (system-controlled) RIB to the "rib"
>list and then refer to it from "connected-rib".

Actually, connected-ribs has a dependency on feature multiple-ribs as well.

+--rw connected-ribs {multiple-ribs}?

Yi

>
>Perhaps it could be another YANG 1.1 issue to relax this rule about
>references from configuration to state data. They can often be useful
>and, as in this case, simplify the configuration.
>
>Lada
>  
>>
>> Yi
>>
>>>> multiple-ribs exists. This is contradictory to what people are
>>>>familiar
>>>>in
>>>>>>>> The term "logical router" in one or more vendors mean a partition
>>>>>>>>of
>>>>>>>>the
>>>>>> long apply, I think a new container above routing-instance is
>>>>>>cleaner.
>>>>>>It
>>>>>>>>> I think though that other work extending the routing module is
>>>>>>>>>much
>>>>>>>>>more
>>>>>>>>> NETMOD WG and YANG Doctors will certainly help but the bulk of
>>>>>>>>>this
>>>>>>>>>work

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 27 Mar 2014 16:29:43 +0100

> +--rw connected-ribs {multiple-ribs}?

So this looks like a mistake, good that you spotted it! The possibility of filtering routes from/to routing protocol instances (which includes redistribution between protocols) is important even with a single RIB.

I will correct it in the next revision, probably/hopefully after IETF last call.

Thanks, Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2014 19:06:11 +0100

"Yi Yang (yiya)" <[email-masked]> writes:

> This brings up an interesting question -- how would a client know if an
> entry is system-controlled or user-controlled?

This is a good question. I think currently the answer is that the client can infer it from comparing the contents of configuration and operational state versions of the list. The server will reject all edits that are not allowed for system-controlled entries.

This might be another candidate for a global attribute.

Lada

>
> Yi 
>
>
>
> On 3/27/14 12:10 PM, "Ladislav Lhotka" <[email-masked]> wrote:
>
>>
>>On 27 Mar 2014, at 16:47, Yi Yang (yiya) <[email-masked]> wrote:
>>
>>> Hi Lada,
>>> 
>>> Back to the original question -- As routing-protocol's connected-ribs
>>>need
>>> to refer default ribs to configure the filters,  we still need these
>>> default-ribs to be shown under ribs. But we need only name for this,
>>> right? One thing I am concerned is, what if a client is trying to change
>>> the address family of a default rib?
>>
>>These default ribs are system-controlled entries, so the server will not
>>allow to do this, or even delete the entry. It is the same as with
>>system-controlled interfaces - the client must not be allowed to change
>>the type of a hardware interface.
>>
>>Lada
>>
>>> 
>>> Yi
>>> 
>>> 
>>> 
>>> On 3/27/14 11:29 AM, "Ladislav Lhotka" <[email-masked]> wrote:
>>> 
>>>> 
>>>> So this looks like a mistake, good that you spotted it! The possibility
>>>> of filtering routes from/to routing protocol instances (which includes
>>>> redistribution between protocols) is important even with a single RIB.
>>>> 
>>>>>>>> Note that default-ribs depends on that feature only in
>>>>>>>>configuration
>>>>>>>> but
>>>>>>>>>>>>>> I agree with what Martin wrote in a parallel thread. I
>>>>>>>>>>>>>>believe
>>>>>>>>>>>>>> the
>>>>>>>>>> "interfaces" is a container inside "routing-instance", and "cpu"
>>>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>>> specific field and add new condition to restrict existing leaf
>>>>>>>>>>> that
>>>>>>>>>>> no
>>>>>>>>>> virtualization. Earlier revisions of the draft used "router" list
>>>>>>>>>> in
>>>>>>>>>> this
>>>>>>>>>> depending on the type). Again, this approach is very similar to
>>>>>>>>>>the
>>>>>>>>>> one
>>>>>>>>>>>>>> The consensus of the NETMOD WG was that these new modules
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> developed by experts in the Routing Area (VRF in the MPLS
>>>>>>>>>>>>>>WG?).
>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>> Another concern I have is about address family. To
>>>>>>>>>>>>>>>facilitate
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> query
>>>>>>>>>>>>>>>> This draft is a work item of the NETCONF Data Modeling
>>>>>>>>>>>>>>>> Language
>>>>>>>>>>>>>>>> Working
>>>>>>>>>>>>>>>> Group of the IETF.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Together they form the core routing data model which serves
>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> framework for configuring and managing a routing subsystem.
>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> modules defining data models for individual routing
>>>>>>>>>>>>>>>>protocols
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> other related functions.  The core routing data model
>>>>>>>>>>>>>>>> provides
>>>>>>>>>>>>>>>> common
>>>>>>>>>>>>>>>> routing information bases (RIB), routing protocols and
>>>>>>>>>>>>>>>>route
>>>>>>>>>>>>>>>> filters.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-c
>>>>>>>>>>>>>>>>fg
>>>>>>>>>>>>>>>> /
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-c
>>>>>>>>>>>>>>>>fg
>>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Please note that it may take a couple of minutes from the
>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> submission

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Fri, 28 Mar 2014 18:21:47 +0000

On 3/28/14 2:06 PM, "Ladislav Lhotka" <[email-masked]> wrote:

>This is a good question. I think currently the answer is that the client
>can infer it from comparing the contents of configuration and operational
>state versions of the list. The server will reject all edits that are not
>allowed for system-controlled entries.

That might become messy in some cases.

>This might be another candidate for a global attribute.

I agree.

Yi

>>>>>>> YANG doesn't allow leafrefs in configuration to point to state
>>>>>>>data,
>>>>>>>it
>>>>>> Actually, connected-ribs has a dependency on feature multiple-ribs
>>>>>>as
>>>>>> well.
>>>>>> 
>>>>>>>>> not in operational state data. So, the idea is that the system
>>>>>>>>>puts
>>>>>>>>> the
>>>>>>>>> name(s) of default RIB(s) into the default-rib list in
>>>>>>>>>operational
>>>>>>>>> state,
>>>>>>>>> RIBs per address family, there is no point to have default-ribs
>>>>>>>>>as
>>>>>>>>>a
>>>>>>>>> configuration option.
>>>>>>>>> 
>>>>>>>>> Does it make sense?
>>>>>>>>> 
>>>>>>>>> Thanks, Lada
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>>>>>> One thing is missing from the data model is association
>>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>>> vrf.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Does the draft intend to manage "logical router" in the
>>>>>>>>>>>>>>above
>>>>>>>>>>>>>> definition?
>>>>>>>>>>>>> One way to implement this is to introduce two types of
>>>>>>>>>>>>>routing
>>>>>>>>>>>>> instances,
>>>>>>>>>>>>> say 'logical-router¹ and Œvrf¹. The Œvrf¹ type then would
>>>>>>>>>>>>>have
>>>>>>>>>>>>> another
>>>>>>>>>>>> However, given that current model that everything is put
>>>>>>>>>>>>inside
>>>>>>>>>>>>a
>>>>>>>>>>>> routing-instance, things like RIB, routing-protocols etc are
>>>>>>>>>>>>no
>>>>>>>>>>>> longer
>>>>>>>>>>> place but it was an specific requirement of I2RS folks to
>>>>>>>>>>>change
>>>>>>>>>>> this
>>>>>>>>>>>>>>>> based on AFI only, or SAFI only, it seems more convenient
>>>>>>>>>>>>>>>>to
>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>> leafs
>>>>>>>>>>>>>>>>> expected that these modules will be augmented by
>>>>>>>>>>>>>>>>>additional
>>>>>>>>>>>>>>>>> YANG

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2014 11:33:38 -0700

> This might be another candidate for a global attribute.

This is exactly why I added the <with-metadata> parameter in the <get2>
operation.
IMO using identity-stmt is better than inventing a new statement,
but we agree on the general concept.

IMO NETCONF needs most of NETCONF-EX in order to be aligned with RESTCONF.
The <get2> and <edit2> operations solve many issues with CRUD operations.
The capability-id and config-id capabilities need to be added to support
standard caching.

If there was a standard "Conditional Enablement" for NETCONF datastores,
then the
default P-container would be a lot more useful.  This is a general feature
that should not be
added to each list as an "enabled" leaf.  The operator should be able to
disable config
(as long as the YANG validation still passes).

Also, a P-container can be augmented, and an 'enabled' leaf cannot.
If there was a default-presence-stmt then a P-container could be used
instead
of a boolean leaf with a default.

BTW, empty type cannot have a default other than "not present", since there
would
be no way to specify a non-default value.

Lada

Andy

> >>>>>>>>>>>> say 'logical-router¹ and OEvrf¹. The OEvrf¹ type then would have
> >>>>>>>>>>>> another