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

From: Marc Binderberger <[email-masked]>
Date: Fri, 1 Nov 2013 01:28:40 -0700

Hello Mahesh,

> What is wrong with being more clear?

what you propose isn't more clear. And no, there is no specific meaning 
for "interface information" outside a specific implementation. I.e. 
it's implementation specific, which is why we are not trying to say 
more - we would get it wrong for the N+1 implementation (we hardly can 
know them all :-)

As I said, nothing wrong asking question and the answer is it is a 
generic "interface information" tat identifies the particular 
interface. To say more is already wrong for the specification. Even if 
your system uses ifindex (or whatever name an interface identifier 
number has in your implementation) then, as you mentioned, it doesn't 
mean the APIs provide this information. Which means an implementation 
for this draft knows the "interface" in a different way. And again I 
cannot specify what "different way" means, as this would be just one 
example I have in my mind.

The wording has been chosen very carefully ... .

Regards, Marc

On Thu, 31 Oct 2013 23:10:10 -0700, Mahesh Jethanandani wrote:
> Marc,
> 
> I do not know about you, but when I read interface there are specific 
> implications in my mind of what it means. To a certain extent I can 
> see that is in this response from Manav. It means something very 
> specific.
> 
> On Oct 27, 2013, at 4:37 AM, Bhatia, Manav (Manav) wrote:
> 
>> Can you explain the scenario where you think its not possible for a 
>> system to know the ifindex of the IP interface over which an 
>> incoming packet arrived?
> 
> My point is that if you believe that by "interface information" you 
> do not necessarily mean the interface (ifIndex) itself or that it is 
> a fairly generic reference to an identification of a member link of 
> LAG, then just say so. Or better still, say what it should mean. What 
> is wrong with being more clear? If I mis-read what was meant, so will 
> others.
> 
> Cheers.
> 
> Mahesh Jethanandani
> [email-masked]
> 
> 
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 1 Nov 2013 10:58:19 +0000

Hi Mahesh,

> implications in my mind of what it means. To a certain extent I can see
> that is in this response from Manav. It means something very specific.
> 
> system to know the ifindex of the IP interface over which an incoming
> packet arrived?

I had given a general comment in response to your email where you had said that its not possible for systems to be aware of the interface a control packet arrives on.

This draft *never* talks about the ifindex. All we're saying is that when you get a uBFD packet you should somehow know which interface and member port of the LAG the packet arrived on. How you do that is an implementation specific issue and will NEVER affect interoperability. 

I don't understand why we're discussing an implementation specific issue that has no bearing on interoperability.

> 
> My point is that if you believe that by "interface information" you do
> not necessarily mean the interface (ifIndex) itself or that it is a
> fairly generic reference to an identification of a member link of LAG,
> then just say so. Or better still, say what it should mean. What is

Can you point to the text in the draft that gives you the impression that we are talking about an "ifIndex"? 

Cheers, Manav

> wrong with being more clear? If I mis-read what was meant, so will
> others.
> 
> Cheers.
> 
> Mahesh Jethanandani
> [email-masked]
> 
>

---

From: Ashesh Mishra <[email-masked]>
Date: Fri, 1 Nov 2013 11:58:54 -0700

Hi all,

Does the mechanism proposed in this draft suggest that the transmitting end will multicast the BFD CC frames over the LAG and the receiving end will have a Rx session for every member of the LAG?

If so, how will the session negotiation work with more than one endpoint on the peer node?

--
Ashesh

---

From: Marc Binderberger <[email-masked]>
Date: Fri, 1 Nov 2013 13:29:13 -0700

Hello Ashesh,

> the receiving end will have a Rx session for every member of the LAG?

Yes. You have a sending and a receiving session per LAG member link.

> endpoint on the peer node?

section 2.2 explains it. Here the part for starting the session:

   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.

In other words your implementation "binds" a particular Rx/Tx session 
to one member interface (I use quotation marks to indicate the details 
are up to your implementation).

Regards, Marc

On Fri, 1 Nov 2013 11:58:54 -0700, Ashesh Mishra wrote:
> Hi all,
> 
> Does the mechanism proposed in this draft suggest that the 
> transmitting end will multicast the BFD CC frames over the LAG and 
> the receiving end will have a Rx session for every member of the LAG?
>

---

