[j-nsp] Prioritize route advertisement

[adamv0025 at netconsultings.com]

> From: Jeffrey Haas <jhaas at juniper.net>
> Sent: Monday, April 6, 2020 6:06 PM
> 
> > On Apr 6, 2020, at 12:59 PM, <adamv0025 at netconsultings.com>
> <adamv0025 at netconsultings.com> wrote:
> >
> >> Gustavo Santos
> >> Sent: Monday, April 6, 2020 4:06 PM
> >>
> >> Is there a way to prioritize advertisement on some BGP sessions above
> >> others? I tried the
> >> https://www.juniper.net/documentation/en_US/junos/topics/topic-
> >> map/bgp-route-prioritization.html
> >>
> > The feature you mentioned is used to say first send L3VPN routes
> > before L2VPN routes when talking to a given peer.
> > I'm not aware of any such mechanism to say peer 192.0.2.1 should be
> > served first and then peer 192.0.2.2 should be next, etc...
> 
> Junos roughly serves the back queue for the peer group based on the
> subsets of peers that get common updates vs. the peers that are ready to
> write.  In the presence of a large back queue for a peer in the group, we
> might appear sluggish to service some of the more in sync peers.  However,
> what will tend to happen is those slower and more out of sync peers will
> write block and next round we just move along to do other work.
> 
> >
> >> The question is if there is a way to work around this change that
> > behavior?
> >>
> > Wondering if it was due to some slow peer(s) Not sure if juniper BGP
> > works similarly to cisco BGP in this area (but considering the
> > differences in update groups between the two it might very well NOT be
> > the case) But cisco has the following to address slow peers holding
> > down the whole update group more info at:
> 
> Yeah, we don't need that.  We just form optimal micro-groups for the peers
> that are in the same sync level at a given part of the queue and are ready
to
> write.
> 
Hi Jeff,
Can you please expand on this last statement please?
How do these 17 output queues of the route prioritization system interwork
with the micro-groups you mentioned please?
The doc quoted by OP says " The queue servicing procedure operates per-BGP
peer group with each group maintaining its own token buckets." - I think it
means update-group rather than peer-group, where update-group might or might
not have a one-to-one relationship to actual update-group. But it also says
" This means that route priority can vary in each BGP peer group as well as
in specific neighbor configurations within the BGP peer groups" so I'm
guessing if it differs per peer then that peer is assigned to its own update
group (hence the reset of the session)?
Thank you.

adam