Hi Job,
On 09.01.18, 16:50, "Job Snijders" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/grow
