Subject: Re: BFD on LAGs - 04 published

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Jul 2012 15:57:31 -0400

Yael,

On Mon, Jun 25, 2012 at 01:31:24PM +0000, Yael Frank Dayan wrote:
> I think the following needs clarification:
> "Control packets use a destination IP address that is the peer's remote IP address."
> The term 'peer's remote IP address' is not specific enough. Do you mean the IP address assigned to the aggregated interface?

As Manav has separately answered, that is our intention.  However, as
discussion among the authors has shown we still have a little way to go to
define what the remote IP address will be in various scenarios.  One example
scenario is unnumbered IP interfaces.  

A second example is when a link is provisioned with 802.1q - which VLANs
address do we use, if any?  The authors are adding some text in the upcoming
-05 to attempt to discuss this case.

> Yael

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Jul 2012 16:33:17 -0400

Greg,

On Thu, Jun 21, 2012 at 05:05:25PM -0700, Greg Mirsky wrote:
> Dear Authors, Editors, et al.,
> I have one rather terminology note to the document:
> 
>    - Introduction. "The goal is to verify link connectivity for every
>    member link." I believe that BFD as per RFC 5080 verifies continuity, not
>    connectivity. If it was the latter, then there should be definitions of
>    mis-connectivity defects, i.e. as in RFC 6428. Yes, the RFC 5080 refers to
>    connectivity check, not to continuity check but, IMHO, clear terminology
>    helps and perhaps we need to get these definitions clarified and use them
>    properly.

Thanks for your comment.  RFC 6428 does provide some clear examples about
how the mechanism there can provide mis-connectivity diagnostics.  In the
current version of the draft, -04, LACP is used to provide the
mis-connectivity verification.  The draft, however, also provides for the
ability to use the feature in the absence of LACP and it's worth considering
how connectivity errors can be diagnosed in that mode.

At this time I'd suggest that the text remain as it is.  We can continue to
explore connectivity verification in the absence of LACP in future versions
of the draft with input from the working group.

-- Jeff