On Wed, Nov 19, 2008 at 10:19 AM, Stephen Stuart <[EMAIL PROTECTED]> wrote:
> 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?
Sorry, I forgot that we took that out.
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
