Hi Sasha,
On 4/3/19, 7:27 AM, "Alexander Vainshtein" <alexander.vainsht...@ecitele.com>
wrote:
Martin,
Lots of thanks for a prompt response.
My reading of your response is that, if you need multiple static routes
with the same destination but different next hops, you configure them as a
single route with next-hop-list, but what you see when you retrieve the RIB may
be multiple individual routes, each with its own simple next hop. Or it may be
something else, since no keys have been defined in the read-only representation
of the RIB.
Is my reading correct?
No - you'd see a single route and next-hop-list with the alternatives when it
is retrieved.
Thanks,
Acee
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 2:05 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> 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.
> 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.
> ______________________________________________________________________
> _____
___________________________________________________________________________
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
