Subject: RE: BFD on LAG interfaces

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Dec 2011 14:26:28 +0200

Resending as plain text - the HTML one has exceeded the 4oK limit...

Regards,
     Sasha

From: Alexander Vainshtein 
Sent: Thursday, December 15, 2011 2:22 PM
To: 'Greg Mirsky'; Dave Katz; 'Bhatia, Manav (Manav)'; 'Nitin Bahadur'
Cc: [email-masked]
Subject: RE: BFD on LAG interfaces

Manav, Dave, Greg, Nitin and all,

Several comments if you do not mind. And I apologize in advance for a rather long email.

Here is my understanding of the problem we try to solve:
1. We are dealing with a LAG between a pair of, say adjacent routers that is::
a. Comprised of links that do not support detection of failure at the physical layer (e.g., loss of optical power) – if they were, we would not need BFD to do the same. (There are several scenarios when detection of link failure at the physical layer is problematic in the real-world deployments)
b. Expected to go down while some of the comprising links are still up (otherwise the regular 1-hop BFD session would probably do the job).
2. We want to detect the “insufficient number of active  links” condition much faster than could be done by using standard LACP, and to bring the LAG down based on this condition. 
3. The situation when LAG goes down due to insufficient number of active links must be reversible, i.e., the LAG must be able to go UP once this condition disappears. 

Do these notes capture the problem space correctly? Or did I miss something important?

One point that is not clear to me is the timeframe for bringing constituent links of a LAG up. I would expect that the requirements for that could be much more relaxed (e.g., in order to avoid link flapping). Is that correct? If it is, one possible implication is that it is possible to use different mechanisms for bringing links DOWN and UP. To the best of my understanding, this is how BFD is supposed to be used with routing adjacencies today, i.e. BFD can bring the adjacency DOWN quite fast, but it has to be brought UP by the appropriate routing protocol.

When it comes to the solution space, there seem to be several candidates:
1. Improved (faster) LACP. This has been suggested by Dave, but I have my doubts regarding this course of action (in addition to LACP being owned by IEEE 802.1):
a. LACP is one of the IEEE 802 SLOW protocols. The summary rate of all these protocols per link is limited by IEEE to 10 per second
b. LACP frame format allows just one bit to define the expected peer transmission interval (1” or 30”).  
2. IEEE 802.1ag (Ethernet CFM). This could definitely do the job, but, as mentioned by Shane on this list, is operationally heavy. You would probably have to treat each constituent link of LAG as a separate MA with a distinct name; configure a separate MEP with its own  MEP ID on both sides of the link etc.
3. BFD in some special encapsulation:
a. Any such encapsulation must provide for distinguishing between a BFD session that is supposed to run over the LAG as a whole and a BFD session that is supposed to run over a specific constituent link of the LAG. Ability to distinguish between these should exist even before the session has been fully established (i.e., when the Active side sends out a packet with Your Discriminator set to 0).  This looks to me as an absolute requirement
b. The nascent BFD session that has been identified as link-specific would be bound to the constituent physical link from which its first packet has been received
c. BFD packets that have been received with a valid Your Discrimination that has been associated with a specific physical link but came  from a different physical link MUST be discarded (similar to what happens with received BFD packets that fail the authentication checks)
d. Failure of a BFD session that has been bound to a specific constituent link of a LAG would be interpreted as the link going DOWN, and an appropriate indication passed to the Aggregator(see IEEE 802.3-2005, Clause 43) so that it can:
i. Disable collection and distribution on that link
ii. Declare LAG DOWNM if the number of active links has decreased below the minimal number of links, and pass this indication to various MAC clients
4. If LACP is used with the LAG in question, bringing the links UP (and, if necessary, bringing LAG as a whole UP) can be relegated to it. There is no need to overload BFD (or any other solution – excluding, of course, faster LACP) with this functionality. This means that IP-based BFD encapsulations can be safely used as solutions in this case. 
a. The BFD session using an IP-based encapsulation that has been bound to a link in a LAG that went DOWN would wait for LAG coming UP again in order to be restarted.
b. This scheme seems to eliminate the potential deadlock mentioned by Manav in his response to Nitin. 
i. IMHO and FWIW the approach described by Nitin (a dedicated UDP port) is preferable 
ii. In any way i suspect that usage of IP encapsulations with multicast IP addresses would not help: If LAG, as an IP interface, goes down, it may safely discard any IP packets it receives
5. If LACP is not used with the LAG in question, a BFD encapsulation that does not rely on IP/UDP (as proposed by Dave) looks like the only possible solution in this class:
a. Once the link-bound session goes  DOWN, the BFD state machine tries to bring it up again
b. Once it is UP, this session indicates to the Aggregator that the link can be used for collection and distribution
c. The Aggregator brings UP the LAG as a whole towards MAC clients if there is enough active constituent links.

