Minutes IETF102: bfd
minutes-102-bfd-01

BFD Minutes
IETF 102 - Montreal
Wednesday July 18th, 15:20-17:50
Chairs: Jeffrey Haas, Reshad Rahman

Meetecho:
https://play.conf.meetecho.com/Playout/?session=IETF102-BFD-20180718-1520
          https://www.youtube.com/watch?v=TsEjkh3s3MY

6m10s in recording
[Note well] 6m25s in recording

[Agenda] 6m35s in recording

[Chairs Slides (Jeff and Reshad)] 7m00 in recording
BFD YANG and BFD multipoint docs in IESG LC.
WG LC for 3 authentication drafts.

BFD authentication drafts: 8m15s
    Greg Mirsky: periodic use of authentication.  Once session is Up, if
    authentication validation fails, what happens then? If we have one
    authenticated packet followed by several non-authenticated packets, RFC5880
    says BFDs session is still up.  If auth fails, we should do something?
    Mahesh Jethanandani: view optimized authentication as not changing the BFD
    protocol any way.  One packet in an up state is marked for authentication
    but fails auth. Protocol says it has to not received its detection
    multiplier, only then will the session be marked down.  If one packet
    fails, but other passes, session stays up. Greg Mirsky: I agree per
    existing specs, that's what supposed to happen.  But then why do the
    periodic authenticated if there’s no impact on state of session when an
    auth packet fails validation? Mahesh Jethanandani: if the auth failed, then
    why? The periodic authentication was added a bit late in the document's
    life again MITM attacks. Greg Mirsky: Authentication is to protect the BFD
    session but we don’t take any actions when a BFD authenticated packet fails
    validation. Feel there is a gap in the logic of the proposal. I see 2
    options 1) periodic doesn't really help, let's remove it. 2) If auth fails
    (periodic mode) in Up state then we should view this as session down. Jeff
    Haas: one possibility is to send detect multiplier number of consecutive
    authenticated packets, then the session will go down if authentication
    packets fail validation. Greg Mirsky: does that require use of P/F
    procedure? Jeff Haas: P/F is not needed, we send consecutive authenticated
    packets Mahesh Jethanandani: we can make that change. Reshad Rahman: is
    there a need to do the same for state change? Mahesh Jethanandani: every
    state change packet has to be authenticated. Jeff Haas: for pedantic
    reasons, when making the state change we should do the same. On P/F
    sequence we should do    this for the new multiplier if it’s longer. We’ll
    take this back to the mailing list.

BFD VXLAN was adopted recently. We were waiting for implementations, we have 2.
Cisco has published IPR against this draft (standard Cisco IPR). We will do WG
LC shortly on this document and get NVO3 WG to pay attention to this document.

BFD unsolicited. Some implementations support this already.
    Jeff Tantsura: YANG model change needed?
    Jeff Haas: yes. Enke, still looking for this to go through adoption?
    Enke Chen: yes, motivation for route servers. Multiple options there.  This
    is the simplest one which some people don’t realize is easy to implement.
    This could be against the base spec or we do informational draft. One
    application is static route and the other is route server. Reshad Rahman:
    regarding YANG model, no decisions on what is needed - full bis, or YANG
    model extensions in the draft. Enke Chen: we just need a configuration
    knob. Naiming Shen: are there prior examples of YANG for feature extensions
    to existing protocols? Reshad Rahman: don't think so but I can’t ask and
    there are enough experts to help you out. Enke Chen: is the BFD YANG
    complete? Reshad Rahman: yes it’s in IESG Enke Chen: not clear where to
    make the YANG change since the unsolicited draft is informational Jeff
    Haas: then we need to change status of the document (can’t be informational)

5884-bis. Jeff Haas has contacted the original authors and they’re willing to
help.  Minor clarification for LSP-Ping bootstrapping mechanism.

Jabber: Greg Mirsky supports BFD VXLAN WG last call.  Will respond to comments.

Adoption call for BFD mpls demand (draft-mirsky—bfd-mpls-demand)
    Jeff Haas: this is core mechanism for BFD, there seems to be an IPR, hope
    Greg can clarify? Greg Mirsky: I’ll get to IPR disclosure. Multipoint BFD
    uses demand mode for IP. Proposal for demand mode for MPLS (RFC5884). Jeff
    Haas: I don’t think this addresses my comments about IPR, will take it to
    mailing list

Jeff Haas: documents to watch elsewhere
Greg Mirsky: p2mp VRRP use case, RTG WG chairs decided that results are
inconclusive because of low response. I’d encourage people to read the draft
and post their thoughts on RTG WG alias.

[BFD Yang Update (Reshad Rahman)] 30m15s in recording
IANA module issue:
    Martin Vigoureux: we don't have to fix this until we get a clear message
    that we should.  Trying to get a rule defined IETF-wide before we change
    this. Need to discuss this with the NETMOD people. Trying to push for
    no-change here. Reshad Rahman: have you discussed with NETMOD chairs?
    Mahesh Jethanandani: if we clear the other discusses we should be able to
    publish? Martin Vigoureux: Discuss has to clear. Jeff Haas: When is the is
    discussion likely to happen? Martin Vigoureux: you (Jeff/Reshad), me, and
    Alissa. Mahesh Jethanandani: could you clarify how NETMOD is involved?
    Reshad Rahman: this is an IETF-wide consideration.  NETMOD would be the one
    involved for the name change. Martin Vigoureux: wouldn't say "approve" wrt
    NETMOD, but definitely NETMOD would be involved in the discussion. Jeff
    Haas: may want to update the best practices document (6087-bis)
Jeff Haas: had discussion with Benjamin that putting security considerations
for the BFD clients in BFD is the wrong spot.


