Hi Robert,
> Just two follow up points,
>
> #1 - I can't stop the feeling that DROID is very IGP centric and not generic
> enough. Do you think we need DROID-2 to start offloading BGP or at least stop
> trashing it ? Or you think that DROID as proposed could take on day one
> flowspec v2
Hi Tony,
Just two follow up points,
#1 - I can't stop the feeling that DROID is very IGP centric and not
generic enough. Do you think we need DROID-2 to start offloading BGP or at
least stop trashing it ? Or you think that DROID as proposed could take on
day one flowspec v2 with its various
Les,
> Nice acronym.
Thank you. I blame the wordle craze. :)
> As regards the original use case (Node Liveness), my opinion hasn’t changed.
> Repackaging this in a more generic wrapper (which makes sense to me) doesn’t
> alter my opinion – which is this isn’t a good way to go.
This
Hi Robert,
> Very happy to see this draft.
Thanks.
> First question - the draft seems to be focusing on hierarchical IGPs and is
> clearly driven by liveness propagation discussion.
The main problem in networking is scale. If you haven’t dealt with scale, you
haven’t solved the
Tony –
Nice acronym.
As regards the original use case (Node Liveness), my opinion hasn’t changed.
Repackaging this in a more generic wrapper (which makes sense to me) doesn’t
alter my opinion – which is this isn’t a good way to go.
As regards the new use case (Capabilities), I think what
Hi Tony,
Very happy to see this draft.
First question - the draft seems to be focusing on hierarchical IGPs and is
clearly driven by liveness propagation discussion.
But the motivation of offloading non routing information from IGPs (and/or
BGP) is also full applicable to non hierarchical IGPs
Hi all,
As discussed during our last meeting, the Node Liveness Protocol could be
generalized to support arbitrary data.
I’ve done that work, turning it into a distributed object store.
In particular, node capabilities are now a generic example of the use of this
mechanism. Node Liveness is
In the MIB, the base types don't include the zone -
https://www.ietf.org/rfc/rfc4001.txt
It was very unfortunate that the YANG IP addresses included the zone in the
base types.
Tom - I think it would be hard to find an author where including the zone was a
conscious decision.
Thanks,
Acee
From: Acee Lindem (acee)
Sent: 04 April 2022 15:58
Hi Tom, +Juergen, netmod WG,
I think the question you ought to be asking is whether the base IPv4 and IPv6
address types should be modified to NOT include the zone and the zone versions
should be added as a separate YANG type.
The RFC 6991
Hi Tom, +Juergen, netmod WG,
I think the question you ought to be asking is whether the base IPv4 and IPv6
address types should be modified to NOT include the zone and the zone versions
should be added as a separate YANG type.
The RFC 6991 is under revision now:
I assume that this is a refresh while waiting for ospf.yang to wind its way
through the system
I wonder if the ip address should be the no-zone variant from RFC6991 - I never
know the answer to that so keep asking.
Some time the contact needs updating to https://datatracker and the TLP to
11 matches
Mail list logo