IMHO and FWIW such an approach would minimize (and, in the case of BFD running directly over Ethernet, completely eliminate) architectural violations.
As such, it would be (hopefully) backward compatible both with the existing LAG implementations and existing BFD ones.

Again, did I miss something?

Regards,
    Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, December 15, 2011 7:53 AM
To: Dave Katz
Cc: [email-masked]
Subject: Re: BFD on LAG interfaces

Dear Dave and All,
I think that Mach brought the right point and that problem we can work is not just BFD over LAG's constituent link but, as Dave pointed earlier, BFD over Ethernet, with or without IP addressing. And I'll draw parallel with RFC 5885 and RFC 6428 that use BFD over MPLS, i.e. ACH VCCV encapsulation without IP header.

Regards,
Greg
On Wed, Dec 14, 2011 at 7:01 PM, Dave Katz <[email-masked]> wrote:

On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote:
>
>> As far as this particular draft goes, I think trying to make
>> this work over IP creates a whole pile of issues that cannot
>> be solved in a standard way, because it essentially requires
>> that BFD tap into private APIs in order to work.
>
> I am not sure I understand what private APIs are you referring to. I think the confusion stems from the two modes that we have defined in Sec 4.
My point is that running IP over an individual leg is an unnatural act, as it is architecturally incompatible with how LAGs are supposed to work (IMHO).  As a result, implementers have to hack something into their implementations to sort-of-pretend-but-not-really that IP is enabled on the individual legs.

There is no good way to spec such a thing because there isn't supposed to be any IP binding to the individual leg.  What you're doing, in effect, is modifying the definition of a LAG in order to shoehorn BFD into the picture, which is rather out-of-scope for the BFD group (and for the IETF in general).  I don't see how it would be possible to standardize such a thing.

>
> In the first mode we just run BFD over the member links. There is no additional BFD running over the whole bundle. In this mode, BFD is simply replacing LACP. It keeps track of all the links that are alive and informs the LAG manager (or some entity, beyond the scope of this document) about it. The IP interface over the LAG is torn down once the number of remaining links reaches the minimum threshold number. BFD is thus used to decide the fate of an IP interface.
>
> We had kept this mode as the default mode.
>
> I am now having second thoughts on whether this is the right thing to do or not.
It's a reasonable thing if all you're doing is replacing LACP with BFD as the per-leg liveness test;  it makes BFD invisible to applications, as the service interface is the top of the LAG.  This is subtly different than having a BFD-over-the-top session in addition to the individual legs, as doing so provides visible BFD semantics rather than LAG semantics, and the service interface reflects those semantics (so you can potentially do things like AdminDown and the like).
>
> Then there is the second mode described in Section 4.
>
> Establish BFD sessions over each member link. The aggregate result of this decides the fate of only the LAG (and not that of the IP interface defined above it). Establish another BFD session over the LAG (which is what most implementations do today) that runs sedate timers and ensures IP reachability with the other end. This mode gives us the best of both worlds.
>
> Would it make more sense to keep this mode as default and completely do away with the first mode that we have defined?
I'm agnostic about the choices;  I can see some benefit in both.  But the real problem is how to do the per-link stuff in a reasonable way.

--Dave

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: Marc Binderberger <[email-masked]>
Date: Fri, 16 Dec 2011 17:59:05 +0100

Hello Alexander,

tried to reply to the end of this thread but it was too difficult to follow the many replies.

