From dkatz@juniper.net Tue Mar 2 16:23:11 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D29A28C1E6 for ; Tue, 2 Mar 2010 16:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVaZKjhH1oLu for ; Tue, 2 Mar 2010 16:23:09 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 4561B28C1B2 for ; Tue, 2 Mar 2010 16:23:03 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS42r5GlVlHp45c7Ch1n3HCmZnxQYKNOO@postini.com; Tue, 02 Mar 2010 16:23:05 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Tue, 2 Mar 2010 16:21:28 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:21:28 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:21:28 -0800 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:21:27 -0800 Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o230LRb46092; Tue, 2 Mar 2010 16:21:27 -0800 (PST) (envelope-from dkatz@juniper.net) Message-ID: <41EF2177-5EA7-4469-AFAC-9E075E5299F6@juniper.net> From: Dave Katz To: In-Reply-To: Content-Type: multipart/alternative; boundary="Apple-Mail-1--641805613" MIME-Version: 1.0 (Apple Message framework v936) Subject: Re: New draft notification: draft-dz-bfd-extensions-for-vl-packets-00 Date: Tue, 2 Mar 2010 16:21:26 -0800 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Mar 2010 00:21:27.0712 (UTC) FILETIME=[772A0200:01CABA67] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 00:23:11 -0000 --Apple-Mail-1--641805613 Content-Type: text/plain; charset="GB2312"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable I'll have to examine the proposal carefully, but my first reaction is =20= that you can do most of this today without changing the protocol, by =20 simply padding the packets in which BFD is carried, without changing =20 the BFD header (or the receiving implementation) at all, since the =20 spec only requires that the BFD packet fit inside of whatever it is =20 being carried within (UDP, typically). For that matter, the spec =20 would allow the BFD packet itself to be padded (since only the lower =20 bound of packet length is supposed to be checked) but that would be =20 more likely to run afoul of out-of-spec implementations. It wouldn't be fancy or negotiated, but it would work today without =20 changing existing implementations. A clever implementor might match the packet length of received packets =20= in order to drive the extension in both directions, though that scheme =20= would be asymmetric (one side has to decide to raise its packet size, =20= and the other to reflect it). The proposal seems like overkill for the purpose, but I'd be =20 interested to see what others have to say. --Dave On Feb 28, 2010, at 7:46 PM, dai.xuehui@zte.com.cn wrote: > > Hi all, > > I have submitted a new draft on BFD extensions, the draft's link is: = http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt > > This document extends BFD mechanism to support detection function =20 > for packets with variable lengths. Through dynamically changing =20 > the length of BFD packets, > it can detect both traditional faults such as link failure or route =20= > fault, as well as non-forwarding problem for packets with a length =20 > in a special range, > which maybe caused by equipment's internal defects. > > Any comments and suggestions are welcomed! > > Regards > Dai > > > > Best Regards. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC= =C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1 --Apple-Mail-1--641805613 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable I'll have to examine the = proposal carefully, but my first reaction is that you can do most of = this today without changing the protocol, by simply padding the packets = in which BFD is carried, without changing the BFD header (or the = receiving implementation) at all, since the spec only requires that the = BFD packet fit inside of whatever it is being carried within (UDP, = typically).  For that matter, the spec would allow the BFD packet = itself to be padded (since only the lower bound of packet length is = supposed to be checked) but that would be more likely to run afoul of = out-of-spec implementations.

It wouldn't be fancy or = negotiated, but it would work today without changing existing = implementations.

A clever implementor might = match the packet length of received packets in order to drive the = extension in both directions, though that scheme would be asymmetric = (one side has to decide to raise its packet size, and the other to = reflect it).

The proposal seems like overkill = for the purpose, but I'd be interested to see what others have to = say.

--Dave


On Feb 28, 2010, at 7:46 PM, dai.xuehui@zte.com.cn = wrote:


Hi = all,

I have submitted a new draft on BFD = extensions, the draft's link is: http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.t= xt

This document = extends BFD mechanism to support detection function for  packets = with variable lengths.  Through dynamically changing the length of = BFD packets,
it can detect both = traditional faults such as link failure or route fault, as well as = non-forwarding problem for packets with a length in a special range, =
which maybe caused by equipment's = internal defects.
Any comments and = suggestions are welcomed!

Regards
Dai

=

Best Regards.
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= =D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC=C9= =ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1

= --Apple-Mail-1--641805613-- From root@core3.amsl.com Thu Mar 4 08:15:01 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A056728C1D5; Thu, 4 Mar 2010 08:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-mib-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100304161501.A056728C1D5@core3.amsl.com> Date: Thu, 4 Mar 2010 08:15:01 -0800 (PST) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:15:01 -0000 --NextPart 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 : BFD Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-bfd-mib-08.txt Pages : 34 Date : 2010-03-04 This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-bfd-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-04080823.I-D@ietf.org> --NextPart-- From vishwas.ietf@gmail.com Thu Mar 4 08:19:55 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962F63A8AEE for ; Thu, 4 Mar 2010 08:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8AXaGzL6NFk for ; Thu, 4 Mar 2010 08:19:52 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 3F0113A8ABD for ; Thu, 4 Mar 2010 08:19:52 -0800 (PST) Received: by gyc15 with SMTP id 15so1510403gyc.31 for ; Thu, 04 Mar 2010 08:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=fBGvLr93JUfLpoGdLYR0Yq02C2eNbDKUsHMLixrA1n8=; b=qQ1JD5SpkHLcNbVHxHyReegsr1qCtdqqTWpLyBAtnHXXLEFhNJGpJ0eVkywewFilxI qUdnzivDbvq/FrQNreyvluYElrSMDNqSv1hwIKbboTqIffwEXiw/umHixLbCplMR6t8A mlE0yEMuMtPhSaL2W3qpdafD8lh/sY57/ZXwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RuNGT5CxbUX8pUqtrPWblYD4m2hPINvRifR8wUxv8mg8JVZaSKRABTm01BABOgotXV KOdCVUxOUsvVTLH4QMAPfkWlUv9hsBMQnJ+1/3m5D+v2gM8bgZ89eAIDjrL4o2LCqnou Sa56C/VygRFYLpY+JCb7xar33/7RabjPiLAyo= MIME-Version: 1.0 Received: by 10.150.176.6 with SMTP id y6mr2622376ybe.280.1267719589020; Thu, 04 Mar 2010 08:19:49 -0800 (PST) In-Reply-To: <20100304161501.A056728C1D5@core3.amsl.com> References: <20100304161501.A056728C1D5@core3.amsl.com> Date: Thu, 4 Mar 2010 08:19:48 -0800 Message-ID: <77ead0ec1003040819w25a465b2qe99dba75af30a1c9@mail.gmail.com> Subject: Re: I-D Action:draft-ietf-bfd-mib-08.txt From: Vishwas Manral To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=000e0cd761d8c7437e0480fbf738 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:19:55 -0000 --000e0cd761d8c7437e0480fbf738 Content-Type: text/plain; charset=ISO-8859-1 Hi, Does this draft take into consideration the comments on the list? What are the changes since the last version? Thanks, Vishwas On Thu, Mar 4, 2010 at 8:15 AM, wrote: > 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 : BFD Management Information Base > Author(s) : T. Nadeau, et al. > Filename : draft-ietf-bfd-mib-08.txt > Pages : 34 > Date : 2010-03-04 > > This draft defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes managed objects for modeling > Bidirectional Forwarding Detection (BFD) protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > --000e0cd761d8c7437e0480fbf738 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
Does this draft take into consideration the comments on the list?
=A0
What are the changes since the last version?
=A0
Thanks,
Vishwas
On Thu, Mar 4, 2010 at 8:15 AM, <Internet-Drafts@ietf.org<= /a>> wrote:
A New Internet-Draft is availabl= e from the on-line Internet-Drafts directories.
This draft is a work ite= m of the Bidirectional Forwarding Detection Working Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : BFD Management Informati= on Base
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Nadeau, et al.
=A0 = =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-bfd-mib-08.txt
=A0 =A0 = =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 34
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 = =A0 =A0 =A0: 2010-03-04

This draft defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community.
I= n particular, it describes managed objects for modeling
Bidirectional Fo= rwarding Detection (BFD) protocol.

A URL for this Internet-Draft is:
http://www.ietf.o= rg/internet-drafts/draft-ietf-bfd-mib-08.txt

Internet-Drafts are= also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a= MIME compliant mail reader
implementation to automatically retrieve the= ASCII version of the
Internet-Draft.



--000e0cd761d8c7437e0480fbf738-- From tnadeau@lucidvision.com Thu Mar 4 12:23:55 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B603A8C7E for ; Thu, 4 Mar 2010 12:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwe-1RapOlFM for ; Thu, 4 Mar 2010 12:23:54 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 0BB603A8DF2 for ; Thu, 4 Mar 2010 12:23:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id A7E0D226F01; Thu, 4 Mar 2010 15:23:55 -0500 (EST) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0pVtxeHr4nb; Thu, 4 Mar 2010 15:23:54 -0500 (EST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 9B793226EF0; Thu, 4 Mar 2010 15:23:54 -0500 (EST) Subject: Re: I-D Action:draft-ietf-bfd-mib-08.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-6--483258334 From: Thomas Nadeau In-Reply-To: <77ead0ec1003040819w25a465b2qe99dba75af30a1c9@mail.gmail.com> Date: Thu, 4 Mar 2010 15:23:54 -0500 Message-Id: <43AE1BF0-C74F-4521-A233-4CF40C2616FB@lucidvision.com> References: <20100304161501.A056728C1D5@core3.amsl.com> <77ead0ec1003040819w25a465b2qe99dba75af30a1c9@mail.gmail.com> To: Vishwas Manral X-Mailer: Apple Mail (2.1077) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:23:56 -0000 --Apple-Mail-6--483258334 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Hi, > =20 > Does this draft take into consideration the comments on the list? Yes, we think so. That doesn't mean we've not missed any though, = so please review it. > What are the changes since the last version? Heard of diff? *) http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-07.txt --Tom > =20 > Thanks, > Vishwas > On Thu, Mar 4, 2010 at 8:15 AM, wrote: > 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. >=20 >=20 > Title : BFD Management Information Base > Author(s) : T. Nadeau, et al. > Filename : draft-ietf-bfd-mib-08.txt > Pages : 34 > Date : 2010-03-04 >=20 > This draft defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes managed objects for modeling > Bidirectional Forwarding Detection (BFD) protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-08.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 >=20 --Apple-Mail-6--483258334 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Hi,
 
Does this draft take into consideration the comments on the list?

Yes, we think so. That doesn't mean we've not missed any though, so please review it.

 What are the changes since the last version?

Heard of diff?  *)


--Tom




 
Thanks,
Vishwas
On Thu, Mar 4, 2010 at 8:15 AM, <Internet-Drafts@ietf.org> wrote:
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           : BFD Management Information Base
       Author(s)       : T. Nadeau, et al.
       Filename        : draft-ietf-bfd-mib-08.txt
       Pages           : 34
       Date            : 2010-03-04

This draft defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling
Bidirectional Forwarding Detection (BFD) protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.




