RE: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8

[Marc Binderberger <[e-mail]>]

Hello Mahesh and Manav,


I share some non-understanding with Manav. The part ...

> The fundamental issue is that the proposal requires BFD protocol to rely on 
> information that is not carried in the frame itself

... didn't make much sense to me either. Can you explain? I can guess 
that this first point is the same as the second point: how to get the 
interface information?

We also do not make the assumption that the internal IP API is carrying 
interface information. Actually at least one vendor has exactly the 
situation of clearly separated L2 and L3 APIs on one of it's platforms 
and can implement the draft nevertheless.  In other words what you see 
as a problem isn't one.
(implementation hint: binding of MAC API per interface)


Regards, Marc



On Wed, 30 Oct 2013 04:10:51 +0000, Bhatia, Manav (Manav) wrote:
> Mahesh,
> 
>> The fundamental issue is that the proposal requires BFD protocol to 
>> rely on 
>> information that is not carried in the frame itself. Unless by 
>> interface check 
> 
> That's what happens with most protocols. How do you identify the 
> ingress IP interface for an IP packet that came from a router 
> multiple hops away. You will have to go beyond the IP payload to 
> associate this packet to an ingress interface.
> 
>> you mean check against IP address. I do not know of many protocols 
>> that require 
>> one to validate/use information that is not part of the frame 
>> itself. Protocols that
> 
> I don't understand why you say this. The uBFD packet carries the dest 
> IP that's bound to you. You use this information (i.e. the 
> information carried in the frame) + some hints from the data plane to 
> determine whether you need to act on it or not.
> 
>> have stood the test of time, like TCP, do not look beyond their own 
>> layers in the frame 
>> for validation of a frame. Even if we have breached the OSI layer, 
>> at least we have 
>> restricted ourselves to looking at what is in the frame.
> 
> This happens all the time. Multicast often takes hints from the data 
> plane before triggering events in the control plane (pruning the RPT, 
> sending Register Stop messages, sending ASSERTs, etc).
> 
>> The second issue as I highlighted is that there is an assumption 
>> that systems carry interface 
>> information up to the protocol itself for it to validate/use the 
>> information. Again, I assume you mean 
>> the check will be against the physical interface and not the IP 
>> address. That as I mentioned is a 
>> huge assumption. There is no precedence for this.
> 
> Isnt this an implementation specific issue? You can, as you suggest 
> later in your email, use the dest MAC.
> 
>> There are couple of ways to solve the problem.
>> 
>> One way would be to use the IP address on the individual member link 
>> to map a packet 
>> to a BFD session running on a member link. When the initial BFD 
>> frame is received with 
>> your discriminator as zero, you would use the destination IP address 
>> contained in the 
>> packet to figure out which link the packet was received on. The same 
>> would be true of 
>> validation of frame. This will not work for unnumbered interfaces.
>> 
>> The other would be use the individual link MAC address as a way to 
>> co-relate a BFD packet to 
>> a particular link both to set up a BFD session (when the 
>> discriminator is zero) and for future validation 
> 
> This is precisely what I had meant by this being an implementation 
> specific issue. Your implementation can always look at the dest MAC 
> to figure out the link that the packet arrived on. It doesn't make 
> sense to explicitly state this in the draft since this is an 
> implementation specific issue. There are several devices that may use 
> a chassis MAC address and MAY not allocate a unique MAC per link.
> 
>> of the frame (to a particular link). This would mean that we cannot 
>> use the multicast address to send the BFD frame.
>> 
>> How the IP/MAC address is collected and setup is beyond the scope of 
>> this document.
> 
> Cheers, Manav
> 
> On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) 
> <[e-mail]> wrote:
> Hi Mahesh,
> 
> This draft only talks about BFD sessions between directly connected boxes.
> 
>> For initial DOWN BFD packet, where the Your Discriminator field is 0,
>> the draft suggests that demultiplexing MUST be based on some
>> combination of other fields which MUST include the interface
>> information of the member link. That assumes that systems are aware of
>> what interface the BFD packet came on. That is not always the case, and
>> in a global label/IP space, systems do not have to know the physical
> Can you explain the scenario where you think its not possible for a 
> system to know the ifindex of the IP interface over which an incoming 
> packet arrived?
> 
>> link traffic came on. I am struggling to suggest an alternative, but
>> would like to see the issue addressed particularly since it is a MUST.
>> 
>> Same is true for the procedure for the reception of BFD control packet
>> and its verification of the interface that it came on.
> I think youre missing something because we already have 3 
> interoperable implementations of this draft. Clearly, those 
> implementations were able to identify the IP interface over which the 
> uBFD packet arrived.
> 
> Cheers, Manav
> 
>> 
>> On Oct 24, 2013, at 10:00 PM, Vengada Prasad Govindan (venggovi) wrote:
>> 
>>> Support
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Jeffrey Haas
>>> Sent: Friday, October 25, 2013 12:45 AM
>>> To: [e-mail]
>>> Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends
>> November 8
>>> 
>>> This email is to initiate working group last call on the BFD on Link
>> Aggregate Group Interfaces document:
>>> 
>>> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01
>>> 
>>> The last call will complete on November 8, the end of IETF week.
>> Time will be available during the Vancouver IETF BFD session to discuss
>> last call comments.
>>> 
>>> Nobo Akiya will be serving as document shepherd (RFC 4858) for this
>> WGLC.
>>> 
>>> Due to the small nature of the BFD working group and the fact that
>> both working group chairs have contributed to this document, we have
>> gotten Carlos Pignataro ([e-mail]) to volunteer to serve as
>> an independent party to gauge working group consensus.
>>> 
>>> In order to facilitate the transparency of this WGLC, please remember
>> to send all comments to the working group mailing list.
>>> 
>>> IPR declarations have been filed against this draft and the document
>> authors and contributors have been polled for any further IPR.  Current
>> IPR declarations may be seen at the following link:
>>> 
>>> 
>> http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft
>> -ietf-bfd-on-lags
>>> 
>>> If you are aware of additional IPR against this document please
>> declare so, per the IETF Note Well.
>>> 
>>> Finally, the IEEE has expressed interest in the disposition of this
>> draft.
>>> They will likely provide additional commentary, if any, via the IETF
>> liaison process.  This process will likely happen after WGLC concludes.
>> Depending on their feedback, WGLC may re-open to address their
>> concerns.
>>> 
>>> -- Jeff (for the chairs)
>> 
>> Mahesh Jethanandani
>> [e-mail]
>> 
>> 
> 
> 
> 
> 
> -- 
> Mahesh Jethanandani
> [e-mail]
>