Subject: RE: BFD on LAG interfaces

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

Hi Sasha,

[clipped]
Here is my understanding of the problem we try to solve:

[clipped]

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

[Manav] I think this pretty much covers everything

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.

[Manav]  IMO, the member link should come UP as soon as the micro BFD session gets established. When the entire LAG is shutdown, it will naturally take some more time before it gets ready to take up all traffic as the routing protocols will take some time before they reconverge (just like how it happens today).

When it comes to the solution space, there seem to be several candidates:
  [clipped]

 3.       BFD in some special encapsulation:

[clipped]

[Manav] Agree to all the above points.

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.

[Manav] I dont understand this part. We bring down the member link when the micro BFD session goes down. When do we bring that up? Will it not take LACP long (at least 1 secs) to bring the link up?

 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.

[Manav] I think you meant that the micro BFD session would wait for the member link to come up before it gets restarted. Why should it wait for the entire LAG to come up again? In fact in some cases the LAG will not even go DOWN when a micro BFD session goes down.

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

[Manav] If we ensure that the member link is UP before initiating the BFD session then Yes we dont need to use a multicast address and a different UDP port can be used to disambiguate the BFD packets. This will however not work for unnumbered IP interfaces. Using a multicast address will work for both numbered and unnumbered IP interfaces.

                                                            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

[Manav] Good point.

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.

[Manav] We had ignored this option since we ha dno idea how easy/feasible it is to coordinate with IEEE, as one would surely need to do if we chose to go down this route.

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 16 Dec 2011 09:08:15 +0200

Hi Manav,
Lots of thanks for a prompt and detailed response.

Before I go into specifics, I have a couple of terminological comments:

 1.  I've assumed that what you call LMM in the draft is called "Aggregator" in the IEEE 802 parlance. Is this correct? (Aside: IMHO it is important to map the problem and solution to IEEE 802 notions and terms, especially if any form of coordination/synchronization with this body is expected/required).
 2.  I assume that your "micro-BFD session" is what I have called "a BFD session bound to a specific constituent link of the LAG". I will use your term since it is much shorter.

Now is the time for specific responses to your comments.

 1.  You've said that the member link should come UP as soon as the micro BFD session gets established and, based on this, you reject LACP (if used) as the mechanism for bringing the member link UP - Will it not take LACP long (at least 1 secs) to bring the link up? I see two issues with this logic:
    *   Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD control packet per second (as explained in RFC 5880, Section 6.8.3). Hence I would expect that bringing UP a failed member link via the 5880-compliant micro-BFD session would take approximately as long as it would with LACP using a 1' timer. Or do you worry about LACP with 30' timers?
    *   If LACP is used on a LAG member that has been brought DOWN by a micro-BFD session, it has to be involved i bringing the link UP anyway: it must declare the local link state as "Collecting" and then go thru some stages until the link is recognized as "Collecting" and "Distributing" by both peers. This would also take some time (probably a few hundreds of milliseconds) because LACP is a slow protocol. Attempts to bypass the LACP procedures for bringing the link UP could easily run into serious interoperability problems - unless you are ready to say that LAG with LACP and LAG with per-link BFD are mutually exclusive.
 2.  Which entity should activate the micro-BFD session, and when? I've probably not expressed my position clearly enough, hence your comment  I think you meant that the micro BFD session would wait for the member link to come up before it gets restarted. Why should it wait for the entire LAG to come up again? In fact in some cases the LAG will not even go DOWN when a micro BFD session goes down. What I've really meant is the following:
    *   If micro-BFD sessions use IP-based encapsulations, LAG (which is the interface that IP sees) MUST be UP before they can be activated. As I've noted, if LAG is down it could safely drop any IP packets it receives. You seem to have accepted this point.
    *   If LACP is used on LAG members and micro-BFD sessions do not use IP-based encapsulation, they can be activated once LACP brings the link UP.
    *   BFD sessions that do not use IP encapsulation can be used even if LACP is not used on LAG members. In this case they will interact directly with the Aggregator rather than with LACP.
 3.  You've claimed that an IP-based encapsulation for micro-BFD that uses unicast IP destination address and a dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP interfaces. I think that this is incorrect because RFC 5881 works for unnumbered P2P IP interfaces as fine as for numbered ones. The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is relevant to P2P links says that "the source address of a BFD Control packet MUST NOT be used to identify the session".
 4.  Last but not least, I do not think that my proposals require complicated coordination with IEEE 802.1AX. LAG-related state machines are well defined, all you need is feeding existing some inputs into them from micro-BFD rather than from the physical layer, and activating micro-BFD sessions from them (which is a minor change IMO). However, to this extent coordination with IEEE 802.1AX  seems unavoidable unless you explicitly declare that LAG with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the consequences of such a decision.

