RE: BFD stability follow-up from IETF-91

"Nobo Akiya (nobo)" <nobo@cisco.com> Thu, 04 December 2014 14:00 UTC

Return-Path: <nobo@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FAB1AD384 for <rtg-bfd@ietfa.amsl.com>; Thu, 4 Dec 2014 06:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.51
X-Spam-Level:
X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9uksxZne-1z for <rtg-bfd@ietfa.amsl.com>; Thu, 4 Dec 2014 06:00:45 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4A31AD3A1 for <rtg-bfd@ietf.org>; Thu, 4 Dec 2014 06:00:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126728; q=dns/txt; s=iport; t=1417701644; x=1418911244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4NZbPLWq9QlH9jjA+1dmWEtw44KOvyqbxT24qAAjalw=; b=FrKPDsnS7mWHZkTDQ3EKS5RSL3SwnbBV+rnoRoQu7SJ5f6E5TAU52Fee 8Uey71dX+eBZZbeDqD5G8dpuzCSJk/2TRbi+8Vy14ObhyuZdDDeQs3AGe A/v1b7ubsyP98NAkrT8hSM+jyOt2335Kw9BCpWINYHQc6T+G4981p+LBm 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIFAHNogFStJA2E/2dsb2JhbABagkMhIlJYBMRmgWqBewGEGgKBGxYBAQEBAX2EAgEBAQMBGgESOgQDCwUHBAIBCBEDAQEBAQoWAQYHIREUCQgCBAENBQgBEogOAwkJAQzQRQ2FXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReOMIIFIAwFBgEGgx6BHgWOBhSBdoQWhEKDFDiCdYNAhWuCNINpg3lvgUWBAAEBAQ
X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="scan'208,217";a="102642689"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 04 Dec 2014 14:00:41 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB4E0fdD021916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 14:00:41 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 08:00:40 -0600
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: Santosh P K <santoshpk@juniper.net>, "MALLIK MUDIGONDA (mmudigon)" <mmudigon@cisco.com>, "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>, Marc Binderberger <marc@sniff.de>, Manav Bhatia <manavbhatia@gmail.com>
Subject: RE: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQCQ6shW/jisJENECZQt8/kBXRdpxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAdjoCAAAsZAIAF49GAgANn8YCAAHj2gIAAlzWAgAAFmYCAAFQ6AIAACIMAgAAA+ACAAADogP//un7w
Date: Thu, 04 Dec 2014 14:00:39 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3943F5AE38D@xmb-aln-x01.cisco.com>
References: <CO2PR0501MB823C222B7D62779F4DF58CDB3780@CO2PR0501MB823.namprd05.prod.outlook.com> <D0A647C1.28843%mmudigon@cisco.com> <CO2PR0501MB8234A1BDDFD008EE12C847AB3780@CO2PR0501MB823.namprd05.prod.outlook.com>
In-Reply-To: <CO2PR0501MB8234A1BDDFD008EE12C847AB3780@CO2PR0501MB823.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.212.136]
Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F5AE38Dxmbalnx01ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/T5G4dkYq_COt1fyg58XgHV2tcO0
X-Mailman-Approved-At: Thu, 04 Dec 2014 06:01:39 -0800
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2014 14:00:53 -0000

A quick question to understand where we are.

If we had:


1.      Standardization of Null Authentication (i.e., sequence numbers)

2.      Implementation of local TX/RX timestamp mechanism described by Marc below

What are the core requirements which have not been satisfied?

Thanks!

-Nobo

P.S. No, there is no need to standardize BFD echo contents.

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Thursday, December 04, 2014 6:52 AM
To: MALLIK MUDIGONDA (mmudigon); Vengada Prasad Govindan (venggovi); Gregory Mirsky; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org
Subject: RE: BFD stability follow-up from IETF-91

Mallaik,
  That's correct and that is why I asked if we really need to define any packet format as Greg suggested?

Thanks
Santosh P K

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Thursday, December 04, 2014 5:19 PM
To: Santosh P K; Vengada Prasad Govindan (venggovi); Gregory Mirsky; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD stability follow-up from IETF-91

Hi Santosh,

With Echo, the receive side is not going to look into the packet. It is just going to send it back and it is the responsibility of the sender to interpret its contents.

Regards
Mallik

From: Santosh P K <santoshpk@juniper.net<mailto:santoshpk@juniper.net>>
Date: Thursday, 4 December 2014 5:15 pm
To: "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com<mailto:venggovi@cisco.com>>, Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>>, Marc Binderberger <marc@sniff.de<mailto:marc@sniff.de>>, Manav Bhatia <manavbhatia@gmail.com<mailto:manavbhatia@gmail.com>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD stability follow-up from IETF-91