[BFD Multipoint drafts(Greg Mirsky, remote)] 37m15 in recording
Greg Mirsky: multipoint and multipoint-active-tail through IESG last calls.
Still some open items being discussed. Connectivity v/s continuity, proposal is
to switch to continuity. Jeff Haas: use of TESLA is not appropriate for BFD
multi-point Greg Mirsky: draft does not say to use TESLA but to look at TESLA
to give you an idea what to use. Martin Vigoureux: regarding Ben Campbell's
discuss.  Ben didn't understand why active tail is updating multipoint.  Why
they were being progressed at the same time.  To resolve this: active tail
doesn't update multipoint, in multipoint add reference to active tail? Greg
Mirsky: we need the UPDATE because active tail does make changes to multipoint.
Martin Vigoureux: do you need the UPDATE tag since you’re progressing both at
same time. Greg Mirsky: I believe so because multipoint is the base. Martin
Vigoureux: you can do that via normative reference which you have. This is a
purely process DISCUSS. Greg Mirsky: I have no problem with that if it doesn’t
raise other eyebrows. Martin Vigoureux: you might see an update from IESG son
about the use of UPDATE tag.

[BFD for Large Packets (Albert Fu)] 51m30s in recording
Mahesh Jethanandani: one of the questions I wanted to make sure we were all
clear on was that that if the MTU went over 1500 and it went through MPLS
network, we may lose space in the packet due to labels. Is one of the
considerations that we wanted to reduce the MTU size? Albert Fu: issue is 'how
low can you go?'  today, 1500, tomorrow 1400.  We're assuming 1500 is lowest
common denominator on provider edge devices.  We just need a mechanism to
detect that a particular link supports that size.  If BFD fails, we just want
to mark it down and not use it. Reshad Rahman: When we talk about the link,
we're talking about single hop BFD. Albert Fu: Most of them are single hop. 
e.g. Sidney to US.  a lot of metro-E may carry the traffic over a backbone
Reshad Rahman: IP single-hop? Albert Fu: Yes

Matthew Bocci: BFD detecting MTU issue.  It’s really detecting control packets
being dropped? Albert Fu:  Could be connectivity issue, but really the MTU
issue being detected.

Rick Taylor: Really like direction this is going.  How does this interact with
don't fragment bit

Naiming Shen: BFD for faster failover, control plane is too slow.  Do this in
data plane.  Normally BFD detection for all lost traffic.  For MTU issue, it
doesn't change all that often.  Doesn't need to be that fast. Use something
similar to authentication - do it occasionally.  Don't need to have such a fast
pace.  For something like LTE link, don't waste the bandwidth. Albert Fu: would
use the same timers as the protocol timers.  they're control plane, we can't go
too fast with those anyway - don't want false alarms.  But still sub-second. 
BFD interval of 100ms considered in one of our deployments.  This problem
doesn't really happen a lot.  About once a month.  But when it does happen, we
want to resolve it.  If we do this manually, we run scripts with ping.  It's
control plane, and thus low reliability.  It can take 15 minutes just to do our
manual. Jeff Tantsura: for 3.3ms applications with 1500 bytes, we'd kill
performance. Talk to guys like Broadcom, Juniper, etc.  Figure out the slow BFD
times. Jeff Haas: we know that we can't scale like that.  Have discussed with
juniper engineering. We know we know to go slower. Albert Fu: OAM - (Jeff - BFD
is OAM for me), in our case it's CFM.  Not all SPs support OAM (IEEE).  We know
BFD would work since it's IP. Jeff Tantsura: Talking about logical OAM on
silicon, including BFD Reshad: This is for single hop.  BFD echo would do the
trick. Jeff Haas: yes.  xiao min draft I worked on.  Not saying any of these is
the specific solution Albert: BFD echo is not common - 1 out of 3 vendors.
Reshad Rahman: how do you configure this? Albert Fu: as users, if we know both
routers do it, we provision it. Reshad Rahman: some implementations might drop
padded packets. Jeff Haas: open discussion point. Is this motivation for BFD
v2? See this as similar to OSPF authentication Mahesh Jethanandani: 2 points.
platforms for 1500 byte packets, might require redirect for special handling. 
needs to be in operational considerations.  Like idea from Naiming as
occasional packet. Use it as a periodic probe. Jeff Haas: similar to xiao min
draft

Greg Mirsky: similar to optimize authentication (Mahesh) may be interested in
BIER MTU discovery from Stig Venaas. Usability of path MTU discovery
protocols. Aggregation of main MTU, and advertisement of MTU by IGP.  Second
point is if we intend to use multi-hop BFD that BFD session follows same path
as data flow. Albert Fu: IGP to MTU, a control plane type signaling rather than
data plane.  We want to verify the data plane rather than what the control
plane asserts.  wrt path MTU, we do want to try send 1500 byte packets, we
don't want to actually utilize PMTU - want the full size, because it impacts
the service. Greg Mirsky: because you want to be guaranteed, you want to do MTU
monitoring on all physical links.  BFD follows best route, how do you monitor
all possible paths proactively before switching to them? Albert Fu: we're only
trying to protect cases where we'd be doing single hop BFD.  Want the alarm to
go do something.  today, we're in the dark. Rick Taylor: following up on Greg,
you're in an overlay network, in multi-path there's no way to recognize how
things are getting exercised in the underlay.  doesn't matter in his use case.
Jeff: with this mechanism we can actually go use this to assert e.g. that the
CPE link has MTU 1500 as advertised. Or take component link out of  LAG if BFD
fails on the component link. Matthew Bocci: worried about complexity for
bursting, but like the idea. Albert Fu: some vendors have concept of BFD
dampening.  Suppresses flapping client protocols (e.g. 60s) Rick Taylor: big
frames tearing down sessions. Sequence numbering draft/RFC.  There are ways to
work around flap.