> a. Comprised of links that do not support detection of failure at the physical layer (e.g., loss of optical power) – if they were, we would not need BFD to do the same. (There are several scenarios…

correct.

> b. Expected to go down while some of the comprising links are still up (otherwise the regular 1-hop BFD session would probably do the job).

yes

> 2. We want to detect the “insufficient number of active  links” condition much faster than could be done by using standard LACP, and to bring the LAG down based on this condition.

yes but ... the draft is clearly written with "bring the LAG down" in mind. But one could alternatively let the LAG aside and use BFD to initiate a reroute of traffic away from the LAG interface. My impression is that Greg and Jeff implemented along this line.

> 3. The situation when LAG goes down due to insufficient number of active links must be reversible, i.e., the LAG must be able to go UP once this condition disappears.

yes, I would prefer this ;-)

> One point that is not clear to me is the timeframe for bringing constituent links of a LAG up. I would expect that the requirements for that could be much more relaxed (e.g., in order to avoid link…

the draft allows this, section 3.2 "To avoid this deadlock ...". So using BFD to bring down fast alone is covered. Now RFC5882, e.g. section 4.1, mentions that waiting for BFD's Up notification may be useful. Thus we allowed this in the draft as well.

[I skip the LACP, CFM part. We had this. Nothing wrong technically but somehow customers push BFD teams to deliver]

> a. Any such encapsulation must provide for distinguishing between a BFD session that is supposed to run over the LAG as a whole and a BFD session that is supposed to run over a specific constituent…

Not sure about "absolute" but I agree that running the per-member (aka micro) sessions should be possible in parallel to BFD over the whole LAG.

> c. BFD packets that have been received with a valid Your Discrimination that has been associated with a specific physical link but came  from a different physical link MUST be discarded (similar to…

right, interesting detail. I think we should add this to the section 3.

> d. Failure of a BFD session that has been bound to a specific constituent link of a LAG would be interpreted as the link going DOWN, and an appropriate indication passed to the Aggregator(see IEEE…

reminds me, if we stick to the close interaction with the LAG then we likely need a paragraph explaining "LMM" and linking it to the term aggregator.

> 4. If LACP is used with the LAG in question, bringing the links UP (and, if necessary, bringing LAG as a whole UP) can be relegated to it. There is no need to overload BFD (or any other solution – excluding, of course, faster LACP) with this functionality.

see my comment above. Agree, we don't need BFD to bring up. But it's not overloading, coupling the protocol "bringup" with BFD's Up state exist in other cases as well (e.g. ISIS)

> This means that IP-based BFD encapsulations can be safely used as solutions in this case.

I'm not sure. I don't think that Dave Katz' reply was about bringing up the LAG session - the draft allows to ignore BFD for bringing up anyway. It's about the APIs you use.

> b. This scheme seems to eliminate the potential deadlock mentioned by Manav in his response to Nitin.

indeed.

> i. IMHO and FWIW the approach described by Nitin (a dedicated UDP port) is preferable

It's a way to differentiate micro from LAG ("macro"?) session. Personally I prefer the destination IP to differentiate (similar to RFC5884, only I wouldn't use 127/8 exactly because it's in use already by this RFC).

Guess this one can be debated ad infinitum :-)

> ii. In any way i suspect that usage of IP encapsulations with multicast IP addresses would not help: If LAG, as an IP interface, goes down, it may safely discard any IP packets it receives

??? the multicast IP was for: (a) having a mcast MAC and  (b) having a dedicated IP address.
Not sure how this fits into (i) talking about UDP ports.

[skipping the LAG w/o LACP. Have to think about it :-) ]

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 18 Dec 2011 17:59:44 -0800

Hello,

Section 3.2.

>   A member link of the LAG is not used anymore for data forwarding
when
>   the particular BFD session running over that link goes down.  The
>   member link MUST be removed from the LAG.  The BFD session for the
>   link remains, i.e. it is not deleted.

It is not clear when BFD session should get deleted (nor created). With
above statement, BFD session could remain even when operator decides to
shut down a member, depending on how it's interpreted/implemented. When
LACP is used, LMM will startup LACP only when interface is up. L2 check
starts only when L1 check passes. Check is done from bottom layer
upwards. Going by same idea, BFD session should only be created when L2
check passes (LACP), when L2 check is being used. If L2 check is not
being used, then L1 check is required for BFD session to get created.
Absence in L1/L2 check pass should cause corresponding BFD sessions to
get deleted.

> > 3. The situation when LAG goes down due to insufficient number of
active
> links must be reversible, i.e., the LAG must be able to go UP once
this
> condition disappears.
> > One point that is not clear to me is the timeframe for bringing
> constituent links of a LAG up. I would expect that the requirements
for
> that could be much more relaxed (e.g., in order to avoid link
flapping).
> Is that correct? If it is, one possible implication is that it is
possible
> to use different mechanisms for bringing links DOWN and UP. To the
best
> of my understanding, this is how BFD is supposed to be used with
routing
> adjacencies today, i.e. BFD can bring the adjacency DOWN quite fast,
but
> it has to be brought UP by the appropriate routing protocol.
> 
> the draft allows this, section 3.2 "To avoid this deadlock ...". So
using
> BFD to bring down fast alone is covered. Now RFC5882, e.g. section
4.1,
> mentions that waiting for BFD's Up notification may be useful. Thus we
> allowed this in the draft as well.
> 
> 
> [I skip the LACP, CFM part. We had this. Nothing wrong technically but
> somehow customers push BFD teams to deliver]

Generally speaking, when up/down use different methods, I've seen a
system fall into continuous flap cycle. Down by BFD, up by protocol/LMM
is one possible approach, and your draft wants to allow this for
interoperability purpose. I can understand the need, but side effect can
be nasty, and it (possible continuous flap) can be described?

Section 4, first bullet.

LAG will be taken down when BFD fails on sufficient members (LAG
interface state will be down). LAG will come up potentially when BFD on
sufficient members come up (LAG interface state will be up). This
behavior implies that all applications will benefit (by monitoring LAG
interface state) even if those applications do not configure BFD on LAG.
Sure, one can configure applications with BFD over LAG, but that's not
an absolute requirement for this model. Statements regarding this
behavior will be beneficial to readers.

Thanx,
Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 19 Dec 2011 09:32:33 +0100

Hello Nobo,

thanks for the comments. Let me check this with the new version we are just preparing (almost done).

And yes, a cleaner description when the creation/deletion is part of it.
But I also think this is where Alexander's comment came from: without some modifications in 802.1AX it will not be possible to lock the "going UP" with BFD. Otherwise you always run into questions and issues - starting LACP first? Or BFD first? Or both in parallel?

> be nasty, and it (possible continuous flap) can be described?

*sigh* yes ... maybe we should write a draft on flap dampening? :-)

Let me go through our latest (internal) version if that addresses your points.

Thanks!

REgards, Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 19 Dec 2011 14:56:54 -0800

Hello Marc.

I see new revision out there, will have to go check it out.

The other question that I have on this draft is, do we really need/want
to reserve IP multicast address for this purpose. Most cases, if not
all, where operator wants to use BFD to protect LAG at member level
should have some sort of IP address assigned at LAG. If not, it can be
assigned one (I see no reason where that isn't possible). In such case,
could we not use assigned IP address on the LAG to run BFD session at
member? Resulting behavior will be less deviating from RFC5881: same
demux procedures can be used when discriminator is zero(0), no need to
come up with special case of TTL=1 which was discussed. I'm questioning
this aspect since I didn't see any strong arguments for burning up IP
multicast address.

Thanx,
Nobo

> -----Original Message-----
> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Monday, December 19, 2011 5:33 PM
> To: Nobo Akiya (nobo)
> Cc: Alexander Vainshtein; Dave Katz; [email-masked]
> But I also think this is where Alexander's comment came from: without
> some modifications in 802.1AX it will not be possible to lock the
"going
> UP" with BFD. Otherwise you always run into questions and issues -
starting
> LACP first? Or BFD first? Or both in parallel?
> 
>

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 20 Dec 2011 00:38:28 +0100

Hello Nobo,

> I see new revision out there, will have to go check it out.

Thanks for the interest :-)

> should have some sort of IP address assigned at LAG.