Hi Prasad,
  That's right. We echo has limitations but for single hop we can still use it. I was trying to understand even for single hop do we need to define any packet format for echo?

Thanks
Santosh P K

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]
Sent: Thursday, December 04, 2014 4:45 PM
To: Gregory Mirsky; Santosh P K; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91
Hello Greg/ Santosh,
   It was my understanding that BFD Async was chosen for stability since there
are configurations where BFD echo mode is not supported (e.g. Multi-hop,
BFD on LAGs and BFD over MPLS). Am I missing something here, please let
me know.
Thanks
Prasad
-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory
Mirsky
Sent: Thursday, December 04, 2014 11:44 AM
To: Santosh P K; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91
Hi Santosh,
yes, the format and thus interpretation of payload in Echo mode is not
defined and that, in my view, is what we need - some open space. And Echo
well could be exactly that - no legacy, no backward compatibility (addressee
that doesn't support "extended Echo" will simply loop the packet back to
sender). Perhaps that will be direction we can discuss and, hopefully, agree
on.
Regards,
Greg
-----Original Message-----
From: Santosh P K [mailto:santoshpk@juniper.net]
Sent: Wednesday, December 03, 2014 9:54 PM
To: Gregory Mirsky; Marc Binderberger; Manav Bhatia
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91
Greg,
    I don't think we have discussed about echo in this context. Echo is good