From: Ashesh Mishra <[email-masked]>
Date: Fri, 1 Nov 2013 13:49:18 -0700

Thanks Marc. Having individual Tx/Rx pair for each member link does make the implementation simpler! 

Regards,
Ashesh

> Date: Fri, 1 Nov 2013 13:29:13 -0700
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8
> 
> Hello Ashesh,
>

---

From: Glen Kent <[email-masked]>
Date: Thu, 7 Nov 2013 22:22:36 +0530

Support.

Glen

On Fri, Oct 25, 2013 at 12:44 AM, Jeffrey Haas <[email-masked]> wrote:

> This email is to initiate working group last call on the BFD on Link
> Aggregate Group Interfaces document:
>
> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01
>
> The last call will complete on November 8, the end of IETF week.  Time will
> be available during the Vancouver IETF BFD session to discuss last call
> comments.
>
> Nobo Akiya will be serving as document shepherd (RFC 4858) for this WGLC.
>
> Due to the small nature of the BFD working group and the fact that both
> working group chairs have contributed to this document, we have gotten
> Carlos Pignataro ([email-masked]) to volunteer to serve as an
> independent party to gauge working group consensus.
>
> In order to facilitate the transparency of this WGLC, please remember to
> send all comments to the working group mailing list.
>
> IPR declarations have been filed against this draft and the document
> authors
> and contributors have been polled for any further IPR.  Current IPR
> declarations may be seen at the following link:
>
>
> http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-bfd-on-lags
>
> If you are aware of additional IPR against this document please declare
> so, per
> the IETF Note Well.
>
> Finally, the IEEE has expressed interest in the disposition of this draft.
> They will likely provide additional commentary, if any, via the IETF
> liaison
> process.  This process will likely happen after WGLC concludes.  Depending
> on their feedback, WGLC may re-open to address their concerns.
>
> -- Jeff (for the chairs)
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 10 Nov 2013 22:29:43 +0000

WG:

Hi,

The BFD co-chairs asked me to gauge consensus on the WGLC for draft-ietf-bfd-on-lags-01, which ended November 8th.

There is clearly good support for this document, and I see strong consensus to move forward including the mention of interoperable implementations. There was also a good discussion (and conclusion) on the list about interface identification.

I captured the following notes:
1. Please fix idnits warnings

Thanks,

— Carlos.

On Oct 24, 2013, at 3:14 PM, Jeffrey Haas <[email-masked]> wrote:

> IPR declarations have been filed against this draft and the document authors
> If you are aware of additional IPR against this document please declare so, per
> the IETF Note Well.
> 
> They will likely provide additional commentary, if any, via the IETF liaison

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 11 Nov 2013 15:21:03 +0000

Carlos, thank you for gauging the WGLC consensus on draft-ietf-bfd-on-lags document.

Authors, please address only the idnits and post a new ID.

-Nobo
(as draft-ietf-bfd-on-lags shepherd)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carlos Pignataro (cpignata)
> Sent: Sunday, November 10, 2013 5:30 PM
> To: Jeffrey Haas
> Cc: [email-masked]
> The BFD co-chairs asked me to gauge consensus on the WGLC for draft-ietf-
> bfd-on-lags-01, which ended November 8th.
> 
> There is clearly good support for this document, and I see strong consensus
> to move forward including the mention of interoperable implementations.
> There was also a good discussion (and conclusion) on the list about interface
> identification.
> 
> - Carlos.
> > The last call will complete on November 8, the end of IETF week.  Time
> > will be available during the Vancouver IETF BFD session to discuss
> > last call comments.
> >
> > Due to the small nature of the BFD working group and the fact that
> > both working group chairs have contributed to this document, we have
> > gotten Carlos Pignataro ([email-masked]) to volunteer to serve as
> > an independent party to gauge working group consensus.
> >
> > In order to facilitate the transparency of this WGLC, please remember
> > to send all comments to the working group mailing list.
> >
> > authors and contributors have been polled for any further IPR.
> > Current IPR declarations may be seen at the following link:
> >
> > If you are aware of additional IPR against this document please
> > declare so, per the IETF Note Well.
> >
> > liaison process.  This process will likely happen after WGLC
> > concludes.  Depending on their feedback, WGLC may re-open to address
> their concerns.
> >
> > -- Jeff (for the chairs)