My 2c,

     Sasha

________________________________
From: Bhatia, Manav (Manav) [[email-masked]]
Sent: Thursday, December 15, 2011 9:25 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: BFD on LAG interfaces

Hi Sasha,

[clipped]

[clipped]

[clipped]

 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.

[Manav] Good point.

Cheers, Manav

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: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 16 Dec 2011 13:59:00 +0530

Hi Sasha,

Thanks for your comments.

My response's inline.

[Manav] Yes, to both. I like the term "micro-BFD session" since it easily helps in distinguishing between the two different BFD flavors.

 You've said that the member link should come UP as soon as the micro BFD session gets established and, based on this, you reject LACP (if used) as the mechanism for bringing the member link UP - Will it not take LACP long (at least 1 secs) to bring the link up? I see two issues with this logic:

    *   Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD control packet per second (as explained in RFC 5880, Section 6.8.3). Hence I would expect that bringing UP a failed member link via the 5880-compliant micro-BFD session would take approximately as long as it would with LACP using a 1' timer. Or do you worry about LACP with 30' timers?
    *
 1.  [Manav] If LACP uses its default periodic timer of 30 secs, then that screws up BFD. This means that BFD on LAG will only work if the administrator manually changes the default LACP timer from 30s to 1sec. I am not very comfortable with a solution that hinges on all administrators manually configuring something correctly for it to work - to me this is a very tenuous design.

          [Manav] This also necessitates running LACP along with BFD. I am ok if LACP can run with BFD. I am not sure if i am ok with mandating LACP to run with BFD. But then this is a personal choice ..

 1.
    *

Which entity should activate the micro-BFD session, and when? I've probably not expressed my position clearly enough, hence your comment  I think you meant that the micro BFD session would wait for the member link to come up before it gets restarted. Why should it wait for the entire LAG to come up again? In fact in some cases the LAG will not even go DOWN when a micro BFD session goes down. What I've really meant is the following:

 1.

[Manav] LAG can only be UP, if there is atleast one component link that is alive. Yes what you have described is a deadlock. But this is more so with Unicast encapsulation. With multicast, we could say that just as a port that is down processes certain L2 control frames, it should also process frames coming with a well known IANA allocated multicast MAC (which would be used by all micro-BFD sessions). If we were to go with a unicast IP encapsulation, then we will have to let the port that is down accept (i) all broadcast frames (ARP requests) (ii) all packets coming with your own MAC (ARP replies) (iii) all IP packets addressed to you.

         Clearly, this is an order of magnitude worse than what happens if we go with multicast IP encapsulation.

 1.

[Manav] Yes. I think i had mentioned even earlier that BFD without IP based encapsulation is perhaps the best. But that requires a well known MAC from IEEE and a new Ether type. I am not sure how easy or complex this is.

    *   BFD sessions that do not use IP encapsulation can be used even if LACP is not used on LAG members. In this case they will interact directly with the Aggregator rather than with LACP.
 2.
 3.  [Manav] I am not sure i understand why having an IP encapsulation precludes an implementation to directly interact with the Aggregator. In fact, all control packets from the micro BFD session will ONLY interact with the Aggregator, and never with LACP.
 4.
 5.  You've claimed that an IP-based encapsulation for micro-BFD that uses unicast IP destination address and a dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP interfaces. I think that this is incorrect because RFC 5881 works for unnumbered P2P IP interfaces as fine as for numbered ones. The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is relevant to P2P links says that "the source address of a BFD Control packet MUST NOT be used to identify the session".

[Manav] I am more concerned about the destination IP address than the source IP. What dest IP to you use? Even if you do manage to use a 127/8, what dest MAC do you use? Do you use a well known L2 MAC address for IP unicast based encaps. If Yes, then you need to get this from IEEE.

