Subject: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 19 Jun 2014 18:28:41 +0000

Ladislav,

Dean and I have some late questions and comments. We came across these while trying to work on the OSPF YANG model.

-----------

The spec mentions in several places something like the following:

   Each routing protocol instance is connected to exactly one RIB for
   each address family that the routing protocol instance supports.

My understanding is that the address family mentioned above does not include SAFI. Because of that, a routing protocol like BGP may connect to multiple RIBs in the same family (RIB for unicast and RIB for multicast RPF purpose in case of incongruent multicast topology) so the above statement is not correct.

This is also a problem in case of Multi-topology. Each topology has its own RIB and a protocol instance like OSPF can connect to multiple MT RIBs.

------

5.1.  Routing Instance

   Each routing instance in the core routing data model represents a
   logical router.  The exact semantics of this term are left to
   implementations.  For example, routing instances may be completely
   isolated virtual routers or, alternatively, they may internally share
   certain information.

   ...

   An implementation MAY support multiple types of logical routers
   simultaneously.  Instances of all routing instance types are
   organized as entries of the same flat "routing-instance" list.  In
   order to discriminate routing instances belonging to different types,
   the "type" leaf is defined as a child of the "routing-instance" node.

The spec purposely left it fuzzy as to what a "routing instance" is. However we definitely should have clear definitions for the three terms mentioned: routing-instance, logical router and virtual router.

Logical router is a very overload term. Today vendors have virtualized their routing capabilities in the system and provide 3 different levels of routing virtualization. Logical systems, logical routers are some of the names used by vendors and those offer routing and management separation. Each logical system has its own routing instances and routing instances can have multiple routing tables, so it is very important to have very precise definition of what is routing instance (and not compare it with logical router)

     identity standard-routing-instance {
       base routing-instance-type;
       description
         "This identity represents a default routing instance.";
     }

What is a "standard-routing-instance"? Would "default-routing-instance" be better? "standard" wording leads to "standard vs. non-standard" question and hints on that the two are different types. "default" vs. "non-default" does not have that (at least to me).

Should this spec distinguish VRF/VR/LR and have corresponding identities defined?

         leaf type {
           type identityref {
             base routing-instance-type;
           }
           description
             "The routing instance type, primarily intended for
              discriminating among different types of logical routers,
              route virtualization, master-slave arrangements etc.,
              while keeping all routing instances in the same flat
              list.";
         }

What is the "master-slave arrangements"?

Depending on the definition of "logical router" and "route virtualization", there may also be concerns with keeping all those kinds of in the same flat list.

Jeffrey Zhang
Dean Bogdanovic

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 20 Jun 2014 13:26:27 +0200

> Dean and I have some late questions and comments. We came across these while trying to work on the OSPF YANG model.

This is quite flexible since address family is defined via identities. I can imagine one implementation using only "ipv4" and "ipv6" (defined in ietf-routing) whilst other implementation could use "ipv[46]-unicast" (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to be defined in a module for unicast routing), that means including SAFI.

> This is also a problem in case of Multi-topology. Each topology has its own RIB and a protocol instance like OSPF can connect to multiple MT RIBs.

Two possible solutions come to my mind:

1. You could derive new address family identities from "ipv4-unicast" etc. so that you can assign a unique address family to multiple tables.

2. You could have one connected RIB e.g. for "ipv4-unicast" and define two or more RIBs for each topology as recipients of the connected RIB. So, in effect, the (single) connected RIB contains routes for all topologies and these are then split via route filters to the per-topology RIBs.

Does it make sense?

> The spec purposely left it fuzzy as to what a "routing instance" is. However we definitely should have clear definitions for the three terms mentioned: routing-instance, logical router and virtual…

Yes, this is by design open-ended because otherwise we would probably never reach consensus on what these terms exactly mean.

> What is a "standard-routing-instance"? Would "default-routing-instance" be better? "standard" wording leads to "standard vs. non-standard" question and hints on that the two are different types. "d…

Well, "default" is overloaded, too, and also has a specific meaning in YANG. Standard is supposed to mean plain vanilla router. It is just a name.

> Should this spec distinguish VRF/VR/LR and have corresponding identities defined?

The idea is this will be done in other modules that define data models for these types of routing instances. Then the "routing-instance" container can be augmented with arbitrary data, but conditionally for that routing instance type.

An implementation may actually use multiple routing-instance types at the same time.

> What is the "master-slave arrangements"?

This came from an early review by Thomas Morin, it has to do with MPLS/BGP VPNs where a master routing-instance exchanges selected routes with each VPN/VRF.

> Depending on the definition of "logical router" and "route virtualization", there may also be concerns with keeping all those kinds of in the same flat list.

It is similar to interfaces, where physical and logical interfaces of all kinds live in the same flat list and are distinguished by the type. I think it could work, relationships among the individual routing instances can be expressed in other data.

Having a single flat list has its advantages, for example you can then easily refer to routing instances via leafrefs (which allow only one path).

Cheers, Lada

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 20 Jun 2014 12:22:11 +0000

Lada,

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Friday, June 20, 2014 7:26 AM
> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; [email-masked]
> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
> 
> > Dean and I have some late questions and comments. We came across these
> while trying to work on the OSPF YANG model.
> >
> > -----------
> >
> > My understanding is that the address family mentioned above does not
> include SAFI. Because of that, a routing protocol like BGP may connect
> to multiple RIBs in the same family (RIB for unicast and RIB for
> multicast RPF purpose in case of incongruent multicast topology) so the
> above statement is not correct.
> 
> This is quite flexible since address family is defined via identities. I
> can imagine one implementation using only "ipv4" and "ipv6" (defined in
> ietf-routing) whilst other implementation could use "ipv[46]-unicast"
> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to be
> defined in a module for unicast routing), that means including SAFI.

Address Family has very specific meanings, typically only refer to IPv4/IPv6 to my understanding. If we want to extend that to include SAFI, then the spec must point it out. More below related to MT.

> 
> >
> > This is also a problem in case of Multi-topology. Each topology has
> its own RIB and a protocol instance like OSPF can connect to multiple MT
> RIBs.
> 
> 1. You could derive new address family identities from "ipv4-unicast"
> etc. so that you can assign a unique address family to multiple tables.
> 
> 2. You could have one connected RIB e.g. for "ipv4-unicast" and define
> two or more RIBs for each topology as recipients of the connected RIB.
> So, in effect, the (single) connected RIB contains routes for all
> topologies and these are then split via route filters to the per-
> topology RIBs.
> 
> Does it make sense?

