BFD Working Group Session
Tuesday, August 3, 2004 - 15:45-16:45 PST

Presenters:
Dave Ward:
o Agenda
o Base specification
o single hop ipv4, ipv6
o multihop BFD
Rahul Aggarwal:
o BFD for MPLS LSPs
Tom Nadeau:
o BFD MIB
Dave Allan:
o BFD extensions for PW Exchanges of Fault Notifications.
Jeff Haas:
o Standards Process

Dave Ward:
Agenda bashing - no changes.

Agenda overview:
---------------
Reviews of base specification changes, also single-hop ipv4, ipv6
Bootstrap BFD for LSPs

MIB - Tom Nadeau

Appliciations draft for L2-VPN O&M from David Allan.
This document depends on whether L2 VPN WG decides to take this on
this work

Changes being requested to BFD
Whether or not the current diagnostic codes are sufficient.

Dave Ward: Deltas of base spec
-------------------------------
Extensions to the base specification:
C - control plane independant bit.
One reviewer of draft noted that we didn't have control plane
independence in the router. This would be the only signal of
whether we were non-stop-forwarding capable.

A - authentication bit.

Everything else is largely the same.

Overview of authentication:
Optional header extention for authentication.
Generic form of header
Different types of authentication:
o Simple password
o Keyed MD5
Plenty of bits for future use

Simple password authentication very similar to other protocols.

MD5 variants, also very similar to other protocols.
Variant 1: Increment sequence number in header periodically -
does not have to increment each time.
Variant 2: Meticulous md5 - increments the sequence number every
single time.

Multiple keys
The draft recommends GTSM

You SHOULD use authentication whenever you do multi-hop BFD, but clearly
you're free to use it any time you like.

Other changes:
Local discriminator allowed to change any time for a session. It was
decided to do this because specification used to require you to note do
it, but there was not a good reason. This also removes the requirement
to clear remote discriminator whenever the session goes down.

Zafar:
Concerns that we were rapidly using up the bits in the BFD header.

Dave Katz:
We can reserve one bit to say that there will be an extension
that provides further bits. "You reserve the last coding point
as a way of buying yourself further coding points."

Single hop specification
--------------------------
Very few changes.

Clarification of BFD over OSPF virtual links - basically follow
what we're suggesting for multihop sessions.

When tunneling, don't decrement the TTL hop count [Section 8]
Also when tunneling, use the authentication mechanisms.

Multi hop specification
------------------------
Needed more work. Issues incnluded:
How do we de-multiplex the first packet exchanged when the discriminator
values were not exchanged?
What about security? Spoofing?
Authentication?

De-multiplexing:
We don't know what "your discriminator value is going to be".
On single-hop, you can use the interface to de-multiplex the values. You
can't do this in multi-hop since multiple sessions may be served by a
single interface.

A couple solutions:
1. Use arbitrary paths with different source:destination pairs
2. Out of band discriminator signaling like BFD for MPLS where
we will never have a your discriminator value of zero.

Unidirectional link - either solution works.
You can also use some active/passive tricks where the sender plays the
active role and the receiver plays the passive role. When in passive
role, you only send out packets after you receive packets. The receiver
is the demultiplexor at that point.

Further comments:
We'd like to extend the comments for 30 more days and then ask the working
group chairs to put out a working group last call for proposed standard.

There are 3 independant implementations. Please tell us if you have
one so we can add it to the implementation report.

Question:
Multiple sessions on a single entity - how do we associate them for a
different appliciations?

Dave Katz: Implementation specific.
Two entities are typically expected to happen for only one session between
two entities. If you have multiple protocols running between these two
entities, the single BFD session should signal all of the protocols.
However, nothing stops you from doing whatever you want.

We're trying hard to not specify things that do not affect
interoperability.

Question: What about different paths?

Dave Katz: The BFD session is very distinct from it's application.
You could have a BFD session where one side is using it to trigger OSPF
and the other one isn't. We're trying to keep the links between the
application's use of BFD and the session very minimal.

In impliciations he's seen he hasn't seen it necessary for the application
to know that they're using BFD. When it is, this should be communicated
within the protocol.

Dave Ward: We're also trying to not make this an RP or protocol liveness
protocol. That's where we originally started, but we've gone beyond
this. We want to try to keep details about what protocol even set up
the session out of this.

Question: Is there anything in the spec about an implementation of
trigger between a BFD state change and the appliciation?

DK: There is a MAY or a SHOULD. It's nominally required that when
the BFD session fails, "you should tell someone".

Also, if the BFD session doesn't come up, you MUST NOT hold your OSPF
session down because of it. You probably should signal a trigger when
the session goes down and everything else is outside the scope of the
specification.

Question: Is there some context or a session ID that indicates an
association to a trigger for a session?

Dave Katz: That's internal to your implemenation. If it isn't signaled
in the protocol, it doesn't belong in the specification.

