Re: [GROW] A question to draft-ietf-grow-bmp-17

["John G. Scudder" <[e-mail]>]

> On Apr 4, 2016, at 11:31 AM, Ebben Aries <[e-mail]> wrote:
> 
> 
> On 04/03/2016 02:59 AM, Zhuangshunwan wrote:
>> Hi Ebben,
>> 
>> Thanks for your reply.
>> Please see inline with [Shunwan].
>> 
>> Regards,
>> Shunwan
>> 
>> -----邮件原件-----
>> 发件人: Ebben Aries [mailto:[e-mail]] 
>> 发送时间: 2016年4月1日 6:26
>> 收件人: Zhuangshunwan; [e-mail]
>> 主题: Re: [GROW] A question to draft-ietf-grow-bmp-17
>> 
>> 
>> On 03/31/2016 01:34 AM, Zhuangshunwan wrote:
>>> Hi all,
>>> 
>>> I have a minor question to draft-ietf-grow-bmp-17.
>>> 
>>> Please help me to understand correctly, thanks.
>>> 
>>> 
>>> 
>>> In draft-ietf-grow-bmp-17, Route Monitoring message was documented as
>>> follows:
>>> 
>>> 4.6.  Route Monitoring
>>> 
>>> 
>>> 
>>>   Route Monitoring messages are used for initial synchronization of
>>> 
>>>   ADJ-RIBs-In.  They are also used for ongoing monitoring of 
>>> ADJ-RIB-In
>>> 
>>>   state.  Route monitoring messages are state-compressed.  This is 
>>> all
>>> 
>>>   discussed in more detail in Section 5.
>>> 
>>> 
>>> 
>>>   Following the common BMP header and per-peer header is a BGP Update
>>> 
>>>   PDU.
>>> 
>>> 
>>> 
>>> My question:
>>> 
>>> How to understand "Following the common BMP header and per-peer header 
>>> is a BGP Update PDU." ?
>>> 
>>> Does it mean that "only" one BGP Update PDU can be encapsulated after 
>>> a per-peer header?
>>> 
>> 
>> Yes
>> 
>>> When multiple BGP Update PDUs share the same per-peer header, can it 
>>> support "1 per-peer header + multiple BGP Update PDUs" ?
>>> 
>> 
>> No - each UPDATE msg is encapsulated in a separate Route Monitoring msg.
>> The text could probably be adjusted to spell this out better.
>> [Shunwan] I think this text is better.
>> 
>> Is your concern the overhead introduced by replicated common/per-peer headers should processing be common across multiple UPDATE msg (down to the timestamp)?
>> [Shunwan] Yes, this is what my concern. My colleagues noticed that multiple BGP Update Msgs share the same per-peer header (including the same timestamp ), so we think if we can put multiple BGP Update Msgs after a sharing per-peer header, so a separate Route Monitoring msg will carry more information.
>>> 
> 
> I think the tradeoff here is efficiency gain in network i/o vs. the
> potential buffering, correlation and packing now needed on the
> monitoring router.  As-is, we have a 1:1 correlation of UPDATE/Routing
> Monitoring which makes this mostly pass-through.  I'm not sure if
> network i/o and overhead has been a concern yet today w/ production
> implementations

Agreed. It generally is down in the noise compared to other costs.

Although I acknowledge there is some hypothetical gain from coalescing multiple BGP PDUs under one BMP header, I don't support changing the current way of doing it. In addition to other concerns, it adds some small complexity to the processing path since right now you can know you always are going to process one PDU.

--John