[j-nsp] Soft removal of traffic from AE?

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Sat Oct 29 01:30:43 EDT 2016

Hi Saku,

> From: Saku Ytti [mailto:saku at ytti.fi]
> Sent: Saturday, October 29, 2016 2:16 AM
> On 29 October 2016 at 02:54,  <adamv0025 at netconsultings.com> wrote:
> > Saku is right there in saying that LACP should have provisions for
> > hitless addition and removal of links from bundle. (not quite sure
> > about removal though, but I'll play along).
> > But my experience is that's not how it works unfortunately.
> >
> > Let's talk about removal first.
> > This process is governed by link failure detection and that can be
> > done in many ways, fastest is the physical layer LAN/WAN/OTN-PHY
> > alarms -that will kick in well before the micro-BFD or CFM on each
> > bundle member link notices a failure.
> Question was not about outage, but operator removing link from an bundle. 

My understanding is that there is no difference and the same procedure is invoked during failure i.e. MAC_Operational=False.  

> LACP can signal this and do it gracefully without losing single packet, which for
> stated reason unfortunately does not mean that end user will experience it
> as lossless.
> From 802.1AX-2014 relevant section to start from is '6.3.14 Detaching a link
> from an Aggregator'
> If actual implementation does it gracefully or not, I cannot answer, but
> protocol does not prohibit it.

Actually I see a problem with that paragraph (hence my earlier comment about not being quite sure about hitless removal from LAG bundle). 
How I read it is, if you remove the link from LAG bundle, then LAG will: 
1)stop sending packets over that link  
2)notify other end 
3)stop accepting packets from that link 

There's no artificial delay between steps 2 and 3, nor any confirmation that there are no inflight packets on the link before step 3(so I assume step 3 is done immediately after step2). 
As I read it there's nothing accounting for link propagation delay and the time it takes the other end to react to the notification and to stop sending packets over the given link. 


::carrier-class solutions for the telecommunications industry::

More information about the juniper-nsp mailing list