Subject: BFDoLAGs Updated

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 19 Dec 2011 16:00:10 +0530

Hi WG members,

We have posted a revised version of the BFD over LAGs draft.

Its available here:
http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt

Diff beween the -00 and the -01 version:
http://tools.ietf.org/rfcdiff?url2=draft-mmm-bfd-on-lags-01.txt

Would be great if the WG members can review this version and provide feedback.

We have also included a small discussion on Unicast vs Multicast encapsulation.
https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 19 Dec 2011 14:20:37 +0200

Manav, and all,
I've looked up the -01 version of the draft. It seems to address some of my earlier concerns (mainly dealing with various possible encapsulations) but, IMHO, still leaves the critical architectural issues unresolved.

Please consider the following scenario:

A LAG comprises N potential member links but limits the number of concurrently active links to M < N.
Priorities of the links are exchanged via LACP (which also guarantees that all the potential links have been, indeed, associated with the same LAG by both peers.
The standard behavior in this case would include the following elements:

1. LACP synchronizes priorities locally set for each link (so that each peer considers the candidate links in exactly the same order)
2. M < N links with highest priorities are bi-directionally agreed upon as both collecting and distributing using LAG.
 3. The remaining (M-N) healthy links are still monitored by LACP but do not carry client traffic, and LACP advertises them as neither" collecting "nor "distributing".

How is this going to change with the introduction of BLM?

In particular:

1. Would micro-BFD sessions run on inactive LAG members?
2. Suppose that one of the high priority links goes down, and the micro-BFD session indicates that two inactive links are healthy - would the link with the highest priority be selected for activation? 
3. Once the new link has been selected, what state would LACP advertise for it? (My understanding is that activation of a link starts with declaring it as "collecting but not distributing", and it passes to "collecting and distributing" only after seeing that the  partner state is "collecting", but I am not sure that the 802.1AX standard dictates this.)
4. Would the LAG try to send user traffic on a link with a healthy micro-BFD session even if the peer is still advertising its state (via LACP) as "not collecting"?  And what would happen to the traffic received from such a link?

In a different scenario, suppose that one of the links has been misconfigured with LAG ID that differs from that of the links on the other side. 

1. What is supposed to happen to its micro-BFD session (would it be started, could it reach UP state etc.)
2. Would the LAG try to send traffic via such a link if its micro-BFD session is UP?

The answer is not clear to me because the draft simply states that "BFD takes precedence over LACP in deciding the fate of individual member links  when both are run in parallel". This can be interpreted in many ways.

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bhatia, Manav (Manav)
> Sent: Monday, December 19, 2011 12:30 PM
> To: [email-masked]
> Subject: BFDoLAGs Updated
> 
> Hi WG members,
> 

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 Dec 2011 21:28:37 -0500

Dear Authors, et al.,
Please find my comments to the -01 version below:
*	Section 2.1, second para. I strongly disagree that IETF needs to standardize what is referred as "BFD over Big Pipe". I think it is more useful to take this discussion into Informational document where different implementations can be described and recommendations to interoperate provided.
*	Section 3.3 If standardization of the evaluation function put outside of the scope of the document then role of the Concluded BFD state is out of scope as well (second bullet in Section 4).
*	Section 7 considering discussion in Appendix A.1 I think that suggestion that request for link-local multicast IP addresses will be made is premature.
*	A.1 One of advantages of Unicast IP address, I suggest use of 127/8 range, used as destination IP address for IP/UDP encapsulation of control packets for micro-BFD is that each micro-BFD session might be assigned unique destination IP address. And I don't see any of listed disadvantages playing any role if destination IP address selected from 127/8 range.
*	A.2 Use of Ethernet multicast address can be suggested if operator is certain that LAG member is p2p in L2 sense. Otherwise, unicast Ethernet address should be used. 

Thank you for your kind consideration.

	Regards,
		Greg 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Monday, December 19, 2011 4:21 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: RE: BFDoLAGs Updated

Manav, and all,

1. LACP synchronizes priorities locally set for each link (so that each peer considers the candidate links in exactly the same order) 2. M < N links with highest priorities are bi-directionally agreed upon as both collecting and distributing using LAG.
 3. The remaining (M-N) healthy links are still monitored by LACP but do not carry client traffic, and LACP advertises them as neither" collecting "nor "distributing".

In particular:

1. Would micro-BFD sessions run on inactive LAG members?
2. Suppose that one of the high priority links goes down, and the micro-BFD session indicates that two inactive links are healthy - would the link with the highest priority be selected for activation? 
3. Once the new link has been selected, what state would LACP advertise for it? (My understanding is that activation of a link starts with declaring it as "collecting but not distributing", and it passes to "collecting and distributing" only after seeing that the  partner state is "collecting", but I am not sure that the 802.1AX standard dictates this.) 4. Would the LAG try to send user traffic on a link with a healthy micro-BFD session even if the peer is still advertising its state (via LACP) as "not collecting"?  And what would happen to the traffic received from such a link?

1. What is supposed to happen to its micro-BFD session (would it be started, could it reach UP state etc.) 2. Would the LAG try to send traffic via such a link if its micro-BFD session is UP?

 

Regards,
     Sasha

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 29 Dec 2011 10:00:23 +0100

Hello Gregory,

> *	Section 2.1, second para. I strongly disagree that IETF needs to standardize what is referred as "BFD over Big Pipe". I think it is more useful to take this discussion into Informational document…

And I strongly disagree with your disagreement :-)