Compare the two, I don't like #2 because it adds an unnecessary indirection. I don't think we want to overload "Address Family" further to include topology either. In many implementations, actual RIBs are per (routing-instance, AFI, SAFI, topology) and it may be extended further. Therefore, the best option is to simply remove the restriction that one protocol instance is connected to exactly one RIB per address family.

> > The spec purposely left it fuzzy as to what a "routing instance" is.
> However we definitely should have clear definitions for the three terms
> mentioned: routing-instance, logical router and virtual router.
> 
> Yes, this is by design open-ended because otherwise we would probably
> never reach consensus on what these terms exactly mean.

While the design needs to be open-ended a standard specification needs to be precise and unambiguous. The names can be discussed and compromised but the meaning must be clear. For example, Cisco "virtual router" and Juniper "logical router/system" are the same but Juniper "virtual router" and Cisco "VRF-lite" are the same. What does the "logical router" in this spec mean? We can't just say that "it can mean any of those". For example if it means Cisco's "virtual router" or Juniper's "logical system", a further discussion may be - should this module really cover that.

> 
> >
> > Logical router is a very overload term. Today vendors have virtualized
> their routing capabilities in the system and provide 3 different levels
> of routing virtualization. Logical systems, logical routers are some of
> the names used by vendors and those offer routing and management
> separation. Each logical system has its own routing instances and
> routing instances can have multiple routing tables, so it is very
> important to have very precise definition of what is routing instance
> (and not compare it with logical router)
> >
> > What is a "standard-routing-instance"? Would "default-routing-
> instance" be better? "standard" wording leads to "standard vs. non-
> standard" question and hints on that the two are different types.
> "default" vs. "non-default" does not have that (at least to me).
> 
> Well, "default" is overloaded, too, and also has a specific meaning in
> YANG. Standard is supposed to mean plain vanilla router. It is just a
> name.

I don't have to split hair between "standard" and "default" but the spec must point out what a "standard-routing-instance" is - is it the default/base/master logical-system (Cisco virtual-router) or the default/base/master "routing-instance" (a "logical-system" would include many "routing-instances" like VRFs).

> The idea is this will be done in other modules that define data models
> for these types of routing instances. Then the "routing-instance"
> container can be augmented with arbitrary data, but conditionally for
> that routing instance type.

I think it is important to define a few well known routing instance types in the base spec as a good foundation for other modules.

> An implementation may actually use multiple routing-instance types at

That's for sure and not what I'm concerned with.

> This came from an early review by Thomas Morin, it has to do with
> MPLS/BGP VPNs where a master routing-instance exchanges selected routes
> with each VPN/VRF.

Either it needs to be clarified in the spec, or it could simply be removed to avoid confusion since "route virtualization" covers that already.

> 
> >
> > Depending on the definition of "logical router" and "route
> virtualization", there may also be concerns with keeping all those kinds
> of in the same flat list.
> 
> It is similar to interfaces, where physical and logical interfaces of
> all kinds live in the same flat list and are distinguished by the type.
> I think it could work, relationships among the individual routing
> instances can be expressed in other data.

I will defer to others about the merits of a flat list, but for a flat list, the base spec needs to provide a way to express the relationship.

Jeffrey

> 
> Having a single flat list has its advantages, for example you can then
> easily refer to routing instances via leafrefs (which allow only one
> path).
> 
> Cheers, Lada
> 
> >
> > Jeffrey Zhang
> > Dean Bogdanovic
> 
> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 10:26:08 +0200

> Address Family has very specific meanings, typically only refer to IPv4/IPv6 to my understanding. If we want to extend that to include SAFI, then the spec must point it out. More below related to M…

Both Cisco and Juniper docs use terms like "IPv6 multicast address family" or "MCAST-VPN address family" that clearly include SAFI as well.    

For better or worse, in the ietf-routing YANG module "address-family" leaf is defined with the type

         type identityref {
           base address-family;
         }

so its meaning follows from that, including the fact that the identity is extensible. In my view, it is a feature, not bug.

> Compare the two, I don't like #2 because it adds an unnecessary indirection. I don't think we want to overload "Address Family" further to include topology either. In many implementations, actual R…

This restriction is only relevant for the "connected-rib" list. If you want, you can add configuration parameters to associate other RIBs directly with a routing protocol instance.

IMO, the common use case for MT are incongruent IPv4 and IPv6 topologies, and the core routing data model can handle this directly and easily.

Also note that the "routing-cfg" document has already been submitted to IESG for publication, so your comments come really late.   

> While the design needs to be open-ended a standard specification needs to be precise and unambiguous. The names can be discussed and compromised but the meaning must be clear. For example, Cisco "v…

The term "logical router" is used in a very general sense, and the document clearly says so ("no semantics"). The other terms are used only as examples what it could possibly mean, to make the spec more accessible.

> I don't have to split hair between "standard" and "default" but the spec must point out what a "standard-routing-instance" is - is it the default/base/master logical-system (Cisco virtual-router) o…

I think the ietf-routing module makes it pretty clear:

         leaf type {
           type identityref {
             base routing-instance-type;
           }
           default "rt:standard-routing-instance";
           description
             "The type of the routing instance.";
         }

The purpose of the "type" is to allow for defining a new routing instance type and augment configuration or state data conditionally for that type. The "standard-routing-instance" is just the default value to start from, it has no other meaning. 

> I think it is important to define a few well known routing instance types in the base spec as a good foundation for other modules.

This is outside the scope of the core routing data model, and should be done by routing experts, not in the NETMOD group. There are other indispensable elements that have to be worked out before the routing data model can be really useful, e.g. routing protocols and route filters.

> Either it needs to be clarified in the spec, or it could simply be removed to avoid confusion since "route virtualization" covers that already.

This is actually a typo - it should be "router virtualization". My understanding of this term is that a virtual router is isolated and exchanges routing information with other routers only through routing protocols.

Anyway, these are really only examples and I think it is sufficiently clear that the core routing data model doesn't use these terms for defining any semantics.  

Lada

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Jun 2014 12:59:04 +0000

Lada,

The discussions basically boil down to two main points:

- I believe the spec should have well defined semantics for some well-known types of "routing-instances". Otherwise it is too loose to be the foundation for future work (e.g. the on-going OSPF YANG model work). That does not prevent the flexibility for future extensions.

- I think the spec is too restrictive in saying "Each routing protocol instance is connected to exactly one RIB for each address family that the routing protocol instance supports". We can mix AF and SAF together and simply say Address Family (if we make it clear) but with the consideration of MT the statement is just not correct.

I am more concerned with the first point.

I don't think this is too late. There is still IETF last call and I am posting my comments here. If there is enough consensus to my points, then necessary changes need to happen. If not, I'll accept that.

Thanks.
Jeffrey

> Sent: Monday, June 23, 2014 4:26 AM
> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
> 
> > Address Family has very specific meanings, typically only refer to
> IPv4/IPv6 to my understanding. If we want to extend that to include SAFI,
> then the spec must point it out. More below related to MT.
> 
> Both Cisco and Juniper docs use terms like "IPv6 multicast address
> family" or "MCAST-VPN address family" that clearly include SAFI as well.
> 
> so its meaning follows from that, including the fact that the identity
> is extensible. In my view, it is a feature, not bug.
> 
> >
> >>
> >> >
> > Compare the two, I don't like #2 because it adds an unnecessary
> indirection. I don't think we want to overload "Address Family" further
> to include topology either. In many implementations, actual RIBs are per
> (routing-instance, AFI, SAFI, topology) and it may be extended further.
> Therefore, the best option is to simply remove the restriction that one
> protocol instance is connected to exactly one RIB per address family.
> 
> This restriction is only relevant for the "connected-rib" list. If you
> want, you can add configuration parameters to associate other RIBs
> directly with a routing protocol instance.
> 
> IMO, the common use case for MT are incongruent IPv4 and IPv6 topologies,
> and the core routing data model can handle this directly and easily.
> 
> Also note that the "routing-cfg" document has already been submitted to
> IESG for publication, so your comments come really late.
> 
> >
> >>
> >> >
> >> > ------
> >> >
> >> > 5.1.  Routing Instance
> >> >
> > While the design needs to be open-ended a standard specification needs
> to be precise and unambiguous. The names can be discussed and
> compromised but the meaning must be clear. For example, Cisco "virtual
> router" and Juniper "logical router/system" are the same but Juniper
> "virtual router" and Cisco "VRF-lite" are the same. What does the
> "logical router" in this spec mean? We can't just say that "it can mean
> any of those". For example if it means Cisco's "virtual router" or
> Juniper's "logical system", a further discussion may be - should this
> module really cover that.
> 
> The term "logical router" is used in a very general sense, and the
> document clearly says so ("no semantics"). The other terms are used only
> as examples what it could possibly mean, to make the spec more
> accessible.
> 
> >
> >>
> >> >
> > I don't have to split hair between "standard" and "default" but the
> spec must point out what a "standard-routing-instance" is - is it the
> default/base/master logical-system (Cisco virtual-router) or the
> default/base/master "routing-instance" (a "logical-system" would include
> many "routing-instances" like VRFs).
> >
> 
> The purpose of the "type" is to allow for defining a new routing
> instance type and augment configuration or state data conditionally for
> that type. The "standard-routing-instance" is just the default value to
> start from, it has no other meaning.
> 
> 
> >>
> >> >
> > I think it is important to define a few well known routing instance
> types in the base spec as a good foundation for other modules.
> 
> This is outside the scope of the core routing data model, and should be
> done by routing experts, not in the NETMOD group. There are other
> indispensable elements that have to be worked out before the routing
> data model can be really useful, e.g. routing protocols and route
> filters.
> 
> >
> >>
> > Either it needs to be clarified in the spec, or it could simply be
> removed to avoid confusion since "route virtualization" covers that
> already.
> 
> This is actually a typo - it should be "router virtualization". My
> understanding of this term is that a virtual router is isolated and
> exchanges routing information with other routers only through routing
> protocols.
> 
> Anyway, these are really only examples and I think it is sufficiently
> clear that the core routing data model doesn't use these terms for
> defining any semantics.
> 
> Lada
> 
> >
> >>
> >> >
> > I will defer to others about the merits of a flat list, but for a flat
> list, the base spec needs to provide a way to express the relationship.
> >
> > Jeffrey
> >
> >>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 16:38:45 +0200

> - I believe the spec should have well defined semantics for some well-known types of "routing-instances". Otherwise it is too loose to be the foundation for future work (e.g. the on-going OSPF YANG…

The OSPF (and more recent ISIS) module can work just fine with "standard-routing-instance". On smaller router platforms (OpenWRT with Quagga or BIRD daemons) this is all that's needed. I don't know why specific routing instance types couldn't be defined in separate modules. 

> - I think the spec is too restrictive in saying "Each routing protocol instance is connected to exactly one RIB for each address family that the routing protocol instance supports". We can mix AF a…

There are currently three possible solutions:

1. Subdivide each address family via identity derivation, e.g. with respect to type of service.

2. Distribute routes from the connected RIB selectively to any number other RIBs via "recipient-rib" mechanism.

3. Augment the "routing-protocol" subtrees with new parameters. For example, one could introduce protocol "sub-instances", one for each topology, and then different sub-instances could use the same address family (this is by the way another advantage of having a flat list of routing protocol instances).

In my view, this choice should be sufficient.

> I don't think this is too late. There is still IETF last call and I am posting my comments here. If there is enough consensus to my points, then necessary changes need to happen. If not, I'll accep…

The routing-cfg document is already long overdue. We've already had several rounds of relatively significant redesigns based on reviewers' comments, and I think now it's time to deliver the result. The data model may not be perfect and I am open to returning to it after we gain some experience, but IMO we first need to fill the gaps by developing modules for routing protocols, route filters and, of course, specific types of routing instances.

Lada

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 23 Jun 2014 14:42:15 +0000

Lada,

Semantics has to be precise, otherwise it can be very differently reinterpreted and then standards becomes not useful.

My take on this is we need a two abstractions
1. routing table - which is a container of routes
and
2. container of routing tables - this container has to have a precise name

If the 2. container name is not well specified and IMO, it is not in your draft, it will be hard to use your draft as foundation. Right now your definition allows free definition of container of routing tables and container of containers of routing tables. We don't need a definition of container of containers of routing tables. If we can come to agreement for the above two, that would be great.

The document is with IESG, but there is still possibility to bring DISCUSS and COMMENT items
http://tools.ietf.org/html/rfc4858#section-3.3

On Jun 23, 2014, at 8:59 AM, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:

Lada,

I agree with this one very strongly.

Thanks.
Jeffrey

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]]
Sent: Monday, June 23, 2014 4:26 AM
To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; [email-masked]<mailto:[email-masked]>
Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg

"Jeffrey (Zhaohui) Zhang" <[email-masked]<mailto:[email-masked]>> writes:

Lada,

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]]
Sent: Friday, June 20, 2014 7:26 AM
To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; [email-masked]<mailto:[email-masked]>
Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg

"Jeffrey (Zhaohui) Zhang" <[email-masked]<mailto:[email-masked]>> writes:

Ladislav,

Dean and I have some late questions and comments. We came across
these
while trying to work on the OSPF YANG model.

-----------

   Each routing protocol instance is connected to exactly one RIB
for
   each address family that the routing protocol instance supports.

My understanding is that the address family mentioned above does
not
include SAFI. Because of that, a routing protocol like BGP may
connect
to multiple RIBs in the same family (RIB for unicast and RIB for
multicast RPF purpose in case of incongruent multicast topology) so
the
above statement is not correct.

This is quite flexible since address family is defined via identities.
I
can imagine one implementation using only "ipv4" and "ipv6" (defined
in
ietf-routing) whilst other implementation could use "ipv[46]-unicast"
(defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to
be
defined in a module for unicast routing), that means including SAFI.

For better or worse, in the ietf-routing YANG module "address-family"
leaf is defined with the type

        type identityref {
          base address-family;
        }

This is also a problem in case of Multi-topology. Each topology has
its own RIB and a protocol instance like OSPF can connect to multiple
MT
RIBs.

1. You could derive new address family identities from "ipv4-unicast"
etc. so that you can assign a unique address family to multiple
tables.

2. You could have one connected RIB e.g. for "ipv4-unicast" and
define
two or more RIBs for each topology as recipients of the connected RIB.
So, in effect, the (single) connected RIB contains routes for all
topologies and these are then split via route filters to the per-
topology RIBs.

Does it make sense?

------

5.1.  Routing Instance

  Each routing instance in the core routing data model represents
a
  logical router.  The exact semantics of this term are left to
  implementations.  For example, routing instances may be
completely
  isolated virtual routers or, alternatively, they may internally
share
  certain information.

  ...

  An implementation MAY support multiple types of logical routers
  simultaneously.  Instances of all routing instance types are
  organized as entries of the same flat "routing-instance" list.
In
  order to discriminate routing instances belonging to different
types,
  the "type" leaf is defined as a child of the "routing-instance"
node.

The spec purposely left it fuzzy as to what a "routing instance" is.
However we definitely should have clear definitions for the three
terms
mentioned: routing-instance, logical router and virtual router.

Logical router is a very overload term. Today vendors have
virtualized
their routing capabilities in the system and provide 3 different
levels
of routing virtualization. Logical systems, logical routers are some
of
the names used by vendors and those offer routing and management
separation. Each logical system has its own routing instances and
routing instances can have multiple routing tables, so it is very
important to have very precise definition of what is routing instance
(and not compare it with logical router)

Well, "default" is overloaded, too, and also has a specific meaning
in
YANG. Standard is supposed to mean plain vanilla router. It is just a
name.

        leaf type {
          type identityref {

Should this spec distinguish VRF/VR/LR and have corresponding
identities defined?

The idea is this will be done in other modules that define data
models
for these types of routing instances. Then the "routing-instance"
container can be augmented with arbitrary data, but conditionally for
that routing instance type.

An implementation may actually use multiple routing-instance types at
the same time.

         leaf type {
           type identityref {
              discriminating among different types of logical
routers,

This came from an early review by Thomas Morin, it has to do with
MPLS/BGP VPNs where a master routing-instance exchanges selected
routes
with each VPN/VRF.

Lada

Depending on the definition of "logical router" and "route
virtualization", there may also be concerns with keeping all those
kinds
of in the same flat list.

It is similar to interfaces, where physical and logical interfaces of
all kinds live in the same flat list and are distinguished by the
type.
I think it could work, relationships among the individual routing
instances can be expressed in other data.

Jeffrey

Having a single flat list has its advantages, for example you can
then
easily refer to routing instances via leafrefs (which allow only one
path).

Cheers, Lada

Jeffrey Zhang
Dean Bogdanovic

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Jun 2014 15:12:08 +0000

Lada,

> Sent: Monday, June 23, 2014 10:39 AM
> Cc: Kiran Agrahara Sreenivasa
> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-
> cfg
> 
> > - I believe the spec should have well defined semantics for some well-
> known types of "routing-instances". Otherwise it is too loose to be the
> foundation for future work (e.g. the on-going OSPF YANG model work).
> That does not prevent the flexibility for future extensions.
> 
> The OSPF (and more recent ISIS) module can work just fine with
> "standard-routing-instance". On smaller router platforms (OpenWRT with
> Quagga or BIRD daemons) this is all that's needed. I don't know why
> specific routing instance types couldn't be defined in separate modules.
> 
> >
> > - I think the spec is too restrictive in saying "Each routing protocol
> instance is connected to exactly one RIB for each address family that
> the routing protocol instance supports". We can mix AF and SAF together
> and simply say Address Family (if we make it clear) but with the
> consideration of MT the statement is just not correct.
> 
> 2. Distribute routes from the connected RIB selectively to any number
> other RIBs via "recipient-rib" mechanism.
> 
> 3. Augment the "routing-protocol" subtrees with new parameters. For
> example, one could introduce protocol "sub-instances", one for each
> topology, and then different sub-instances could use the same address
> family (this is by the way another advantage of having a flat list of
> routing protocol instances).
> 

How about simply remove that restriction that one protocol instance connects to only one RIB per address family?

> > I don't think this is too late. There is still IETF last call and I am
> posting my comments here. If there is enough consensus to my points,
> then necessary changes need to happen. If not, I'll accept that.
> 
> The routing-cfg document is already long overdue. We've already had
> several rounds of relatively significant redesigns based on reviewers'
> comments, and I think now it's time to deliver the result. The data
> model may not be perfect and I am open to returning to it after we gain
> some experience, but IMO we first need to fill the gaps by developing
> modules for routing protocols, route filters and, of course, specific
> types of routing instances.

We're developing protocol modules, and it is during that process (for OSPF YANG module) that the issue with "routing-instance" came up. It's better to address that in the netmod-routing-cfg spec now than later/separately.

Jeffrey

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 Jun 2014 11:32:44 -0400

Lada,

On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka <[email-masked]> wrote:

> > - I believe the spec should have well defined semantics for some
> well-known types of "routing-instances". Otherwise it is too loose to be
> the foundation for future work (e.g. the on-going OSPF YANG model work).
Supporting very common features (L3VPNs, logical routers, multiple routing
instances) can
make routers significantly more complex than Quagga supports.  While Quagga
certainly has some useful features, I do not think it has kept pace.  What
is needed for routing is more.

> instance is connected to exactly one RIB for each address family that the
> routing protocol instance supports". We can mix AF and SAF together and
> simply say Address Family (if we make it clear) but with the consideration
> of MT the statement is just not correct.
>
> posting my comments here. If there is enough consensus to my points, then
> necessary changes need to happen. If not, I'll accept that.
>
> comments, and I think now it's time to deliver the result. The data model
> may not be perfect and I am open to returning to it after we gain some
> experience, but IMO we first need to fill the gaps by developing modules
> for routing protocols, route filters and, of course, specific types of
> routing instances.
>

Jeffrey is coming in, trying to work on an OSPF YANG model, as a routing
person very familiar with one implementation.  If this draft is not a
sufficient base on which to build the other routing models, how should we
proceed?  I have requested yet another routing directorate review on this
draft; I'd expect that review before the upcoming IETF.

I can appreciate the frustration in the time it is taking to get this draft
done.  Cross-area review does frequently happen after WGLC.

Alia

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 20:16:03 +0200

Hi Alia,

On 23 Jun 2014, at 17:32, Alia Atlas <[email-masked]> wrote:

> Supporting very common features (L3VPNs, logical routers, multiple routing instances) can
> make routers significantly more complex than Quagga supports.  While Quagga certainly has some useful features, I do not think it has kept pace.  What is needed for routing is more.

Right, but it doesn’t mean this more has to be implemented by the core routing model. I think the important point is that such extensions are possible to do in other modules, and I am convinced it is the case.

> Jeffrey is coming in, trying to work on an OSPF YANG model, as a routing person very familiar with one implementation.  If this draft is not a sufficient base on which to build the other routing models, how should we proceed?  I have requested yet another routing directorate review on this draft; I'd expect that review before the upcoming IETF.

Yes, it is really challenging to combine YANG expertise (as YANG is a relatively new data modelling language) with domain-specific know-how. FWIW, I wrote an OSPF module for the BIRD daemon that perhaps may be used for comparison:

https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/data-models/bird/bird-ospf.yang

Lada

> 
> I can appreciate the frustration in the time it is taking to get this draft done.  Cross-area review does frequently happen after WGLC.
> 
> Alia
> 
> Lada
> 
> >
> > Thanks.
> > Jeffrey
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 20:43:11 +0200

> 1. routing table - which is a container of routes

This is called RIB in the ietf-routing module, after the terminology has been harmonized with the I2RS RIB info model.

> 2. container of routing tables - this container has to have a precise name

I am not sure I understand - in the ietf-routing module, this container does have a precise name: “ribs”, i.e., every routing instance can use multiple RIBs.

> If the 2. container name is not well specified and IMO, it is not in your draft, it will be hard to use your draft as foundation. Right now your definition allows free definition of container of ro…

But routing instances are (among other things) exactly these containers of containers of RIBs, but IMO the various types of routing instances so far have been pretty much vendor-specific, even though there are some de facto standards. It would be great if these thing are standardised in the IETF, and corresponding YANG modules written.

> http://tools.ietf.org/html/rfc4858#section-3.3

It sure is.

Lada

> 
> 
> On Jun 23, 2014, at 8:59 AM, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
>> Lada,
>>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Jun 2014 18:59:01 +0000

Lada,

> Right, but it doesn't mean this more has to be implemented by the core
> routing model. I think the important point is that such extensions are
> possible to do in other modules, and I am convinced it is the case

While we are trying to work on the OSPF YANG module, which is to base on netmod-routing-cfg, some interpret the "routing-instance" in netmod-routing-cfg as Juniper's "Logical Router/System" (i.e. Cisco's "Virtual Router"), while some others interpret that as Juniper's VRF/VR (i.e., Cisco's VRF/VRF-lite). That difference has a major impact on how OSPF YANG module is defined.

If netmod-routing-cfg is to allow both the above, it is critical for netmod-routing-cfg to be clear what the terms "logical router" and "virtual router" mean, and then OSPF YANG module will proceed accordingly. It does not make sense to defer that to another document.

There are even people who argue that it is not good to put the above two types of routing instances into the same flat list. That's a separate topic and I am not trying to open up that discussion here, but it shows how important it is for the netmod-routing-cfg to be clear what a "routing-instances" is instead of deferring to another document.

Jeffrey

> Sent: Monday, June 23, 2014 2:16 PM
> To: Alia Atlas
> Cc: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; [email-masked]; Kiran
> Agrahara Sreenivasa
> > make routers significantly more complex than Quagga supports.  While
> Quagga certainly has some useful features, I do not think it has kept
> pace.  What is needed for routing is more.
> 
> Right, but it doesn't mean this more has to be implemented by the core
> routing model. I think the important point is that such extensions are
> possible to do in other modules, and I am convinced it is the case.
> 
> 
> >
> > >
> > > - I think the spec is too restrictive in saying "Each routing
> protocol instance is connected to exactly one RIB for each address
> family that the routing protocol instance supports". We can mix AF and
> SAF together and simply say Address Family (if we make it clear) but
> with the consideration of MT the statement is just not correct.
> >
> > > I don't think this is too late. There is still IETF last call and I
> am posting my comments here. If there is enough consensus to my points,
> > Jeffrey is coming in, trying to work on an OSPF YANG model, as a
> routing person very familiar with one implementation.  If this draft is
> not a sufficient base on which to build the other routing models, how
> should we proceed?  I have requested yet another routing directorate
> review on this draft; I'd expect that review before the upcoming IETF.
> 
> Yes, it is really challenging to combine YANG expertise (as YANG is a
> relatively new data modelling language) with domain-specific know-how.
> FWIW, I wrote an OSPF module for the BIRD daemon that perhaps may be
> used for comparison:
> 
> > I can appreciate the frustration in the time it is taking to get this
> draft done.  Cross-area review does frequently happen after WGLC.
> >
> > Alia
> >
> > Lada
> >
> > >
> > > Thanks.
> > > Jeffrey
> > >

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 23 Jun 2014 19:34:44 +0000

> I am not sure I understand - in the ietf-routing module, this container does have a precise name: “ribs”, i.e., every routing instance can use multiple RIBs.
so based on your sentence routing instance is a container of RIBs?

> But routing instances are (among other things) exactly these containers of containers of RIBs, but IMO the various types of routing instances so far have been pretty much vendor-specific, even thou…
here you are saying that routing instance is container of container of RIBs, which is one abstraction too many, based on your previous  sentence

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 21:42:41 +0200

> While we are trying to work on the OSPF YANG module, which is to base on netmod-routing-cfg, some interpret the "routing-instance" in netmod-routing-cfg as Juniper's "Logical Router/System" (i.e. C…

It is none of the above, and I think the draft is pretty clear about this. You can consider the “standard-routing-instance” to represent the situation before any logical/virtual routers were introduced, because that’s what is standardized. It is not the job for the ietf-routing module to declare Cisco's virtualization model superior to Juniper’s, or vice versa.
     
> If netmod-routing-cfg is to allow both the above, it is critical for netmod-routing-cfg to be clear what the terms "logical router" and "virtual router" mean, and then OSPF YANG module will proceed…

Why not? The amount of work needed for writing an extra module is pretty much the same as for adding it to ietf-routing and, importantly, it is a task for routing experts to decide what a standard logical/virtual router should be.

> There are even people who argue that it is not good to put the above two types of routing instances into the same flat list. That's a separate topic and I am not trying to open up that discussion h…

Those people should explain why it is not good.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 21:58:08 +0200

On 23 Jun 2014, at 21:05, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:

> Lada,
> 
>>> How about simply remove that restriction that one protocol instance
>> connects to only one RIB per address family?
>> 
>> It has other implications: you have to have a way for specifying which
>> protocol routes go to which RIB, and also how the RIBs are used in the
>> data plane for forwarding packets.
> 
> I am just saying to remove the restriction that one protocol instance only connects to one rib per family. It does not change anything else like what you are saying above.

I don’t agree. If two different RIBs for, e.g., ipv4-unicast are connected to a routing protocol instance, then in which RIB the IPv4 unicast routes learned by that protocol instance are supposed to appear?
  
> 
>> What is this issue with "routing-instance"? Could you be more specific?
> 
> Please see my previous email that I just sent.

I don’t know where the logical/virtual router type comes into play in the OSPF module. They certainly don’t in the ISIS module.

Lada 

>> Sent: Monday, June 23, 2014 2:23 PM
>> To: Jeffrey (Zhaohui) Zhang
>> On 23 Jun 2014, at 17:12, Jeffrey (Zhaohui) Zhang <[email-masked]>
>> wrote:
>> 
>>> Lada,
>>> 
>> well-
>> protocol
>>> How about simply remove that restriction that one protocol instance
>> connects to only one RIB per address family?
>> 
>> It has other implications: you have to have a way for specifying which
>> protocol routes go to which RIB, and also how the RIBs are used in the
>> data plane for forwarding packets.
>> 
>>> 
>>>> 
>>>> 
>>>>> 
>> am
>>> We're developing protocol modules, and it is during that process (for
>> OSPF YANG module) that the issue with "routing-instance" came up. It's
>> better to address that in the netmod-routing-cfg spec now than
>> later/separately.
>> 
>> What is this issue with "routing-instance"? Could you be more specific?
>> 
>> Lada
>> 
>>> 
>>> Jeffrey
>>> 
>>>> 
>>>> Lada
>>>> 
>>>>> 
>>>>> Thanks.
>>>>> Jeffrey
>>>>> 
>>>>>> to include topology either. In many implementations, actual RIBs
>> are
>>>> per
>>>>>> Also note that the "routing-cfg" document has already been
>> submitted
>>>> to
>>>>>> that type. The "standard-routing-instance" is just the default
>> value
>>>> to
>>>>>> This is outside the scope of the core routing data model, and
>> should
>>>> be
>>>>>>>> An implementation may actually use multiple routing-instance
>> types
>>>> at
>>>>>>>> the same time.
>>>>>>> 
>>>>>>>> It is similar to interfaces, where physical and logical
>> interfaces
>>>> of

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Jun 2014 20:00:19 +0000

Lada,

> Sent: Monday, June 23, 2014 3:43 PM
> Cc: Alia Atlas; Dean Bogdanovic; [email-masked]; Kiran Agrahara
> Sreenivasa
> > While we are trying to work on the OSPF YANG module, which is to base
> on netmod-routing-cfg, some interpret the "routing-instance" in netmod-
> routing-cfg as Juniper's "Logical Router/System" (i.e. Cisco's "Virtual
> Router"), while some others interpret that as Juniper's VRF/VR (i.e.,
> Cisco's VRF/VRF-lite). That difference has a major impact on how OSPF
> YANG module is defined.
> 
> It is none of the above, and I think the draft is pretty clear about
> this. You can consider the "standard-routing-instance" to represent the
> situation before any logical/virtual routers were introduced, because
> that's what is standardized. It is not the job for the ietf-routing
> module to declare Cisco's virtualization model superior to Juniper's, or
> vice versa.

Nobody is trying to argue which is better. I used this example to show that people from Cisco and Juniper interpreted the "routing-instance" different - a clear sign that the draft is far from "pretty clear".

> 
> >
> > If netmod-routing-cfg is to allow both the above, it is critical for
> netmod-routing-cfg to be clear what the terms "logical router" and
> "virtual router" mean, and then OSPF YANG module will proceed
> accordingly. It does not make sense to defer that to another document.
> 
> Why not? The amount of work needed for writing an extra module is pretty
> much the same as for adding it to ietf-routing and, importantly, it is a
> task for routing experts to decide what a standard logical/virtual
> router should be.

The argument is that this spec needs to have that definition, or at least using examples to illustrate.

> 
> >
> > There are even people who argue that it is not good to put the above
> two types of routing instances into the same flat list. That's a
> separate topic and I am not trying to open up that discussion here, but
> it shows how important it is for the netmod-routing-cfg to be clear what
> a "routing-instances" is instead of deferring to another document.
> 

I will defer to those; it is fine if they don't speak up, but I mention it here to show the importance of having clear definitions.

Jeffrey

> >>>>> IPv4/IPv6 to my understanding. If we want to extend that to
> include
> >> SAFI,
> >> are per
> >>>>> Therefore, the best option is to simply remove the restriction
> that
> >> one
> >> submitted to
> >>>>> document clearly says so ("no semantics"). The other terms are
> used
> >> only
> >>>>> instance type and augment configuration or state data
> conditionally
> >> for
> >> value to
> >> should be
> >> types at
> >> interfaces of

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 22:02:44 +0200

> here you are saying that routing instance is container of container of RIBs, which is one abstraction too many, based on your previous  sentence

Each routing instance defines a flat list of RIBs available to it, but these RIBs are divided into subsets (or rather dependency graphs) through the mechanisms of connected RIBs and recipient RIBs.

Lada

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Jun 2014 20:03:19 +0000

Lada,

> Sent: Monday, June 23, 2014 3:58 PM
> Cc: NETMOD Working Group
> > I am just saying to remove the restriction that one protocol instance
> only connects to one rib per family. It does not change anything else
> like what you are saying above.
> 
> I don't agree. If two different RIBs for, e.g., ipv4-unicast are
> connected to a routing protocol instance, then in which RIB the IPv4
> unicast routes learned by that protocol instance are supposed to appear?

That's what could deferred to an extension module :-)

> I don't know where the logical/virtual router type comes into play in
> the OSPF module. They certainly don't in the ISIS module.

We can include you in OSPF YANG discussions. I will also review the ISIS module.

Jeffrey

> >>>>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-
> multicast"
> >>>> (to
> >>>>>> be
> >>>>>> family" or "MCAST-VPN address family" that clearly include SAFI
> as
> >>>> well.
> >>>>>>
> >>>>>>>>> This is also a problem in case of Multi-topology. Each
> topology
> >>>> has
> >>>>>>>> two or more RIBs for each topology as recipients of the
> connected
> >>>> RIB.
> >>>>>> This restriction is only relevant for the "connected-rib" list.
> If
> >>>> you
> >>>>>>>>> The spec purposely left it fuzzy as to what a "routing
> instance"
> >>>> is.
> >>>>>> "logical router" in this spec mean? We can't just say that "it
> can
> >>>> mean
> >>>>>>>> container can be augmented with arbitrary data, but
> conditionally
> >>>> for
> >>>>>>> I will defer to others about the merits of a flat list, but for
> a
> >>>> flat
> >>>>>>>> easily refer to routing instances via leafrefs (which allow
> only
> >>>> one
> >>>>>>>> path).
> >>>>>>>>
> >>>>>>>> Cheers, Lada
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Jeffrey Zhang
> >>>>>>>>> Dean Bogdanovic
> >>>>>>>>
> >>>>>>>> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 22:34:59 +0200

On 23 Jun 2014, at 22:00, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:

> Nobody is trying to argue which is better. I used this example to show that people from Cisco and Juniper interpreted the "routing-instance" different - a clear sign that the draft is far from "pretty clear”.

So which virtualization model do you want the ietf-routing module to adopt? I guess VMware people would have yet another idea of what a virtual router is.

I would actually expect Cisco and Juniper to either
- write proprietary YANG modules describing the semantic of their own routing instances, or
- find an agreement and propose a type for an IETF standard.  

> The argument is that this spec needs to have that definition, or at least using examples to illustrate.

The spec only defines the “standard-routing-instance”, which has nothing to do with logical/virtual routers. The “routing-instance” list (which was added in later stages of the module development) provides a mechanism for defining various routing instance types, nothing more.

Lada

>>>> multicast" (to
>>>> topology has
>>>> connected RIB.
>>>> instance" is.
>>>> conditionally for

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Jun 2014 22:36:41 +0200

On 23 Jun 2014, at 22:03, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:

> We can include you in OSPF YANG discussions.

Yes, that would be useful.

Lada

> I will also review the ISIS module.
> 
> Jeffrey
> 
>> 
>> Lada
>> 
>>> 
>>> Jeffrey
>>>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Jun 2014 21:01:40 +0000

Lada,

> So which virtualization model do you want the ietf-routing module to adopt? I guess VMware people would have yet another idea of what a virtual router is.

I am not asking to adopt or restrict to any particular one. I am asking the following:

- what is the definition (or example of) "logical router" and "virtual router" in the current spec; you could say it covers "anything" with examples like Cisco's or Juniper's or some specific vendor's "logical router" and "VRF" and "VRF-lite", and that's fine with me.

- with the above Cisco/Juniper terms, VRF or VRF-lites belong to LRs. If they're put into a flat list of "routing-instances", then each "routing-instance" needs indicate its "parent" instance (e.g. which LR a VRF belongs to). This is very basic functionality for a modern router and if that needs to be specified in an extension module, then all protocol modules need to refer to that extension module. If that's eventually what happens I can accept that, but to me it is just a lot better to include that well-known functionality in the base spec.

Jeffrey

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 Jun 2014 10:30:12 +0200

> - what is the definition (or example of) "logical router" and "virtual router" in the current spec; you could say it covers "anything" with examples like Cisco's or Juniper's or some specific vendo…

Yes, this is how I understand the following paragraph in sec. 5.1:

>
> - with the above Cisco/Juniper terms, VRF or VRF-lites belong to LRs. If they're put into a > flat list of "routing-instances", then each "routing-instance" needs indicate its "parent"
> instance (e.g. which LR a VRF belongs to). This is very basic functionality for a modern

Right, and this is what I'd expect a YANG module defining VRF or VRF-lite to do, using the "augment" statement. 

It is very similar to the ietf-interfaces, where the "interface" list is designed to contain anything that other modules define - physical or various logical interfaces.

> router and if that needs to be specified in an extension module, then all protocol modules
> need to refer to that extension module. If that's eventually what happens I can accept that, > but to me it is just a lot better to include that well-known functionality in the base spec.

Yes, implementations will have to advertise modules for specific routing instance type(s) they support. Just as they will have to advertise, e.g., an Ethernet module along with ietf-interfaces.

Lada

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 24 Jun 2014 12:38:51 +0000

>   isolated virtual routers or, alternatively, they may internally share
But based on this you are saying that routing instance is logical router and that is confusing with vendors understanding of logical router. Logical router is container of routing instances in Cisco and Juniper case

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 Jun 2014 15:27:58 +0200

> But based on this you are saying that routing instance is logical router and that is confusing with vendors understanding of logical router. Logical router is container of routing instances in Cisc…

Do you mean “routing instance” to be an instance of a routing *protocol*? I do admit this is confusing but I2RS guys really insisted of the term “routing instance”. See also their definition in draft-ietf-i2rs-rib-info-model-03:

“A routing instance, in the context of the RIB information model, is a collection of RIBs, interfaces, and routing parameters.  A routing instance creates a logical slice of the router and allows different logical slices …”

Isn’t it what Cisco and Juniper call “logical router”?

Actually, now I see the above definition of “routing instance” in the routing-cfg I-D could/should be improved. The intention is not to allow implementations to use an arbitrary concept of a logical router: its config/state data and semantics has to be defined in a YANG module together with its type identity, and only then it can be used.

Lada

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 24 Jun 2014 13:50:54 +0000

We're converging :-)

> Sent: Tuesday, June 24, 2014 9:28 AM
> To: Dean Bogdanovic
> Cc: Jeffrey (Zhaohui) Zhang; Alia Atlas; [email-masked]; Kiran Agrahara
> Sreenivasa
> >>>>> Nobody is trying to argue which is better. I used this example to
> show that people from Cisco and Juniper interpreted the "routing-
> instance" different - a clear sign that the draft is far from "pretty
> clear".
> >>>
> >>>> So which virtualization model do you want the ietf-routing module
> to adopt? I guess VMware people would have yet another idea of what a
> virtual router is.
> >>>
> >>> - what is the definition (or example of) "logical router" and
> "virtual router" in the current spec; you could say it covers "anything"
> with examples like Cisco's or Juniper's or some specific vendor's
> "logical router" and "VRF" and "VRF-lite", and that's fine with me.
> >>
> > But based on this you are saying that routing instance is logical
> router and that is confusing with vendors understanding of logical
> router. Logical router is container of routing instances in Cisco and
> Juniper case
> 
> Do you mean "routing instance" to be an instance of a routing *protocol*?

No.

> I do admit this is confusing but I2RS guys really insisted of the term
> "routing instance". See also their definition in draft-ietf-i2rs-rib-
> info-model-03:
> 
> "A routing instance, in the context of the RIB information model, is a
> collection of RIBs, interfaces, and routing parameters.  A routing
> instance creates a logical slice of the router and allows different
> logical slices ..."

Good that you dig out this definition :-)

That corresponds to Cisco's VRF/VRF-lite, or Juniper's VRF/VR, not logical router.

> 
> Isn't it what Cisco and Juniper call "logical router"?

No. Cisco's and Juniper's logical routers are similar (I was told they were different but apparently they are) and definitions are here:

http://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-2/interfaces/configuration/guide/int_c32/hc32logr.pdf
http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/logical-systems-overview-solutions.html

A single LR can have multiple VR or VRF-lites.

Jeffrey

> 
> Actually, now I see the above definition of "routing instance" in the
> routing-cfg I-D could/should be improved. The intention is not to allow
> implementations to use an arbitrary concept of a logical router: its
> config/state data and semantics has to be defined in a YANG module
> together with its type identity, and only then it can be used.
> 
> Lada
> 
> >>
> >>>
> >>> - with the above Cisco/Juniper terms, VRF or VRF-lites belong to LRs.
> If they're put into a > flat list of "routing-instances", then each
> "routing-instance" needs indicate its "parent"
> >> Right, and this is what I'd expect a YANG module defining VRF or VRF-
> lite to do, using the "augment" statement.
> >>
> >> It is very similar to the ietf-interfaces, where the "interface" list
> is designed to contain anything that other modules define - physical or
> various logical interfaces.
> >>
> >>> need to refer to that extension module. If that's eventually what
> happens I can accept that, > but to me it is just a lot better to
> include that well-known functionality in the base spec.
> >>
> >> Yes, implementations will have to advertise modules for specific
> routing instance type(s) they support. Just as they will have to
> advertise, e.g., an Ethernet module along with ietf-interfaces.
> >>
> >> Lada
> >>
> >>>
> >>> Jeffrey
> >>
> >> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 Jun 2014 16:44:42 +0200

> We're converging :-)

Good. :-)

