On 3/8/16, 6:35 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
> >> On 08 Mar 2016, at 12:08, Acee Lindem (acee) <a...@cisco.com> wrote: >> >> >> >> On 3/8/16, 1:55 AM, "Martin Bjorklund" <m...@tail-f.com> wrote: >> >>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: >>>> On Tue, Mar 08, 2016 at 01:23:50AM +0000, Acee Lindem (acee) wrote: >>>>> >>>>> The thing about the static route definition for IPv4 and IPv6 is that >>>> their RIBs will have pretty much the same structure other than >>>> differences in address type. For other AFs, there may be other >>>> differences as well. For every augmentation, we’re essentially >>>>doubling >>>> the specification effort. >>>>> >>>> >>>> One benefit of having separate augmentations is that the data types >>>> are tighter. For example, the data model does not allow an IPv6 next >>>> hop for an IPv4 prefix, i.e., you can't mess up address families since >>>> the data model forces a clear separation (and generic validation will >>>> catch that in contrast to having the runtime catching inconsistent >>>> address family data). >>>> >>>> How much that matters likely can be debated. But somehow it feels like >>>> keeping things separate allows for independent evolution, which may >>>> proof to be very handy in the future. I kind of liked Lada's approach >>>> to maintain the architectural separation in the data model. >>> >>> I agree. I think the model is more clear this way. I guess I don't >>> understand why Acee wants to have a single module? >> >> I was trying to eliminate the effort of updating both modules with the >> exact same augmentations. However, I guess I’m ready to relent on this >> point. > >OK, thanks. Do we want to post another revision before IETF 95? If so, we >should probably do most preparations this week because I will be on >vacation next week. I think we should at least try and get the structural changes posted before IETF 95. We can meet on next hops at IETF 95. Thanks, Acee > >Lada > >> >> >> Thanks, >> Acee >> >> >> >>> >>> >>> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
