Subject: BFD on LAGs - 04 published

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Jun 2012 13:40:12 -0400

Working Group,

I'm still waiting for the I-D publication notice to work its way through the
system, but the latest version of BFD over LAGs is available for comment:

http://tools.ietf.org/html/draft-mmm-bfd-on-lags-04

This version of the draft reflects the various comments we've had to this
point and in particular attempts to address the IEEE concerns with the
draft.

At this point, the draft appears to be rapdily converging on stability.
There is still time for a -05 to be issued prior to the upcoming IETF
session to reflect further discussion.  The authors and editors would thus
like to invite comment on the draft.

It is my expectation that even if the implementation details for the BFD
over LAG mechanism are likely to change that our normative requirements on
LACP will *not* change.  

I'd like to request for expedited review from the WG to review the draft, in
particular for the normative requirements on LACP.  This is so that we can
issue our response to IEEE.

I'd like to suggest a one week review period prior to the IEEE response.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 21 Jun 2012 17:05:25 -0700

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.

Regards,
Greg

---

From: Yael Frank Dayan <[email-masked]>
Date: Mon, 25 Jun 2012 13:31:24 +0000

Hi,
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?
Thanks,
Yael

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Friday, June 22, 2012 3:05 AM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: BFD on LAGs - 04 published

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.
Regards,
Greg
On Wed, Jun 6, 2012 at 10:40 AM, Jeffrey Haas <[email-masked]> wrote:
Working Group,

-- Jeff

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 26 Jun 2012 04:54:12 +0530

Yes, that's what it means.

Cheers, Manav 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yael Frank Dayan
> Sent: Monday, June 25, 2012 7:01 PM
> To: [email-masked]
> Subject: RE: BFD on LAGs - 04 published
> 
> Hi,
> The term 'peer's remote IP address' is not specific enough. 
> Do you mean the IP address assigned to the aggregated interface?
> Thanks,
> Yael
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Greg Mirsky
> . 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.
> Regards,
> Greg
> I'm still waiting for the I-D publication notice to work its 
> way through the system, but the latest version of BFD over 
> LAGs is available for comment:
> 
> This version of the draft reflects the various comments we've 
> had to this point and in particular attempts to address the 
> IEEE concerns with the draft.
> 
> There is still time for a -05 to be issued prior to the 
> upcoming IETF session to reflect further discussion.  The 
> authors and editors would thus like to invite comment on the draft.
> 
> It is my expectation that even if the implementation details 
> for the BFD over LAG mechanism are likely to change that our 
> normative requirements on LACP will *not* change.
> 
> I'd like to request for expedited review from the WG to 
> review the draft, in particular for the normative 
> requirements on LACP.  This is so that we can issue our 
> response to IEEE.
>