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

[Mahesh Jethanandani <[e-mail]>]

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]