I have seen there had been some "unnumbered" discussion but actually that is not the reason. Actually "unnumbered" was put aside when we discussed the original draft-chen-bfd-interface and the list feedback was to focus on LAG with IP at that time.

What we want to achieve:

- you can have a member-link session (aka "micro session") 
- you can have additionally a BBP session (the single session over LAG) for the main LAG interface

On the receiving side, what do you do to differentiate these sessions (think about the your_discr zero case)?

(i) different address
(ii) different UDP port

Both should work. We started the draft with (i) in mind and I don't see a hard reason to change this.

For (i) you then come up with the idea of a "dedicated address". 127/8 was proposed by Gregory and again, that would work although ... how do you differentiate this from a BFD-LSP (RFFC5884) packet arriving on the LAG interface?  So a Multicast address seems another option.

> Resulting behavior will be less deviating from RFC5881: same
> demux procedures can be used when discriminator is zero(0),

so can it for the link-local multihop address I think - no? Now we do mention this in section 3.2, as a reminder that for your_Discr zero the main difference is the ingress interface:

   The demultiplexing of a received packet is solely based on the Your
   Discriminator field, if this field is nonzero.  For the initial Down
   packet of a micro session this value may be zero.  In this case
   demultiplexing MUST be based on some combination of other fields
   which MUST include the interface information of the member link.

> no need to
> come up with special case of TTL=1 which was discussed.

oh-oh I missed this part! Have to go through the emails. TTL = 1 ?!?  Our draft is not talking about this (section 3 mentions RFC5880, so you would have a TTL of 255)

> I'm questioning

actually I wonder if all-router or all-hosts wouldn't do the job. We could probably even use 255.255.255.255 as the setup is a direct link, back to back. Open to this. But if it turns out we need one, well then we need one. Or alternatively - see (ii) above - a new IANA UDP port. Not sure what is better/worse.

Regards, Marc

---

From: Glen Kent <[email-masked]>
Date: Tue, 20 Dec 2011 06:24:47 +0530

Some more reasons for going in for multicast given at the end of the
new version.

http://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1

I dont think there is a need to specify that the TTL=1 since the
multicast addresses have a link local scope. Am i missing something?

Thanks,
Glen

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 19 Dec 2011 18:29:59 -0800

Hello Marc, Glen,

Thanx for prompt response.

> multicast addresses have a link local scope. Am i missing something?

Somewhere in the thread, "TTL for all IPv4 multicast packets MUST be 1" was mentioned by Manav.

Nice appendix in the new revision. Some comments.

(1) Unicast ARP disadvantage becomes moot if you add third option of using well-known multicast/broadcast MAC.
(2) Unicast configuration difficulty is valid in a sense that one would need to configure destination IP address.
(3) Unnumbered IP address, I'm a bit slow on this one. Can you elaborate a bit more on this issue?

> > so can it for the link-local multihop address I think - no? Now we do
> mention this in section 3.2, as a reminder that for your_Discr zero the
> main difference is the ingress interface:

For regular RFC5881 sessions, incoming packets with zero(0) discriminator is usually demux'ed mainly based on incoming interface and source IP address. I was pointing out that implementation will most likely need to stem off to slightly deviating demux code, if destination IP of received packets is a multicast address.

   o  Minimal code changes to support micro BFD sessions per member
      link.  A new UDP port number can be used to differentiate BFD
      control packets associated with the micro BFD sessions and the
      regular BFD sessions.

Running regular BFD sessions on top of bundle which has micro BFD sessions per member enabled make sense if they are of deviating AF or if regular sessions are on subinterface. But running on same AF on main bundle ... yeah it actually make sense. Primary strength here is that regular session is able run echo, which micro BFD sessions per member isn't able to do, allowing much better coverage. You are right, if we went to unicast destination IP address, UDP port is only thing we have to differentiate the sessions, which usage of multicast destination IP would appear simpler. Second sentence of above snippet is really more of advantage of multicast destination IP approach, IMO.

Also related, should the draft make suggestion of running per member only on bundle main interface, or allowing same mechanism to be used even on bundle subinterface?

Thanx,
Nobo

