Notes IETF 63 BFD Working Group

David Ward <dward@cisco.com> Fri, 12 August 2005 15:22 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bMy-0006ml-5h; Fri, 12 Aug 2005 11:22:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bMw-0006mZ-1o for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 11:22:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00830 for <rtg-bfd@ietf.org>; Fri, 12 Aug 2005 11:22:47 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3bvT-0004cs-8E for rtg-bfd@ietf.org; Fri, 12 Aug 2005 11:58:32 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2005 08:22:36 -0700
X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="331693552:sNHT725347162"
Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7CFMQQM000756; Fri, 12 Aug 2005 08:22:27 -0700 (PDT)
Received: from [10.83.142.178] (cfcentral.cisco.com [64.101.210.32]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA19068; Fri, 12 Aug 2005 10:22:29 -0500 (CDT)
Mime-Version: 1.0
X-Sender: wardd@127.0.0.1
Message-Id: <p0611040abf226ac34866@[10.83.142.178]>
Date: Fri, 12 Aug 2005 10:22:34 -0500
To: rtg-bfd@ietf.org
From: David Ward <dward@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32
Cc: jhaas@nexthop.com, dward@cisco.com, dkatz@juniper.net
Subject: Notes IETF 63 BFD Working Group
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

IETF 63 BFD WG Meeting Minutes

Thanks to Tom Nadeau for taking the minutes.


Wednesday, August 3  9:00 AM

Dave:  Introduction. Read Note Well.

         Short agenda:
Dave will talk about changes, applicability.
Presentation by Suping.

0) Status of the drafts.
         LC base specs. Technically, last call is finished. Released
           an intermediate draft containing only editorial comments. 
No comments (0)
           during LC. Assuming that most folks are happy with single-hop and
            MH specs. Will send out call for implementation experience.

         MH spec. minor tweak.

         MIB: may need another spin.  Will go to LC after quick review to
            determine if any changes needed. Tom, is this okay?  Yes.

         MPLS spec. WG LC start next week.

         Generic spec. version 00 is out. version -01 is imminent.
            Potentially to LC after draft settles down or 3 week comment period.

         Milestones:  Status to be updated. Expect last meeting in Vancouver.

         Discuss specification changes details:  Base spec., SH,
            MH spec.  Major change is a port change used to discern MH or SH
            cases.

         Comments on new version of MIB? Dave asks for comments. No comments.

         New author set on MPLS draft.  Basic changes to draft are to 
send original
             port, but replies will use the MH port on replies.  Dave 
asks room for
             comments. No comments.

1) Describes diffs between generic draft 00 and 01.

         Dave: Alex Z. is here. Can we get a MIB Doc review for MIB?
         Tom: can we do the LC and MIB doctor review at the same time? 
Alex: I will send
            an email to  MIB doctor pool and get one assigned.

0a) Dave: back to diffs...

         Dave: I would like comments on multiple topologies or adj multiplexed
           over one interface. Must have proper packet demux before 
session demux. Is this
           a good change?

             PekkaS: Yes, this is a good change.

         BFD should not be used to carry any other 
application-specific information.

         Lowest level of control plane should be attached to the BFD 
session. Others
         should be keyed to the events (control dependencies) from this FSM.

         Last slide is on static routes.  Must be configured on both 
end points to work.
           Recommending BFD is bootstrapped the same way its done for 
the static case. Transition
           to/from states processing should be the same as non-static case.

         BFD should be run inside tunnels for max to operate at most basic
           level.

         Dave: should this draft be informational?

            Alex: could be okay for standards track.

         Rob (Laurel): you said in a hierarchy that BFD should 
interact with the lowest level.
             The lowest level should bootstrap too. So from a 
bootstrapping AND a listening situation
             BFD should interact with the lowest level? Clarify?

         Dave: You can bootstrap the BFD session using the best method.
            The lowest point of the control plane should interact with the BFD
             session.

         Rob: for iBGP, ignore BFD. don't set up BFD sessions to loopbacks. Let
             OSPF/ISIS do it. Its not aware that BFD is running.

         Dave: There is nothing subtle there. You can do whatever you 
think makes
             sense. But the recommendation is not to run BFD to 