thing but payload of BFD echo packet is decided by local system. Did you
mean to add suggestion on how echo packet should look like? Or how echo
can help in BFD loss/delay issue?
Thanks
Santosh P K
> -----Original Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Thursday, December 04, 2014 2:22 AM
> To: Santosh P K; Marc Binderberger; Manav Bhatia
> Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
> Subject: RE: BFD stability follow-up from IETF-91
>
> Dear All,
> had authors of the proposal or we already dismissed use of BFD Echo?
> I've scanned the thread and couldn't find trace of us discussing BFD
> Echo mode. I think that it is more suitable for experimentation and
unorthodox use.
>
> Regards,
> Greg
>
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P
> K
> Sent: Wednesday, December 03, 2014 5:39 AM
> To: Marc Binderberger; Manav Bhatia
> Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
> Subject: RE: BFD stability follow-up from IETF-91
>
> Hello Manav and Marc,
>
>
> > > One way to solve this problem is by attaching a debug trailer that
> > > only carries the seq numbers at the *end* of the BFD packet. This
> > > would not be covered in the Length field carried in the BFD header
> > > but would be accounted for in the length carried in the IP header.
> >
> > BFD itself is not related to IP, i.e. there is not always an IP header.
> > Sure, the encapsulating "frame" may provide a length but actually,
> > why not covering the debug trailer with the BFD length?
> >
> > If this is solely for debug purpose than this may work. For simple
> > copying-out into e.g. a packet trace buffer it would be even simpler
> > to have the BFD length covering the trailer.
> > If hardware is supposed to process the trailer information (other
> > than copying out) then it's getting ugly - having fixed position,
> > fixed length extension headers would be preferable for simple access.
>
> Fixed length would be easy to process in hardware. Problem is when we
> have many have extensions in future. If we want to use only one
> extension that is at the last then I will be forced to pad all the
> other extension ahead of it? This might not be a problem if we have
> fewer extensions but might become problem when there are too many
extensions.
>
>
> >
> > Another idea is to use the 0x80 bit of the auth type to distinguish
> > between a "normal" authentication header and a "sequence +
> authentication".
> >
>
> I think this is good. In the BFD extension TLV we still have many
> reserved bits that can be used as well?
>
> Thanks
> Santosh P K
>
>
>
> >
> > On Thu, 27 Nov 2014 21:12:00 +0530, Manav Bhatia wrote:
> > > Hi Santosh,
> > >
> > > You could use the crypto sequence numbers carried in the
> > > meticulous cryptographic auth for detecting packet losses.
> > > However, this breaks when you use non-meticulous crypto
> > > authentication since the sequence number is only incremented
> > > occasionally there. This i believe is a deal breaker since i
> > > really envision non meticulous mode to be the one being widely
> > > deployed. In fact we were supposed to write a draft on that and i
> > > guess it just fell through the cracks (lemme ping my co-author on
> > > that !)
> > >
> > > One way to solve this problem is by attaching a debug trailer that
> > > only carries the seq numbers at the *end* of the BFD packet. This
> > > would not be covered in the Length field carried in the BFD header
> > > but would be accounted for in the length carried in the IP header.
> > > The concept of attaching a trailer is documented well and is used
> > > in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The
> > > catch however is that this debug trailer will NOT be covered by
> > > the BFD authentication. Is this acceptable to the WG?
> > >
> > > I think the problem of diagnosing a BFD flap becomes all the more
> > > important with BFD authentication turned on since then we have
> > > more points where a delay can be inserted.
> > >
> > > Cheers, Manav
> > >
> > >
> > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K
> > > <santoshpk@juniper.net<mailto:santoshpk@juniper.net>>
> > wrote:
> > >> Manav,
> > >>     This is good question.
> > >>
> > >>> Can the authors add some text on how this debugging mechanism
> > >>> would work if somebody employs BFD authentication?
> > >>
> > >> Right now we have considered without authentication (we are
> > >> setting A bit). We should add some text on how we can use both
> > >> Auth and de bug
> > TLV.
> > >> Is there any suggestion you have? I will get back to you on this.
> > >>
> > >>
> > >> Thanks
> > >> Santosh P K
> > >>
> > >>>> -----Original Message-----
> > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> > >>>> Mach
> > Chen
> > >>>> Sent: Thursday, November 27, 2014 2:13 PM
> > >>>> To: Marc Binderberger
> > >>>> Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
> > >>>> Subject: RE: BFD stability follow-up from IETF-91
> > >>>>
> > >>>> Hi Marc,
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Marc Binderberger [mailto:marc@sniff.de]
> > >>>>> Sent: Thursday, November 27, 2014 1:43 AM
> > >>>>> To: Mach Chen
> > >>>>> Cc: Manav Bhatia; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
> > >>>>> Subject: RE: BFD stability follow-up from IETF-91
> > >>>>>
> > >>>>> Hello Mach,
> > >>>>>
> > >>>>>> This triggers me think out there should be another solution
> > >>>>>> for getting the Tx and Rx timestamps without encoding the
> > >>>>>> timestamps
> > in
> > >>>>>> the BFD
> > >>>>> packets.
> > >>>>>> For example, the Tx and Rx systems could just save timestamps
> > >>>>>> locally or send them to a centralized entity and then use the
> > >>>>>> sequence numbers to correlate them for further analyzing.
> > >>>>>
> > >>>>> I remember some discussion on NVO3 about how many bits it
> > >>>>> takes
> > >>>>> ;-
> > ) -
> > >>>>> could you send the links/draft names you are working on to this
list?
> > >>>>> May be useful for further discussions.
> > >>>>
> > >>>> Sure, here is the
> > >>>> link(http://tools.ietf.org/html/draft-chen-ippm-coloring-
> > >>> based-ipfpm-framework-02) for the reference.
> > >>>>
> > >>>> But here I want to say is that since we have sequence number,
> > >>>> we may
> > not
> > >>> need the marking based solution. Suppose that someone want to
> > monitor
> > >>> the delay of a BFD packet , just record and save the timestamp
> > >>> at the Tx side, which indexed by the sequence number. Similarly,
> > >>> do the same at the Rx side. Then based on the timestamps from
> > >>> both Tx and Rx, and using the sequence number to correlate the
> > >>> timestamps, it can also provide a way
> > to
> > >>> monitor the delay of the BFD packet.
> > >>>>
> > >>>> That means, only if there is sequence number, even if without
> > >>>> carrying the
> > >>> timestamp in the BFD packet, BFD packet delay can be measured.
> > >>>>
> > >>>> Best regards,
> > >>>> Mach
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> Thanks & Regards,
> > >>>>> Marc
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote:
> > >>>>>> Hi Marc and Manav,
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> > Marc
> > >>>>>>> Binderberger
> > >>>>>>> Sent: Wednesday, November 26, 2014 4:50 PM
> > >>>>>>> To: Manav Bhatia
> > >>>>>>> Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
> > >>>>>>> Subject: Re: BFD stability follow-up from IETF-91
> > >>>>>>>
> > >>>>>>> Hello Manav,
> > >>>>>>>
> > >>>>>>>> I believe the work is important and addresses something
> > >>>>>>>> thats really required (spent too much time debugging why
> > >>>>>>>> BFD
> > flapped!).
> > >>>>>>>
> > >>>>>>> agree :-) we should keep the discussion alive.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> side Time stamping would have helped in debugging whether
> the
> > >>> BFD
> > >>>>>>>> packet was sent late, or whether the packet was sent on
> > >>>>>>>> time and also arrived on time but was delayed when passing
> > >>>>>>>> it up the BFD stack/processor (lay in the RX buffer for tad
> > >>>>>>>> too
> > >>>>>>>> long)
> > >>>>>>>
> > >>>>>>> well, I can see a point in having the Tx timestamps in the
> > >>>>>>> packet mainly for the purpose of knowing "this" packet was
> > >>>>>>> okay/not okay on the Tx side and to correlate it with your
> > >>>>>>> local Rx
> measurement.
> > >>>>>>
> > >>>>>> Yes, this is one solution if people think BFD delay is needed.
> > >>>>>> If allow to have Tx timestamps to be carried in the packets,
> > >>>>>> seems it should be no problem to leave a seat for the Rx
> > >>>>>> timestamps as well :-). After all, with both Tx and Rx
> > >>>>>> timestamp, it may simplify the
> > >>>>> implementation.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> And even this point is less relevant with sequence numbers
> > >>>>>>> as this number allows the identification of packets and thus
> > >>>>>>> the correlation of information from the Tx and Rx system.
> > >>>>>>
> > >>>>>> Indeed, the sequence number helps a lot for the correlation
> > between
> > >>>>>> the Tx and Rx system.
> > >>>>>>
> > >>>>>> This triggers me think out there should be another solution
> > >>>>>> for getting the Tx and Rx timestamps without encoding the
> > >>>>>> timestamps
> > in
> > >>>>>> the BFD
> > >>>>> packets.
> > >>>>>> For example, the Tx and Rx systems could just save timestamps
> > >>>>>> locally or send them to a centralized entity and then use the
> > >>>>>> sequence numbers to correlate them for further analyzing.
> > >>>>>>
> > >>>>>> Best regards,
> > >>>>>> Mach
> > >>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Regards, Marc
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote:
> > >>>>>>>> Hi Jeff,
> > >>>>>>>>
> > >>>>>>>> I vividly remember the original intent of the stability
> > >>>>>>>> draft was to help debug BFD failures -- to isolate the
> > >>>>>>>> issue at the RX or the TX side Time stamping would have
> > >>>>>>>> helped in debugging
> > whether
> > >>>>>>>> the BFD packet was sent late, or whether the packet was
> > >>>>>>>> sent on time and also arrived on time but was delayed when
> > >>>>>>>> passing it up the BFD stack/processor (lay in the RX buffer
> > >>>>>>>> for tad too long), etc. But then time stamping came with
> > >>>>>>>> its own set of issues, and was hence dropped from the original
draft.
> > >>>>>>>>
> > >>>>>>>> Can the authors send a summary on the list on why time
> > >>>>>>>> stamping was dropped so that we're all clear on that one.
> > >>>>>>>>
> > >>>>>>>> The current proposal does help but is not complete.
> > >>>>>>>>
> > >>>>>>>> Assume that the RX end loses a BFD session and learns later
> > >>>>>>>> that it did eventually receive the missing BFD packets
> > >>>>>>>> (based on the
> > seq
> > >>> #).
> > >>>>>>>> How would it know which end was misbehaving? Was it a
delay
> > >>>>>>>> at the TX side, or was it the RX that delayed passing the
> > >>>>>>>> packets to the BFD process(or). This is usually what we
> > >>>>>>>> want to debug and i want to understand how this draft with
> > >>>>>>>> sequence numbers can unequivocally tell me that.
> > >>>>>>>>
> > >>>>>>>> I believe the work is important and addresses something
> > >>>>>>>> thats really required (spent too much time debugging why
> > >>>>>>>> BFD
> > flapped!).
> > >>>>>>>> Clearly what would help is putting a small section that
> > >>>>>>>> describes how we can use the sequence numbers to debug
> what
> > >>>>>>>> and
> > where
> > >>> things went wrong.
> > >>>>>>>>
> > >>>>>>>> Cheers, Manav
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas
> > >>>>>>>> <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
> > >>> wrote:
> > >>>>>>>>> draft-ashesh-bfd-stability-01 was presented again during
> > >>>>>>>>> IETF-91 in Honolulu.  The slides can be viewed here:
> > >>>>>>>>>
> > >>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.
> > >>>>>>>>> pp
> > >>>>>>>>> tx
> > >>>>>>>>>
> > >>>>>>>>> To attempt to simplify the presentation, the contentious
> > >>>>>>>>> portion of the timers were removed from the proposal,
> > >>>>>>>>> leaving only the sequence numbering for detecting loss of
> > >>>>>>>>> BFD
> async packets.
> > >>>>>>>>>
> > >>>>>>>>> When the room was polled to see whether the draft should
> > >>>>>>>>> be adopted as a WG item, the sense of the room was very
quiet.
> > >>>>>>>>> As promised, this is to inquire for support for this draft
> > >>>>>>>>> on the WG mailing list to make sure the whole group has a
> voice.
> > >>>>>>>>>
> > >>>>>>>>> It should be noted that post-meeting discussion on the
> > >>>>>>>>> fate of this draft noted that BFD authentication code
> > >>>>>>>>> points are plentiful and are available with expert review.
> > >>>>>>>>> Should the draft authors wish to continue this work as
> > >>>>>>>>> Experimental, that is
> > an
> > >>> option.
> > >>>>>>>>>
> > >>>>>>>>> -- Jeff
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > >