Re: IETF 94 candiate minutes

[Marc Binderberger <[e-mail]>]

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]
> I will take the question to the mailing list.


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:
> 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)" <[e-mail]> 
> -----
> 
> Tuesday, November 3, 2015
>         10:30 - 11:30  Morning session I
>         Chairs: Jeff Haas, Reshad Rahman
>         Scribe: Ignas Bagdonas [e-mail]
> 
> 
> 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.
> 
>