BFD for MPLS LSPs.
--------------------
[Note that much of the session didn't get recorded clearly due to
some microphone problem. However, the comments were brief.]
Rahul Aggarwal:
We are requesting this to be made a BFD WG document. It has components
that are currently in the MPLS working group.

A comparison between BFD and LSP-PING was given and the expected
appliciability of each mechanism.
LSP-PING has greater operational overhead.
BFD is much lighter weight and is more appropriate as a liveness
mechanism.

Discussion about using out of band mechanism to bootstrap BFD
session from the Internet-Draft.

Dave Ward: We would like to bring this into the WG as a WG document as
long as LSP-PING is adopted as a WG item. Per George (MPLS WG chair),
we were going to take this bootstrapping of BFD into the WG.

George: Doesn't really care where the work gets done so long as
it gets done.

BFD MIB.
----------
Tom Nadeau

Changes from previous versions of document.
Need to update the MIB to reflect the current protocol structure

General makeup of MIB:
o Configured sessions
o Session state will capture all sessions on the box regardless
of who owns the session.
o Performance table that contains performance stats for each session
o Session mapping table.
Session and performance table indexed by simple key only
significant to the router - because we can have 10's of thousands of
bfd sessions. The mapping table lets you map from session id to
the true keys.
o Only a few scalar variables

Session table: Shows session from the box - flat indexing scheme.

Question to the working group:
Is the structure of this sufficient for the operators that want to
use this? We (Zafar and Tom) really need to know.

Session performance table: Number of sessions, up and down sessions, etc.
It is important for operators to look at this!

The current functionality is extrapolated from the drafts.

2 notifications - session up and down. They can be grouped together
so that you can do one notification in place of X contiguous ones.

One more revision needs to be made to bring it up for the
last call - waiting on next version of base draft.

Question to the WG Chairs: Do we have a MIB doctor?

Chairs: No. We need one assigned.

Tom: Would like one to look this right away.


BFD extensions for PW Exchanges of Fault Notifications.
--------------------------------------------------------
David Allan:
Anyone not at l2vpn?

The slides were edited somewhat from that session.

BFD extension related to pseudowires. Vasile is coauthor.

Motiviation: BFD diagnostic codes and procedures need to be
extended to cover psuedowire operational scenarios.

BFD seems to be a good fit for this.

New diagnostic codes suggested - slightly different semantics
than existing codes.

Discussion points:
This is close to the LDP status tlv?
The two additional BFD diagnostic codes requested may be sufficient.
Do the diagnostic codes need the sense of direction? We think so.

Overlap of functionality with AIS(?) notification.

Discussion of pseudowire components.
Noted how when the BFD session is signalled when the attachment
circuit goes down there is a loss of some AC diagnostic information
since the existing diagnostic codes can't convey quite the
right signaling information.

There was some spirited discussion as to why particular
BFD diagnostics were converted to particular AC circuit down
signaling.

The AIS protocol apparently has enough richness to convey
this information, but BFD does not.

Dave Katz: More generic names for these events would make the diagnostic
codes more palatable.

Dave Ward: If the l2vpn group accepts this mechanism, we can adopt this
mechanism within BFD.

There was a lot of general discussion over the appropriateness
of BFD to convey the OAM information for the pseudowire.

DK/DW: Not in opposition to making appropriate changes, but need
to get some consensus as to what is "appropriate".

From someone in the WG: Is LSP-Ping more appropriate?

Dave Allan: Yes, but it's not light weight enough.

Dave Katz: We're trying to keep this a generic mechanism and adding
some PWE3 specific components goes against the spirit of that.

Jeff Haas: It looks like this is good for PE-PE, but may not
be appropriate for the other components?

Dave Allan: There are number of scenarios we're trying to work through.

Standards Process.
-------------------
Jeff Haas:
IESG asked for clarification on our security practices.
MD5 may not sufficient. They are getting clarification.

It was suggested that SHA-1 should be added as a SHOULD.

We have a depenency on the MPLS WG for LSP-PING. LSP-PING and BFD for
MPLS LSPs will have to advance together in the standards track.

The BFD documents require the new boilerplate and will need to follow
the new ID-checklist.

IPR disclosures are requirerd. The co-authors of the base specification
have been asked for this.

Dave Ward to Bill Fenner: SHA-1 - are we still getting this issue
cleared up?

Bill Fenner: The security guys say we just need replay protection.

Dave Ward: If you want me to put SHA-1 in here, we'll do it.

Bill Fenner: SHA-1 isn't an issue. Keying and replay is an issue.

Jeff Haas: Per bar conversation with Steve, we just need to add some
extra entropy to the keyspace.

As Tom mentioned, we'll need to make some changes ot the MIB.

We need one implementation, we have 3.

We need further community or cross area review.

We have other things to take to other WGs for their or adoption as a
working group item before we can adopt the other items. E.g. L2VPN O&M.

We need IANA considerations for items like code points for error codes.

We are hoping to have WG last call well before November IETF session.