Note that with multicast you dont need any L2 address allocation.

 1.  Last but not least, I do not think that my proposals require complicated coordination with IEEE 802.1AX. LAG-related state machines are well defined, all you need is feeding existing some inputs into them from micro-BFD rather than from the physical layer, and activating micro-BFD sessions from them (which is a minor change IMO). However, to this extent coordination with IEEE 802.1AX  seems unavoidable unless you explicitly declare that LAG with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the consequences of such a decision.

[Manav] I am not worried about feeding state from the micro BFD sessions to the LAG module - thats an implementation specific issue. What i am concerned about is getting their approval for a new ether type, L2 mac addr and new encap that we want.

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 16 Dec 2011 13:12:39 +0200

Manav,
Lots of thanks for a prompt response.

Please see some comments inline  in green italics below (with snipped parts when we seem to be aligned).

Regards,
     Sasha

________________________________
From: Bhatia, Manav (Manav) [[email-masked]]
Sent: Friday, December 16, 2011 10:29 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: BFD on LAG interfaces

Hi Sasha,

My response's inline.

... snipped...

[[Sasha]] I see your point, but I do not think it is a very serious issue. Misconfiguration can kill lots of protocols, and BFD is not really an exception.

          [Manav] This also necessitates running LACP along with BFD. I am ok if LACP can run with BFD. I am not sure if i am ok with mandating LACP to run with BFD. But then this is a personal choice ..
[[Sasha]] LACP is only required if you insist on running BFD in an IP encapsulation.

 1.

 1.

[[Sasha]] IMHO what you really say is "Let's treat BFD as one more L2 control protocol".. The problem (as I see it) is that there is a clear definition of what consitutes L2 control protocols (given by IEEE 802 and accepted by, say, MEF when it discusses tunneling of these protocols). A multicast IP packet would not be ever recognized as such.

[[Sasha]] Sorry, but I do not see any difference - for the reasons stated above.

 1.

[[Sasha]] Neither do I, but it is worth trying IMHO. BTW, IETF already has a block of MAC addresses allocated to it by IEEE 802 with IANA distributing addresses within this block. So you probably need only a new Ethertype, and these are usually reasonably easy to obtain. E.g., MEF has easily got one for its CESoETH (MEF 8) protocol several years ago.

 1.  [Manav] I am not sure i understand why having an IP encapsulation precludes an implementation to directly interact with the Aggregator. In fact, all control packets from the micro BFD session will ONLY interact with the Aggregator, and never with LACP.

[[Sasha]] I suspect that this would create lots of conflicts because Aggregator's understanding of the link status would be fed by two conflicting sources: LACP session and micro-BFD session.

 1.        You've claimed that an IP-based encapsulation for micro-BFD that uses unicast IP destination address and a dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP interfaces. I think that this is incorrect because RFC 5881 works for unnumbered P2P IP interfaces as fine as for numbered ones. The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is relevant to P2P links says that "the source address of a BFD Control packet MUST NOT be used to identify the session".

[[Sasha]] What destination IP address do you use in RFC 5881? As for MAC, LAG is assigned with its own MAC address (which may but does not have to match MAC address of one of its member links), and, in the case of IP over LAG, is learned via ARP.

[[Sasha]] I'd say you the only way to find out would be to try?

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 16 Dec 2011 17:10:53 +0530

Hi Sasha,
 	 
> [Manav] I am more concerned about the destination IP 
> address than the source IP. What dest IP to you use? Even if you do 
> manage to use a 127/8, what dest MAC do you use? Do you use a well 
> known L2 MAC address for IP unicast based encaps. If Yes, then you need 
> to get this from IEEE.
>		 
> [[Sasha]] What destination IP address do you use in RFC 5881? As for
>  MAC, LAG is assigned with its own MAC address (which may but does 
> not have to match MAC address of one of its member links), and,
> in the case of IP over LAG, is learned via ARP.

I don't think you do dynamic ARP over unnumbered interfaces.

> [Manav] I am not worried about feeding state from the micro BFD sessions 
> to the LAG module - thats an implementation specific issue. What i am 
> concerned about is getting their approval for a new ether type, L2 mac 
> addr and new encap that we want.  
>		 
		 
