Subject: IETF 94 candiate minutes

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Nov 2015 19:02:20 -0500

Thanks to Ignas and Reshad for taking minutes and to Reshad for
consolidating them.

Please forward addendums or corrections to the mailing list by end of day
Friday.

----- Forwarded message from "Reshad Rahman (rrahman)" <[email-masked]> -----

Tuesday, November 3, 2015
        10:30 - 11:30  Morning session I
        Chairs: Jeff Haas, Reshad Rahman
        Scribe: Ignas Bagdonas [email-masked]

1) 10:30-10:40 - WG Status Update

[Jeff]
Thank you Nobo, welcome to Reshad.

[Jeff]
Document status: wiki status is current. 5884-bis is in editor queue. Santosh Pallagati is taking over editorial work for S-BFD (one open issue).

[Jeff]
S-BFD use case document publication status - what is the feeling of WG? Taking sense of the room. Do you think we should publish this? Not to publish this? Two people have opinion on this, one way or the other. Sense of WG is that this is not critical work, will give another chance to the authors.

[Jeff]
WG last-call: 2 multipoint drafts and MIB draft. 0 comments to date regarding progressing these documents.

Have you read BFD multipoint document? Of you who have read the document who think that it is ready for last-call? Around two-thirds of the people have read the multi-point draft and think it should go to last-call.

[Loa Andersson]
I would not object the progress of the first MP doc.

[Jeff]
Is there anyone who has read the first MP document but not the second one and would like to progress the first one?
[Answer]
Sense of the room seems to be that we will progress these things together.

[Jeff Haas]
Who has read the MIB document?
[Answer]
One.
[Loa]
It should get MIB Doctor review too.

[Jeff]
Interesting BFD work going on elsewhere: use of BFD with VRRP (RTG WG) to benefit from BFD’s more aggressive timer intervals.

2) 10:40-10:50 - https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-01 BFD For VXLAN presented by Greg Mirsky

[Jeff]
Regarding adoption as WG doc, this draft is not intended to be in BFD WG since there are no BFD changes.
[Greg]
To be presented in NVO3 also.

[Jeff]
Concerns on multicast addressing on mailing list.
[Greg]
That is a generic concern of multicast in DC environment. VRRP uses well known multicast address. This is a generic problem. We need to find the right group to discuss this.
[Jeff]
VRRP does not use aggressive timers as BFD. There can be many sessions crossing the same link.
[Greg]
There was a proposal to use multipoint BFD to help convergence of VRRP

[Shahram]
Is the intention to have BFD packet processed up-mep or down-mep?
[Greg]
Up-Mep is the intent. We can enforce/check that.

[Shahram]
Is the intent to test VXLAN forwarding?
[Greg]
Yes.

[Wim Hendrickx]
There are VXLAN OAM proposals (OAM bit in VXLAN header). Did you consider integrating this solution into a more common NVO3 OAM protocol?[Greg] Yes.
[Wim]
If that mechanism would become available, would you be willing to adopt it for your proposal?
[Greg]
Yes.

[Ilya Vershkov]
Does VNI 0 address ECMP?
[Greg]
If we have OAM protocol, then ICMP overlay then becomes a non-issue. IP OAM has a problem ensuring that your OAM traffic is inband. If you are in a tunnel, you are guaranteed to be inband. You can have different source BFD sessions to the same target FEC to address ECMP use case.

[Jeff Tantsura]
The current incarnation is used to detect the liveness of receiver, not the end-to-end path.  Change of UDP port to change path?
[Greg]
If we have ACH and OAM protocol type, then we are not subject to UDP header hashing and will follow the same path. BFD is more of CC than CV.

[Jeff Haas]
How many people have read the doc?
[Answer]
8 people read the doc.
[Jeff Haas]
You need to talk to NVO3 and see how to progress OAM mechanism there.

3) 10:50-11:00 - https://tools.ietf.org/html/draft-mahesh-bfd-authentication-01 BFD Fast Authentication presented by Ashesh Mishra

