Hi Sasha, Martin,
Just one clarification below.
On 4/3/19, 7:05 AM, "Martin Bjorklund" <m...@tail-f.com> wrote:
Hi,
Alexander Vainshtein <alexander.vainsht...@ecitele.com> wrote:
> Martin,
>
> Lots of thanks for an interesting input.
>
> I have noticed that Appendix A in RFC
> 8349<https://tools.ietf.org/html/rfc8349#appendix-A> defines the
> key for static IPv4 and IPv6 unicast routes as
> “destination-prefix”.
Right (to be precise, the key is defined in the YANG models in section
8 and 9).
> draft-ietf-rtgwg-
>
yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-extend-01>
> claims that it augments the model defined in 8349, therefore, to the
> best of my understanding, it uses the same key for station IPv4 and
> IPv6 unicast routes.
Correct.
The way multiple alternatives are supported is via the existing RFC 8349
next-hop-list list.
This is keyed with an index. What the augmentation provides is a way to specify
a
preference for each next hop so that either ECMP or primary/backup uses case can
be supported. It is clear I need to expand the descriptive text for these
augmentations
in the draft-ietf-rtgwg-yang-rib-extend.
Thanks,
Acee
> At the same time Appendix A in this draft does not define any keys
> for the read-only RIB.
>
> Can you explain this controversy?
Not sure there's a controversy. The static route list is how you
configure static routes, and the RIB is the operational state of all
routes (static and others). Two different things.
The MIB had a single table to show routes and write routes. I don't
think the persistency of the routes you wrote into the MIB was
defined; perhaps these can be viewed as being "static".
/martin
>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> Email: alexander.vainsht...@ecitele.com
>
>
>
> -----Original Message-----
> From: Martin Bjorklund <m...@tail-f.com>
> Sent: Wednesday, April 3, 2019 1:34 PM
> To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
> Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
>
>
>
> Hi,
>
>
>
> Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
wrote:
>
>
>
> [...]
>
>
>
> > Meanwhile, could you please explain the rationale for changing the
>
> > data model that has been defined in RFC 4292 (where both the
>
> > destination prefix and the next hop have been parts of the index in
>
> > the appropriate MIB table) ?
>
> >
>
> > The side effect of this change is that it is not backward-compatible
>
> > with multiple existing RFC 4292-compliant RIB implementations:
>
> >
>
> > - Retrieval of such a RIB using YANG requires a stateful
mapper that
>
> > merges multiple RIB entries with the same destination prefix
and
>
> > different “simple” NH into a single entry with the
>
> > next-hop-list
>
>
>
> Note that the "route" list in the rib doesn't have any keys. This means
that you can report several entries with the same destination prefix. So I
think that this design is compatible with the MIB design.
>
>
>
>
>
>
>
> /martin
>
>
___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains
information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this
> transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
> and all copies thereof.
>
___________________________________________________________________________
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
