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:[email protected]] > 发送时间: 2016年4月1日 6:26 > 收件人: Zhuangshunwan; [email protected] > 主题: 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 >> >> >> >> Thanks, >> >> Shunwan >> >> >> >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow >> _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
