| Thank you to Xiao Min who produced the following transcript of the session from IETF 106. Here is a pointer to the meetecho recording: -- Jeff |
Chairs update: 5 mins - Jeff Haas Welcome to BFD. I'm Jeff Haas, Reshad is unable to co-chair for this session, because he is unable to come Singapore.
We have four sessions today.
BFD for vxlan and BFD for large Packets have been through working group last
call.
A presentation on one-armed BFD.
BFD for vxlan:
15 minutes - Greg Mirsky
Greg: So you can see it, it says The inner destination IP address SHOULD use
one of the loopback addresses. And again, that is because we were told that
their implementations that hard coded using different than that. And we're not
told that they can be configured to something else.
Matthew: In the past, for the tunnelled BFD, it's always set to 127/8.
Greg: I would say, even more generic, when we do any IP OAM over the tunnel, we
use loopback, LSP Ping or BFD, actually BFD follow the same because the first
one it was RFC4379, which changed the loopback in another RFC1122.
Matthew: And that was for pretty good reason I think was something to do if it
gets extracted at the wrong ...
Greg: Absolutely yes.
Matthew: And we've also come across sort of interoperability issues with things
like earlier implementations of seamless BFD, and LSP BFD, where some
implementations will check for 127/8 some won't, and some will discard it if it
is not 127/8. And I'm just worried that if you're implementing this on a box
that's also doing other flavors of BFD you're going to run into issues, if you
allow anything other than 127/8.
Greg: Again, my understanding is that this is something that working group can
decide.
Jeff: So, speaking personally rather than as chair, I think we all agree that
if you're writing this from scratch and you had a clean implementation, the
procedure here is the right thing to do. And the proper thing, likely to do is
the industry is just simply to pressure people to conform with this, certainly
know it's implemented, have that choice by making sure that your stuff doesn't
interoperate with things you consider broken.
Martin: Could you at least write it down what's on the risk of not respecting
that SHOULD?
Greg: OK, that will be easy.
Matthew: Maybe in the security consideration section, right something to say.
Greg: That will be not a problem, absolutely.
Jeff: Yeah, and my feeling of the consensus for the conversation is that SHOULD
gives the feature out there. It encourages people to do the right thing and
implementers that choose not to interoperate with them, have the option to do
so.
Greg: Okay, so just add text in Security Consideration explaining a choice, I
probably pretty much cut and paste text from 4479 or 8029.
Greg: Management VNI is a control signaling channel between VTEPs. So any
communication between them over this channel should be using, if we decide,
this MAC address, including BFD. Is there decision that we'll not address that
in this document?
Jeff: I think that is the reasonable thing we do. That's the consensus we
currently have from the mail discussion. We provided a possible path that
allows us to edit after the fact, updating other RFCs is a reasonable thing to
do. And this means that we can unlock this document through the RFC Queue, and
depending on exactly how much work there is to do in NVO3 for such a management
document, maybe that comes out much faster than this.
Greg: So Demand mode is not mentioned in the document explicitly. And is that
the indication that it's outside the scope of the draft? And if it's outside
the scope of the draft, should we have the same statement similar to in regard
to BFD Echo mode?
Jeff: In regard to BFD Echo mode, the consideration is traffic that needs to be
encapsulated outside the protocol. So that's the reason why it has to be
explicitly said outside. For demand mode, unless there is a reason we think
that it breaks for some strange reason in this environment that we don't need
to mention it because it's just a supportive feature. Just leave it as is.
Greg: With that, I think that we have one action point to the editors to edit
text which is pretty clear, and then for the working group chairs to decide
what we do next.
Jeff: So we've completed working group last call, you've gotten substantial
feedback, the amount of text change is part of the feedback has been relatively
small. So what that means is we've mostly converge on this point. So once
you've added the other item we can each take a quick editor's pass through
things, but the working group last call has concluded. And once we have the new
version we'll advance it to the IESG.
-----
BFD for Large Packets:
5 minutes - Jeff Haas
No questions.
-----
Using One-Arm BFD in Cloud Network:
10 minutes - Weiqiang Cheng
Jeff: A little over a year ago, somebody may be aware of the broadband forum
TR-146 document, and this gave me, why people are asking about it is because
another standards organization had decided that they were going to try to make
use of a small piece of our functionality, but in a way that was not well
specified there, their document has errors in it. This is an understood thing.
Discussion is interesting, so you're the first to bring this to IETF to ask
about this. So, our problem is IETF is doing this to put a document together
that effectively publishes the scenario for BBF, maybe with corrections and
IETF context. Thank you for the presentation is that this is a helpful piece of
functionality. And you also gave an example of could we maybe extend Yang, to
cover this behavior. So that such things could be configured. So, there is
possibility for the work. And certainly if you wish to be one of the authors on
the document towards IETF, that can be done, but there are many process
discussions that have to happen first.
Weiqiang: No problem. I think it will be very useful because currently a lot of
overlay network is deployed that not only within the data center such as the
VxLAN, as well as you know, one system in the SD-WAN, especially for some
industry internet, so maybe that kind of function can be used in more
application scenarios, that will be useful.
Jeff: The issue that we do have to verify before we can start to progress is
since BBF is a standards body. Do they have an intellectual property
restriction, and their proposal. So, even if they wanted to do work on this,
you'd have to figure out the status of that.
Weiqiang: Yeah, I think the bfd is raised by IETF. I think IETF is the host of
the BFD.
Les: This is a kind of interesting. But I'm wondering about the interactions
with the various forms of strict mode. I think that would be problematic.
Jeff: There's probably some sort of no commodity silicon then here that happens
to have a BFD echoes back programmed into their hardware and it makes this
cheap and easy. And people are just using that, but this could be ping, you
know, literally any mechanism could be used that test them to revoke
activity.And you know, the BFD state machinery for clients can be used echo it.
Greg: Actually, thanks to bring the TR-146 to attention, I was not aware of it.
And when I read it, I believe they do use not only BFD echo, they use
combination of poll/sequence to communicate diag modes. And actually that's
where I found more mistakes and misconceptions. And actually the good thing is
that BBF member meeting is one week from this week.
Mach: I think this idea is very interesting and it's very useful for some
scenario. In my personal opinion I think there may be some protocol work to be
defined in this working group, because for the traditional BFD session we need
to set my discriminator, but for this one-armed BFD, we need to set both my
discriminator and your discriminator. So, there may be some different protocol
process to be done for this solution.
Jeff: Based on my understanding, the whole issue here is that they don't want
to put any BFD machinery into the effectively the host devices like a media
gateway for cable networks that sort of thing, very dumb boxes. And they're
relying on the packet loop to simply fulfill the need. So, this is very bad
from the working group's pespective because we don't have any negotiation that
can help BFD sender to figure out packet speed receiver actually wants to get.
This is probably okay for the people who did this work because for their
environment they knew what speed they're willing to support.
Mach: Yeah, for that aspect I think I agree with you there is no need for some
protocol extension between the local side and the remote side, but for the
local process, and based on the current process I think we need some
modifications to the current process and to how to handle the discriminators.
Jeff: No discriminators, remember this is Echo, and it's literally just IP
packets. This is a very dumb mechanism.
Matthew: On your kind of echoing yourself, there is another mechanism called
LSP self-ping, where you just address the packet yourself and send it into an
LSP, and it comes back. So I'm wondering about the negotiation you're taling
about is already you know negotiation with yourself because it's just a route.
Weiqiang: You just send it out. And because the remote side is very weak
system, but it can echo the packet, and we can use very low speed BFD packet
rate, but we can check the link's quality, that's enough.
Jeff: And call it a BFD packet is a little misleading. It's BFD echo packets
that are just data. It just happens to be a well-known port.
Louis Chan: One direction maybe from the echo side is might not actually
require the echo side to do anything, right? So, therefore actually for trouble
shooting we may specify the format so that the echo side can optionally turned
on to get the statistics, so that the trouble shoot to look at what happened in
the networks and look how many sections to be established. I think it may be
useful in some places but need to identify who are the sender, I think that is
important, which is the discriminator and then echo back the packet itself.
Greg: I think that this exchange brings very good question. That was somewhere
in the back of my mind, is it would be good in the document when we write it,
that explain what exactly can be verified and monitored using this technique.
So that to have right expectations, and I want to point out that echo works
only over a single hop. It could be a tunnel, but used to crossing a single
hop.
Jeff: And relaying a question from Robert and jabber, was this spoofing
protection considered in this echo mode? And Greg you just answered a portion
of the question, which is that it's single hop only. Beyond that, this is just
an echo functionality and the remote side exercises no protocol behaviors at
all. So it is up to the sender to put something into the packet that they would
recognize. You know, the BFD 5880 spec does not talk about that at all.
Jeff: So I think the action for the working group is we'll continue discussion
in the mailing list, will discuss things with BBF and figure out how to take
this forward.
-----
Jeff: And that concludes our content. We will probably be meeting in Canada in
the upcoming IETF. And thank you for coming to IETF 106.