Sure, that can be done. I will include some text on direct encapsulation over L2 (without IP/UDP headers) in the next version.

Right now we have three encapsulation options for the micro-BFD sessions.

1. Using multicast dest IP
2. Using Unicast IP
3. Direct encapsulation of the BFD packet without IP/UDP headers

I think its clear that there is value in implementing (3) as long as we can get IEEE to part with some of its treasure. What about (1) and (2)? I will raise a separate thread to discuss the preferred IP encapsulation scheme.

Regarding (1), I am sure someone on the list can illuminate us on what it entails to get a well known MAC and an Ether Type from IEEE for our purpose. This was done for TRILL recently and I can ping the TRILL folks on this, unless someone on this list already has this information, and is kind enough to share it with us.

Cheers, Manav

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 16 Dec 2011 11:45:11 -0500

Dear Sasha, Manav, et al.,
I agree with Sasha that non-IP encapsulation of BFD over Ethernet is attainable and will refer to draft-fbb-mpls-tp-ethernet-addressing-00 that requests allocation multicast MAC by IANA:
"IANA is requested to allocate an Ethernet Multicast Address from the Ethernet Multicast Addresses table in the ethernet-numbers registry for use by MPLS-TP LSRs over point-to-point links as described in Section 2<http://tools.ietf.org/html/draft-fbb-mpls-tp-ethernet-addressing-00#section-2>."

Regards,
Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Friday, December 16, 2011 3:13 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: RE: BFD on LAG interfaces

Manav,

Regards,
     Sasha

Hi Sasha,

My response's inline.

... snipped...

 1.

 1.

 1.

Cheers, Manav

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 17 Dec 2011 11:28:01 +0100

Hello Alexander,

now I found the time to read this as well ... few questions to you:

- it seems that defining the "bringing down" of a LAG member link via BFD micro session is mainly a matter of referring to the particular state(-changes) in aggregation control of 802.1AX ?  So no changes required within 802.1AX definition itself, in your opinion?

- the "bringing up" though does require changes in 802.1AX, if we want to make it dependent on BFD?  I wonder already about basics like "do I bring up LACP first and then BFD? Or vice versa? Or both in parallel?". 

Btw, the customers I know largely do use both, LACP and the BFD on LAG member links. LACP does the right job to organize a bundle in general - it's just a bit slow. Which also means when LACP is configured one probably wants both protocols signalling their "go" before a link it brought into forwarding (_if_ you want to make it depending on BFD, I mean).

Alexander, you mentioned:

The problem (as I see it) is that there is a clear definition of what consitutes L2 control protocols (given by IEEE 802 and accepted by, say, MEF when it discusses tunneling of these protocols). A multicast IP packet would not be ever recognized as such. 

- do you have a pointer to the definition?

- you see this as a problem for the case when BFD is used to "bring up", correct? Once the LAG is up then using e.g. IPv4 or IPv6 related multicast MAC is fine in your opinion?

About approvals from 802.1AX and a draft that requires such approvals my opinion is it's the wrong direction. Faster LACP implementation(s) exist - proprietary, I assume - and if this hasn't been managed to be standardized yet then I don't see why BFD should have any better chance.

As much as I like the insight I gained from this discussion between Alexander and Manav, I wonder how much of this can be standardized in an IETF draft. Maybe we should define the core mechanics of BFD on Lag member links (BLM for short) and make the result of this 802.1AX centric discussion a section of how BLM could be used with LAG, marked as informal?

Regards, Marc

On 2011-12-16, at 12:12 , Alexander Vainshtein wrote:

> Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD control packet per second (as explained in RFC 5880, Section 6.8.3). Hence I would expect that bringing UP a failed member link via the 5880-compliant micro-BFD session would take approximately as long as it would with LACP using a 1' timer. Or do you worry about LACP with 30' timers?  
> [Manav] If LACP uses its default periodic timer of 30 secs, then that screws up BFD. This means that BFD on LAG will only work if the administrator manually changes the default LACP timer from 30s to 1sec. I am not very comfortable with a solution that hinges on all administrators manually configuring something correctly for it to work - to me this is a very tenuous design.
> If LACP is used on a LAG member that has been brought DOWN by a micro-BFD session, it has to be involved i bringing the link UP anyway: it must declare the local link state as "Collecting" and then go thru some stages until the link is recognized as "Collecting" and "Distributing" by both peers. This would also take some time (probably a few hundreds of milliseconds) because LACP is a slow protocol. Attempts to bypass the LACP procedures for bringing the link UP could easily run into serious interoperability problems - unless you are ready to say that LAG with LACP and LAG with per-link BFD are mutually exclusive. 
> If micro-BFD sessions use IP-based encapsulations, LAG (which is the interface that IP sees) MUST be UP before they can be activated. As I've noted, if LAG is down it could safely drop any IP packets it receives. You seem to have accepted this point.  
>  
> If LACP is used on LAG members and micro-BFD sessions do not use IP-based encapsulation, they can be activated once LACP brings the link UP.  
>  
> BFD sessions that do not use IP encapsulation can be used even if LACP is not used on LAG members. In this case they will interact directly with the Aggregator rather than with LACP. 
> [Manav] I am not sure i understand why having an IP encapsulation precludes an implementation to directly interact with the Aggregator. In fact, all control packets from the micro BFD session will ONLY interact with the Aggregator, and never with LACP.
>  
>       You've claimed that an IP-based encapsulation for micro-BFD that uses unicast IP destination address and a dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP interfaces. I think that this is incorrect because RFC 5881 works for unnumbered P2P IP interfaces as fine as for numbered ones. The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is relevant to P2P links says that "the source address of a BFD Control packet MUST NOT be used to identify the session".  
>  
> Last but not least, I do not think that my proposals require complicated coordination with IEEE 802.1AX. LAG-related state machines are well defined, all you need is feeding existing some inputs into them from micro-BFD rather than from the physical layer, and activating micro-BFD sessions from them (which is a minor change IMO). However, to this extent coordination with IEEE 802.1AX  seems unavoidable unless you explicitly declare that LAG with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the consequences of such a decision.  
>  

--
Marc Binderberger           <[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 17 Dec 2011 19:15:57 +0200

Dear Greg,
To clarify one point:

The text you've quoted refers to IANA (and not to the IEEE MAC addresses' registry) because IETF "owns" a pre-allocated block of MAC addresses, and specific allocations from this block are made by IANA.

Whether we need a dedicated Ethertype for BFD over Ethernet for micro-BFD sessions is a separate issue.

My 2c,
     Sasha

________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Friday, December 16, 2011 6:45 PM
To: Alexander Vainshtein; Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: RE: BFD on LAG interfaces

Regards,
Greg

Manav,

Regards,
     Sasha

Hi Sasha,

My response's inline.

... snipped...

 1.

 1.

 1.

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 17 Dec 2011 21:22:50 +0200

Resending as plain text and clipping most of the "long tail"  to fit the 40K limit...

Regards,
     Sasha

From: Alexander Vainshtein 
Sent: Saturday, December 17, 2011 9:15 PM
To: 'Marc Binderberger'
Cc: [email-masked]; Bhatia, Manav (Manav); Mach Chen
Subject: RE: BFD on LAG interfaces

Dear Marc,
Lots of thanks for  prompt and detailed responses.

Regarding the pointer to what constitutes a Layer 2 control Protocol:  MEF10.2, Section 6.5.1.4 states that frames with Destination MAC addresses listed in a below are L2CP frames:
 	01-80-C2-00-00-00 thru 01-80-C2-00-00-0F - bridge block of protocols
	01-80-C2-00-00-20 thru 01-80-C2-00-00-2F - GARP block of protocols
	01080-C2-00-00-10                                              - all Bridges protocol

This definitely does not include destination MAC addresses from the IETF block.

Regarding the interaction between LACP and micro-BFD session on a given member link of LAG:
I think that this should follow the scheme in Section 4.1 of RFC 5882 if we treat LACP as the control protocol that uses a micro-BFD session to bring its adjacency down. LACP definitely does not provide for signaling that both peers are willing to establish a BFD session, hence it can safely bring its adjacency UP and notify the Aggregator. This approach IMHO provides an unambiguous and non-controversial answer to all specific questions with the indications provided by the micro-BFD session just augmenting those provided by the physical layer of the corresponding member link. 

Hopefully these notes clarify my position on the subject,

My 2c,
     Sasha

Regards,
     Sasha

From: Marc Binderberger [mailto:[email-masked]] 
Sent: Saturday, December 17, 2011 12:28 PM
To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen
Cc: [email-masked]
Subject: Re: BFD on LAG interfaces

Hello Alexander,

Btw, the customers I know largely do use both, LACP and the BFD on LAG member links. LACP does the right job to organize a bundle in general - it's just a bit slow. Which also means when LACP is configured one probably wants both protocols signaling their "go" before a link it brought into forwarding (_if_ you want to make it depending on BFD, I mean).

The problem (as I see it) is that there is a clear definition of what constitutes L2 control protocols (given by IEEE 802 and accepted by, say, MEF when it discusses tunneling of these protocols). A multicast IP packet would not be ever recognized as such. 

Regards, Marc

... snipped...

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 18 Dec 2011 07:54:06 +0200

Manav hi,
I apologize for a delayed response to your message.

Please see some comments inline below.

Regards,
     Sasha

________________________________________
From: Bhatia, Manav (Manav) [[email-masked]]
Sent: Friday, December 16, 2011 1:40 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: BFD on LAG interfaces

> I don't think you do dynamic ARP over unnumbered interfaces.

[[Sasha]] Why not? And in any case, unicast IP was supposed to run over the LAG in question. 
So the destination MAC address (that of LAG itself) would be known in some way. 
(If IP was not supposed to run over LAG in question, we could use the mechanism defined in
draft-fbb-mpls-tp-ethernet-addressing-00). Do I miss something?

>> to the LAG module - that's an implementation specific issue. What i am

> I think its clear that there is value in implementing (3) as long as we can get IEEE to part with some of its 
> treasure. What about (1) and (2)? I will raise a separate thread to discuss the preferred IP 
> encapsulation scheme.

[[Sasha]]. Raising a separate thread  dealing with possible encapsulation(s) of micro-BFD sessions looks
right to me. Currently there are at least two groups of issues we're discussing: architecture (relationships 
between Aggregator, LACP and micro-BFD) and encapsulation. IP-based encapsulation adds its own
architectural issue but IMHO it cannot be considered unless the larger issues have been nailed down.

> Regarding (1), I am sure someone on the list can illuminate us on what it entails to get a well known MAC
> and an Ether Type from IEEE for our purpose. This was done for TRILL recently and I can ping the TRILL
>  folks on this, unless someone on this list already has this information, and is kind enough to share it with us.

[[Sasha]] I am repeating what Greg and I have already mentioned in this thread:  a new MAC address should 
be  assigned by IANA from the block it holds from IEEE 802. A new Ethertype is probably the preferred method, but it could be bypassed. One option (admittedly a hack!) could be to run micro-BFD sessions in G-ACH encapsulations defined for MPLS-TP.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 18 Dec 2011 10:30:10 -0500

Hi,

On Fri, Dec 16, 2011 at 6:40 AM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
>...

On getting a MAC address, I would recommend going through IANA as per
RFC 5342. While it was not that hard to get a standards use multicast
MAC address from the IEEE Registration Authority, it took a while.
However, if you are using  multicast destination IP, I'm not sure why
you wouldn't just use the derived multicast MAC.

In any case, for an Ethertype you pretty much just do an regular
application but explain that it is for standards use and they zero out
the amount due. See
http://standards.ieee.org/develop/regauth/ethertype/

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 18 Dec 2011 21:12:35 +0530

Hi Donald,
 
> On getting a MAC address, I would recommend going through 
> IANA as per RFC 5342. While it was not that hard to get a 
> standards use multicast MAC address from the IEEE 
> Registration Authority, it took a while.
> However, if you are using  multicast destination IP, I'm not 
> sure why you wouldn't just use the derived multicast MAC.

We're looking at an L2 MAC if we need to directly encapsulate the BFD packet (without IP/UDP headers) over the L2 header.

> 
> In any case, for an Ethertype you pretty much just do an 
> regular application but explain that it is for standards use 
> and they zero out the amount due. See 

Thanks!

Cheers, Manav