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

[Jeffrey Haas <[e-mail]>]

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.

-- Jeff