> From: Glen Kent [mailto:[email-masked]]
> Sent: Tuesday, December 20, 2011 9:55 AM
> To: Marc Binderberger
> Cc: Nobo Akiya (nobo); [email-masked]; Dave Katz
> > I have seen there had been some "unnumbered" discussion but actually
> that is not the reason. Actually "unnumbered" was put aside when we
> discussed the original draft-chen-bfd-interface and the list feedback
> was to focus on LAG with IP at that time.
> >
> >
> > What we want to achieve:
> >
> > For (i) you then come up with the idea of a "dedicated address". 127/8
> was proposed by Gregory and again, that would work although ... how do
> you differentiate this from a BFD-LSP (RFFC5884) packet arriving on the
> LAG interface?  So a Multicast address seems another option.
> >
> >
> > so can it for the link-local multihop address I think - no? Now we do
> mention this in section 3.2, as a reminder that for your_Discr zero the
> main difference is the ingress interface:
> >
> > oh-oh I missed this part! Have to go through the emails. TTL = 1 ?!?  Our
> draft is not talking about this (section 3 mentions RFC5880, so you would
> have a TTL of 255)
> >
> >
> >> I'm questioning
> > actually I wonder if all-router or all-hosts wouldn't do the job. We
> could probably even use 255.255.255.255 as the setup is a direct link,
> back to back. Open to this. But if it turns out we need one, well then
> we need one. Or alternatively - see (ii) above - a new IANA UDP port.
> Not sure what is better/worse.
> >
> >
> > Regards, Marc
> >
> >
> >
> >
> >>
> >> Thanx,
> >> Nobo
> >>
> >>> thanks for the comments. Let me check this with the new version we
> are
> >>> just preparing (almost done).
> >>>
> >>> And yes, a cleaner description when the creation/deletion is part
> of
> >> it.
> >>> Let me go through our latest (internal) version if that addresses
> your
> >>> points.
> >>>
> >>>
> >>> Thanks!
> >>>
> >>> REgards, Marc
> >>>
> >>>
> >>>
> >>>
> >>>> interface state will be down). LAG will come up potentially when
> BFD
> >>> on
> >>>> interface state) even if those applications do not configure BFD
> on
> >>> LAG.

---

From: Glen Kent <[email-masked]>
Date: Tue, 20 Dec 2011 08:52:39 +0530

Hi Nobo,

> Also related, should the draft make suggestion of running per member
> only on bundle main interface, or allowing same mechanism to be used even on bundle subinterface?

subinterfaces afaik is a Cisco specific implement. Are you talking
about IP interfaces with different vlans on the same phy port?

Thanks,
Glen

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 19 Dec 2011 21:30:16 -0800

Hello Glen,

> Sent: Tuesday, December 20, 2011 12:23 PM
> To: Nobo Akiya (nobo)
> Cc: Marc Binderberger; [email-masked]; Dave Katz

Sorry for not using right terminology there. I meant 801.1q on an ether bundle (ex: bundle-ether1.1).

Thanx,
Nobo

> >> > - you can have additionally a BBP session (the single session over
> LAG)
> >> for the main LAG interface
> >> >
> >> >> this aspect since I didn't see any strong arguments for burning
> up
> >> IP
> >> >> multicast address.
> >> >
> >> >>>> interoperability purpose. I can understand the need, but side
> effect
> >> >>> can
> >> >>>> above statement, BFD session could remain even when operator
> decides
> >> >>> to
> >> >>>> LACP is used, LMM will startup LACP only when interface is up.
> L2
> >> >> check
> >> >>>> upwards. Going by same idea, BFD session should only be created
> when
> >> >>> L2
> >> >>>> check passes (LACP), when L2 check is being used. If L2 check
> is
> >> not
> >> >>>> Absence in L1/L2 check pass should cause corresponding BFD
> sessions
> >> >>> to
> >> >>>> get deleted.
> >> >>>>
> >> >>>>
> >> >>>>>> Do these notes capture the problem space correctly? Or did I
> miss
> >> >>>>> something important?
> >> >>>>>>
> >> >>>>> mentions that waiting for BFD's Up notification may be useful.
> Thus
> >> >>> we
> >> >>>> interoperability purpose. I can understand the need, but side
> effect
> >> >>> can

