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

Hi guys,

any update on this?

Best regards,
Thomas

On 11.01.18, 22:34, "GROW on behalf of Thomas King" <grow-bounces@ietf.org on behalf of thomas.king@de-cix.net> wrote:

    Hi Job,

    On 09.01.18, 16:50, "Job Snijders" <job@instituut.net> 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

    _______________________________________________
    GROW mailing list
    GROW@ietf.org
    https://www.ietf.org/mailman/listinfo/grow