[Ashesh]
Proposed to adopt this as WG doc.
[Jeff]
Requests that authors find someone to check all the state transitions. Any review from security group?
[Ashesh]
None at this point

[Jeff]
Out of those who have read the doc, how many think it is ready for adoption?

4 people say it’s ready for adoption

[Shahram]
How about any changes to the packet? e.g. Timer interval change
[Ashesh]
Poll sequence is part of the change which requires authentication

[Jeff]
Shahram are you happy to support this authentication mechanism?
[Shahram]
Yes

[Jeff Haas]
How many operators in the room
[Answer]
3

[Jeff Haas]
Out of the 3 how many have deployed BFD authentication?
[Answer]
2 out of 3.

[Reshad]
Is it only for single-hop?
[Answer]
Yes.

[Jeff]
SHA-1 EOL is closer than expected, need to use stronger crypto mechanism, but then the rate needs to be decreased?

4) 11:00-11:10 – https://tools.ietf.org/html/draft-ietf-bfd-yang-00 BFD YANG Update presented by Reshad Rahman

[Les Ginsberg]
When an implementation has different sessions for same neighbour, what is the value add? Why support it?
[Reshad]
I don’t have the answer at this point

[Greg Mirsky]
I see a use case for multihop BFD. For single hop bfd I do not see possible use cases. In case of IP MPLS, you can use source port number trick to cover ECMP scenario scenario to force sessions onto different ECMP paths.
[Mahesh Jethanandani]
Was the question specific to MPLS, or for any routing protocols running between two endpoints?
[Les]
My question is for multiple clients requesting multiple sessions.
[Reshad]
One use case that I can see is multiple applications requiring different convergence parameters.
[Jeff Haas]
One application is granularity of timers. This is because of how timer negotiation works - more aggressive timers get accepted, and in case of failure of the more aggressive session may be covered by another session with less aggressive timers.
[Les]
That is a good summary. The question for the group whether WG wants to support it.
[Reshad]
What we are discussing in Design Team is not a common implementation. If this makes life for majority of implementations hard then this is not right approach.
[Jeff]
We can choose one or another behaviour. As an example from BGP, there may be multiple BGP sessions between the same two peers, there are a few deployments and that added a lot of complexity.

[Jeff Haas]
Regarding LIME - it does not define common RPC types. With S-BFD we have basically introduced ping stype functionality.
[Jeff Haas]
Question to Loa. Do MPLS chairs have a work item to try to look at this work and make sure that it is supporting your needs?
[Loa Andersoon]
We are not doing anything to coordinate. If this is needed, we can address it, but we do not do that at the moment.

5 – 11:10-11:20 - Wrap–up

[Jeff Haas]
Is there anybody in the room that has implenentation that supports demand mode BFD?
[Answer]
No-one.
[Jeff Haas]: BFD has been pretty stable for several years. We potentially can take BFD to full standard then. This needs to do errata, implementation reports, etc. Question to WG - do you think that BFD should be considered to be full standard?
[Answer]
0 hands.
[Jeff Haas]
I will take the question to the mailing list.

[Shahram]
Is anyone using echo mode?
[Jeff Haas]
Yes, there are vendors supporting echo.
Attendees from Cisco (Reshad Rahman, Mahesh etc) and Ericsson (Rick Taylor) indicated that they support echo.

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 17 Nov 2015 22:55:21 -0800

Hello Jeff & BFD list,

> [Jeff Haas]: BFD has been pretty stable for several years. We potentially 
> can take BFD to full standard then. This needs to do errata, implementation 
> reports, etc. Question to WG - do you think that BFD should be considered 
> to be full standard?
> [Answer]
> 0 hands.
> [Jeff Haas]

Being a full standard, does this has any implications for BFD?  Will there be 
more IETF-hoops to jump through for future protocol work?  Or is it more a 
natural step for a stable "Proposed Standard" to be recognized as a Standard?

Regards, Marc

