Comments inline marked [tte] On 12/8/11 12:31 PM, "Robert Raszuk" wrote:
>> The next hop thing is interesting, but I have to ask: can't you pull >> it out of the IGP already? > > Not possible across IGP areas/levels. > However perhaps it would be interesting to discuss pros/cons of using > either: > http://tools.ietf.org/html/draft-gredler-bgp-te-01 [1] > http://tools.ietf.org/html/draft-varlashkin-bgp-nh-cost-02 [2] > Tim - do you think using any of those would not be feasible for you ? If > not I am personally fine to extend BMP to carry next hop metrics. > Of course Stephen will say that it requires to run BGP on the linux host > and is a dangerous thing, but is that really an issue ? [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. draft-varlashkin-bgp-nh-cost-02 doesn't limit the next hop requests to only prefixes advertised to the given neighbor, right? 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. 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. 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. Thanks, Tim Links: ------ [1] http://tools.ietf.org/html/draft-gredler-bgp-te-01 [2] http://tools.ietf.org/html/draft-varlashkin-bgp-nh-cost-02 [3] mailto:[email protected]
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
