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

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Oct 2013 15:14:31 -0400

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: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 24 Oct 2013 19:29:07 +0000

support

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 24 Oct 2013 19:50:41 +0000

Yes/support

Cheers,
Jeff

>>http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-i
>>e
>>tf-bfd-on-lags
>>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 25 Oct 2013 00:48:47 +0000

Support.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jeffrey Haas
> Sent: Friday, October 25, 2013 12:45 AM
> To: [email-masked]
> Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends
> November 8
> 
> 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.
> 
> 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:
> 
> 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 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: "Srihari Raghavan (srihari)" <[email-masked]>
Date: Fri, 25 Oct 2013 01:07:56 +0000

Yes/support.

Thanks
Srihari

On 25/10/13 12:44 AM, "Jeffrey Haas" <[email-masked]> wrote:

>will
>authors
>liaison

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 24 Oct 2013 18:40:04 -0700

Support

Marc

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 25 Oct 2013 10:45:42 +0900

support

Regards,
-Shishio

(2013/10/25 4:14), Jeffrey Haas wrote:
> .

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Fri, 25 Oct 2013 05:00:17 +0000

Support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, October 25, 2013 12:45 AM
To: [email-masked]
Subject: WGLC for BFD over Link Aggregate Group Interfaces - ends November 8

This email is to initiate working group last call on the BFD on Link Aggregate Group Interfaces document:

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.

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:

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: Mahesh Jethanandani <[email-masked]>
Date: Fri, 25 Oct 2013 09:30:27 -0700

I am not clear on the fact whether the draft is talking about BFD session between two boxes that are one hop away and have a LAG between them. I assume it does not address the case where the LAG might be in the middle of the network, where one or both ends of the LAG are not the end points of the BFD session.

The document talks about using IP/UDP encapsulation on each micro BFD session. How will this work on MPLS-TP tunnels running over a LAG?

For initial DOWN BFD packet, where the Your Discriminator field is 0,  the draft suggests that demultiplexing MUST be based on some combination of other fields which MUST include the interface information of the member link. That assumes that systems are aware of what interface the BFD packet came on. That is not always the case, and in a global label/IP space, systems do not have to know the physical link traffic came on. I am struggling to suggest an alternative, but would like to see the issue addressed particularly since it is a MUST.

Same is true for the procedure for the reception of BFD control packet and its verification of the interface that it came on.

> 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 addres…

Mahesh Jethanandani
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 27 Oct 2013 11:37:37 +0000

Hi Mahesh,

This draft only talks about BFD sessions between directly connected boxes.

> For initial DOWN BFD packet, where the Your Discriminator field is 0,
> the draft suggests that demultiplexing MUST be based on some
> combination of other fields which MUST include the interface
> information of the member link. That assumes that systems are aware of
> what interface the BFD packet came on. That is not always the case, and
> in a global label/IP space, systems do not have to know the physical

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?

> link traffic came on. I am struggling to suggest an alternative, but
> would like to see the issue addressed particularly since it is a MUST.
> 
> Same is true for the procedure for the reception of BFD control packet
> and its verification of the interface that it came on.

I think youre missing something because we already have 3 interoperable implementations of this draft. Clearly, those implementations were able to identify the IP interface over which the uBFD packet arrived.

Cheers, Manav

> > 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.
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 29 Oct 2013 12:18:33 +0000

[as an individual]

Hi,

I've followed this document and have also read the current version under WGLC. I support its publication as it solves a real problem and is very comprehensively written.

There are one or two small nits (broken citations/references) that ought to be fixed:
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bfd-on-lags-01.txt

Thanks,

-- Carlos.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 29 Oct 2013 16:46:57 -0700

Manav,

I have problems with the draft in its current format for two reasons.

The fundamental issue is that the proposal requires BFD protocol to rely on
information that is not carried in the frame itself. Unless by interface
check you mean check against IP address. I do not know of many protocols
that require one to validate/use information that is not part of the frame
itself. Protocols that 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.

The second issue as I highlighted is that there is an assumption that
systems carry interface information up to the protocol itself for it to
validate/use the information. Again, I assume you mean the check will be
against the physical interface and not the IP address. That as I mentioned
is a huge assumption. There is no precedence for this.

There are couple of ways to solve the problem.

One way would be to use the IP address on the individual member link to map
a packet to a BFD session running on a member link. When the initial BFD
frame is received with your discriminator as zero, you would use the
destination IP address contained in the packet to figure out which link the
packet was received on. The same would be true of validation of frame. This
will not work for unnumbered interfaces.

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 of the frame (to
a particular link). This would mean that we cannot use the multicast
address to send the BFD frame.

How the IP/MAC address is collected and setup is beyond the scope of this
document.

On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) <
[email-masked]> 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?
>
> I think youre missing something because we already have 3 interoperable
> implementations of this draft. Clearly, those implementations were able to
> identify the IP interface over which the uBFD packet arrived.
>
> Cheers, Manav
>
> >

-- 
Mahesh Jethanandani
[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 30 Oct 2013 04:10:51 +0000

Mahesh,

> information that is not carried in the frame itself. Unless by interface check 

That's what happens with most protocols. How do you identify the ingress IP interface for an IP packet that came from a router multiple hops away. You will have to go beyond the IP payload to associate this packet to an ingress interface.

> you mean check against IP address. I do not know of many protocols that require 
> one to validate/use information that is not part of the frame itself. Protocols that

I don't understand why you say this. The uBFD packet carries the dest IP that's bound to you. You use this information (i.e. the information carried in the frame) + some hints from the data plane to determine whether you need to act on it or not.

> 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).