On Tue, 17 Nov 2015 19:02:20 -0500, Jeffrey Haas wrote:
> Document status: wiki status is current. 5884-bis is in editor queue. 
> Santosh Pallagati is taking over editorial work for S-BFD (one open issue).
> 
> [Jeff]
> S-BFD use case document publication status - what is the feeling of WG? 
> Taking sense of the room. Do you think we should publish this? Not to 
> publish this? Two people have opinion on this, one way or the other. Sense 
> of WG is that this is not critical work, will give another chance to the 
> authors.
> 
> [Jeff]
> Have you read BFD multipoint document? Of you who have read the document 
> who think that it is ready for last-call? Around two-thirds of the people 
> have read the multi-point draft and think it should go to last-call.
> 
> [Loa Andersson]
> Is there anyone who has read the first MP document but not the second one 
> and would like to progress the first one?
> [Answer]
> Interesting BFD work going on elsewhere: use of BFD with VRRP (RTG WG) to 
> benefit from BFD’s more aggressive timer intervals.
> 
> That is a generic concern of multicast in DC environment. VRRP uses well 
> known multicast address. This is a generic problem. We need to find the 
> right group to discuss this.
> [Jeff]
> There are VXLAN OAM proposals (OAM bit in VXLAN header). Did you consider 
> integrating this solution into a more common NVO3 OAM protocol?[Greg] Yes.
> [Wim]
> If we have OAM protocol, then ICMP overlay then becomes a non-issue. IP OAM 
> has a problem ensuring that your OAM traffic is inband. If you are in a 
> tunnel, you are guaranteed to be inband. You can have different source BFD 
> sessions to the same target FEC to address ECMP use case.
> 
> [Jeff Tantsura]
> The current incarnation is used to detect the liveness of receiver, not the 
> end-to-end path.  Change of UDP port to change path?
> [Greg]
> If we have ACH and OAM protocol type, then we are not subject to UDP header 
> hashing and will follow the same path. BFD is more of CC than CV.
> 
> [Jeff Haas]
> 3) 10:50-11:00 - 
> https://tools.ietf.org/html/draft-mahesh-bfd-authentication-01 BFD Fast 
> Authentication presented by Ashesh Mishra
> 
> [Ashesh]
> I see a use case for multihop BFD. For single hop bfd I do not see possible 
> use cases. In case of IP MPLS, you can use source port number trick to 
> cover ECMP scenario scenario to force sessions onto different ECMP paths.
> [Mahesh Jethanandani]
> One application is granularity of timers. This is because of how timer 
> negotiation works - more aggressive timers get accepted, and in case of 
> failure of the more aggressive session may be covered by another session 
> with less aggressive timers.
> [Les]
> What we are discussing in Design Team is not a common implementation. If 
> this makes life for majority of implementations hard then this is not right 
> approach.
> [Jeff]
> We can choose one or another behaviour. As an example from BGP, there may 
> be multiple BGP sessions between the same two peers, there are a few 
> deployments and that added a lot of complexity.
> 
> [Jeff Haas]
> Regarding LIME - it does not define common RPC types. With S-BFD we have 
> basically introduced ping stype functionality.
> [Jeff Haas]
> Question to Loa. Do MPLS chairs have a work item to try to look at this 
> work and make sure that it is supporting your needs?
> [Loa Andersoon]
> [Jeff Haas]: BFD has been pretty stable for several years. We potentially 
> can take BFD to full standard then. This needs to do errata, implementation 
> reports, etc. Question to WG - do you think that BFD should be considered 
> to be full standard?
> [Answer]
> 0 hands.
> [Jeff Haas]

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Nov 2015 05:32:08 -0500

Marc,

> natural step for a stable "Proposed Standard" to be recognized as a Standard?

No additional hoops for future work.  It is just recognition of stability.
It should be noted that of all of the RFC series, there are less than 100
full standard document sets.

But that said, part of the work of moving to full standard is taking care of
any open issues in the specs.  With regard to the based RFC 5880, this
really covers two items:

- Demand mode, no one implements this.
- The M-bit, for multipoint.  We're trying to get that implemented. :-)

It's perhaps arguable that the fast authentication mechanism and the better
cryptographic functionality drafts are part of the suite we'd want to take
with us if we went to full standard.

-- Jeff