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

From: "Derek Man-Kit Yeung (myeung)" <[email-masked]>
Date: Tue, 4 Mar 2014 12:39:08 +0000

Hi Ladislav,

Have a few of questions for the draft.
1) I saw an ipv4-unicast identity defined.
   Is there a ipv4-multicast for reference to the RIB which store ipv4
unicast route for RPF lookup?
2) How would topology as used in RFC5120 be supported?
3) Given routing-protocol has only name as the key
           list routing-protocol {
               key "name";
   Would it prevent different protocols from using the same name? Like
"router ospf 101" and "router rip 101" at the same time using IOS syntax?

Thanks,
- Derek

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 4 Mar 2014 14:50:19 +0000

Hi Derek,

thanks for reading the draft.

> unicast route for RPF lookup?

Identities are extensible by design, so the “ipv4-multicast” identity can (and will) be defined in another module - it will be derived from the “rt:ipv4” identity.

> 2) How would topology as used in RFC5120 be supported?

I am not an expert on IS-IS, so I don’t have a quick answer to this. Do you have any specific concerns that it might NOT work?

> "router ospf 101" and "router rip 101" at the same time using IOS syntax?

List keys have to be unique, so in this case you would need to use e.g. “ospf-101” and “rip-101” as the keys.

Lada

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

---

From: "Derek Man-Kit Yeung (myeung)" <[email-masked]>
Date: Thu, 6 Mar 2014 09:50:50 +0000

On 3/4/14 6:50 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Identities are extensible by design, so the ³ipv4-multicast² identity can
>(and will) be defined in another module - it will be derived from the
>³rt:ipv4² identity.

DY> Defer reply on this one. I have some questions on how identity is
used. Will reply once I got that clarified.

>I am not an expert on IS-IS, so I don¹t have a quick answer to this. Do
>you have any specific concerns that it might NOT work?

DY> See reply in 3).

>List keys have to be unique, so in this case you would need to use e.g.
>³ospf-101² and ³rip-101² as the keys.

DY> One the router, the routing protocol is identified by the type and a
tag.
DY> Example is type OSPF and tag 101. For display purpose, you may see
"ospf 101", "Protocol: OSPF, Tag: 101" or "ospf-101" depending on
implementation.
DY> When I read your draft, I took that name mean tag and hence the
uniqueness question.
DY> If name equate a string like "ospf-101", then the string cannot be
just arbitrary as the draft said.
DY> It has to have some forward like <Routing Protocol Type
Str><Separator><Tag> so the network device can extract the tag from it.
DY> My preference is to treat the name as <Tag> and include type a part of
the key. 
DY> Even if name mean just the tag, still need some kind of pattern as not
all character is allowed.
DY> Is this a way in YANG to augment the name with pattern which suit the
implementation that it talk to?

DY> For topology, it is just a RIB.
DY> Before topology, a RIB is identified by (Name, AFI, SAFI) like
("Customer1", IPv4, UNICAST).
DY> Topology add an extract topology name so the identifier become (VRF
name, AFI, SAFI, Topo name).
DY> Example are ("Customer1", IPv4, UNICAST, "Gold"), ("Customer1", IPv4,
UNICAST, "Sliver"), ("Customer1", IPv4, UNICAST, "Bronze")
DY> It is like providing multiple data in the under the same VRF, AFI and
SAFI.
DY> It is similar to the routing protocol name discussion.
DY> Either an topology name is added (Could it be through augmentation as
not all vendors support topology),
DY> or the RIB name is made to have certain format like <VRF Name> or <VRF
Name>:<Topo Name>.
DY> It will need more discussion to agree on solution.

Thanks,
- Derek

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 06 Mar 2014 10:43:54 +0000

"Derek Man-Kit Yeung (myeung)" <[email-masked]> writes:

...

> DY> When I read your draft, I took that name mean tag and hence the

As this is a vendor-neutral module, we tried to avoid assigning semantics to the names of objects because that would hardly work for different vendors. An implementation may use random strings as list keys provided they are unique.

> just arbitrary as the draft said.

"ospf-101" is just an example how the name can be disambiguated in a way that is "friendly" to a particular platform. 

> Str><Separator><Tag> so the network device can extract the tag from it.

I don't know what you mean by a "forward". How is this tag supposed to be used?

> implementation that it talk to?

Yes, it is. Some protocols add a tag as a new route attribute - see the example RIP implementation in Appendix C.

If a vendor then wants to use a tag or anything else in an implementation-specific way, it can do so by writing a proprietary module that augments the standard module where necessary. This is IMO much better than encode semantics into routing protocol names.

> not all vendors support topology),

I believe this topology object has to do with link-state protocols, so in my view a future implementation of OSPF or IS-IS has to design new configuration and/or state data representing topologies, and augment "rt:routing-protocol" (or "rt:interface") with it.  

> DY> or the RIB name is made to have certain format like <VRF Name> or <VRF