---

From: Tom Sanders <[email-masked]>
Date: Wed, 21 Dec 2011 07:32:42 +0530

> Sorry for not using right terminology there. I meant 801.1q on an ether bundle (ex: bundle-ether1.1).

The authors can correct me if i am greatly off the mark, but as per my
understanding, we may not need to run micro BFD sessions per dot1q LAG
interfaces. Look at each micro BFD session as an entity that interacts
with LACP (which runs at a port level) and helps it to monitor & the
maintain the LAG.

Toms.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 20 Dec 2011 18:17:14 -0800

Hello Tom,

> with LACP (which runs at a port level) and helps it to monitor & the

Agree. Theoretically, it should be possible for BFD to run micro BFD sessions per 802.1q, not that we want to from scale perspective. However, it would be difficult for LMM to react to failures at such granularity. Same applies to running micro BFD sessions for both v4 and v6 at main 802.1ax. AF aspect is mentioned in the draft in sec 3.1.

   Per BLM session request only one address family can be used.  I.e.
   the set of micro sessions belonging to the BLM session MUST either
   all use IPv4 or all use IPv6.

But since 802.1q aspect wasn't specifically mentioned (a bit implied in section 4), I was simply curious.

Thanx,
Nobo

---

From: Mach Chen <[email-masked]>
Date: Wed, 21 Dec 2011 02:29:34 +0000

Hi Nobo and Tom,

Thanks for your comments.

You are right, the draft is intended to run macro BFD session per port. We could update the draft to explicitly mention this to make it clearer in the revision.

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nobo Akiya (nobo)
> Sent: Wednesday, December 21, 2011 10:17 AM
> To: Tom Sanders
> Cc: [email-masked]; Dave Katz
> Agree. Theoretically, it should be possible for BFD to run micro BFD sessions
> per 802.1q, not that we want to from scale perspective. However, it would be
> difficult for LMM to react to failures at such granularity. Same applies to
> running micro BFD sessions for both v4 and v6 at main 802.1ax. AF aspect is
> mentioned in the draft in sec 3.1.
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 Dec 2011 09:48:09 +0530

Hi Nobo,
 
> Agree. Theoretically, it should be possible for BFD to run 
> micro BFD sessions per 802.1q, not that we want to from scale 
> perspective. However, it would be difficult for LMM to react 
> to failures at such granularity. Same applies to running 

Yes that's correct. Moreover, we don't NEED to run separate micro sessions per .1q interface. Running it per port should be fine. If the micro session goes down then LMM takes care of removing this port from all LAGs that it's a part of.

> micro BFD sessions for both v4 and v6 at main 802.1ax. AF 
> aspect is mentioned in the draft in sec 3.1.
> 
> But since 802.1q aspect wasn't specifically mentioned (a bit 
> implied in section 4), I was simply curious.

Yup, we should include a note on this.

Cheers, Manav

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 21 Dec 2011 12:21:47 +0100

Hello Nobo and Tom,

most answers have been given already - and yes, we should be explicit that we want to send micro sessions untagged, i.e. without a VLAN.

> Same applies to running micro BFD sessions for both v4 and v6 at main 802.1ax. AF aspect is mentioned in the draft in sec 3.1.
> 

right, but there is still a detail missing as we don't forbid to request an IPv4 BLM and also an IPv6 BLM for the same LAG. As we work on section 5 to be more detailed on the 802.1AX part I think we need to mention which logic to be used: OR-logic, i.e. any BFD Down trigger removes the link from distributed state?

What also needs an update is section 4: here we use the concluded state of the corresponding BLM session. Bu which one, that of BLM-IPv4 or BLM-IPv6? :-)  We may need to reword this a bit, ala "using the concluded state of the BLM session for the same LAG and with the same AF" or such.

And of course this discussion depends on the detail if we go with BFD in IP/UDP encapsulation; only then Address Family makes sense.

Dave, I haven't seen a reply regarding my questions. Still have the problem that "unnatural" and "tap into private API" is a bit vague to be addressed. Or in other words: where starts "natural" and what API model are we allowed to use?

Regards, Marc