...

> A single LR can have multiple VR or VRF-lites.

Right, and the truth is "routing-instance" list in the ietf-routing module is intended to harbour both! The organization can be for example as follows (in JSON):

"routing-instance":
  [
    { "name": "LR1",
      "type": "logical-router",
      ...
    },
    { "name": "VRF1",
      "type": "VRF-lite",
      "logical-router": "LR1",
      ...
    },
    { "name": "VRF2",
      "type": "VRF-lite",
      "logical-router": "LR1",
      ...
    }
  ]

Lada

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 24 Jun 2014 19:43:30 +0000

Lada,

I believe the definition of routing-instance in i2rs, as you quoted earlier, does not include LR? It's a "collection of RIBs, interfaces, and routing parameters" which maps to VR/VRF/VRF-lite, while an LR is a collection of routing-instances.

Additionally, Stephane articulated very well in another thread (about ISIS YANG module) why LR should not be included.

Jeffrey

> Sent: Tuesday, June 24, 2014 10:45 AM
> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
> Cc: Alia Atlas; [email-masked]; Kiran Agrahara Sreenivasa
> Subject: RE: [netmod] Questions/comments on draft-ietf-netmod-routing-
> cfg
> 
> Right, and the truth is "routing-instance" list in the ietf-routing
> module is intended to harbour both! The organization can be for example
> as follows (in JSON):
> 
> "routing-instance":
>   [
>     { "name": "LR1",

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Jun 2014 10:26:41 +0200

> I believe the definition of routing-instance in i2rs, as you quoted earlier, does not include LR? It's a "collection of RIBs, interfaces, and routing parameters" which maps to VR/VRF/VRF-lite, whil…

I am still not convinced the I2RS definition excludes logical routers/systems ("A routing instance creates a logical slice of the router …”).

In any case, the definition of routing instance in routing-cfg (sec. 5.1) was really intended to include *both* logical routers/systems (“completely isolated virtual routers”) and VRFs that “internally share certain information”.

I think it was Phil Shafer of Juniper who requested the addition of the top-level list (originally “router”, now “routing-instance”) and I remember we explicitly discussed JUNOS logical systems.

> Additionally, Stephane articulated very well in another thread (about ISIS YANG module) why LR should not be included.

In this case it would suffice to write a module defining a data model for VRF/VRF-lite instances via augmenting “routing-instance”. I can help with it if you want.

Lada