A discussion of VRFs is now going on in the NETCONF mailing list and I already expressed my opinion there:

http://www.ietf.org/mail-archive/web/netconf/current/msg08755.html

In short, I think the VRF concept should be defined as a special type of routing-instance.

Thanks, Lada

---

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

On 3/6/14 2:43 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>As this is a vendor-neutral module, we tried to avoid assigning semantics
>to the names of objects because that would hardly work for different
>vendors. An implementation may use random strings as list keys provided
>they are unique.

Combination of type and tag is very generic for identifying a routing
protocol.
If we use a name string which include both the type and tag info and do
not provide a format for it,
then I am concerned that the controller need to to adjust name string
accordingly depending on which vendor it is talking to.
It is doable but it seems to defeat the purpose of having the same data
model in the first place.

>"ospf-101" is just an example how the name can be disambiguated in a way
>that is "friendly" to a particular platform.
>

Sorry. Typos. I mean "format".
For the string "ospf-1", "ospf" is the type and "1" is the tag.

>Yes, it is. Some protocols add a tag as a new route attribute - see the
>example RIP implementation in Appendix C.
>
>If a vendor then wants to use a tag or anything else in an
>implementation-specific way, it can do so by writing a proprietary module
>that augments the standard module where necessary. This is IMO much
>better than encode semantics into routing protocol names.

What about making both type and name as the key?

>I believe this topology object has to do with link-state protocols, so in
>my view a future implementation of OSPF or IS-IS has to design new
>configuration and/or state data representing topologies, and augment
>"rt:routing-protocol" (or "rt:interface") with it.

No. it is not link state protocols specific. It is part of the RIB design.
Suppose routing-instances could mean VRF (from below). In that case, the
RIB inside the routing-stances could be a "topology". We still have figure
out how the identifier should look like.

Thanks,
- Derek

---

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

>better than encode semantics into routing protocol names.

Need to address this particular point. The "tag" I mentioned is different
then the tag in the route.
The "tag" I mean is the name of that routing protocol of a particular type.

Thanks,
- Derek

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 15 Mar 2014 10:11:59 +0100

Hi Derek,

please see my responses inline.

> Combination of type and tag is very generic for identifying a routing

I don't think it is that generic - two examples:

- JUNOS doesn't use such tags at all because multiple instances of the same routing protocol have to be in different routing instances.

- BIRD routing daemon does use tags for protocol instances, e.g.

protocol ospf foo {
  ...
}

but the same tag ("foo") cannot be reused for a different protocol type.

> What about making both type and name as the key?

This would be possible in principle but first I don't see really convincing reasons for this change, and second, as Juergen already pointed out, we are past WGLC and I am concerned that we will never finish this work.

> out how the identifier should look like.

