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

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 May 2011 09:51:58 +0200 (CEST)

Hi,

I have some general questions regarding this document.  In the
previous version, there was one single module, but in this version, it
is split into two, one generic, and one ipv4-unicast specific module.
This seems fine, from a high level pow.

But in the current document, some of the generic concepts, like route
filtering, routing tables, are defined in the ipv4-unicast module.
The only concept defined in the generic routing module is routing
process.  What is the reasoning behind this?  It means that when we
define e.g. a ipv6-unicast module, we either need to reinvent route
filters and routing tables, or might come up with completely new
concepts.

Woudln't it be better to move all the generic concepts back into the
main routing module?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 May 2011 10:28:25 +0200

> process.  What is the reasoning behind this?  It means that when we

I did it in order to be able to support other address families, especially in multiprotocol BGP. Even if nobody was interested in AppleTalk or IPX anymore, things like IP-MPLS or multicast will be needed, I think.

> filters and routing tables, or might come up with completely new

Yes, that's the deal.

> Woudln't it be better to move all the generic concepts back into the

The concepts could perhaps be made generic, to some extent, only for pure unicast IP but not for other address families. So we could have a generic model for IP but I don't think it we could go very far with it. One problem is that union types such as ip-address don't tell whether their contents is IPv4 or IPv6.

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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 May 2011 10:46:50 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I did it in order to be able to support other address families, especially in
> multiprotocol BGP. Even if nobody was interested in AppleTalk or IPX anymore,
> things like IP-MPLS or multicast will be needed, I think.

It seems to me that 'routing-protocol-instance', 'route-filters', and
'routing-tables' all could be generic.  The ipv4-unicast module would
augment 'routing-protocol-instance' with its static routes, and
augment 'routing-table' with the ipv4-specific routes.

Maybe we can discuss this approach off-list...

/martin