Re: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling

[Thomas King <[e-mail]>]

Hi Job,

On 09.01.18, 16:50, "Job Snijders" <[e-mail]> wrote:

    On Tue, Jan 09, 2018 at 03:34:46PM +0000, Will Hargrave wrote:
    > On 9 Jan 2018, at 11:35, Job Snijders wrote:
    > > > Our suggestion for handling LAGs looks like this: Typically, a
    > > > minimum number of port members can be defined for a LAG being up.
    > > > The LAG is not touched by BGP Session Culling during a maintenance
    > > > unless this number is undercut. If the number if undercut the LAG
    > > > is handled by BGP Session Culling as defined in the Internet
    > > > Draft.
    > > > 
    > > > If no value for the minimum number of active port members is
    > > > defined for a LAG, the value 1 should be used as this is the
    > > > behaviour of LAGs today already.
    > >
    > > Is this in context of multi-chassis LAG?
    > 
    > I think if we include anything about LAGs we should make it very clear
    > that you must apply the culling ACL to *either* all ports of a LAG
    > *or* none.  Applying it to half of an MCLAG could be disastrous.
    
    Will, my reading of Thomas' message is slightly different, I don't think
    he is proposing to apply culling ACLs on half the ports of a LAG, he
    proposes that culling ACLs are only applied (to all ports) when more
    than X members of a LAG will be impacted by the maintenance (where X is
    an ixp-participant configurable number).

This is what I meant!
    
    > I didn’t realise there were IXPs using MC-LAG. Discovering this maybe
    > surprise some members.
    
    Thomas, in terms of IETF logistics, the RFC-To-Be draft-ietf-grow-bgp-session-culling
    document has already been submitted to the RFC Editor and is in the
    queue, information on LAGs cannot be added at this point to the
    publication.

Really, my understanding is it could be added. It is not typical but doable.

    However, since this is a BCP, the next iteration could include
    additional information as our understanding of the culling practise
    improves, and the BCP number wouldn't change of course.
    
    From what I read in your message your organisation is still in the early
    phases of applying the 'culling' mechanism. I recommend you to (over
    time) carefully take notes of the interaction between LAG and culling,
    and whatever arises as the best current practise is documented in the
    next revision of the BCP.

From my point of view the culling mechanism is very import for LAGs and should be clearly defined in order to be useful und comprehensive. As we see more and more IXP peers moving to LAGs (n times 10GE and also n times 100GE) this topic is already very important. It will gain more importance in the future as traffic volumes increase.

Best regards,
Thomas