Subject: [netmod] draft-ietf-netmod-routing-cfg

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Nov 2015 18:20:21 +0000

We had a lot of good discussions at IETF 94 with respect to the
ietf-routing and how it could be augmented in the future to support I2RS.
These discussions are ongoing.

One current change that I would like to propose is to change the base
instance container from routing-instance to networking-instance. This
would provide an instance definition that could be augmented for L2
protocols and service functionality as well as L3. It is also consistent
with the term used in both
https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.

Thanks,
Acee

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Nov 2015 10:24:41 +0100 (CET)

Hi,

"Acee Lindem (acee)" <[email-masked]> wrote:
> instance container from routing-instance to networking-instance.

Is the idea to simply rename the "routing-instance" container to
"networking-instance"?

Then we would have:

   +--rw routing
      +--rw networking-instance

Would you keep the top-level name "routing"?

/martin

> This
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 24 Nov 2015 15:11:22 -0500

Martin,
> n Nov 24, 2015, at 4:24 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 
> Would you keep the top-level name "routing”?

Yes, routing is not confined to IP only. TRILL and PBB do routing at MAC layer, so routing as top level domain can stay. OTH, routing instance is well defined term in the industry, so there is a need to have a term that can encompass L2 and L3.

Dean

> Rtg-dt-yang-arch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Nov 2015 20:30:45 +0000

Hi Martin,
 
I think using the more generic term, “networking”, at the top would be
preferable. What we need is an instance abstraction that covers L3 (e.g.,
virtual router or VRF), L2 (e.g., Virtual Switch Instance), or a
combination (some EVPN, TRILL, etc). This could be used in lieu of each L2
model creating their own top separate list of instances. For example, the
networking-instance could be augmented with both the VPLS and VPWS
instances in https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00.

Some YANG models ascribe greatness from the start, others achieve
greatness through refinement, while still others have greatness thrust
upon them. routing-cfg would fall into the last category…

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Nov 2015 09:26:36 +0100

"Acee Lindem (acee)" <[email-masked]> writes:

> preferable. What we need is an instance abstraction that covers L3

Hmm, shall we also rename "routing-protocol" to "networking-protocol"?
Seriously, I am concerned that we are drifting away from the original
focus of the data model. We should keep in mind it needs to remain
usable by hosts (even constrained ones) and simple routers because there
is no other model such devices could use.

> (e.g., virtual router or VRF), L2 (e.g., Virtual Switch Instance), or
> a combination (some EVPN, TRILL, etc). This could be used in lieu of
> each L2 model creating their own top separate list of instances. For
> example, the networking-instance could be augmented with both the VPLS
> and VPWS instances in
> https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00.
>

If it ever gets finished.

Lada

> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

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