On Tue, Nov 18, 2008 at 9:09 PM, Shane Amante <[EMAIL PROTECTED]> wrote:
> Hi John,
>
> On Nov 12, 2008, at 5:16 PM, John G. Scudder wrote:
>>
>> GROW folks,
>>
>> I'll be presenting draft-scudder-bmp-01 ("BGP Monitoring Protocol") at the
>> meeting in Minneapolis. Long-time GROW fans may remember that the WG
>> requested to make the -00 version a WG document way back in 2005. It turned
>> out that there were some major implementation hurdles with the draft as
>> written and it became moribund and never did get issued as draft-ietf-grow.
>>
>> Fast forward to present, there's been significant renewed interest so
>> we've dusted off the draft and modified the mechanism to make it more
>> implementor-friendly. I'm hoping that the WG would still, after the long
>> hiatus, like to adopt the draft.
>
> I'm glad to see this draft has been resuscitated and I do support its
> adoption.
>
> A few questions:
> 1) The draft says the following in Section 2:
> ---snip---
> If the peer is a "Global Instance Peer", this field is zero filled. If the
> peer is a "L3VPN Instance Peer", it is set to the route distinguisher of the
> particular L3VPN instance that the peer belongs to.
> ---snip---
> I'm a little confused by the second sentence. Is that referring to the case
> where a router is doing RFC 4364 "Option A" style eBGP with a remote peer,
> or something else?
>
> 2) In Section 3, the draft talks about sources of routing information
> (Adj-RIB-In or Loc-RIB) sent in Route Monitoring messages. Would it be
> useful to have a bit in the BMP "Peer Flags" that indicates if the path
> being sent in a RM message was retrieved pre- (Adj-RIB-In) or post-
> (Loc-RIB) policies, so the receiver knows which he/she is looking at?
The "L" flag described in section 2.1 conveys that information?
Stephen
> 3) How will BMP cope with BGP flap dampening being enabled on a BMP source
> router? In other words, a router (configured as a BMP source) receives a
> series of WITHDRAW's & UPDATE's that it is configured to apply flap
> dampening on, suppressing re-advertisement of these updates further into an
> AS. If the BMP source is forwarding messages from Adj-RIB-In, would a BMP
> receiver see all incoming WITHDRAW's & UPDATE's associated with a "flap"
> event, (even though these updates would have been suppressed from further
> re-advertisement after flap dampening is applied)? How would, or should, a
> BMP receiver know that flap dampening is enabled and/or would be applied?
> The reason I ask is perhaps this is more a question of the 'authenticity'
> of "monitoring data" at a BMP receiver with respect to formulating what did
> (or could) have happened with a series of Updates being propagated further
> within an AS? Or, perhaps there's another answer?
>
> -shane
>
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
