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

[Marc Binderberger <[e-mail]>]

Hello Mahesh et al.,

from the draft, section 2.2:

   The demultiplexing of a received BFD packet is solely based on the
   Your Discriminator field, if this field is nonzero.  For the initial
   Down BFD packets of a BFD 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.

   The procedure for the Reception of BFD Control Packets in Section
   6.8.6 of [RFC5880] is amended as follows for per LAG member link
   micro BFD sessions: "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 MUST correspond to the interface
   associated with that session."


And that's it pretty much what we are saying. Fairly generic. What this 
"interface information" is we don't say because this may differ from 
implementation to implementation - and the details are not relevant for 
this specification.

Don't get me wrong, you had a question and you got an answer. But I 
don't see anything to change in the draft.


Regards, Marc



On Thu, 31 Oct 2013 19:10:48 -0700, Mahesh Jethanandani wrote:
> Jeff,
> 
> My e-mail editor behaves funny so look for comment starting with [mj]
> 
> 
> On Thu, Oct 31, 2013 at 3:20 PM, Jeffrey Haas <[e-mail]> wrote:
>> For Mahesh,
>> 
>> On Wed, Oct 30, 2013 at 04:10:51AM +0000, Bhatia, Manav (Manav) wrote:
>>> > 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).
>> 
>> I want to strongly support this point since it seems to be the big item of
>> contention here.  IP implementations have been able to tell what interface
>> datagram protocols come in for a rather long time.
>> 
>> If you were to base your argument largely upon this point, you'll have to
>> throw out a large chunk of deployed multicast protocols. :-)
>> 
>> FYI:
>> http://linux.die.net/man/7/ip - see IP_PKTINFO
>> 
>>> > 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.
>> 
>> The draft effectively says "figure out what interface it came in on".  If a
>> given implementation of an IP stack has deficiencies compared to others,
>> there are options.  The real question is whether the text is clear enough
>> about this point.
> 
> [mj] My last e-mail effectively suggests just that. If the draft 
> says, figure out for yourself which member link a particular BFD 
> frame came on, it would be fine. It is the implication (and where the 
> text could be more clear), that it is the ifIndex that the system 
> MUST match against, is where I had a problem.
> 
> How systems map the frame to a member link is an implementation level 
> detail which is outside the scope of this draft.
> 
> I suggested some text, but it is just that.
> 
>> 
>> -- Jeff
> 
> 
> 
> -- 
> Mahesh Jethanandani
> [e-mail]