I am still not sure this is something that has to be dealt with in the core routing data model. IMO, the model in its current state is a reasonable common denominator of routing subsystem implementations (note it's not intended only for routers, let alone only "big" ones).

I think we should finish this data model soon and let routing experts augment and extend it via new modules covering routing protocols, route filtering, various kinds of virtualization etc.
It is quite possible that this work will identify flaws in the routing model, and then it will have to be revised. Recently, we aligned the model with the info model of the I2RS WG. However, we cannot continue adding new features here and there because then we will never be done.

Lada

---

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

On 3/15/14 2:11 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>- JUNOS doesn't use such tags at all because multiple instances of the
>same routing protocol have to be in different routing instances.

If routing-protocol is keyed on both type and name (what I suggested),
then the name could be empty string. (Name becomes the tag I mentioned).

Then for JUNOS, the tag could just be empty string.

routing-instances {
	routing-instance-name {
		protocols {
			bgp {
				bgp-configuration;
			}
			isis {
				isis-configuration;
			}
			ospf {
				ospf-configuration;
			}
…

The routing-instance-name is the 'name' of the routing-instance container.
The bgp, isis, ospf is indicated by the 'type' of the routing-protocol
container and 'name' of the routing-protocol will be empty string.

For vendor which support multiple instances of the same routing protocol
in the same routing-instances (VRF), the 'name' of the routing-protocol
could be the distinguisher.

>but the same tag ("foo") cannot be reused for a different protocol type.

This is restriction of that particular implementation, I think the data
model should allow that and the backend could reject if it is not
supported.

Actually, the current model allow routing-protcol name already, the point
we are argument is why do we need routing-type information encoded into
the name string as the current model required.

>>>I don't know what you mean by a "forward". How is this tag supposed to
>>>be
>>>used?
>>
>>>> DY> My preference is to treat the name as <Tag> and include type a
>>>>part
>>>>of
>>>> the key. 
>This would be possible in principle but first I don't see really
>convincing reasons for this change, and second, as Juergen already
>pointed out, we are past WGLC and I am concerned that we will never
>finish this work.

I think there is very good reason to change ;-)

BTW, it is similar limitation for the routing-instance name, either
different type of routing-instance cannot have the same name or the type
has to be encoded in the name itself.

>I am still not sure this is something that has to be dealt with in the
>core routing data model. IMO, the model in its current state is a
>reasonable common denominator of routing subsystem implementations (note
>it's not intended only for routers, let alone only "big" ones).

If it is just the naming convention is left for later specification, it
could be fine. 
My point is that it should not be left for each implementation to pick
their own convention.
For reference, the JUNOS encode the topology name in the RIB name.

But there is restriction that is not necessary, in term of multiple
topology, in the draft.
For example,

  o  Each routing protocol instance, including the "static" and
      "direct" pseudo-protocols, is connected to exactly one RIB with
      which it can exchange routes (in both directions, except for the
      "static" and "direct" pseudo-protocols).

container connected-ribs {
	description
	"Container for connected RIBs.";
	list connected-rib {
		key "rib-name";
		description
		"List of RIBs to which the routing protocol instance
		is connected (at most one RIB per address
		family).";

For routing protocol that support multiple topologies, those RIBs could
belong to the same address family.
For example, OSPF could be connected to two IPv4 unicast RIB.

- Derek

>
>I think we should finish this data model soon and let routing experts
>augment and extend it via new modules covering routing protocols, route
>filtering, various kinds of virtualization etc.
>It is quite possible that this work will identify flaws in the routing
>model, and then it will have to be revised. Recently, we aligned the
>model with the info model of the I2RS WG. However, we cannot continue
>adding new features here and there because then we will never be done.
>
>Lada
>
>>
>> Thanks,
>> - Derek
>>
>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Mar 2014 08:23:52 +0100

> has to be encoded in the name itself.

As WG chair, I strongly believe we need to deliver.

So far, I have only heard one voice asking for a change and one voice
saying the change is not strictly needed. Correct me if I am wrong. It
is not clear to me that we have a fundamental flaw. If we do have a
_fundamental_ flaw, you need to describe this flaw clearly and
concisely and it would help if others can confirm that it is a flaw.

As long as we have a "this could have been done differently to make it
easier for some implementations" discussion, I will not hold the
document. Note that there is going to be an IETF last call - so there
is another chance to raise _fundamental_ flaws if there are any.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

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

> Then for JUNOS, the tag could just be empty string.

My point was that the IOS convention is by no means universal.

> the name string as the current model required.

The data model doesn't require this, only the routing protocol instances within a routing instance have to have unique keys. Choosing "<type> <tag>" as the key is just one way for satifying this constraint.

It is pretty much the same situation as with the "interface" list as defined in the "ietf-interfaces" module: "name" is the only key and its value will quite often encode the type of the interface, e.g. "eth0" or "GigabitEthernet1/0", even though this information is also contained in the "type" leaf.

> has to be encoded in the name itself.

Right, although I don't see it as a limitation. Having a flat list of routing instances, possibly of different types seems to be the most flexible structure.

> My point is that it should not be left for each implementation to pick

An implementation can choose either native names (or combinations thereof) as keys of various list entries, such as "ospf 101", or an opaque string that is internally mapped to native names (and this mapping can be recorded in state data).

Yes, if an implementation chooses the former approach, its configuration may not be directly transferable to another platform, but it is again the same situation as with interface naming.

> For example, OSPF could be connected to two IPv4 unicast RIB.

Then the organization can be as follows:

                          +--------+
                          |  OSPF  |
                          +---+----+
                              |
                              |
                         +----------+
                         | RIB-ospf |
                         +----------+
                           /     \
                          /       \
                     +------+   +------+
                     | RIB1 |   | RIB2 |
                     +------+   +------+

where RIB-ospf is the RIB that's connected to the OSPF routing instance, and RIB1 and RIB2 exchange routes with RIB-ospf (in one or both directions) via the "recipient-rib" mechanism.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Mar 2014 10:02:07 -0700

Hi,

> is another chance to raise _fundamental_ flaws if there are any.
big +1

There was lots of WG discussion wrt/ instance naming (even more for
interfaces),
and no consensus could be reached on picking 1 naming scheme. We did not
start
with a plain string containing proprietary syntax. We ended up there.
 Carving up
the string into fields that are vendor-specific would be like starting over.

/js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Mar 2014 19:47:43 +0100

On 19 Mar 2014, at 18:02, Andy Bierman <[email-masked]> wrote:

> Hi,
> 
> 
> On Wed, Mar 19, 2014 at 12:23 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> There was lots of WG discussion wrt/ instance naming (even more for interfaces),
> and no consensus could be reached on picking 1 naming scheme. We did not start
> with a plain string containing proprietary syntax. We ended up there.  Carving up

Agreed. It it not that everybody likes the naming schemes (including myself), but this has indeed been the result of looong WG discussions. A good thing is that the naming of instances is reasonably uniform across all the core data models.

Lada