--Apple-Mail-6--483258334-- From root@core3.amsl.com Mon Mar 8 00:15:02 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 39A483A67A3; Mon, 8 Mar 2010 00:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-mib-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308081502.39A483A67A3@core3.amsl.com> Date: Mon, 8 Mar 2010 00:15:02 -0800 (PST) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:15:02 -0000 --NextPart 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 : BFD Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-bfd-mib-09.txt Pages : 34 Date : 2010-03-08 This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-bfd-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08000139.I-D@ietf.org> --NextPart-- From dai.xuehui@zte.com.cn Wed Mar 10 18:12:26 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1453A6ACC for ; Wed, 10 Mar 2010 18:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.983 X-Spam-Level: X-Spam-Status: No, score=-92.983 tagged_above=-999 required=5 tests=[AWL=-2.052, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAPV+bimsdez for ; Wed, 10 Mar 2010 18:12:24 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id F35633A6AAB for ; Wed, 10 Mar 2010 18:12:21 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 469076853516; Thu, 11 Mar 2010 09:42:48 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.984503890; Thu, 11 Mar 2010 10:12:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2B2CHNa076767; Thu, 11 Mar 2010 10:12:17 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) In-Reply-To: <41EF2177-5EA7-4469-AFAC-9E075E5299F6@juniper.net> To: Dave Katz Subject: =?GB2312?B?tPC4tDogUmU6IE5ldyBkcmFmdCBub3RpZmljYXRpb246IA==?= =?GB2312?B?ZHJhZnQtZHotYmZkLWV4dGVuc2lvbnMtZm9yLXZsLXBhY2tldHMtMDA=?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: dai.xuehui@zte.com.cn Date: Thu, 11 Mar 2010 10:10:40 +0800 X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-11 10:16:19, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-11 10:16:19, Serialize complete at 2010-03-11 10:16:19, S/MIME Sign failed at 2010-03-11 10:16:19: =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-11 10:12:14, Serialize complete at 2010-03-11 10:12:14 Content-Type: multipart/alternative; boundary="=_alternative 000C7B2B482576E3_=" X-MAIL: mse2.zte.com.cn o2B2CHNa076767 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 02:12:26 -0000 This is a multipart message in MIME format. --=_alternative 000C7B2B482576E3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGF2ZSwNCg0KICAgICBUaGFua3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UsIGFuZCB5b3Ug YXJlIHJpZ2h0LiBCdXQgdGhlIGV4c2l0aW5nIA0KQkZEIGNhbid0IG1lZXQgb3VyIHJlcXVpcmVt ZW50cyB0byByZXNvbHZlIHN1Y2ggbm9uLWZvcndhcmRpbmcgcHJvYmxlbSwgDQpzaW5jZSBCRkQn cyAgZmxleGliaWxpdHkgaXMgbm90IHNvIGdvb2QuDQoNCnNvIHdlIG1ha2Ugc29tZSBjaGFuZ2Vz IGluIEJGRCBoZWFkZXIgdG8gc3VwcG9ydCBuZWdvdGlhdGlvbiBmb3IgDQp2YXJpYWJsZS1sZW5n dGggZGV0ZWN0aW9uIHBhcmFtZXRlcnMuIFRocm91Z2ggdGhpcyBuZWdvdGlhdGlvbiwgYXN5bW1l dHJpYyANCmNvbmRpdGlvbiB0aGF0IHlvdSBtZW50aW9uZWQgY2FuIGJlIGF2b2lkZWSjrCANCg0K aW4gYWRkaXRpb24sICB3ZSBjYW4gb2J0YWluIHRoZSBsZW5ndGggaW50ZXJ2YWwgZHVyaW5nIHdo aWNoIHRoZSBmYXVsdCANCm9jY3VyZWQgbW9yZSBhY2N1cmF0ZWx5Lg0KDQpXaXNoIGZ1cnRoZXIg Y29tbWVudHMgZnJvbSB5b3UgYW5kIGFsbCBvdGhlcnMuDQoNCkJSLg0KDQpYdWVodWkNCg0KDQoN Cg0KDQpCZXN0IFJlZ2FyZHMuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQrXo8T60MK0utPkv+yjrLmk1/fLs8D7o6zJ7czlvaG/taOs49i80ru2wNajoQ0KDQoN Cg0KRGF2ZSBLYXR6IDxka2F0ekBqdW5pcGVyLm5ldD4gDQoyMDEwLTAzLTAzIDA4OjIxDQoNCsrV vP7Iyw0KPGRhaS54dWVodWlAenRlLmNvbS5jbj4NCrOty80NCnJ0Zy1iZmRAaWV0Zi5vcmcNCtb3 zOINClJlOiBOZXcgZHJhZnQgbm90aWZpY2F0aW9uOiBkcmFmdC1kei1iZmQtZXh0ZW5zaW9ucy1m b3ItdmwtcGFja2V0cy0wMA0KDQoNCg0KDQoNCg0KSSdsbCBoYXZlIHRvIGV4YW1pbmUgdGhlIHBy b3Bvc2FsIGNhcmVmdWxseSwgYnV0IG15IGZpcnN0IHJlYWN0aW9uIGlzIHRoYXQgDQp5b3UgY2Fu IGRvIG1vc3Qgb2YgdGhpcyB0b2RheSB3aXRob3V0IGNoYW5naW5nIHRoZSBwcm90b2NvbCwgYnkg c2ltcGx5IA0KcGFkZGluZyB0aGUgcGFja2V0cyBpbiB3aGljaCBCRkQgaXMgY2FycmllZCwgd2l0 aG91dCBjaGFuZ2luZyB0aGUgQkZEIA0KaGVhZGVyIChvciB0aGUgcmVjZWl2aW5nIGltcGxlbWVu dGF0aW9uKSBhdCBhbGwsIHNpbmNlIHRoZSBzcGVjIG9ubHkgDQpyZXF1aXJlcyB0aGF0IHRoZSBC RkQgcGFja2V0IGZpdCBpbnNpZGUgb2Ygd2hhdGV2ZXIgaXQgaXMgYmVpbmcgY2FycmllZCANCndp dGhpbiAoVURQLCB0eXBpY2FsbHkpLiAgRm9yIHRoYXQgbWF0dGVyLCB0aGUgc3BlYyB3b3VsZCBh bGxvdyB0aGUgQkZEIA0KcGFja2V0IGl0c2VsZiB0byBiZSBwYWRkZWQgKHNpbmNlIG9ubHkgdGhl IGxvd2VyIGJvdW5kIG9mIHBhY2tldCBsZW5ndGggaXMgDQpzdXBwb3NlZCB0byBiZSBjaGVja2Vk KSBidXQgdGhhdCB3b3VsZCBiZSBtb3JlIGxpa2VseSB0byBydW4gYWZvdWwgb2YgDQpvdXQtb2Yt c3BlYyBpbXBsZW1lbnRhdGlvbnMuDQoNCkl0IHdvdWxkbid0IGJlIGZhbmN5IG9yIG5lZ290aWF0 ZWQsIGJ1dCBpdCB3b3VsZCB3b3JrIHRvZGF5IHdpdGhvdXQgDQpjaGFuZ2luZyBleGlzdGluZyBp bXBsZW1lbnRhdGlvbnMuDQoNCkEgY2xldmVyIGltcGxlbWVudG9yIG1pZ2h0IG1hdGNoIHRoZSBw YWNrZXQgbGVuZ3RoIG9mIHJlY2VpdmVkIHBhY2tldHMgaW4gDQpvcmRlciB0byBkcml2ZSB0aGUg ZXh0ZW5zaW9uIGluIGJvdGggZGlyZWN0aW9ucywgdGhvdWdoIHRoYXQgc2NoZW1lIHdvdWxkIA0K YmUgYXN5bW1ldHJpYyAob25lIHNpZGUgaGFzIHRvIGRlY2lkZSB0byByYWlzZSBpdHMgcGFja2V0 IHNpemUsIGFuZCB0aGUgDQpvdGhlciB0byByZWZsZWN0IGl0KS4NCg0KVGhlIHByb3Bvc2FsIHNl ZW1zIGxpa2Ugb3ZlcmtpbGwgZm9yIHRoZSBwdXJwb3NlLCBidXQgSSdkIGJlIGludGVyZXN0ZWQg dG8gDQpzZWUgd2hhdCBvdGhlcnMgaGF2ZSB0byBzYXkuDQoNCi0tRGF2ZQ0KDQoNCk9uIEZlYiAy OCwgMjAxMCwgYXQgNzo0NiBQTSwgZGFpLnh1ZWh1aUB6dGUuY29tLmNuIHdyb3RlOg0KDQoNCkhp IGFsbCwgDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgb24gQkZEIGV4dGVuc2lvbnMs IHRoZSBkcmFmdCdzIGxpbmsgaXM6IA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWR6 LWJmZC1leHRlbnNpb25zLWZvci12bC1wYWNrZXRzLTAwLnR4dA0KDQpUaGlzIGRvY3VtZW50IGV4 dGVuZHMgQkZEIG1lY2hhbmlzbSB0byBzdXBwb3J0IGRldGVjdGlvbiBmdW5jdGlvbiBmb3IgDQpw YWNrZXRzIHdpdGggdmFyaWFibGUgbGVuZ3Rocy4gIFRocm91Z2ggZHluYW1pY2FsbHkgY2hhbmdp bmcgdGhlIGxlbmd0aCBvZiANCkJGRCBwYWNrZXRzLCANCml0IGNhbiBkZXRlY3QgYm90aCB0cmFk aXRpb25hbCBmYXVsdHMgc3VjaCBhcyBsaW5rIGZhaWx1cmUgb3Igcm91dGUgZmF1bHQsIA0KYXMg d2VsbCBhcyBub24tZm9yd2FyZGluZyBwcm9ibGVtIGZvciBwYWNrZXRzIHdpdGggYSBsZW5ndGgg aW4gYSBzcGVjaWFsIA0KcmFuZ2UsIA0Kd2hpY2ggbWF5YmUgY2F1c2VkIGJ5IGVxdWlwbWVudCdz IGludGVybmFsIGRlZmVjdHMuDQoNCkFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdl bGNvbWVkISANCg0KUmVnYXJkcyANCkRhaSANCg0KDQoNCkJlc3QgUmVnYXJkcy4NCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCtejxPrQwrS60+S/7KOsuaTX98uz wPujrMntzOW9ob+1o6zj2LzSu7bA1qOhDQoNCg0K --=_alternative 000C7B2B482576E3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERhdmUsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw O1RoYW5rcyBmb3IgeW91cg0KcXVpY2sgcmVzcG9uc2UsIGFuZCB5b3UgYXJlIHJpZ2h0LiBCdXQg dGhlIGV4c2l0aW5nIEJGRCBjYW4ndCBtZWV0IG91cg0KcmVxdWlyZW1lbnRzIHRvIHJlc29sdmUg c3VjaCBub24tZm9yd2FyZGluZyBwcm9ibGVtLCBzaW5jZSBCRkQncyAmbmJzcDtmbGV4aWJpbGl0 eQ0KaXMgbm90IHNvIGdvb2QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5zbyB3ZSBtYWtlIHNvbWUgY2hhbmdlcyBpbiBCRkQgaGVhZGVyDQp0byBzdXBw b3J0IG5lZ290aWF0aW9uIGZvciB2YXJpYWJsZS1sZW5ndGggZGV0ZWN0aW9uIHBhcmFtZXRlcnMu IFRocm91Z2gNCnRoaXMgbmVnb3RpYXRpb24sIGFzeW1tZXRyaWMgY29uZGl0aW9uIHRoYXQgeW91 IG1lbnRpb25lZCBjYW4gYmUgYXZvaWRlZKOsDQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmluIGFkZGl0aW9uLCAmbmJzcDt3ZSBjYW4gb2J0YWluIHRo ZQ0KbGVuZ3RoIGludGVydmFsIGR1cmluZyB3aGljaCB0aGUgZmF1bHQgb2NjdXJlZCBtb3JlIGFj Y3VyYXRlbHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5XaXNoIGZ1cnRoZXIgY29tbWVudHMgZnJvbSB5b3UgYW5kIGFsbA0Kb3RoZXJzLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlIuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5YdWVodWk8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkJlc3QgUmVnYXJkcy48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PGJyPg0K16PE+tDCtLrT5L/so6y5pNf3y7PA+6Osye3M5b2hv7WjrOPYvNK7tsDW o6E8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ RGF2ZSBLYXR6ICZsdDtka2F0ekBqdW5pcGVyLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wMy0wMyAwODoyMTwvZm9udD4NCjx0ZCB3 aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7ZGFpLnh1ZWh1 aUB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+cnRnLWJmZEBpZXRmLm9yZzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+UmU6IE5ldyBkcmFmdCBub3RpZmljYXRpb246IGRyYWZ0LWR6LWJmZC1l eHRlbnNpb25zLWZvci12bC1wYWNrZXRzLTAwPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkknbGwgaGF2ZSB0byBl eGFtaW5lIHRoZSBwcm9wb3NhbCBjYXJlZnVsbHksDQpidXQgbXkgZmlyc3QgcmVhY3Rpb24gaXMg dGhhdCB5b3UgY2FuIGRvIG1vc3Qgb2YgdGhpcyB0b2RheSB3aXRob3V0IGNoYW5naW5nDQp0aGUg cHJvdG9jb2wsIGJ5IHNpbXBseSBwYWRkaW5nIHRoZSBwYWNrZXRzIGluIHdoaWNoIEJGRCBpcyBj YXJyaWVkLCB3aXRob3V0DQpjaGFuZ2luZyB0aGUgQkZEIGhlYWRlciAob3IgdGhlIHJlY2Vpdmlu ZyBpbXBsZW1lbnRhdGlvbikgYXQgYWxsLCBzaW5jZQ0KdGhlIHNwZWMgb25seSByZXF1aXJlcyB0 aGF0IHRoZSBCRkQgcGFja2V0IGZpdCBpbnNpZGUgb2Ygd2hhdGV2ZXIgaXQgaXMNCmJlaW5nIGNh cnJpZWQgd2l0aGluIChVRFAsIHR5cGljYWxseSkuICZuYnNwO0ZvciB0aGF0IG1hdHRlciwgdGhl IHNwZWMNCndvdWxkIGFsbG93IHRoZSBCRkQgcGFja2V0IGl0c2VsZiB0byBiZSBwYWRkZWQgKHNp bmNlIG9ubHkgdGhlIGxvd2VyIGJvdW5kDQpvZiBwYWNrZXQgbGVuZ3RoIGlzIHN1cHBvc2VkIHRv IGJlIGNoZWNrZWQpIGJ1dCB0aGF0IHdvdWxkIGJlIG1vcmUgbGlrZWx5DQp0byBydW4gYWZvdWwg b2Ygb3V0LW9mLXNwZWMgaW1wbGVtZW50YXRpb25zLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SXQgd291bGRuJ3QgYmUgZmFuY3kgb3IgbmVnb3RpYXRl ZCwNCmJ1dCBpdCB3b3VsZCB3b3JrIHRvZGF5IHdpdGhvdXQgY2hhbmdpbmcgZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+QSBjbGV2ZXIgaW1wbGVtZW50b3IgbWlnaHQgbWF0Y2ggdGhlDQpwYWNrZXQgbGVuZ3Ro IG9mIHJlY2VpdmVkIHBhY2tldHMgaW4gb3JkZXIgdG8gZHJpdmUgdGhlIGV4dGVuc2lvbiBpbiBi b3RoDQpkaXJlY3Rpb25zLCB0aG91Z2ggdGhhdCBzY2hlbWUgd291bGQgYmUgYXN5bW1ldHJpYyAo b25lIHNpZGUgaGFzIHRvIGRlY2lkZQ0KdG8gcmFpc2UgaXRzIHBhY2tldCBzaXplLCBhbmQgdGhl IG90aGVyIHRvIHJlZmxlY3QgaXQpLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+VGhlIHByb3Bvc2FsIHNlZW1zIGxpa2Ugb3ZlcmtpbGwgZm9yDQp0aGUg cHVycG9zZSwgYnV0IEknZCBiZSBpbnRlcmVzdGVkIHRvIHNlZSB3aGF0IG90aGVycyBoYXZlIHRv IHNheS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi0t RGF2ZTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+T24gRmViIDI4LCAyMDEwLCBhdCA3OjQ2IFBNLCA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGFp Lnh1ZWh1aUB6dGUuY29tLmNuPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PmRhaS54dWVodWlAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCndyb3RlOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSGkgYWxsLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PGJyPg0KSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBvbiBCRkQgZXh0ZW5zaW9uczwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+LA0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj50aGUgZHJhZnQncyBsaW5rIGlzOiA8L2ZvbnQ+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWR6LWJmZC1leHRlbnNpb25zLWZvci12bC1wYWNr ZXRzLTAwLnR4dCI+PGZvbnQgc2l6ZT00IGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZHotYmZkLWV4dGVuc2lvbnMtZm9y LXZsLXBhY2tldHMtMDAudHh0PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NClRoaXMgZG9jdW1lbnQg ZXh0ZW5kcyBCRkQgbWVjaGFuaXNtIHRvIHN1cHBvcnQgZGV0ZWN0aW9uIGZ1bmN0aW9uIGZvciAm bmJzcDtwYWNrZXRzDQp3aXRoIHZhcmlhYmxlIGxlbmd0aHMuICZuYnNwO1Rocm91Z2ggZHluYW1p Y2FsbHkgY2hhbmdpbmcgdGhlIGxlbmd0aCBvZg0KQkZEIHBhY2tldHMsIDxicj4NCml0IGNhbiBk ZXRlY3QgYm90aCB0cmFkaXRpb25hbCBmYXVsdHMgc3VjaCBhcyBsaW5rIGZhaWx1cmUgb3Igcm91 dGUgZmF1bHQsDQphcyB3ZWxsIGFzIG5vbi1mb3J3YXJkaW5nIHByb2JsZW0gZm9yIHBhY2tldHMg d2l0aCBhIGxlbmd0aCBpbiBhIHNwZWNpYWwNCnJhbmdlLCA8YnI+DQp3aGljaCBtYXliZSBjYXVz ZWQgYnkgZXF1aXBtZW50J3MgaW50ZXJuYWwgZGVmZWN0cy48YnI+DQo8YnI+DQpBbnkgY29tbWVu dHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lZCE8L3R0PjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpS ZWdhcmRzPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpEYWk8L3R0PjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KQmVzdCBSZWdhcmRzLjxicj4NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQrXo8T60MK0utPkv+yjrLmk1/fLs8D7o6zJ7czl vaG/taOs49i80ru2wNajoTwvZm9udD4NCjxicj4NCjxicj4NCg== --=_alternative 000C7B2B482576E3_=-- From mahesh.akula@wipro.com Thu Mar 11 04:30:10 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67103A68AB for ; Thu, 11 Mar 2010 04:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX0mD3-jz7xw for ; Thu, 11 Mar 2010 04:30:10 -0800 (PST) Received: from wipro-blr-out02.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 69CA03A6905 for ; Thu, 11 Mar 2010 04:29:55 -0800 (PST) X-AuditID: cb5bdd58-b7bf7ae000006db3-33-4b98e24626f5 Received: from blr-ec-aa03.wipro.com ( [10.201.18.42]) by wipro-blr-out02.wipro.com (Symantec Mail Security) with SMTP id F8.D8.28083.642E89B4; Thu, 11 Mar 2010 17:59:58 +0530 (IST) Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 17:59:51 +0530 Received: from blr-ec-bh04.wipro.com ([10.201.50.98]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 17:59:51 +0530 Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh04.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 17:59:51 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC116.7FCE8F15" Subject: Comments on the BFD MIB. Date: Thu, 11 Mar 2010 17:57:01 +0530 Message-ID: <6CD4ED5690208D4186E7E46B4C13B7EC099A82C0@HYD-MDP-MBX01.wipro.com> In-Reply-To: <43AE1BF0-C74F-4521-A233-4CF40C2616FB@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the BFD MIB. Thread-Index: Acq72KH/EoZFjpxCTRWI02uA4x9MEwFPChdA References: <20100304161501.A056728C1D5@core3.amsl.com><77ead0ec1003040819w25a465b2qe99dba75af30a1c9@mail.gmail.com> <43AE1BF0-C74F-4521-A233-4CF40C2616FB@lucidvision.com> From: To: X-OriginalArrivalTime: 11 Mar 2010 12:29:51.0846 (UTC) FILETIME=[8C29A060:01CAC116] X-Brightmail-Tracker: AAAAAA== X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 12:30:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC116.7FCE8F15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Description of the Performance counters in BFD MIB seems to have an issue. =20 For example if we consider the bfdSessPerfCtrlPktInHC counter, description says that value of the "bfdSessPerfCtrlPktInHC must be equal to the least significant 32 bits of bfdSessPerfCtrlPktIn if bfdSessPerfCtrlPktInHC is supported". =20 What does it mean by least significant 32 bits in a 32 bit counter?=20 =20 I think this text should be added in the description of bfdSessPerfCtrlPktIn where the value of the bfdSessPerfCtrlPktIn MUST be equal to the least significant 32 bits of bfdSessPerfCtrlPktInHC if bfdSessPerfCtrlPktInHC is supported. =20 Pls correct me if i'm missing something. =20 Thanks, Mahesh. =20 ************************************************************ bfdSessPerfCtrlPktInHC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the total number of BFD control messages received for this BFD session. It MUST be equal to the least significant 32 bits of bfdSessPerfCtrlPktIn if bfdSessPerfCtrlPktInHC is supported according to the rules spelled out in RFC2863 ." ::=3D { bfdSessPerfEntry 14 } =20 ------_=_NextPart_001_01CAC116.7FCE8F15 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Description of the Performance counters in = BFD MIB=20 seems to have an issue.
 
For example if we consider the = bfdSessPerfCtrlPktInHC=20 counter, description says that value of the "bfdSessPerfCtrlPktInHC must = be=20 equal to the least significant 32 bits of bfdSessPerfCtrlPktIn if=20 bfdSessPerfCtrlPktInHC is supported".
 
What does it mean by least significant 32 = bits in a 32=20 bit counter?
 
I think this text should be added in the = description of=20 bfdSessPerfCtrlPktIn where the value of the bfdSessPerfCtrlPktIn MUST be = equal=20 to the least significant 32 bits of bfdSessPerfCtrlPktInHC  if=20 bfdSessPerfCtrlPktInHC  is supported.
 
Pls correct me if i'm missing=20 something.
 
Thanks,
Mahesh.
 
**********************************************= **************
    bfdSessPerfCtrlPktInHC=20 OBJECT-TYPE
       =20 SYNTAX    =20 Counter64
        MAX-ACCESS=20 read-only
       =20 STATUS    =20 current
       =20 DESCRIPTION
         &nbs= p; =20 "This value represents the total number of BFD=20 control
          &n= bsp; =20 messages received for this BFD session. It MUST be=20 equal
          &nbs= p; =20 to the least significant 32 bits of=20 bfdSessPerfCtrlPktIn
        &= nbsp;   =20 if bfdSessPerfCtrlPktInHC is supported according=20 to
           &= nbsp;=20 the rules spelled out in RFC2863."
     &nb= sp; =20 ::=3D { bfdSessPerfEntry 14 }
 

------_=_NextPart_001_01CAC116.7FCE8F15-- From vishwas.ietf@gmail.com Mon Mar 15 18:52:32 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5E73A6806 for ; Mon, 15 Mar 2010 18:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.349 X-Spam-Level: ** X-Spam-Status: No, score=2.349 tagged_above=-999 required=5 tests=[AWL=-4.948, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoyJfqfoJd9g for ; Mon, 15 Mar 2010 18:52:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AC4CA3A6831 for ; Mon, 15 Mar 2010 18:52:27 -0700 (PDT) Received: by vws13 with SMTP id 13so185514vws.31 for ; Mon, 15 Mar 2010 18:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=t8rqyvpuzljJaHKmIjlv4wL5k9bP0H8zhtcc970Abd8=; b=t0CSMxS8aLltrHci+vfwO8KGw/1Y2wdVdR6yDcrhKxGNGZvl4F2jikDKBuC8D0fxUq Eveh1LSX8XwXT3PFr0uhzh9+WbU9iMqkEW4RuDFSJqqyeUPPz+lYbA/FDNJ9jkISZwQL SYGkdVAwaT1A7UTgo+FjTahAwGTqrKruMgp18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s/Hvz7jB4ItNt5c6AXKrUb0mORMmZmSLK7HJ7o7ROQgUmXlz43EqsTKpA1x034b6hI 8wwCgXnBuYbsb3XUCij/IpF3f+74ycTp4xmhaO/OJX2Y312xIndH/Fg4wlLtaVyfBvx3 MHZwxea/TXeGTZHnZo7CiUn3OVwdYdyg4tef8= MIME-Version: 1.0 Received: by 10.220.126.208 with SMTP id d16mr123191vcs.20.1268704352453; Mon, 15 Mar 2010 18:52:32 -0700 (PDT) In-Reply-To: References: <41EF2177-5EA7-4469-AFAC-9E075E5299F6@juniper.net> Date: Mon, 15 Mar 2010 18:52:32 -0700 Message-ID: <77ead0ec1003151852u7d2e370as41953c352da674ff@mail.gmail.com> Subject: =?GB2312?B?UmU6ILTwuLQ6IFJlOiBOZXcgZHJhZnQgbm90aWZpY2F0aW9uOiBkcmFmdC1kei1iZmQ=?= =?GB2312?B?LWV4dGVuc2lvbnMtZm9yLXZsLXBhY2tldHMtMDA=?= From: Vishwas Manral To: dai.xuehui@zte.com.cn Content-Type: multipart/alternative; boundary=0016e68dbb7140c57f0481e14091 Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 01:52:32 -0000 --0016e68dbb7140c57f0481e14091 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Dai, I have skimmed through the draft but have the following comments: 1. Isn't the padding functionality more a part of CV and not a CC mechanism like BFD? Though errors could happen at run time, these would generallty be there at startup time. 2. Having a different version number may be a bit hard to fly. There are other ways to add padding by overloading the A bit and the auth_field. So the first bit of the authtype filed could be used to signal padding and respective data. This would mean that all older implementations would still work without change in version number and implementations supporting this requirement could interoperate. So the authtype filed could be split into u_int32_t padding: 1 u_int32_t auth_type:7; u_int32_t total_len:24; u_int32_t auth_len:16; u_char data[]; u_char pad_info; Thanks, Vishwas 2010/3/10 > > Hi Dave, > > Thanks for your quick response, and you are right. But the exsiting > BFD can't meet our requirements to resolve such non-forwarding problem, > since BFD's flexibility is not so good. > > so we make some changes in BFD header to support negotiation for > variable-length detection parameters. Through this negotiation, asymmetri= c > condition that you mentioned can be avoided=A3=AC > > in addition, we can obtain the length interval during which the fault > occured more accurately. > > Wish further comments from you and all others. > > BR. > > Xuehui > > > > > > Best Regards. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC= =C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1 > > > *Dave Katz * > > 2010-03-03 08:21 > =CA=D5=BC=FE=C8=CB > > =B3=AD=CB=CD > rtg-bfd@ietf.org > =D6=F7=CC=E2 > Re: New draft notification: draft-dz-bfd-extensions-for-vl-packets-00 > > > > > I'll have to examine the proposal carefully, but my first reaction is tha= t > you can do most of this today without changing the protocol, by simply > padding the packets in which BFD is carried, without changing the BFD hea= der > (or the receiving implementation) at all, since the spec only requires th= at > the BFD packet fit inside of whatever it is being carried within (UDP, > typically). For that matter, the spec would allow the BFD packet itself = to > be padded (since only the lower bound of packet length is supposed to be > checked) but that would be more likely to run afoul of out-of-spec > implementations. > > It wouldn't be fancy or negotiated, but it would work today without > changing existing implementations. > > A clever implementor might match the packet length of received packets in > order to drive the extension in both directions, though that scheme would= be > asymmetric (one side has to decide to raise its packet size, and the othe= r > to reflect it). > > The proposal seems like overkill for the purpose, but I'd be interested t= o > see what others have to say. > > --Dave > > > On Feb 28, 2010, at 7:46 PM, *dai.xuehui@zte.com.cn*wrote: > > > Hi all, > > I have submitted a new draft on BFD extensions, the draft's link is: * > http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt* > > This document extends BFD mechanism to support detection function for > packets with variable lengths. Through dynamically changing the length = of > BFD packets, > it can detect both traditional faults such as link failure or route fault= , > as well as non-forwarding problem for packets with a length in a special > range, > which maybe caused by equipment's internal defects. > > Any comments and suggestions are welcomed! > > Regards > Dai > > > > Best Regards. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC= =C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1 > > --0016e68dbb7140c57f0481e14091 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Dai,
 
I have skimmed through the draft but have the following comments:=
 
1. Isn't the padding functionality more a part of CV and not a CC = mechanism like BFD? Though errors could happen at run time, these would gen= erallty be there at startup time.
 
2. Having a different version number may be a bit hard to fly. There a= re other ways to add padding by overloading the A bit and the auth_fie= ld. So the first bit of the authtype filed could be used to signal padding = and respective data.
 
This would mean that all older implementations would still work withou= t change in version number and implementations supporting this requirement = could interoperate.
 
So the authtype filed could be split into
 
u_int32_t padding: 1
u_int32_t auth_type:7;
u_int32_t total_len:24;
u_int32_t auth_len:16;
u_char data[];
u_char pad_info;
 
Thanks,
Vishwas

2010/3/10 <dai.xuehui@zte.com.cn>

Hi Dave,

 = ;    Thanks for your quick response, and you are right. But the e= xsiting BFD can't meet our requirements to resolve such non-forwarding = problem, since BFD's  flexibility is not so good.

so we make some changes in BFD hea= der to support negotiation for variable-length detection parameters. Throug= h this negotiation, asymmetric condition that you mentioned can be avoided= =A3=AC

in addition,  we can obtain t= he length interval during which the fault occured more accurately. <= br>
Wish further comments from you = and all others.

BR.

Xuehui





= Best Regards.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC= =C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1

Dave Katz <dkatz@juniper.net&g= t;

2010-03-03 08:21

=CA=D5=BC=FE=C8= =CB
<dai.xuehui@zte.com.cn>
=B3=AD=CB=CD
rtg-bfd@ietf.org=20
=D6=F7=CC=E2
Re: New draft notification: draft-= dz-bfd-extensions-for-vl-packets-00




I'll= have to examine the proposal carefully, but my first reaction is that you = can do most of this today without changing the protocol, by simply padding = the packets in which BFD is carried, without changing the BFD header (or th= e receiving implementation) at all, since the spec only requires that the B= FD packet fit inside of whatever it is being carried within (UDP, typically= ).  For that matter, the spec would allow the BFD packet itself to be = padded (since only the lower bound of packet length is supposed to be check= ed) but that would be more likely to run afoul of out-of-spec implementatio= ns.

It wouldn't be fancy or negoti= ated, but it would work today without changing existing implementations.

A clever implementor migh= t match the packet length of received packets in order to drive the extensi= on in both directions, though that scheme would be asymmetric (one side has= to decide to raise its packet size, and the other to reflect it). <= br>
The proposal seems like overkill f= or the purpose, but I'd be interested to see what others have to say.

--Dave

On Feb 28, 2010, at 7:46 PM, = dai.xuehui@zte.com.cn= wrote:


Hi all,

I= have submitted a new draft on BFD extensions, the draft'= ;s link is: http://tools.ietf.org/id/draft-dz-bfd-extensi= ons-for-vl-packets-00.txt

This document extends BFD mechanism to supp= ort detection function for  packets with variable lengths.  Throu= gh dynamically changing the length of BFD packets,
it can detect both t= raditional faults such as link failure or route fault, as well as non-forwa= rding problem for packets with a length in a special range,
which maybe caused by equipment's internal defects.

Any comments= and suggestions are welcomed!

Regards
Dai



Best Regards.
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF= =EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC=C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8= =BC=D2=BB=B6=C0=D6=A3=A1


--0016e68dbb7140c57f0481e14091-- From vishwas.ietf@gmail.com Mon Mar 15 18:55:13 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0293A6864 for ; Mon, 15 Mar 2010 18:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.349 X-Spam-Level: ** X-Spam-Status: No, score=2.349 tagged_above=-999 required=5 tests=[AWL=-4.948, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcWte57qpr8a for ; Mon, 15 Mar 2010 18:55:12 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1E51A3A6831 for ; Mon, 15 Mar 2010 18:55:12 -0700 (PDT) Received: by gwj18 with SMTP id 18so1652564gwj.31 for ; Mon, 15 Mar 2010 18:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6/tCsXEMOH0t2J8HEaPRo6YimSZhls1LsHiiVQCOx58=; b=Wuu52JzV7BDYu9sOmnTD5Na3KUKnhcJ90sEbsFXvBZcIKlLWt7XQbFoKGgUp68yTqy P0E+ntVyhOWA0AfVukHc+RfiZ9L4UAY6cWuON+KiUrpXj3f7tnRSRlz0zeGUly6PjKx/ yNMZuJ4FAbmE7LvR12gKuMgFvtlfkLYbgp9nY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nNBrjFrIQfB0JvRapLRoH13i22RPMXykPQ6rw4Sj7SRdC+G4OqI1XyVUNLUzuvJdR5 SJ2QwdHWEnTQsC4zxW8vOzTvKnPtpADWsXKKysr/1i5kCTVW2/d60L/8ipRw2/MK0iZQ Q1LroSxYdk+SJ4VT9yq4bRBot40ccf+xZ8E/8= MIME-Version: 1.0 Received: by 10.100.23.19 with SMTP id 19mr1936029anw.15.1268704516460; Mon, 15 Mar 2010 18:55:16 -0700 (PDT) In-Reply-To: <77ead0ec1003151852u7d2e370as41953c352da674ff@mail.gmail.com> References: <41EF2177-5EA7-4469-AFAC-9E075E5299F6@juniper.net> <77ead0ec1003151852u7d2e370as41953c352da674ff@mail.gmail.com> Date: Mon, 15 Mar 2010 18:55:16 -0700 Message-ID: <77ead0ec1003151855w65b79583o61f33c2b2a92521c@mail.gmail.com> Subject: =?GB2312?B?UmU6ILTwuLQ6IFJlOiBOZXcgZHJhZnQgbm90aWZpY2F0aW9uOiBkcmFmdC1kei1iZmQ=?= =?GB2312?B?LWV4dGVuc2lvbnMtZm9yLXZsLXBhY2tldHMtMDA=?= From: Vishwas Manral To: dai.xuehui@zte.com.cn Content-Type: multipart/alternative; boundary=001485f9a8640750e40481e14af1 Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 01:55:13 -0000 --001485f9a8640750e40481e14af1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Dai, One more interesting thing is how many packets we need to send for each type. I think it should depend on the detect multiplier of the neighbor, otherwise if we send a packet of different size and we have issues at a particular size the hold timer will not time out and the error will not be detected. Thanks, Vishwas 2010/3/15 Vishwas Manral > Hi Dai, > > I have skimmed through the draft but have the following comments: > > 1. Isn't the padding functionality more a part of CV and not a CC mechani= sm > like BFD? Though errors could happen at run time, these would generallty = be > there at startup time. > > 2. Having a different version number may be a bit hard to fly. There are > other ways to add padding by overloading the A bit and the auth_field. So > the first bit of the authtype filed could be used to signal padding and > respective data. > > This would mean that all older implementations would still work without > change in version number and implementations supporting this requirement > could interoperate. > > So the authtype filed could be split into > > u_int32_t padding: 1 > u_int32_t auth_type:7; > u_int32_t total_len:24; > u_int32_t auth_len:16; > u_char data[]; > u_char pad_info; > > Thanks, > Vishwas > > 2010/3/10 > >> >> Hi Dave, >> >> Thanks for your quick response, and you are right. But the exsiting >> BFD can't meet our requirements to resolve such non-forwarding problem, >> since BFD's flexibility is not so good. >> >> so we make some changes in BFD header to support negotiation for >> variable-length detection parameters. Through this negotiation, asymmetr= ic >> condition that you mentioned can be avoided=A3=AC >> >> in addition, we can obtain the length interval during which the fault >> occured more accurately. >> >> Wish further comments from you and all others. >> >> BR. >> >> Xuehui >> >> >> >> >> >> Best Regards. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC= =C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1 >> >> >> *Dave Katz * >> >> 2010-03-03 08:21 >> =CA=D5=BC=FE=C8=CB >> >> =B3=AD=CB=CD >> rtg-bfd@ietf.org >> =D6=F7=CC=E2 >> Re: New draft notification: draft-dz-bfd-extensions-for-vl-packets-00 >> >> >> >> >> I'll have to examine the proposal carefully, but my first reaction is th= at >> you can do most of this today without changing the protocol, by simply >> padding the packets in which BFD is carried, without changing the BFD he= ader >> (or the receiving implementation) at all, since the spec only requires t= hat >> the BFD packet fit inside of whatever it is being carried within (UDP, >> typically). For that matter, the spec would allow the BFD packet itself= to >> be padded (since only the lower bound of packet length is supposed to be >> checked) but that would be more likely to run afoul of out-of-spec >> implementations. >> >> It wouldn't be fancy or negotiated, but it would work today without >> changing existing implementations. >> >> A clever implementor might match the packet length of received packets i= n >> order to drive the extension in both directions, though that scheme woul= d be >> asymmetric (one side has to decide to raise its packet size, and the oth= er >> to reflect it). >> >> The proposal seems like overkill for the purpose, but I'd be interested = to >> see what others have to say. >> >> --Dave >> >> >> On Feb 28, 2010, at 7:46 PM, *dai.xuehui@zte.com.cn*wrote: >> >> >> Hi all, >> >> I have submitted a new draft on BFD extensions, the draft's link is: * >> http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt*<= http://tools.ietf.org/id/draft-dz-bfd-extensions-for-vl-packets-00.txt> >> >> This document extends BFD mechanism to support detection function for >> packets with variable lengths. Through dynamically changing the length= of >> BFD packets, >> it can detect both traditional faults such as link failure or route faul= t, >> as well as non-forwarding problem for packets with a length in a special >> range, >> which maybe caused by equipment's internal defects. >> >> Any comments and suggestions are welcomed! >> >> Regards >> Dai >> >> >> >> Best Regards. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC= =C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1 >> >> > --001485f9a8640750e40481e14af1 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Dai,
 
One more interesting thing is how many packets we need to send for eac= h type. I think it should depend on the detect multiplier of the neighbor, = otherwise if we send a packet of different size and we have issues at a par= ticular size the hold timer will not time out and the error will not be det= ected.
 
Thanks,
Vishwas

2010/3/15 Vishwas Manral <<= a href=3D"mailto:vishwas.ietf@gmail.com">vishwas.ietf@gmail.com>
Hi Dai,
 
I have skimmed through the draft but have the following comments:=
 
1. Isn't the padding functionality more a part of CV and not a CC = mechanism like BFD? Though errors could happen at run time, these would gen= erallty be there at startup time.
 
2. Having a different version number may be a bit hard to fly. There a= re other ways to add padding by overloading the A bit and the auth_fie= ld. So the first bit of the authtype filed could be used to signal padding = and respective data.
 
This would mean that all older implementations would still work withou= t change in version number and implementations supporting this requirement = could interoperate.
 
So the authtype filed could be split into
 
u_int32_t padding: 1
u_int32_t auth_type:7;
u_int32_t total_len:24;
u_int32_t auth_len:16;
u_char data[];
u_char pad_info;
 
Thanks,
Vishwas

2010/3/10 <dai.xuehui@zte.com.cn>

Hi Dave,

 = ;    Thanks for your quick response, and you are right. But the e= xsiting BFD can't meet our requirements to resolve such non-forwarding = problem, since BFD's  flexibility is not so good.

so we make some changes in BFD hea= der to support negotiation for variable-length detection parameters. Throug= h this negotiation, asymmetric condition that you mentioned can be avoided= =A3=AC

in addition,  we can obtain t= he length interval during which the fault occured more accurately. <= br>
Wish further comments from you = and all others.

BR.

Xuehui





Best Regards.=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=D7=A3=C4= =FA=D0=C2=B4=BA=D3=E4=BF=EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC=C9=ED=CC=E5= =BD=A1=BF=B5=A3=AC=E3=D8=BC=D2=BB=B6=C0=D6=A3=A1


Dave Katz <dkatz@juniper.net&g= t;

2010-03-03 08:21

=CA=D5=BC=FE=C8= =CB
=B3=AD=CB=CD
rtg-bfd@ietf.org=20
=D6=F7=CC=E2
Re: New draft notification: draft-= dz-bfd-extensions-for-vl-packets-00




I'll have to exam= ine the proposal carefully, but my first reaction is that you can do most o= f this today without changing the protocol, by simply padding the packets i= n which BFD is carried, without changing the BFD header (or the receiving i= mplementation) at all, since the spec only requires that the BFD packet fit= inside of whatever it is being carried within (UDP, typically).  For = that matter, the spec would allow the BFD packet itself to be padded (since= only the lower bound of packet length is supposed to be checked) but that = would be more likely to run afoul of out-of-spec implementations.
It wouldn't be fancy or negoti= ated, but it would work today without changing existing implementations.

A clever implementor migh= t match the packet length of received packets in order to drive the extensi= on in both directions, though that scheme would be asymmetric (one side has= to decide to raise its packet size, and the other to reflect it). <= br>
The proposal seems like overkill f= or the purpose, but I'd be interested to see what others have to say.

--Dave

On Feb 28, 2010, at 7:46 PM, = dai.xuehui@zte.com.cn= wrote:


Hi all,

I= have submitted a new draft on BFD extensions, the draft'= ;s link is: http://tools.ietf.org/id/draft-dz-bfd-extensi= ons-for-vl-packets-00.txt

This document extends BFD mechanism to supp= ort detection function for  packets with variable lengths.  Throu= gh dynamically changing the length of BFD packets,
it can detect both t= raditional faults such as link failure or route fault, as well as non-forwa= rding problem for packets with a length in a special range,
which maybe caused by equipment's internal defects.

Any comments= and suggestions are welcomed!

Regards
Dai



Best Regards.
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=D7=A3=C4=FA=D0=C2=B4=BA=D3=E4=BF= =EC=A3=AC=B9=A4=D7=F7=CB=B3=C0=FB=A3=AC=C9=ED=CC=E5=BD=A1=BF=B5=A3=AC=E3=D8= =BC=D2=BB=B6=C0=D6=A3=A1



--001485f9a8640750e40481e14af1-- From jhaas@slice.pfrc.org Sat Mar 20 09:33:41 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF613A6987 for ; Sat, 20 Mar 2010 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+Q807gcXQGO for ; Sat, 20 Mar 2010 09:33:40 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 6ADB23A684D for ; Sat, 20 Mar 2010 09:33:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 396BA22405F; Sat, 20 Mar 2010 16:33:52 +0000 (UTC) Date: Sat, 20 Mar 2010 16:33:52 +0000 From: Jeffrey Haas To: mahesh.akula@wipro.com Subject: Re: Comments on the BFD MIB. Message-ID: <20100320163352.GB31380@slice> References: <43AE1BF0-C74F-4521-A233-4CF40C2616FB@lucidvision.com> <6CD4ED5690208D4186E7E46B4C13B7EC099A82C0@HYD-MDP-MBX01.wipro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6CD4ED5690208D4186E7E46B4C13B7EC099A82C0@HYD-MDP-MBX01.wipro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 16:33:41 -0000 Mahesh, On Thu, Mar 11, 2010 at 05:57:01PM +0530, mahesh.akula@wipro.com wrote: > Description of the Performance counters in BFD MIB seems to have an > issue. > > For example if we consider the bfdSessPerfCtrlPktInHC counter, > description says that value of the "bfdSessPerfCtrlPktInHC must be equal > to the least significant 32 bits of bfdSessPerfCtrlPktIn if > bfdSessPerfCtrlPktInHC is supported". > > What does it mean by least significant 32 bits in a 32 bit counter? See RFC 2863, section 3.1.6 as an example: : When 64-bit counters are in use, the 32-bit counters MUST still be : available. They will report the low 32-bits of the associated 64-bit : count (e.g., ifInOctets will report the least significant 32 bits of : ifHCInOctets). This enhances inter-operability with existing : implementations at a very minimal cost to agents. I suspect what the MIB authors meant was that the Counter32 objects should contain text that say something roughly like the following: bfdSessPerfCtrlPktIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of BFD control messages received for this BFD session. This value MUST be equal to the least significant 32 bits of bfdSessPerfCtrlPktInHC." ::= { bfdSessPerfEntry 1 } bfdSessPerfCtrlPktInHC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the total number of BFD control messages received for this BFD session." ::= { bfdSessPerfEntry 14 } -- Jeff From vishwas.ietf@gmail.com Sat Mar 20 09:37:12 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C583A6855 for ; Sat, 20 Mar 2010 09:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-1.164, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C012fMjmI0V for ; Sat, 20 Mar 2010 09:37:11 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.210.180]) by core3.amsl.com (Postfix) with ESMTP id C39653A684D for ; Sat, 20 Mar 2010 09:37:11 -0700 (PDT) Received: by yxe10 with SMTP id 10so365931yxe.29 for ; Sat, 20 Mar 2010 09:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u28UvarIFqcGI9T9gP/Eyghp0uSQVlYIfnowSPc5byg=; b=BDLAhDns9QlTzawKPwPRuzWTglXsIq9CroJBuuicxEVDm4k8edT3EBRwm3VvtBlapc Uau0VMIu6v/uu6M/m/6jBXLdxnuWVUTKBbqIVyx20Q/42Iis0P+9d7JBdVDvHjrLyEfW OX1RaVthOZqICAmerERjxcG1tkx3IDuCXbB5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WzBhpRfcUy2WcJBPqWczhXmx3nyhx05PhKVUNar8Fc5JckIxfJUbRnhLYXoI2BjJZK H+fF0NAaAGglYJ7/9XsG+ObxWWaBTNsLgatUJCXZJYnXZvpJ0w7QuCb/NodhnGzpax+C lDZHpHYe3QbeUJfKaplmlRAJP6AHASvsL4DZk= MIME-Version: 1.0 Received: by 10.151.2.5 with SMTP id e5mr4265193ybi.164.1269103043592; Sat, 20 Mar 2010 09:37:23 -0700 (PDT) In-Reply-To: <20100320163352.GB31380@slice> References: <43AE1BF0-C74F-4521-A233-4CF40C2616FB@lucidvision.com> <6CD4ED5690208D4186E7E46B4C13B7EC099A82C0@HYD-MDP-MBX01.wipro.com> <20100320163352.GB31380@slice> Date: Sat, 20 Mar 2010 09:37:23 -0700 Message-ID: <77ead0ec1003200937u4f0de340r2ffbb169f4c2efba@mail.gmail.com> Subject: Re: Comments on the BFD MIB. From: Vishwas Manral To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 16:37:12 -0000 Hi Mahesh, I agree with Jeff it looks like the description is messed up. Thanks, Vishwas On Sat, Mar 20, 2010 at 9:33 AM, Jeffrey Haas wrote: > Mahesh, > > On Thu, Mar 11, 2010 at 05:57:01PM +0530, mahesh.akula@wipro.com wrote: >> Description of the Performance counters in BFD MIB seems to have an >> issue. >> >> For example if we consider the bfdSessPerfCtrlPktInHC counter, >> description says that value of the "bfdSessPerfCtrlPktInHC must be equal >> to the least significant 32 bits of bfdSessPerfCtrlPktIn if >> bfdSessPerfCtrlPktInHC is supported". >> >> What does it mean by least significant 32 bits in a 32 bit counter? > > See RFC 2863, section 3.1.6 as an example: > : =A0 =A0When 64-bit counters are in use, the 32-bit counters MUST still = be > : =A0 =A0available. =A0They will report the low 32-bits of the associated= 64-bit > : =A0 =A0count (e.g., ifInOctets will report the least significant 32 bit= s of > : =A0 =A0ifHCInOctets). =A0This enhances inter-operability with existing > : =A0 =A0implementations at a very minimal cost to agents. > > I suspect what the MIB authors meant was that the Counter32 objects shoul= d > contain text that say something roughly like the following: > > =A0 =A0bfdSessPerfCtrlPktIn OBJECT-TYPE > =A0 =A0 =A0 =A0SYNTAX =A0 =A0 Counter32 > =A0 =A0 =A0 =A0MAX-ACCESS read-only > =A0 =A0 =A0 =A0STATUS =A0 =A0 current > =A0 =A0 =A0 =A0DESCRIPTION > =A0 =A0 =A0 =A0 =A0 =A0"The total number of BFD control messages received= for this > =A0 =A0 =A0 =A0 =A0 =A0 BFD session. =A0This value MUST be equal to the l= east significant > =A0 =A0 =A0 =A0 =A0 =A0 32 bits of bfdSessPerfCtrlPktInHC." > =A0 =A0 =A0 =A0::=3D { bfdSessPerfEntry 1 } > > =A0 =A0bfdSessPerfCtrlPktInHC OBJECT-TYPE > =A0 =A0 =A0 =A0SYNTAX =A0 =A0 Counter64 > =A0 =A0 =A0 =A0MAX-ACCESS read-only > =A0 =A0 =A0 =A0STATUS =A0 =A0 current > =A0 =A0 =A0 =A0DESCRIPTION > =A0 =A0 =A0 =A0 =A0 =A0"This value represents the total number of BFD con= trol > =A0 =A0 =A0 =A0 =A0 =A0 messages received for this BFD session." > =A0 =A0 =A0 =A0::=3D { bfdSessPerfEntry 14 } > > -- Jeff > From jhaas@slice.pfrc.org Sat Mar 20 09:55:39 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDB33A6822 for ; Sat, 20 Mar 2010 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg12umqZwhmK for ; Sat, 20 Mar 2010 09:55:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 13DA93A63EC for ; Sat, 20 Mar 2010 09:55:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E8FF122405F; Sat, 20 Mar 2010 16:55:53 +0000 (UTC) Date: Sat, 20 Mar 2010 16:55:53 +0000 From: Jeffrey Haas To: Vishwas Manral Subject: Re: BFD MIB Message-ID: <20100320165553.GC31380@slice> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 16:55:39 -0000 Vishwas, I'm following up in teh context of version 09 of the BFD MIB. On Tue, Nov 10, 2009 at 11:19:59AM -0800, Vishwas Manral wrote: > This is regarding the BFD MIB version 07. I noticed that the sessions > table has the objects bfdSessDesiredMinTxInterval and other session > related parameters. > > The issue with this is that because the sessions in BFD are actually > triggered by protocols outside BFD and in BFD we are unaware of which > sessions will be created, changing the values of the objects when the > row create is triggered dynamically from other protocols is not > possible. I think you're referring to a few different things here: 1. There is no object that may be queried for an available index number to use as the bfdSessIndex. 2. System BFD applications may create BFD sessions where session parameters should be outside the control of SNMP SET operations. 3. The text for managing a BFD session via its logical row in the MIB is absent. For example, what operations may be permitted via SNMP SET on objects without touching the row's RowStatus object. Is this correct? > Looking at the Cisco CLI it seems to take the parameters on the > interface basis too. Why is the MIB not aligned to the CLI (even > though the authors themselves are from the company)? Specific vendor aside, what do you see missing in the session table with respect to interfaces? > Vishwas -- Jeff From jhaas@slice.pfrc.org Sat Mar 20 10:46:46 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DC53A67F9 for ; Sat, 20 Mar 2010 10:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.532 X-Spam-Level: X-Spam-Status: No, score=0.532 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QJdVwyMmggz for ; Sat, 20 Mar 2010 10:46:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id AA5343A67F0 for ; Sat, 20 Mar 2010 10:46:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AFCA022405F; Sat, 20 Mar 2010 17:46:59 +0000 (UTC) Date: Sat, 20 Mar 2010 17:46:59 +0000 From: Jeffrey Haas To: tom.nadeau@bt.com, zali@cisco.com, nobo@cisco.com Subject: Comments on draft-ietf-bfd-mib-09 Message-ID: <20100320174659.GD31380@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 17:46:46 -0000 Authors: These comments are as an individual contributor rather than in my role of BFD co-chair. I have not run the mib through snmplint. --- Regarding bfdSessType, I realize this has been in the MIB for a while in the context of the type of multi-hop session. However, I'd like to suggest that this is heading for a collision with likely future working group tasks. In this case, it would be draft-katz-ward-bfd-multipoint. That draft defines a new BFD variable meant to cover the BFD session type. Further, that type covers semantics that don't overlap well with those currently covered by bfdSessType. The current object describes the session in terms of its mult-hop properties. While this is potentially useful for helping a MIB consumer understand some of the session properties and why some of the various other objects have their current values, it's somewhat problematic in terms of configuring a session from the MIB. I can see why OOB would only occur for BFD sessions created by other applications (e.g. OSPF, LSP-PING), however it's unclear how the MIB implementation should handle setting this variable for other MIB-created sessions. This object could use some additional clarification text to cover the use cases. I'd also suggest factoring it out into a textual convention. Similarly, the bfdSessMultiHopUniLinkMode object could use clarification for its use cases - in particular why it's read-only instead of read-create. This object, name aside, seems potentially useful for setting a BFD session to be active instead of passive. If that's the intention I'd suggest making it read-create and deleting the MultiHopUniLink portion of the name. This would require clarification about acceptable values for certain types of sessions. bfdSessSourceUdpPort is constrained by the BFD specifciations to be limited to values 49152..65535. I don't recall if ranges can be applied to a textual convention - I suspect you would need to to create a new one to cover these restrictions. Also, given the above, the DEFVAL should be adjusted or clarified. For example, 0 would permit the SNMP agent to choose its own source port. The DEFVAL for bfdSessEchoSourceUdpPort when 0 should be similarly clarified. I would suggest that the SYNTAX of the bfdSessState object be put into a TEXTUAL-CONVENTION. bfdSessDiag is accessible-for-notify rather than read-only. Is there a reason why the user wouldn't want to see this status in a MIB poll? bfdSessOperMode has semantics that may end up being incompatible with draft-katz-war-bfd-multipoint. That document is not yet a working group item, but I'd suggest considering how such a document would impact this object. Perhaps factoring this into a TEXTUAL-CONVENTION would make sense. Additionally, bfdSessOperMode is read-only. Why wouldn't this be read-create? bfdSessMultiPointFlag is included in this MIB as a read-only object. Given that the semantics and impact of this flag are covered by draft-katz-ward-bfd-multipoint, would you suggest: 1. Keeping the object in here, read-only? 2. Updating it to read-create and plan on updating the base BFD MIB to accomodate the draft if it is adopted as a WG item? 3. Remove the object and plan on making the multipoint changes as AUGMENTation tables to the base MIB? For bfdSessGTSMTTL, what are the semantics you expect a 0 TTL to have (the DEFVAL)? Should this be 0 only if GTSM is disabled in bfdSessGTSM? Also, you should consider updating the DESCRIPTION to accommodate requirements of bfd-mpls where the TTL of the bottom label MUST be 1. In bfdSessDesiredMinTxInterval, consider adding text to the DESCRIPTION to note that a value of 0 disables transmitting periodic control packets from BFD. Similarly in bfdSessReqMinEchoRxInterval, consider adding text to the DESCRIPTION to note that a value of 0 indicates that no echo traffic is desired and this value MUST be 0 for multi-hop sessions. bfdSessAuthPresFlag is read-only. Since it's in the read-write conformance group, I suspect this is an error. If that's not the case, you should add text to the DESCRIPTION to clarify its value in the presence of the configuration of bfdSessAuthentication(Type|KeyId|Key). bfdSessAuthentiacationType probably should call out value 0 as being used when no authentication is in use. I would also suggest factoring the SYNTAX into a TEXTUAL-CONVENTION. bfdSessAuthenticationKey carries a *lot* of semantics that should vary depending on the authentication type. While the valid range of the field could be 0..252 based on the PDU description, the values are constrained based on the type: - Password: 1..16 - MD5: 16 - SHA-1: 20 I would suggest creating a TEXTUAL-CONVENTION that describes these semantics. bfdSessPerfEntry: s/bfdCounterDiscontinuityTime/bfdSessPerfDiscTime/ In bfdSessDiscMapIndex and bfdSessIpMapIndex, I think you mean BfdSessIndexTC instead of BfdIndex, correct? In bfdSessIpMapTable, shouldn't the table apply to multi-hop types as well? In the Security Considerations, where bfdSessPerfTable is mentioned, it should also mention bfdSessPerfHCTable. --- Conformance Group issues: bfdSessDiscMapTable is not in a conformance group bfdsessIpMapTable is not in a conformance group bfdSessionPerfHCGroup and bfdNotificationGroup should not be in both a GROUP clause and in MANDATORY-GROUPS. bfdNotificationGroup sounds like it is meant to be optional and probably should be excluded from MANDATORY-GROUPS. --- Editorial nits: In section 5.3: " The session performance table is used for collecting BFD performance counts on a per session basis." s/counts/counters/ In section 5.5: " BfdSessIndexTC used in the bfdSessionTable. This table SHOULD contains those BFD sessions are of IP type." "that are of IP type". BfdInterval ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The BFD interval delay in microseconds." I'd suggest deleting "delay". In bfdSessAddr: " It can also be used to enabled BFD on a specific" s/enabled/enable/ From jhaas@slice.pfrc.org Sat Mar 20 11:20:45 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830A43A688C for ; Sat, 20 Mar 2010 11:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.719 X-Spam-Level: X-Spam-Status: No, score=0.719 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+unBZS70t7a for ; Sat, 20 Mar 2010 11:20:40 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 302BF3A67E9 for ; Sat, 20 Mar 2010 11:20:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 31319224060; Sat, 20 Mar 2010 18:20:54 +0000 (UTC) Date: Sat, 20 Mar 2010 18:20:54 +0000 From: Jeffrey Haas To: dkatz@juniper.net, dward@juniper.net Subject: Editorial comments on draft-ietf-bfd-base-11 Message-ID: <20100320182054.GE31380@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 18:20:48 -0000 Daves, Since I had to review the MIB, I reviewed most of the base specs as well. I had a few comments which are very minor and perhaps worth including in an auth48 update. At no point in the specification is the location of the authentication section in the BFD described. It would be sufficient to say that it follows the mandatory section. There are some minor issues regarding the length field in the mdndatory section and the authentication present bit. This is the stuff of conformance weenies and I suspect I know where you'll tell me to put my comments. :-) - If the authentication present bit is 0 and authentication is present in the PDU, should we ignore the authentication data even if the length of the BFD control packet correctly includes the optional authentication section? - The mandatory section has a fixed length. The optional authentication section is at least 2 bytes of data. Length MUST accomodate the mandatory section plus the optional authentication section. Section 6.8.6 doesn't accomodate for improper authentication length. It merely places a lower bound on it and an upper bound of the transport payload length. Section 6.7 places checks on the authentication length but doesn't check against length. I suspect the loose wording is intended to accommodate adding arbitrary data *after* the optional authentication section (good for future extensions) but it's loose enough to not require Length be long enough to cover the packet contents. Given the thought that this is meant to accommodate future expansion, you may wish to consider adding wording that states that length must be long enough to cover the mandatory section and the optional authentication section. -- Jeff From vishwas.ietf@gmail.com Sat Mar 20 16:31:43 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9143A67DD for ; Sat, 20 Mar 2010 16:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=-1.462, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c111DcNpaQlj for ; Sat, 20 Mar 2010 16:31:42 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 853B53A67BD for ; Sat, 20 Mar 2010 16:31:39 -0700 (PDT) Received: by ywh38 with SMTP id 38so2233018ywh.29 for ; Sat, 20 Mar 2010 16:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=c20C86rOlLvpl9ZjA6JolkYz+MRLxBQmps4lK4N2gMA=; b=TQWvRGNpFplZgi3rF347wVq5wQooebc4WMvAzar+c4FQHFhkVNCDWRepAZBuit5faM yDDinBfx6AxyH7wehyQc+3I++sVPRDPNld/lc1n0X5AOuSLHOcHezE1/x8JRNw5C4PIe Nk6VHWGcx4ZHaqVw2seyNZ8ssPKfzCIBaJEOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tFRr+P3dCwBrlYKRu5aATe65191H/36f5pI5VWovPgpZNIAOVvYZv/UOvMRioQBfqY 5sx0kJev1tdwdiTzsyCnTwlpGF9sfaSKkfVELLVhF0fDau8az6XQSIQHVg/F08Rc1Ri4 f0MKIEhwxrc9VRPvkjVQtB1aGrzaHP8D9YVYs= MIME-Version: 1.0 Received: by 10.151.2.5 with SMTP id e5mr4644667ybi.164.1269127911768; Sat, 20 Mar 2010 16:31:51 -0700 (PDT) In-Reply-To: <20100320165553.GC31380@slice> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> Date: Sat, 20 Mar 2010 16:31:51 -0700 Message-ID: <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 23:31:44 -0000 hi jeff, you are right. the point i have raised is sessiontable should be read only in bfd. i do not know what it would mean to have a session row without a protocol waiting for the session notification. this is one of the basic flaws in the mib. sessions are learned dynamically and we cannot configure a row for every possible session. the second part is that we should allow objects to be configured on a global or an interface basis so when a session is configured from a protcol the default value of parameters is automatically inherited. on seeing the cli from the vendor i mentioned its also done the way i have mentioned. i m at the ietf. let us discuss this if you are there too. thanks, vishwas On 3/20/10, Jeffrey Haas wrote: > Vishwas, > > I'm following up in teh context of version 09 of the BFD MIB. > > On Tue, Nov 10, 2009 at 11:19:59AM -0800, Vishwas Manral wrote: >> This is regarding the BFD MIB version 07. I noticed that the sessions >> table has the objects bfdSessDesiredMinTxInterval and other session >> related parameters. >> >> The issue with this is that because the sessions in BFD are actually >> triggered by protocols outside BFD and in BFD we are unaware of which >> sessions will be created, changing the values of the objects when the >> row create is triggered dynamically from other protocols is not >> possible. > > I think you're referring to a few different things here: > 1. There is no object that may be queried for an available index number to > use as the bfdSessIndex. > 2. System BFD applications may create BFD sessions where session parameters > should be outside the control of SNMP SET operations. > 3. The text for managing a BFD session via its logical row in the MIB is > absent. For example, what operations may be permitted via SNMP SET on > objects without touching the row's RowStatus object. > > Is this correct? > >> Looking at the Cisco CLI it seems to take the parameters on the >> interface basis too. Why is the MIB not aligned to the CLI (even >> though the authors themselves are from the company)? > > Specific vendor aside, what do you see missing in the session table with > respect to interfaces? > >> Vishwas > > -- Jeff > From jhaas@slice.pfrc.org Sun Mar 21 05:48:53 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB00D3A67F3 for ; Sun, 21 Mar 2010 05:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.843 X-Spam-Level: X-Spam-Status: No, score=0.843 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik8aXXr4T+Sq for ; Sun, 21 Mar 2010 05:48:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id EF0943A67AF for ; Sun, 21 Mar 2010 05:48:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id ED102224060; Sun, 21 Mar 2010 12:49:08 +0000 (UTC) Date: Sun, 21 Mar 2010 12:49:08 +0000 From: Jeffrey Haas To: Vishwas Manral Subject: Re: BFD MIB Message-ID: <20100321124908.GA6307@slice> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 12:48:53 -0000 Vishwas, Unfortunately, I'm not at the current IETF session. I will admit to some biases against SNMP configuration of protocols based on my experiences with trying to find use cases for configuring BGP via a MIB. However, I'm also aware of operators who *do* want things like OSPF configurable via MIB. Regardless of our own particular SNMP SET based prejudices, we must answer two questions: 1. Given the protocol cases where BFD may be fully configured, does the MIB support this? 2. Given the protocol cases where BFD may have been configured outside of the SNMP system, does the MIB safely support configuration or manipulation of those sessions? Speaking as co-chair of the group for a moment to the BFD MIB authors: Do you have specific use cases for SNMP configuration in mind in the BFD MIB? If not, should we consider moving the bulk of the MIB to read-only? (This question also goes out to members of the WG that may require MIB configuration support.) On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: > you are right. the point i have raised is sessiontable should be read > only in bfd. i do not know what it would mean to have a session row > without a protocol waiting for the session notification. this is one > of the basic flaws in the mib. sessions are learned dynamically and we > cannot configure a row for every possible session. I agree that we cannot do this for every possible session. Protocols requiring bootstrap of discriminator values MUST come from the outside of MIB configuration. Given this, what should the current sessiontable show? One option that is reasonable within the context of SNMP would be to have the logical row's StorageType be readOnly for rows created by sessions requiring bootstrap. Alternatively, permanent, would permit manipulation of row variables but with potentially serious impacts upon the protocol. As for "a protocol waiting for the session notification", it would be reasonable for a protocol-specific MIB to have their session/neighbor/etc. table AUGMENTed with a BFD peering table. Such a table would likely have an "enable BFD" object, and at least one more object which referred to the bfdSessIndex of the associated BFD session. Whether the configuration for the BFD session was part of the augmentation table or in the base BFD MIB is an implementation detail; I can see configuration scenarios both ways. The challenge for the MIB authors is to write text for the BFD MIB supporting each use case. By way of supporting the reverse mapping, the BFD MIB could also have a RowPointer into the appropriate BFD protocol-specific portion of its MIB. > the second part is that we should allow objects to be configured on a > global or an interface basis so when a session is configured from a > protcol the default value of parameters is automatically inherited. on > seeing the cli from the vendor i mentioned its also done the way i > have mentioned. While I agree that such mechanisms are operationally useful, they are also vendor-specific forms of convenience. At a SNMP table level, it is indistinguishable to have interface-specific configuration templates and to have the user enter each of the same values from the template into the appropriate portion of the protocol MIB. Putting such templates into the base protocol MIB constrains the implementation to have a specific form that may be inappropriate to a given vendor. In my opinion, that is out of scope for the BFD MIB but certainly within scope of vendor support in an enterprise MIB. -- Jeff From vishwas.ietf@gmail.com Sun Mar 21 11:11:41 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8AE3A679C for ; Sun, 21 Mar 2010 11:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[AWL=-1.372, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pistImN9JZTI for ; Sun, 21 Mar 2010 11:11:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 337753A63EC for ; Sun, 21 Mar 2010 11:11:28 -0700 (PDT) Received: by gyh4 with SMTP id 4so2431753gyh.31 for ; Sun, 21 Mar 2010 11:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=utODGaVmxA3zdxKUlTkQ/1hi1R5o7BnYfEp1R9ovm5A=; b=wB2QgNloB5fzJHatX4PvEfn13iXKJr/rlhC4p1rkxogqOQersLC7C4zzfchUSYMxrh WxXbAEDBr2+G06wosiyF7SBZ1niSVpgZzRR9tY2Q4/3sdjjvm/YevkANqc6WMc2Viws7 I3+QfdTGrVEIfWzOcdQT2N+EqDNcGvvYKyx44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=STpIXLyOR/3dxaLgx4j4QnTAKWKiYp/sG97OolsmiIxhMdGwxAeydzITx1DHQUt02n LWr/GZwHTF/tYz6JO8KoGnBoOzFTbVWF+493R4pyvHEqajvXXNm3KTC8x9Pbb4oOzZN9 FYHD+jixQRwOVK1ni2kxMoANeDGXYcItbuXzc= MIME-Version: 1.0 Received: by 10.150.162.1 with SMTP id k1mr546280ybe.170.1269195100994; Sun, 21 Mar 2010 11:11:40 -0700 (PDT) In-Reply-To: <20100321124908.GA6307@slice> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> Date: Sun, 21 Mar 2010 11:11:40 -0700 Message-ID: <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:11:42 -0000 Hi Jeff, I guess now we are exactly on the same page. Thanks for following up the comments given on the list. I am sure there still are others which need to be looked at. Thanks, Vishwas On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas wrote: > Vishwas, > > Unfortunately, I'm not at the current IETF session. > > I will admit to some biases against SNMP configuration of protocols based= on > my experiences with trying to find use cases for configuring BGP via a MI= B. > However, I'm also aware of operators who *do* want things like OSPF > configurable via MIB. =A0Regardless of our own particular SNMP SET based > prejudices, we must answer two questions: > > 1. Given the protocol cases where BFD may be fully configured, does the M= IB > =A0 support this? > 2. Given the protocol cases where BFD may have been configured outside of > =A0 the SNMP system, does the MIB safely support configuration or manipul= ation > =A0 of those sessions? > > Speaking as co-chair of the group for a moment to the BFD MIB authors: = =A0Do > you have specific use cases for SNMP configuration in mind in the BFD MIB= ? > If not, should we consider moving the bulk of the MIB to read-only? > (This question also goes out to members of the WG that may require MIB > configuration support.) > > On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >> you are right. the point i have raised is sessiontable should be read >> only in bfd. i do not know what it would mean to have a session row >> without a protocol waiting for the session notification. this is one >> of the basic flaws in the mib. sessions are learned dynamically and we >> cannot configure a row for every possible session. > > I agree that we cannot do this for every possible session. =A0Protocols > requiring bootstrap of discriminator values MUST come from the outside of > MIB configuration. =A0Given this, what should the current sessiontable sh= ow? > One option that is reasonable within the context of SNMP would be to have > the logical row's StorageType be readOnly for rows created by sessions > requiring bootstrap. =A0Alternatively, permanent, would permit manipulati= on of > row variables but with potentially serious impacts upon the protocol. > > As for "a protocol waiting for the session notification", it would be > reasonable for a protocol-specific MIB to have their session/neighbor/etc= . > table AUGMENTed with a BFD peering table. =A0Such a table would likely ha= ve > an "enable BFD" object, and at least one more object which referred to th= e > bfdSessIndex of the associated BFD session. =A0Whether the configuration = for > the BFD session was part of the augmentation table or in the base BFD MIB= is > an implementation detail; I can see configuration scenarios both ways. = =A0The > challenge for the MIB authors is to write text for the BFD MIB supporting > each use case. > > By way of supporting the reverse mapping, the BFD MIB could also have a > RowPointer into the appropriate BFD protocol-specific portion of its MIB. > >> the second part is that we should allow objects to be configured on a >> global or an interface basis so when a session is configured from a >> protcol the default value of parameters is automatically inherited. on >> seeing the cli from the vendor i mentioned its also done the way i >> have mentioned. > > While I agree that such mechanisms are operationally useful, they are als= o > vendor-specific forms of convenience. =A0At a SNMP table level, it is > indistinguishable to have interface-specific configuration templates and = to > have the user enter each of the same values from the template into the > appropriate portion of the protocol MIB. > > Putting such templates into the base protocol MIB constrains the > implementation to have a specific form that may be inappropriate to a giv= en > vendor. =A0In my opinion, that is out of scope for the BFD MIB but certai= nly > within scope of vendor support in an enterprise MIB. > > -- Jeff > From vishwas.ietf@gmail.com Sun Mar 21 11:12:42 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381723A67F9 for ; Sun, 21 Mar 2010 11:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2MfWrT4Vm0B for ; Sun, 21 Mar 2010 11:12:41 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 0372D3A63EC for ; Sun, 21 Mar 2010 11:12:40 -0700 (PDT) Received: by gxk9 with SMTP id 9so56806gxk.8 for ; Sun, 21 Mar 2010 11:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l+RpFAbBu0RKIt8W4VQBOfGLyzxVNkSMz6MdN0Lumn4=; b=Z3dd0qpYDNT1iL5UUTpqswGd1w3l3eco5zgJ5+n1JGOHXSbvrdA3FpRlXB7ixoBgZb jXsa3CdWCvyc7eaPjzCo0t8P6ExvoaVn/I0Lxe2lb7WfNyxib2kQutBZcVSTGonWHpoh Tx2qGK3kmh6Y2hDWOeOgphv64iAdMBpDVKHD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qlzj1CHsHSV+A+JfKqsCMu1FUJKAXqX2BtWawR3XCN5xSbuTjVNn4GNKKZaa6iGnfA skMjUTCl2+9SVOzcywVzaRBH+o0p5HaUHTqOmCgA0yuzh2vwRKO1YURUC3l3pXyWPUyS uhZ/RChqBGGmILvxIlsM5DpavMBFArzIWwx3A= MIME-Version: 1.0 Received: by 10.150.184.14 with SMTP id h14mr2226699ybf.51.1269195174497; Sun, 21 Mar 2010 11:12:54 -0700 (PDT) In-Reply-To: <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> Date: Sun, 21 Mar 2010 11:12:54 -0700 Message-ID: <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:12:42 -0000 Hi Jeff, Just to add, if you look at the LDP MIB and others we will find it similar to what I have been saying. In LDP the concept is called entities. Thanks, Vishwas On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral w= rote: > Hi Jeff, > > I guess now we are exactly on the same page. > > Thanks for following up the comments given on the list. I am sure > there still are others which need to be looked at. > > Thanks, > Vishwas > > On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas wrote: >> Vishwas, >> >> Unfortunately, I'm not at the current IETF session. >> >> I will admit to some biases against SNMP configuration of protocols base= d on >> my experiences with trying to find use cases for configuring BGP via a M= IB. >> However, I'm also aware of operators who *do* want things like OSPF >> configurable via MIB. =A0Regardless of our own particular SNMP SET based >> prejudices, we must answer two questions: >> >> 1. Given the protocol cases where BFD may be fully configured, does the = MIB >> =A0 support this? >> 2. Given the protocol cases where BFD may have been configured outside o= f >> =A0 the SNMP system, does the MIB safely support configuration or manipu= lation >> =A0 of those sessions? >> >> Speaking as co-chair of the group for a moment to the BFD MIB authors: = =A0Do >> you have specific use cases for SNMP configuration in mind in the BFD MI= B? >> If not, should we consider moving the bulk of the MIB to read-only? >> (This question also goes out to members of the WG that may require MIB >> configuration support.) >> >> On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >>> you are right. the point i have raised is sessiontable should be read >>> only in bfd. i do not know what it would mean to have a session row >>> without a protocol waiting for the session notification. this is one >>> of the basic flaws in the mib. sessions are learned dynamically and we >>> cannot configure a row for every possible session. >> >> I agree that we cannot do this for every possible session. =A0Protocols >> requiring bootstrap of discriminator values MUST come from the outside o= f >> MIB configuration. =A0Given this, what should the current sessiontable s= how? >> One option that is reasonable within the context of SNMP would be to hav= e >> the logical row's StorageType be readOnly for rows created by sessions >> requiring bootstrap. =A0Alternatively, permanent, would permit manipulat= ion of >> row variables but with potentially serious impacts upon the protocol. >> >> As for "a protocol waiting for the session notification", it would be >> reasonable for a protocol-specific MIB to have their session/neighbor/et= c. >> table AUGMENTed with a BFD peering table. =A0Such a table would likely h= ave >> an "enable BFD" object, and at least one more object which referred to t= he >> bfdSessIndex of the associated BFD session. =A0Whether the configuration= for >> the BFD session was part of the augmentation table or in the base BFD MI= B is >> an implementation detail; I can see configuration scenarios both ways. = =A0The >> challenge for the MIB authors is to write text for the BFD MIB supportin= g >> each use case. >> >> By way of supporting the reverse mapping, the BFD MIB could also have a >> RowPointer into the appropriate BFD protocol-specific portion of its MIB= . >> >>> the second part is that we should allow objects to be configured on a >>> global or an interface basis so when a session is configured from a >>> protcol the default value of parameters is automatically inherited. on >>> seeing the cli from the vendor i mentioned its also done the way i >>> have mentioned. >> >> While I agree that such mechanisms are operationally useful, they are al= so >> vendor-specific forms of convenience. =A0At a SNMP table level, it is >> indistinguishable to have interface-specific configuration templates and= to >> have the user enter each of the same values from the template into the >> appropriate portion of the protocol MIB. >> >> Putting such templates into the base protocol MIB constrains the >> implementation to have a specific form that may be inappropriate to a gi= ven >> vendor. =A0In my opinion, that is out of scope for the BFD MIB but certa= inly >> within scope of vendor support in an enterprise MIB. >> >> -- Jeff >> > From tnadeau@lucidvision.com Sun Mar 21 12:09:56 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5F03A691F for ; Sun, 21 Mar 2010 12:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw-NqcU-PcVW for ; Sun, 21 Mar 2010 12:09:55 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 101223A685A for ; Sun, 21 Mar 2010 12:09:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 92DE1271411; Sun, 21 Mar 2010 15:10:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch2hqwbBaB-4; Sun, 21 Mar 2010 15:10:10 -0400 (EDT) Received: from [10.55.42.198] (unknown [166.205.10.104]) by lucidvision.com (Postfix) with ESMTP id CF3BA271409; Sun, 21 Mar 2010 15:10:06 -0400 (EDT) References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> Message-Id: From: Thomas Nadeau To: Vishwas Manral In-Reply-To: <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: BFD MIB Date: Sun, 21 Mar 2010 12:09:55 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 19:09:56 -0000 Before we go down the road of configuration we should ask the WG if this is needed; it's a lot of work and most SPs queried in the past did not want SNMP configuration. Tom On Mar 21, 2010, at 11:12 AM, Vishwas Manral wrote: > Hi Jeff, > > Just to add, if you look at the LDP MIB and others we will find it > similar to what I have been saying. In LDP the concept is called > entities. > > Thanks, > Vishwas > > On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral > wrote: >> Hi Jeff, >> >> I guess now we are exactly on the same page. >> >> Thanks for following up the comments given on the list. I am sure >> there still are others which need to be looked at. >> >> Thanks, >> Vishwas >> >> On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas wrote: >>> Vishwas, >>> >>> Unfortunately, I'm not at the current IETF session. >>> >>> I will admit to some biases against SNMP configuration of >>> protocols based on >>> my experiences with trying to find use cases for configuring BGP >>> via a MIB. >>> However, I'm also aware of operators who *do* want things like OSPF >>> configurable via MIB. Regardless of our own particular SNMP SET >>> based >>> prejudices, we must answer two questions: >>> >>> 1. Given the protocol cases where BFD may be fully configured, >>> does the MIB >>> support this? >>> 2. Given the protocol cases where BFD may have been configured >>> outside of >>> the SNMP system, does the MIB safely support configuration or >>> manipulation >>> of those sessions? >>> >>> Speaking as co-chair of the group for a moment to the BFD MIB >>> authors: Do >>> you have specific use cases for SNMP configuration in mind in the >>> BFD MIB? >>> If not, should we consider moving the bulk of the MIB to read-only? >>> (This question also goes out to members of the WG that may require >>> MIB >>> configuration support.) >>> >>> On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >>>> you are right. the point i have raised is sessiontable should be >>>> read >>>> only in bfd. i do not know what it would mean to have a session row >>>> without a protocol waiting for the session notification. this is >>>> one >>>> of the basic flaws in the mib. sessions are learned dynamically >>>> and we >>>> cannot configure a row for every possible session. >>> >>> I agree that we cannot do this for every possible session. >>> Protocols >>> requiring bootstrap of discriminator values MUST come from the >>> outside of >>> MIB configuration. Given this, what should the current >>> sessiontable show? >>> One option that is reasonable within the context of SNMP would be >>> to have >>> the logical row's StorageType be readOnly for rows created by >>> sessions >>> requiring bootstrap. Alternatively, permanent, would permit >>> manipulation of >>> row variables but with potentially serious impacts upon the >>> protocol. >>> >>> As for "a protocol waiting for the session notification", it would >>> be >>> reasonable for a protocol-specific MIB to have their session/ >>> neighbor/etc. >>> table AUGMENTed with a BFD peering table. Such a table would >>> likely have >>> an "enable BFD" object, and at least one more object which >>> referred to the >>> bfdSessIndex of the associated BFD session. Whether the >>> configuration for >>> the BFD session was part of the augmentation table or in the base >>> BFD MIB is >>> an implementation detail; I can see configuration scenarios both >>> ways. The >>> challenge for the MIB authors is to write text for the BFD MIB >>> supporting >>> each use case. >>> >>> By way of supporting the reverse mapping, the BFD MIB could also >>> have a >>> RowPointer into the appropriate BFD protocol-specific portion of >>> its MIB. >>> >>>> the second part is that we should allow objects to be configured >>>> on a >>>> global or an interface basis so when a session is configured from a >>>> protcol the default value of parameters is automatically >>>> inherited. on >>>> seeing the cli from the vendor i mentioned its also done the way i >>>> have mentioned. >>> >>> While I agree that such mechanisms are operationally useful, they >>> are also >>> vendor-specific forms of convenience. At a SNMP table level, it is >>> indistinguishable to have interface-specific configuration >>> templates and to >>> have the user enter each of the same values from the template into >>> the >>> appropriate portion of the protocol MIB. >>> >>> Putting such templates into the base protocol MIB constrains the >>> implementation to have a specific form that may be inappropriate >>> to a given >>> vendor. In my opinion, that is out of scope for the BFD MIB but >>> certainly >>> within scope of vendor support in an enterprise MIB. >>> >>> -- Jeff >>> >> > From dward@juniper.net Sun Mar 21 13:04:55 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146C73A68A2 for ; Sun, 21 Mar 2010 13:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.734 X-Spam-Level: X-Spam-Status: No, score=-4.734 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOyxV8v6t7N7 for ; Sun, 21 Mar 2010 13:04:54 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id DA4E73A681E for ; Sun, 21 Mar 2010 13:03:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS6Z7o3+zi0V50zlh9tRlgWBTuSAKQ34k@postini.com; Sun, 21 Mar 2010 13:05:10 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sun, 21 Mar 2010 13:02:19 -0700 From: David Ward To: Thomas Nadeau Date: Sun, 21 Mar 2010 13:02:05 -0700 Subject: Re: BFD MIB Thread-Topic: BFD MIB Thread-Index: AcrJMWk4wW6EkyjgRlqaTqFXjFEO1g== Message-ID: <4369C525-F048-4DF6-8EC4-1DA4C035BC66@juniper.net> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 20:04:55 -0000 Tom - We know for mpls-tp we'll need some way to configure bfd. Snmp or =20 netconf or??? Will be required. Can you check the mpls-tp nms reqmts =20 draft? -DWard On Mar 21, 2010, at 12:10, "Thomas Nadeau" =20 wrote: > Before we go down the road of configuration we should ask the WG if > this is needed; it's a lot of work and most SPs queried in the past > did not want SNMP configuration. > > Tom > > > > > On Mar 21, 2010, at 11:12 AM, Vishwas Manral > wrote: > >> Hi Jeff, >> >> Just to add, if you look at the LDP MIB and others we will find it >> similar to what I have been saying. In LDP the concept is called >> entities. >> >> Thanks, >> Vishwas >> >> On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral >> wrote: >>> Hi Jeff, >>> >>> I guess now we are exactly on the same page. >>> >>> Thanks for following up the comments given on the list. I am sure >>> there still are others which need to be looked at. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas =20 >>> wrote: >>>> Vishwas, >>>> >>>> Unfortunately, I'm not at the current IETF session. >>>> >>>> I will admit to some biases against SNMP configuration of >>>> protocols based on >>>> my experiences with trying to find use cases for configuring BGP >>>> via a MIB. >>>> However, I'm also aware of operators who *do* want things like OSPF >>>> configurable via MIB. Regardless of our own particular SNMP SET >>>> based >>>> prejudices, we must answer two questions: >>>> >>>> 1. Given the protocol cases where BFD may be fully configured, >>>> does the MIB >>>> support this? >>>> 2. Given the protocol cases where BFD may have been configured >>>> outside of >>>> the SNMP system, does the MIB safely support configuration or >>>> manipulation >>>> of those sessions? >>>> >>>> Speaking as co-chair of the group for a moment to the BFD MIB >>>> authors: Do >>>> you have specific use cases for SNMP configuration in mind in the >>>> BFD MIB? >>>> If not, should we consider moving the bulk of the MIB to read-only? >>>> (This question also goes out to members of the WG that may require >>>> MIB >>>> configuration support.) >>>> >>>> On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >>>>> you are right. the point i have raised is sessiontable should be >>>>> read >>>>> only in bfd. i do not know what it would mean to have a session =20 >>>>> row >>>>> without a protocol waiting for the session notification. this is >>>>> one >>>>> of the basic flaws in the mib. sessions are learned dynamically >>>>> and we >>>>> cannot configure a row for every possible session. >>>> >>>> I agree that we cannot do this for every possible session. >>>> Protocols >>>> requiring bootstrap of discriminator values MUST come from the >>>> outside of >>>> MIB configuration. Given this, what should the current >>>> sessiontable show? >>>> One option that is reasonable within the context of SNMP would be >>>> to have >>>> the logical row's StorageType be readOnly for rows created by >>>> sessions >>>> requiring bootstrap. Alternatively, permanent, would permit >>>> manipulation of >>>> row variables but with potentially serious impacts upon the >>>> protocol. >>>> >>>> As for "a protocol waiting for the session notification", it would >>>> be >>>> reasonable for a protocol-specific MIB to have their session/ >>>> neighbor/etc. >>>> table AUGMENTed with a BFD peering table. Such a table would >>>> likely have >>>> an "enable BFD" object, and at least one more object which >>>> referred to the >>>> bfdSessIndex of the associated BFD session. Whether the >>>> configuration for >>>> the BFD session was part of the augmentation table or in the base >>>> BFD MIB is >>>> an implementation detail; I can see configuration scenarios both >>>> ways. The >>>> challenge for the MIB authors is to write text for the BFD MIB >>>> supporting >>>> each use case. >>>> >>>> By way of supporting the reverse mapping, the BFD MIB could also >>>> have a >>>> RowPointer into the appropriate BFD protocol-specific portion of >>>> its MIB. >>>> >>>>> the second part is that we should allow objects to be configured >>>>> on a >>>>> global or an interface basis so when a session is configured =20 >>>>> from a >>>>> protcol the default value of parameters is automatically >>>>> inherited. on >>>>> seeing the cli from the vendor i mentioned its also done the way i >>>>> have mentioned. >>>> >>>> While I agree that such mechanisms are operationally useful, they >>>> are also >>>> vendor-specific forms of convenience. At a SNMP table level, it is >>>> indistinguishable to have interface-specific configuration >>>> templates and to >>>> have the user enter each of the same values from the template into >>>> the >>>> appropriate portion of the protocol MIB. >>>> >>>> Putting such templates into the base protocol MIB constrains the >>>> implementation to have a specific form that may be inappropriate >>>> to a given >>>> vendor. In my opinion, that is out of scope for the BFD MIB but >>>> certainly >>>> within scope of vendor support in an enterprise MIB. >>>> >>>> -- Jeff >>>> >>> >> From tnadeau@lucidvision.com Sun Mar 21 13:20:33 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989F03A67FD for ; Sun, 21 Mar 2010 13:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNy7DIwrUNxP for ; Sun, 21 Mar 2010 13:20:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id AB7E63A6813 for ; Sun, 21 Mar 2010 13:20:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id E589A2716C8; Sun, 21 Mar 2010 16:20:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHtzJXBIT1c3; Sun, 21 Mar 2010 16:20:22 -0400 (EDT) Received: from [10.55.42.198] (unknown [166.205.10.104]) by lucidvision.com (Postfix) with ESMTP id 4CB1B2716C0; Sun, 21 Mar 2010 16:20:18 -0400 (EDT) References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> <4369C525-F048-4DF6-8EC4-1DA4C035BC66@juniper.net> Message-Id: From: Thomas Nadeau To: David Ward In-Reply-To: <4369C525-F048-4DF6-8EC4-1DA4C035BC66@juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: BFD MIB Date: Sun, 21 Mar 2010 13:20:08 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 20:20:33 -0000 I will check but from memory all of the above are allowed. Tom On Mar 21, 2010, at 1:02 PM, David Ward wrote: > Tom - > > We know for mpls-tp we'll need some way to configure bfd. Snmp or > netconf or??? Will be required. Can you check the mpls-tp nms reqmts > draft? > > -DWard > > > > > > On Mar 21, 2010, at 12:10, "Thomas Nadeau" > wrote: > >> Before we go down the road of configuration we should ask the WG if >> this is needed; it's a lot of work and most SPs queried in the past >> did not want SNMP configuration. >> >> Tom >> >> >> >> >> On Mar 21, 2010, at 11:12 AM, Vishwas Manral >> wrote: >> >>> Hi Jeff, >>> >>> Just to add, if you look at the LDP MIB and others we will find it >>> similar to what I have been saying. In LDP the concept is called >>> entities. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral >>> wrote: >>>> Hi Jeff, >>>> >>>> I guess now we are exactly on the same page. >>>> >>>> Thanks for following up the comments given on the list. I am sure >>>> there still are others which need to be looked at. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas >>>> wrote: >>>>> Vishwas, >>>>> >>>>> Unfortunately, I'm not at the current IETF session. >>>>> >>>>> I will admit to some biases against SNMP configuration of >>>>> protocols based on >>>>> my experiences with trying to find use cases for configuring BGP >>>>> via a MIB. >>>>> However, I'm also aware of operators who *do* want things like >>>>> OSPF >>>>> configurable via MIB. Regardless of our own particular SNMP SET >>>>> based >>>>> prejudices, we must answer two questions: >>>>> >>>>> 1. Given the protocol cases where BFD may be fully configured, >>>>> does the MIB >>>>> support this? >>>>> 2. Given the protocol cases where BFD may have been configured >>>>> outside of >>>>> the SNMP system, does the MIB safely support configuration or >>>>> manipulation >>>>> of those sessions? >>>>> >>>>> Speaking as co-chair of the group for a moment to the BFD MIB >>>>> authors: Do >>>>> you have specific use cases for SNMP configuration in mind in the >>>>> BFD MIB? >>>>> If not, should we consider moving the bulk of the MIB to read- >>>>> only? >>>>> (This question also goes out to members of the WG that may require >>>>> MIB >>>>> configuration support.) >>>>> >>>>> On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >>>>>> you are right. the point i have raised is sessiontable should be >>>>>> read >>>>>> only in bfd. i do not know what it would mean to have a session >>>>>> row >>>>>> without a protocol waiting for the session notification. this is >>>>>> one >>>>>> of the basic flaws in the mib. sessions are learned dynamically >>>>>> and we >>>>>> cannot configure a row for every possible session. >>>>> >>>>> I agree that we cannot do this for every possible session. >>>>> Protocols >>>>> requiring bootstrap of discriminator values MUST come from the >>>>> outside of >>>>> MIB configuration. Given this, what should the current >>>>> sessiontable show? >>>>> One option that is reasonable within the context of SNMP would be >>>>> to have >>>>> the logical row's StorageType be readOnly for rows created by >>>>> sessions >>>>> requiring bootstrap. Alternatively, permanent, would permit >>>>> manipulation of >>>>> row variables but with potentially serious impacts upon the >>>>> protocol. >>>>> >>>>> As for "a protocol waiting for the session notification", it would >>>>> be >>>>> reasonable for a protocol-specific MIB to have their session/ >>>>> neighbor/etc. >>>>> table AUGMENTed with a BFD peering table. Such a table would >>>>> likely have >>>>> an "enable BFD" object, and at least one more object which >>>>> referred to the >>>>> bfdSessIndex of the associated BFD session. Whether the >>>>> configuration for >>>>> the BFD session was part of the augmentation table or in the base >>>>> BFD MIB is >>>>> an implementation detail; I can see configuration scenarios both >>>>> ways. The >>>>> challenge for the MIB authors is to write text for the BFD MIB >>>>> supporting >>>>> each use case. >>>>> >>>>> By way of supporting the reverse mapping, the BFD MIB could also >>>>> have a >>>>> RowPointer into the appropriate BFD protocol-specific portion of >>>>> its MIB. >>>>> >>>>>> the second part is that we should allow objects to be configured >>>>>> on a >>>>>> global or an interface basis so when a session is configured >>>>>> from a >>>>>> protcol the default value of parameters is automatically >>>>>> inherited. on >>>>>> seeing the cli from the vendor i mentioned its also done the >>>>>> way i >>>>>> have mentioned. >>>>> >>>>> While I agree that such mechanisms are operationally useful, they >>>>> are also >>>>> vendor-specific forms of convenience. At a SNMP table level, it >>>>> is >>>>> indistinguishable to have interface-specific configuration >>>>> templates and to >>>>> have the user enter each of the same values from the template into >>>>> the >>>>> appropriate portion of the protocol MIB. >>>>> >>>>> Putting such templates into the base protocol MIB constrains the >>>>> implementation to have a specific form that may be inappropriate >>>>> to a given >>>>> vendor. In my opinion, that is out of scope for the BFD MIB but >>>>> certainly >>>>> within scope of vendor support in an enterprise MIB. >>>>> >>>>> -- Jeff >>>>> >>>> >>> > From vishwas.ietf@gmail.com Sun Mar 21 21:30:44 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951F03A6860 for ; Sun, 21 Mar 2010 21:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lxx+pi3qdMcQ for ; Sun, 21 Mar 2010 21:30:43 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 295823A6845 for ; Sun, 21 Mar 2010 21:30:42 -0700 (PDT) Received: by gwaa11 with SMTP id a11so1361212gwa.31 for ; Sun, 21 Mar 2010 21:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rTlFhRd7aDIxM/HBvTYHXdmWf+vr9BSWiEHJkFNK1gQ=; b=SMFihw0y6Saq8beG7a4ffmrz35NeKdUT9OH8pEJWM8fFGm1riUnOmjZrxLP/7OWZ10 Orv9SYOru78UDZPqvtysiEh65OGekVxC1EId0etouquwJytExY53DIxL+20a27XHuiOp PP/Fyq8qtG5XXd/AICvSDHHMcamYzcEZNrmXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eYllKA7EwBLhPXwvS/92g5VcDxG7ptR2KOj00xaR9xoYTlm5TcKdJpmjODmCPqHVK9 r2rk8RR2kBd7sWkAGLNVx2eE/PkYxlL+Kxix5vFcs3zmO01uMkpRA/g6Mg4j2NXcOWBB Chp+dRw3LZuiHD86he86Jk7HEJlLRgB+CaPCc= MIME-Version: 1.0 Received: by 10.150.75.8 with SMTP id x8mr2850881yba.126.1269232253111; Sun, 21 Mar 2010 21:30:53 -0700 (PDT) In-Reply-To: References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> Date: Sun, 21 Mar 2010 21:30:53 -0700 Message-ID: <77ead0ec1003212130r6101de5cn13be781f175d5aa1@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 04:30:44 -0000 Hi Thomas, If we ever want to allow non-default parameters for a session we have to allow this. It now depends whether we want that or not. Thanks, Vishwas On Sun, Mar 21, 2010 at 12:09 PM, Thomas Nadeau w= rote: > Before we go down the road of configuration we should ask the WG if this = is > needed; it's a lot of work and most SPs queried in the past did not want > SNMP configuration. > > Tom > > > > > On Mar 21, 2010, at 11:12 AM, Vishwas Manral wro= te: > >> Hi Jeff, >> >> Just to add, if you look at the LDP MIB and others we will find it >> similar to what I have been saying. In LDP the concept is called >> entities. >> >> Thanks, >> Vishwas >> >> On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral >> wrote: >>> >>> Hi Jeff, >>> >>> I guess now we are exactly on the same page. >>> >>> Thanks for following up the comments given on the list. I am sure >>> there still are others which need to be looked at. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas wrote: >>>> >>>> Vishwas, >>>> >>>> Unfortunately, I'm not at the current IETF session. >>>> >>>> I will admit to some biases against SNMP configuration of protocols >>>> based on >>>> my experiences with trying to find use cases for configuring BGP via a >>>> MIB. >>>> However, I'm also aware of operators who *do* want things like OSPF >>>> configurable via MIB. =A0Regardless of our own particular SNMP SET bas= ed >>>> prejudices, we must answer two questions: >>>> >>>> 1. Given the protocol cases where BFD may be fully configured, does th= e >>>> MIB >>>> =A0support this? >>>> 2. Given the protocol cases where BFD may have been configured outside >>>> of >>>> =A0the SNMP system, does the MIB safely support configuration or >>>> manipulation >>>> =A0of those sessions? >>>> >>>> Speaking as co-chair of the group for a moment to the BFD MIB authors: >>>> =A0Do >>>> you have specific use cases for SNMP configuration in mind in the BFD >>>> MIB? >>>> If not, should we consider moving the bulk of the MIB to read-only? >>>> (This question also goes out to members of the WG that may require MIB >>>> configuration support.) >>>> >>>> On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >>>>> >>>>> you are right. the point i have raised is sessiontable should be read >>>>> only in bfd. i do not know what it would mean to have a session row >>>>> without a protocol waiting for the session notification. this is one >>>>> of the basic flaws in the mib. sessions are learned dynamically and w= e >>>>> cannot configure a row for every possible session. >>>> >>>> I agree that we cannot do this for every possible session. =A0Protocol= s >>>> requiring bootstrap of discriminator values MUST come from the outside >>>> of >>>> MIB configuration. =A0Given this, what should the current sessiontable >>>> show? >>>> One option that is reasonable within the context of SNMP would be to >>>> have >>>> the logical row's StorageType be readOnly for rows created by sessions >>>> requiring bootstrap. =A0Alternatively, permanent, would permit >>>> manipulation of >>>> row variables but with potentially serious impacts upon the protocol. >>>> >>>> As for "a protocol waiting for the session notification", it would be >>>> reasonable for a protocol-specific MIB to have their >>>> session/neighbor/etc. >>>> table AUGMENTed with a BFD peering table. =A0Such a table would likely >>>> have >>>> an "enable BFD" object, and at least one more object which referred to >>>> the >>>> bfdSessIndex of the associated BFD session. =A0Whether the configurati= on >>>> for >>>> the BFD session was part of the augmentation table or in the base BFD >>>> MIB is >>>> an implementation detail; I can see configuration scenarios both ways. >>>> =A0The >>>> challenge for the MIB authors is to write text for the BFD MIB >>>> supporting >>>> each use case. >>>> >>>> By way of supporting the reverse mapping, the BFD MIB could also have = a >>>> RowPointer into the appropriate BFD protocol-specific portion of its >>>> MIB. >>>> >>>>> the second part is that we should allow objects to be configured on a >>>>> global or an interface basis so when a session is configured from a >>>>> protcol the default value of parameters is automatically inherited. o= n >>>>> seeing the cli from the vendor i mentioned its also done the way i >>>>> have mentioned. >>>> >>>> While I agree that such mechanisms are operationally useful, they are >>>> also >>>> vendor-specific forms of convenience. =A0At a SNMP table level, it is >>>> indistinguishable to have interface-specific configuration templates a= nd >>>> to >>>> have the user enter each of the same values from the template into the >>>> appropriate portion of the protocol MIB. >>>> >>>> Putting such templates into the base protocol MIB constrains the >>>> implementation to have a specific form that may be inappropriate to a >>>> given >>>> vendor. =A0In my opinion, that is out of scope for the BFD MIB but >>>> certainly >>>> within scope of vendor support in an enterprise MIB. >>>> >>>> -- Jeff >>>> >>> >> > From tnadeau@lucidvision.com Sun Mar 21 22:11:21 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11403A695F for ; Sun, 21 Mar 2010 22:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcBH84no0MId for ; Sun, 21 Mar 2010 22:11:19 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 49F7E3A69CA for ; Sun, 21 Mar 2010 22:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 08F81272996; Mon, 22 Mar 2010 01:10:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XTMLgnJ-CTa; Mon, 22 Mar 2010 01:10:35 -0400 (EDT) Received: from [10.60.246.203] (unknown [166.205.139.169]) by lucidvision.com (Postfix) with ESMTP id AA68A27298E; Mon, 22 Mar 2010 01:10:31 -0400 (EDT) References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> <77ead0ec1003212130r6101de5cn13be781f175d5aa1@mail.gmail.com> Message-Id: <3C64D748-E06E-42D9-8496-EEFF12EC341B@lucidvision.com> From: Thomas Nadeau To: Vishwas Manral In-Reply-To: <77ead0ec1003212130r6101de5cn13be781f175d5aa1@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: BFD MIB Date: Sun, 21 Mar 2010 22:10:16 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 05:11:21 -0000 That is only true if you assume configuration via Snmp. While a possibility, configuration via other means will achieve the same result, and can be reflected in the MIB. Tom On Mar 21, 2010, at 9:30 PM, Vishwas Manral wrote: > Hi Thomas, > > If we ever want to allow non-default parameters for a session we have > to allow this. > > It now depends whether we want that or not. > > Thanks, > Vishwas > > On Sun, Mar 21, 2010 at 12:09 PM, Thomas Nadeau > wrote: >> Before we go down the road of configuration we should ask the WG if >> this is >> needed; it's a lot of work and most SPs queried in the past did not >> want >> SNMP configuration. >> >> Tom >> >> >> >> >> On Mar 21, 2010, at 11:12 AM, Vishwas Manral >> wrote: >> >>> Hi Jeff, >>> >>> Just to add, if you look at the LDP MIB and others we will find it >>> similar to what I have been saying. In LDP the concept is called >>> entities. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral >> > >>> wrote: >>>> >>>> Hi Jeff, >>>> >>>> I guess now we are exactly on the same page. >>>> >>>> Thanks for following up the comments given on the list. I am sure >>>> there still are others which need to be looked at. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas >>>> wrote: >>>>> >>>>> Vishwas, >>>>> >>>>> Unfortunately, I'm not at the current IETF session. >>>>> >>>>> I will admit to some biases against SNMP configuration of >>>>> protocols >>>>> based on >>>>> my experiences with trying to find use cases for configuring BGP >>>>> via a >>>>> MIB. >>>>> However, I'm also aware of operators who *do* want things like >>>>> OSPF >>>>> configurable via MIB. Regardless of our own particular SNMP SET >>>>> based >>>>> prejudices, we must answer two questions: >>>>> >>>>> 1. Given the protocol cases where BFD may be fully configured, >>>>> does the >>>>> MIB >>>>> support this? >>>>> 2. Given the protocol cases where BFD may have been configured >>>>> outside >>>>> of >>>>> the SNMP system, does the MIB safely support configuration or >>>>> manipulation >>>>> of those sessions? >>>>> >>>>> Speaking as co-chair of the group for a moment to the BFD MIB >>>>> authors: >>>>> Do >>>>> you have specific use cases for SNMP configuration in mind in >>>>> the BFD >>>>> MIB? >>>>> If not, should we consider moving the bulk of the MIB to read- >>>>> only? >>>>> (This question also goes out to members of the WG that may >>>>> require MIB >>>>> configuration support.) >>>>> >>>>> On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >>>>>> >>>>>> you are right. the point i have raised is sessiontable should >>>>>> be read >>>>>> only in bfd. i do not know what it would mean to have a session >>>>>> row >>>>>> without a protocol waiting for the session notification. this >>>>>> is one >>>>>> of the basic flaws in the mib. sessions are learned dynamically >>>>>> and we >>>>>> cannot configure a row for every possible session. >>>>> >>>>> I agree that we cannot do this for every possible session. >>>>> Protocols >>>>> requiring bootstrap of discriminator values MUST come from the >>>>> outside >>>>> of >>>>> MIB configuration. Given this, what should the current >>>>> sessiontable >>>>> show? >>>>> One option that is reasonable within the context of SNMP would >>>>> be to >>>>> have >>>>> the logical row's StorageType be readOnly for rows created by >>>>> sessions >>>>> requiring bootstrap. Alternatively, permanent, would permit >>>>> manipulation of >>>>> row variables but with potentially serious impacts upon the >>>>> protocol. >>>>> >>>>> As for "a protocol waiting for the session notification", it >>>>> would be >>>>> reasonable for a protocol-specific MIB to have their >>>>> session/neighbor/etc. >>>>> table AUGMENTed with a BFD peering table. Such a table would >>>>> likely >>>>> have >>>>> an "enable BFD" object, and at least one more object which >>>>> referred to >>>>> the >>>>> bfdSessIndex of the associated BFD session. Whether the >>>>> configuration >>>>> for >>>>> the BFD session was part of the augmentation table or in the >>>>> base BFD >>>>> MIB is >>>>> an implementation detail; I can see configuration scenarios both >>>>> ways. >>>>> The >>>>> challenge for the MIB authors is to write text for the BFD MIB >>>>> supporting >>>>> each use case. >>>>> >>>>> By way of supporting the reverse mapping, the BFD MIB could also >>>>> have a >>>>> RowPointer into the appropriate BFD protocol-specific portion of >>>>> its >>>>> MIB. >>>>> >>>>>> the second part is that we should allow objects to be >>>>>> configured on a >>>>>> global or an interface basis so when a session is configured >>>>>> from a >>>>>> protcol the default value of parameters is automatically >>>>>> inherited. on >>>>>> seeing the cli from the vendor i mentioned its also done the >>>>>> way i >>>>>> have mentioned. >>>>> >>>>> While I agree that such mechanisms are operationally useful, >>>>> they are >>>>> also >>>>> vendor-specific forms of convenience. At a SNMP table level, it >>>>> is >>>>> indistinguishable to have interface-specific configuration >>>>> templates and >>>>> to >>>>> have the user enter each of the same values from the template >>>>> into the >>>>> appropriate portion of the protocol MIB. >>>>> >>>>> Putting such templates into the base protocol MIB constrains the >>>>> implementation to have a specific form that may be inappropriate >>>>> to a >>>>> given >>>>> vendor. In my opinion, that is out of scope for the BFD MIB but >>>>> certainly >>>>> within scope of vendor support in an enterprise MIB. >>>>> >>>>> -- Jeff >>>>> >>>> >>> >> > From vishwas.ietf@gmail.com Sun Mar 21 22:26:42 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2083A69CA for ; Sun, 21 Mar 2010 22:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsHvjh3N8wFd for ; Sun, 21 Mar 2010 22:26:41 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 6B0AE3A6B1F for ; Sun, 21 Mar 2010 22:20:22 -0700 (PDT) Received: by ywh38 with SMTP id 38so2709607ywh.29 for ; Sun, 21 Mar 2010 22:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FHhqJMZo8/k3C5lyNjFBJHl+2nAEpg/eWxlPsMN94G0=; b=P17V0510F2rT5ySrbbkRgRJYxC9JnBCAwNYTnQPri2yhkMyKX2+hdglqlGc2E9le/z 4crnBVXFBGevGrIiM50CpsmWGpawpnO/7qamNnGQPOTSHKM74B8nwtadFEIFQimCevEb nVXB1U9rGX76wtCg8x2JYalkkM3yB9ypbBtog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eE/zVMityAPDgcOX/eiBV4dOrJiidkC5SK/WuYwxXe4CzCgI3gNzG6wlAFJRIoWgaa eufdkUaaLbqkltr4PDaFLi1XYgon1K2/zZVEgUlZLUuPhtnOo+yrbSS6ln/Vk5sOqDH6 qiWp+bzbxLSHUlxQbjwKyG6PPVWP3WHrjDItA= MIME-Version: 1.0 Received: by 10.150.210.2 with SMTP id i2mr6121361ybg.168.1269235222361; Sun, 21 Mar 2010 22:20:22 -0700 (PDT) In-Reply-To: <3C64D748-E06E-42D9-8496-EEFF12EC341B@lucidvision.com> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> <77ead0ec1003212130r6101de5cn13be781f175d5aa1@mail.gmail.com> <3C64D748-E06E-42D9-8496-EEFF12EC341B@lucidvision.com> Date: Sun, 21 Mar 2010 22:20:22 -0700 Message-ID: <77ead0ec1003212220p6a62e1ddvff8be1c5cf64428c@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 05:26:42 -0000 Hi Tom, I agree if we are talking about using CLI or other means to achieve this we do not necessarily need the MIb to support the same. However let me tell you, we have customers who want to configure the same through MIB (that is one of the reasons we have gone into actully supporting the MIB). If you are at the IETF we can discuss this as well as all MPLS-TC MIB which we need to correct and need a non disruptive way to do the same. Thanks, Vishwas On Sun, Mar 21, 2010 at 10:10 PM, Thomas Nadeau w= rote: > That is only true if you assume configuration via Snmp. =A0While a > possibility, configuration via other means will achieve the same result, = and > can be reflected in the MIB. > > Tom > > > > > On Mar 21, 2010, at 9:30 PM, Vishwas Manral wrot= e: > >> Hi Thomas, >> >> If we ever want to allow non-default parameters for a session we have >> to allow this. >> >> It now depends whether we want that or not. >> >> Thanks, >> Vishwas >> >> On Sun, Mar 21, 2010 at 12:09 PM, Thomas Nadeau >> wrote: >>> >>> Before we go down the road of configuration we should ask the WG if thi= s >>> is >>> needed; it's a lot of work and most SPs queried in the past did not wan= t >>> SNMP configuration. >>> >>> Tom >>> >>> >>> >>> >>> On Mar 21, 2010, at 11:12 AM, Vishwas Manral >>> wrote: >>> >>>> Hi Jeff, >>>> >>>> Just to add, if you look at the LDP MIB and others we will find it >>>> similar to what I have been saying. In LDP the concept is called >>>> entities. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, Mar 21, 2010 at 11:11 AM, Vishwas Manral >>>> >>>> wrote: >>>>> >>>>> Hi Jeff, >>>>> >>>>> I guess now we are exactly on the same page. >>>>> >>>>> Thanks for following up the comments given on the list. I am sure >>>>> there still are others which need to be looked at. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Sun, Mar 21, 2010 at 5:49 AM, Jeffrey Haas wrote: >>>>>> >>>>>> Vishwas, >>>>>> >>>>>> Unfortunately, I'm not at the current IETF session. >>>>>> >>>>>> I will admit to some biases against SNMP configuration of protocols >>>>>> based on >>>>>> my experiences with trying to find use cases for configuring BGP via= a >>>>>> MIB. >>>>>> However, I'm also aware of operators who *do* want things like OSPF >>>>>> configurable via MIB. =A0Regardless of our own particular SNMP SET b= ased >>>>>> prejudices, we must answer two questions: >>>>>> >>>>>> 1. Given the protocol cases where BFD may be fully configured, does >>>>>> the >>>>>> MIB >>>>>> =A0support this? >>>>>> 2. Given the protocol cases where BFD may have been configured outsi= de >>>>>> of >>>>>> =A0the SNMP system, does the MIB safely support configuration or >>>>>> manipulation >>>>>> =A0of those sessions? >>>>>> >>>>>> Speaking as co-chair of the group for a moment to the BFD MIB author= s: >>>>>> =A0Do >>>>>> you have specific use cases for SNMP configuration in mind in the BF= D >>>>>> MIB? >>>>>> If not, should we consider moving the bulk of the MIB to read-only? >>>>>> (This question also goes out to members of the WG that may require M= IB >>>>>> configuration support.) >>>>>> >>>>>> On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: >>>>>>> >>>>>>> you are right. the point i have raised is sessiontable should be re= ad >>>>>>> only in bfd. i do not know what it would mean to have a session row >>>>>>> without a protocol waiting for the session notification. this is on= e >>>>>>> of the basic flaws in the mib. sessions are learned dynamically and >>>>>>> we >>>>>>> cannot configure a row for every possible session. >>>>>> >>>>>> I agree that we cannot do this for every possible session. =A0Protoc= ols >>>>>> requiring bootstrap of discriminator values MUST come from the outsi= de >>>>>> of >>>>>> MIB configuration. =A0Given this, what should the current sessiontab= le >>>>>> show? >>>>>> One option that is reasonable within the context of SNMP would be to >>>>>> have >>>>>> the logical row's StorageType be readOnly for rows created by sessio= ns >>>>>> requiring bootstrap. =A0Alternatively, permanent, would permit >>>>>> manipulation of >>>>>> row variables but with potentially serious impacts upon the protocol= . >>>>>> >>>>>> As for "a protocol waiting for the session notification", it would b= e >>>>>> reasonable for a protocol-specific MIB to have their >>>>>> session/neighbor/etc. >>>>>> table AUGMENTed with a BFD peering table. =A0Such a table would like= ly >>>>>> have >>>>>> an "enable BFD" object, and at least one more object which referred = to >>>>>> the >>>>>> bfdSessIndex of the associated BFD session. =A0Whether the configura= tion >>>>>> for >>>>>> the BFD session was part of the augmentation table or in the base BF= D >>>>>> MIB is >>>>>> an implementation detail; I can see configuration scenarios both way= s. >>>>>> =A0The >>>>>> challenge for the MIB authors is to write text for the BFD MIB >>>>>> supporting >>>>>> each use case. >>>>>> >>>>>> By way of supporting the reverse mapping, the BFD MIB could also hav= e >>>>>> a >>>>>> RowPointer into the appropriate BFD protocol-specific portion of its >>>>>> MIB. >>>>>> >>>>>>> the second part is that we should allow objects to be configured on= a >>>>>>> global or an interface basis so when a session is configured from a >>>>>>> protcol the default value of parameters is automatically inherited. >>>>>>> on >>>>>>> seeing the cli from the vendor i mentioned its also done the way i >>>>>>> have mentioned. >>>>>> >>>>>> While I agree that such mechanisms are operationally useful, they ar= e >>>>>> also >>>>>> vendor-specific forms of convenience. =A0At a SNMP table level, it i= s >>>>>> indistinguishable to have interface-specific configuration templates >>>>>> and >>>>>> to >>>>>> have the user enter each of the same values from the template into t= he >>>>>> appropriate portion of the protocol MIB. >>>>>> >>>>>> Putting such templates into the base protocol MIB constrains the >>>>>> implementation to have a specific form that may be inappropriate to = a >>>>>> given >>>>>> vendor. =A0In my opinion, that is out of scope for the BFD MIB but >>>>>> certainly >>>>>> within scope of vendor support in an enterprise MIB. >>>>>> >>>>>> -- Jeff >>>>>> >>>>> >>>> >>> >> > From mahesh.akula@wipro.com Mon Mar 22 00:40:23 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE603A683A for ; Mon, 22 Mar 2010 00:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-1.772, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkyXPoUOBTGS for ; Mon, 22 Mar 2010 00:40:22 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id B12523A67FF for ; Mon, 22 Mar 2010 00:40:18 -0700 (PDT) X-AuditID: cb5bdd57-b7b7aae0000079a9-b5-4ba71ef15ec6 Received: from blr-ec-aa01.wipro.com ( [10.201.18.41]) by wipro-blr-out01.wipro.com (Symantec Mail Security) with SMTP id 11.99.31145.1FE17AB4; Mon, 22 Mar 2010 13:10:33 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 13:10:33 +0530 Received: from blr-ec-bh03.wipro.com ([10.201.50.97]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 13:10:31 +0530 Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 13:10:32 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on the BFD MIB. Date: Mon, 22 Mar 2010 13:08:01 +0530 Message-ID: <6CD4ED5690208D4186E7E46B4C13B7EC09A2CFF4@HYD-MDP-MBX01.wipro.com> In-Reply-To: <20100320163352.GB31380@slice> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on the BFD MIB. Thread-Index: AcrISyJjOcgMHR/QQ2qT+2DpNu724gBRzHpw References: <43AE1BF0-C74F-4521-A233-4CF40C2616FB@lucidvision.com> <6CD4ED5690208D4186E7E46B4C13B7EC099A82C0@HYD-MDP-MBX01.wipro.com> <20100320163352.GB31380@slice> From: To: X-OriginalArrivalTime: 22 Mar 2010 07:40:32.0065 (UTC) FILETIME=[F3788310:01CAC992] X-Brightmail-Tracker: AAAAAA== Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 07:40:23 -0000 Hi Jeff, Exactly, I'm suggesting the authors of the BFD MIB to rephrase the description for all the counters the way you mentioned it. Thanks, Mahesh.=20 -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Saturday, March 20, 2010 10:04 PM To: Mahesh Akula (WT01 - Telecom Equipment) Cc: rtg-bfd@ietf.org Subject: Re: Comments on the BFD MIB. Mahesh, On Thu, Mar 11, 2010 at 05:57:01PM +0530, mahesh.akula@wipro.com wrote: > Description of the Performance counters in BFD MIB seems to have an=20 > issue. > =20 > For example if we consider the bfdSessPerfCtrlPktInHC counter,=20 > description says that value of the "bfdSessPerfCtrlPktInHC must be=20 > equal to the least significant 32 bits of bfdSessPerfCtrlPktIn if=20 > bfdSessPerfCtrlPktInHC is supported". > =20 > What does it mean by least significant 32 bits in a 32 bit counter?=20 See RFC 2863, section 3.1.6 as an example: : When 64-bit counters are in use, the 32-bit counters MUST still be : available. They will report the low 32-bits of the associated 64-bit : count (e.g., ifInOctets will report the least significant 32 bits of : ifHCInOctets). This enhances inter-operability with existing : implementations at a very minimal cost to agents. I suspect what the MIB authors meant was that the Counter32 objects should contain text that say something roughly like the following: bfdSessPerfCtrlPktIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of BFD control messages received for this BFD session. This value MUST be equal to the least significant 32 bits of bfdSessPerfCtrlPktInHC." ::=3D { bfdSessPerfEntry 1 } bfdSessPerfCtrlPktInHC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the total number of BFD control messages received for this BFD session." ::=3D { bfdSessPerfEntry 14 } -- Jeff From tnadeau@lucidvision.com Mon Mar 22 06:04:27 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBFC28C104 for ; Mon, 22 Mar 2010 06:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99ACNQATRpfB for ; Mon, 22 Mar 2010 06:04:26 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id C498B3A68D1 for ; Mon, 22 Mar 2010 06:04:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 485D7273CB4; Mon, 22 Mar 2010 09:04:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myFeivQvV391; Mon, 22 Mar 2010 09:04:19 -0400 (EDT) Received: from [172.27.171.100] (207.88.181.2.ptr.us.xo.net [207.88.181.2]) by lucidvision.com (Postfix) with ESMTP id 1BCBB273CA9; Mon, 22 Mar 2010 09:04:18 -0400 (EDT) Subject: Re: Comments on the BFD MIB. Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <6CD4ED5690208D4186E7E46B4C13B7EC09A2CFF4@HYD-MDP-MBX01.wipro.com> Date: Mon, 22 Mar 2010 06:04:16 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <43AE1BF0-C74F-4521-A233-4CF40C2616FB@lucidvision.com> <6CD4ED5690208D4186E7E46B4C13B7EC099A82C0@HYD-MDP-MBX01.wipro.com> <20100320163352.GB31380@slice> <6CD4ED5690208D4186E7E46B4C13B7EC09A2CFF4@HYD-MDP-MBX01.wipro.com> To: X-Mailer: Apple Mail (2.1077) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 13:04:27 -0000 This sounds reasonable. On Mar 22, 2010:12:38 AM, at 12:38 AM, wrote: > Hi Jeff, > > Exactly, I'm suggesting the authors of the BFD MIB to rephrase the > description for all the counters the way you mentioned it. > > Thanks, > Mahesh. > > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Saturday, March 20, 2010 10:04 PM > To: Mahesh Akula (WT01 - Telecom Equipment) > Cc: rtg-bfd@ietf.org > Subject: Re: Comments on the BFD MIB. > > Mahesh, > > On Thu, Mar 11, 2010 at 05:57:01PM +0530, mahesh.akula@wipro.com wrote: >> Description of the Performance counters in BFD MIB seems to have an >> issue. >> >> For example if we consider the bfdSessPerfCtrlPktInHC counter, >> description says that value of the "bfdSessPerfCtrlPktInHC must be >> equal to the least significant 32 bits of bfdSessPerfCtrlPktIn if >> bfdSessPerfCtrlPktInHC is supported". >> >> What does it mean by least significant 32 bits in a 32 bit counter? > > See RFC 2863, section 3.1.6 as an example: > : When 64-bit counters are in use, the 32-bit counters MUST still be > : available. They will report the low 32-bits of the associated > 64-bit > : count (e.g., ifInOctets will report the least significant 32 bits > of > : ifHCInOctets). This enhances inter-operability with existing > : implementations at a very minimal cost to agents. > > I suspect what the MIB authors meant was that the Counter32 objects > should contain text that say something roughly like the following: > > bfdSessPerfCtrlPktIn OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of BFD control messages received for this > BFD session. This value MUST be equal to the least > significant > 32 bits of bfdSessPerfCtrlPktInHC." > ::= { bfdSessPerfEntry 1 } > > bfdSessPerfCtrlPktInHC OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This value represents the total number of BFD control > messages received for this BFD session." > ::= { bfdSessPerfEntry 14 } > > -- Jeff > From jhaas@slice.pfrc.org Mon Mar 22 06:29:19 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7043728C11A for ; Mon, 22 Mar 2010 06:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.377 X-Spam-Level: X-Spam-Status: No, score=0.377 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELT2pcJ3ePDe for ; Mon, 22 Mar 2010 06:29:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id D7AC828C125 for ; Mon, 22 Mar 2010 06:22:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A296422414E; Mon, 22 Mar 2010 13:22:17 +0000 (UTC) Date: Mon, 22 Mar 2010 13:22:17 +0000 From: Jeffrey Haas To: Vishwas Manral Subject: Re: BFD MIB Message-ID: <20100322132217.GA20964@slice> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <20100320165553.GC31380@slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d@mail.gmail.com> <20100321124908.GA6307@slice> <77ead0ec1003211111m1d2b1e2obbf1c4289e30346b@mail.gmail.com> <77ead0ec1003211112p3e55c146uf5643a3f67891b25@mail.gmail.com> <77ead0ec1003212130r6101de5cn13be781f175d5aa1@mail.gmail.com> <3C64D748-E06E-42D9-8496-EEFF12EC341B@lucidvision.com> <77ead0ec1003212220p6a62e1ddvff8be1c5cf64428c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77ead0ec1003212220p6a62e1ddvff8be1c5cf64428c@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 13:29:19 -0000 Vishwas/Tom, On Sun, Mar 21, 2010 at 10:20:22PM -0700, Vishwas Manral wrote: > However let me tell you, we have customers who want to configure the > same through MIB (that is one of the reasons we have gone into actully > supporting the MIB). > > If you are at the IETF we can discuss this as well as all MPLS-TC MIB > which we need to correct and need a non disruptive way to do the same. After you've had your discussion, would you please follow-up to the mailing list with the general outline of your proposed changes? > Vishwas -- Jeff From wwwrun@core3.amsl.com Tue Mar 23 09:02:02 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 31A893A6C78; Tue, 23 Mar 2010 09:02:02 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'Bidirectional Forwarding Detection' to Proposed Standard Message-Id: <20100323160202.31A893A6C78@core3.amsl.com> Date: Tue, 23 Mar 2010 09:02:02 -0700 (PDT) Cc: bfd mailing list , Internet Architecture Board , bfd chair , RFC Editor X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:02:02 -0000 The IESG has approved the following document: - 'Bidirectional Forwarding Detection ' as a Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-11.txt Technical Summary This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols (for example since it is relatively simple and is independent of media type it allows rapid detection of faults on media such as Ethernet that don't have the same inherent fault detection at Sonet, and due to independence from routing protocol one protocol can be used to detect link failures quickly, which allows multiple routing and signaling protocols to be notified of failure). Working Group Summary This working group has ran very smoothly. A couple of people have noted that the documents were ready a while ago. Note that some late IPR announcements were referred back to the WG to check that they were OK. No issues were raised. Document Quality The protocol is widely implemented and deployed and has become part of default deployments on the internet. The drafts reflect the lessons learned from the deployed and operation. Multiple vendors have implemented and deployed BFD in operational networks. There are a few minor nits to be corrected based on Gen-Art and Last Call comments. The authors would like to correct these along with any IESG comments received. Personnel Dave Ward is the document shepherd. Adrian Farrel is the responsible Area Director. From vishwas.ietf@gmail.com Tue Mar 23 17:58:00 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8C33A6B3D for ; Tue, 23 Mar 2010 17:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.109 X-Spam-Level: ** X-Spam-Status: No, score=2.109 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBhjbREhiFOk for ; Tue, 23 Mar 2010 17:57:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id CE7CF3A67F0 for ; Tue, 23 Mar 2010 17:57:54 -0700 (PDT) Received: by gyh4 with SMTP id 4so3604124gyh.31 for ; Tue, 23 Mar 2010 17:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3Ke4CcaxdAVUQ00YYOvWxEMAIQjzki7/N+pmJdZqh3M=; b=w7VUd3ntU8M3jBaQGjdJOvWmAJpjmDY8TgpI+2c/6Bpnb+6iXa/oXxDbDtiwK/QRty daLTZazdfybuO5xj3QV9QOpYVwShmIeEqEzBYPgKGCWC61rFj05qPEksaHKYlENcI7/8 t4wTxn61OF3teTk5kbCedLlDoap396I270DoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P9yoI6WL3bHKvmRHouSm1WGn3AFN7jvqH8P7sw1bx3AMsdtcahBixmAjn7PSSJuJIl Ssp145rW4sVvRn5TiQ4dioNFk01wQZPwNig70oHpZbF6tY1GeAaCOmYm5MHoeIRL/vTO KBfC51UNyhCmTuzSRx3Qbo/DRdlRiJ/Sgvjzc= MIME-Version: 1.0 Received: by 10.150.127.5 with SMTP id z5mr5579439ybc.275.1269392291200; Tue, 23 Mar 2010 17:58:11 -0700 (PDT) In-Reply-To: <77ead0ec0911111007le094b7k7b1febb3475b6709@mail.gmail.com> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a@mail.gmail.com> <77ead0ec0911101331m7fce0f16n8de8f9da4b935417@mail.gmail.com> <77ead0ec0911101344s49fad341t65a4f6ed699a9c12@mail.gmail.com> <438D5604-83C2-4159-B8CB-6D6AD8353090@cisco.com> <77ead0ec0911101845t2c582efcq59e76c0c972ce55b@mail.gmail.com> <77ead0ec0911110829s27419995hd6032b8e00a8dfd7@mail.gmail.com> <7CC717E2F49DAA4A827DA3FEA237111B188995@XMB-RCD-103.cisco.com> <77ead0ec0911111007le094b7k7b1febb3475b6709@mail.gmail.com> Date: Tue, 23 Mar 2010 17:58:11 -0700 Message-ID: <77ead0ec1003231758q38116aa6od3542451245a1df9@mail.gmail.com> Subject: Re: BFD MIB From: Vishwas Manral To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 00:58:00 -0000 Hi Tom, I found the second list of changes I had requested (I know most of the comments on the first list have not been incorporated in the MIB). Thanks, Vishwas On Wed, Nov 11, 2009 at 11:07 AM, Vishwas Manral w= rote: > Thanks Zafar. I agree with what Dave mentioned. > > Some top level things I have in mind right now besides what I > mentioned in the mail are: > > 1. BFD session table is called bfdSessTable in some places and > bfdSessionTable at others. > 2. Take care of non IP BFD too. > 3. BFD sessions can be single hop in one direction and multihop in others= . > 4. I think for Multiplier we could have a TC. > > -Vishwas > > On Wed, Nov 11, 2009 at 8:43 AM, Zafar Ali (zali) wrote: >> Hi Vishwas- >> >> Acking your email. I am behind in my emails but will reply during next w= eek. >> >> Re: earlier comments not addressed- can you please resend the comments? = I may have lost them. We will reply and try to close on all of them during = next week. >> >> Like Dave mentioned, we also need to align the BFD MIBs with the latest = version of the base document in the next revision. >> >> Thanks >> >> Regards... Zafar >> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org >>> [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Vishwas Manral >>> Sent: Wednesday, November 11, 2009 11:30 AM >>> To: Thomas Nadeau >>> Cc: rtg-bfd@ietf.org; David Ward >>> Subject: Re: BFD MIB >>> >>> Hi Tom, >>> >>> Thats great. >>> >>> Do you have any comments on the questions I have raised? What >>> about the other comments discussed on the list, have they >>> been looked into? >>> >>> Thanks, >>> Vishwas >>> >>> On Wed, Nov 11, 2009 at 4:06 AM, Thomas Nadeau >>> wrote: >>> > >>> > =A0 =A0 =A0 =A0Thanks for the offer, but we have updated the >>> document but missed the update deadline. >>> > >>> > =A0 =A0 =A0 =A0--Tom >>> > >>> > >>> >> Hi David, >>> >> >>> >> Thanks. I think some of the comments on the list earlier have also >>> >> not been incorporated either. As the MIB has expired I am >>> not sure if >>> >> the authors need help closing the MIB. Do let me know if you need >>> >> help closing the document? >>> >> >>> >> Thanks again, >>> >> Vishwas >>> >> >>> >> On Tue, Nov 10, 2009 at 4:53 PM, David Ward >>> wrote: >>> >>> Leaving aside the questions specific to a vendor, the MIB >>> is out of >>> >>> date after the changes to the specs following IESG >>> review/comments >>> >>> and needs another revision. >>> >>> >>> >>> -DWard >>> >>> >>> >>> >>> >>> >>> >> >>> > >>> > >>> >> > From dai.xuehui@zte.com.cn Wed Mar 24 17:23:29 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178A03A6C68 for ; Wed, 24 Mar 2010 17:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.06 X-Spam-Level: X-Spam-Status: No, score=-89.06 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NROOwHpvK9Ie for ; Wed, 24 Mar 2010 17:23:14 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1C3523A6C5F for ; Wed, 24 Mar 2010 17:23:12 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 314906853516; Thu, 25 Mar 2010 08:22:34 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.2996381502; Thu, 25 Mar 2010 08:23:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2P0NTjK020301; Thu, 25 Mar 2010 08:23:29 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) In-Reply-To: <77ead0ec1003221928s5e77c4bckd7e31c0dad0cec3e@mail.gmail.com> To: Vishwas Manral Subject: =?GB2312?B?tPC4tDogUmU6ILTwuLQ6IFJlOiBOZXcgZHJhZnQgbm90aWZpY2F0aW9uOiA=?= =?GB2312?B?ZHJhZnQtZHotYmZkLWV4dGVuc2lvbnMtZm9yLXZsLXBhY2tldHMtMDA=?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: dai.xuehui@zte.com.cn Date: Wed, 24 Mar 2010 16:23:08 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-25 08:23:29, Serialize complete at 2010-03-25 08:23:29 Content-Type: multipart/alternative; boundary="=_alternative 0002224C882576F1_=" X-MAIL: mse2.zte.com.cn o2P0NTjK020301 Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 00:23:29 -0000 This is a multipart message in MIME format. --=_alternative 0002224C882576F1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVmlzaHdhcywNCg0KWW91IGFyZSByaWdodCBhdCB0aGlzIHBvaW50LCBhbmQgdGhhbmtzIGZv ciB5b3UgYWR2aWNlLiBXZSB3aWxsIGNvbnNpZGVyIA0KaXQgYW5kIG1ha2Ugc29tZSB1cGRhdGVz IGFjY29yZGluZyB0byB5b3VyIGNvbW1lbnRzLiBUaGFua3MgYSBsb3QgYW5kIA0KZXhwZWN0IGZ1 cnRoZXIgY29tbWVudHMgDQoNCmZyb20gYWxsIG1lbWJlcnMuDQoNCg0KQmVzdCBSZWdhcmRzLg0K DQotWHVlaHVpDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN Cg0KDQoNClZpc2h3YXMgTWFucmFsIDx2aXNod2FzLmlldGZAZ21haWwuY29tPiANCjIwMTAtMDMt MjIgMTk6MjgNCg0KytW8/sjLDQpkYWkueHVlaHVpQHp0ZS5jb20uY24NCrOty80NCkRhdmUgS2F0 eiA8ZGthdHpAanVuaXBlci5uZXQ+LCBydGctYmZkQGlldGYub3JnDQrW98ziDQpSZTogtPC4tDog UmU6IE5ldyBkcmFmdCBub3RpZmljYXRpb246IA0KZHJhZnQtZHotYmZkLWV4dGVuc2lvbnMtZm9y LXZsLXBhY2tldHMtMDANCg0KDQoNCg0KDQoNCkhpIERhaSwNCiANCkxpa2Ugd2UgZGlzY3Vzc2Vk IHRvZGF5IGEgQkZEIHBhY2tldCBjYW5ub3QgYmUgb2YgbGVuZ3RoID4gMjU1LiBUaGlzIA0KbGlt aXRzIHRoZSB1c2FnZSBvZiB5b3VyIGRyYWZ0IHRvIE1UVSBjaGVja3Mgb2YgbGVzcyB0aGFuIDI1 NSBieXRlcz8NCiANClRoYW5rcywNClZpc2h3YXMNCjIwMTAvMy8xNSBWaXNod2FzIE1hbnJhbCA8 dmlzaHdhcy5pZXRmQGdtYWlsLmNvbT4NCkhpIERhaSwNCiANCk9uZSBtb3JlIGludGVyZXN0aW5n IHRoaW5nIGlzIGhvdyBtYW55IHBhY2tldHMgd2UgbmVlZCB0byBzZW5kIGZvciBlYWNoIA0KdHlw ZS4gSSB0aGluayBpdCBzaG91bGQgZGVwZW5kIG9uIHRoZSBkZXRlY3QgbXVsdGlwbGllciBvZiB0 aGUgbmVpZ2hib3IsIA0Kb3RoZXJ3aXNlIGlmIHdlIHNlbmQgYSBwYWNrZXQgb2YgZGlmZmVyZW50 IHNpemUgYW5kIHdlIGhhdmUgaXNzdWVzIGF0IGEgDQpwYXJ0aWN1bGFyIHNpemUgdGhlIGhvbGQg dGltZXIgd2lsbCBub3QgdGltZSBvdXQgYW5kIHRoZSBlcnJvciB3aWxsIG5vdCBiZSANCmRldGVj dGVkLg0KIA0KVGhhbmtzLA0KVmlzaHdhcw0KDQoyMDEwLzMvMTUgVmlzaHdhcyBNYW5yYWwgPHZp c2h3YXMuaWV0ZkBnbWFpbC5jb20+DQpIaSBEYWksDQogDQpJIGhhdmUgc2tpbW1lZCB0aHJvdWdo IHRoZSBkcmFmdCBidXQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KIA0KMS4gSXNuJ3Qg dGhlIHBhZGRpbmcgZnVuY3Rpb25hbGl0eSBtb3JlIGEgcGFydCBvZiBDViBhbmQgbm90IGEgQ0Mg DQptZWNoYW5pc20gbGlrZSBCRkQ/IFRob3VnaCBlcnJvcnMgY291bGQgaGFwcGVuIGF0IHJ1biB0 aW1lLCB0aGVzZSB3b3VsZCANCmdlbmVyYWxsdHkgYmUgdGhlcmUgYXQgc3RhcnR1cCB0aW1lLg0K IA0KMi4gSGF2aW5nIGEgZGlmZmVyZW50IHZlcnNpb24gbnVtYmVyIG1heSBiZSBhIGJpdCBoYXJk IHRvIGZseS4gVGhlcmUgYXJlIA0Kb3RoZXIgd2F5cyB0byBhZGQgcGFkZGluZyBieSBvdmVybG9h ZGluZyB0aGUgQSBiaXQgYW5kIHRoZSBhdXRoX2ZpZWxkLiBTbyANCnRoZSBmaXJzdCBiaXQgb2Yg dGhlIGF1dGh0eXBlIGZpbGVkIGNvdWxkIGJlIHVzZWQgdG8gc2lnbmFsIHBhZGRpbmcgYW5kIA0K cmVzcGVjdGl2ZSBkYXRhLiANCiANClRoaXMgd291bGQgbWVhbiB0aGF0IGFsbCBvbGRlciBpbXBs ZW1lbnRhdGlvbnMgd291bGQgc3RpbGwgd29yayB3aXRob3V0IA0KY2hhbmdlIGluIHZlcnNpb24g bnVtYmVyIGFuZCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydGluZyB0aGlzIHJlcXVpcmVtZW50IA0K Y291bGQgaW50ZXJvcGVyYXRlLg0KIA0KU28gdGhlIGF1dGh0eXBlIGZpbGVkIGNvdWxkIGJlIHNw bGl0IGludG8NCiANCnVfaW50MzJfdCBwYWRkaW5nOiAxDQp1X2ludDMyX3QgYXV0aF90eXBlOjc7 DQp1X2ludDMyX3QgdG90YWxfbGVuOjI0Ow0KdV9pbnQzMl90IGF1dGhfbGVuOjE2Ow0KdV9jaGFy IGRhdGFbXTsNCnVfY2hhciBwYWRfaW5mbzsNCiANClRoYW5rcywNClZpc2h3YXMNCg0KMjAxMC8z LzEwIDxkYWkueHVlaHVpQHp0ZS5jb20uY24+DQoNCkhpIERhdmUsIA0KDQogICAgIFRoYW5rcyBm b3IgeW91ciBxdWljayByZXNwb25zZSwgYW5kIHlvdSBhcmUgcmlnaHQuIEJ1dCB0aGUgZXhzaXRp bmcgDQpCRkQgY2FuJ3QgbWVldCBvdXIgcmVxdWlyZW1lbnRzIHRvIHJlc29sdmUgc3VjaCBub24t Zm9yd2FyZGluZyBwcm9ibGVtLCANCnNpbmNlIEJGRCdzICBmbGV4aWJpbGl0eSBpcyBub3Qgc28g Z29vZC4gDQoNCnNvIHdlIG1ha2Ugc29tZSBjaGFuZ2VzIGluIEJGRCBoZWFkZXIgdG8gc3VwcG9y dCBuZWdvdGlhdGlvbiBmb3IgDQp2YXJpYWJsZS1sZW5ndGggZGV0ZWN0aW9uIHBhcmFtZXRlcnMu IFRocm91Z2ggdGhpcyBuZWdvdGlhdGlvbiwgYXN5bW1ldHJpYyANCmNvbmRpdGlvbiB0aGF0IHlv dSBtZW50aW9uZWQgY2FuIGJlIGF2b2lkZWSjrCANCg0KaW4gYWRkaXRpb24sICB3ZSBjYW4gb2J0 YWluIHRoZSBsZW5ndGggaW50ZXJ2YWwgZHVyaW5nIHdoaWNoIHRoZSBmYXVsdCANCm9jY3VyZWQg bW9yZSBhY2N1cmF0ZWx5LiANCg0KV2lzaCBmdXJ0aGVyIGNvbW1lbnRzIGZyb20geW91IGFuZCBh bGwgb3RoZXJzLiANCg0KQlIuIA0KDQpYdWVodWkgDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K16PE+tDCtLrT5L/s o6y5pNf3y7PA+6Osye3M5b2hv7WjrOPYvNK7tsDWo6EgDQoNCg0KRGF2ZSBLYXR6IDxka2F0ekBq dW5pcGVyLm5ldD4gDQoyMDEwLTAzLTAzIDA4OjIxIA0KDQoNCsrVvP7Iyw0KPGRhaS54dWVodWlA enRlLmNvbS5jbj4gDQqzrcvNDQpydGctYmZkQGlldGYub3JnIA0K1vfM4g0KUmU6IE5ldyBkcmFm dCBub3RpZmljYXRpb246IGRyYWZ0LWR6LWJmZC1leHRlbnNpb25zLWZvci12bC1wYWNrZXRzLTAw DQoNCg0KDQoNCg0KDQoNCg0KDQpJJ2xsIGhhdmUgdG8gZXhhbWluZSB0aGUgcHJvcG9zYWwgY2Fy ZWZ1bGx5LCBidXQgbXkgZmlyc3QgcmVhY3Rpb24gaXMgdGhhdCANCnlvdSBjYW4gZG8gbW9zdCBv ZiB0aGlzIHRvZGF5IHdpdGhvdXQgY2hhbmdpbmcgdGhlIHByb3RvY29sLCBieSBzaW1wbHkgDQpw YWRkaW5nIHRoZSBwYWNrZXRzIGluIHdoaWNoIEJGRCBpcyBjYXJyaWVkLCB3aXRob3V0IGNoYW5n aW5nIHRoZSBCRkQgDQpoZWFkZXIgKG9yIHRoZSByZWNlaXZpbmcgaW1wbGVtZW50YXRpb24pIGF0 IGFsbCwgc2luY2UgdGhlIHNwZWMgb25seSANCnJlcXVpcmVzIHRoYXQgdGhlIEJGRCBwYWNrZXQg Zml0IGluc2lkZSBvZiB3aGF0ZXZlciBpdCBpcyBiZWluZyBjYXJyaWVkIA0Kd2l0aGluIChVRFAs IHR5cGljYWxseSkuICBGb3IgdGhhdCBtYXR0ZXIsIHRoZSBzcGVjIHdvdWxkIGFsbG93IHRoZSBC RkQgDQpwYWNrZXQgaXRzZWxmIHRvIGJlIHBhZGRlZCAoc2luY2Ugb25seSB0aGUgbG93ZXIgYm91 bmQgb2YgcGFja2V0IGxlbmd0aCBpcyANCnN1cHBvc2VkIHRvIGJlIGNoZWNrZWQpIGJ1dCB0aGF0 IHdvdWxkIGJlIG1vcmUgbGlrZWx5IHRvIHJ1biBhZm91bCBvZiANCm91dC1vZi1zcGVjIGltcGxl bWVudGF0aW9ucy4gDQoNCkl0IHdvdWxkbid0IGJlIGZhbmN5IG9yIG5lZ290aWF0ZWQsIGJ1dCBp dCB3b3VsZCB3b3JrIHRvZGF5IHdpdGhvdXQgDQpjaGFuZ2luZyBleGlzdGluZyBpbXBsZW1lbnRh dGlvbnMuIA0KDQpBIGNsZXZlciBpbXBsZW1lbnRvciBtaWdodCBtYXRjaCB0aGUgcGFja2V0IGxl bmd0aCBvZiByZWNlaXZlZCBwYWNrZXRzIGluIA0Kb3JkZXIgdG8gZHJpdmUgdGhlIGV4dGVuc2lv biBpbiBib3RoIGRpcmVjdGlvbnMsIHRob3VnaCB0aGF0IHNjaGVtZSB3b3VsZCANCmJlIGFzeW1t ZXRyaWMgKG9uZSBzaWRlIGhhcyB0byBkZWNpZGUgdG8gcmFpc2UgaXRzIHBhY2tldCBzaXplLCBh bmQgdGhlIA0Kb3RoZXIgdG8gcmVmbGVjdCBpdCkuIA0KDQpUaGUgcHJvcG9zYWwgc2VlbXMgbGlr ZSBvdmVya2lsbCBmb3IgdGhlIHB1cnBvc2UsIGJ1dCBJJ2QgYmUgaW50ZXJlc3RlZCB0byANCnNl ZSB3aGF0IG90aGVycyBoYXZlIHRvIHNheS4gDQoNCi0tRGF2ZSANCg0KDQpPbiBGZWIgMjgsIDIw MTAsIGF0IDc6NDYgUE0sIGRhaS54dWVodWlAenRlLmNvbS5jbiB3cm90ZTogDQoNCg0KSGkgYWxs LCANCg0KSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBvbiBCRkQgZXh0ZW5zaW9ucywgdGhl IGRyYWZ0J3MgbGluayBpczogDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZHotYmZk LWV4dGVuc2lvbnMtZm9yLXZsLXBhY2tldHMtMDAudHh0DQoNClRoaXMgZG9jdW1lbnQgZXh0ZW5k cyBCRkQgbWVjaGFuaXNtIHRvIHN1cHBvcnQgZGV0ZWN0aW9uIGZ1bmN0aW9uIGZvciANCnBhY2tl dHMgd2l0aCB2YXJpYWJsZSBsZW5ndGhzLiAgVGhyb3VnaCBkeW5hbWljYWxseSBjaGFuZ2luZyB0 aGUgbGVuZ3RoIG9mIA0KQkZEIHBhY2tldHMsIA0KaXQgY2FuIGRldGVjdCBib3RoIHRyYWRpdGlv bmFsIGZhdWx0cyBzdWNoIGFzIGxpbmsgZmFpbHVyZSBvciByb3V0ZSBmYXVsdCwgDQphcyB3ZWxs IGFzIG5vbi1mb3J3YXJkaW5nIHByb2JsZW0gZm9yIHBhY2tldHMgd2l0aCBhIGxlbmd0aCBpbiBh IHNwZWNpYWwgDQpyYW5nZSwgDQp3aGljaCBtYXliZSBjYXVzZWQgYnkgZXF1aXBtZW50J3MgaW50 ZXJuYWwgZGVmZWN0cy4NCg0KQW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29t ZWQhIA0KDQpSZWdhcmRzIA0KRGFpIA0KDQoNCg0KQmVzdCBSZWdhcmRzLg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K16PE+tDCtLrT5L/so6y5pNf3y7PA+6Os ye3M5b2hv7WjrOPYvNK7tsDWo6EgDQoNCg0KDQoNCg0K --=_alternative 0002224C882576F1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFZpc2h3YXMsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Zb3UgYXJlIHJpZ2h0IGF0 IHRoaXMgcG9pbnQsIGFuZCB0aGFua3MNCmZvciB5b3UgYWR2aWNlLiBXZSB3aWxsIGNvbnNpZGVy IGl0IGFuZCBtYWtlIHNvbWUgdXBkYXRlcyBhY2NvcmRpbmcgdG8NCnlvdXIgY29tbWVudHMuIFRo YW5rcyBhIGxvdCBhbmQgZXhwZWN0IGZ1cnRoZXIgY29tbWVudHMgPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5mcm9tIGFsbCBtZW1iZXJzLjwvZm9udD4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdh cmRzLjxicj4NCjxicj4NCi1YdWVodWk8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNCU+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxiPlZpc2h3YXMgTWFucmFsICZsdDt2aXNod2FzLmlldGZAZ21haWwu Y29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDEwLTAzLTIyIDE5OjI4PC9mb250Pg0KPHRkIHdpZHRoPTY1JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPmRhaS54dWVodWlAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ RGF2ZSBLYXR6ICZsdDtka2F0ekBqdW5pcGVyLm5ldCZndDssDQpydGctYmZkQGlldGYub3JnPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogtPC4tDogUmU6IE5ldyBkcmFmdCBub3RpZmljYXRpb246DQpk cmFmdC1kei1iZmQtZXh0ZW5zaW9ucy1mb3ItdmwtcGFja2V0cy0wMDwvZm9udD48L3RhYmxlPg0K PGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5I aSBEYWksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkxpa2Ugd2UgZGlzY3Vz c2VkIHRvZGF5IGEgQkZEIHBhY2tldA0KY2Fubm90IGJlIG9mIGxlbmd0aCAmZ3Q7IDI1NS4gVGhp cyBsaW1pdHMgdGhlIHVzYWdlIG9mIHlvdXIgZHJhZnQgdG8gTVRVDQpjaGVja3Mgb2YgbGVzcyB0 aGFuIDI1NSBieXRlcz88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtz LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VmlzaHdhczwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC8zLzE1IFZpc2h3YXMg TWFucmFsICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dmlzaHdhcy5pZXRmQGdtYWlsLmNvbT48 Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT52aXNod2FzLmlldGZA Z21haWwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZn dDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIERhaSw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+T25lIG1vcmUgaW50ZXJlc3RpbmcgdGhp bmcgaXMgaG93IG1hbnkNCnBhY2tldHMgd2UgbmVlZCB0byBzZW5kIGZvciBlYWNoIHR5cGUuIEkg dGhpbmsgaXQgc2hvdWxkIGRlcGVuZCBvbiB0aGUNCmRldGVjdCBtdWx0aXBsaWVyIG9mIHRoZSBu ZWlnaGJvciwgb3RoZXJ3aXNlIGlmIHdlIHNlbmQgYSBwYWNrZXQgb2YgZGlmZmVyZW50DQpzaXpl IGFuZCB3ZSBoYXZlIGlzc3VlcyBhdCBhIHBhcnRpY3VsYXIgc2l6ZSB0aGUgaG9sZCB0aW1lciB3 aWxsIG5vdCB0aW1lDQpvdXQgYW5kIHRoZSBlcnJvciB3aWxsIG5vdCBiZSBkZXRlY3RlZC48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VmlzaHdhczxicj4NCjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC8zLzE1IFZpc2h3YXMgTWFucmFsICZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dmlzaHdhcy5pZXRmQGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnZpc2h3YXMuaWV0 ZkBnbWFpbC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SGkgRGFpLDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5JIGhhdmUgc2tpbW1lZCB0aHJvdWdo IHRoZSBkcmFmdCBidXQNCmhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50czo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MS4gSXNuJ3QgdGhlIHBhZGRpbmcgZnVuY3Rpb25hbGl0 eSBtb3JlDQphIHBhcnQgb2YgQ1YgYW5kIG5vdCBhIENDIG1lY2hhbmlzbSBsaWtlIEJGRD8gVGhv dWdoIGVycm9ycyBjb3VsZCBoYXBwZW4NCmF0IHJ1biB0aW1lLCB0aGVzZSB3b3VsZCBnZW5lcmFs bHR5IGJlIHRoZXJlIGF0IHN0YXJ0dXAgdGltZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Mi4gSGF2aW5nIGEgZGlmZmVyZW50IHZlcnNpb24gbnVtYmVyDQptYXkgYmUgYSBi aXQgaGFyZCB0byBmbHkuIFRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIGFkZCBwYWRkaW5nIGJ5IG92 ZXJsb2FkaW5nDQp0aGUgQSBiaXQgYW5kIHRoZSBhdXRoX2ZpZWxkLiBTbyB0aGUgZmlyc3QgYml0 IG9mIHRoZSBhdXRodHlwZSBmaWxlZCBjb3VsZA0KYmUgdXNlZCB0byBzaWduYWwgcGFkZGluZyBh bmQgcmVzcGVjdGl2ZSBkYXRhLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ VGhpcyB3b3VsZCBtZWFuIHRoYXQgYWxsIG9sZGVyIGltcGxlbWVudGF0aW9ucw0Kd291bGQgc3Rp bGwgd29yayB3aXRob3V0IGNoYW5nZSBpbiB2ZXJzaW9uIG51bWJlciBhbmQgaW1wbGVtZW50YXRp b25zIHN1cHBvcnRpbmcNCnRoaXMgcmVxdWlyZW1lbnQgY291bGQgaW50ZXJvcGVyYXRlLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5TbyB0aGUgYXV0aHR5cGUgZmlsZWQgY291 bGQgYmUgc3BsaXQNCmludG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+dV9p bnQzMl90IHBhZGRpbmc6IDE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPnVfaW50MzJfdCBhdXRoX3R5cGU6Nzs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPnVfaW50MzJfdCB0b3RhbF9sZW46MjQ7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj51X2ludDMyX3QgYXV0aF9sZW46MTY7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj51X2NoYXIgZGF0YVtdOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+dV9jaGFyIHBhZF9pbmZvOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj5WaXNod2FzPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLzMvMTAgJmx0OzwvZm9udD48YSBocmVmPW1haWx0 bzpkYWkueHVlaHVpQHp0ZS5jb20uY24gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5kYWkueHVlaHVpQHp0ZS5jb20uY248L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSGkgRGF2ZSw8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7IFRoYW5rcyBmb3IgeW91ciBxdWljayByZXNw b25zZSwgYW5kIHlvdSBhcmUgcmlnaHQuIEJ1dCB0aGUNCmV4c2l0aW5nIEJGRCBjYW4ndCBtZWV0 IG91ciByZXF1aXJlbWVudHMgdG8gcmVzb2x2ZSBzdWNoIG5vbi1mb3J3YXJkaW5nDQpwcm9ibGVt LCBzaW5jZSBCRkQncyAmbmJzcDtmbGV4aWJpbGl0eSBpcyBub3Qgc28gZ29vZC48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQpzbyB3ZSBtYWtlIHNvbWUgY2hhbmdlcyBpbiBCRkQgaGVh ZGVyIHRvIHN1cHBvcnQgbmVnb3RpYXRpb24gZm9yIHZhcmlhYmxlLWxlbmd0aA0KZGV0ZWN0aW9u IHBhcmFtZXRlcnMuIFRocm91Z2ggdGhpcyBuZWdvdGlhdGlvbiwgYXN5bW1ldHJpYyBjb25kaXRp b24gdGhhdA0KeW91IG1lbnRpb25lZCBjYW4gYmUgYXZvaWRlZKOsIDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQppbiBhZGRpdGlvbiwgJm5ic3A7d2UgY2FuIG9idGFpbiB0aGUgbGVuZ3Ro IGludGVydmFsIGR1cmluZyB3aGljaCB0aGUgZmF1bHQNCm9jY3VyZWQgbW9yZSBhY2N1cmF0ZWx5 LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KV2lzaCBmdXJ0aGVyIGNvbW1lbnRzIGZy b20geW91IGFuZCBhbGwgb3RoZXJzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkJS LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KWHVlaHVpPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCkJlc3QgUmVnYXJkcy48YnI+DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K16PE+tDCtLrT5L/so6y5pNf3y7PA+6Osye3M 5b2hv7WjrOPYvNK7tsDWo6E8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0K PGJyPg0KPGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD0zMSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkRhdmUgS2F0 eiAmbHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzpka2F0ekBqdW5pcGVyLm5ldCB0YXJnZXQ9 X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PmRr YXR6QGp1bmlwZXIubmV0PC91PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjIwMTAtMDMtMDMgMDg6MjE8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTY3JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NyU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTIl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRv OmRhaS54dWVodWlAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PmRhaS54dWVodWlAenRlLmNvbS5jbjwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5ydGctYmZkQGll dGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogTmV3IGRyYWZ0IG5vdGlmaWNhdGlvbjogZHJhZnQtZHotYmZk LWV4dGVuc2lvbnMtZm9yLXZsLXBhY2tldHMtMDA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRk IHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTElPjwvdGFibGU+DQo8cD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KSSdsbCBoYXZlIHRv IGV4YW1pbmUgdGhlIHByb3Bvc2FsIGNhcmVmdWxseSwgYnV0IG15IGZpcnN0IHJlYWN0aW9uIGlz IHRoYXQNCnlvdSBjYW4gZG8gbW9zdCBvZiB0aGlzIHRvZGF5IHdpdGhvdXQgY2hhbmdpbmcgdGhl IHByb3RvY29sLCBieSBzaW1wbHkNCnBhZGRpbmcgdGhlIHBhY2tldHMgaW4gd2hpY2ggQkZEIGlz IGNhcnJpZWQsIHdpdGhvdXQgY2hhbmdpbmcgdGhlIEJGRCBoZWFkZXINCihvciB0aGUgcmVjZWl2 aW5nIGltcGxlbWVudGF0aW9uKSBhdCBhbGwsIHNpbmNlIHRoZSBzcGVjIG9ubHkgcmVxdWlyZXMN CnRoYXQgdGhlIEJGRCBwYWNrZXQgZml0IGluc2lkZSBvZiB3aGF0ZXZlciBpdCBpcyBiZWluZyBj YXJyaWVkIHdpdGhpbiAoVURQLA0KdHlwaWNhbGx5KS4gJm5ic3A7Rm9yIHRoYXQgbWF0dGVyLCB0 aGUgc3BlYyB3b3VsZCBhbGxvdyB0aGUgQkZEIHBhY2tldA0KaXRzZWxmIHRvIGJlIHBhZGRlZCAo c2luY2Ugb25seSB0aGUgbG93ZXIgYm91bmQgb2YgcGFja2V0IGxlbmd0aCBpcyBzdXBwb3NlZA0K dG8gYmUgY2hlY2tlZCkgYnV0IHRoYXQgd291bGQgYmUgbW9yZSBsaWtlbHkgdG8gcnVuIGFmb3Vs IG9mIG91dC1vZi1zcGVjDQppbXBsZW1lbnRhdGlvbnMuIDxicj4NCjxicj4NCkl0IHdvdWxkbid0 IGJlIGZhbmN5IG9yIG5lZ290aWF0ZWQsIGJ1dCBpdCB3b3VsZCB3b3JrIHRvZGF5IHdpdGhvdXQg Y2hhbmdpbmcNCmV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gPGJyPg0KPGJyPg0KQSBjbGV2ZXIg aW1wbGVtZW50b3IgbWlnaHQgbWF0Y2ggdGhlIHBhY2tldCBsZW5ndGggb2YgcmVjZWl2ZWQgcGFj a2V0cw0KaW4gb3JkZXIgdG8gZHJpdmUgdGhlIGV4dGVuc2lvbiBpbiBib3RoIGRpcmVjdGlvbnMs IHRob3VnaCB0aGF0IHNjaGVtZQ0Kd291bGQgYmUgYXN5bW1ldHJpYyAob25lIHNpZGUgaGFzIHRv IGRlY2lkZSB0byByYWlzZSBpdHMgcGFja2V0IHNpemUsIGFuZA0KdGhlIG90aGVyIHRvIHJlZmxl Y3QgaXQpLiA8YnI+DQo8YnI+DQpUaGUgcHJvcG9zYWwgc2VlbXMgbGlrZSBvdmVya2lsbCBmb3Ig dGhlIHB1cnBvc2UsIGJ1dCBJJ2QgYmUgaW50ZXJlc3RlZA0KdG8gc2VlIHdoYXQgb3RoZXJzIGhh dmUgdG8gc2F5LiA8YnI+DQo8YnI+DQotLURhdmUgPGJyPg0KPGJyPg0KPGJyPg0KT24gRmViIDI4 LCAyMDEwLCBhdCA3OjQ2IFBNLCA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGFpLnh1ZWh1aUB6dGUu Y29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+PHU+ZGFpLnh1ZWh1aUB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0Kd3JvdGU6IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KSGkgYWxsLDwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KPGJyPg0KSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBvbiBCRkQgZXh0ZW5zaW9uczwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+LA0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj50aGUgZHJhZnQncyBsaW5rIGlzOiA8L2ZvbnQ+PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWR6LWJmZC1leHRlbnNpb25zLWZvci12bC1w YWNrZXRzLTAwLnR4dCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTQgY29sb3I9Ymx1ZSBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1kei1i ZmQtZXh0ZW5zaW9ucy1mb3ItdmwtcGFja2V0cy0wMC50eHQ8L3U+PC9mb250PjwvYT48dHQ+PGZv bnQgc2l6ZT0yPjxicj4NCjxicj4NClRoaXMgZG9jdW1lbnQgZXh0ZW5kcyBCRkQgbWVjaGFuaXNt IHRvIHN1cHBvcnQgZGV0ZWN0aW9uIGZ1bmN0aW9uIGZvciAmbmJzcDtwYWNrZXRzDQp3aXRoIHZh cmlhYmxlIGxlbmd0aHMuICZuYnNwO1Rocm91Z2ggZHluYW1pY2FsbHkgY2hhbmdpbmcgdGhlIGxl bmd0aCBvZg0KQkZEIHBhY2tldHMsIDxicj4NCml0IGNhbiBkZXRlY3QgYm90aCB0cmFkaXRpb25h bCBmYXVsdHMgc3VjaCBhcyBsaW5rIGZhaWx1cmUgb3Igcm91dGUgZmF1bHQsDQphcyB3ZWxsIGFz IG5vbi1mb3J3YXJkaW5nIHByb2JsZW0gZm9yIHBhY2tldHMgd2l0aCBhIGxlbmd0aCBpbiBhIHNw ZWNpYWwNCnJhbmdlLCA8YnI+DQp3aGljaCBtYXliZSBjYXVzZWQgYnkgZXF1aXBtZW50J3MgaW50 ZXJuYWwgZGVmZWN0cy48YnI+DQo8YnI+DQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFy ZSB3ZWxjb21lZCE8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpSZWdhcmRzPC9mb250PjwvdHQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQpEYWk8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KQmVz dCBSZWdhcmRzLjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQrXo8T60MK0utPkv+yjrLmk1/fLs8D7o6zJ7czlvaG/taOs49i80ru2wNajoTwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo= --=_alternative 0002224C882576F1_=-- From glen.kent@gmail.com Wed Mar 31 17:31:06 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772EB3A67CC for ; Wed, 31 Mar 2010 17:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIidvSmiDNQH for ; Wed, 31 Mar 2010 17:31:05 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id A4DEE3A65A6 for ; Wed, 31 Mar 2010 17:31:05 -0700 (PDT) Received: by gwj15 with SMTP id 15so444236gwj.31 for ; Wed, 31 Mar 2010 17:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=YkdSHhHPSOO/o7Ux6i7aQln9QeINwchvjAAu+cK1PaU=; b=DuZ84Vb+9u5qaUWl9W/K9lYks7qiiuCyUuJTsqwqQ9rjiBvvcSEKQ/qLTVeeovBXH2 36xPcUPcLmVqsf45YfeO7rdRBqcWAsMWnHM2cnRMeWxNLzOSLtl/92xWCXq5vfO6HTBs t++/XN/vwuMK5rR2g0hgMWkeX4uClj5JGDfOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UNKvdchl5M5JVXLueQT3XdWKuOSt2nVXg1fp5kpPUsAvvNjdtkeycMP7NKYZ1kzhjZ wtmGWcAHgSF2vHpN62/KRTPJCZb+Wb7uxjeXwPvqEb4jKTGs8hNl7HtTlQW76tbYhu9N L+ytpEupBcdr5Bd43sGPcClpLpEBZCJfEoEhs= MIME-Version: 1.0 Received: by 10.100.106.2 with HTTP; Wed, 31 Mar 2010 17:31:33 -0700 (PDT) Date: Thu, 1 Apr 2010 06:01:33 +0530 Received: by 10.101.126.3 with SMTP id d3mr833630ann.92.1270081893996; Wed, 31 Mar 2010 17:31:33 -0700 (PDT) Message-ID: Subject: Different UDP dest ports From: Glen Kent To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 00:31:06 -0000 Hi, What is the motivation for having different UDP dest ports for directly connected IP nexthops (3784) and multhop paths (4784) in BFD? What do we lose by using just one, say 3784? Glen From davari@broadcom.com Wed Mar 31 17:35:12 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CC93A681D for ; Wed, 31 Mar 2010 17:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-u+5+AeJP1M for ; Wed, 31 Mar 2010 17:35:11 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id C10A13A68F0 for ; Wed, 31 Mar 2010 17:35:09 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 31 Mar 2010 17:35:27 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 31 Mar 2010 17:35:27 -0700 From: "Shahram Davari" To: "Glen Kent" , "rtg-bfd@ietf.org" Date: Wed, 31 Mar 2010 17:35:25 -0700 Subject: RE: Different UDP dest ports Thread-Topic: Different UDP dest ports Thread-Index: AcrRMrqbdVwrAdNBS1emEfjLVbiNUwAAEbmw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F018909C@SJEXCHCCR02.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67AD35C520S76048121-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 00:35:12 -0000 Hi, The receiver needs to check the IPTTL=3D255 for 1hop, and the only way to d= ifferentiate between 1hop and multi-hop is by using different UDP dest port= #. -Shahram=20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Glen Kent Sent: Wednesday, March 31, 2010 5:32 PM To: rtg-bfd@ietf.org Subject: Different UDP dest ports Hi, What is the motivation for having different UDP dest ports for directly connected IP nexthops (3784) and multhop paths (4784) in BFD? What do we lose by using just one, say 3784? Glen From glen.kent@gmail.com Wed Mar 31 17:39:09 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C1E3A681D for ; Wed, 31 Mar 2010 17:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec83yjRD0T-K for ; Wed, 31 Mar 2010 17:39:08 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 256743A65A6 for ; Wed, 31 Mar 2010 17:39:08 -0700 (PDT) Received: by gxk20 with SMTP id 20so378908gxk.12 for ; Wed, 31 Mar 2010 17:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=TmNjnaBhDXktyVVezNUrp3n8feOsasYfcq2lPyhokjg=; b=YloGolUEzPlB2IDYiOKOqKi3T2ueeNC+U/BnNwEBMRoQl00MHSHtzNWYxLm0tCI0FI tFm9OYyFr+BTiJ9yjvwzkr0cja5ZWPJbU5kiJ2luESWGj9k1R5/fUJjgwi0+TUq1PRWP Nbt5OKliKplHDDAN5pJDpP8vtqEL5925xr3HU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R85sDxU/nkSPhSLpqts1CJyXWztv1GeAxN3JHz1aR/h+H93vek16f3fBNP293ftyxJ EwYb763ZgwE1XPZQssRJR5pD5xFpXAqmhWsJieoSRBJX3R08yFaPwRU+VMIeTOSFCO0s Od4hp+r9sdl+M4N33DLZLSTjm8vMXOuof4Cmw= MIME-Version: 1.0 Received: by 10.100.106.2 with HTTP; Wed, 31 Mar 2010 17:39:36 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018909C@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD693F018909C@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 1 Apr 2010 06:09:36 +0530 Received: by 10.101.8.28 with SMTP id l28mr908165ani.159.1270082376473; Wed, 31 Mar 2010 17:39:36 -0700 (PDT) Message-ID: Subject: Re: Different UDP dest ports From: Glen Kent To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 00:39:09 -0000 Hi Shahram, So the sender should be intelligent enough to use dst port 4784 if it knows that the packet is being sent on a multihop path. Fair enough. What happens if i need to send a packet destined to the system IP or the loopback IP of a directly connected router? Should i use 3784 or 4784? Glen On Thu, Apr 1, 2010 at 6:05 AM, Shahram Davari wrote: > Hi, > > The receiver needs to check the IPTTL=255 for 1hop, and the only way to differentiate between 1hop and multi-hop is by using different UDP dest port #. > > -Shahram > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Glen Kent > Sent: Wednesday, March 31, 2010 5:32 PM > To: rtg-bfd@ietf.org > Subject: Different UDP dest ports > > Hi, > > What is the motivation for having different UDP dest ports for > directly connected IP nexthops (3784) and multhop paths (4784) in BFD? > > What do we lose by using just one, say 3784? > > Glen > > > From davari@broadcom.com Wed Mar 31 17:44:57 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516333A6858 for ; Wed, 31 Mar 2010 17:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYcp5vM4DVPr for ; Wed, 31 Mar 2010 17:44:56 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id EBE803A6A79 for ; Wed, 31 Mar 2010 17:44:27 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 31 Mar 2010 17:44:49 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 31 Mar 2010 17:44:49 -0700 From: "Shahram Davari" To: "Glen Kent" Date: Wed, 31 Mar 2010 17:44:48 -0700 Subject: RE: Different UDP dest ports Thread-Topic: Different UDP dest ports Thread-Index: AcrRM9UJ2pamcy/bST+Stle//OoP3AAAFwCw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F01890A0@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD693F018909C@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67AD330B20S76053229-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 00:44:57 -0000 Hi Glen, The loopback (12/8) address can't appear on a wire unless it is encapsulate= d in an IP or MPLS tunnel. For directly attached routers you can use either 1hop (3784) or Multi-hop (= 4784). But for non-directly attached router you need to use Multi-hop. Regards, Shahram -----Original Message----- From: Glen Kent [mailto:glen.kent@gmail.com]=20 Sent: Wednesday, March 31, 2010 5:40 PM To: Shahram Davari Cc: rtg-bfd@ietf.org Subject: Re: Different UDP dest ports Hi Shahram, So the sender should be intelligent enough to use dst port 4784 if it knows that the packet is being sent on a multihop path. Fair enough. What happens if i need to send a packet destined to the system IP or the loopback IP of a directly connected router? Should i use 3784 or 4784? Glen On Thu, Apr 1, 2010 at 6:05 AM, Shahram Davari wrote: > Hi, > > The receiver needs to check the IPTTL=3D255 for 1hop, and the only way to= differentiate between 1hop and multi-hop is by using different UDP dest po= rt #. > > -Shahram > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Glen Kent > Sent: Wednesday, March 31, 2010 5:32 PM > To: rtg-bfd@ietf.org > Subject: Different UDP dest ports > > Hi, > > What is the motivation for having different UDP dest ports for > directly connected IP nexthops (3784) and multhop paths (4784) in BFD? > > What do we lose by using just one, say 3784? > > Glen > > > From glen.kent@gmail.com Wed Mar 31 17:48:17 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5770B3A6AC5 for ; Wed, 31 Mar 2010 17:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.575 X-Spam-Level: X-Spam-Status: No, score=0.575 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWPjxMDzPDPP for ; Wed, 31 Mar 2010 17:48:16 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 71B163A6AB9 for ; Wed, 31 Mar 2010 17:48:16 -0700 (PDT) Received: by gwj15 with SMTP id 15so458156gwj.31 for ; Wed, 31 Mar 2010 17:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=+KCemAfF6/iHMZU8zbkoSWSKvphjBj9yrtBcE3r3qoQ=; b=NVKwIAOgx4yh53wz1d8+qkvJBpqMmntQSajpi77VnwvWP0nBwiW4nCxq+WwYsXKx9+ YQ41Knu40ds0Zx7OpC/imF58+/P3okkxGxj/4C0z2UWUJqCFfW4VhXLJjq10RBHJ9z58 sNssRVOydr3vPjkmZ0E8lwsB3Wyqm6tji0LIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rR6Vu3KHg78PzEqr3qyLLsG0kt/+0FUrbZXvtc7eJWY1nEhlfbGGSV5Vq1XkBOqmYp UqKWMzxM661e4ym2oCeByaDi655AVrftqnoQ03xJRRTebpeIQxOgcjThg8cqCQu1p4Un 79CvNogzDLujllFhvLU1w2jeglL/AOr3pYce4= MIME-Version: 1.0 Received: by 10.100.106.2 with HTTP; Wed, 31 Mar 2010 17:48:45 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F01890A0@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD693F018909C@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD693F01890A0@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 1 Apr 2010 06:18:45 +0530 Received: by 10.101.217.11 with SMTP id u11mr812038anq.243.1270082925260; Wed, 31 Mar 2010 17:48:45 -0700 (PDT) Message-ID: Subject: Re: Different UDP dest ports From: Glen Kent To: Shahram Davari Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 00:48:17 -0000 Hi Shahram, By loopback i did not mean 12/8 but was alluding to IP interfaces that are not tied to a particular physical port. They could have any logical routable IP address Glen On Thu, Apr 1, 2010 at 6:14 AM, Shahram Davari wrote: > Hi Glen, > > The loopback (12/8) address can't appear on a wire unless it is encapsulated in an IP or MPLS tunnel. > For directly attached routers you can use either 1hop (3784) or Multi-hop (4784). But for non-directly attached router you need to use Multi-hop. > > Regards, > Shahram > > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com] > Sent: Wednesday, March 31, 2010 5:40 PM > To: Shahram Davari > Cc: rtg-bfd@ietf.org > Subject: Re: Different UDP dest ports > > Hi Shahram, > > So the sender should be intelligent enough to use dst port 4784 if it > knows that the packet is being sent on a multihop path. Fair enough. > What happens if i need to send a packet destined to the system IP or > the loopback IP of a directly connected router? Should i use 3784 or > 4784? > > Glen > > On Thu, Apr 1, 2010 at 6:05 AM, Shahram Davari wrote: >> Hi, >> >> The receiver needs to check the IPTTL=255 for 1hop, and the only way to differentiate between 1hop and multi-hop is by using different UDP dest port #. >> >> -Shahram >> >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Glen Kent >> Sent: Wednesday, March 31, 2010 5:32 PM >> To: rtg-bfd@ietf.org >> Subject: Different UDP dest ports >> >> Hi, >> >> What is the motivation for having different UDP dest ports for >> directly connected IP nexthops (3784) and multhop paths (4784) in BFD? >> >> What do we lose by using just one, say 3784? >> >> Glen >> >> >> > > > From vishwas.ietf@gmail.com Wed Mar 31 18:03:55 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727B83A67A5 for ; Wed, 31 Mar 2010 18:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.003 X-Spam-Level: * X-Spam-Status: No, score=1.003 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U6L-yTxdv4U for ; Wed, 31 Mar 2010 18:03:54 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 7FBB23A65A6 for ; Wed, 31 Mar 2010 18:03:54 -0700 (PDT) Received: by gxk20 with SMTP id 20so402612gxk.12 for ; Wed, 31 Mar 2010 18:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=3M7ERcYMJmZMwvjnN/gRBDWeqMrVquOGMdyXsGZF1yQ=; b=n/bPmqw3RUHyycd+LXzOVNLyaCWuocZ8wojOI7Q0h+SiMQDnNMrBHkRA7PEbUujDmq ZErI2dIzZETyE70M4GsCZlDwYifIJY/z+eAiLoiyQX3tDkcFCxgwJunyRMZ+G70Xh5gg Lyhyiiqe+kNMTmK6PDYnY8QDVzNEcPyWMGMtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XWgBPc73lBQ7R39qceBv5g68AnMmSFmVABtWU33AisQ4ro5xeY+IO2RrIlf2Fpd0mn zZe+5GWKsj18YvHRtoz32N60fksuxkXtA6Zrr/JnVmCX28RUSprmX7uRktps8shAQe3+ Z6UIqONLKPAXSwsYdX73qYhtfbtTbIa2eEt9w= MIME-Version: 1.0 Received: by 10.150.147.9 with HTTP; Wed, 31 Mar 2010 18:04:22 -0700 (PDT) In-Reply-To: References: <2C2F1EBA8050E74EA81502D5740B4BD693F018909C@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD693F01890A0@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 31 Mar 2010 18:04:22 -0700 Received: by 10.150.80.3 with SMTP id d3mr633128ybb.212.1270083863045; Wed, 31 Mar 2010 18:04:23 -0700 (PDT) Message-ID: Subject: Re: Different UDP dest ports From: Vishwas Manral To: Glen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 01:03:55 -0000 Hi Glen, In my view when in doubt you should use the Multihop port. Thanks, Vishwas On Wed, Mar 31, 2010 at 5:48 PM, Glen Kent wrote: > Hi Shahram, > > By loopback i did not mean 12/8 but was alluding to IP interfaces that > are not tied to a particular physical port. They could have any > logical routable IP address > > Glen > > On Thu, Apr 1, 2010 at 6:14 AM, Shahram Davari wrote: >> Hi Glen, >> >> The loopback (12/8) address can't appear on a wire unless it is encapsulated in an IP or MPLS tunnel. >> For directly attached routers you can use either 1hop (3784) or Multi-hop (4784). But for non-directly attached router you need to use Multi-hop. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: Glen Kent [mailto:glen.kent@gmail.com] >> Sent: Wednesday, March 31, 2010 5:40 PM >> To: Shahram Davari >> Cc: rtg-bfd@ietf.org >> Subject: Re: Different UDP dest ports >> >> Hi Shahram, >> >> So the sender should be intelligent enough to use dst port 4784 if it >> knows that the packet is being sent on a multihop path. Fair enough. >> What happens if i need to send a packet destined to the system IP or >> the loopback IP of a directly connected router? Should i use 3784 or >> 4784? >> >> Glen >> >> On Thu, Apr 1, 2010 at 6:05 AM, Shahram Davari wrote: >>> Hi, >>> >>> The receiver needs to check the IPTTL=255 for 1hop, and the only way to differentiate between 1hop and multi-hop is by using different UDP dest port #. >>> >>> -Shahram >>> >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Glen Kent >>> Sent: Wednesday, March 31, 2010 5:32 PM >>> To: rtg-bfd@ietf.org >>> Subject: Different UDP dest ports >>> >>> Hi, >>> >>> What is the motivation for having different UDP dest ports for >>> directly connected IP nexthops (3784) and multhop paths (4784) in BFD? >>> >>> What do we lose by using just one, say 3784? >>> >>> Glen >>> >>> >>> >> >> >> >