Subject: Re: [GROW] I-D Action: draft-ietf-grow-bmp-06.txt

From: [email-masked]
Date: Wed, 14 Dec 2011 16:52:09 -0700

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-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Dec 2011 01:01:47 +0100

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

Yes.

> 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

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

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.