Hi Tim,
[tte] I believe that nh-cost might work providing that it would support
a minimal BGP peering session to the BMP router so that the BMP server
(receiver) can initiate requests for NH information on specifics NH's
that it's interested in, and if it's not restricted to just iBGP/RR
configurations.
Correct. It is not restricted.
draft-varlashkin-bgp-nh-cost-02 doesn't limit the next
hop requests to only prefixes advertised to the given neighbor, right?
Yes.
For this to work with BMP, we would need the BMP receiver to peer
directly with the BMP sender to request NH costs on NH's that pertain to
other prefixes learned by other peers on the BMP sender.
Well I think it depends on your BMP use model. Usually NH metrics would
ba valid at the given BMP peer. So within your domain you would end up
having as many nh-cost sessions as number of your BMP sessions.
Considering the
BMP receiver receives unmodified BGP updates from the other peers, next
hops could be duplicate if RD isn't factored into the request for NH
information.
If you are considering the case of multiple BGP SAFIs having identical
next hops let's observe that each such SAFI could result in different NH
metric.
However if you are considering things like add-paths I would assume
single reply would be sufficient.
It looks like draft-gredler-bgp-te-01 might be a better fit for
conveying the IGP information that I was thinking of, but the
implementation is more complex.
True !
Cheers,
R.
PS.
As to the point of "BMP receiver receives unmodified BGP updates from
the other peers" that is no longer the case in the current spec as I
have already tried to point out before in this thread. That is way I did
propose a new type to replay real unmodified BGP updates as they are
received from the peers. That was the original BMP intention. At this
point it is no longer the case in the spec.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
