Draft minutes for BFD session for IETF-88, Vancouver

[Jeffrey Haas <[e-mail]>]

The following are the draft minutes for the working group session at IETF-88
in Vancouver.  Please send corretions to the WG list.

I will be posting these notes immediately to the proceedings and will post
updates no later than this Friday.

--------------------------8<--- cut --->8---------------------------

BFD Working Group, IETF-88 Vancouver
Monday, November 4, 2013
Chairs: Nobo Akiya ([e-mail]), Jeffrey Haas ([e-mail])

------

Presentation: Working Group Status
(see meeting materials)

3 documents in Working Group last call, ending this week. (November 8.)
The Working Group chairs will be handling the shepherding of the documents.
Carlos Pignatoro has volunteered to gauge Working Group consensus.

There have been a few clarification questions on BFD on LAGs
(draft-ietf-bfd-on-lags).  The questions on the list appear to be resolved.

BFD MIB documents (draft-ietf-bfd-mib, draft-ietf-tc-mib), as expected, not
getting a lot of feedback requesting changes.

MPLS MIB document (draft-ietf-bfd-mpls-mib), needs additional input on the
mailing list.  Particulary, are there any implementations available?

BFD Crypto documents (draft-ietf-bfd-generic-crypto-auth,
draft-ietf-bfd-hmac-sha) demonstrate good practice and the KARP Working
Group gave us good input.  However, the motivation for BFD authentication
crypto at line rate is not there at the moment.  This is holding back
implementations and thus progression of the documents in the Working Group.
S-BFD may potentially require some stronger crypto?

BFD multipoint (draft-ietf-bfd-multipoint). Silent tail not being
implemented. Should silent tail get snipped to move draft along? Dave Ward
doesnt think we should move it out.
Perhaps we can move active tail to appendix?

Interval draft (draft-akiya-bfd-intervals).
Nobo: There's an interesting problem of P/F bit workability when the session
is not yet up, when HW based BFD supports deviating interval set.
I spoke to co-author, Marc Binderberger, and he is actively working
on this document to roll it out as informational draft.
If you have any inputs around interval topic, please send to WG list.

Greg Mirsky, Ericsson: We should target BCP for this document.

Several people at the meeting had read the draft and would support its
adoption as a Working Group document.

Redundancy draft (draft-mbind-bfd-redundancy), there were some discussion on
the list.  Impression is the draft will not move forward.

BFD over eVPN (draft-vgovindan-l2vpn-evpn-bfd) will be presented in L2VPN,
perhaps presented as BFD at next London.

------

Presentation: S-BFD (Nobo Akiya)
(see meeting materials)

Greg Mirsky (on the alert discriminator draft): In the BFD multi-hop, there
is no mechanism, nothing to require congruent forwarding.  The tools are
thus no less predictable.  Doesn't really matter which tool you're using.

Nobo Akiya: In IP multi-hop, how do we protect it in the first place?

Greg Mirsky: The ambiguity is just there to begin with.

Nobo Akiya: If you have BFD multi-hop in the first place, operators still want to
find the issues.

Greg Mirsky: BFD will just get ICMP.

Nobo Akiya: In some cases, yes.

Greg Mirsky: This argument to switch to use IP traceroute is only an _okay_
mechanism.

Nobo Akiya: There are scenarios for a BFD trace...

Greg Mirsky: Traceroute S-BFD may not follow the same path as ECMP traffic.
If we're talking about IP, it is one thing.  MPLS may be something
different.

Nobo Akiya: The longer you wait, the harder it is to determine where the
fault was.

Greg Mirsky: Fault isolation is usually driven by the operator.

Nobo Akiya: The hints this would provide are still helpful for operators.

Greg Mirsky: [Wants to hear from the operators.]  LSPTrace is sufficient.
LSP Ping can be extended better than BFD, usually.

---

Greg Mirsky: On selecting the discriminator, there's some confusion.  For
example, suggesting that an IPv4 address is directly interpreted but also
refers to a mapping table.  What happens if it is already allocate by
dynamic BFD?  Since S-BFD is on a different port, use a different
discriminator pool.  Overlapping spaces creates a lot of issues.

Nobo Akiya: Agreed.  Part of the change was for this reason.

Greg Mirksy: It's more robust. Separate space of reserved values in an IANA
registry?  Mapping other than direct registration.

Nobo Akiya: Please clarify.

Greg Mirsky: The ambiguity is the IP address is the same as the
discriminator.  If mapped, you can map numbers to discriminators easily.

Nobo Akiya: Direct mapping is simpler.  No signaling is required.

Greg Mirsky: The mapping mechanism can be outside of the BFD protocol.
Manual provisioning is often more flexible.

---

Greg Mirsky: It's good to have separate requirements documents.  I don't see
enough reason to justify this feature [S-BFD] compared to IP and LSP Ping.
These are better to troubleshoot an IP/MPLS network.

Perhaps talk to the LMAP Working Group about large scale access groups.
It's possibly in their charter to help.

Jeff Haas: The S-BFD mechanism is not just about the alert feature.  The
primary novel thing about the feature is that it can provide _stateless_
BFD.  The presentation shows several mechanisms that were originally part of
a single document that had been split into the base feature and several
application documents.  Most of the comments provided have targeted the
alert feature, but it's not even the biggest feature.  Suggest the WG
consider evaluating it in that light.

What happens when you have need for reachability verification at extremely
large scale and use existing BFD?  This may be one use case.

To handle cryptographic sequence number, some amount of minimumal state
needs to be kept.

Greg Mirsky: Use case document may be appropriate?

---

A poll of the room showed that about half of the room had read the S-BFD
drafts.  A second poll showed that most of those who had read it would
support the documents be adopted as Working Group Drafts.


--------------------------8<--- cut --->8---------------------------

-- Jeff