Seriously: the BFD over Big Pipe ("BBP" for short) is used in the draft in combination with "BLM" (the BFD over LAG member), so it must be defined. This is where I also disagree with "informational document".

Do we need to define it in the same draft as BLM? Can be debated. It seemed practical to do but if the opinion is we need a separate draft then we can do so as well.

> *	Section 3.3 If standardization of the evaluation function put outside of the scope of the document then role of the Concluded BFD state is out of scope as well (second bullet in Section 4).

Doesn't make sense. The document defines the BLM session, the concluded state is part of that session, so it must be defined in this draft, including what it is for.

Maybe this is a matter of wording? "outside scope" vs. "implementation detail"?  In any case, we can define one evaluation function in the draft that MUST be implemented (but allow for alternative functions as well) if your concern is interoperability - is it?
(using the concluded state to influence the BBP session state is addressing any difference between the peer's evaluation function, btw)

Thanks for the feedback!

REgards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 29 Dec 2011 13:34:14 -0500

Dear Marc, et al.,
Thank you for taking time to respond in this busy holiday season.
I believe that we will be better off by defining requirements for BFD over LAG, a.k.a. BFD over Big Pipe, rather than specific variant of implementation known to authors.
Is Concluded BFD State intended to replace LACP as it is defined in IEEE 802.1ax-2008?
I think that it is beneficial to define BFD over Ethernet encapsulation perhaps in two variants - with IP/UDP header and without one. And I agree with Sasha and Tom (another thread of the discussion) that to view BFD over LAG member (BLM) as equivalent of indication of Layer 1 connectivity (though it is not only that).

	Regards,
		Greg

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]] 
Sent: Thursday, December 29, 2011 1:00 AM
To: Gregory Mirsky
Cc: Bhatia, Manav (Manav); [email-masked]
Subject: Re: BFDoLAGs Updated

Hello Gregory,

Thanks for the feedback!

REgards, Marc

> Behalf Of Alexander Vainshtein

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 29 Dec 2011 21:22:28 +0100

Hello Gregory,

> I believe that we will be better off by defining requirements for BFD over LAG, a.k.a. BFD over Big Pipe, rather than specific variant of implementation known to authors.

Okay, fair comment.

> Is Concluded BFD State intended to replace LACP as it is defined in IEEE 802.1ax-2008?

No. BFD on LAG members (BLM) is a booster for detection. Personally I would go for a network design that uses LACP to organize the LAG, then BLM for the detection speed.

> I think that it is beneficial to define BFD over Ethernet encapsulation perhaps in two variants - with IP/UDP header and without one.

Interesting. I have just send "draft-mmm-bfd-on-lags-02-B" to Mach and Manav, which is a variant of the draft using BFD directly in Ethernet. And we discuss the IP/UDP variant as well.

> And I agree with Sasha and Tom (another thread of the discussion) that to view BFD over LAG member (BLM) as equivalent of indication of Layer 1 connectivity (though it is not only that).

okay.

Thanks a lot for the feedback!

REgards, Marc

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 29 Dec 2011 15:32:41 -0500

Dear Marc,
Looking forward to -02 version.
Happy New Year! Best wishes and good luck to all!

	Regards,
		Greg 

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]] 
Sent: Thursday, December 29, 2011 12:22 PM
To: Gregory Mirsky
Cc: Bhatia, Manav (Manav); [email-masked]
Subject: Re: BFDoLAGs Updated

Hello Gregory,

Okay, fair comment.

okay.

REgards, Marc

> (using the concluded state to influence the BBP session state is 
> addressing any difference between the peer's evaluation function, btw)
> 
> 
> Thanks for the feedback!
> 
> REgards, Marc
> 
> 
> 
> 
> 
>