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

[Mahesh Jethanandani <[e-mail]>]

Manav,

It is understandable that from an implementation perspective, systems might choose to use their own methods to validate frames. RFCs generally tend to stay clear of implementation details. Making a MUST in the protocol for something that is not in the frame itself is new to me.

How about in Section 2.2 third and fourth paragraph you drop the MUST to a SHOULD and clarify what you mean by "interface information" to include e.g. destination IP address or destination MAC address. So the paragraphs would read something like this.

Third paragraph:

"In this case demultiplexing MUST be based on some combination of other fields which SHOULD include the interface information of the member link, such as destination IP address of the member link or destination MAC address of the member link."

and

Fourth paragraph:

"If the Your Discriminator field is non-zero and a micro BFD over LAG session is found, the interface on which the micro BFD control packet arrived on SHOULD correspond to the interface associated with that session. This interface association can be in the form of destination IP address of the member link or destination MAC address of the member link".

Best.

On Oct 29, 2013, at 9:10 PM, 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]

Mahesh Jethanandani
[e-mail]