loopbacks or IBGP
             sessions. Use lower layer.

         PekkaS:  We dont have any documents yet that describe the static
             route case nor do these show how to run this in iBGP.

         Dave: I think we do.  We have statics in non-control plane portion of
             the documents.   You generally don't want to run this for 
iBGP peers;
             you run it on IGP.  In MH or eBGP case we do explain why this is
             needed.  External BGP reacts to the downstate of the directly
             connected link or fwding plane. We describe the l3 state 
and tear down the
             session quickly.  Maybe we need stronger text?  With static routes
             we don't do bootstrapping, so when its configured you
              can have a BFD configuration too. Local decision.

          PekkaS: What I was looking for is guidance of what to do in
             these cases, to have consistent implementations.

     Dave: Whether or not you deactivate the route is a local decision,
          but will most often result in not transmitting data.

     PekkaS: I still don't get it.

     Dave: The sentence should state that you can stop
         xmitting data and should withdraw the route if redistributed.

     PekkaS: Another eBGP question. Issues with graceful restart?

     Dave: It could: When receiving a BFD failure notification, in
         eBGP you would tear down the state and if the router was enabled
        for Graceful Restart, it should not perform GR. We are only detecting
        failure of data plane.

     Tom: in MPLS draft I think that we recommended that you do
         the graceful restart procedures if sessions are lost.

     Dave: We can suggest some language in draft. In the eBGP
         case the assumptions of graceful restart might want to be
         avoided. The assumption of GR is that the fwding plane is still
         working. BFD detects that it is not. Therefore, you do not want
         to announce GR if the assumptions of GR are not met.

     Alia: I like the discussion of the lowest level of the
        control plane attachment to BFD. What I want is the text
        to state that the BFD session down notification should
        take the same action for the other applications.

     Dave: We state that in the SH draft, but in the BFD Generic
         draft we try not to use "BFD failure?" == "L2 down"  Its whether
         or not the text would be confusing. It probably would be as BFD doesn't
         limit itself to L2 only.

     Alia: It seems that if you don't have the text that way
         you could have some odd corner cases.  Something to give
         the philosophy/guidance.

     PekkaS:  Just to clarify that my initial proposal for this
         text was to explicitly take explicit action when the event
         comes in. I have no objections if some objections would like
         to remove it from the routing when the if goes down; might be
         an implementation case.

     Dave: I think we are going to put down the routing case. I see
         your point. We can state that if the static route goes down,
         one SHOULD withdraw the route.

     Q: Where are the drafts?

     Dave: -01 is coming out ASAP.

     Dave: Is there any dissent to make the gen draft a WG doc?

     room: none.

1)Supping preso:
      Dave: anyone to present idea?  I will present slides on BFD init
          with BGP/static routes...

     Dave: Has anyone read the draft.

     PekkaS: Before we have this clarifying discussion. I am a bit
         sympathetic to the first bullet.  From the perspective
         of the operator. This was before the generic draft came out.

     Tom: Do not make a WG document; clarify the existing drafts.

     Richard Spencer: Should we put all applications in this
        draft? Are we going to end up with multiple drafts?
        If there is something to be
        standardized to implement interop. we need to agree
        what. In the static case, we need to configure the src/dst
        points manually. I think if you want to this  draft
        become a WG draft,then we need to say what is missing
        from current drafts.  If there is anything missing, then
        we should incorporate it into existing drafts.

     Dave: I concur. I do not think we need to extend
         BGP, and to clarify what to do in the base documents.
         So the BGP extensions are unnecessary to bring up
         a BFD session, and so the extentions as prescribed
         are not applicable to get the BFD session up. No
         issue to be solved here.  WRT finishing generic
         applicability -- I strongly prefer that we do not
         have a draft for every application. Instead have a
         generic application document that includes these.

     Dave to the Room: are there any WG members that
         want to accept this as a WG draft? None.

     Tom: Ask coauthors to clarify text in
         generic draft if anything is missing?

      Dave: Have already done so.

     PekkaS: Maybe some appendices to explicitly clarify
         popular cases.

     Dave: I know we have used the "appendix out"
         in the past, but I think we will just put it inline into
         the document. As we are going to add the four sentences
         that were requested.

     Dave: Comments/questions? None.  Attempt is to have
         a short LC after documents have been updated.

Adjourn