Subject: Re: I-D ACTION:draft-ietf-bfd-generic-00.txt

From: Suping Zhai <[email-masked]>
Date: Thu, 21 Jul 2005 10:36:48 +0800

Hi Carlos,
I am sympathy with you regarding this generic draft. 
And more I think that it's better if all the BFD related applications including IGP, BGP, MPLS and static routes can go together into one draft.

And another note, in this draft section 2, it reads as followings,
   The service interface with BFD is straightforward.  The application
   supplies session parameters (neighbor address, time parameters,
   protocol options), and BFD provides the session state, of which the
   most interesting transitions are to and from the Up state.  The
   application is expected to bootstrap the BFD session, as BFD has no
   discovery mechanism.

Perhaps, the session paramters of time parameters is the responsiblity of BFD session its self, not supplied by application.

I dont' what's opinions?

Regards,
suping
>Hi,
>
>Reading the generic document, I now have a doubt: shouldn't mentions
>to OSPF and IS-IS in the 1-hop draft go in a separate "IGP application
>document" or "OSPF / ISIS application document"? Most of the content
>is not related to the 1hop functionality but rather with BFD-protocol
>interactions, including Graceful restart.
>
>Or perhaps, as another example in the generic draft?
>
>For example, the Graceful restart mentioned in the 1hop draft, is
>probably applicable to all protocols that have Graceful restart (as
>BGP), not only to IGPs.
>
>I know it is a non negligible amount of editorial work, but will
>probably lay out a clear structure for the BFD standards... that, with
>the count already up to more than four drafts for BFD, may be a good
>thing. (or not, it probably depends).
>
>Regards,
>Carlos.
>
>2005/7/16, [email-masked] <[email-masked]>:
>> Date: Fri, 15 Jul 2005 15:50:02 -0400
>> From: [email-masked]
>> Subject: I-D ACTION:draft-ietf-bfd-generic-00.txt
>> To: [email-masked]
>> Cc: [email-masked]
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.
>> 
>>         Title           : Generic Application of BFD
>>         Author(s)       : D. Katz, D. Ward
>>         Filename        : draft-ietf-bfd-generic-00.txt
>>         Pages           : 7
>>         Date            : 2005-7-15
>> 
>>    This document describes the generic application of the Bidirectional
>>    Forwarding Detection (BFD) protocol in environments not specifically
>>    documented in other specifications.  Comments on this draft should be
>>    directed to [email-masked].
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-00.txt
>> 
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP. Login with the username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>>         "get draft-ietf-bfd-generic-00.txt".
>> 
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

---

From: David Ward <[email-masked]>
Date: Fri, 22 Jul 2005 15:27:17 -0500

All -

We have left the 1-hop (w/ IGP examples) and generic draft as agreed at
the last two WG meetings. There is no real benefit (as discussed) to mentioning
each and every app that could bootstrap a BFD session, we would never 
standardize the doc as new ones are creeping up every day. Since the 
base spec and 1-hop are in LC (again as agreed by the WG), I recommend
we don't reopen this can of worms.

more down below. 

> Perhaps, the session paramters of time parameters is the responsiblity of BFD session its self, not supplied by application.

I don't see how this is possible. BFD checks the forwarding plane created
by other applications. Those applications are requesting from BFD the 
fast notification of a failure. Since BFD doesn't setup the forwarding plane,
it should bootstrap itself. 

-DWard