> The second issue as I highlighted is that there is an assumption that systems carry interface 
> information up to the protocol itself for it to validate/use the information. Again, I assume you mean 
> the check will be against the physical interface and not the IP address. That as I mentioned is a 
> huge assumption. There is no precedence for this.

Isnt this an implementation specific issue? You can, as you suggest later in your email, use the dest MAC.

> One way would be to use the IP address on the individual member link to map a packet 
> to a BFD session running on a member link. When the initial BFD frame is received with 
> your discriminator as zero, you would use the destination IP address contained in the 
> packet to figure out which link the packet was received on. The same would be true of 
> validation of frame. This will not work for unnumbered interfaces.
>
> 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.

> of the frame (to a particular link). This would mean that we cannot use the multicast address to send the BFD frame.
>
> How the IP/MAC address is collected and setup is beyond the scope of this document.

Cheers, Manav

On Sun, Oct 27, 2013 at 4:37 AM, Bhatia, Manav (Manav) <[email-masked]> wrote:
Hi Mahesh,

Cheers, Manav

-- 
Mahesh Jethanandani
[email-masked]

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 29 Oct 2013 23:00:13 -0700

Hello Carlos,

ah thanks!  Okay, RFC 5342 is now RFC 7042 and I have a reference to 
it, to silence idnit (gee, it's just an informational reference! ...) :

----snip----snap----snip----snap----
7.  IANA Considerations

   IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see
   [RFC7042]) as well as UDP port 6784 for UDP encapsulated micro BFD
   sessions.
----snip----snap----snip----snap----

Will upload within the next 24 hours (unless I receive emails not to :-)

Regards, Marc

On Tue, 29 Oct 2013 12:18:33 +0000, Carlos Pignataro (cpignata) wrote:
> [as an individual]
> 
> Hi,
> 
> I've followed this document and have also read the current version 
> under WGLC. I support its publication as it solves a real problem and 
> is very comprehensively written.
>

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 29 Oct 2013 23:22:39 -0700

Hello Mahesh and Manav,

I share some non-understanding with Manav. The part ...

> information that is not carried in the frame itself

... didn't make much sense to me either. Can you explain? I can guess 
that this first point is the same as the second point: how to get the 
interface information?

We also do not make the assumption that the internal IP API is carrying 
interface information. Actually at least one vendor has exactly the 
situation of clearly separated L2 and L3 APIs on one of it's platforms 
and can implement the draft nevertheless.  In other words what you see 
as a problem isn't one.
(implementation hint: binding of MAC API per interface)

Regards, Marc

On Wed, 30 Oct 2013 04:10:51 +0000, Bhatia, Manav (Manav) wrote:
> That's what happens with most protocols. How do you identify the 
> ingress IP interface for an IP packet that came from a router 
> multiple hops away. You will have to go beyond the IP payload to 
> associate this packet to an ingress interface.
> 
> I don't understand why you say this. The uBFD packet carries the dest 
> IP that's bound to you. You use this information (i.e. the 
> information carried in the frame) + some hints from the data plane to 
> determine whether you need to act on it or not.
> 
> 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).
> 
>> 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.
> 
>> of the frame (to a particular link). This would mean that we cannot 
>> use the multicast address to send the BFD frame.
>> 
> 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?
> 
> I think youre missing something because we already have 3 
> interoperable implementations of this draft. Clearly, those 
> implementations were able to identify the IP interface over which the 
> uBFD packet arrived.
> 
> Cheers, Manav
> 
>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 31 Oct 2013 10:23:31 -0700

Manav,

It is understandable that from an implementation perspective, systems might choose to use their own methods to validate frames. RFCs generally tend to stay clear of implementation details. Making a MUST in the protocol for something that is not in the frame itself is new to me.

How about in Section 2.2 third and fourth paragraph you drop the MUST to a SHOULD and clarify what you mean by "interface information" to include e.g. destination IP address or destination MAC address. So the paragraphs would read something like this.

Third paragraph:

"In this case demultiplexing MUST be based on some combination of other fields which SHOULD include the interface information of the member link, such as destination IP address of the member link or destination MAC address of the member link."

and

Fourth paragraph:

"If the Your Discriminator field is non-zero and a micro BFD over LAG session is found, the interface on which the micro BFD control packet arrived on SHOULD correspond to the interface associated with that session. This interface association can be in the form of destination IP address of the member link or destination MAC address of the member link".

Best.

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 31 Oct 2013 18:20:17 -0400

For Mahesh,

> 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

> 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…

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 31 Oct 2013 19:10:48 -0700

Jeff,

My e-mail editor behaves funny so look for comment starting with [mj]

> 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.
>

[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.

-- 
Mahesh Jethanandani
[email-masked]

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 31 Oct 2013 22:15:57 -0700

Hello Mahesh et al.,

from the draft, section 2.2:

   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.

   The procedure for the Reception of BFD Control Packets in Section
   6.8.6 of [RFC5880] is amended as follows for per LAG member link
   micro BFD sessions: "If the Your Discriminator field is non-zero and
   a micro BFD over LAG session is found, the interface on which the
   micro BFD control packet arrived on MUST correspond to the interface
   associated with that session."

And that's it pretty much what we are saying. Fairly generic. What this 
"interface information" is we don't say because this may differ from 
implementation to implementation - and the details are not relevant for 
this specification.

Don't get me wrong, you had a question and you got an answer. But I 
don't see anything to change in the draft.

Regards, Marc

On Thu, 31 Oct 2013 19:10:48 -0700, Mahesh Jethanandani wrote:
>>> 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).
>> 
>> implementation specific issue. There are several devices that may 
>> use a chassis MAC address and MAY not allocate a unique MAC per link.
>> 
> [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.
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 31 Oct 2013 23:10:10 -0700

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.

> 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]