Hi Ladislav,

>this work, or at least its general parts, is closely related to the
>following work item of the NETMOD WG:
>
>http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09

Yes. I agree and I've been aware of this document all along.


>I tried to compare these two documents, and IMO the match is pretty good.
>Paradoxically, the match would be even better if we take one of the
>previous revisions of the routing-cfg documents because some constraints
>that were originally present have been relaxed in the meantime (details
>follow).
>
>I think it would make a good sense to coordinate these two efforts, and
>it should't be difficult.

Agree again.


>
>Specific comments:
>
>1. What you call "routing instance" is very similar to "router
>(instance)" in routing-cfg. Interfaces are also assigned to each router
>instance, but we don't require (since rev. -03) that the sets of
>interfaces assigned to different router instances be disjoint. One use
>case is that two router instances may be used for different address
>families, e.g., instance A for IPv4 and B for IPv6. Then the same
>interface may be used in A for IPv4 traffic and in B for IPv6. Perhaps
>this also depends on the definition of "interface".

Interface is not address family specific. It's not clear why one would
need 2 router instances, one per address type. The way I've been modeling
this is how I've seen customers use interfaces. They associate all
features with a given interface as part of one domain. So everything
related to a given GigE interface (like routes, VPNs, etc) are managed in
a wholesome way.


>2. Until rev. -05, each routing table was also confined to one router
>instance. This was relaxed based on the following comment of a Routing
>Directorate reviewer (Thomas Morin):
>
>"Allowing multiple "routers" is a good starting point for using these
>specs in the context of RFC4364
>(MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the
>way the filters are defined would
>not work in the context of RFC4364, where a BGP routing instance in the
>master "router" exports selected
>routes in each of the routing table of each VPN (VRF).  The VRF also
>export routes to the master
>instance."

IMO this is the export-import policy stuff (that I left out on purpose in
rev -00). IMO, import-export between tables in different router instances
should be supported/allowed. But that does not mean the tables need to be
in multiple router instances. Based on your knowledge of Yang, do you
think it's not possible to define import-export of routes between tables
in different instances?

Rest of your comments were data-model specific, which I will defer for now
(we'll take that up on a separate thread).

Thanks
Nitin



_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to