From nobody Fri Apr 4 11:22:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDC71A0452 for ; Fri, 4 Apr 2014 11:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy-JNTNeF0mL for ; Fri, 4 Apr 2014 11:22:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 61E461A0235 for ; Fri, 4 Apr 2014 11:22:37 -0700 (PDT) X-AuditID: c6180641-b7f768e000001855-60-533ef580f8e9 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9F.88.06229.085FE335; Fri, 4 Apr 2014 20:10:08 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Fri, 4 Apr 2014 14:22:31 -0400 From: Gregory Mirsky To: "rtg-bfd@ietf.org" Subject: New Version Notification for draft-aldrin-bfd-seamless-use-case-01.txt Thread-Topic: New Version Notification for draft-aldrin-bfd-seamless-use-case-01.txt Thread-Index: Ac9QMpp/OcxMVcrIQA6QwT2a5vE7XA== Date: Fri, 4 Apr 2014 18:22:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78DF90@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B78DF90eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyuXRPuG7DV7tgg1M/TC0+/9nG6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNWrz7IWTPSqOPXwHWsD40PHLkZODgkBE4nVja/ZIGwxiQv3 1gPZXBxCAkcZJa7OPM8O4SxjlNh5/g0zSBWbgJHEi4097CC2iICmxNo521lBbGGBQImzR+4x QcTDJE5NnMcCYetJtKzeBlbPIqAisejMfqA4BwevgK/E0ed5IGFGoMXfT60Ba2UWEJe49WQ+ E8RBAhJL9pxnhrBFJV4+/scKYStK7Oufzg5Rny/R09cIVsMrIChxcuYTlgmMQrOQjJqFpGwW kjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipGjtDi1LDfdyHATIzDwj0mwOe5gXPDJ 8hCjNAeLkjjvl7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYzXge/nI/Ee6lsC3s0blV woJ/OwzWHtnAMfdvSpvau1/CN9e8+Rb8UMrVYGk/b2dVVuO/Wyp2y/Lif6jezH33k+/opokM JsoK70s/Hn1qOslG5hqbcFGaho+p+h/jEvY2WY/9t25PrPCav7fgbv/G85vu/Gr+uzA3neGf jY3kwa5nPiaWwt/2KLEUZyQaajEXFScCAPHPzFdKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kj9Xhm6t-11RIAmYwTNgas4sYwE X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 18:22:42 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78DF90eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, apologies for duplicated and multiplicated copies as we've experienced some= mail-list issues lately. Many thanks to Sam for patiently and thoroughly preparing and publishing th= e next version of the document. We have started discussion among authors that I'd like to bring to the WG a= ttention and get your comments. * do you think that section Introduction to Seamless BFD may be mov= ed past section Use Cases? Would having requirements toward enhanced BFD fi= rst and then map them to the Seamless BFD mechanisms help? * Section 3.1 refers to "unidirectional BFD". I think that we don't= have such mechanism in BFD yet. What we are trying to characterize may be = better referred as "single-ended behavior". Your questions, suggestions , and comments always welcome and greatly appre= ciated by authors. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B78DF90eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

apologies for duplicated = and multiplicated copies as we’ve experienced some mail-list issues l= ately.

 <= /p>

Many thanks to Sam for pa= tiently and thoroughly preparing and publishing the next version of the doc= ument.

We have started discussio= n among authors that I’d like to bring to the WG attention and get yo= ur comments.

·      = ;   do you think that= section Introduction to Seamless BFD may be moved past section Use Cases? = Would having requirements toward enhanced BFD first and then map them to the Seamless BFD mechanisms help?

·      = ;   Section 3.1 refer= s to “unidirectional BFD”. I think that we don’t have suc= h mechanism in BFD yet. What we are trying to characterize may be better referred as “single-ended behavior”.

 <= /p>

Your questions, suggestio= ns , and comments always welcome and greatly appreciated by authors.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

 

--_000_7347100B5761DC41A166AC17F22DF1121B78DF90eusaamb103erics_-- From nobody Fri Apr 4 12:27:23 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B519C1A0452 for ; Fri, 4 Apr 2014 12:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u_weNzDjChS for ; Fri, 4 Apr 2014 12:27:16 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id CCB731A04BA for ; Fri, 4 Apr 2014 12:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=948; q=dns/txt; s=iport; t=1396639632; x=1397849232; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Nth712pf0wq72HwWUGVl5iC9pjILWXT6r74nMV10jtw=; b=LtEi/rjQKsaS1YgyGKEiW/eoUcqND66TxnJKIVBfbJMclahN1or4gs+T kqSK87mLXvmPYdMx3H+oNdnTw/diYylpZ+uQoSPw/IYNIizu3M5gEKBE9 MIoR0UC6rK51yUVmnqEIfY6aq+rIT7PHhxwRoEdNWahcut27Tmp5fEVN9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAN4GP1OtJA2G/2dsb2JhbABZgmUhgRLEDoEkFnSCJQEBAQMBOj0HCwIBCCIUEDIlAQEEARqHaQgB0CIXjiABAR44gySBFAEDqxqDMIFyOQ X-IronPort-AV: E=Sophos;i="4.97,796,1389744000"; d="scan'208";a="33144498" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 04 Apr 2014 19:27:12 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s34JRBNV001548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 19:27:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 14:27:11 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-aldrin-bfd-seamless-use-case-01.txt Thread-Topic: New Version Notification for draft-aldrin-bfd-seamless-use-case-01.txt Thread-Index: Ac9QMpp/OcxMVcrIQA6QwT2a5vE7XAACMAhQ Date: Fri, 4 Apr 2014 19:27:10 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B78DF90@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B78DF90@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-MyC39uMqwr-zHUuUtTT53VpFJk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 19:27:21 -0000 Hi Sam, Greg, All, > Dear All, > apologies for duplicated and multiplicated copies as we've experienced > some mail-list issues lately. I too apologize to everyone on this list for resending my response again, p= rior emails weren't archived. =20 > * do you think that section Introduction to Seamless BFD may be moved pas= t > section Use Cases? Would having requirements toward enhanced BFD first > and then map them to the Seamless BFD mechanisms help? I think that's a good idea. > * Section 3.1 refers to "unidirectional BFD". I think that we don't have = such > mechanism in BFD yet. What we are trying to characterize may be better > referred as "single-ended behavior". "single-ended behavior" characterises it fairly well. Also in section (3.4), there's no need to tie this to Segment Routing eithe= r. One can do the same thing with MPLS static as well. Perhaps we can gener= alize this use-case. -Nobo From nobody Mon Apr 7 08:08:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82191A0791; Mon, 7 Apr 2014 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwcVi42Tcxsj; Mon, 7 Apr 2014 08:08:34 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB991A0781; Mon, 7 Apr 2014 08:08:34 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id c6fb2435.0.5225.00-2354.15075.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 07 Apr 2014 15:08:29 +0000 (UTC) X-MXL-Hash: 5342bf6d19e1f23c-5fb45c684da7879e5b33af559819792bac94ee70 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s37F8RQp001117; Mon, 7 Apr 2014 11:08:28 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s37F8FNH000796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2014 11:08:21 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 7 Apr 2014 15:08:01 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 11:08:01 -0400 From: "BRUNGARD, DEBORAH A" To: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Prep for IESG review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext Thread-Topic: Prep for IESG review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext Thread-Index: Ac9ScyqegRoGiALTRMWBWVujf+IFFg== Date: Mon, 7 Apr 2014 15:08:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.71.59] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=W6OPo2qk c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=jHPW6ygmP3IA:10 a=ofMgfj31e3cA:10 a=By6Mh84-ZgcA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=xT-_WGOjd] X-AnalysisOut: [5w2C3Hgg20A:9 a=CjuIK1q_8ugA:10 a=5v5zimUNW9oA:10 a=aQW1B-] X-AnalysisOut: [_K2K0A:10 a=gTNRcJHmHxC0pAnbdLYA:9 a=_W_S_7VecoQA:10 a=frz] X-AnalysisOut: [4AuCg-hUA:10 a=cjh8W46Ov5fGW6Oo:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UBGJxUZ5cKo6rTz2I2v7_fBQsJI Cc: "ccamp@ietf.org" , Lou Berger X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 15:08:40 -0000 --_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS, BFD, CCAMP has submitted this draft for publication, it is currently being updat= ed for AD review comments. If any comments, please use the ccamp mailing list. Thanks, Deborah --_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
MPLS, BFD,
 
CCAMP has submitted this draft for publication, it is currently being = updated for AD review comments.
 
If any comments, please use the ccamp mailing list.
 
Thanks,
Deborah
 
 
 --_000_F64C10EAA68C8044B33656FA214632C80C177F47MISOUT7MSGUSR9O_-- From nobody Mon Apr 7 10:07:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD0D1A07F6 for ; Mon, 7 Apr 2014 10:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKkvHMbC8Bl9 for ; Mon, 7 Apr 2014 10:07:08 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9C81A01E0 for ; Mon, 7 Apr 2014 10:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=574; q=dns/txt; s=iport; t=1396890422; x=1398100022; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=EMr3XYnE12dia45T1PwRJGERo3LxxzM5hkDpmd2rgfY=; b=KAww7O5l6d35kq3qyMIIRGBFVN0k7X0+ucwdB9Q1fZZKy7Xxi6MvxJtk gyciRgxnAB5f6airCqJO3XCNHv1Klil98Rne/BQka1Ky8egWBwYQu33kN TVAAW3P0ASmhYA//leMyJlrPdWvUJzYWzU6xyQgn5F4yqW4z5UI1A28GT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAFbaQlOtJA2J/2dsb2JhbABZgmUhgRLEJYEoFnSCJwEEOj8SASoUQiYBBA4Nh3EBzBsXjkAxgyuBFASrGoMwgis X-IronPort-AV: E=Sophos;i="4.97,811,1389744000"; d="scan'208";a="33706101" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 07 Apr 2014 17:07:01 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s37H71kX025519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Apr 2014 17:07:01 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 12:07:01 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+g== Date: Mon, 7 Apr 2014 17:07:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/a-bOGQY44GNPUsDzmYx3TJzKQPk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 17:07:13 -0000 Hi BFDers, Authors of draft-ietf-bfd-intervals have discussed and concluded that defin= ed "common intervals set" does _not_ need to be maintained by IANA. Reasons: 1. Document is an informational draft. 2. Additions of interval(s) in the "common intervals set" should anyways be= done through a new draft, whether or not draft-ietf-bfd-intervals creates = an IANA registry and defines allocation policies for it. Do you agree with this? Do you see any concern with this? Seeking opinions/comments from folks on this matter. Thanks, Nobo, Marc, Greg From nobody Mon Apr 7 20:05:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B731A00AB for ; Mon, 7 Apr 2014 20:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of21iR3X-xEL for ; Mon, 7 Apr 2014 20:05:35 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF3E61A00AD for ; Mon, 7 Apr 2014 20:05:32 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wp18so357176obc.23 for ; Mon, 07 Apr 2014 20:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tQtnqFkiAuUxbBlmGpd96ZZ7MlcggWILE7AAYDB+R3M=; b=GSznCzI3aCTSu5siUfodazMKQPXZ7KcHnyBwfZDb6+T3JsfSe3FnONa8ZjAQ0Wwio3 hm/BrUcWwhsVgRx5fkO4Igha4OeADR+qMJ5RU+RCnkcWXcGl3Uk9id0nKsa3FAEklUL2 dR8v2g4GVB10nBQu9UJYjDcOX8sU7qAfh9AkpjPuUI+QBG2uyw9BhyilEmsz9pyw/mED acZQVTsRYi9Rc8cCDoyFpstcPK0v/SDwlf7JwoVSIJAWxeOpyWFeaNt45mJVaoGbHOeA n9S4HeTJbK8Y0QlUDxeth/4Cq0UdvX69Qq4Q+mwiWotcq/kTeuhD9tzfprMIXmxfws49 22zA== X-Received: by 10.60.50.163 with SMTP id d3mr918273oeo.51.1396926327178; Mon, 07 Apr 2014 20:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.41 with HTTP; Mon, 7 Apr 2014 20:05:07 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Mon, 7 Apr 2014 23:05:07 -0400 Message-ID: Subject: Re: draft-ietf-bfd-intervals IANA considerations? To: "Nobo Akiya (nobo)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ptA3sCwHNvD2xrJiGVp6xIJd4tE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 03:05:40 -0000 There is no problem with having IANA Considerations setting up a registry or the like in an Informational document. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) wrote: > Hi BFDers, > > Authors of draft-ietf-bfd-intervals have discussed and concluded that defined "common intervals set" does _not_ need to be maintained by IANA. > > Reasons: > 1. Document is an informational draft. > 2. Additions of interval(s) in the "common intervals set" should anyways be done through a new draft, whether or not draft-ietf-bfd-intervals creates an IANA registry and defines allocation policies for it. > > Do you agree with this? > Do you see any concern with this? > > Seeking opinions/comments from folks on this matter. > > Thanks, > Nobo, Marc, Greg > From nobody Mon Apr 7 20:12:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E5F1A00AE for ; Mon, 7 Apr 2014 20:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id migpSrOBqCRL for ; Mon, 7 Apr 2014 20:11:52 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 17FDD1A00B0 for ; Mon, 7 Apr 2014 20:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1502; q=dns/txt; s=iport; t=1396926702; x=1398136302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=16y1Lcra1HPNFMyCqNaxYWF37TdV65/hDDDvm/WLIMw=; b=BDBLYcUhqRCuPcnlL66AFBwsqyKSCa0sSuF/Xb2T+8Rcb/3GCyC/ocfR sEWi5L5kq4e5ZYORW4RDtoQ+wFagUw6/be0wbJkrzMHAqyNzasFOp2cap iAPI0yOmvuru6p6jsdYUIb9McY1P72+UquNrQNOgMI7n72YvTDKk1Qc7x w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFBoQ1OtJV2c/2dsb2JhbABWA4MGgRLEKYEeFnSCJQEBAQR5DAQCAQgOAwMBAgEuIREdCAEBBAENBYdlAxHEMQ2GaxeMUYFmIxAHBguEJwEDiSONTIFtjHGFT4Mwgis X-IronPort-AV: E=Sophos;i="4.97,815,1389744000"; d="scan'208";a="33827902" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 08 Apr 2014 03:11:41 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s383BfR8026738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 03:11:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 22:11:41 -0500 From: "Carlos Pignataro (cpignata)" To: Donald Eastlake , "Nobo Akiya (nobo)" Subject: Re: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAfyXWA//++xgA= Date: Tue, 8 Apr 2014 03:11:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.254.227] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <899CB87147296F449B08A8181D22451F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gUZnyYRgjrfY48OW611L_BHw5HY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 03:11:57 -0000 Donald, I agree with this as a general statement. As it pertains to the =B3Common interval values=B2, it does not appear that is the role of an IANA numbers registry. Thanks, Carlos. -----Original Message----- From: Donald Eastlake Date: Monday, April 7, 2014 at 11:05 PM To: Nobo Akiya Cc: "rtg-bfd@ietf.org" Subject: Re: draft-ietf-bfd-intervals IANA considerations? >There is no problem with having IANA Considerations setting up a >registry or the like in an Informational document. > >Thanks, >Donald >=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 > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > >On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) wrote: >> Hi BFDers, >> >> Authors of draft-ietf-bfd-intervals have discussed and concluded that >>defined "common intervals set" does _not_ need to be maintained by IANA. >> >> Reasons: >> 1. Document is an informational draft. >> 2. Additions of interval(s) in the "common intervals set" should >>anyways be done through a new draft, whether or not >>draft-ietf-bfd-intervals creates an IANA registry and defines allocation >>policies for it. >> >> Do you agree with this? >> Do you see any concern with this? >> >> Seeking opinions/comments from folks on this matter. >> >> Thanks, >> Nobo, Marc, Greg >> > From nobody Mon Apr 7 21:41:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BF1A00E3 for ; Mon, 7 Apr 2014 21:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcvFyhxWTwMH for ; Mon, 7 Apr 2014 21:41:01 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB0C1A00D3 for ; Mon, 7 Apr 2014 21:40:58 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 04:40:51 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 04:40:51 +0000 From: Alexander Vainshtein To: "Carlos Pignataro (cpignata)" , Donald Eastlake , "Nobo Akiya (nobo)" Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAVTz+AAAA6kAAAAshEGw== Date: Tue, 8 Apr 2014 04:40:51 +0000 Message-ID: <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.64.194.172] x-forefront-prvs: 017589626D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(164054003)(51704005)(30594002)(377454003)(199002)(189002)(49866001)(20776003)(50986001)(46102001)(74316001)(92566001)(65816001)(90146001)(33646001)(95666003)(80022001)(74366001)(97336001)(66066001)(79102001)(77982001)(47976001)(59766001)(93136001)(94316002)(31966008)(4396001)(86362001)(47736001)(63696002)(93516002)(19580405001)(76576001)(94946001)(56816005)(56776001)(54356001)(97186001)(2656002)(81816001)(99396002)(74662001)(85852003)(81542001)(76786001)(87266001)(81686001)(85306002)(98676001)(69226001)(47446002)(76796001)(19580395003)(74502001)(83072002)(54316002)(74706001)(80976001)(74876001)(53806001)(76482001)(87936001)(81342001)(83322001)(95416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:BEFCF4DD.9472951A.70FD3DAB.4BE9DDC1.2038E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2C5d0Pbl0iXu0OYrrf7IngWceBw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 04:41:07 -0000 Carlos and all,=0A= I am not sure I follow the logic of the decision.=0A= Donald has already commented on setting a new registry in an Informational = document; and saying that new values would be always set via a new draft se= ems to map well to one of the already existing IANA policies.=0A= =0A= But what worries me most is the fact that without a IANA registry there wil= l be no single place where these "common interval values" could be looked u= p by implementers. Instead, they would have to track a (potentially long) s= equence of documents in order to understand what they should try to impleme= nt and test.=0A= =0A= I could also say that operators commonly request "compliance" with Informat= ional documents in RFPs and RFIs they publish. (Somebody has recently menti= oned requests to comply with some April 1 RFCs as well on the RTG-DIR :-).= And while such an argument would not hold in the court of law, I am not sur= e we should simply ignore it.=0A= =0A= My 2c,=0A= Sasha=0A= =0A= =0A= =0A= ________________________________________=0A= From: Rtg-bfd on behalf of Carlos Pignataro (cpi= gnata) =0A= Sent: Tuesday, April 8, 2014 6:11 AM=0A= To: Donald Eastlake; Nobo Akiya (nobo)=0A= Cc: rtg-bfd@ietf.org=0A= Subject: Re: draft-ietf-bfd-intervals IANA considerations?=0A= =0A= Donald,=0A= =0A= I agree with this as a general statement. As it pertains to the =B3Common= =0A= interval values=B2, it does not appear that is the role of an IANA numbers= =0A= registry.=0A= =0A= Thanks,=0A= =0A= Carlos.=0A= =0A= -----Original Message-----=0A= From: Donald Eastlake =0A= Date: Monday, April 7, 2014 at 11:05 PM=0A= To: Nobo Akiya =0A= Cc: "rtg-bfd@ietf.org" =0A= Subject: Re: draft-ietf-bfd-intervals IANA considerations?=0A= =0A= >There is no problem with having IANA Considerations setting up a=0A= >registry or the like in an Informational document.=0A= >=0A= >Thanks,=0A= >Donald=0A= >=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=0A= > Donald E. Eastlake 3rd +1-508-333-2270 (cell)=0A= > 155 Beaver Street, Milford, MA 01757 USA=0A= > d3e3e3@gmail.com=0A= >=0A= >=0A= >On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) wrote:= =0A= >> Hi BFDers,=0A= >>=0A= >> Authors of draft-ietf-bfd-intervals have discussed and concluded that=0A= >>defined "common intervals set" does _not_ need to be maintained by IANA.= =0A= >>=0A= >> Reasons:=0A= >> 1. Document is an informational draft.=0A= >> 2. Additions of interval(s) in the "common intervals set" should=0A= >>anyways be done through a new draft, whether or not=0A= >>draft-ietf-bfd-intervals creates an IANA registry and defines allocation= =0A= >>policies for it.=0A= >>=0A= >> Do you agree with this?=0A= >> Do you see any concern with this?=0A= >>=0A= >> Seeking opinions/comments from folks on this matter.=0A= >>=0A= >> Thanks,=0A= >> Nobo, Marc, Greg=0A= >>=0A= >=0A= =0A= From nobody Tue Apr 8 07:31:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3247C1A0402 for ; Tue, 8 Apr 2014 07:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.073 X-Spam-Level: X-Spam-Status: No, score=-112.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51IQOHpuClJ8 for ; Tue, 8 Apr 2014 07:31:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B33571A040F for ; Tue, 8 Apr 2014 07:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2321; q=dns/txt; s=iport; t=1396967498; x=1398177098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9qJCTA0URl3dfcPm5XjKlLPgEvJEkQBg3D31u+/vOfE=; b=RmLoJQ6A850drD2CPW//VwAkz2BQX6HRMPcNoyr3SzCdmiUIA/7gOf7v pdlEu8fOroBr7GBSTObgAtrMBqQV8dyjy6yV+stMRyjk31MnkDANUxjRr wHG58Ue5fPGCwjDjZEVEMHJ4s4Spowv66Fqu98+7QcCCS86SO7baFUziN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALcHRFOtJV2d/2dsb2JhbABZgmUhgRLEJ4EeFnSCJQEBAQMBOj8FCwIBCCIUEDIlAQEEAQ0Nh2wIAcpKF447MQeDJIEUAQOUcJYtgzCCKw X-IronPort-AV: E=Sophos;i="4.97,818,1389744000"; d="scan'208";a="315904531" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 08 Apr 2014 14:31:37 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s38EVbqC023650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 14:31:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 09:31:37 -0500 From: "Nobo Akiya (nobo)" To: Alexander Vainshtein , "Carlos Pignataro (cpignata)" , Donald Eastlake Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAfyXWA//++xgCAAFv5gP//tfLw Date: Tue, 8 Apr 2014 14:31:36 +0000 Message-ID: References: , <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2oR12mZSo2Dmofjt9ggfOM5lwpc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:31:41 -0000 Hi Sasha, Carlos, Donald, all, Thanks for comments. Sasha, Donald, I think you are saying we can create IANA registry, which I = agree. But are you saying we *should* create IANA registry for this documen= t? Comments inline. > Donald has already commented on setting a new registry in an > Informational document; and saying that new values would be always set > via a new draft seems to map well to one of the already existing IANA > policies. Sure. My question then is, if we were to create one IANA registry for "comm= on interval values", do we create one registry or also prepare *optional* r= egistry where intervals specific to application/session-type can go into? > But what worries me most is the fact that without a IANA registry there w= ill > be no single place where these "common interval values" could be looked > up by implementers. Instead, they would have to track a (potentially long= ) > sequence of documents in order to understand what they should try to > implement and test. We probably won't have that many "updates", and it shouldn't be that diffic= ult to locate right documents via internet. If we see a trend of possible i= terative updates, it's possible to create an IANA registry at that point as= well (with first of such draft). > I could also say that operators commonly request "compliance" with > Informational documents in RFPs and RFIs they publish. (Somebody has > recently mentioned requests to comply with some April 1 RFCs as well on > the RTG-DIR :-).And while such an argument would not hold in the court of > law, I am not sure we should simply ignore it. Pointing to RFCs for RFPs/RFIs and claiming conformance via RFCs will proba= bly be simpler than referring to an IANA registry in this case (i.e. these = intervals of this IANA registry). If we were aiming this document as "standard track", then we definitely wan= t to pursue creation of IANA registry. However, this is an "informational" = track document (instructed by RTG directorates) which is simply used as a r= eferenced for "recommendation". Considering there doesn't seem to be strong= benefit in creating IANA registry for it at this point, not entirely convi= nced that we should accompany it with IANA registry. Is there benefits? -Nobo From nobody Tue Apr 8 09:40:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E551A0431 for ; Tue, 8 Apr 2014 09:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2pXTSpG0CE1 for ; Tue, 8 Apr 2014 09:40:47 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB71A04A1 for ; Tue, 8 Apr 2014 09:40:41 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 16:40:39 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 16:40:39 +0000 From: Alexander Vainshtein To: "Nobo Akiya (nobo)" , "Carlos Pignataro (cpignata)" , Donald Eastlake Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAVTz+AAAA6kAAAAshEGwAU9tAAAAQ9Fpk= Date: Tue, 8 Apr 2014 16:40:39 +0000 Message-ID: References: , <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.64.194.172] x-forefront-prvs: 017589626D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(189002)(199002)(99396002)(90146001)(83322001)(97336001)(81686001)(56816005)(74662001)(65816001)(20776003)(81542001)(81342001)(33646001)(59766001)(49866001)(87936001)(76482001)(74366001)(66066001)(46102001)(80022001)(19580405001)(74876001)(74316001)(97186001)(54356002)(47976002)(54316003)(47736002)(47446003)(79102001)(81816001)(74706001)(19580395003)(80976001)(4396001)(63696002)(31966008)(74502001)(95666003)(77982001)(98676001)(69226001)(92566001)(94316002)(94946001)(85306002)(76786001)(87266001)(76796001)(95416001)(76576001)(93136001)(93516002)(2656002)(86362001)(56776001)(85852003)(53806002)(83072002)(50986002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:AEDCF015.AFCA99D9.30F32D8B.5AE9C0D1.20449; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/C4h5vaDgMLeo-v3KQhf_hHJtdoo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:40:53 -0000 Nobo, and all,=0A= Regarding the structure of the registry (if we go for it) - I'd say that a = flat structure (with comments pointing to specific application needs) would= suffice. No need to make things more complicated than they are already:-)= =0A= =0A= Regarding the benefit - a single repository for commonly used values always= helps IMO. Of course, you can search Internet for almost everything - but = does not this apply to almost all other numbers IANA maintains in its regis= tries today? Starting from such things as special use IPv4 addresses?=0A= RFC 3330 has been published as Informational - but it was authored by IANA,= so I suspect (even if I cannot prove it) that there was some kind of e reg= istry for these addresses even in 2002. And it is now obsoleted by RFC 5735= that is a BCP.=0A= =0A= My 2c,=0A= Sasha=0A= =0A= =0A= ________________________________________=0A= From: Nobo Akiya (nobo) =0A= Sent: Tuesday, April 8, 2014 5:31 PM=0A= To: Alexander Vainshtein; Carlos Pignataro (cpignata); Donald Eastlake=0A= Cc: rtg-bfd@ietf.org=0A= Subject: RE: draft-ietf-bfd-intervals IANA considerations?=0A= =0A= Hi Sasha, Carlos, Donald, all,=0A= =0A= Thanks for comments.=0A= =0A= Sasha, Donald, I think you are saying we can create IANA registry, which I = agree. But are you saying we *should* create IANA registry for this documen= t?=0A= =0A= Comments inline.=0A= =0A= > Donald has already commented on setting a new registry in an=0A= > Informational document; and saying that new values would be always set=0A= > via a new draft seems to map well to one of the already existing IANA=0A= > policies.=0A= =0A= Sure. My question then is, if we were to create one IANA registry for "comm= on interval values", do we create one registry or also prepare *optional* r= egistry where intervals specific to application/session-type can go into?= =0A= =0A= > But what worries me most is the fact that without a IANA registry there w= ill=0A= > be no single place where these "common interval values" could be looked= =0A= > up by implementers. Instead, they would have to track a (potentially long= )=0A= > sequence of documents in order to understand what they should try to=0A= > implement and test.=0A= =0A= We probably won't have that many "updates", and it shouldn't be that diffic= ult to locate right documents via internet. If we see a trend of possible i= terative updates, it's possible to create an IANA registry at that point as= well (with first of such draft).=0A= =0A= > I could also say that operators commonly request "compliance" with=0A= > Informational documents in RFPs and RFIs they publish. (Somebody has=0A= > recently mentioned requests to comply with some April 1 RFCs as well on= =0A= > the RTG-DIR :-).And while such an argument would not hold in the court of= =0A= > law, I am not sure we should simply ignore it.=0A= =0A= Pointing to RFCs for RFPs/RFIs and claiming conformance via RFCs will proba= bly be simpler than referring to an IANA registry in this case (i.e. these = intervals of this IANA registry).=0A= =0A= If we were aiming this document as "standard track", then we definitely wan= t to pursue creation of IANA registry. However, this is an "informational" = track document (instructed by RTG directorates) which is simply used as a r= eferenced for "recommendation". Considering there doesn't seem to be strong= benefit in creating IANA registry for it at this point, not entirely convi= nced that we should accompany it with IANA registry.=0A= =0A= Is there benefits?=0A= =0A= -Nobo=0A= =0A= From nobody Tue Apr 8 11:27:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5030C1A0416 for ; Tue, 8 Apr 2014 11:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTiNKlBsPljp for ; Tue, 8 Apr 2014 11:27:30 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 60A511A068B for ; Tue, 8 Apr 2014 11:27:24 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so1360508pde.29 for ; Tue, 08 Apr 2014 11:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=J6SK/V9i0UE+gVqYIfevqisvc7lG3YA9LGrYtc0gIzQ=; b=pY3EVcPEeyiDsR9wM2zjrsddibuQBPkWP6J2JfgMwXHpdicNuoj1C+maQDHLsCrTUL FciAAO/WXj7P0ytuXP6HSaj+BfpoDmAEIZnROUaqJY87yzsJ0UA9VWfg4UJSqkXv7VmL WFwFokhCPfjjXAf7DN1Q0N/GrINbCnanv7hFiyk9L3ScU8PFKpjhnLPVplCMIl6jAxUd c4Rjfb0vT54MYMfuQD/F4TABbS3vDWnyU6W9kwO+nuK96D2ctrCS/s7oSbUimf8YCo+u 1ONfi2qI8xiYN92AwQK8FyPBIYzysUROQcDOe3PSwWOIL7U5uWgsraUDeJGrbNqOkRXw kezA== X-Received: by 10.68.139.71 with SMTP id qw7mr6468366pbb.68.1396981644342; Tue, 08 Apr 2014 11:27:24 -0700 (PDT) Received: from [10.226.163.182] (mobile-198-228-223-223.mycingular.net. [198.228.223.223]) by mx.google.com with ESMTPSA id pv4sm6103691pbb.55.2014.04.08.11.27.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 11:27:23 -0700 (PDT) References: <20140319082501342601.778988ca@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B50DD@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140321175433104493.12bf1506@sniff.de> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <093ED17D-3805-46B4-8A58-8411B395C9E9@gmail.com> X-Mailer: iPhone Mail (11D167) From: Sam Aldrin Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Date: Tue, 8 Apr 2014 11:27:19 -0700 To: "Nobo Akiya (nobo)" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/v13RV7qMU9rLjL2eXgGA4gEC4Nk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:27:38 -0000 Would it be better to see some references to use cases from the base documen= t? That way, it provides right context. Just a thought. Cheers Sam Sent from my iPhone > On Mar 23, 2014, at 7:56 AM, "Nobo Akiya (nobo)" wrote: >=20 > Hi Marc, et al, >=20 >> * the authors of the draft write down what they have in mind for the D bi= t >> and publish it as -03 draft. Seems this will require a closer look at tex= t >> details, so having it properly written down would be great >=20 > There has been many responses around this particular point (and thanks to a= ll who has responded!), it would be a good idea to have a revised document w= hich provides a new starting baseline for further discussions. Although at t= his point, *rough consensus* does seem to be D-bit approach. We would place t= he D-bit as the solution, but place all other alternatives in the Appendix. >=20 > The other thing which I would like to point out is that, we are actively d= iscussing the solution but not the use-cases ... many of us are engineers!? := ) What would be helpful to take S-BFD to the next step (i.e. re-chartering a= nd WG adoption) is for us to discuss more of use-cases on the list. >=20 > Thus I'd like to direct some of the attention to the S-BFD use-case draft.= >=20 > http://tools.ietf.org/html/draft-aldrin-bfd-seamless-use-case-00 >=20 > Do you [not] agree with use-cases listed? > Do you see any other use-cases which should be added? > Even a comment such as "I agree with this use-case from the draft" is very= helpful. >=20 > -Nobo >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Friday, March 21, 2014 8:55 PM >> To: Nobo Akiya (nobo); Santosh P K; Bhatia, Manav (Manav); >> aldrin.ietf@gmail.com; MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>=20 >> Hello, >>=20 >> may I propose two things: >>=20 >> * the authors of the draft write down what they have in mind for the D bi= t >> and publish it as -03 draft. Seems this will require a closer look at tex= t >> details, so having it properly written down would be great >>=20 >>=20 >> * the discussion about the loop prevention should be completed, there are= >> several proposals open. I would like to see what options are available. S= ure, >> when the authors found a clean path for the "D" bit then this is somewhat= >> academic but so far the discussion isn't finished, I think >>=20 >> * the discriminator proposal. I will re-re-read it but have still proble= ms to >> see why the my_discr of a packet received by the initiator is used for ..= . >> multiplexing? Something else? Sorry, I may be slow thinking here. >>=20 >> * Girija proposal to use the state. As S-BFD introduces a new state mach= ine >> this seems a valid proposal. Haven't seen any reply on the list (beside >> myself) >>=20 >> * my "Required Min Echo RX Interval" proposal. If it's wrong or "weird" I= >> would like to learn about it. >>=20 >> * Greg's source UDP port idea (if I understand it right: reflector uses S= -BFD >> port as source port + rule: never reflect when source port is the well-kn= own >> S-BFD port). >>=20 >>=20 >> Basically a summary with why it won't work or at least pros/cons? >>=20 >>=20 >>=20 >> Thanks & Regards, >> Marc >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Thu, 20 Mar 2014 11:40:54 +0000, Nobo Akiya (nobo) wrote: >>> Hi Santosh, >>>=20 >>>>> If implementation shares the local discriminator pool between BFD >>>>> and S-BFD, then session object located with your_discrim in incoming >>>>> packet will provide the bfd.SessionType. >>>>=20 >>>> If pool is shared then how can your_disc help to get the sessionType? >>>> Did you mean not share pool between BFD and S-BFD? >>>=20 >>> If we mimic the logic from multipoint draft, it would be something >>> like this. >>>=20 >>> If the Your Discriminator field is nonzero >>>=20 >>> Select a session based on the value of Your Discriminator. >>> If no session is found, the packet MUST be discarded. >>>=20 >>> If bfd.SessionType is SBFDInitiator >>>=20 >>> If Demand (D) bit is set, the packet MUST be discarded. >>>=20 >>> Else if bfd.sessionType is SBFDReflector >>>=20 >>> If Demand (D) bit is clear, the packet MUST be discarded. >>>=20 >>> Else (non S-BFD) >>>=20 >>> ... >>>=20 >>> -Nobo >>>=20 >>>> -----Original Message----- >>>> From: Santosh P K [mailto:santoshpk@juniper.net] >>>> Sent: Thursday, March 20, 2014 7:01 AM >>>> To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger >>>> Cc: rtg-bfd@ietf.org >>>> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >>>>=20 >>>> Nobo, >>>> I am confused with your statement below. Can you please clarify? >>>>=20 >>>>=20 >>>>> If implementation shares the local discriminator pool between BFD >>>>> and S-BFD, then session object located with your_discrim in incoming >>>>> packet will provide the bfd.SessionType. >>>>=20 >>>> If pool is shared then how can your_disc help to get the sessionType? >>>> Did you mean not share pool between BFD and S-BFD? >>>>=20 >>>>=20 >>>> Thanks >>>> Santosh P K >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>>> Akiya >>>>> (nobo) >>>>> Sent: Thursday, March 20, 2014 6:20 AM >>>>> To: Bhatia, Manav (Manav); Marc Binderberger >>>>> Cc: rtg-bfd@ietf.org >>>>> Subject: RE: Loop Prevention in S-BFD >>>>> (draft-akiya-bfd-seamless-base) >>>>>=20 >>>>> Agree with Manav. >>>>>=20 >>>>> One nit and one clarification. >>>>>=20 >>>>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD >>>>>> reflector to reflect the S-BFD packets that it receives. The S-BFD >>>>>> reflectors should discard all packets that come with the D bit clear.= >>>>>=20 >>>>> s/The S-BFD reflectors should discard/The S-BFD reflectors MUST >>>>> discard/ >>>>>=20 >>>>>> Please note that we will always know the S-BFD clients/reflectors >>>>>> since they would use a new UDP port. >>>>>=20 >>>>> If implementation shares the local discriminator pool between BFD >>>>> and S-BFD, then session object located with your_discrim in incoming >>>>> packet will provide the bfd.SessionType. In this implementation, >>>>> non-IP based S-BFD can be supported without new G-Ach code point for >>>>> S-BFD. If implementation does not share the local discriminator pool >>>>> between BFD and S-BFD, then UDP port is required to first figure out >>>>> which table to lookup the session object, in which case will provide >>>>> BFD or S-BFD answer. In this implementation, non-IP based S- BFD >>>>> will require separate G-Ach code point than BFD (but one new G-Ach >>>>> code point for S-BFD should be sufficient). We should probably >>>>> assume that the >>>> latter is needed. >>>>>=20 >>>>> -Nobo >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Bhatia, Manav (Manav) >>>>>> [mailto:manav.bhatia@alcatel-lucent.com] >>>>>> Sent: Wednesday, March 19, 2014 8:01 PM >>>>>> To: Nobo Akiya (nobo); Marc Binderberger >>>>>> Cc: rtg-bfd@ietf.org >>>>>> Subject: RE: Loop Prevention in S-BFD >>>>>> (draft-akiya-bfd-seamless-base) >>>>>>=20 >>>>>> Adding on top of what Nobo has already said. >>>>>>=20 >>>>>> New bfd.SessionType variables can be defined for S-BFD clients and >>>>>> reflectors. The S-BFD draft will update the "D" bit based on the >>>>>> bfd.SessionType variable. This requires no other changes to 5880/5881= . >>>>>> The S-BFD draft should unequivocally define what the "D" bit means >>>>>> in the context of the S-BFD packets. >>>>>>=20 >>>>>> It can still be called the "D" (demand) bit and will be redefined >>>>>> to something like below: >>>>>>=20 >>>>>> Demand (D) >>>>>>=20 >>>>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD >>>>>> reflector to reflect the S-BFD packets that it receives. The S-BFD >>>>>> reflectors should discard all packets that come with the D bit clear.= >>>>>>=20 >>>>>> S-BFD clients MUST always ignore packets coming with the "D" bit set.= >>>>>>=20 >>>>>> Please note that we will always know the S-BFD clients/reflectors >>>>>> since they would use a new UDP port. >>>>>>=20 >>>>>> I like this approach over the one that uses descriminator values >>>>>> simply because examining a bit to detect a loop is much easier to >>>>>> implement in hardware. Looking at the descriminator values and then >>>>>> detecting a loop cannot be easily done in HW. >>>>>>=20 >>>>>> Since the approach using the "D" bit seems to be acceptable to >>>>>> quite a few folks here, I would like to understand the reason, if >>>>>> any, for >>>> opposing this. >>>>>>=20 >>>>>> Cheers, Manav >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>>>>> Akiya >>>>>>> (nobo) >>>>>>> Sent: Wednesday, March 19, 2014 9:22 PM >>>>>>> To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) >>>>>>> Cc: rtg-bfd@ietf.org >>>>>>> Subject: RE: Loop Prevention in S-BFD >>>>>>> (draft-akiya-bfd-seamless-base) >>>>>>>=20 >>>>>>>> we will see how the discussion goes although I personally do not >>>>>>> think the >>>>>>>> M and D bit can be compared. Seems other people didn't see D a >>>>>>>> good >>>>>>> fit >>>>>>>> (formally) either. Anyway, I'll have a look again at the "M" bit >>>>>>>> and >>>>>>> the >>>>>>>> multipoint draft. >>>>>>>=20 >>>>>>> You are right Marc, M and D bit alone is not a good comparison. >>>>>>> However, it's not just M bit that's updated in the multipoint draft.= >>>>>>> Multipoint draft updates M bit, introduces new state variables >>>>>>> (bfd.SessionType) and updates RX procedures. >>>>>>>=20 >>>>>>> Take a look at following sections in the multipoint draft. >>>>>>> 4.4.1. New State Variable >>>>>>> 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing >>>>>>> BFD Control Packets >>>>>>>=20 >>>>>>> Since your_discrim in S-BFD (both directions) is never zero(0), >>>>>>> bfd.SessionType is derivable for all cases. And D bit check can be >>>>>>> added for new bfd.SessionType values defined for S-BFD (both >>>>>>> directions), as part of RX procedures. Not only this approach >>>>>>> doesn't require BFDv2, it also addresses the point raised by Greg (i= .e. >>>>>>> support for non-IP based S-BFD). >>>>>>>=20 >>>>>>> -Nobo >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>>>>> Sent: Wednesday, March 19, 2014 11:25 AM >>>>>>>> To: MALLIK MUDIGONDA (mmudigon) >>>>>>>> Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- >>>>>>>> bfd@ietf.org >>>>>>>> Subject: Re: Loop Prevention in S-BFD >>>>>>>> (draft-akiya-bfd-seamless-base) >>>>>>>>=20 >>>>>>>> Hello Mallik, >>>>>>>>=20 >>>>>>>> we will see how the discussion goes although I personally do not >>>>>>> think the >>>>>>>> M and D bit can be compared. Seems other people didn't see D a >>>>>>>> good >>>>>>> fit >>>>>>>> (formally) either. Anyway, I'll have a look again at the "M" bit >>>>>>>> and >>>>>>> the >>>>>>>> multipoint draft. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Regarding the discriminator usage for solving this, we do not >>>>>>>>> want >>>>>>> to >>>>>>>>> put any specific restrictions on the way discriminators are used. >>>>>>>>=20 >>>>>>>> what restriction? >>>>>>>>=20 >>>>>>>>> That's the reason the thread stopped there. Can't think of any >>>>>>>>> particular use case where MyDisc is used to demux, but that's >>>>>>>>> the reason not to impose this restriction. >>>>>>>>=20 >>>>>>>> Huh?! There is some misunderstanding here, so let me repeat the >>>>>>>> discriminator idea: >>>>>>>>=20 >>>>>>>> (1) S-BFD initiator R1 sends a BFD packet to reflector R2 >>>>>>>>=20 >>>>>>>> (2) Reflector R2 copies the my_discr from incoming packet into >>>>>>> your_discr >>>>>>>> for outgoing packet. >>>>>>>>=20 >>>>>>>> (3) Reflector R2 copies one of his local discriminator values >>>>>>>> into >>>>>>> my_discr of >>>>>>>> the outgoing packet. This local discriminator is not a "reflector >>>>>>>> discriminator" of R2. >>>>>>>>=20 >>>>>>>> (4) The S-BFD initiator R1 is doing normal BFD operations by >>>>>>>> looking >>>>>>> into the >>>>>>>> your_discr of the reflected packet to demux. >>>>>>>>=20 >>>>>>>> Especially R1 is not using "my_discr" of the reflected packet to >>>>>>> demux. >>>>>>>>=20 >>>>>>>> The point is: when someone is injecting an "endless loop" packet >>>>>>>> by >>>>>>> using >>>>>>>> the "reflector discriminator" of R1 as my_discr, the reflector >>>>>>> discriminator of >>>>>>>> R2 as your_discr and sends the packet to R2 then the steps above >>>>>>> result in a >>>>>>>> packet >>>>>>>>=20 >>>>>>>> attacker -> R2 -> R1 -> R2 -> drop/punt >>>>>>>>=20 >>>>>>>> So after maximum 2 reflections the loop is broken. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, Marc >>>=20 From nobody Thu Apr 10 03:04:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AC91A0671 for ; Thu, 10 Apr 2014 03:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wysJ39ny9m2G for ; Thu, 10 Apr 2014 03:04:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A631C1A01D8 for ; Thu, 10 Apr 2014 03:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4045; q=dns/txt; s=iport; t=1397124288; x=1398333888; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HKMbj7gOw4l/vswdMqYMBwFzN5OYzbmLWeEGkt1LOZM=; b=eZynJVrz6/IVE0FAvg1gO7I63iGuygfSLGVHJ47Wu9CDUsLrJDaio+sX 5r2QIOkS6SHOEmF2dpSqefo2ASwqU7X1chXB8rFYRVdOLdU23DF+jKR1v lgVoi+tMjeXOd602lj/NJFrogntFzK9/MY29HzI56kJShVZ31FT4ExdpA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAPBrRlOtJV2Z/2dsb2JhbABXA4MGgRLEKIEjFnSCJQEBAQMBeQUHBAIBCBEDAQEBAS4hER0IAQEEDgWHaAMJCMVJDYcJF4xTgWYIGxAHBguDE4EUBIkji06Bf4FujHOFT4Mwgis X-IronPort-AV: E=Sophos;i="4.97,833,1389744000"; d="scan'208";a="316626937" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 10 Apr 2014 10:04:47 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3AA4llo010900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Apr 2014 10:04:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 05:04:47 -0500 From: "Carlos Pignataro (cpignata)" To: Alexander Vainshtein Subject: Re: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAfyXWA//++xgCAAFv5gIADfy2A Date: Thu, 10 Apr 2014 10:04:46 +0000 Message-ID: References: , <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.229.74] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <99181DFE3992A8498C6D0005437DA68C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/wAkCAHa-WQV1hRJwChw1FVVBvNk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:04:54 -0000 Hi, Sasha, Thanks for the follow-up, please see inline. On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein wrote: > Carlos and all, > I am not sure I follow the logic of the decision. I do not think there's a decision yet, only a discussion. > Donald has already commented on setting a new registry in an Informationa= l document; and saying that new values would be always set via a new draft = seems to map well to one of the already existing IANA policies. >=20 It is clearly possible (and many times desirable) to create or update IANA = registries with Informational documents. I've done so myself as well. But "= it can be done" does not imply "it should be done". > But what worries me most is the fact that without a IANA registry there w= ill be no single place where these "common interval values" could be looked= up by implementers. Instead, they would have to track a (potentially long)= sequence of documents in order to understand what they should try to imple= ment and test. My perspective is that a set of suggested (or recommended) interval/timer v= alues, or default timer values, is not what a numbers registry is used for.= Many protocols recommend timer values (TCP, L2TP, etc), but I do not belie= ve those are managed by IANA. Tracking a linked-list of Updated RFCs is not= always fun, but in this case I would not expect a long list documents. It = also seems to me that when implementing or checking compliance against an R= FC, the first place to check is the RFC itself and not an IANA registry. >=20 > I could also say that operators commonly request "compliance" with Inform= ational documents in RFPs and RFIs they publish. (Somebody has recently men= tioned requests to comply with some April 1 RFCs as well on the RTG-DIR :-= ).And while such an argument would not hold in the court of law, I am not s= ure we should simply ignore it. >=20 That's fine but orthogonal to this discussion. Thanks, Carlos. > My 2c, > Sasha >=20 >=20 >=20 > ________________________________________ > From: Rtg-bfd on behalf of Carlos Pignataro (c= pignata) > Sent: Tuesday, April 8, 2014 6:11 AM > To: Donald Eastlake; Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: Re: draft-ietf-bfd-intervals IANA considerations? >=20 > Donald, >=20 > I agree with this as a general statement. As it pertains to the =B3Common > interval values=B2, it does not appear that is the role of an IANA number= s > registry. >=20 > Thanks, >=20 > Carlos. >=20 > -----Original Message----- > From: Donald Eastlake > Date: Monday, April 7, 2014 at 11:05 PM > To: Nobo Akiya > Cc: "rtg-bfd@ietf.org" > Subject: Re: draft-ietf-bfd-intervals IANA considerations? >=20 >> There is no problem with having IANA Considerations setting up a >> registry or the like in an Informational document. >>=20 >> Thanks, >> Donald >> =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 >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >>=20 >>=20 >> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) wrote= : >>> Hi BFDers, >>>=20 >>> Authors of draft-ietf-bfd-intervals have discussed and concluded that >>> defined "common intervals set" does _not_ need to be maintained by IANA= . >>>=20 >>> Reasons: >>> 1. Document is an informational draft. >>> 2. Additions of interval(s) in the "common intervals set" should >>> anyways be done through a new draft, whether or not >>> draft-ietf-bfd-intervals creates an IANA registry and defines allocatio= n >>> policies for it. >>>=20 >>> Do you agree with this? >>> Do you see any concern with this? >>>=20 >>> Seeking opinions/comments from folks on this matter. >>>=20 >>> Thanks, >>> Nobo, Marc, Greg >>>=20 >>=20 >=20 From nobody Thu Apr 10 03:40:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ECB1A01D3 for ; Thu, 10 Apr 2014 03:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDK-g8D1D0aA for ; Thu, 10 Apr 2014 03:39:58 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) by ietfa.amsl.com (Postfix) with ESMTP id B361B1A021B for ; Thu, 10 Apr 2014 03:39:57 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 10 Apr 2014 10:39:55 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0918.000; Thu, 10 Apr 2014 10:39:55 +0000 From: Alexander Vainshtein To: "Carlos Pignataro (cpignata)" Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAVTz+AAAA6kAAAAshEGwBwOlgAAABG9mA= Date: Thu, 10 Apr 2014 10:39:54 +0000 Message-ID: <4581a1d2d3b44a04b6317efb2f7bb090@AM3PR03MB612.eurprd03.prod.outlook.com> References: , <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(30594002)(252514010)(51914003)(377454003)(199002)(189002)(164054003)(24454002)(51704005)(13464003)(74502001)(83322001)(81342001)(66066001)(33646001)(20776003)(80022001)(79102001)(76482001)(74316001)(31966008)(4396001)(99396002)(80976001)(19580395003)(81542001)(19580405001)(87936001)(74662001)(2656002)(85852003)(92566001)(46102001)(76576001)(83072002)(86362001)(77982001)(54356999)(50986999)(76176999)(77096999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB612; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:EAFCF0DE.9C72955E.7CF13DBB.82A9D1C0.20513; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gDVrFdHoYvR4p_LCc8L9wKbgIyE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:40:02 -0000 Carlos, Lots of thanks for a prompt and detailed response. I fully agree with you that "it can be done" does not mean "it should be do= ne". What I have been trying to say is that, at least in this case we are = not dealing with the situation like "thou shalt not..." and not even with "= these things are simply not done".=20 Any advantages and disadvantages are "in the eye of the beholder" (at least= until the document goes to the IESG:-). And would be much easier for me to= accept your position if you could expect why you object to requesting a ne= w IANA registry. So far the main argument I see is that you (and presumably= the other authors) do not expect many updates to the list of common interv= als. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Thursday, April 10, 2014 1:05 PM > To: Alexander Vainshtein > Cc: Donald Eastlake; Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: Re: draft-ietf-bfd-intervals IANA considerations? >=20 > Hi, Sasha, >=20 > Thanks for the follow-up, please see inline. >=20 > On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein > wrote: >=20 > > Carlos and all, > > I am not sure I follow the logic of the decision. >=20 > I do not think there's a decision yet, only a discussion. >=20 > > Donald has already commented on setting a new registry in an > Informational document; and saying that new values would be always set vi= a > a new draft seems to map well to one of the already existing IANA policie= s. > > >=20 > It is clearly possible (and many times desirable) to create or update IAN= A > registries with Informational documents. I've done so myself as well. But= "it > can be done" does not imply "it should be done". >=20 > > But what worries me most is the fact that without a IANA registry there= will > be no single place where these "common interval values" could be looked u= p > by implementers. Instead, they would have to track a (potentially long) > sequence of documents in order to understand what they should try to > implement and test. >=20 > My perspective is that a set of suggested (or recommended) interval/timer > values, or default timer values, is not what a numbers registry is used f= or. > Many protocols recommend timer values (TCP, L2TP, etc), but I do not > believe those are managed by IANA. Tracking a linked-list of Updated RFCs= is > not always fun, but in this case I would not expect a long list documents= . It > also seems to me that when implementing or checking compliance against an > RFC, the first place to check is the RFC itself and not an IANA registry. >=20 > > > > I could also say that operators commonly request "compliance" with > Informational documents in RFPs and RFIs they publish. (Somebody has > recently mentioned requests to comply with some April 1 RFCs as well on > the RTG-DIR :-).And while such an argument would not hold in the court of > law, I am not sure we should simply ignore it. > > >=20 > That's fine but orthogonal to this discussion. >=20 > Thanks, >=20 > Carlos. >=20 > > My 2c, > > Sasha > > > > > > > > ________________________________________ > > From: Rtg-bfd on behalf of Carlos Pignataro > > (cpignata) > > Sent: Tuesday, April 8, 2014 6:11 AM > > To: Donald Eastlake; Nobo Akiya (nobo) > > Cc: rtg-bfd@ietf.org > > Subject: Re: draft-ietf-bfd-intervals IANA considerations? > > > > Donald, > > > > I agree with this as a general statement. As it pertains to the > > =B3Common interval values=B2, it does not appear that is the role of an > > IANA numbers registry. > > > > Thanks, > > > > Carlos. > > > > -----Original Message----- > > From: Donald Eastlake > > Date: Monday, April 7, 2014 at 11:05 PM > > To: Nobo Akiya > > Cc: "rtg-bfd@ietf.org" > > Subject: Re: draft-ietf-bfd-intervals IANA considerations? > > > >> There is no problem with having IANA Considerations setting up a > >> registry or the like in an Informational document. > >> > >> Thanks, > >> Donald > >> =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 > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > >> > >> > >> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) > wrote: > >>> Hi BFDers, > >>> > >>> Authors of draft-ietf-bfd-intervals have discussed and concluded > >>> that defined "common intervals set" does _not_ need to be maintained > by IANA. > >>> > >>> Reasons: > >>> 1. Document is an informational draft. > >>> 2. Additions of interval(s) in the "common intervals set" should > >>> anyways be done through a new draft, whether or not > >>> draft-ietf-bfd-intervals creates an IANA registry and defines > >>> allocation policies for it. > >>> > >>> Do you agree with this? > >>> Do you see any concern with this? > >>> > >>> Seeking opinions/comments from folks on this matter. > >>> > >>> Thanks, > >>> Nobo, Marc, Greg > >>> > >> > > From nobody Thu Apr 10 04:44:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7C1A01CB for ; Thu, 10 Apr 2014 04:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHdyEllov_6f for ; Thu, 10 Apr 2014 04:44:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 296E41A01C3 for ; Thu, 10 Apr 2014 04:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6155; q=dns/txt; s=iport; t=1397130246; x=1398339846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BiTJEeMbTCQzE5vdHXYTAkCB/dq8Dny2bBti16S4oJg=; b=JtdS9E5Dub97H0mWDB0suJAvrmuLzqSQ0wfcvbrHaxAI46eY6xBHH4LF Ah3XaUtFXXbHRrYBFSDKW8hX2KV5nntn2oDJQn9RN6UecLIEHWyat0prT iK1FSa3VD6egqfRj/SwWfX3+Et6CXn/U7AkXlwRy/9+UiG2C9OpypWdRL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAJ+DRlOtJV2c/2dsb2JhbABXA4MGxTqBIxZ0giUBAQEDAXkFBwQCAQgRAwEBAQEnByERFAkIAgQOBYdoAwkIxWMNhwkXjFOBNxEBHQgbEAcGC4MTgRQEiSOLToF/gW6Mc4VPgzCBcg X-IronPort-AV: E=Sophos;i="4.97,834,1389744000"; d="scan'208";a="34614841" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 10 Apr 2014 11:43:50 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3ABho5S001900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Apr 2014 11:43:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 06:43:50 -0500 From: "Carlos Pignataro (cpignata)" To: Alexander Vainshtein Subject: Re: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAfyXWA//++xgCAAFv5gIADfy2AgAAJzgD//74LKQ== Date: Thu, 10 Apr 2014 11:43:50 +0000 Message-ID: <4F50F612-EE42-4235-85A5-4F95029EB16F@cisco.com> References: , <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> , <4581a1d2d3b44a04b6317efb2f7bb090@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <4581a1d2d3b44a04b6317efb2f7bb090@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ygikoLKPVrGlf0KxU_7DMkxOLaM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:44:11 -0000 Sasha, Sorry if I wasn't clear. Like I said, I do not think that a small set of in= terval values qualifies as something useful to be recorded in an IANA regis= try. I do not "object", I just see it as unnecessary overhead, something that do= es not add value. These is not a namespace of diag codes or auth types. I s= ee no harm (other than busywork) hence not "objecting".=20 Do you know of a similar IANA registry? The cases I can think of of suggest= ed protocol timers/periods are *not* managed by IANA.=20 Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein" wrote: >=20 > Carlos, > Lots of thanks for a prompt and detailed response. >=20 > I fully agree with you that "it can be done" does not mean "it should be = done". What I have been trying to say is that, at least in this case we ar= e not dealing with the situation like "thou shalt not..." and not even with= "these things are simply not done".=20 > Any advantages and disadvantages are "in the eye of the beholder" (at lea= st until the document goes to the IESG:-). And would be much easier for me = to accept your position if you could expect why you object to requesting a = new IANA registry. So far the main argument I see is that you (and presumab= ly the other authors) do not expect many updates to the list of common inte= rvals. >=20 > Regards, > Sasha=20 > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: Thursday, April 10, 2014 1:05 PM >> To: Alexander Vainshtein >> Cc: Donald Eastlake; Nobo Akiya (nobo); rtg-bfd@ietf.org >> Subject: Re: draft-ietf-bfd-intervals IANA considerations? >>=20 >> Hi, Sasha, >>=20 >> Thanks for the follow-up, please see inline. >>=20 >> On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein >> wrote: >>=20 >>> Carlos and all, >>> I am not sure I follow the logic of the decision. >>=20 >> I do not think there's a decision yet, only a discussion. >>=20 >>> Donald has already commented on setting a new registry in an >> Informational document; and saying that new values would be always set v= ia >> a new draft seems to map well to one of the already existing IANA polici= es. >>=20 >> It is clearly possible (and many times desirable) to create or update IA= NA >> registries with Informational documents. I've done so myself as well. Bu= t "it >> can be done" does not imply "it should be done". >>=20 >>> But what worries me most is the fact that without a IANA registry there= will >> be no single place where these "common interval values" could be looked = up >> by implementers. Instead, they would have to track a (potentially long) >> sequence of documents in order to understand what they should try to >> implement and test. >>=20 >> My perspective is that a set of suggested (or recommended) interval/time= r >> values, or default timer values, is not what a numbers registry is used = for. >> Many protocols recommend timer values (TCP, L2TP, etc), but I do not >> believe those are managed by IANA. Tracking a linked-list of Updated RFC= s is >> not always fun, but in this case I would not expect a long list document= s. It >> also seems to me that when implementing or checking compliance against a= n >> RFC, the first place to check is the RFC itself and not an IANA registry= . >>=20 >>>=20 >>> I could also say that operators commonly request "compliance" with >> Informational documents in RFPs and RFIs they publish. (Somebody has >> recently mentioned requests to comply with some April 1 RFCs as well on >> the RTG-DIR :-).And while such an argument would not hold in the court o= f >> law, I am not sure we should simply ignore it. >>=20 >> That's fine but orthogonal to this discussion. >>=20 >> Thanks, >>=20 >> Carlos. >>=20 >>> My 2c, >>> Sasha >>>=20 >>>=20 >>>=20 >>> ________________________________________ >>> From: Rtg-bfd on behalf of Carlos Pignataro >>> (cpignata) >>> Sent: Tuesday, April 8, 2014 6:11 AM >>> To: Donald Eastlake; Nobo Akiya (nobo) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: draft-ietf-bfd-intervals IANA considerations? >>>=20 >>> Donald, >>>=20 >>> I agree with this as a general statement. As it pertains to the >>> =B3Common interval values=B2, it does not appear that is the role of an >>> IANA numbers registry. >>>=20 >>> Thanks, >>>=20 >>> Carlos. >>>=20 >>> -----Original Message----- >>> From: Donald Eastlake >>> Date: Monday, April 7, 2014 at 11:05 PM >>> To: Nobo Akiya >>> Cc: "rtg-bfd@ietf.org" >>> Subject: Re: draft-ietf-bfd-intervals IANA considerations? >>>=20 >>>> There is no problem with having IANA Considerations setting up a >>>> registry or the like in an Informational document. >>>>=20 >>>> Thanks, >>>> Donald >>>> =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 >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>>>=20 >>>>=20 >>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) >> wrote: >>>>> Hi BFDers, >>>>>=20 >>>>> Authors of draft-ietf-bfd-intervals have discussed and concluded >>>>> that defined "common intervals set" does _not_ need to be maintained >> by IANA. >>>>>=20 >>>>> Reasons: >>>>> 1. Document is an informational draft. >>>>> 2. Additions of interval(s) in the "common intervals set" should >>>>> anyways be done through a new draft, whether or not >>>>> draft-ietf-bfd-intervals creates an IANA registry and defines >>>>> allocation policies for it. >>>>>=20 >>>>> Do you agree with this? >>>>> Do you see any concern with this? >>>>>=20 >>>>> Seeking opinions/comments from folks on this matter. >>>>>=20 >>>>> Thanks, >>>>> Nobo, Marc, Greg >=20 From nobody Thu Apr 10 04:51:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E602C1A0212 for ; Thu, 10 Apr 2014 04:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkLfKGecHS9W for ; Thu, 10 Apr 2014 04:51:19 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) by ietfa.amsl.com (Postfix) with ESMTP id BBC191A0239 for ; Thu, 10 Apr 2014 04:51:18 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 10 Apr 2014 11:51:15 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0918.000; Thu, 10 Apr 2014 11:51:15 +0000 From: Alexander Vainshtein To: "Carlos Pignataro (cpignata)" Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAVTz+AAAA6kAAAAshEGwBwOlgAAABG9mAAAy7DAAAAF58Q Date: Thu, 10 Apr 2014 11:51:15 +0000 Message-ID: References: , <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> , <4581a1d2d3b44a04b6317efb2f7bb090@AM3PR03MB612.eurprd03.prod.outlook.com> <4F50F612-EE42-4235-85A5-4F95029EB16F@cisco.com> In-Reply-To: <4F50F612-EE42-4235-85A5-4F95029EB16F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(30594002)(377454003)(252514010)(164054003)(24454002)(13464003)(51914003)(51704005)(76576001)(4396001)(74316001)(80976001)(77982001)(19580395003)(31966008)(33646001)(99396002)(74502001)(76482001)(81342001)(19300405004)(74662001)(81542001)(16236675002)(86362001)(46102001)(15975445006)(15202345003)(20776003)(19580405001)(83072002)(87936001)(85852003)(83322001)(66066001)(92566001)(79102001)(2656002)(80022001)(54356999)(50986999)(76176999)(77096999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:EAFCF1D6.987A995D.7CF13D8B.82A9D1C0.205EC; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_edde4293302d4b239692deb6810caab4AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Xpd4BPVj7isH7xndr95KHvYWbwU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:51:24 -0000 --_000_edde4293302d4b239692deb6810caab4AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Carlos, The example that comes to my mind (and it is quite personal, you may say th= at it is not a relevant example for your case) is IPv4 Addresses Space. It is not about timers and (in many cases) not even refers to any RFCs (all= records that say =93Administered by ARIN/APNIC/AFRINIC etc.=94), but it is= clearly most useful. And much more difficult for IANA to maintain I think:= ). My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Thursday, April 10, 2014 2:44 PM > To: Alexander Vainshtein > Cc: Donald Eastlake; Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: Re: draft-ietf-bfd-intervals IANA considerations? > > Sasha, > > Sorry if I wasn't clear. Like I said, I do not think that a small set of = interval > values qualifies as something useful to be recorded in an IANA registry. > > I do not "object", I just see it as unnecessary overhead, something that = does > not add value. These is not a namespace of diag codes or auth types. I se= e no > harm (other than busywork) hence not "objecting". > > Do you know of a similar IANA registry? The cases I can think of of sugge= sted > protocol timers/periods are *not* managed by IANA. > > Thanks, > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > > On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein" > > wrote: > > > > Carlos, > > Lots of thanks for a prompt and detailed response. > > > > I fully agree with you that "it can be done" does not mean "it should b= e > done". What I have been trying to say is that, at least in this case we = are not > dealing with the situation like "thou shalt not..." and not even with "th= ese > things are simply not done". > > Any advantages and disadvantages are "in the eye of the beholder" (at > least until the document goes to the IESG:-). And would be much easier fo= r > me to accept your position if you could expect why you object to requesti= ng > a new IANA registry. So far the main argument I see is that you (and > presumably the other authors) do not expect many updates to the list of > common intervals. > > > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > >> -----Original Message----- > >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > >> Sent: Thursday, April 10, 2014 1:05 PM > >> To: Alexander Vainshtein > >> Cc: Donald Eastlake; Nobo Akiya (nobo); rtg-bfd@ietf.org > >> Subject: Re: draft-ietf-bfd-intervals IANA considerations? > >> > >> Hi, Sasha, > >> > >> Thanks for the follow-up, please see inline. > >> > >> On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein > >> > wrote: > >> > >>> Carlos and all, > >>> I am not sure I follow the logic of the decision. > >> > >> I do not think there's a decision yet, only a discussion. > >> > >>> Donald has already commented on setting a new registry in an > >> Informational document; and saying that new values would be always > >> set via a new draft seems to map well to one of the already existing I= ANA > policies. > >> > >> It is clearly possible (and many times desirable) to create or update > >> IANA registries with Informational documents. I've done so myself as > >> well. But "it can be done" does not imply "it should be done". > >> > >>> But what worries me most is the fact that without a IANA registry > >>> there will > >> be no single place where these "common interval values" could be > >> looked up by implementers. Instead, they would have to track a > >> (potentially long) sequence of documents in order to understand what > >> they should try to implement and test. > >> > >> My perspective is that a set of suggested (or recommended) > >> interval/timer values, or default timer values, is not what a numbers > registry is used for. > >> Many protocols recommend timer values (TCP, L2TP, etc), but I do not > >> believe those are managed by IANA. Tracking a linked-list of Updated > >> RFCs is not always fun, but in this case I would not expect a long > >> list documents. It also seems to me that when implementing or > >> checking compliance against an RFC, the first place to check is the RF= C > itself and not an IANA registry. > >> > >>> > >>> I could also say that operators commonly request "compliance" with > >> Informational documents in RFPs and RFIs they publish. (Somebody has > >> recently mentioned requests to comply with some April 1 RFCs as well > >> on the RTG-DIR :-).And while such an argument would not hold in the > >> court of law, I am not sure we should simply ignore it. > >> > >> That's fine but orthogonal to this discussion. > >> > >> Thanks, > >> > >> Carlos. > >> > >>> My 2c, > >>> Sasha > >>> > >>> > >>> > >>> ________________________________________ > >>> From: Rtg-bfd > on behalf of Carlos > >>> Pignataro > >>> (cpignata) > > >>> Sent: Tuesday, April 8, 2014 6:11 AM > >>> To: Donald Eastlake; Nobo Akiya (nobo) > >>> Cc: rtg-bfd@ietf.org > >>> Subject: Re: draft-ietf-bfd-intervals IANA considerations? > >>> > >>> Donald, > >>> > >>> I agree with this as a general statement. As it pertains to the > >>> =B3Common interval values=B2, it does not appear that is the role of = an > >>> IANA numbers registry. > >>> > >>> Thanks, > >>> > >>> Carlos. > >>> > >>> -----Original Message----- > >>> From: Donald Eastlake > > >>> Date: Monday, April 7, 2014 at 11:05 PM > >>> To: Nobo Akiya > > >>> Cc: "rtg-bfd@ietf.org" > > >>> Subject: Re: draft-ietf-bfd-intervals IANA considerations? > >>> > >>>> There is no problem with having IANA Considerations setting up a > >>>> registry or the like in an Informational document. > >>>> > >>>> Thanks, > >>>> Donald > >>>> =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 > >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >>>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > >>>> > >>>> > >>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) > > > >> wrote: > >>>>> Hi BFDers, > >>>>> > >>>>> Authors of draft-ietf-bfd-intervals have discussed and concluded > >>>>> that defined "common intervals set" does _not_ need to be > >>>>> maintained > >> by IANA. > >>>>> > >>>>> Reasons: > >>>>> 1. Document is an informational draft. > >>>>> 2. Additions of interval(s) in the "common intervals set" should > >>>>> anyways be done through a new draft, whether or not > >>>>> draft-ietf-bfd-intervals creates an IANA registry and defines > >>>>> allocation policies for it. > >>>>> > >>>>> Do you agree with this? > >>>>> Do you see any concern with this? > >>>>> > >>>>> Seeking opinions/comments from folks on this matter. > >>>>> > >>>>> Thanks, > >>>>> Nobo, Marc, Greg > > --_000_edde4293302d4b239692deb6810caab4AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Carlos,

The example that comes to my mind (and it is quit= e personal, you may say that it is not a relevant example for your case) is IPv4 Addresses Space.

 

It is not about timers and (in many cases) not ev= en refers to any RFCs (all records that say =93Administered by ARIN/APNIC/A= FRINIC etc.=94), but it is clearly most useful. And much more difficult for= IANA to maintain I thinkJ.

 

My 2c,

       Sasha <= /o:p>

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

 

> -----Original Message-----

> From: Carlos Pignataro (cpignata) [mailto:cp= ignata@cisco.com]

> Sent: Thursday, April 10, 2014 2:44 PM

> To: Alexander Vainshtein

> Cc: Donald Eastlake; Nobo Akiya (nobo); rtg-= bfd@ietf.org

> Subject: Re: draft-ietf-bfd-intervals IANA c= onsiderations?

>

> Sasha,

>

> Sorry if I wasn't clear. Like I said, I do n= ot think that a small set of interval

> values qualifies as something useful to be r= ecorded in an IANA registry.

>

> I do not "object", I just see it a= s unnecessary overhead, something that does

> not add value. These is not a namespace of d= iag codes or auth types. I see no

> harm (other than busywork) hence not "o= bjecting".

>

> Do you know of a similar IANA registry? The = cases I can think of of suggested

> protocol timers/periods are *not* managed by= IANA.

>

> Thanks,

>

> Thumb typed by Carlos Pignataro.

> Excuze typofraphicak errows

>

> > On Apr 10, 2014, at 6:40 AM, "Alex= ander Vainshtein"

> <Alexander= .Vainshtein@ecitele.com> wrote:

> >

> > Carlos,

> > Lots of thanks for a prompt and detaile= d response.

> >

> > I fully agree with you that "it ca= n be done" does not mean "it should be

> done".  What I have been trying to= say is that, at least in this case we are not

> dealing with the situation like "thou s= halt not..." and not even with "these

> things are simply not done".

> > Any advantages and disadvantages are &q= uot;in the eye of the beholder" (at

> least until the document goes to the IESG:-)= . And would be much easier for

> me to accept your position if you could expe= ct why you object to requesting

> a new IANA registry. So far the main argumen= t I see is that you (and

> presumably the other authors) do not expect = many updates to the list of

> common intervals.

> >

> > Regards,

> >       Sas= ha

> > Email: Alexander.Vainshtein@= ecitele.com

> > Mobile: 054-9266302

> >

> >> -----Original Message-----

> >> From: Carlos Pignataro (cpignata) [= mailto:cpignata@cisco.com]

> >> Sent: Thursday, April 10, 2014 1:05= PM

> >> To: Alexander Vainshtein

> >> Cc: Donald Eastlake; Nobo Akiya (no= bo); rtg-bfd@ietf.org

> >> Subject: Re: draft-ietf-bfd-interva= ls IANA considerations?

> >>

> >> Hi, Sasha,

> >>

> >> Thanks for the follow-up, please se= e inline.

> >>

> >> On Apr 8, 2014, at 12:40 AM, Alexan= der Vainshtein

> >> <= Alexander.Vainshtein@ecitele.com> wrote:

> >>

> >>> Carlos and all,

> >>> I am not sure I follow the logi= c of the decision.

> >>

> >> I do not think there's a decision y= et, only a discussion.

> >>

> >>> Donald has already commented on= setting a new registry in an

> >> Informational document; and saying = that new values would be always

> >> set via a new draft seems to map we= ll to one of the already existing IANA

> policies.

> >>

> >> It is clearly possible (and many ti= mes desirable) to create or update

> >> IANA registries with Informational = documents. I've done so myself as

> >> well. But "it can be done"= ; does not imply "it should be done".

> >>

> >>> But what worries me most is the= fact that without a IANA registry

> >>> there will

> >> be no single place where these &quo= t;common interval values" could be

> >> looked up by implementers. Instead,= they would have to track a

> >> (potentially long) sequence of docu= ments in order to understand what

> >> they should try to implement and te= st.

> >>

> >> My perspective is that a set of sug= gested (or recommended)

> >> interval/timer values, or default t= imer values, is not what a numbers

> registry is used for.

> >> Many protocols recommend timer valu= es (TCP, L2TP, etc), but I do not

> >> believe those are managed by IANA. = Tracking a linked-list of Updated

> >> RFCs is not always fun, but in this= case I would not expect a long

> >> list documents. It also seems to me= that when implementing or

> >> checking compliance against an RFC,= the first place to check is the RFC

> itself and not an IANA registry.

> >>

> >>>

> >>> I could also say that operators= commonly request "compliance" with

> >> Informational documents in RFPs and= RFIs they publish. (Somebody has

> >> recently mentioned requests to comp= ly with some April 1  RFCs as well

> >> on the RTG-DIR :-).And while such a= n argument would not hold in the

> >> court of law, I am not sure we shou= ld simply ignore it.

> >>

> >> That's fine but orthogonal to this = discussion.

> >>

> >> Thanks,

> >>

> >> Carlos.

> >>

> >>> My 2c,

> >>>    Sasha

> >>>

> >>>

> >>>

> >>> _______________________________= _________

> >>> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Carlos

> >>> Pignataro

> >>> (cpignata) <cpignata@cisco.com>

> >>> Sent: Tuesday, April 8, 2014 6:= 11 AM

> >>> To: Donald Eastlake; Nobo Akiya= (nobo)

> >>> Cc: rtg-bfd@ietf= .org

> >>> Subject: Re: draft-ietf-bfd-int= ervals IANA considerations?

> >>>

> >>> Donald,

> >>>

> >>> I agree with this as a general = statement. As it pertains to the

> >>> =B3Common interval values=B2, i= t does not appear that is the role of an

> >>> IANA numbers registry.

> >>>

> >>> Thanks,

> >>>

> >>> Carlos.

> >>>

> >>> -----Original Message-----

> >>> From: Donald Eastlake <d3e3e3@gmail.com>

> >>> Date: Monday, April 7, 2014 at = 11:05 PM

> >>> To: Nobo Akiya <nobo@cisco.com>

> >>> Cc: "rtg-bf= d@ietf.org" <rtg-bfd@ietf.org&= gt;

> >>> Subject: Re: draft-ietf-bfd-int= ervals IANA considerations?

> >>>

> >>>> There is no problem with ha= ving IANA Considerations setting up a

> >>>> registry or the like in an = Informational document.

> >>>>

> >>>> Thanks,

> >>>> Donald

> >>>> =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

> >>>> Donald E. Eastlake 3rd = ;  +1-508-333-2270 (cell)

> >>>> 155 Beaver Street, Milford,= MA 01757 USA d3e3e3@gmail.com

> >>>>

> >>>>

> >>>> On Mon, Apr 7, 2014 at 1:07= PM, Nobo Akiya (nobo)

> <nobo@cisco.com&g= t;

> >> wrote:

> >>>>> Hi BFDers,

> >>>>>

> >>>>> Authors of draft-ietf-b= fd-intervals have discussed and concluded

> >>>>> that defined "comm= on intervals set" does _not_ need to be

> >>>>> maintained

> >> by IANA.

> >>>>>

> >>>>> Reasons:

> >>>>> 1. Document is an infor= mational draft.

> >>>>> 2. Additions of interva= l(s) in the "common intervals set" should

> >>>>> anyways be done through= a new draft, whether or not

> >>>>> draft-ietf-bfd-interval= s creates an IANA registry and defines

> >>>>> allocation policies for= it.

> >>>>>

> >>>>> Do you agree with this?=

> >>>>> Do you see any concern = with this?

> >>>>>

> >>>>> Seeking opinions/commen= ts from folks on this matter.

> >>>>>

> >>>>> Thanks,

> >>>>> Nobo, Marc, Greg

> >

--_000_edde4293302d4b239692deb6810caab4AM3PR03MB612eurprd03pro_-- From nobody Thu Apr 10 08:30:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF22B1A020D for ; Thu, 10 Apr 2014 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNN2O3f96yuT for ; Thu, 10 Apr 2014 08:30:33 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 674F91A0073 for ; Thu, 10 Apr 2014 08:30:33 -0700 (PDT) X-AuditID: c618062d-b7f948e000000b0c-ce-5346b6c5c5d7 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 87.8B.02828.5C6B6435; Thu, 10 Apr 2014 17:20:37 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 10 Apr 2014 11:30:32 -0400 From: Gregory Mirsky To: "Carlos Pignataro (cpignata)" , Alexander Vainshtein Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: Ac9SghtQsLTMhLuZTf6VtD0SKBbG+gAfyXWA//++xgCAAFv5gIADfy2A///5CgCAABHdAIAABcIA Date: Thu, 10 Apr 2014 15:30:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B79F7AF@eusaamb103.ericsson.se> References: , <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> , <4581a1d2d3b44a04b6317efb2f7bb090@AM3PR03MB612.eurprd03.prod.outlook.com> <4F50F612-EE42-4235-85A5-4F95029EB16F@cisco.com> In-Reply-To: <4F50F612-EE42-4235-85A5-4F95029EB16F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B79F7AFeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPiO7RbW7BBgf3yVlM3fqB2eLTux0s Fp//bGN0YPaY8nsjq8emf8cZPZYs+ckUwBzFZZOSmpNZllqkb5fAlbHqVw9zweKpjBXPZs9l b2BcX9fFyMkhIWAicbJzIwuELSZx4d56ti5GLg4hgaOMEnMutbCBJIQEljNKNH0qBrHZBIwk XmzsYe9i5OAQESiUmDTZBCTMLKAp0XTiM1hYWMBKYvG0fJCwiIC1xOUHUxkh7CiJyx+2gk1k EVCVmH7+J5jNK+Ar8fP1YlaItTuZJTZN/8cOkuAUsJVo33AGrJkR6Lbvp9YwQewSl7j1ZD4T xM0CEkv2nGeGsEUlXj7+xwphK0rs65/ODlGfL/HnwDYWiGWCEidnPmGZwCg6C8moWUjKZiEp g4jrSdyYOoUNwtaWWLbwNTOErSsx498hFmTxBYzsqxg5SotTy3LTjQw2MQIj7ZgEm+4Oxj0v LQ8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsX3Hlisf1pjwWeVsee4m ojSlkOVf9YQqjr2spxYbFcdduip4wH9X67zU6FPpMwTmmb9Y0Ky3/fCJNXZ6yaY2m4yvvBI5 vyJY+HH5SSnBrJO5qk+7lfmfn3x08Iew1bUFb6X3scV+z23KkX37bXV9874vD2RqJHUUL8wN k7/Ac6pT28K8IDxKXImlOCPRUIu5qDgRADU9JIKCAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/foxQNC3oYDcEYWqcj9XIX-XUjJE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 15:30:38 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B79F7AFeusaamb103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sasha, Carlos, et. al, I share Carlos' point of view in regard to creating a new registry for reco= mmended set of BFD intervals. I think that precisely because these values b= een recommended and none is mandatory creating a registry, IMO, is not nece= ssary. And I'm concerned that if there's such registry then interpretation = of the set might change from 'recommended' to 'mandatory'. And that might b= e reflected in RFPs we'll have to deal with. I for one would not want that = to happen. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos Pignata= ro (cpignata) Sent: Thursday, April 10, 2014 4:44 AM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: Re: draft-ietf-bfd-intervals IANA considerations? Sasha, Sorry if I wasn't clear. Like I said, I do not think that a small set of in= terval values qualifies as something useful to be recorded in an IANA regis= try. I do not "object", I just see it as unnecessary overhead, something that do= es not add value. These is not a namespace of diag codes or auth types. I s= ee no harm (other than busywork) hence not "objecting". Do you know of a similar IANA registry? The cases I can think of of suggest= ed protocol timers/periods are *not* managed by IANA. Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein" > wrote: > > Carlos, > Lots of thanks for a prompt and detailed response. > > I fully agree with you that "it can be done" does not mean "it should be = done". What I have been trying to say is that, at least in this case we ar= e not dealing with the situation like "thou shalt not..." and not even with= "these things are simply not done". > Any advantages and disadvantages are "in the eye of the beholder" (at lea= st until the document goes to the IESG:-). And would be much easier for me = to accept your position if you could expect why you object to requesting a = new IANA registry. So far the main argument I see is that you (and presumab= ly the other authors) do not expect many updates to the list of common inte= rvals. > > Regards, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 > >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: Thursday, April 10, 2014 1:05 PM >> To: Alexander Vainshtein >> Cc: Donald Eastlake; Nobo Akiya (nobo); rtg-bfd@ietf.org >> Subject: Re: draft-ietf-bfd-intervals IANA considerations? >> >> Hi, Sasha, >> >> Thanks for the follow-up, please see inline. >> >> On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein >> > wrote: >> >>> Carlos and all, >>> I am not sure I follow the logic of the decision. >> >> I do not think there's a decision yet, only a discussion. >> >>> Donald has already commented on setting a new registry in an >> Informational document; and saying that new values would be always >> set via a new draft seems to map well to one of the already existing IAN= A policies. >> >> It is clearly possible (and many times desirable) to create or update >> IANA registries with Informational documents. I've done so myself as >> well. But "it can be done" does not imply "it should be done". >> >>> But what worries me most is the fact that without a IANA registry >>> there will >> be no single place where these "common interval values" could be >> looked up by implementers. Instead, they would have to track a >> (potentially long) sequence of documents in order to understand what >> they should try to implement and test. >> >> My perspective is that a set of suggested (or recommended) >> interval/timer values, or default timer values, is not what a numbers re= gistry is used for. >> Many protocols recommend timer values (TCP, L2TP, etc), but I do not >> believe those are managed by IANA. Tracking a linked-list of Updated >> RFCs is not always fun, but in this case I would not expect a long >> list documents. It also seems to me that when implementing or >> checking compliance against an RFC, the first place to check is the RFC = itself and not an IANA registry. >> >>> >>> I could also say that operators commonly request "compliance" with >> Informational documents in RFPs and RFIs they publish. (Somebody has >> recently mentioned requests to comply with some April 1 RFCs as well >> on the RTG-DIR :-).And while such an argument would not hold in the >> court of law, I am not sure we should simply ignore it. >> >> That's fine but orthogonal to this discussion. >> >> Thanks, >> >> Carlos. >> >>> My 2c, >>> Sasha >>> >>> >>> >>> ________________________________________ >>> From: Rtg-bfd > on behalf of Carlos >>> Pignataro >>> (cpignata) > >>> Sent: Tuesday, April 8, 2014 6:11 AM >>> To: Donald Eastlake; Nobo Akiya (nobo) >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: draft-ietf-bfd-intervals IANA considerations? >>> >>> Donald, >>> >>> I agree with this as a general statement. As it pertains to the >>> =B3Common interval values=B2, it does not appear that is the role of an >>> IANA numbers registry. >>> >>> Thanks, >>> >>> Carlos. >>> >>> -----Original Message----- >>> From: Donald Eastlake > >>> Date: Monday, April 7, 2014 at 11:05 PM >>> To: Nobo Akiya > >>> Cc: "rtg-bfd@ietf.org" > >>> Subject: Re: draft-ietf-bfd-intervals IANA considerations? >>> >>>> There is no problem with having IANA Considerations setting up a >>>> registry or the like in an Informational document. >>>> >>>> Thanks, >>>> Donald >>>> =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 >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>>> >>>> >>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) > >> wrote: >>>>> Hi BFDers, >>>>> >>>>> Authors of draft-ietf-bfd-intervals have discussed and concluded >>>>> that defined "common intervals set" does _not_ need to be >>>>> maintained >> by IANA. >>>>> >>>>> Reasons: >>>>> 1. Document is an informational draft. >>>>> 2. Additions of interval(s) in the "common intervals set" should >>>>> anyways be done through a new draft, whether or not >>>>> draft-ietf-bfd-intervals creates an IANA registry and defines >>>>> allocation policies for it. >>>>> >>>>> Do you agree with this? >>>>> Do you see any concern with this? >>>>> >>>>> Seeking opinions/comments from folks on this matter. >>>>> >>>>> Thanks, >>>>> Nobo, Marc, Greg > --_000_7347100B5761DC41A166AC17F22DF1121B79F7AFeusaamb103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sasha, Carlos, et. al,
I share Carlos' point of view in regard to creating a new registry for= recommended set of BFD intervals. I think that precisely bec= ause these values been recommended and none is mandatory creating a registr= y, IMO, is not necessary. And I'm concerned that if there's such registry then interpretation of the set migh= t change from 'recommended' to 'mandatory'. And that might be reflected in = RFPs we'll have to deal with. I for one would not want that to happen.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Thursday, April 10, 2014 4:44 AM
To: Alexander Vainshtein
Cc: rtg-bfd@ietf.org
Subject: Re: draft-ietf-bfd-intervals IANA considerations?
 
Sasha,
 
Sorry if I wasn't clear. Like I said, I do not think that a small set = of interval values qualifies as something useful to be recorded in an IANA = registry.
 
I do not "object", I just see it as unnecessary overhead, so= mething that does not add value. These is not a namespace of diag codes or = auth types. I see no harm (other than busywork) hence not "objecting&q= uot;.
 
Do you know of a similar IANA registry? The cases I can think of of su= ggested protocol timers/periods are *not* managed by IANA.
 
Thanks,
 
Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows
 
> On Apr 10, 2014, at 6:40 AM, "Alexander Vainshtein" <= ;Alexander.Vainshtein@e= citele.com> wrote:
>
> Carlos,
> Lots of thanks for a prompt and detailed response.
>
> I fully agree with you that "it can be done" does not m= ean "it should be done".  What I have been trying to say is = that, at least in this case we are not dealing with the situation like &quo= t;thou shalt not..." and not even with "these things are simply n= ot done".
> Any advantages and disadvantages are "in the eye of the beho= lder" (at least until the document goes to the IESG:-). And would be m= uch easier for me to accept your position if you could expect why you objec= t to requesting a new IANA registry. So far the main argument I see is that you (and presumably the other authors) do not e= xpect many updates to the list of common intervals.
>
> Regards,
>       Sasha
> Mobile: 054-9266302
>
>> -----Original Message-----
>> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
>> Sent: Thursday, April 10, 2014 1:05 PM
>> To: Alexander Vainshtein
>> Cc: Donald Eastlake; Nobo Akiya (nobo); rtg-bfd@ietf.org
>> Subject: Re: draft-ietf-bfd-intervals IANA considerations?
>>
>> Hi, Sasha,
>>
>> Thanks for the follow-up, please see inline.
>>
>> On Apr 8, 2014, at 12:40 AM, Alexander Vainshtein
>>
>>> Carlos and all,
>>> I am not sure I follow the logic of the decision.
>>
>> I do not think there's a decision yet, only a discussion.
>>
>>> Donald has already commented on setting a new registry in= an
>> Informational document; and saying that new values would be a= lways
>> set via a new draft seems to map well to one of the already e= xisting IANA policies.
>>
>> It is clearly possible (and many times desirable) to create o= r update
>> IANA registries with Informational documents. I've done so my= self as
>> well. But "it can be done" does not imply "it = should be done".
>>
>>> But what worries me most is the fact that without a IANA = registry
>>> there will
>> be no single place where these "common interval values&q= uot; could be
>> looked up by implementers. Instead, they would have to track = a
>> (potentially long) sequence of documents in order to understa= nd what
>> they should try to implement and test.
>>
>> My perspective is that a set of suggested (or recommended)
>> interval/timer values, or default timer values, is not what a= numbers registry is used for.
>> Many protocols recommend timer values (TCP, L2TP, etc), but I= do not
>> believe those are managed by IANA. Tracking a linked-list of = Updated
>> RFCs is not always fun, but in this case I would not expect a= long
>> list documents. It also seems to me that when implementing or=
>> checking compliance against an RFC, the first place to check = is the RFC itself and not an IANA registry.
>>
>>>
>>> I could also say that operators commonly request "co= mpliance" with
>> Informational documents in RFPs and RFIs they publish. (Someb= ody has
>> recently mentioned requests to comply with some April 1 = RFCs as well
>> on the RTG-DIR :-).And while such an argument would not hold = in the
>> court of law, I am not sure we should simply ignore it.
>>
>> That's fine but orthogonal to this discussion.
>>
>> Thanks,
>>
>> Carlos.
>>
>>> My 2c,
>>>    Sasha
>>>
>>>
>>>
>>> ________________________________________
>>> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Carlos
>>> Pignataro
>>> (cpignata) <cpig= nata@cisco.com>
>>> Sent: Tuesday, April 8, 2014 6:11 AM
>>> To: Donald Eastlake; Nobo Akiya (nobo)
>>> Subject: Re: draft-ietf-bfd-intervals IANA considerations= ?
>>>
>>> Donald,
>>>
>>> I agree with this as a general statement. As it pertains = to the
>>> =B3Common interval values=B2, it does not appear that is = the role of an
>>> IANA numbers registry.
>>>
>>> Thanks,
>>>
>>> Carlos.
>>>
>>> -----Original Message-----
>>> Date: Monday, April 7, 2014 at 11:05 PM
>>> To: Nobo Akiya <nobo= @cisco.com>
>>> Subject: Re: draft-ietf-bfd-intervals IANA considerations= ?
>>>
>>>> There is no problem with having IANA Considerations s= etting up a
>>>> registry or the like in an Informational document.
>>>>
>>>> Thanks,
>>>> Donald
>>>> =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
>>>> Donald E. Eastlake 3rd   +1-508-333-227= 0 (cell)
>>>>
>>>>
>>>> On Mon, Apr 7, 2014 at 1:07 PM, Nobo Akiya (nobo) <= ;nobo@cisco.com>
>> wrote:
>>>>> Hi BFDers,
>>>>>
>>>>> Authors of draft-ietf-bfd-intervals have discusse= d and concluded
>>>>> that defined "common intervals set" doe= s _not_ need to be
>>>>> maintained
>> by IANA.
>>>>>
>>>>> Reasons:
>>>>> 1. Document is an informational draft.
>>>>> 2. Additions of interval(s) in the "common i= ntervals set" should
>>>>> anyways be done through a new draft, whether or n= ot
>>>>> draft-ietf-bfd-intervals creates an IANA registry= and defines
>>>>> allocation policies for it.
>>>>>
>>>>> Do you agree with this?
>>>>> Do you see any concern with this?
>>>>>
>>>>> Seeking opinions/comments from folks on this matt= er.
>>>>>
>>>>> Thanks,
>>>>> Nobo, Marc, Greg
>
 
 
 --_000_7347100B5761DC41A166AC17F22DF1121B79F7AFeusaamb103erics_-- From nobody Thu Apr 10 10:09:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8A1A01FF for ; Thu, 10 Apr 2014 10:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2H_D4O-cZcW for ; Thu, 10 Apr 2014 10:09:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22C1A01DD for ; Thu, 10 Apr 2014 10:09:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8D739C091; Thu, 10 Apr 2014 13:09:46 -0400 (EDT) Date: Thu, 10 Apr 2014 13:09:46 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: draft-ietf-bfd-intervals IANA considerations? Message-ID: <20140410170946.GB15065@pfrc> References: <406073cde28b4372af2a9364f3de14d2@AM3PR03MB612.eurprd03.prod.outlook.com> <4581a1d2d3b44a04b6317efb2f7bb090@AM3PR03MB612.eurprd03.prod.outlook.com> <4F50F612-EE42-4235-85A5-4F95029EB16F@cisco.com> <7347100B5761DC41A166AC17F22DF1121B79F7AF@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B79F7AF@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gcgjOiphId0UOm2mv8jEDY1SWhs Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 17:09:48 -0000 Greg, On Thu, Apr 10, 2014 at 03:30:31PM +0000, Gregory Mirsky wrote: > I share Carlos' point of view in regard to creating a new registry for > recommended set of BFD intervals. I think that precisely because these > values been recommended and none is mandatory creating a registry, IMO, is > not necessary. And I'm concerned that if there's such registry then > interpretation of the set might change from 'recommended' to 'mandatory'. > And that might be reflected in RFPs we'll have to deal with. I for one > would not want that to happen. Personally, I'm ambivalent to whether the registry is created or not. This is largely because the simple existence of even an Informational RFC will have some of the impact you're concerned about. Adding a registry to permit the consolidation of changes of future Informational RFCs and the traceability of why a given interval is recommended won't change whether the IETF considers such a thing normative or not. And one must admit the whole point of such a draft in the first place is to give users a way to say "this is a common value, do you support it?" -- Jeff From nobody Thu Apr 10 11:15:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8AF1A02EB for ; Thu, 10 Apr 2014 11:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs_Wk-PqglK7 for ; Thu, 10 Apr 2014 11:15:01 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id E305A1A02BC for ; Thu, 10 Apr 2014 11:15:00 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 10 Apr 2014 18:14:43 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0918.000; Thu, 10 Apr 2014 18:14:43 +0000 From: Alexander Vainshtein To: Gregory Mirsky , "Carlos Pignataro (cpignata)" Subject: Re: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: AQHPVOi+sLTMhLuZTf6VtD0SKBbG+g== Date: Thu, 10 Apr 2014 18:14:42 +0000 Message-ID: <95ebd013887b448cb85770bd60a46577@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.35.58.59] x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(30594002)(252514010)(51914003)(377454003)(479174003)(199002)(189002)(164054003)(51444003)(24454002)(13464003)(51704005)(81342001)(74502001)(16236675002)(83322001)(66066001)(31966008)(76482001)(33646001)(79102001)(80022001)(74316001)(20776003)(4396001)(99396002)(80976001)(19580395003)(19580405001)(81542001)(87936001)(2656002)(74662001)(85852003)(92566001)(46102001)(76576001)(83072002)(86362001)(77982001)(50986999)(54356999)(77096999)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB612; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:EADCF0F6.9A62915D.7CD13D8B.82A9D140.2063C; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (: ecitele.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_95ebd013887b448cb85770bd60a46577AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/F-soSY7k6jv1Pzv4upmAoMicGGA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 18:15:06 -0000 --_000_95ebd013887b448cb85770bd60a46577AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBHcmVnLA0KDQpJIHRoaW5rIHRoYXQgdGhlIHZhbHVlcyBsaXN0ZWQgaW4gdGhpcyBkcmFm dCB3aWxsIHVsdGltYXRlbHkgZmluZCB0aGVpciB3YXkgdG8gUkZQcyByZWdhcmRsZXNzIG9mIGNy ZWF0aW9uIChvciBub24tY3JlYXRpb24pIG9mIHRoZSByZWdpc3RyeS4NCg0KQW5kIHdoaWxlIHRo ZSBkcmFmdCBpcyBJbmZvcm1hdGlvbmFsLCBpdCBpcyBxdWl0ZSBjb252aW5jaW5nIGluIGV4cGxh aW5pbmcgdGhhdCBzdXBwb3J0IG9mIHRoaXMgc2V0IG9mIHZhbHVlcyBpcyBpbXBvcnRhbnQgZm9y IGFjaGlldmluZyBpbmVyb3BlcmFiaWxpdHkuLi4gV2hpY2ggbWFrZXMgaXQgcXVpdGUgcmVhc29u YWJsZSBmb3IgdGhlIG9wZXJhdG9ycyB0byByZXF1ZXN0IHRoYXQgdGhlc2UgdmFsdWVzIGFyZSBz dXBwb3J0ZWQuDQoNCk15IDJjLA0KDQpTYXNoYQ0KDQoNCg0KU2VudCBmcm9tIG15IExHIE1vYmls ZQ0KDQotLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0NCkZyb206IEdyZWdvcnkgTWlyc2t5 DQpEYXRlOiAxMC8wNC8yMDE0IDE4OjMwDQpUbzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp O0FsZXhhbmRlciBWYWluc2h0ZWluOw0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmc7DQpTdWJqZWN0OlJF OiBkcmFmdC1pZXRmLWJmZC1pbnRlcnZhbHMgSUFOQSBjb25zaWRlcmF0aW9ucz8NCg0KRGVhciBT YXNoYSwgQ2FybG9zLCBldC4gYWwsDQpJIHNoYXJlIENhcmxvcycgcG9pbnQgb2YgdmlldyBpbiBy ZWdhcmQgdG8gY3JlYXRpbmcgYSBuZXcgcmVnaXN0cnkgZm9yIHJlY29tbWVuZGVkIHNldCBvZiBC RkQgaW50ZXJ2YWxzLiBJIHRoaW5rIHRoYXQgcHJlY2lzZWx5IGJlY2F1c2UgdGhlc2UgdmFsdWVz IGJlZW4gcmVjb21tZW5kZWQgYW5kIG5vbmUgaXMgbWFuZGF0b3J5IGNyZWF0aW5nIGEgcmVnaXN0 cnksIElNTywgaXMgbm90IG5lY2Vzc2FyeS4gQW5kIEknbSBjb25jZXJuZWQgdGhhdCBpZiB0aGVy ZSdzIHN1Y2ggcmVnaXN0cnkgdGhlbiBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc2V0IG1pZ2h0IGNo YW5nZSBmcm9tICdyZWNvbW1lbmRlZCcgdG8gJ21hbmRhdG9yeScuIEFuZCB0aGF0IG1pZ2h0IGJl IHJlZmxlY3RlZCBpbiBSRlBzIHdlJ2xsIGhhdmUgdG8gZGVhbCB3aXRoLiBJIGZvciBvbmUgd291 bGQgbm90IHdhbnQgdGhhdCB0byBoYXBwZW4uDQoNCiAgICAgICAgUmVnYXJkcywNCiAgICAgICAg ICAgICAgICBHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSdGctYmZk IFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2FybG9zIFBp Z25hdGFybyAoY3BpZ25hdGEpDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTAsIDIwMTQgNDo0NCBB TQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQpDYzogcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IGRyYWZ0LWlldGYtYmZkLWludGVydmFscyBJQU5BIGNvbnNpZGVyYXRpb25zPw0KDQpT YXNoYSwNCg0KU29ycnkgaWYgSSB3YXNuJ3QgY2xlYXIuIExpa2UgSSBzYWlkLCBJIGRvIG5vdCB0 aGluayB0aGF0IGEgc21hbGwgc2V0IG9mIGludGVydmFsIHZhbHVlcyBxdWFsaWZpZXMgYXMgc29t ZXRoaW5nIHVzZWZ1bCB0byBiZSByZWNvcmRlZCBpbiBhbiBJQU5BIHJlZ2lzdHJ5Lg0KDQpJIGRv IG5vdCAib2JqZWN0IiwgSSBqdXN0IHNlZSBpdCBhcyB1bm5lY2Vzc2FyeSBvdmVyaGVhZCwgc29t ZXRoaW5nIHRoYXQgZG9lcyBub3QgYWRkIHZhbHVlLiBUaGVzZSBpcyBub3QgYSBuYW1lc3BhY2Ug b2YgZGlhZyBjb2RlcyBvciBhdXRoIHR5cGVzLiBJIHNlZSBubyBoYXJtIChvdGhlciB0aGFuIGJ1 c3l3b3JrKSBoZW5jZSBub3QgIm9iamVjdGluZyIuDQoNCkRvIHlvdSBrbm93IG9mIGEgc2ltaWxh ciBJQU5BIHJlZ2lzdHJ5PyBUaGUgY2FzZXMgSSBjYW4gdGhpbmsgb2Ygb2Ygc3VnZ2VzdGVkIHBy b3RvY29sIHRpbWVycy9wZXJpb2RzIGFyZSAqbm90KiBtYW5hZ2VkIGJ5IElBTkEuDQoNClRoYW5r cywNCg0KVGh1bWIgdHlwZWQgYnkgQ2FybG9zIFBpZ25hdGFyby4NCkV4Y3V6ZSB0eXBvZnJhcGhp Y2FrIGVycm93cw0KDQo+IE9uIEFwciAxMCwgMjAxNCwgYXQgNjo0MCBBTSwgIkFsZXhhbmRlciBW YWluc2h0ZWluIiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4gd3JvdGU6DQo+DQo+IENhcmxvcywNCj4gTG90 cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IGFuZCBkZXRhaWxlZCByZXNwb25zZS4NCj4NCj4gSSBm dWxseSBhZ3JlZSB3aXRoIHlvdSB0aGF0ICJpdCBjYW4gYmUgZG9uZSIgZG9lcyBub3QgbWVhbiAi aXQgc2hvdWxkIGJlIGRvbmUiLiAgV2hhdCBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gc2F5IGlzIHRo YXQsIGF0IGxlYXN0IGluIHRoaXMgY2FzZSB3ZSBhcmUgbm90IGRlYWxpbmcgd2l0aCB0aGUgc2l0 dWF0aW9uIGxpa2UgInRob3Ugc2hhbHQgbm90Li4uIiBhbmQgbm90IGV2ZW4gd2l0aCAidGhlc2Ug dGhpbmdzIGFyZSBzaW1wbHkgbm90IGRvbmUiLg0KPiBBbnkgYWR2YW50YWdlcyBhbmQgZGlzYWR2 YW50YWdlcyBhcmUgImluIHRoZSBleWUgb2YgdGhlIGJlaG9sZGVyIiAoYXQgbGVhc3QgdW50aWwg dGhlIGRvY3VtZW50IGdvZXMgdG8gdGhlIElFU0c6LSkuIEFuZCB3b3VsZCBiZSBtdWNoIGVhc2ll ciBmb3IgbWUgdG8gYWNjZXB0IHlvdXIgcG9zaXRpb24gaWYgeW91IGNvdWxkIGV4cGVjdCB3aHkg eW91IG9iamVjdCB0byByZXF1ZXN0aW5nIGEgbmV3IElBTkEgcmVnaXN0cnkuIFNvIGZhciB0aGUg bWFpbiBhcmd1bWVudCBJIHNlZSBpcyB0aGF0IHlvdSAoYW5kIHByZXN1bWFibHkgdGhlIG90aGVy IGF1dGhvcnMpIGRvIG5vdCBleHBlY3QgbWFueSB1cGRhdGVzIHRvIHRoZSBsaXN0IG9mIGNvbW1v biBpbnRlcnZhbHMuDQo+DQo+IFJlZ2FyZHMsDQo+ICAgICAgIFNhc2hhDQo+IEVtYWlsOiBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+DQo+IE1vYmlsZTogMDU0LTkyNjYzMDINCj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0 bzpjcGlnbmF0YUBjaXNjby5jb21dDQo+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTAsIDIwMTQg MTowNSBQTQ0KPj4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+PiBDYzogRG9uYWxkIEVhc3Rs YWtlOyBOb2JvIEFraXlhIChub2JvKTsgIHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRA aWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIElBTkEg Y29uc2lkZXJhdGlvbnM/DQo+Pg0KPj4gSGksIFNhc2hhLA0KPj4NCj4+IFRoYW5rcyBmb3IgdGhl IGZvbGxvdy11cCwgcGxlYXNlIHNlZSBpbmxpbmUuDQo+Pg0KPj4gT24gQXByIDgsIDIwMTQsIGF0 IDEyOjQwIEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPj4gPEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+IHdy b3RlOg0KPj4NCj4+PiBDYXJsb3MgYW5kIGFsbCwNCj4+PiBJIGFtIG5vdCBzdXJlIEkgZm9sbG93 IHRoZSBsb2dpYyBvZiB0aGUgZGVjaXNpb24uDQo+Pg0KPj4gSSBkbyBub3QgdGhpbmsgdGhlcmUn cyBhIGRlY2lzaW9uIHlldCwgb25seSBhIGRpc2N1c3Npb24uDQo+Pg0KPj4+IERvbmFsZCBoYXMg YWxyZWFkeSBjb21tZW50ZWQgb24gc2V0dGluZyBhIG5ldyByZWdpc3RyeSBpbiBhbg0KPj4gSW5m b3JtYXRpb25hbCBkb2N1bWVudDsgYW5kIHNheWluZyB0aGF0IG5ldyB2YWx1ZXMgd291bGQgYmUg YWx3YXlzDQo+PiBzZXQgdmlhIGEgbmV3IGRyYWZ0IHNlZW1zIHRvIG1hcCB3ZWxsIHRvIG9uZSBv ZiB0aGUgYWxyZWFkeSBleGlzdGluZyBJQU5BIHBvbGljaWVzLg0KPj4NCj4+IEl0IGlzIGNsZWFy bHkgcG9zc2libGUgKGFuZCBtYW55IHRpbWVzIGRlc2lyYWJsZSkgdG8gY3JlYXRlIG9yIHVwZGF0 ZQ0KPj4gSUFOQSByZWdpc3RyaWVzIHdpdGggSW5mb3JtYXRpb25hbCBkb2N1bWVudHMuIEkndmUg ZG9uZSBzbyBteXNlbGYgYXMNCj4+IHdlbGwuIEJ1dCAiaXQgY2FuIGJlIGRvbmUiIGRvZXMgbm90 IGltcGx5ICJpdCBzaG91bGQgYmUgZG9uZSIuDQo+Pg0KPj4+IEJ1dCB3aGF0IHdvcnJpZXMgbWUg bW9zdCBpcyB0aGUgZmFjdCB0aGF0IHdpdGhvdXQgYSBJQU5BIHJlZ2lzdHJ5DQo+Pj4gdGhlcmUg d2lsbA0KPj4gYmUgbm8gc2luZ2xlIHBsYWNlIHdoZXJlIHRoZXNlICJjb21tb24gaW50ZXJ2YWwg dmFsdWVzIiBjb3VsZCBiZQ0KPj4gbG9va2VkIHVwIGJ5IGltcGxlbWVudGVycy4gSW5zdGVhZCwg dGhleSB3b3VsZCBoYXZlIHRvIHRyYWNrIGENCj4+IChwb3RlbnRpYWxseSBsb25nKSBzZXF1ZW5j ZSBvZiBkb2N1bWVudHMgaW4gb3JkZXIgdG8gdW5kZXJzdGFuZCB3aGF0DQo+PiB0aGV5IHNob3Vs ZCB0cnkgdG8gaW1wbGVtZW50IGFuZCB0ZXN0Lg0KPj4NCj4+IE15IHBlcnNwZWN0aXZlIGlzIHRo YXQgYSBzZXQgb2Ygc3VnZ2VzdGVkIChvciByZWNvbW1lbmRlZCkNCj4+IGludGVydmFsL3RpbWVy IHZhbHVlcywgb3IgZGVmYXVsdCB0aW1lciB2YWx1ZXMsIGlzIG5vdCB3aGF0IGEgbnVtYmVycyBy ZWdpc3RyeSBpcyB1c2VkIGZvci4NCj4+IE1hbnkgcHJvdG9jb2xzIHJlY29tbWVuZCB0aW1lciB2 YWx1ZXMgKFRDUCwgTDJUUCwgZXRjKSwgYnV0IEkgZG8gbm90DQo+PiBiZWxpZXZlIHRob3NlIGFy ZSBtYW5hZ2VkIGJ5IElBTkEuIFRyYWNraW5nIGEgbGlua2VkLWxpc3Qgb2YgVXBkYXRlZA0KPj4g UkZDcyBpcyBub3QgYWx3YXlzIGZ1biwgYnV0IGluIHRoaXMgY2FzZSBJIHdvdWxkIG5vdCBleHBl Y3QgYSBsb25nDQo+PiBsaXN0IGRvY3VtZW50cy4gSXQgYWxzbyBzZWVtcyB0byBtZSB0aGF0IHdo ZW4gaW1wbGVtZW50aW5nIG9yDQo+PiBjaGVja2luZyBjb21wbGlhbmNlIGFnYWluc3QgYW4gUkZD LCB0aGUgZmlyc3QgcGxhY2UgdG8gY2hlY2sgaXMgdGhlIFJGQyBpdHNlbGYgYW5kIG5vdCBhbiBJ QU5BIHJlZ2lzdHJ5Lg0KPj4NCj4+Pg0KPj4+IEkgY291bGQgYWxzbyBzYXkgdGhhdCBvcGVyYXRv cnMgY29tbW9ubHkgcmVxdWVzdCAiY29tcGxpYW5jZSIgd2l0aA0KPj4gSW5mb3JtYXRpb25hbCBk b2N1bWVudHMgaW4gUkZQcyBhbmQgUkZJcyB0aGV5IHB1Ymxpc2guIChTb21lYm9keSBoYXMNCj4+ IHJlY2VudGx5IG1lbnRpb25lZCByZXF1ZXN0cyB0byBjb21wbHkgd2l0aCBzb21lIEFwcmlsIDEg IFJGQ3MgYXMgd2VsbA0KPj4gb24gdGhlIFJURy1ESVIgOi0pLkFuZCB3aGlsZSBzdWNoIGFuIGFy Z3VtZW50IHdvdWxkIG5vdCBob2xkIGluIHRoZQ0KPj4gY291cnQgb2YgbGF3LCBJIGFtIG5vdCBz dXJlIHdlIHNob3VsZCBzaW1wbHkgaWdub3JlIGl0Lg0KPj4NCj4+IFRoYXQncyBmaW5lIGJ1dCBv cnRob2dvbmFsIHRvIHRoaXMgZGlzY3Vzc2lvbi4NCj4+DQo+PiBUaGFua3MsDQo+Pg0KPj4gQ2Fy bG9zLg0KPj4NCj4+PiBNeSAyYywNCj4+PiAgICBTYXNoYQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBGcm9tOiBSdGctYmZk IDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiBDYXJsb3MNCj4+PiBQaWduYXRhcm8NCj4+PiAoY3BpZ25hdGEpIDxj cGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+DQo+Pj4gU2VudDog VHVlc2RheSwgQXByaWwgOCwgMjAxNCA2OjExIEFNDQo+Pj4gVG86IERvbmFsZCBFYXN0bGFrZTsg Tm9ibyBBa2l5YSAobm9ibykNCj4+PiBDYzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJm ZEBpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIElB TkEgY29uc2lkZXJhdGlvbnM/DQo+Pj4NCj4+PiBEb25hbGQsDQo+Pj4NCj4+PiBJIGFncmVlIHdp dGggdGhpcyBhcyBhIGdlbmVyYWwgc3RhdGVtZW50LiBBcyBpdCBwZXJ0YWlucyB0byB0aGUNCj4+ PiDCs0NvbW1vbiBpbnRlcnZhbCB2YWx1ZXPCsiwgaXQgZG9lcyBub3QgYXBwZWFyIHRoYXQgaXMg dGhlIHJvbGUgb2YgYW4NCj4+PiBJQU5BIG51bWJlcnMgcmVnaXN0cnkuDQo+Pj4NCj4+PiBUaGFu a3MsDQo+Pj4NCj4+PiBDYXJsb3MuDQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+IEZyb206IERvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbTxtYWlsdG86ZDNl M2UzQGdtYWlsLmNvbT4+DQo+Pj4gRGF0ZTogTW9uZGF5LCBBcHJpbCA3LCAyMDE0IGF0IDExOjA1 IFBNDQo+Pj4gVG86IE5vYm8gQWtpeWEgPG5vYm9AY2lzY28uY29tPG1haWx0bzpub2JvQGNpc2Nv LmNvbT4+DQo+Pj4gQ2M6ICJydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3Jn PiIgPHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+Pg0KPj4+IFN1Ympl Y3Q6IFJlOiBkcmFmdC1pZXRmLWJmZC1pbnRlcnZhbHMgSUFOQSBjb25zaWRlcmF0aW9ucz8NCj4+ Pg0KPj4+PiBUaGVyZSBpcyBubyBwcm9ibGVtIHdpdGggaGF2aW5nIElBTkEgQ29uc2lkZXJhdGlv bnMgc2V0dGluZyB1cCBhDQo+Pj4+IHJlZ2lzdHJ5IG9yIHRoZSBsaWtlIGluIGFuIEluZm9ybWF0 aW9uYWwgZG9jdW1lbnQuDQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gRG9uYWxkDQo+Pj4+ID09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4+IERvbmFsZCBFLiBFYXN0bGFrZSAzcmQg ICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQo+Pj4+IDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3Jk LCBNQSAwMTc1NyBVU0EgIGQzZTNlM0BnbWFpbC5jb208bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+ DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIE1vbiwgQXByIDcsIDIwMTQgYXQgMTowNyBQTSwgTm9ibyBB a2l5YSAobm9ibykgPG5vYm9AY2lzY28uY29tPG1haWx0bzpub2JvQGNpc2NvLmNvbT4+DQo+PiB3 cm90ZToNCj4+Pj4+IEhpIEJGRGVycywNCj4+Pj4+DQo+Pj4+PiBBdXRob3JzIG9mIGRyYWZ0LWll dGYtYmZkLWludGVydmFscyBoYXZlIGRpc2N1c3NlZCBhbmQgY29uY2x1ZGVkDQo+Pj4+PiB0aGF0 IGRlZmluZWQgImNvbW1vbiBpbnRlcnZhbHMgc2V0IiBkb2VzIF9ub3RfIG5lZWQgdG8gYmUNCj4+ Pj4+IG1haW50YWluZWQNCj4+IGJ5IElBTkEuDQo+Pj4+Pg0KPj4+Pj4gUmVhc29uczoNCj4+Pj4+ IDEuIERvY3VtZW50IGlzIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQuDQo+Pj4+PiAyLiBBZGRpdGlv bnMgb2YgaW50ZXJ2YWwocykgaW4gdGhlICJjb21tb24gaW50ZXJ2YWxzIHNldCIgc2hvdWxkDQo+ Pj4+PiBhbnl3YXlzIGJlIGRvbmUgdGhyb3VnaCBhIG5ldyBkcmFmdCwgd2hldGhlciBvciBub3QN Cj4+Pj4+IGRyYWZ0LWlldGYtYmZkLWludGVydmFscyBjcmVhdGVzIGFuIElBTkEgcmVnaXN0cnkg YW5kIGRlZmluZXMNCj4+Pj4+IGFsbG9jYXRpb24gcG9saWNpZXMgZm9yIGl0Lg0KPj4+Pj4NCj4+ Pj4+IERvIHlvdSBhZ3JlZSB3aXRoIHRoaXM/DQo+Pj4+PiBEbyB5b3Ugc2VlIGFueSBjb25jZXJu IHdpdGggdGhpcz8NCj4+Pj4+DQo+Pj4+PiBTZWVraW5nIG9waW5pb25zL2NvbW1lbnRzIGZyb20g Zm9sa3Mgb24gdGhpcyBtYXR0ZXIuDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gTm9ibywg TWFyYywgR3JlZw0KPg0KDQoNCg== --_000_95ebd013887b448cb85770bd60a46577AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCi5FbWFpbFF1b3RlDQoJ e21hcmdpbi1sZWZ0OjFwdDsNCglwYWRkaW5nLWxlZnQ6NHB0Ow0KCWJvcmRlci1sZWZ0OiM4MDAw MDAgMnB4IHNvbGlkfQ0KLS0+DQo8L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwcHQ7Ij4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRv bTowOyI+RGVhciBHcmVnLDwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRv bTowOyI+SSB0aGluayB0aGF0IHRoZSB2YWx1ZXMgbGlzdGVkIGluIHRoaXMgZHJhZnQgd2lsbCB1 bHRpbWF0ZWx5IGZpbmQgdGhlaXIgd2F5IHRvIFJGUHMgcmVnYXJkbGVzcyBvZiBjcmVhdGlvbiAo b3Igbm9uLWNyZWF0aW9uKSBvZiB0aGUgcmVnaXN0cnkuPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10 b3A6MDttYXJnaW4tYm90dG9tOjA7Ij5BbmQgd2hpbGUgdGhlIGRyYWZ0IGlzIEluZm9ybWF0aW9u YWwsIGl0IGlzIHF1aXRlIGNvbnZpbmNpbmcgaW4gZXhwbGFpbmluZyB0aGF0IHN1cHBvcnQgb2Yg dGhpcyBzZXQgb2YgdmFsdWVzIGlzIGltcG9ydGFudCBmb3IgYWNoaWV2aW5nIGluZXJvcGVyYWJp bGl0eS4uLiBXaGljaCBtYWtlcyBpdCBxdWl0ZSByZWFzb25hYmxlIGZvciB0aGUgb3BlcmF0b3Jz IHRvIHJlcXVlc3QNCiB0aGF0IHRoZXNlIHZhbHVlcyBhcmUgc3VwcG9ydGVkLjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+TXkgMmMsPC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij5TYXNoYTwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+Jm5ic3A7PC9wPg0KPGRldjNfamp5PlNlbnQgZnJv bSBteSBMRyBNb2JpbGU8L2RldjNfamp5Pjxicj4NCjxicj4NCi0tLS0tLSBPcmlnaW5hbCBtZXNz YWdlIC0tLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9iPkdyZWdvcnkgTWlyc2t5PGdyZWdvcnku bWlyc2t5QGVyaWNzc29uLmNvbT48YnI+DQo8Yj5EYXRlOiZuYnNwOzwvYj4xMC8wNC8yMDE0IDE4 OjMwPGJyPg0KPGI+VG86Jm5ic3A7PC9iPkNhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTtBbGV4 YW5kZXIgVmFpbnNodGVpbjs8YnI+DQo8Yj5DYzombmJzcDs8L2I+cnRnLWJmZEBpZXRmLm9yZzs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj5SRTogZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIElBTkEgY29u c2lkZXJhdGlvbnM/PGJyPg0KPGJyPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij4NCjxkaXY+RGVhciBTYXNoYSwgQ2FybG9zLCBldC4g YWwsPC9kaXY+DQo8ZGl2Pkkgc2hhcmUgQ2FybG9zJyBwb2ludCBvZiB2aWV3IGluIHJlZ2FyZCB0 byBjcmVhdGluZyBhIG5ldyByZWdpc3RyeSBmb3ImbmJzcDs8dT5yZWNvbW1lbmRlZDwvdT4gc2V0 IG9mIEJGRCBpbnRlcnZhbHMuIEkgdGhpbmsgdGhhdCBwcmVjaXNlbHkgYmVjYXVzZSB0aGVzZSB2 YWx1ZXMgYmVlbiByZWNvbW1lbmRlZCBhbmQgbm9uZSBpcyBtYW5kYXRvcnkgY3JlYXRpbmcgYSBy ZWdpc3RyeSwgSU1PLCBpcyBub3QgbmVjZXNzYXJ5LiBBbmQgSSdtIGNvbmNlcm5lZA0KIHRoYXQg aWYgdGhlcmUncyBzdWNoIHJlZ2lzdHJ5IHRoZW4gaW50ZXJwcmV0YXRpb24gb2YgdGhlIHNldCBt aWdodCBjaGFuZ2UgZnJvbSAncmVjb21tZW5kZWQnIHRvICdtYW5kYXRvcnknLiBBbmQgdGhhdCBt aWdodCBiZSByZWZsZWN0ZWQgaW4gUkZQcyB3ZSdsbCBoYXZlIHRvIGRlYWwgd2l0aC4gSSBmb3Ig b25lIHdvdWxkIG5vdCB3YW50IHRoYXQgdG8gaGFwcGVuLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 UmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7R3JlZzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBSdGctYmZkIFs8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTxicj4NClNlbnQ6IFRodXJzZGF5LCBB cHJpbCAxMCwgMjAxNCA0OjQ0IEFNPGJyPg0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluPGJyPg0K Q2M6IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmQtaW50 ZXJ2YWxzIElBTkEgY29uc2lkZXJhdGlvbnM/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp dj5TYXNoYSw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlNvcnJ5IGlmIEkgd2Fzbid0 IGNsZWFyLiBMaWtlIEkgc2FpZCwgSSBkbyBub3QgdGhpbmsgdGhhdCBhIHNtYWxsIHNldCBvZiBp bnRlcnZhbCB2YWx1ZXMgcXVhbGlmaWVzIGFzIHNvbWV0aGluZyB1c2VmdWwgdG8gYmUgcmVjb3Jk ZWQgaW4gYW4gSUFOQSByZWdpc3RyeS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkkg ZG8gbm90ICZxdW90O29iamVjdCZxdW90OywgSSBqdXN0IHNlZSBpdCBhcyB1bm5lY2Vzc2FyeSBv dmVyaGVhZCwgc29tZXRoaW5nIHRoYXQgZG9lcyBub3QgYWRkIHZhbHVlLiBUaGVzZSBpcyBub3Qg YSBuYW1lc3BhY2Ugb2YgZGlhZyBjb2RlcyBvciBhdXRoIHR5cGVzLiBJIHNlZSBubyBoYXJtIChv dGhlciB0aGFuIGJ1c3l3b3JrKSBoZW5jZSBub3QgJnF1b3Q7b2JqZWN0aW5nJnF1b3Q7Lg0KPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5EbyB5b3Uga25vdyBvZiBhIHNpbWlsYXIgSUFO QSByZWdpc3RyeT8gVGhlIGNhc2VzIEkgY2FuIHRoaW5rIG9mIG9mIHN1Z2dlc3RlZCBwcm90b2Nv bCB0aW1lcnMvcGVyaW9kcyBhcmUgKm5vdCogbWFuYWdlZCBieSBJQU5BLg0KPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp dj5UaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLjwvZGl2Pg0KPGRpdj5FeGN1emUgdHlw b2ZyYXBoaWNhayBlcnJvd3M8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgT24g QXByIDEwLCAyMDE0LCBhdCA2OjQwIEFNLCAmcXVvdDtBbGV4YW5kZXIgVmFpbnNodGVpbiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5B bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRp dj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IENhcmxvcyw8L2Rpdj4NCjxkaXY+Jmd0OyBMb3RzIG9m IHRoYW5rcyBmb3IgYSBwcm9tcHQgYW5kIGRldGFpbGVkIHJlc3BvbnNlLjwvZGl2Pg0KPGRpdj4m Z3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3UgdGhhdCAmcXVvdDtp dCBjYW4gYmUgZG9uZSZxdW90OyBkb2VzIG5vdCBtZWFuICZxdW90O2l0IHNob3VsZCBiZSBkb25l JnF1b3Q7LiAmbmJzcDtXaGF0IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBzYXkgaXMgdGhhdCwgYXQg bGVhc3QgaW4gdGhpcyBjYXNlIHdlIGFyZSBub3QgZGVhbGluZyB3aXRoIHRoZSBzaXR1YXRpb24g bGlrZSAmcXVvdDt0aG91IHNoYWx0IG5vdC4uLiZxdW90OyBhbmQgbm90IGV2ZW4gd2l0aCAmcXVv dDt0aGVzZSB0aGluZ3MgYXJlIHNpbXBseSBub3QNCiBkb25lJnF1b3Q7LiA8L2Rpdj4NCjxkaXY+ Jmd0OyBBbnkgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyBhcmUgJnF1b3Q7aW4gdGhlIGV5 ZSBvZiB0aGUgYmVob2xkZXImcXVvdDsgKGF0IGxlYXN0IHVudGlsIHRoZSBkb2N1bWVudCBnb2Vz IHRvIHRoZSBJRVNHOi0pLiBBbmQgd291bGQgYmUgbXVjaCBlYXNpZXIgZm9yIG1lIHRvIGFjY2Vw dCB5b3VyIHBvc2l0aW9uIGlmIHlvdSBjb3VsZCBleHBlY3Qgd2h5IHlvdSBvYmplY3QgdG8gcmVx dWVzdGluZyBhIG5ldyBJQU5BIHJlZ2lzdHJ5LiBTbyBmYXIgdGhlDQogbWFpbiBhcmd1bWVudCBJ IHNlZSBpcyB0aGF0IHlvdSAoYW5kIHByZXN1bWFibHkgdGhlIG90aGVyIGF1dGhvcnMpIGRvIG5v dCBleHBlY3QgbWFueSB1cGRhdGVzIHRvIHRoZSBsaXN0IG9mIGNvbW1vbiBpbnRlcnZhbHMuPC9k aXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgUmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTYXNoYTwvZGl2Pg0KPGRpdj4m Z3Q7IEVtYWlsOiZuYnNwOzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbSI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PC9kaXY+DQo8ZGl2 PiZndDsgTW9iaWxlOiAwNTQtOTI2NjMwMjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBG cm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgWzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0 YUBjaXNjby5jb20iPm1haWx0bzpjcGlnbmF0YUBjaXNjby5jb208L2E+XTwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgQXByaWwgMTAsIDIwMTQgMTowNSBQTTwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW48L2Rpdj4NCjxkaXY+Jmd0OyZndDsg Q2M6IERvbmFsZCBFYXN0bGFrZTsgTm9ibyBBa2l5YSAobm9ibyk7Jm5ic3A7IDxhIGhyZWY9Im1h aWx0bzpydGctYmZkQGlldGYub3JnIj4NCnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWJmZC1pbnRlcnZhbHMgSUFOQSBjb25z aWRlcmF0aW9ucz88L2Rpdj4NCjxkaXY+Jmd0OyZndDsgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IEhp LCBTYXNoYSw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFRoYW5r cyBmb3IgdGhlIGZvbGxvdy11cCwgcGxlYXNlIHNlZSBpbmxpbmUuPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBPbiBBcHIgOCwgMjAxNCwgYXQgMTI6NDAgQU0sIEFs ZXhhbmRlciBWYWluc2h0ZWluIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8L2Rpdj4N CjxkaXY+Jmd0OyZndDsmZ3Q7IENhcmxvcyBhbmQgYWxsLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZn dDsgSSBhbSBub3Qgc3VyZSBJIGZvbGxvdyB0aGUgbG9naWMgb2YgdGhlIGRlY2lzaW9uLjwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgSSBkbyBub3QgdGhpbmsgdGhl cmUncyBhIGRlY2lzaW9uIHlldCwgb25seSBhIGRpc2N1c3Npb24uPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgRG9uYWxkIGhhcyBhbHJlYWR5IGNvbW1lbnRl ZCBvbiBzZXR0aW5nIGEgbmV3IHJlZ2lzdHJ5IGluIGFuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IElu Zm9ybWF0aW9uYWwgZG9jdW1lbnQ7IGFuZCBzYXlpbmcgdGhhdCBuZXcgdmFsdWVzIHdvdWxkIGJl IGFsd2F5cyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgc2V0IHZpYSBhIG5ldyBkcmFmdCBzZWVtcyB0 byBtYXAgd2VsbCB0byBvbmUgb2YgdGhlIGFscmVhZHkgZXhpc3RpbmcgSUFOQSBwb2xpY2llcy48 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IEl0IGlzIGNsZWFybHkg cG9zc2libGUgKGFuZCBtYW55IHRpbWVzIGRlc2lyYWJsZSkgdG8gY3JlYXRlIG9yIHVwZGF0ZSA8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgSUFOQSByZWdpc3RyaWVzIHdpdGggSW5mb3JtYXRpb25hbCBk b2N1bWVudHMuIEkndmUgZG9uZSBzbyBteXNlbGYgYXMgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IHdl bGwuIEJ1dCAmcXVvdDtpdCBjYW4gYmUgZG9uZSZxdW90OyBkb2VzIG5vdCBpbXBseSAmcXVvdDtp dCBzaG91bGQgYmUgZG9uZSZxdW90Oy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7Jmd0OyBCdXQgd2hhdCB3b3JyaWVzIG1lIG1vc3QgaXMgdGhlIGZhY3QgdGhhdCB3 aXRob3V0IGEgSUFOQSByZWdpc3RyeSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IHRoZXJlIHdp bGw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgYmUgbm8gc2luZ2xlIHBsYWNlIHdoZXJlIHRoZXNlICZx dW90O2NvbW1vbiBpbnRlcnZhbCB2YWx1ZXMmcXVvdDsgY291bGQgYmUgPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7IGxvb2tlZCB1cCBieSBpbXBsZW1lbnRlcnMuIEluc3RlYWQsIHRoZXkgd291bGQgaGF2 ZSB0byB0cmFjayBhIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAocG90ZW50aWFsbHkgbG9uZykgc2Vx dWVuY2Ugb2YgZG9jdW1lbnRzIGluIG9yZGVyIHRvIHVuZGVyc3RhbmQgd2hhdCA8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgdGhleSBzaG91bGQgdHJ5IHRvIGltcGxlbWVudCBhbmQgdGVzdC48L2Rpdj4N CjxkaXY+Jmd0OyZndDsgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IE15IHBlcnNwZWN0aXZlIGlzIHRo YXQgYSBzZXQgb2Ygc3VnZ2VzdGVkIChvciByZWNvbW1lbmRlZCkgPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7IGludGVydmFsL3RpbWVyIHZhbHVlcywgb3IgZGVmYXVsdCB0aW1lciB2YWx1ZXMsIGlzIG5v dCB3aGF0IGEgbnVtYmVycyByZWdpc3RyeSBpcyB1c2VkIGZvci48L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgTWFueSBwcm90b2NvbHMgcmVjb21tZW5kIHRpbWVyIHZhbHVlcyAoVENQLCBMMlRQLCBldGMp LCBidXQgSSBkbyBub3QgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IGJlbGlldmUgdGhvc2UgYXJlIG1h bmFnZWQgYnkgSUFOQS4gVHJhY2tpbmcgYSBsaW5rZWQtbGlzdCBvZiBVcGRhdGVkIDwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyBSRkNzIGlzIG5vdCBhbHdheXMgZnVuLCBidXQgaW4gdGhpcyBjYXNlIEkg d291bGQgbm90IGV4cGVjdCBhIGxvbmcgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IGxpc3QgZG9jdW1l bnRzLiBJdCBhbHNvIHNlZW1zIHRvIG1lIHRoYXQgd2hlbiBpbXBsZW1lbnRpbmcgb3IgPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7IGNoZWNraW5nIGNvbXBsaWFuY2UgYWdhaW5zdCBhbiBSRkMsIHRoZSBm aXJzdCBwbGFjZSB0byBjaGVjayBpcyB0aGUgUkZDIGl0c2VsZiBhbmQgbm90IGFuIElBTkEgcmVn aXN0cnkuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBJIGNvdWxkIGFsc28gc2F5IHRoYXQgb3BlcmF0b3JzIGNv bW1vbmx5IHJlcXVlc3QgJnF1b3Q7Y29tcGxpYW5jZSZxdW90OyB3aXRoPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7IEluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIGluIFJGUHMgYW5kIFJGSXMgdGhleSBwdWJs aXNoLiAoU29tZWJvZHkgaGFzIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyByZWNlbnRseSBtZW50aW9u ZWQgcmVxdWVzdHMgdG8gY29tcGx5IHdpdGggc29tZSBBcHJpbCAxICZuYnNwO1JGQ3MgYXMgd2Vs bCA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgb24gdGhlIFJURy1ESVIgOi0pLkFuZCB3aGlsZSBzdWNo IGFuIGFyZ3VtZW50IHdvdWxkIG5vdCBob2xkIGluIHRoZSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsg Y291cnQgb2YgbGF3LCBJIGFtIG5vdCBzdXJlIHdlIHNob3VsZCBzaW1wbHkgaWdub3JlIGl0Ljwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgVGhhdCdzIGZpbmUgYnV0 IG9ydGhvZ29uYWwgdG8gdGhpcyBkaXNjdXNzaW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8L2Rp dj4NCjxkaXY+Jmd0OyZndDsgVGhhbmtzLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgQ2FybG9zLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7IE15IDJjLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5i c3A7U2FzaGE8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZn dDsgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7IEZyb206IFJ0Zy1iZmQgJmx0OzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmciPnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBD YXJsb3MNCjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgUGlnbmF0YXJvPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7Jmd0OyAoY3BpZ25hdGEpICZsdDs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28u Y29tIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsg U2VudDogVHVlc2RheSwgQXByaWwgOCwgMjAxNCA2OjExIEFNPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jmd0OyBUbzogRG9uYWxkIEVhc3RsYWtlOyBOb2JvIEFraXlhIChub2JvKTwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDsgQ2M6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPnJ0 Zy1iZmRAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTog ZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIElBTkEgY29uc2lkZXJhdGlvbnM/PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IERvbmFsZCw8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgSSBhZ3JlZSB3aXRoIHRo aXMgYXMgYSBnZW5lcmFsIHN0YXRlbWVudC4gQXMgaXQgcGVydGFpbnMgdG8gdGhlIDwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZndDsgwrNDb21tb24gaW50ZXJ2YWwgdmFsdWVzwrIsIGl0IGRvZXMgbm90 IGFwcGVhciB0aGF0IGlzIHRoZSByb2xlIG9mIGFuIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsg SUFOQSBudW1iZXJzIHJlZ2lzdHJ5LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jmd0OyBUaGFua3MsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyA8L2Rpdj4N CjxkaXY+Jmd0OyZndDsmZ3Q7IENhcmxvcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IDwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7IEZyb206IERvbmFsZCBFYXN0bGFrZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmQzZTNlM0BnbWFpbC5jb20iPmQzZTNlM0BnbWFpbC5jb208L2E+Jmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDsgRGF0ZTogTW9uZGF5LCBBcHJpbCA3LCAyMDE0IGF0IDExOjA1IFBNPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBUbzogTm9ibyBBa2l5YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5v Ym9AY2lzY28uY29tIj5ub2JvQGNpc2NvLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jmd0OyBDYzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPnJ0Zy1iZmRA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyI+ cnRnLWJmZEBpZXRmLm9yZzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBTdWJqZWN0 OiBSZTogZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIElBTkEgY29uc2lkZXJhdGlvbnM/PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBp cyBubyBwcm9ibGVtIHdpdGggaGF2aW5nIElBTkEgQ29uc2lkZXJhdGlvbnMgc2V0dGluZyB1cCBh IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2lzdHJ5IG9yIHRoZSBsaWtlIGluIGFu IEluZm9ybWF0aW9uYWwgZG9jdW1lbnQuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsgPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZn dDsmZ3Q7IERvbmFsZDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7ID09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsgRG9uYWxkIEUuIEVh c3RsYWtlIDNyZCAmbmJzcDsmbmJzcDsmIzQzOzEtNTA4LTMzMy0yMjcwIChjZWxsKTwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1 NyBVU0EmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmQzZTNlM0BnbWFpbC5jb20iPg0KZDNlM2UzQGdt YWlsLmNvbTwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNb24sIEFwciA3 LCAyMDE0IGF0IDE6MDcgUE0sIE5vYm8gQWtpeWEgKG5vYm8pICZsdDs8YSBocmVmPSJtYWlsdG86 bm9ib0BjaXNjby5jb20iPm5vYm9AY2lzY28uY29tPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIEJGRGVycyw8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIGhhdmUgZGlzY3Vzc2Vk IGFuZCBjb25jbHVkZWQgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgZGVm aW5lZCAmcXVvdDtjb21tb24gaW50ZXJ2YWxzIHNldCZxdW90OyBkb2VzIF9ub3RfIG5lZWQgdG8g YmUgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1haW50YWluZWQ8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgYnkgSUFOQS48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlYXNvbnM6PC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDEuIERvY3VtZW50IGlzIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQuPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIuIEFkZGl0aW9ucyBvZiBpbnRlcnZhbChz KSBpbiB0aGUgJnF1b3Q7Y29tbW9uIGludGVydmFscyBzZXQmcXVvdDsgc2hvdWxkIDwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbnl3YXlzIGJlIGRvbmUgdGhyb3VnaCBhIG5ldyBk cmFmdCwgd2hldGhlciBvciBub3QgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRy YWZ0LWlldGYtYmZkLWludGVydmFscyBjcmVhdGVzIGFuIElBTkEgcmVnaXN0cnkgYW5kIGRlZmlu ZXMgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFsbG9jYXRpb24gcG9saWNpZXMg Zm9yIGl0LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgRG8geW91IGFncmVlIHdpdGggdGhpcz88L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgRG8geW91IHNlZSBhbnkgY29uY2VybiB3aXRoIHRoaXM/PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBTZWVraW5nIG9waW5pb25zL2NvbW1lbnRzIGZyb20gZm9sa3Mgb24gdGhpcyBtYXR0ZXIu PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGFua3MsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vYm8s IE1hcmMsIEdyZWc8L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_95ebd013887b448cb85770bd60a46577AM3PR03MB612eurprd03pro_-- From nobody Fri Apr 11 10:45:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729231A0738 for ; Fri, 11 Apr 2014 10:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEGhY1nSTk0v for ; Fri, 11 Apr 2014 10:45:50 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 13BC21A0729 for ; Fri, 11 Apr 2014 10:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13392; q=dns/txt; s=iport; t=1397238349; x=1398447949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o7pz5qKZiS8gFuCBJrhc4/NQsu3HsiWEtPiT69lQNYE=; b=jP22bCgHhC0k+hJPvN2LSUOBVZKikFqvTxg/QEh4T2cLCbwM04DUzkih chfxm8myjj2np63LDUSjBiepGFi05g2MgSmACKjd0vUZpCdealhT3n5RB qU/wz8SouywNqYNpfe82Iu9I8o1/KK75Kx2GHM40CFWMFYgU1DY4AOsL5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAPQpSFOtJV2b/2dsb2JhbABWA4JlIYESgw7BRBmBBRZ0giUBAQEDASMRRQwEAgEGAhEDAQEBAQICBh0DAgICHxEUAQgIAgQBDQUIh2ADCQgBjRScGZtuDYZjF4EpiyqBNxEBHwYQCxAHBAILgl41gRQBA5RzgX+OYYVPgzGBcjk X-IronPort-AV: E=Sophos;i="4.97,843,1389744000"; d="scan'208";a="35051416" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 11 Apr 2014 17:45:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3BHjmKf015729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 17:45:48 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 12:45:47 -0500 From: "Nobo Akiya (nobo)" To: Alexander Vainshtein , Gregory Mirsky , "Carlos Pignataro (cpignata)" Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: AQHPVOi+sLTMhLuZTf6VtD0SKBbG+psMi19g Date: Fri, 11 Apr 2014 17:45:46 +0000 Message-ID: References: <95ebd013887b448cb85770bd60a46577@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <95ebd013887b448cb85770bd60a46577@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ERXuuGRA5qzWhUPmy26Nxtwd4WI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:45:54 -0000 W2hpc3Rvcnkgb2YgdGhlIGRyYWZ0XQ0KLSBUaGlzIGRvY3VtZW50IHVzZWQgdG8gYmUgc3RhbmRh cmQgdHJhY2suDQotIFNldmVyYWwgZm9sa3Mgd2VyZSBvcHBvc2VkIHRvIHRoZSBkb2N1bWVudCBi ZWluZyBzdGFuZGFyZCB0cmFjay4NCi0gTWFueSAoaW5jbHVkaW5nIHRob3NlIHdobyBvcHBvc2Vk IGFzIHN0YW5kYXJkIHRyYWNrKSB3ZXJlIHN1cHBvcnRpdmUgb2YgdGhlIGRvY3VtZW50IGJlaW5n IGluZm9ybWF0aW9uYWwuDQotIERvY3VtZW50IGNoYW5nZWQgdG8gaW5mb3JtYXRpb25hbCBmcm9t IC0wNCBvZiBpbmRpdmlkdWFsIGRvY3VtZW50Lg0KDQpUaHVzLCB0ZWNobmljYWxseSwgcHJvcG9z ZWQgaW50ZXJ2YWxzIHdpbGwgb25seSBiZSAicmVjb21tZW5kZWQiIHNldCBvZiBpbnRlcnZhbHMu DQoNCltTYXNoYSB3cm90ZV0NCj4gSSB0aGluayB0aGF0IHRoZSB2YWx1ZXMgbGlzdGVkIGluIHRo aXMgZHJhZnQgd2lsbCB1bHRpbWF0ZWx5IGZpbmQgdGhlaXIgd2F5IHRvDQo+IFJGUHMgcmVnYXJk bGVzcyBvZiBjcmVhdGlvbiAob3Igbm9uLWNyZWF0aW9uKSBvZiB0aGUgcmVnaXN0cnkuDQoNCltK ZWZmIHdyb3RlXQ0KPiBBbmQgb25lIG11c3QgYWRtaXQgdGhlIHdob2xlIHBvaW50IG9mIHN1Y2gg YSBkcmFmdCBpbiB0aGUgZmlyc3QgcGxhY2UgaXMgdG8NCj4gZ2l2ZSB1c2VycyBhIHdheSB0byBz YXkgInRoaXMgaXMgYSBjb21tb24gdmFsdWUsIGRvIHlvdSBzdXBwb3J0IGl0PyINCg0KQW5kIGFz IHlvdSBTYXNoYSBhbmQgSmVmZiBzdGF0ZWQsIGl0IHdpbGwgYmUgdXAgdG8gdmVuZG9ycy9vcGVy YXRvcnMgdG8gZ2V0IHRoZSAicmVjb21tZW5kZWQiIGludGVydmFsIHNldCBpbiBpbXBsZW1lbnRh dGlvbnMgdG8gaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5LCB2aWEgcG9pbnRpbmcgdG8gdGhpcyBk cmFmdC4NCg0KTmVpdGhlciBvZiBhYm92ZSBhcmUgcmVsZXZhbnQgb2Ygd2hldGhlciBvciBub3Qg d2UgbmVlZCBJQU5BIHJlZ2lzdHJ5IGZvciAicmVjb21tZW5kZWQiIGludGVydmFsIHNldCwgYnV0 IGZlbHQgdGhhdCB0aGV5J2xsIHByb3ZpZGUgc29tZSB1c2UgdG8gdGhvc2UganVzdCBzdGFydGlu ZyB0byByZWFkIHRoaXMgdGhyZWFkL2RyYWZ0Lg0KDQpBcyBmb3IgSUFOQSwgSSBiZWxpZXZlIHdl IGhhdmUgMyBhcHByb2FjaGVzLg0KMS4gQ3JlYXRlIElBTkEgcmVnaXN0cnkgd2l0aCB0aGlzIGRy YWZ0Lg0KMi4gRG8gbm90IGNyZWF0ZSBJQU5BIHJlZ2lzdHJ5IHdpdGggdGhpcyBkcmFmdC4NCjMu IERvIG5vdCBjcmVhdGUgSUFOQSByZWdpc3RyeSB3aXRoIHRoaXMgZHJhZnQsIGJ1dCBjcmVhdGUg SUFOQSByZWdpc3RyeSB3aXRoIGZ1dHVyZSBkcmFmdCBpZi93aGVuIHdlIGZvcmVzZWUgW211bHRp cGxlXSB1cGRhdGVzIHRvICJyZWNvbW1lbmRlZCIgaW50ZXJ2YWwgc2V0IGFuZCB3ZSBjb252ZXJn ZSB0aGF0IGhhdmluZyBJQU5BIG1haW50ZW5hbmNlIHdpbGwgYmUgYmVuZWZpY2lhbC4NCg0KU2lu Y2UgdGhlcmUgYXJlIG9waW5pb25zIGZvciBib3RoICgxKSBhbmQgKDIpLCB3aXRoIG1vcmUgZm9s a3MgYXJndWluZyBmb3IgKDIpLCBwZXJoYXBzIGFwcHJvYWNoICgzKSBtaWdodCBiZSBhIHJlYXNv bmFibGUgbWlkZGxlIGdyb3VuZD8NCg0KLU5vYm8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQWxleGFuZGVyDQo+IFZhaW5zaHRlaW4NCj4gU2VudDogVGh1cnNkYXksIEFw cmlsIDEwLCAyMDE0IDI6MTUgUE0NCj4gVG86IEdyZWdvcnkgTWlyc2t5OyBDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSkNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGRy YWZ0LWlldGYtYmZkLWludGVydmFscyBJQU5BIGNvbnNpZGVyYXRpb25zPw0KPiANCj4gRGVhciBH cmVnLA0KPiBJIHRoaW5rIHRoYXQgdGhlIHZhbHVlcyBsaXN0ZWQgaW4gdGhpcyBkcmFmdCB3aWxs IHVsdGltYXRlbHkgZmluZCB0aGVpciB3YXkgdG8NCj4gUkZQcyByZWdhcmRsZXNzIG9mIGNyZWF0 aW9uIChvciBub24tY3JlYXRpb24pIG9mIHRoZSByZWdpc3RyeS4NCj4gQW5kIHdoaWxlIHRoZSBk cmFmdCBpcyBJbmZvcm1hdGlvbmFsLCBpdCBpcyBxdWl0ZSBjb252aW5jaW5nIGluIGV4cGxhaW5p bmcgdGhhdA0KPiBzdXBwb3J0IG9mIHRoaXMgc2V0IG9mIHZhbHVlcyBpcyBpbXBvcnRhbnQgZm9y IGFjaGlldmluZyBpbmVyb3BlcmFiaWxpdHkuLi4NCj4gV2hpY2ggbWFrZXMgaXQgcXVpdGUgcmVh c29uYWJsZSBmb3IgdGhlIG9wZXJhdG9ycyB0byByZXF1ZXN0IHRoYXQgdGhlc2UNCj4gdmFsdWVz IGFyZSBzdXBwb3J0ZWQuDQo+IE15IDJjLA0KPiBTYXNoYQ0KPiANCj4gU2VudCBmcm9tIG15IExH IE1vYmlsZQ0KPiANCj4gLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tDQo+IEZyb206wqBH cmVnb3J5IE1pcnNreQ0KPiBEYXRlOsKgMTAvMDQvMjAxNCAxODozMA0KPiBUbzrCoENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKTtBbGV4YW5kZXIgVmFpbnNodGVpbjsNCj4gQ2M6wqBydGctYmZk QGlldGYub3JnOw0KPiBTdWJqZWN0OlJFOiBkcmFmdC1pZXRmLWJmZC1pbnRlcnZhbHMgSUFOQSBj b25zaWRlcmF0aW9ucz8NCj4gRGVhciBTYXNoYSwgQ2FybG9zLCBldC4gYWwsDQo+IEkgc2hhcmUg Q2FybG9zJyBwb2ludCBvZiB2aWV3IGluIHJlZ2FyZCB0byBjcmVhdGluZyBhIG5ldyByZWdpc3Ry eQ0KPiBmb3LCoHJlY29tbWVuZGVkIHNldCBvZiBCRkQgaW50ZXJ2YWxzLiBJIHRoaW5rIHRoYXQg cHJlY2lzZWx5IGJlY2F1c2UgdGhlc2UNCj4gdmFsdWVzIGJlZW4gcmVjb21tZW5kZWQgYW5kIG5v bmUgaXMgbWFuZGF0b3J5IGNyZWF0aW5nIGEgcmVnaXN0cnksIElNTywNCj4gaXMgbm90IG5lY2Vz c2FyeS4gQW5kIEknbSBjb25jZXJuZWQgdGhhdCBpZiB0aGVyZSdzIHN1Y2ggcmVnaXN0cnkgdGhl bg0KPiBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc2V0IG1pZ2h0IGNoYW5nZSBmcm9tICdyZWNvbW1l bmRlZCcgdG8gJ21hbmRhdG9yeScuDQo+IEFuZCB0aGF0IG1pZ2h0IGJlIHJlZmxlY3RlZCBpbiBS RlBzIHdlJ2xsIGhhdmUgdG8gZGVhbCB3aXRoLiBJIGZvciBvbmUgd291bGQNCj4gbm90IHdhbnQg dGhhdCB0byBoYXBwZW4uDQo+IA0KPiDCoMKgwqDCoMKgwqDCoMKgUmVnYXJkcywNCj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBHcmVnDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQ2FybG9zDQo+IFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+IFNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAxMCwgMjAxNCA0OjQ0IEFNDQo+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVp bg0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmQt aW50ZXJ2YWxzIElBTkEgY29uc2lkZXJhdGlvbnM/DQo+IA0KPiBTYXNoYSwNCj4gDQo+IFNvcnJ5 IGlmIEkgd2Fzbid0IGNsZWFyLiBMaWtlIEkgc2FpZCwgSSBkbyBub3QgdGhpbmsgdGhhdCBhIHNt YWxsIHNldCBvZiBpbnRlcnZhbA0KPiB2YWx1ZXMgcXVhbGlmaWVzIGFzIHNvbWV0aGluZyB1c2Vm dWwgdG8gYmUgcmVjb3JkZWQgaW4gYW4gSUFOQSByZWdpc3RyeS4NCj4gDQo+IEkgZG8gbm90ICJv YmplY3QiLCBJIGp1c3Qgc2VlIGl0IGFzIHVubmVjZXNzYXJ5IG92ZXJoZWFkLCBzb21ldGhpbmcg dGhhdCBkb2VzDQo+IG5vdCBhZGQgdmFsdWUuIFRoZXNlIGlzIG5vdCBhIG5hbWVzcGFjZSBvZiBk aWFnIGNvZGVzIG9yIGF1dGggdHlwZXMuIEkgc2VlDQo+IG5vIGhhcm0gKG90aGVyIHRoYW4gYnVz eXdvcmspIGhlbmNlIG5vdCAib2JqZWN0aW5nIi4NCj4gDQo+IERvIHlvdSBrbm93IG9mIGEgc2lt aWxhciBJQU5BIHJlZ2lzdHJ5PyBUaGUgY2FzZXMgSSBjYW4gdGhpbmsgb2Ygb2Ygc3VnZ2VzdGVk DQo+IHByb3RvY29sIHRpbWVycy9wZXJpb2RzIGFyZSAqbm90KiBtYW5hZ2VkIGJ5IElBTkEuDQo+ IA0KPiBUaGFua3MsDQo+IA0KPiBUaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLg0KPiBF eGN1emUgdHlwb2ZyYXBoaWNhayBlcnJvd3MNCj4gDQo+ID4gT24gQXByIDEwLCAyMDE0LCBhdCA2 OjQwIEFNLCAiQWxleGFuZGVyIFZhaW5zaHRlaW4iDQo+IDxBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBDYXJsb3MsDQo+ID4gTG90cyBvZiB0aGFua3Mg Zm9yIGEgcHJvbXB0IGFuZCBkZXRhaWxlZCByZXNwb25zZS4NCj4gPg0KPiA+IEkgZnVsbHkgYWdy ZWUgd2l0aCB5b3UgdGhhdCAiaXQgY2FuIGJlIGRvbmUiIGRvZXMgbm90IG1lYW4gIml0IHNob3Vs ZCBiZQ0KPiBkb25lIi4gwqBXaGF0IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBzYXkgaXMgdGhhdCwg YXQgbGVhc3QgaW4gdGhpcyBjYXNlIHdlIGFyZSBub3QNCj4gZGVhbGluZyB3aXRoIHRoZSBzaXR1 YXRpb24gbGlrZSAidGhvdSBzaGFsdCBub3QuLi4iIGFuZCBub3QgZXZlbiB3aXRoICJ0aGVzZQ0K PiB0aGluZ3MgYXJlIHNpbXBseSBub3QgZG9uZSIuDQo+ID4gQW55IGFkdmFudGFnZXMgYW5kIGRp c2FkdmFudGFnZXMgYXJlICJpbiB0aGUgZXllIG9mIHRoZSBiZWhvbGRlciIgKGF0DQo+IGxlYXN0 IHVudGlsIHRoZSBkb2N1bWVudCBnb2VzIHRvIHRoZSBJRVNHOi0pLiBBbmQgd291bGQgYmUgbXVj aCBlYXNpZXIgZm9yDQo+IG1lIHRvIGFjY2VwdCB5b3VyIHBvc2l0aW9uIGlmIHlvdSBjb3VsZCBl eHBlY3Qgd2h5IHlvdSBvYmplY3QgdG8gcmVxdWVzdGluZw0KPiBhIG5ldyBJQU5BIHJlZ2lzdHJ5 LiBTbyBmYXIgdGhlIG1haW4gYXJndW1lbnQgSSBzZWUgaXMgdGhhdCB5b3UgKGFuZA0KPiBwcmVz dW1hYmx5IHRoZSBvdGhlciBhdXRob3JzKSBkbyBub3QgZXhwZWN0IG1hbnkgdXBkYXRlcyB0byB0 aGUgbGlzdCBvZg0KPiBjb21tb24gaW50ZXJ2YWxzLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiDC oMKgwqDCoMKgwqBTYXNoYQ0KPiA+IEVtYWlsOsKgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20NCj4gPiBNb2JpbGU6IDA1NC05MjY2MzAyDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWls dG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTAsIDIw MTQgMTowNSBQTQ0KPiA+PiBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gPj4gQ2M6IERvbmFs ZCBFYXN0bGFrZTsgTm9ibyBBa2l5YSAobm9ibyk7wqAgcnRnLWJmZEBpZXRmLm9yZw0KPiA+PiBT dWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIElBTkEgY29uc2lkZXJhdGlvbnM/ DQo+ID4+DQo+ID4+IEhpLCBTYXNoYSwNCj4gPj4NCj4gPj4gVGhhbmtzIGZvciB0aGUgZm9sbG93 LXVwLCBwbGVhc2Ugc2VlIGlubGluZS4NCj4gPj4NCj4gPj4gT24gQXByIDgsIDIwMTQsIGF0IDEy OjQwIEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiA+PiA8QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gQ2FybG9zIGFuZCBhbGwsDQo+ID4+PiBJ IGFtIG5vdCBzdXJlIEkgZm9sbG93IHRoZSBsb2dpYyBvZiB0aGUgZGVjaXNpb24uDQo+ID4+DQo+ ID4+IEkgZG8gbm90IHRoaW5rIHRoZXJlJ3MgYSBkZWNpc2lvbiB5ZXQsIG9ubHkgYSBkaXNjdXNz aW9uLg0KPiA+Pg0KPiA+Pj4gRG9uYWxkIGhhcyBhbHJlYWR5IGNvbW1lbnRlZCBvbiBzZXR0aW5n IGEgbmV3IHJlZ2lzdHJ5IGluIGFuDQo+ID4+IEluZm9ybWF0aW9uYWwgZG9jdW1lbnQ7IGFuZCBz YXlpbmcgdGhhdCBuZXcgdmFsdWVzIHdvdWxkIGJlIGFsd2F5cw0KPiA+PiBzZXQgdmlhIGEgbmV3 IGRyYWZ0IHNlZW1zIHRvIG1hcCB3ZWxsIHRvIG9uZSBvZiB0aGUgYWxyZWFkeSBleGlzdGluZyBJ QU5BDQo+IHBvbGljaWVzLg0KPiA+Pg0KPiA+PiBJdCBpcyBjbGVhcmx5IHBvc3NpYmxlIChhbmQg bWFueSB0aW1lcyBkZXNpcmFibGUpIHRvIGNyZWF0ZSBvciB1cGRhdGUNCj4gPj4gSUFOQSByZWdp c3RyaWVzIHdpdGggSW5mb3JtYXRpb25hbCBkb2N1bWVudHMuIEkndmUgZG9uZSBzbyBteXNlbGYg YXMNCj4gPj4gd2VsbC4gQnV0ICJpdCBjYW4gYmUgZG9uZSIgZG9lcyBub3QgaW1wbHkgIml0IHNo b3VsZCBiZSBkb25lIi4NCj4gPj4NCj4gPj4+IEJ1dCB3aGF0IHdvcnJpZXMgbWUgbW9zdCBpcyB0 aGUgZmFjdCB0aGF0IHdpdGhvdXQgYSBJQU5BIHJlZ2lzdHJ5DQo+ID4+PiB0aGVyZSB3aWxsDQo+ ID4+IGJlIG5vIHNpbmdsZSBwbGFjZSB3aGVyZSB0aGVzZSAiY29tbW9uIGludGVydmFsIHZhbHVl cyIgY291bGQgYmUNCj4gPj4gbG9va2VkIHVwIGJ5IGltcGxlbWVudGVycy4gSW5zdGVhZCwgdGhl eSB3b3VsZCBoYXZlIHRvIHRyYWNrIGENCj4gPj4gKHBvdGVudGlhbGx5IGxvbmcpIHNlcXVlbmNl IG9mIGRvY3VtZW50cyBpbiBvcmRlciB0byB1bmRlcnN0YW5kIHdoYXQNCj4gPj4gdGhleSBzaG91 bGQgdHJ5IHRvIGltcGxlbWVudCBhbmQgdGVzdC4NCj4gPj4NCj4gPj4gTXkgcGVyc3BlY3RpdmUg aXMgdGhhdCBhIHNldCBvZiBzdWdnZXN0ZWQgKG9yIHJlY29tbWVuZGVkKQ0KPiA+PiBpbnRlcnZh bC90aW1lciB2YWx1ZXMsIG9yIGRlZmF1bHQgdGltZXIgdmFsdWVzLCBpcyBub3Qgd2hhdCBhIG51 bWJlcnMNCj4gcmVnaXN0cnkgaXMgdXNlZCBmb3IuDQo+ID4+IE1hbnkgcHJvdG9jb2xzIHJlY29t bWVuZCB0aW1lciB2YWx1ZXMgKFRDUCwgTDJUUCwgZXRjKSwgYnV0IEkgZG8gbm90DQo+ID4+IGJl bGlldmUgdGhvc2UgYXJlIG1hbmFnZWQgYnkgSUFOQS4gVHJhY2tpbmcgYSBsaW5rZWQtbGlzdCBv ZiBVcGRhdGVkDQo+ID4+IFJGQ3MgaXMgbm90IGFsd2F5cyBmdW4sIGJ1dCBpbiB0aGlzIGNhc2Ug SSB3b3VsZCBub3QgZXhwZWN0IGEgbG9uZw0KPiA+PiBsaXN0IGRvY3VtZW50cy4gSXQgYWxzbyBz ZWVtcyB0byBtZSB0aGF0IHdoZW4gaW1wbGVtZW50aW5nIG9yDQo+ID4+IGNoZWNraW5nIGNvbXBs aWFuY2UgYWdhaW5zdCBhbiBSRkMsIHRoZSBmaXJzdCBwbGFjZSB0byBjaGVjayBpcyB0aGUgUkZD DQo+IGl0c2VsZiBhbmQgbm90IGFuIElBTkEgcmVnaXN0cnkuDQo+ID4+DQo+ID4+Pg0KPiA+Pj4g SSBjb3VsZCBhbHNvIHNheSB0aGF0IG9wZXJhdG9ycyBjb21tb25seSByZXF1ZXN0ICJjb21wbGlh bmNlIiB3aXRoDQo+ID4+IEluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIGluIFJGUHMgYW5kIFJGSXMg dGhleSBwdWJsaXNoLiAoU29tZWJvZHkgaGFzDQo+ID4+IHJlY2VudGx5IG1lbnRpb25lZCByZXF1 ZXN0cyB0byBjb21wbHkgd2l0aCBzb21lIEFwcmlsIDEgwqBSRkNzIGFzIHdlbGwNCj4gPj4gb24g dGhlIFJURy1ESVIgOi0pLkFuZCB3aGlsZSBzdWNoIGFuIGFyZ3VtZW50IHdvdWxkIG5vdCBob2xk IGluIHRoZQ0KPiA+PiBjb3VydCBvZiBsYXcsIEkgYW0gbm90IHN1cmUgd2Ugc2hvdWxkIHNpbXBs eSBpZ25vcmUgaXQuDQo+ID4+DQo+ID4+IFRoYXQncyBmaW5lIGJ1dCBvcnRob2dvbmFsIHRvIHRo aXMgZGlzY3Vzc2lvbi4NCj4gPj4NCj4gPj4gVGhhbmtzLA0KPiA+Pg0KPiA+PiBDYXJsb3MuDQo+ ID4+DQo+ID4+PiBNeSAyYywNCj4gPj4+IMKgwqDCoFNhc2hhDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBG cm9tOiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDYXJs b3MNCj4gPj4+IFBpZ25hdGFybw0KPiA+Pj4gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29t Pg0KPiA+Pj4gU2VudDogVHVlc2RheSwgQXByaWwgOCwgMjAxNCA2OjExIEFNDQo+ID4+PiBUbzog RG9uYWxkIEVhc3RsYWtlOyBOb2JvIEFraXlhIChub2JvKQ0KPiA+Pj4gQ2M6wqBydGctYmZkQGll dGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmQtaW50ZXJ2YWxzIElBTkEg Y29uc2lkZXJhdGlvbnM/DQo+ID4+Pg0KPiA+Pj4gRG9uYWxkLA0KPiA+Pj4NCj4gPj4+IEkgYWdy ZWUgd2l0aCB0aGlzIGFzIGEgZ2VuZXJhbCBzdGF0ZW1lbnQuIEFzIGl0IHBlcnRhaW5zIHRvIHRo ZQ0KPiA+Pj4gwrNDb21tb24gaW50ZXJ2YWwgdmFsdWVzwrIsIGl0IGRvZXMgbm90IGFwcGVhciB0 aGF0IGlzIHRoZSByb2xlIG9mIGFuDQo+ID4+PiBJQU5BIG51bWJlcnMgcmVnaXN0cnkuDQo+ID4+ Pg0KPiA+Pj4gVGhhbmtzLA0KPiA+Pj4NCj4gPj4+IENhcmxvcy4NCj4gPj4+DQo+ID4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogRG9uYWxkIEVhc3RsYWtlIDxkM2Uz ZTNAZ21haWwuY29tPg0KPiA+Pj4gRGF0ZTogTW9uZGF5LCBBcHJpbCA3LCAyMDE0IGF0IDExOjA1 IFBNDQo+ID4+PiBUbzogTm9ibyBBa2l5YSA8bm9ib0BjaXNjby5jb20+DQo+ID4+PiBDYzogInJ0 Zy1iZmRAaWV0Zi5vcmciIDxydGctYmZkQGlldGYub3JnPg0KPiA+Pj4gU3ViamVjdDogUmU6IGRy YWZ0LWlldGYtYmZkLWludGVydmFscyBJQU5BIGNvbnNpZGVyYXRpb25zPw0KPiA+Pj4NCj4gPj4+ PiBUaGVyZSBpcyBubyBwcm9ibGVtIHdpdGggaGF2aW5nIElBTkEgQ29uc2lkZXJhdGlvbnMgc2V0 dGluZyB1cCBhDQo+ID4+Pj4gcmVnaXN0cnkgb3IgdGhlIGxpa2UgaW4gYW4gSW5mb3JtYXRpb25h bCBkb2N1bWVudC4NCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcywNCj4gPj4+PiBEb25hbGQNCj4gPj4+ PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+Pj4+IERvbmFsZCBFLiBFYXN0bGFr ZSAzcmQgwqDCoCsxLTUwOC0zMzMtMjI3MCAoY2VsbCkNCj4gPj4+PiAxNTUgQmVhdmVyIFN0cmVl dCwgTWlsZm9yZCwgTUEgMDE3NTcgVVNBwqAgZDNlM2UzQGdtYWlsLmNvbQ0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+PiBPbiBNb24sIEFwciA3LCAyMDE0IGF0IDE6MDcgUE0sIE5vYm8gQWtpeWEgKG5v Ym8pIDxub2JvQGNpc2NvLmNvbT4NCj4gPj4gd3JvdGU6DQo+ID4+Pj4+IEhpIEJGRGVycywNCj4g Pj4+Pj4NCj4gPj4+Pj4gQXV0aG9ycyBvZiBkcmFmdC1pZXRmLWJmZC1pbnRlcnZhbHMgaGF2ZSBk aXNjdXNzZWQgYW5kIGNvbmNsdWRlZA0KPiA+Pj4+PiB0aGF0IGRlZmluZWQgImNvbW1vbiBpbnRl cnZhbHMgc2V0IiBkb2VzIF9ub3RfIG5lZWQgdG8gYmUNCj4gPj4+Pj4gbWFpbnRhaW5lZA0KPiA+ PiBieSBJQU5BLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBSZWFzb25zOg0KPiA+Pj4+PiAxLiBEb2N1bWVu dCBpcyBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0Lg0KPiA+Pj4+PiAyLiBBZGRpdGlvbnMgb2YgaW50 ZXJ2YWwocykgaW4gdGhlICJjb21tb24gaW50ZXJ2YWxzIHNldCIgc2hvdWxkDQo+ID4+Pj4+IGFu eXdheXMgYmUgZG9uZSB0aHJvdWdoIGEgbmV3IGRyYWZ0LCB3aGV0aGVyIG9yIG5vdA0KPiA+Pj4+ PiBkcmFmdC1pZXRmLWJmZC1pbnRlcnZhbHMgY3JlYXRlcyBhbiBJQU5BIHJlZ2lzdHJ5IGFuZCBk ZWZpbmVzDQo+ID4+Pj4+IGFsbG9jYXRpb24gcG9saWNpZXMgZm9yIGl0Lg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBEbyB5b3UgYWdyZWUgd2l0aCB0aGlzPw0KPiA+Pj4+PiBEbyB5b3Ugc2VlIGFueSBjb25j ZXJuIHdpdGggdGhpcz8NCj4gPj4+Pj4NCj4gPj4+Pj4gU2Vla2luZyBvcGluaW9ucy9jb21tZW50 cyBmcm9tIGZvbGtzIG9uIHRoaXMgbWF0dGVyLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MsDQo+ ID4+Pj4+IE5vYm8sIE1hcmMsIEdyZWcNCj4gPg0KPiANCj4gDQo= From nobody Sun Apr 13 16:05:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56031A0250 for ; Sun, 13 Apr 2014 16:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.874 X-Spam-Level: X-Spam-Status: No, score=-112.874 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5wB3SQGPPJC for ; Sun, 13 Apr 2014 16:05:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE5C1A0241 for ; Sun, 13 Apr 2014 16:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8522; q=dns/txt; s=iport; t=1397430338; x=1398639938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5zjdFXJsCoDJfhZJPnQpGIXEqAIvoMtcVD755lHoT3E=; b=dBk4nDzf0Y/U/E1ld2aZ6DKhwM+3alORHuyudITkPBMkBsCZpV74u4tS nw5M6koqAB6VXaeUmja6tzGGdxpgTrvgqOlFDKmVCwyVZ8yOa5lh9HRF0 AYncVqwDwnbHyhdAj1bpLaPbQ34zBIxoLHgaXm88N3YaHzGb/y+LkaApS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAHcXS1OtJA2L/2dsb2JhbABZgmUhgRLDF4EaFnSCJQEBAQMBOj8MBAIBCBEEAQELFAkHMhQJCAEBBAENBQiHbAgBymQXjgwRAQcYMQcGgx6BFAEDlHSWMIMxgWoIFyI X-IronPort-AV: E=Sophos;i="4.97,853,1389744000"; d="scan'208";a="317431158" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 13 Apr 2014 23:05:37 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3DN5b1d023291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Apr 2014 23:05:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Sun, 13 Apr 2014 18:05:37 -0500 From: "Nobo Akiya (nobo)" To: "adrian@olddog.co.uk" , "draft-ietf-bfd-mib.all@tools.ietf.org" Subject: RE: AD review of draft-ietf-bfd-mib Thread-Topic: AD review of draft-ietf-bfd-mib Thread-Index: Ac8FX0xMV0n63iAxRmuydGul4CdnwxSC5hAQ Date: Sun, 13 Apr 2014 23:05:36 +0000 Message-ID: References: <075e01cf055f$77a1d400$66e57c00$@olddog.co.uk> In-Reply-To: <075e01cf055f$77a1d400$66e57c00$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FNqixgmxJDzpT796tSP-C437YZg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 23:05:43 -0000 Hi Adrian, Thank you so much for thorough review of this document! Tom and I are working on the changes with help from Jeff, almost there. Please see comments/reply in-line. > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian Farre= l > Sent: Monday, December 30, 2013 8:03 AM > To: draft-ietf-bfd-mib.all@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: AD review of draft-ietf-bfd-mib >=20 > Hi authors of draft-ietf-bfd-mib, >=20 > I have done my usual AD review after receiving a publication request. > The purpose of the review is to catch issues that would show up during IE= TF > last call or IESG review and so save the reviewers some time and get the > quality up to a level that is acceptable. >=20 > This document represents a lot of work: thank you. The issues I have foun= d > are relatively small. Some of them take the form of questions and you can > answer these with email rather than feeling compelled to make > documentation changes. Furthermore, all of the issues are open for > discussion. >=20 > I will put the document into "Revised I-D" state and wait to hear back fr= om > you. >=20 > Thanks, > Adrian >=20 > =3D=3D=3D >=20 > You'll obviously want to make updates to accommodate changes to draft- > ietf-bfd-tc-mib ACK. >=20 > --- >=20 > Tom may want to change his coordinates. Done. >=20 > --- >=20 > Could you swap sections 1 and 2 so that the document starts with the > Introduction. Done. >=20 > --- >=20 > Section 2 >=20 > s/an portion/a portion/ Thanks for catching this. Done. >=20 > --- >=20 > Section 4.4 >=20 > I don't think the table maps a discriminator to a TC. Maybe it maps the > discriminator to the session or the session index or something. >=20 > The same thing shows up in some of the Description clauses, for example, > bfdSessDiscMapTable Section 4.4 updated. >=20 > --- >=20 > Similarly 4.5 Section 4.5 updated. >=20 > --- >=20 > It is nice if you name the RFCs in comments next to the import clauses. That's true. Added. >=20 > --- >=20 > If I am creating an entry in bfdSessTable (and it seems that I can since = most > of the objects are read-create) how do I know what value to pick for > bfdSessIndex? >=20 > A way to handle this is through a "next available index" global object. Good point. Added bfdSessIndexNext. >=20 > --- >=20 > bfdAdminStatus is ambiguous! > Does setting bfdSessAdminStatus to "start" mean that the session is up or > only that the implementation will attempt to bring it up? > The normal approach is to have adminStatus described as "the desired > operational status" and a separate object reports the actual operStatus. > Since you have bfdSessOperMode, I think this is your intention. Right. Added bfdOperStatus and bfdSessOperStatus. >=20 > --- >=20 > bfdSessState and bfdSessRemoteHeardFlag are read-only. What does it > mean to have default values? Good point. Removed DEFVAL from both. >=20 > --- >=20 > Doesn't bfdSessMultipointFlag need a reference to the document that > defines multipoint BFD? If so, doesn't that create a normative reference > gate for this MIB module? That means you either take multipoint out or yo= u > will have to wait until it completes the process. Multipoint (M) flag is something defined in RFC5880 (BFD base spec), so thi= s is ok. IANAbfdSessTypeTC in the TC MIB, however, referenced the multipoin= t draft. IANAbfdSessTypeTC used to have MultipointHead and MultipointTail. = We have removed MultipointHead and MultipointTail from IANAbfdSessTypeTC no= w. Multipoint draft should ask to add new session types in the IANAbfdSessT= ypeTC registry. Updated drafts no longer have any normative reference to multipoint draft. >=20 > --- >=20 > You appear to have two mechanisms to turn off GTSM >=20 > bfdSessGTSM OBJECT-TYPE > SYNTAX TruthValue > DESCRIPTION > "Setting the value of this object to true(1) will enable GTSM > protection of the BFD session. > ... So presumably setting it to false will disable GTSM. But... >=20 >=20 > bfdSessGTSMTTL OBJECT-TYPE > SYNTAX Unsigned32 (0..255) > DESCRIPTION > The value of zero(0) indicates that > bfdSessGTSM is disabled." Good point. Description of bfdSessGTSMTTL updated. >=20 > --- >=20 > bfdSessAuthPresFlag has a default of false indicating that no authenticat= ion > is to be used. And bfdSessAuthenticationType has a default of -1 meaning > no authentication is in use. Doesn't that mean that the default for > bfdSessGTSM should be true and the default for bfdSessGTSMTTL should be > non-zero? Good catch. Changed default value of bfdSessGTSM to true, updated default v= alue for bfdSessGTSMTTL to 255 and added recommendation updating of this va= riable for multihop sessions in description for bfdSessGTSMTTL. >=20 > --- >=20 > Why don't objects like bfdSessDesiredMinTxInterval have default values? It is probably not correct to have any default values for objects for inter= vals and multiplier, as RFC5880 does not recommend any. These objects are b= fdSessDesiredMinTxInterval, bfdSessReqMinRxInterval, bfdSessReqMinEchoRxInt= erval and bfdSessDetectMult. We believe it is correct for them to not have = default values, but let implementations add their own default values. >=20 > --- >=20 > Shouldn't the default for bfdSessAuthenticationType be noAuthentication > not -1? Done. >=20 > --- >=20 > I am unsure about how the three objects for authentication work. >=20 > bfdSessAuthenticationType and bfdSessAuthenticationKeyID say that they > must be -1 if bfdSessAuthPresFlag is false. >=20 > Now, suppose I want to turn on authentication. I want to set > bfdSessAuthPresFlag to true, but if I do, the settings of > bfdSessAuthenticationType and bfdSessAuthenticationKeyID are bogus. > But if I want to set bfdSessAuthenticationType and > bfdSessAuthenticationKeyID to real values in preparation to setting > bfdSessAuthPresFlag to true then I will have broken the rule. >=20 > The only option appears to set all three objects at once (which is possib= le > only depending on implementation). Right. Removed following statement from bfdSessAuthenticationKeyID. When bfdSessAuthPresFlag is false(2), then the value of this object MUST be -1. =20 Now implementations can update bfdSessAuthenticationType, bfdSessAuthentica= tionKeyID and bfdSessAuthenticationKey, and then enable authentication by s= etting bfdSessAuthPresFlag to true. >=20 > --- >=20 > I'm surprised that entries in bfdSessDiscMapTable are writeable. > That is to say, that bfdSessDiscMapStorageType and > bfdSessDiscMapRowStatus exist and are writeable. Surely this table is > automatic and entries an artifice of entries in bfdSessTable. >=20 > Why would you want an entry in this table to have a different storage typ= e > or row status from those in bfdSessTable? >=20 > What does it mean that those two objects are creatable? Does it mean that > you can create an entry in this table without knowing the value of > bfdSessDiscMapIndex which is automatic? >=20 > Same questions about bfdSessIpMapTable Good point. bfdSessDiscMapTable and bfdSessIpMapTable are indeed lookup tab= les. Googled on how to make these tables read-only. I believe correct thing= to do remove RowStatus and StorageType objects from the two tables. Is thi= s correct? >=20 > --- >=20 > The Security section says... >=20 > The bfdSessAuthenticationType, bfdSessAuthenticationKeyID, and > bfdSessAuthenticationKey objects hold security methods and associated > security keys of BFD sessions. These objects SHOULD be considered > highly sensitive objects. In order for these sensitive information > from being improperly accessed, implementers MAY wish to disallow > read and create access to these objects. >=20 > You don't want to prevent write access as well? Fixed. >=20 > But note that preventing read access is pretty much not having the object= . > So why *do* you have the objects and then suggest not providing any acces= s > to them? We believe that this MIB should have these objects defined in case implemen= tations do want to allow access to some of these objects. -Nobo, on behalf of authors From nobody Sun Apr 13 16:07:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA271A0251 for ; Sun, 13 Apr 2014 16:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he7uyoWKWpgD for ; Sun, 13 Apr 2014 16:07:42 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id F311B1A0250 for ; Sun, 13 Apr 2014 16:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2579; q=dns/txt; s=iport; t=1397430460; x=1398640060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Uccr/r0h/k1qEGjaiKelHVft/7DASZzR70/PJYJd13I=; b=moQieGaIgB5kGe0oKkxkTvNlS/RBvdqgFeecD0zS1vPmYmWtiSXt2OQm zOiZqbpBX8ECETyUIBO6s4uPPRYEQBphWMiSnAwrE+w9I5dELeH5S/Otf ga7W1xfl/KZp6bGwcdsT6Tr+yfCHPTHGSATceoLYxIxCMJqc5EAap0lF9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAO8XS1OtJV2d/2dsb2JhbABZgmUhgRLDF4EaFnSCJQEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAQEEAQ0FCId0AcpWF44nFjEHBoMegRQBA6skgzGCKw X-IronPort-AV: E=Sophos;i="4.97,853,1389744000"; d="scan'208";a="35458611" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 13 Apr 2014 23:07:39 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3DN7daw007492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Apr 2014 23:07:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sun, 13 Apr 2014 18:07:39 -0500 From: "Nobo Akiya (nobo)" To: "adrian@olddog.co.uk" , "draft-ietf-bfd-tc-mib.all@tools.ietf.org" Subject: RE: AD review of draft-ietf-bfd-tc-mib Thread-Topic: AD review of draft-ietf-bfd-tc-mib Thread-Index: Ac8E0GpllEYZRDVjQZitSOPA4qtRtBSnHmpA Date: Sun, 13 Apr 2014 23:07:37 +0000 Message-ID: References: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> In-Reply-To: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PuRAbnyRNo5vX9cYrFGQIeT3Z4Y Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 23:07:44 -0000 Hi Adrian, Also thank you so much for thorough review of this document! Please see comments/reply in-line. > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian Farre= l > Sent: Sunday, December 29, 2013 2:59 PM > To: draft-ietf-bfd-tc-mib.all@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: AD review of draft-ietf-bfd-tc-mib >=20 > Hi authors of draft-ietf-bfd-tc-mib, >=20 > I am doing my AD review of this document having received the publication > request. The purpose of my review is to clear up any issues that might > otherwise show up during IETF last call or IESG review. >=20 > During my review I have found a number of minor issues with the MIB > module. I don't think any substantially change the definitions, but I do = think > that some editorial work is needed. I believe there will be knock- on > editorial changes to draft-ietf-bfd-mib, but nothing of substance that wi= ll > impact that document. >=20 > I will put this document into "Revised I-D State", but I would be happy t= o > discuss any of these points if you think that changes are not needed. >=20 > Thanks for the work. >=20 > Adrian >=20 > =3D=3D=3D >=20 > Tom may want to update his coordinates. Done. >=20 > --- >=20 > I think the Abstract should note that the TCs defined here are maintained= by > IANA as this is an important feature. >=20 > BUT... >=20 > I don't see why all of these TCs are in an IANA module. It seems that a > number of them would not be updated by IANA upon the allocation of new > protocol code points. I believe the following should be moved to their ow= n > module and out of the IANA module... >=20 > IANAbfdSessIndexTC > IANAbfdIntervalTC > IANAbfdMultiplierTC > IANAbfdCtrlDestPortNumberTC (unless you propose to define explicit > enumerations) IANAbfdCtrlSourcePortNumberTC >=20 > I am suspicious of some of the other TCs as well. Really, an IANA module > should be used for TCs that mirror registries. Do the other TCs actually > mirror registries? If so you should say which. If not, then you should > probably move them out of the IANA module as well. True. We have split them up into BFD TC and IANA maintained TC. >=20 > --- >=20 > Could you swap Sections 1 and 2 so that the document begins with the > Introduction. Done. >=20 > --- >=20 > A number of TCs could usefully have Reference clauses so that the meaning > of the TC is more clearly understood. Done. -Nobo, on behalf of authors From nobody Mon Apr 14 00:24:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CF41A0395 for ; Mon, 14 Apr 2014 00:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuIhTtrnFp6T for ; Mon, 14 Apr 2014 00:24:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 292611A0393 for ; Mon, 14 Apr 2014 00:24:37 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3E7OUPo028075; Mon, 14 Apr 2014 08:24:30 +0100 Received: from 950129200 ([149.254.186.186]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3E7OGWA027911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 08:24:26 +0100 From: "Adrian Farrel" To: "'Nobo Akiya \(nobo\)'" , References: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> In-Reply-To: Subject: RE: AD review of draft-ietf-bfd-tc-mib Date: Mon, 14 Apr 2014 08:24:11 +0100 Message-ID: <003401cf57b2$92d7dfd0$b8879f70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlDvm5h+j4+T5nMSyBexsZ2Ebe0gJDNywlm1Msm/A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20630.005 X-TM-AS-Result: No--1.587-10.0-31-10 X-imss-scan-details: No--1.587-10.0-31-10 X-TMASE-MatchedRID: 2yoavFRFKjGnykMun0J1wlu4M/xm4KZefS0Ip2eEHny+qryzYw2E8M4b ajgO0kgvvoLxXxVZN/E+Aoot6UqUmMRB0bsfrpPIx1FPlNAAmcBiSFGuzYbAOWS+Gyjjyoa9vkd u9xKcEY1xNz32CJzYYCXidVjAhEZBrX7cmKNisA4yqaEb8zSjj/QwfDO7YmjAFm3/b4o5bPM= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KcZmh-mWMY5imy-C6fdpuQKpKdY Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:24:40 -0000 Hi again, All changes look good. Thanks for the work, Adrian From nobody Mon Apr 14 00:25:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD491A039D for ; Mon, 14 Apr 2014 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ1UC_WBXhTx for ; Mon, 14 Apr 2014 00:24:42 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 85F741A038E for ; Mon, 14 Apr 2014 00:24:41 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3E7OZod028121; Mon, 14 Apr 2014 08:24:36 +0100 Received: from 950129200 ([149.254.186.186]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3E7OGWB027911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 08:24:31 +0100 From: "Adrian Farrel" To: "'Nobo Akiya \(nobo\)'" , References: <075e01cf055f$77a1d400$66e57c00$@olddog.co.uk> In-Reply-To: Subject: RE: AD review of draft-ietf-bfd-mib Date: Mon, 14 Apr 2014 08:24:11 +0100 Message-ID: <003501cf57b2$96037d40$c20a77c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFLPelnEXazNGcDPfYcozwKFCyU8QEOeGWinBBxjJA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20630.005 X-TM-AS-Result: No--9.602-10.0-31-10 X-imss-scan-details: No--9.602-10.0-31-10 X-TMASE-MatchedRID: O/y65JfDwwtm8SPGyjDNlZmug812qIbzVBDQSDMig9Ge9toQ6h6LE+uq uVIRgyCJk2W5BFQt9sLka8ZDruPolDgcoj/JqpGb3FqOVb7PDEIHSA1qABZYHlSOymiJfTYXZtB vVFKTdG0uKrGXQowld5s6sZ5vv7JIfGmUm/ExoKLmAId+2bAQwn0tCKdnhB58vqq8s2MNhPB9j2 GwzTE3vSq2rl3dzGQ1ksGjn0OSaiHE3ocrgiORg8VC06sGzB5svDT+TuEHgBUkXmHWzCq9KA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/wG_cd9Ez9Ii5xtWgSFTHYAxQieM Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:24:44 -0000 Hi Nobo, All looks good. Just an answer to one of your points.... > > I'm surprised that entries in bfdSessDiscMapTable are writeable. > > That is to say, that bfdSessDiscMapStorageType and > > bfdSessDiscMapRowStatus exist and are writeable. Surely this table is > > automatic and entries an artifice of entries in bfdSessTable. > > > > Why would you want an entry in this table to have a different storage type > > or row status from those in bfdSessTable? > > > > What does it mean that those two objects are creatable? Does it mean that > > you can create an entry in this table without knowing the value of > > bfdSessDiscMapIndex which is automatic? > > > > Same questions about bfdSessIpMapTable > > Good point. bfdSessDiscMapTable and bfdSessIpMapTable are indeed lookup > tables. Googled on how to make these tables read-only. I believe correct thing to > do remove RowStatus and StorageType objects from the two tables. Is this > correct? Wow! Google as a MIB-authoring tool ;-) Yes. Remove those objects. Looking forward to the next revision. Thanks, Adrian From nobody Mon Apr 14 02:21:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752331A0298 for ; Mon, 14 Apr 2014 02:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoIQq-3t4LOX for ; Mon, 14 Apr 2014 02:21:44 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1411A0106 for ; Mon, 14 Apr 2014 02:21:44 -0700 (PDT) Received: from [10.187.90.33] (mobile-198-228-199-026.mycingular.net [198.228.199.26]) by lucidvision.com (Postfix) with ESMTP id F26A42765102; Mon, 14 Apr 2014 05:21:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: AD review of draft-ietf-bfd-tc-mib From: Thomas Nadeau X-Mailer: iPhone Mail (11D167) In-Reply-To: <003401cf57b2$92d7dfd0$b8879f70$@olddog.co.uk> Date: Mon, 14 Apr 2014 05:21:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: <856FD83B-8D72-4EDB-A35F-F1B507F9C449@lucidvision.com> References: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> <003401cf57b2$92d7dfd0$b8879f70$@olddog.co.uk> To: "adrian@olddog.co.uk" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/t_VMrjQXgUV3JTq5J3ZK3jgDrdE Cc: "rtg-bfd@ietf.org" , "" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 09:21:47 -0000 Cool. Thx for looking. Tom > On Apr 14, 2014, at 3:24 AM, "Adrian Farrel" wrote: > > Hi again, > > All changes look good. > > Thanks for the work, > Adrian > > From nobody Mon Apr 14 06:07:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D961A0441; Mon, 14 Apr 2014 06:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xYWsyfqy1Ii; Mon, 14 Apr 2014 06:07:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5C1A0468; Mon, 14 Apr 2014 06:07:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-tc-mib-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140414130734.32763.73128.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 06:07:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/h9CjKzKF3aIfuR7jEi9a67X1kAs Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:07:48 -0000 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 : Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-05.txt Pages : 12 Date : 2014-04-14 Abstract: This draft defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-tc-mib-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 14 06:09:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55341A03EC; Mon, 14 Apr 2014 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQVL4rmjftmL; Mon, 14 Apr 2014 06:09:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3E1A0469; Mon, 14 Apr 2014 06:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-17.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140414130900.32755.20014.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 06:09:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZtKOyop3INlesJsD9P0JICuJ6HM Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:09:22 -0000 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 Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-17.txt Pages : 37 Date : 2014-04-14 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 14 06:48:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637441A01D4 for ; Mon, 14 Apr 2014 06:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz5U5NtGEgCP for ; Mon, 14 Apr 2014 06:48:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 061241A010B for ; Mon, 14 Apr 2014 06:48:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8B7ADC263; Mon, 14 Apr 2014 09:47:59 -0400 (EDT) Date: Mon, 14 Apr 2014 09:47:59 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [nobo@cisco.com: BFD MIB revisions published] Message-ID: <20140414134759.GB13919@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5rURvR0Q9FbJwra0YLDBxAhKOhQ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2014 13:48:06 -0000 Working Group, As part of working through AD comments for the MIB (which passed WGLC and is in the path for publication), some concerns were addressed. Please take a look at the resulting changes. -- Jeff (wearing the document shepherd hat) ----- Forwarded message from "Nobo Akiya (nobo)" ----- Date: Mon, 14 Apr 2014 13:15:32 +0000 From: "Nobo Akiya (nobo)" To: "adrian@olddog.co.uk" , "Jeffrey Haas (jhaas@pfrc.org)" CC: Thomas Nadeau , "Zafar Ali (zali)" , "Jeff Haas (jhaas@juniper.net)" Subject: BFD MIB revisions published Dear AD and Shepherd, BFD MIB revisions (base and TC) have been published. Adrian, thank you for great comments, quality of the document jumped up few notches! Jeff, thank you for your guidance and multiple reviews along the way! URL: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-17.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ Htmlized: http://tools.ietf.org/html/draft-ietf-bfd-mib-17 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-17 URL: http://www.ietf.org/internet-drafts/draft-ietf-bfd-tc-mib-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ Htmlized: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-tc-mib-05 Thanks, Nobo, on behalf of authors ----- End forwarded message ----- From nobody Mon Apr 14 07:26:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71511A0491 for ; Mon, 14 Apr 2014 07:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXjLYLcbs0tm for ; Mon, 14 Apr 2014 07:26:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 281741A048D for ; Mon, 14 Apr 2014 07:26:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B08B5C263; Mon, 14 Apr 2014 10:26:03 -0400 (EDT) Date: Mon, 14 Apr 2014 10:26:03 -0400 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: [nobo@cisco.com: BFD MIB revisions published] Message-ID: <20140414142603.GC13919@pfrc> References: <20140414134759.GB13919@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140414134759.GB13919@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/47Z3jH1u0rX-6zphy-mxhV1cyLo Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:26:13 -0000 On Mon, Apr 14, 2014 at 09:47:59AM -0400, Jeffrey Haas wrote: > Working Group, > > As part of working through AD comments for the MIB (which passed WGLC and is > in the path for publication), some concerns were addressed. > > Please take a look at the resulting changes. Note that the draft has been advanced to IETF last call. Review comments to the IETF mailing list, please. -- Jeff From nobody Mon Apr 14 09:17:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1251A0668; Mon, 14 Apr 2014 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxDUgzo5WTe0; Mon, 14 Apr 2014 09:17:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2C71A058E; Mon, 14 Apr 2014 09:17:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (BFD Management Information Base) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140414161702.31128.34205.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 09:17:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OjMmXhJeIdvyseFnO_Kk4CzoI5M Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:17:09 -0000 The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'BFD Management Information Base' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 14 09:20:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA251A02CD; Mon, 14 Apr 2014 09:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_BkRJU2PGhP; Mon, 14 Apr 2014 09:20:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 046DC1A04C1; Mon, 14 Apr 2014 09:20:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140414162043.21310.13192.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 09:20:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZMnf-P6oDxcZFKbTvjcZkhVcgvo Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:20:55 -0000 The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 14 10:23:25 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2491A069E for ; Mon, 14 Apr 2014 10:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.373 X-Spam-Level: X-Spam-Status: No, score=-113.373 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sn1AtPi2aOy for ; Mon, 14 Apr 2014 10:23:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D37441A04C1 for ; Mon, 14 Apr 2014 10:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2961; q=dns/txt; s=iport; t=1397496199; x=1398705799; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=y2IZmxuQ7wlxMKrkv8VHhZrrjMrB+vrKvvcKbWe+KYI=; b=lEgNSr4sQ/lJCtccOKfBX0+d7Klpt4qqFUo9YQmrytBwaEeIjlChgK5D SdD6YlKfpaJofg7TBwdD2zlMVNuAgYSycucKwxl6s6yLq7cBbkFv37vkV 9EF44OYR0CZyogs1wdJrAydIAGrvqISETloPTMEeFiYW9Snn+0Wq8wvr0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMwYTFOtJA2H/2dsb2JhbABZgmUhgRLDJoEkFnSCJwEEOj8SASoUQiYBBA4Nh3QBy2wXiUaEdzGDK4EUBJR0ljCDMYIr X-IronPort-AV: E=Sophos;i="4.97,858,1389744000"; d="scan'208";a="314585593" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 14 Apr 2014 17:23:19 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3EHNJgh007871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 17:23:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 12:23:18 -0500 From: "Nobo Akiya (nobo)" To: "draft-ietf-bfd-generic-crypto-auth@tools.ietf.org" Subject: Comments on draft-ietf-bfd-generic-crypto-auth Thread-Topic: Comments on draft-ietf-bfd-generic-crypto-auth Thread-Index: Ac9YBPKPaFZoutd+S+2hfnRg0bnzxw== Date: Mon, 14 Apr 2014 17:23:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/tN5zscgDFb3hTtXSF3bJSBu1LVE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:23:23 -0000 Hi Authors, I have reviewed your draft (draft-ietf-bfd-generic-crypto-auth ), comments = below. Since document is nearing expiration, perhaps you can address some of these= comments and re-publish? (1) Abstract s/arbitary/arbitrary/ (2) Section 2 Before listing "Not Before Time" and "Not After Time", it'll be great if th= e document can provide some words to better transition from previous paragr= aph.=20 (3) Section 3.3 [snip] The device MUST fill the Auth Type and the Auth Len fields before the authentication data is computed. The Sequence Number field MUST be set to bfd.XmitAuthSeq. [snip] The paragraph is slightly confusing wrt whether Sequence Number field need = to be set before or after authentication data is computed. It'll be good to= clarify this. (4) Section 3.4, second paragraph [snip] If the Authentication Present (A) bit is set in the packet header and the receiver will try to find a appropriate BFD SA in its local key table to process the packet. [snip] I believe you meant to say: If the Authentication Present (A) bit is set in the packet header and Auth Type is TBD1 or TBD2, the receiver is to find an appropriate BFD SA in its local key table to process the packet. See below for usage of TBD1/TBD2. (5) Section 3.4, fourth paragraph Is it better to say "unsigned 64 bit circular number space" here, or keep i= t as "unsigned 32 bit circular number space"? If latter, then the document = should clarify that it's low order 32 bits. (6) Section 3.4, sixth paragraph [snip] In such a case, an error event SHOULD be logged. [snip] Such log could become DoS attack point? Rate limiting of such log is outsid= e the scope of this document, but it could be beneficial to explain this in= the Security Considerations section ... optional comment though. (7) IANA Considerations Indeed values 6 and 7 are next, but it's technically not correct to just us= e them [yet]. Can we use TBD1 and TBD2? If someone is implementing and early allocation i= s required, then we can do that. Also it'll be beneficial for this section to clearly describe what is neede= d from where. Maybe something like: IANA is requested to assign two authentication types from the "BFD Authentication Types" sub-registry within the "Bidirectional Forwarding Detection (BFD) Parameters" registry. Address BFD Authentication Type Name Reference ------- --------------------------------------- ------------- TBD1 Cryptographic Authentication this document TBD2 Meticulous Cryptographic Authentication this document (8) Security Considerations s/reestablishing/re-establishing/ (9) References RFC5880 should be a normative reference instead of informative, as document= is even referencing a variable from RFC5880 (ex: bfd.XmitAuthSeq). -Nobo From nobody Mon Apr 14 15:21:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8791A0764 for ; Mon, 14 Apr 2014 15:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxyTDI0Vkoor for ; Mon, 14 Apr 2014 15:21:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 109FD1A0687 for ; Mon, 14 Apr 2014 15:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1401; q=dns/txt; s=iport; t=1397514085; x=1398723685; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=DgKKU+OGqI+Z5ysRFmAJfHP1m3ijgss3zK648ZX54sg=; b=VXJmcv+gdOMGhcyioCfptH6MKl7EJiGKTBOr/KJroTwKRd4s5RII9301 2gwwgtqTZarLrzELR+/ls5BVAnc0H+s5ciuLrnA5W5BxJs9CQSZmrh92z c2LiAs709Cs0PkxksiRtVaF8ypBJeldSfIKN5eumPPXkRChl51vLJzZQU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAOZeTFOtJV2b/2dsb2JhbABYgmUhgRLDLYEnFnSCJwEEOj8SASoUQiYBBA4Nh3QBzBMXjj0xgyuBFASrJIMxgis X-IronPort-AV: E=Sophos;i="4.97,860,1389744000"; d="scan'208";a="317685414" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 14 Apr 2014 22:21:24 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3EMLO9t013926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 22:21:24 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 17:21:23 -0500 From: "Nobo Akiya (nobo)" To: "draft-ietf-bfd-hmac-sha@tools.ietf.org" Subject: Comments on draft-ietf-bfd-hmac-sha Thread-Topic: Comments on draft-ietf-bfd-hmac-sha Thread-Index: Ac9YIlbosz55+Nx5RgqmDHvfyuFe+g== Date: Mon, 14 Apr 2014 22:21:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/wH1Ehz2uKMdrIt9nw7f9oSuWHKE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:21:31 -0000 Hi Authors, I have reviewed your draft (draft-ietf-bfd-hmac-sha), comments below. Since document is nearing expiration, perhaps you can address some of these= comments and re-publish? (1) Section 3, couple of places s/avaliable/available/g (2) Section 2, 3, 4 I see that most texts from sections 3 & 4 overlaps with texts in draft-ietf= -bfd-generic-crypto-auth. Are texts in section 2 something required for BFD= to use HMAC-SHA (i.e. required to interop)? I'm just wondering why this i= s a standard-track document, i.e. with draft-ietf-bfd-generic-crypto-auth a= vailable, whether or not we need to write standard-track draft for every au= thentication that BFD need to use going forward. Maybe I over-looked someth= ing ... (3) Section 2 Missing '.' chars. [old] B is the block size of H, measured in octets rather than bits. Note that B is the internal block size, not the hash size. For SHA-1 and SHA-256: B =3D=3D 64 For SHA-384 and SHA-512: B =3D=3D 128 L is the leng= th of the hash, measured in octets rather than bits. [new] B is the block size of H, measured in octets rather than bits. Note that B is the internal block size, not the hash size. For SHA-1 and SHA-256: B =3D=3D 64. For SHA-384 and SHA-512: B =3D=3D 128. L is the le= ngth of the hash, measured in octets rather than bits. [snip] -Nobo From nobody Mon Apr 14 19:59:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1CA1A0310 for ; Mon, 14 Apr 2014 19:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2BJKFkf61Tf for ; Mon, 14 Apr 2014 19:59:09 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1C1A04E8 for ; Mon, 14 Apr 2014 19:59:01 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s3F2wt3R023413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Apr 2014 21:58:55 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s3F2wr4G001940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 22:58:53 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 14 Apr 2014 22:58:53 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Tue, 15 Apr 2014 10:58:52 +0800 From: "Bhatia, Manav (Manav)" To: "Nobo Akiya (nobo)" , "draft-ietf-bfd-hmac-sha@tools.ietf.org" Subject: RE: Comments on draft-ietf-bfd-hmac-sha Thread-Topic: Comments on draft-ietf-bfd-hmac-sha Thread-Index: Ac9YIlbosz55+Nx5RgqmDHvfyuFe+gAMyFQw Date: Tue, 15 Apr 2014 02:58:51 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5EC50D@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QaVuR13cd7qvmIYUIlNiPUmRFwI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 02:59:11 -0000 Hi Nobo, Thanks for the review. We'll be addressing them all in the next revision. One quick comment. It's a standard track document because vendors have to implement the crypto= -mathematics given in this document down to the last dot (if there ever was= such a phrase) to come up with an interoperable implementation. The crypto-maths here includes the notion of an Additional Pad (Apad) which= increases the security, and isnt defined in the regular NIST documents tha= t we refer to in this draft. How it increases the security is a long painfu= l discussion best done in a pub when everything around is us already fuzzy = and blurred. Cheers, Manav > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Tuesday, April 15, 2014 3:51 AM > To: draft-ietf-bfd-hmac-sha@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: Comments on draft-ietf-bfd-hmac-sha >=20 > Hi Authors, >=20 > I have reviewed your draft (draft-ietf-bfd-hmac-sha), comments below. > Since document is nearing expiration, perhaps you can address some of > these comments and re-publish? >=20 >=20 > (1) Section 3, couple of places >=20 > s/avaliable/available/g >=20 >=20 > (2) Section 2, 3, 4 >=20 > I see that most texts from sections 3 & 4 overlaps with texts in draft- > ietf-bfd-generic-crypto-auth. Are texts in section 2 something required > for BFD to use HMAC-SHA (i.e. required to interop)? I'm just wondering > why this is a standard-track document, i.e. with draft-ietf-bfd- > generic-crypto-auth available, whether or not we need to write > standard-track draft for every authentication that BFD need to use > going forward. Maybe I over-looked something ... >=20 >=20 > (3) Section 2 >=20 > Missing '.' chars. >=20 > [old] > B is the block size of H, measured in octets rather than bits. Note > that B is the internal block size, not the hash size. For SHA-1 and > SHA-256: B =3D=3D 64 For SHA-384 and SHA-512: B =3D=3D 128 L is the le= ngth > of > the hash, measured in octets rather than bits. > [new] > B is the block size of H, measured in octets rather than bits. Note > that B is the internal block size, not the hash size. For SHA-1 and > SHA-256: B =3D=3D 64. For SHA-384 and SHA-512: B =3D=3D 128. L is the = length > of the hash, measured in octets rather than bits. > [snip] >=20 >=20 > -Nobo From nobody Tue Apr 15 05:36:23 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFF01A04CD for ; Tue, 15 Apr 2014 05:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RUfoFFI1Pi1 for ; Tue, 15 Apr 2014 05:36:18 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2F01F1A069B for ; Tue, 15 Apr 2014 05:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2913; q=dns/txt; s=iport; t=1397565373; x=1398774973; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=btHCrXP87cFjvQMXj5oaWFfebD8OkoNNC4243VWHx60=; b=DBjzJaCJT/odin4TWvHPQOKwuOFnOFIdQTeHU715dtW8FZDAPuZptgKq VHbetHGDTTiZeE33+DXg3gu8dARu7Xpl+oY1UYsXjaOcyG+GVSZk5Q5ew FcGprTc/7QzVZ8TGM96y/AzhJ2LEAnPxXqvkVkxp+BWdV2U7YHTmxVxQj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJUmTVOtJA2G/2dsb2JhbABZgmUhgRLDKIEiFnSCJQEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAQEEAQ0FCId0Acw8F44yMQcGgx6BFAEDqyeDMYIr X-IronPort-AV: E=Sophos;i="4.97,864,1389744000"; d="scan'208";a="35951704" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP; 15 Apr 2014 12:36:12 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3FCaCgQ013891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 12:36:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 15 Apr 2014 07:36:12 -0500 From: "Nobo Akiya (nobo)" To: "Bhatia, Manav (Manav)" , "draft-ietf-bfd-hmac-sha@tools.ietf.org" Subject: RE: Comments on draft-ietf-bfd-hmac-sha Thread-Topic: Comments on draft-ietf-bfd-hmac-sha Thread-Index: Ac9YIlbosz55+Nx5RgqmDHvfyuFe+gAMyFQwABRuaFA= Date: Tue, 15 Apr 2014 12:36:11 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C32E5EC50D@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E5EC50D@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/3q98HYDE5VrlOp2VgbpeeC85FWA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 12:36:22 -0000 Hi Manav, Ah I see, thanks for clarification! -Nobo > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Monday, April 14, 2014 10:59 PM > To: Nobo Akiya (nobo); draft-ietf-bfd-hmac-sha@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: RE: Comments on draft-ietf-bfd-hmac-sha >=20 > Hi Nobo, >=20 > Thanks for the review. We'll be addressing them all in the next revision. >=20 > One quick comment. >=20 > It's a standard track document because vendors have to implement the > crypto-mathematics given in this document down to the last dot (if there > ever was such a phrase) to come up with an interoperable implementation. >=20 > The crypto-maths here includes the notion of an Additional Pad (Apad) > which increases the security, and isnt defined in the regular NIST > documents that we refer to in this draft. How it increases the security i= s a > long painful discussion best done in a pub when everything around is us > already fuzzy and blurred. >=20 > Cheers, Manav >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Tuesday, April 15, 2014 3:51 AM > > To: draft-ietf-bfd-hmac-sha@tools.ietf.org > > Cc: rtg-bfd@ietf.org > > Subject: Comments on draft-ietf-bfd-hmac-sha > > > > Hi Authors, > > > > I have reviewed your draft (draft-ietf-bfd-hmac-sha), comments below. > > Since document is nearing expiration, perhaps you can address some of > > these comments and re-publish? > > > > > > (1) Section 3, couple of places > > > > s/avaliable/available/g > > > > > > (2) Section 2, 3, 4 > > > > I see that most texts from sections 3 & 4 overlaps with texts in > > draft- ietf-bfd-generic-crypto-auth. Are texts in section 2 something > > required for BFD to use HMAC-SHA (i.e. required to interop)? I'm just > > wondering why this is a standard-track document, i.e. with > > draft-ietf-bfd- generic-crypto-auth available, whether or not we need > > to write standard-track draft for every authentication that BFD need > > to use going forward. Maybe I over-looked something ... > > > > > > (3) Section 2 > > > > Missing '.' chars. > > > > [old] > > B is the block size of H, measured in octets rather than bits. Note > > that B is the internal block size, not the hash size. For SHA-1 and > > SHA-256: B =3D=3D 64 For SHA-384 and SHA-512: B =3D=3D 128 L is the = length > > of > > the hash, measured in octets rather than bits. > > [new] > > B is the block size of H, measured in octets rather than bits. Note > > that B is the internal block size, not the hash size. For SHA-1 and > > SHA-256: B =3D=3D 64. For SHA-384 and SHA-512: B =3D=3D 128. L is th= e length > > of the hash, measured in octets rather than bits. > > [snip] > > > > > > -Nobo From nobody Wed Apr 16 23:18:25 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438AE1A03FE for ; Wed, 16 Apr 2014 23:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWU7aBut53XY for ; Wed, 16 Apr 2014 23:18:22 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 95A021A03D6 for ; Wed, 16 Apr 2014 23:18:22 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so8639yho.4 for ; Wed, 16 Apr 2014 23:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qvgjvLbmFmYvReVoUC8H5hVaEH/3QQM/U2BtFhxT4gQ=; b=zye3ludga65N7yZtISTrwxQ4BOMm+F7vwpZeEGdaDPwdWkHJZbs3At10TO9SnqAwOu sD15MxXR6JQh3OicpfwS5I6mY2/r2wsd9u8StF7333V27wwgKo7uSy7HPls5z4WfwXdW xAx2TYE5JicWxQKhUh4e4baePdfVybnoI2hsqEvgb4jMhWsBK2dqGTdzMPP9KjpqiSa6 JSb7/o+/uUy5d53lmMFYJ/LMxryHsn4He16zJxgBxBrgrwW1oPiYAAAg5eccd7RUP8oB bSvTLEgPgS2yCIRWJHmhcoEspWCmJz6LFF7K4lNVcj6X4N4ssujb6x3/VTYiin0RLK97 dmWA== X-Received: by 10.236.45.69 with SMTP id o45mr19538579yhb.64.1397715499102; Wed, 16 Apr 2014 23:18:19 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id h66sm46640572yhb.7.2014.04.16.23.18.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 23:18:18 -0700 (PDT) Subject: Re: Comments on draft-ietf-bfd-generic-crypto-auth Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: Date: Wed, 16 Apr 2014 23:18:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nobo Akiya (nobo) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RccT7yt491eJ4lxzsdQAgn5dF8k Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-generic-crypto-auth@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 06:18:24 -0000 Nobo, See comments inline. On Apr 14, 2014, at 10:23 AM, Nobo Akiya (nobo) wrote: > Hi Authors, >=20 > I have reviewed your draft (draft-ietf-bfd-generic-crypto-auth ), = comments below. > Since document is nearing expiration, perhaps you can address some of = these comments and re-publish? >=20 >=20 > (1) Abstract >=20 > s/arbitary/arbitrary/ Fixed. >=20 >=20 > (2) Section 2 >=20 > Before listing "Not Before Time" and "Not After Time", it'll be great = if the document can provide some words to better transition from = previous paragraph.=20 Those are the parameters associated with a BFD SA just like = Authentication Algorithm etc. The indentation might have thrown you off. = Let me see if I can fix it. >=20 >=20 > (3) Section 3.3 >=20 > [snip] > The device MUST fill the Auth Type and the Auth Len fields before = the > authentication data is computed. The Sequence Number field MUST be > set to bfd.XmitAuthSeq. > [snip] >=20 > The paragraph is slightly confusing wrt whether Sequence Number field = need to be set before or after authentication data is computed. It'll be = good to clarify this. I was looking at RFC 5880 for guidance on this. It says "The Sequence = Number field MUST be set to bfd.XmitAuthSeq." Period. No mention of = before or after. How about this: "The device MUST fill the Auth Type, the Auth Len fields and set the = Sequence Number field to bfd.XmitAuthSeq before the authentication data = is computed." >=20 >=20 > (4) Section 3.4, second paragraph >=20 > [snip] > If the Authentication Present (A) bit is set in the packet header = and > the receiver will try to find a appropriate BFD SA in its local key > table to process the packet. > [snip] >=20 > I believe you meant to say: >=20 > If the Authentication Present (A) bit is set in the packet header = and > Auth Type is TBD1 or TBD2, the receiver is to find an appropriate = BFD > SA in its local key table to process the packet. >=20 > See below for usage of TBD1/TBD2. Ok. Will fix it. >=20 >=20 > (5) Section 3.4, fourth paragraph >=20 > Is it better to say "unsigned 64 bit circular number space" here, or = keep it as "unsigned 32 bit circular number space"? If latter, then the = document should clarify that it's low order 32 bits. Ok. Will change it to say "unsigned 64 bit circular number space" >=20 >=20 > (6) Section 3.4, sixth paragraph >=20 > [snip] > In such a case, an error event SHOULD be logged. > [snip] >=20 > Such log could become DoS attack point? Rate limiting of such log is = outside the scope of this document, but it could be beneficial to = explain this in the Security Considerations section ... optional comment = though. >=20 How about this: "In such a case, an error event SHOULD be logged. Rate limiting of such = a log to prevent a DoS attack is outside the scope of this document." >=20 > (7) IANA Considerations >=20 > Indeed values 6 and 7 are next, but it's technically not correct to = just use them [yet]. > Can we use TBD1 and TBD2? If someone is implementing and early = allocation is required, then we can do that. >=20 > Also it'll be beneficial for this section to clearly describe what is = needed from where. Maybe something like: >=20 > IANA is requested to assign two authentication types from the > "BFD Authentication Types" sub-registry within the "Bidirectional > Forwarding Detection (BFD) Parameters" registry. >=20 > Address BFD Authentication Type Name Reference > ------- --------------------------------------- ------------- > TBD1 Cryptographic Authentication this document > TBD2 Meticulous Cryptographic Authentication this document >=20 >=20 Ok. Will make the suggested changes. > (8) Security Considerations >=20 > s/reestablishing/re-establishing/ >=20 Will fix. >=20 > (9) References >=20 > RFC5880 should be a normative reference instead of informative, as = document is even referencing a variable from RFC5880 (ex: = bfd.XmitAuthSeq). >=20 That is correct. Consider it done. Thanks >=20 > -Nobo >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Apr 17 05:39:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97341A0410; Wed, 16 Apr 2014 16:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzgEx2SxbtlP; Wed, 16 Apr 2014 16:31:13 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 27E6A1A040F; Wed, 16 Apr 2014 16:31:12 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3GNV7C1003223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Apr 2014 19:31:08 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s3GNV7C1003223 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1397691068; bh=v3EwX5/iElkqecTL8cKXJGphWVY=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=pfeRnmVgmn7BlgDHfYP1Npst+unTEj122jtCF8Fu/TMZeLbg+uoUKnuTYia3agmwO EWzfwTZYp0cTEjSeXczyOxPNC6JEEw486ONQylWX15QvyIh3dsbzYuaBnZnb/gKDhQ P1TPDMXa0ezF81zdRhwGggv8nbUK4y6OVaqhkjmM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s3GNV7C1003223 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Wed, 16 Apr 2014 16:30:59 -0700 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3GNUv2n006543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 19:30:58 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub33.corp.emc.com ([::1]) with mapi; Wed, 16 Apr 2014 19:30:57 -0400 From: "Black, David" To: "tnadeau@lucidvision.com" , "zali@cisco.com" , "nobo@cisco.com" , "General Area Review Team (gen-art@ietf.org)" Date: Wed, 16 Apr 2014 19:30:56 -0400 Subject: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Index: Ac9Zy+Zk0qHspTLsTUq2+7kL82/PpA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/T1imWrSt3FYE9OpO1O_nKQbztCg X-Mailman-Approved-At: Thu, 17 Apr 2014 05:39:06 -0700 Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" , "Black, David" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 23:31:18 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-bfd-mib-17 Reviewer: David L. Black Review Date: April 16, 2014 IETF LC End Date: April 28, 2014 Summary: This draft is on the right track, but has open issues described in the review. This draft is a MIB module for the BFD protocol, which is an important low- level routing protocol. The draft is reasonable for a MIB draft; one needs to go read the protocol documents to understand how the protocol works, and significant portions of the text are derived from the usual MIB "boilerplat= e" as one would expect. The "Brief Description of MIB Objects" is indeed brief, but reasonable. The shepherd writeup indicates that there are multiple implementations. Major issues: This MIB contains many writable objects, so the authors should take note of the IESG statement on writable MIB modules: http://www.ietf.org/iesg/statement/writable-mib-module.html I did not see this mentioned in the shepherd writeup. If the OPS Area has not been consulted, I strongly suggest doing so during IETF Last Call, e.g., starting with Benoit Claise (AD). Minor issues: The security considerations section includes considerations for unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus, but omits the corresponding considerations for bfdAdminStatus and bfdSessNotificationsEnable. Both of the latter objects are global, so significant damage can be inflicted via these objects with a small number of unauthorized modifications, so they need to be included in the first list of sensitive objects. I suggest that the authors recheck the entire MIB to ensure that every object or table that should be included in the security considerations section is appropriately included. Also, as a General Variable, would bfdSessNotificationsEnable be better named bfdNotificationsEnable, as it's not in the BFD Session Table? I did not see a compliance requirement for a system that only implements BFD protocol version 0. That absence should at least be mentioned somewhere. For example, if this reflects a considered and deliberate decision by the WG, that should be mentioned in the introduction. Nits/editorial comments: In the security considerations for authentication-related objects: OLD In order for these sensitive information from being improperly accessed, implementers MAY wish to disallow access to these objects. NEW In order to prevent this sensitive information from being improperly accessed, implementers MAY disallow access to these objects. idnits 2.13.01 found a truly minor nit that should be corrected when the draft is next revised: =3D=3D Outdated reference: A later version (-05) exists of draft-ietf-bfd-tc-mib-04 it also generated a warning that probably does not reflect an actual proble= m: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If yo= u have contacted all the original authors and they are all willing to gr= ant the BCP78 rights to the IETF Trust, then this is fine, and you can ign= ore this comment. If not, you may need to add the pre-RFC5378 disclaimer.= =20 (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Thu Apr 17 05:50:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D841A0158 for ; Thu, 17 Apr 2014 05:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pATrpKuSaPGq for ; Thu, 17 Apr 2014 05:50:16 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 65B641A013B for ; Thu, 17 Apr 2014 05:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1430; q=dns/txt; s=iport; t=1397739013; x=1398948613; h=from:to:cc:subject:date:message-id:mime-version; bh=vZStQc0w7C2NRenMGxuQcWt0b1o9pDXt70zvvTz4aUo=; b=BgEQgdVTevFRWPoxzuSjL32h3uTeKWnjpbQZMCdy6WQZwhHattakHup5 Va04fXIF0Gmow1PIv96MjsYbPPcrY3BAJbms0MFcyZzCyZEK+3C3BOxZb ukWY/Z7DlyrqshS3Li17HX+PjhNK7Nv9xvpQguEz+vdoZtdYVpsXkyrA8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAKbMT1OtJV2a/2dsb2JhbABZgkJEgRLDYoElFnSCHBB3AhIBCwFhEycEDogBynwXjmKEPwSPDYlhkk2DMYIr X-IronPort-AV: E=Sophos;i="4.97,879,1389744000"; d="scan'208,217";a="318463200" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 17 Apr 2014 12:50:12 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3HCoCA9031286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Apr 2014 12:50:12 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.208]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 07:50:12 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: "rtg-bfd@ietf.org" Subject: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Topic: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Index: AQHPWjuSIo9hc5e0sES09J7I8hmrpQ== Date: Thu, 17 Apr 2014 12:50:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.92] Content-Type: multipart/alternative; boundary="_000_CF75CBDA1E595mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AP7cT8iYE2temaew1QhJ7lmyg5k X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 12:50:17 -0000 --_000_CF75CBDA1E595mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello BFD WG Members, We have published a new version of Seamless BFD draft, draft-akiya-bfd-seam= less-base-03. Several sections have been updated for improving readability.= It also has a few technical changes as well. Please review the draft and g= et back to us with your comments. Thanks Regards Mallik --_000_CF75CBDA1E595mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8F59AA7CF5F1DE4FA2723164A0EA7A65@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello BFD WG Members,

We have published a new version of Seamless BFD draft, draft-akiya-bfd= -seamless-base-03. Several sections have been updated for improving readabi= lity. It also has a few technical changes as well. Please review the draft = and get back to us with your comments.

Thanks

Regards
Mallik
--_000_CF75CBDA1E595mmudigonciscocom_-- From nobody Thu Apr 17 06:02:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F4F1A02BE for ; Thu, 17 Apr 2014 06:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fGruT6I60xr for ; Thu, 17 Apr 2014 06:02:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 97BC91A0146 for ; Thu, 17 Apr 2014 06:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1766; q=dns/txt; s=iport; t=1397739733; x=1398949333; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EG2CFf3g64+dUBNc2ke79OmdwYDskHTpWdjmibHoDWE=; b=XhbHWX6+cTVx+eQ56KNqACpR3zERiVpinj9750pgFeOACrwCeb/8okR9 jZDddpwrR3kECkmUnWs87tFVl3xuu0+nARgJBd8sLIezGg611RTY56Jev JTKLHaR4yWwJk++182aXlwFMHNv1GN0Q88mNS1bxJFERnmYE4TRNizHoc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGHQT1OtJA2H/2dsb2JhbABZgmUhgRLDX4ElFnSCJgEBBDo/EAIBCA4UFBAyJQIEDg2HdAHKeBeOMTEHgySBFAEDqzuDMYIr X-IronPort-AV: E=Sophos;i="4.97,879,1389744000"; d="scan'208";a="318409792" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 17 Apr 2014 13:02:02 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3HD22qv024126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 13:02:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 08:02:02 -0500 From: "Nobo Akiya (nobo)" To: Mahesh Jethanandani Subject: RE: Comments on draft-ietf-bfd-generic-crypto-auth Thread-Topic: Comments on draft-ietf-bfd-generic-crypto-auth Thread-Index: AQHPWgTUuOoYgkEaVkOvKIVTeBrAM5sVweNQ Date: Thu, 17 Apr 2014 13:02:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-FnYDBg_OE_KJ_quf0kAeqf2G8E Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-generic-crypto-auth@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 13:02:18 -0000 Hi Mahesh, Thanks for considering my comments. > > (3) Section 3.3 > > > > [snip] > > The device MUST fill the Auth Type and the Auth Len fields before the > > authentication data is computed. The Sequence Number field MUST be > > set to bfd.XmitAuthSeq. > > [snip] > > > > The paragraph is slightly confusing wrt whether Sequence Number field > need to be set before or after authentication data is computed. It'll be = good > to clarify this. >=20 >=20 > I was looking at RFC 5880 for guidance on this. It says "The Sequence > Number field MUST be set to bfd.XmitAuthSeq." Period. No mention of > before or after. >=20 > How about this: > "The device MUST fill the Auth Type, the Auth Len fields and set the > Sequence Number field to bfd.XmitAuthSeq before the authentication data > is computed." That is much clearer. > > (6) Section 3.4, sixth paragraph > > > > [snip] > > In such a case, an error event SHOULD be logged. > > [snip] > > > > Such log could become DoS attack point? Rate limiting of such log is > outside the scope of this document, but it could be beneficial to explain= this > in the Security Considerations section ... optional comment though. > > >=20 > How about this: >=20 > "In such a case, an error event SHOULD be logged. Rate limiting of such a= log > to prevent a DoS attack is outside the scope of this document." Changes does imply that rate limiting should be applied. However, consideri= ng these logs could be generated for every BFD packet received by the syste= m (which can be significant amount), it may be better to explicitly have a = paragraph on this in the Security Consideration section. Perhaps this can b= e taken up as a next next revision? -Nobo From nobody Thu Apr 17 14:18:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E519A1A0168; Thu, 17 Apr 2014 14:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6XFA6VeeC2l; Thu, 17 Apr 2014 14:18:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 135CD1A0054; Thu, 17 Apr 2014 14:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6800; q=dns/txt; s=iport; t=1397769510; x=1398979110; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hLKYK5Tid4Oymx7mWHA3JWXrFKs8DPKGdfamuUTiTOw=; b=ONWRRAQZXfZt/cLeHmsVHE371nt7WfIarDx/E8judYe+J8CvEXPeaSaQ M/UEDFThlYNkKA+k2V0PcXFLBos4irsS/R4YWyhmQxZqkIN4SRKCtdTA+ c7ROZAx4hwCEYcvDX6gAYGLbe6lZlop1N0n6XDWi6i0lJu+NHON9uhUVg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGNEUFOtJA2K/2dsb2JhbABWA4JlITtXw2eBJxZ0giUBAQEDAXkMBAIBCBEDAQEBCx0HMhQJCAEBBAENBQgBh2sIAQzMHBeMb4FCIRACBQYLgxOBFASIdDaLVoUlkRaDMYIr X-IronPort-AV: E=Sophos;i="4.97,881,1389744000"; d="scan'208";a="318644398" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 17 Apr 2014 21:18:30 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3HLITFG025344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 21:18:29 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 16:18:29 -0500 From: "Nobo Akiya (nobo)" To: "Black, David" , "tnadeau@lucidvision.com" , "Zafar Ali (zali)" , "General Area Review Team (gen-art@ietf.org)" Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Index: Ac9Zy+Zk0qHspTLsTUq2+7kL82/PpAAiJosQ Date: Thu, 17 Apr 2014 21:18:28 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zho1_m9dByt4k2_W82tOVuOB9rU Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 21:18:41 -0000 Hi David, Thank you for thorough review of this document. Please see replies in-line. > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, April 16, 2014 7:31 PM > To: tnadeau@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); General > Area Review Team (gen-art@ietf.org) > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > Subject: Gen-ART review of draft-ietf-bfd-mib-17 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen- > ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-bfd-mib-17 > Reviewer: David L. Black > Review Date: April 16, 2014 > IETF LC End Date: April 28, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft is a MIB module for the BFD protocol, which is an important lo= w- > level routing protocol. The draft is reasonable for a MIB draft; one nee= ds to > go read the protocol documents to understand how the protocol works, and > significant portions of the text are derived from the usual MIB "boilerpl= ate" > as one would expect. The "Brief Description of MIB Objects" is indeed br= ief, > but reasonable. The shepherd writeup indicates that there are multiple > implementations. >=20 > Major issues: >=20 > This MIB contains many writable objects, so the authors should take note = of > the IESG statement on writable MIB modules: >=20 > http://www.ietf.org/iesg/statement/writable-mib-module.html >=20 > I did not see this mentioned in the shepherd writeup. If the OPS Area ha= s > not been consulted, I strongly suggest doing so during IETF Last Call, e.= g., > starting with Benoit Claise (AD). I remember seeing the statement from IESG, which I agree is a good directio= n for new charter items. [This] BFD MIB, on the other hand, is almost 10 ye= ars old, with several implementations already around. I highly suspect the = WG will not want to see *change of direction* at this point. With that said= , let me take this up with the AD and the Shepherd. >=20 > Minor issues: >=20 > The security considerations section includes considerations for > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus, > but omits the corresponding considerations for bfdAdminStatus and > bfdSessNotificationsEnable. Both of the latter objects are global, so > significant damage can be inflicted via these objects with a small number= of > unauthorized modifications, so they need to be included in the first list= of > sensitive objects. Good point. I will add bfdAdminStatus and bfdOperStatus in the security con= siderations section. >=20 > I suggest that the authors recheck the entire MIB to ensure that every ob= ject > or table that should be included in the security considerations section i= s > appropriately included. I've gone through them. There are set of objects which really should not be= modified once a session is functioning. I've added this in the security co= nsiderations section. o Some management objects define the BFD session whilst other management objects define the parameter of the BFD session. It is particularly important to control the support for SET access to those management objects that define the BFD session, as changes to them can be disruptive. Implementation SHOULD NOT allow changes to following management objects when bfdSessState is up(4): * bfdSessVersionNumber * bfdSessType * bfdSessDestinationUdpPort * bfdSessMultipointFlag * bfdSessInterface * bfdSessSrcAddrType * bfdSessSrcAddr * bfdSessDstAddrType * bfdSessDstAddr >=20 > Also, as a General Variable, would bfdSessNotificationsEnable be better > named bfdNotificationsEnable, as it's not in the BFD Session Table? That's true. Renamed as suggested. >=20 > I did not see a compliance requirement for a system that only implements > BFD protocol version 0. That absence should at least be mentioned > somewhere. For example, if this reflects a considered and deliberate > decision by the WG, that should be mentioned in the introduction. Good point. If I remember correctly, BFD version 0 had a problem in the sta= te machine that can cause the two ends to fall into a deadlock. It would be= , therefore, very bad for anybody to have BFD version 0 deployed out there,= and asking for any MIB compliance requirement for such. Consensus on absen= ce of compliance requirement for BFD version 0 was never polled in the WG, = but I can say that there shouldn't be any desire for that. I will add a short statement on lack of BFD version 0 compliance requiremen= t in the introduction section, as you suggested. >=20 > Nits/editorial comments: >=20 > In the security considerations for authentication-related objects: >=20 > OLD > In order for these sensitive information > from being improperly accessed, implementers MAY wish to disallow > access to these objects. > NEW > In order to prevent this sensitive information > from being improperly accessed, implementers MAY disallow > access to these objects. Thanks for the text. Updated in local copy. >=20 > idnits 2.13.01 found a truly minor nit that should be corrected when the > draft is next revised: >=20 > =3D=3D Outdated reference: A later version (-05) exists of > draft-ietf-bfd-tc-mib-04 Agree, non-issue. >=20 > it also generated a warning that probably does not reflect an actual > problem: >=20 > -- The document seems to lack a disclaimer for pre-RFC5378 work, but ma= y > have content which was first submitted before 10 November 2008. If = you > have contacted all the original authors and they are all willing to = grant > the BCP78 rights to the IETF Trust, then this is fine, and you can i= gnore > this comment. If not, you may need to add the pre-RFC5378 disclaime= r. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) Agree, non-issue. Thanks again! -Nobo >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Thu Apr 17 14:37:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0441A0167; Thu, 17 Apr 2014 14:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQaQqrcGVipN; Thu, 17 Apr 2014 14:31:49 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9F1A0133; Thu, 17 Apr 2014 14:31:48 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HLVfcP030891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2014 17:31:41 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s3HLVfcP030891 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1397770302; bh=g4RSLBFR0A8YAd4iJhfH78ibJFY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=VSrAbX62azadSl/bgkEfACJ7xVeub5vI5M3Ugi92nd2h0sePVXA1gcelbhYer755Y kGc+z2mIUaO89oz5n3fqp6XiiX3FVyfT+efO8QP61R4dQMYSTccSSTLINc3pZHDJCE 2TSVbGebcEpHqbGjy7lr6NENVl/WPQ/WEKGzM75U= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s3HLVfcP030891 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd54.lss.emc.com (RSA Interceptor); Thu, 17 Apr 2014 17:31:25 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HLVPUI006105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 17:31:25 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Thu, 17 Apr 2014 17:31:25 -0400 From: "Black, David" To: "Nobo Akiya (nobo)" , "tnadeau@lucidvision.com" , "Zafar Ali (zali)" , "General Area Review Team (gen-art@ietf.org)" Date: Thu, 17 Apr 2014 17:31:23 -0400 Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Index: Ac9Zy+Zk0qHspTLsTUq2+7kL82/PpAAiJosQAAum6hA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C2EC413@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RudrEBrKuzP6HZaHMAsV93n3uQ4 X-Mailman-Approved-At: Thu, 17 Apr 2014 14:37:54 -0700 Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 21:31:53 -0000 Hi Nobo, > > This MIB contains many writable objects, so the authors should take not= e of > > the IESG statement on writable MIB modules: > > > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > > > I did not see this mentioned in the shepherd writeup. If the OPS Area = has > > not been consulted, I strongly suggest doing so during IETF Last Call, = e.g., > > starting with Benoit Claise (AD). >=20 > I remember seeing the statement from IESG, which I agree is a good direct= ion > for new charter items. [This] BFD MIB, on the other hand, is almost 10 ye= ars > old, with several implementations already around. I highly suspect the WG= will > not want to see *change of direction* at this point. With that said, let = me > take this up with the AD and the Shepherd. I have no problem with "running code" as a good reason to continue with writable objects in this MIB; taking this topic up with your AD and Shepher= d should suffice. > > I suggest that the authors recheck the entire MIB to ensure that every = object > > or table that should be included in the security considerations section= is > > appropriately included. >=20 > I've gone through them. There are set of objects which really should not = be > modified once a session is functioning. I've added this in the security > considerations section. Good - thank you for doing that. Everything else is fine with me, and I appreciate the prompt response. Thanks, --David > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Thursday, April 17, 2014 5:18 PM > To: Black, David; tnadeau@lucidvision.com; Zafar Ali (zali); General Area > Review Team (gen-art@ietf.org) > Cc: rtg-bfd@ietf.org; ietf@ietf.org > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 >=20 > Hi David, >=20 > Thank you for thorough review of this document. > Please see replies in-line. >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Wednesday, April 16, 2014 7:31 PM > > To: tnadeau@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); Gener= al > > Area Review Team (gen-art@ietf.org) > > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > > Subject: Gen-ART review of draft-ietf-bfd-mib-17 > > > > I am the assigned Gen-ART reviewer for this draft. For background on Ge= n- > > ART, please see the FAQ at > > > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-bfd-mib-17 > > Reviewer: David L. Black > > Review Date: April 16, 2014 > > IETF LC End Date: April 28, 2014 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft is a MIB module for the BFD protocol, which is an important = low- > > level routing protocol. The draft is reasonable for a MIB draft; one n= eeds > to > > go read the protocol documents to understand how the protocol works, an= d > > significant portions of the text are derived from the usual MIB > "boilerplate" > > as one would expect. The "Brief Description of MIB Objects" is indeed > brief, > > but reasonable. The shepherd writeup indicates that there are multiple > > implementations. > > > > Major issues: > > > > This MIB contains many writable objects, so the authors should take not= e of > > the IESG statement on writable MIB modules: > > > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > > > I did not see this mentioned in the shepherd writeup. If the OPS Area = has > > not been consulted, I strongly suggest doing so during IETF Last Call, = e.g., > > starting with Benoit Claise (AD). >=20 > I remember seeing the statement from IESG, which I agree is a good direct= ion > for new charter items. [This] BFD MIB, on the other hand, is almost 10 ye= ars > old, with several implementations already around. I highly suspect the WG= will > not want to see *change of direction* at this point. With that said, let = me > take this up with the AD and the Shepherd. >=20 > > > > Minor issues: > > > > The security considerations section includes considerations for > > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus, > > but omits the corresponding considerations for bfdAdminStatus and > > bfdSessNotificationsEnable. Both of the latter objects are global, so > > significant damage can be inflicted via these objects with a small numb= er of > > unauthorized modifications, so they need to be included in the first li= st of > > sensitive objects. >=20 > Good point. I will add bfdAdminStatus and bfdOperStatus in the security > considerations section. >=20 > > > > I suggest that the authors recheck the entire MIB to ensure that every > object > > or table that should be included in the security considerations section= is > > appropriately included. >=20 > I've gone through them. There are set of objects which really should not = be > modified once a session is functioning. I've added this in the security > considerations section. >=20 > o Some management objects define the BFD session whilst other > management objects define the parameter of the BFD session. It is > particularly important to control the support for SET access to > those management objects that define the BFD session, as changes > to them can be disruptive. Implementation SHOULD NOT allow > changes to following management objects when bfdSessState is > up(4): >=20 > * bfdSessVersionNumber > * bfdSessType > * bfdSessDestinationUdpPort > * bfdSessMultipointFlag > * bfdSessInterface > * bfdSessSrcAddrType > * bfdSessSrcAddr > * bfdSessDstAddrType > * bfdSessDstAddr >=20 > > > > Also, as a General Variable, would bfdSessNotificationsEnable be better > > named bfdNotificationsEnable, as it's not in the BFD Session Table? >=20 > That's true. Renamed as suggested. >=20 > > > > I did not see a compliance requirement for a system that only implement= s > > BFD protocol version 0. That absence should at least be mentioned > > somewhere. For example, if this reflects a considered and deliberate > > decision by the WG, that should be mentioned in the introduction. >=20 > Good point. If I remember correctly, BFD version 0 had a problem in the s= tate > machine that can cause the two ends to fall into a deadlock. It would be, > therefore, very bad for anybody to have BFD version 0 deployed out there,= and > asking for any MIB compliance requirement for such. Consensus on absence = of > compliance requirement for BFD version 0 was never polled in the WG, but = I can > say that there shouldn't be any desire for that. >=20 > I will add a short statement on lack of BFD version 0 compliance requirem= ent > in the introduction section, as you suggested. >=20 > > > > Nits/editorial comments: > > > > In the security considerations for authentication-related objects: > > > > OLD > > In order for these sensitive information > > from being improperly accessed, implementers MAY wish to disallow > > access to these objects. > > NEW > > In order to prevent this sensitive information > > from being improperly accessed, implementers MAY disallow > > access to these objects. >=20 > Thanks for the text. Updated in local copy. >=20 > > > > idnits 2.13.01 found a truly minor nit that should be corrected when th= e > > draft is next revised: > > > > =3D=3D Outdated reference: A later version (-05) exists of > > draft-ietf-bfd-tc-mib-04 >=20 > Agree, non-issue. >=20 > > > > it also generated a warning that probably does not reflect an actual > > problem: > > > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but = may > > have content which was first submitted before 10 November 2008. I= f you > > have contacted all the original authors and they are all willing t= o > grant > > the BCP78 rights to the IETF Trust, then this is fine, and you can > ignore > > this comment. If not, you may need to add the pre-RFC5378 disclai= mer. > > (See the Legal Provisions document at > > http://trustee.ietf.org/license-info for more information.) >=20 > Agree, non-issue. >=20 > Thanks again! >=20 > -Nobo >=20 > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- >=20 From nobody Thu Apr 17 14:55:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D601A01D6; Thu, 17 Apr 2014 14:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cESKme936dPR; Thu, 17 Apr 2014 14:55:30 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 4B72C1A01CE; Thu, 17 Apr 2014 14:55:30 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HLtKmr011886; Thu, 17 Apr 2014 22:55:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HLtJQ1011877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 22:55:19 +0100 From: "Adrian Farrel" To: "'Black, David'" , , , , "'General Area Review Team'" References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 Date: Thu, 17 Apr 2014 22:55:18 +0100 Message-ID: <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXstybkl3Rj5QCVQi0ErrtVmSSApsFo67A Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20640.002 X-TM-AS-Result: No--7.041-10.0-31-10 X-imss-scan-details: No--7.041-10.0-31-10 X-TMASE-MatchedRID: QfHZjzml1E+nykMun0J1wpmug812qIbzC/ExpXrHizxXopZjyO6CZaem Jq66qqv9A72lF8jbwSm+h2+kRiP1Xo4a2rhHAtuZoMfp2vHck9WHxi2fvkKUM8izgKND8Lm5VZ8 xQvqztISd5Vi9MggDmL1DgIPIkgsZSWKSZniod93ThGbP9qB93B9fNWA7SFWqWltirZ/iPP4Duw Qv5f82WF/nw1MAso95JvN5sPGL1gQqCxvBy34zX2gws6g0ewz2moKXVHfiMM8gcyGevtftJ6PFj JEFr+olqYB+kyCYtxRcLc3sLtjOt+TCMddcL/gjOwBXM346/+zID5XcD4FtapcOFu+rNPoeDEFa KkIPel+133QqrH6lMVsi4ALUpd8T Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/66TB6chbpN9oufRmIDP7Y9M9Ew0 Cc: rtg-bfd@ietf.org, ietf@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:55:32 -0000 Hi David, Thanks for the review. To pick out one of your points: > This MIB contains many writable objects, so the authors should > take note of the IESG statement on writable MIB modules: > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > I did not see this mentioned in the shepherd writeup. If the OPS Area > has not been consulted, I strongly suggest doing so during IETF Last > Call, e.g., starting with Benoit Claise (AD). The OPS Directorate and the MIB Doctors will have been alerted to this document by the last call and we can expect their comments. But this question was discussed between the AD and the authors, and the AD was unlikely to agree to sponsor the document if he felt it went against the IESG statement. Our discussion resulted in some reduction of writeable objects. I think there are several points to consider: 1. This document had already been completed and publication requested (i.e. shepherd write-up written) at the time of the IESG statement. It would be unreasonable to make the statement retrospective. 2. There are already various implementations in equipment (not just management stations) of proprietary modules approximating to this document and these support write-access. 3. This is a low-level component protocol of the sort that is used on dumber devices and that is an area where write-access is more common. Cheers, Adrian From nobody Thu Apr 17 15:08:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A974F1A01AD; Thu, 17 Apr 2014 15:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlcU0EXzAanW; Thu, 17 Apr 2014 15:06:42 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1BF1A01A5; Thu, 17 Apr 2014 15:06:41 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HM6WCl028810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2014 18:06:33 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s3HM6WCl028810 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1397772394; bh=x5lPp3hwEyXiFe09SBaiImx5+CQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=DUr7XRUrSxNEVBasvsv0aoBRzweKYySNTspmpf2P6t97h4d+7kpT2fEAkcCjzMQK8 PJ8AsSk6sI5BsAZjUKZCkLDdt8jnKwFEZOwpNGxu2SFMVcURN4U6BpxTP3mg+mJHYl LdAG7S8UalWA7VJlISkl+eOQR5EaP0h/CmTS/5bI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s3HM6WCl028810 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Thu, 17 Apr 2014 18:06:22 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HM6Lqn009455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 18:06:21 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Thu, 17 Apr 2014 18:06:21 -0400 From: "Black, David" To: "adrian@olddog.co.uk" , "tnadeau@lucidvision.com" , "zali@cisco.com" , "nobo@cisco.com" , "'General Area Review Team'" Date: Thu, 17 Apr 2014 18:06:20 -0400 Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Index: AQHXstybkl3Rj5QCVQi0ErrtVmSSApsFo67AgAAGUSA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C2EC421@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> In-Reply-To: <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> 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 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LKqVhOHCk8lXJwmBvg_n8ROo3OY X-Mailman-Approved-At: Thu, 17 Apr 2014 15:08:29 -0700 Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" , "Black, David" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 22:06:44 -0000 Hi Adrian, As clarified in my response to Nobo, I raised the concern about writable MIB modules primarily as a process check (I was expecting to find something on this topic in the shepherd writeup, and didn't). In particular, this concern was not intended as a strong reason not to publish, and I have no disagreements with any of the points in your message below. With you on top of this and the OPS folks sure to notice, I have no doubt that this will get suitably addressed, although it might be simpler to ensure that the OPS Area is ok now rather than waiting for IESG Evaluation. Thanks, --David (in part, wearing his OPS Directorate member "hat"). > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, April 17, 2014 5:55 PM > To: Black, David; tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com= ; > 'General Area Review Team' > Cc: rtg-bfd@ietf.org; ietf@ietf.org > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 >=20 > Hi David, >=20 > Thanks for the review. >=20 > To pick out one of your points: >=20 > > This MIB contains many writable objects, so the authors should > > take note of the IESG statement on writable MIB modules: > > > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > > > I did not see this mentioned in the shepherd writeup. If the OPS Area > > has not been consulted, I strongly suggest doing so during IETF Last > > Call, e.g., starting with Benoit Claise (AD). >=20 > The OPS Directorate and the MIB Doctors will have been alerted to this > document > by the last call and we can expect their comments. >=20 > But this question was discussed between the AD and the authors, and the A= D was > unlikely to agree to sponsor the document if he felt it went against the = IESG > statement. Our discussion resulted in some reduction of writeable objects= . >=20 > I think there are several points to consider: > 1. This document had already been completed and publication requested (i.= e. > shepherd write-up written) at the time of the IESG statement. It would be > unreasonable to make the statement retrospective. > 2. There are already various implementations in equipment (not just manag= ement > stations) of proprietary modules approximating to this document and these > support write-access. > 3. This is a low-level component protocol of the sort that is used on dum= ber > devices and that is an area where write-access is more common. >=20 > Cheers, > Adrian >=20 >=20 From nobody Thu Apr 17 15:11:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E821A0100; Thu, 17 Apr 2014 15:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9_pYKbvpYtm; Thu, 17 Apr 2014 15:11:22 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D3D081A00FE; Thu, 17 Apr 2014 15:11:21 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so817177pbb.25 for ; Thu, 17 Apr 2014 15:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LFXLyYpahXiiwnMu44Nc1E4R1kYqRN49rDIcE/QeGfo=; b=hEaJUEsbwsaPkVvXJvmykvB/SjKfpBJPXbck3oieXVwQndHu9UX3k/h3KV7TjJLNw0 yC9HyPHV/BlJ1J32NbDXcd8P4Mlv/essuIDn30UsHqGNa7Hi69ApxJECNkGfFX2QTowQ p3DTjEbzG2xlrzryaJ04J4lYqgBF5viHgYpztCIf9r0B+QooxMum2JuJjqN7Pu9SIjgR QAbRvEtB7+d9fnkVPlNIYPFT1EVh8sbmwjhb9mpl0vOaioZ2o/dj5KJWEO/l5g1vFRiR CZOuUBR3c0QtSh0oau/iwFrAisF6vbG96ABDHYfWdno2+bJSo3V3Kn7LlGyUGwevVIHn 9GLg== X-Received: by 10.68.254.103 with SMTP id ah7mr18009827pbd.159.1397772678265; Thu, 17 Apr 2014 15:11:18 -0700 (PDT) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id pl10sm55697899pbb.56.2014.04.17.15.11.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 15:11:17 -0700 (PDT) Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Sam K. Aldrin" In-Reply-To: <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> Date: Thu, 17 Apr 2014 15:11:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fRbWfvjf77CSgGDSU-pvng7VwV4 Cc: ietf@ietf.org, "'Black, David'" , rtg-bfd@ietf.org, zali@cisco.com, 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 22:11:32 -0000 Hi Adrian, One comment inline. On Apr 17, 2014, at 2:55 PM, Adrian Farrel wrote: > Hi David, >=20 > Thanks for the review. >=20 > To pick out one of your points: >=20 >> This MIB contains many writable objects, so the authors should >> take note of the IESG statement on writable MIB modules: >>=20 >> http://www.ietf.org/iesg/statement/writable-mib-module.html >>=20 >> I did not see this mentioned in the shepherd writeup. If the OPS = Area >> has not been consulted, I strongly suggest doing so during IETF Last >> Call, e.g., starting with Benoit Claise (AD). >=20 > The OPS Directorate and the MIB Doctors will have been alerted to this = document > by the last call and we can expect their comments. >=20 > But this question was discussed between the AD and the authors, and = the AD was > unlikely to agree to sponsor the document if he felt it went against = the IESG > statement. Our discussion resulted in some reduction of writeable = objects. >=20 > I think there are several points to consider: > 1. This document had already been completed and publication requested = (i.e. > shepherd write-up written) at the time of the IESG statement. It would = be > unreasonable to make the statement retrospective. > 2. There are already various implementations in equipment (not just = management > stations) of proprietary modules approximating to this document and = these > support write-access. %sam - If this MIB allows write access, do you/WG anticipate, any = extension to the MIB should also provide write-access as well? For = example: http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ = augments this base MIB to support MPLS. It adds more confusion than = solving the issue as base MIB supports write-access, but augmented/ MIB = extension doesn't.=20 As the BFD MIB authors were not supportive of write-access objects in = the MIBs, why to have them in the first place?=20 cheers -sam > 3. This is a low-level component protocol of the sort that is used on = dumber > devices and that is an area where write-access is more common. >=20 > Cheers, > Adrian >=20 >=20 From nobody Thu Apr 17 15:15:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0945D1A0100; Thu, 17 Apr 2014 15:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1saCmvMvMKx; Thu, 17 Apr 2014 15:15:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF17F1A011D; Thu, 17 Apr 2014 15:15:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 37915C2A3; Thu, 17 Apr 2014 18:15:11 -0400 (EDT) Date: Thu, 17 Apr 2014 18:15:11 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Message-ID: <20140417221511.GC29430@pfrc> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4wU3WPpNrhsWiaYyTsm09rHk1Qg Cc: "ietf@ietf.org" , "Black, David" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , "General Area Review Team \(gen-art@ietf.org\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 22:15:16 -0000 On Thu, Apr 17, 2014 at 09:18:28PM +0000, Nobo Akiya (nobo) wrote: > > I did not see a compliance requirement for a system that only implements > > BFD protocol version 0. That absence should at least be mentioned > > somewhere. For example, if this reflects a considered and deliberate > > decision by the WG, that should be mentioned in the introduction. > > Good point. If I remember correctly, BFD version 0 had a problem in the state machine that can cause the two ends to fall into a deadlock. It would be, therefore, very bad for anybody to have BFD version 0 deployed out there, and asking for any MIB compliance requirement for such. Consensus on absence of compliance requirement for BFD version 0 was never polled in the WG, but I can say that there shouldn't be any desire for that. With respect to v0 vs. v1 from a MIB perspective, the only user-visible detail was the additional state in the state machine. That means that the MIB in its current form should be able to accommodate bfd v0. This does suggest, however, that the TC mib could use a comment in the DESCRIPTION toward the point that failing(5) is only valid for BFD v0. A conformance clause indicating that those so foolish as to deploy BFD v0 would better be served by the determinism of a five-year-old child flipping a coin is probably out of scope for the draft. But if someone has sufficiently proscriptive text to add to say "don't do bfd v0" that is acceptable to the reviewers, I'm fine with that. -- Jeff From nobody Thu Apr 17 15:18:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F6F1A00D1; Thu, 17 Apr 2014 15:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxxf6ice03wp; Thu, 17 Apr 2014 15:18:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6449C1A0173; Thu, 17 Apr 2014 15:18:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CB696C2A3; Thu, 17 Apr 2014 18:18:50 -0400 (EDT) Date: Thu, 17 Apr 2014 18:18:50 -0400 From: Jeffrey Haas To: "Sam K. Aldrin" Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Message-ID: <20140417221850.GD29430@pfrc> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9oFcbnIdqJfC5-IxgCf515Stfjs Cc: ietf@ietf.org, "'Black, David'" , rtg-bfd@ietf.org, zali@cisco.com, 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 22:18:55 -0000 Sam, On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: > %sam - If this MIB allows write access, do you/WG anticipate, any extension to the MIB should also provide write-access as well? For example: http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments this base MIB to support MPLS. It adds more confusion than solving the issue as base MIB supports write-access, but augmented/ MIB extension doesn't. > > As the BFD MIB authors were not supportive of write-access objects in the MIBs, why to have them in the first place? As noted in earlier mailing list chatter, there is some support for write access in existing implementations. Given the lack of significant detail when pressed for the name of such an implementation, I'm suspecting smaller vendor or internal implementation. That's still sufficient to leave write available. Given that one of the original contexts of asking if we could remove write was whether IETF was being asked to provide such a thing for MPLS-TP with related impact on your extension MIB and the answer was "no", that shouldn't be the main criteria. My suspicion is that if we were to ship the base MIB with writeable objects, we may be forced to consider similar things for the extension MIB(s). -- Jeff From nobody Thu Apr 17 15:40:30 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9291A0188; Thu, 17 Apr 2014 15:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR_prD7fdVy2; Thu, 17 Apr 2014 15:40:23 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 521771A0176; Thu, 17 Apr 2014 15:40:23 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id p10so819849pdj.31 for ; Thu, 17 Apr 2014 15:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gvbubcSt5auUHsa6TpP/bsQ7HxWk9Ll6lcrsfEFtZM4=; b=Wa90Z3SjJ5EUcQ0Zhw5maeny+KUACTiXLvadWHgr64xSZRd+xJMfswJPBdOk8qse/U las9lpQ1UcnZkWWahW9X/DQJONUwOO8kVFws5P1dyk88AiOhHRE+J7dKuya8m01gags3 pam2RY55WXalW+8GyKNmRYVJN/sM3dsOhhgYGmQ5V2A8aRffe8PRXmmjseKjvkIju3of M06loibhYLTEsmdbx11A+d8dWQB8+w9YRGw3srC6bgMiqrCUS9qdpoTfQcvOZvEDV0ZY kbFfkLE1LjwFYx6zZ3hvXL6x2NBZ3WzvzOy70NYpDMuzDzasVvC/CexWuqqYKnH4YdZJ S7qA== X-Received: by 10.66.253.33 with SMTP id zx1mr18534581pac.28.1397774419692; Thu, 17 Apr 2014 15:40:19 -0700 (PDT) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id q10sm55812565pbl.29.2014.04.17.15.40.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 15:40:17 -0700 (PDT) Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Sam K. Aldrin" In-Reply-To: <20140417221850.GD29430@pfrc> Date: Thu, 17 Apr 2014 15:40:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UgfOiqpSw-FEiZCC83UwLzfpl3A Cc: ietf@ietf.org, "'Black, David'" , rtg-bfd@ietf.org, zali@cisco.com, 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 22:40:25 -0000 Hi Jeff, Comments inline. On Apr 17, 2014, at 3:18 PM, Jeffrey Haas wrote: > Sam, >=20 > On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: >> %sam - If this MIB allows write access, do you/WG anticipate, any = extension to the MIB should also provide write-access as well? For = example: http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ = augments this base MIB to support MPLS. It adds more confusion than = solving the issue as base MIB supports write-access, but augmented/ MIB = extension doesn't.=20 >>=20 >> As the BFD MIB authors were not supportive of write-access objects in = the MIBs, why to have them in the first place?=20 >=20 > As noted in earlier mailing list chatter, there is some support for = write > access in existing implementations. Given the lack of significant = detail > when pressed for the name of such an implementation, I'm suspecting = smaller > vendor or internal implementation. That's still sufficient to leave = write > available. >=20 > Given that one of the original contexts of asking if we could remove = write > was whether IETF was being asked to provide such a thing for MPLS-TP = with > related impact on your extension MIB and the answer was "no", that = shouldn't > be the main criteria. =20 No. The context of my question is not related to MPLS-TP as such, but = write-access support in general.=20 I should have added 'clarification' in my earlier email. >=20 > My suspicion is that if we were to ship the base MIB with writeable = objects, > we may be forced to consider similar things for the extension MIB(s). Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE = and BFD-MIB respectively, with write-access. Had to do write-access = because of the reason you've mentioned above, which is base MIB. It = would be painful to publish/support write-access MIB's when there is no = clear interest. Hence my clarification question.=20 -sam >=20 > -- Jeff From nobody Thu Apr 17 18:05:01 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313A91A01E6; Thu, 17 Apr 2014 18:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeXP7-RUyS0X; Thu, 17 Apr 2014 18:04:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 64AF41A0134; Thu, 17 Apr 2014 18:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2616; q=dns/txt; s=iport; t=1397783090; x=1398992690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9hS/2W9x/fYLzWcVQQBs8PLMW9/qgJipIGCwZA11CS4=; b=Gbbr6rbJEMvUI99IFDb0d2WuHYwwTQbxY+49cHnHU5ALla0fTaM4xOOd IswlHGRFWT8aX/am45/2A/xJkK39KedYO0AJulmagwTWSb9YLwlllCz2Q ILtINXXtQiczeUHqMXU26uJIccTUOsiEWNLILzTO6KHX8v/xjXLpPFQrg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJd5UFOtJV2Z/2dsb2JhbABZgmUhO1fDaIEjFnSCJQEBAQMBOjQLEAIBCBgKFBAyJQEBBAENDQELh2AIAQzMFBeOABACAR4xAgWDJIEUBJolkRaDMYIr X-IronPort-AV: E=Sophos;i="4.97,882,1389744000"; d="scan'208";a="318620035" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 18 Apr 2014 01:04:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3I14nIr011776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 01:04:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 20:04:48 -0500 From: "Nobo Akiya (nobo)" To: "Sam K. Aldrin" , Jeffrey Haas Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Index: Ac9Zy+Zk0qHspTLsTUq2+7kL82/PpAA5br4AAACOm4AAAEPMAAAAv3uAAAaLVxA= Date: Fri, 18 Apr 2014 01:04:47 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> In-Reply-To: <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RpAaDon5kghDLJ2_B3IoncAZy5Y Cc: "ietf@ietf.org" , "'Black, David'" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 01:04:58 -0000 Hi Sam, > > On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: > >> %sam - If this MIB allows write access, do you/WG anticipate, any > extension to the MIB should also provide write-access as well? For exampl= e: > http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments this > base MIB to support MPLS. It adds more confusion than solving the issue a= s > base MIB supports write-access, but augmented/ MIB extension doesn't. > >> > >> As the BFD MIB authors were not supportive of write-access objects in > the MIBs, why to have them in the first place? > > > > As noted in earlier mailing list chatter, there is some support for > > write access in existing implementations. Given the lack of > > significant detail when pressed for the name of such an > > implementation, I'm suspecting smaller vendor or internal > > implementation. That's still sufficient to leave write available. > > > > Given that one of the original contexts of asking if we could remove > > write was whether IETF was being asked to provide such a thing for > > MPLS-TP with related impact on your extension MIB and the answer was > > "no", that shouldn't be the main criteria. > No. The context of my question is not related to MPLS-TP as such, but wri= te- > access support in general. > I should have added 'clarification' in my earlier email. > > > > My suspicion is that if we were to ship the base MIB with writeable > > objects, we may be forced to consider similar things for the extension > MIB(s). > Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE and > BFD-MIB respectively, with write-access. Had to do write-access because = of > the reason you've mentioned above, which is base MIB. It would be painful > to publish/support write-access MIB's when there is no clear interest. He= nce > my clarification question. This mentions three vendors wanting to implement MIB as writable. http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html And one more vendor voicing for writable. http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html I agree that defining & wording writable MIB is much more painful than all = read-only MIB. But above thread indicates the desire by multiple vendors to= implement writable BFD MIB. Therefore it does seem that there are interest= s, and going forward with write-access will benefit the community. And with= *ReadOnlyCompliance defined, BFD MIB can also accommodate those implementi= ng them as just read-only. -Nobo >=20 > -sam >=20 > > > > -- Jeff From nobody Thu Apr 17 18:24:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6CD1A018F; Thu, 17 Apr 2014 18:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdC8r-4JTAZc; Thu, 17 Apr 2014 18:24:28 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7B96F1A0057; Thu, 17 Apr 2014 18:24:28 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so958280pab.38 for ; Thu, 17 Apr 2014 18:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=35aHL2qacWZN28WEqFB9sF9D1eRAX7ZaqHAhqbfSSZ8=; b=LmBGZd1Ai2g4tjRlc47UHbYKa5zPK4ykWzA+m/68o1aeQEBgmxPhejTD1FxPy451b+ nuFWtJUtwVbRE959WgzC0wghGxfi4cqFSTUVD839yocc31w1S6Ejkmwadz0pxmmMBzw/ b/xrwLyS7B2M9/7JWFk9i5jN/HbC6F6Qdsf5XKFlcW3XwZC4ewHtckiRuXjpztrvYJkq LEmJyG0YxHVh4pvEFEG3gwtgey9cg74VmNoaoffPoe4QCiQS46MeiX0wxNjYtWDr9Jqg P0vCk0QQB6uI8BTDEvH9tAV1aBROO3m6yVZAI+u/5Xa6KbgGX6I1TTOsdv0kriYqYSJU YIFw== X-Received: by 10.68.139.71 with SMTP id qw7mr19092420pbb.68.1397784264847; Thu, 17 Apr 2014 18:24:24 -0700 (PDT) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id pv4sm56277102pbb.55.2014.04.17.18.24.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 18:24:24 -0700 (PDT) Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Sam K. Aldrin" In-Reply-To: Date: Thu, 17 Apr 2014 18:24:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/O7RL8spWZqTtbXfDDfXeE1LGYq4 Cc: "ietf@ietf.org" , "'Black, David'" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 01:24:30 -0000 Hi Nobo, [sorry for the top post] Yes, this is an old MIB and was in existence for a long time.=20 My only concern is with the new extension MIB's. If the base MIB (this = MIB) has write access, future extension MIB's may be forced to support = write-access. And that is the painful part, where community at large has = not shown interest in developing write-access MIB's at IETF, lest = implementation.=20 I want to re-iterate again, I am not objecting or proposing an = alternative option. Just wanted to get clarification, so that, we don't = have to burn cycles and do the exercise again, when we have to review = these new extension MIB's. -sam On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote: > Hi Sam, >=20 >>> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: >>>> %sam - If this MIB allows write access, do you/WG anticipate, any >> extension to the MIB should also provide write-access as well? For = example: >> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments = this >> base MIB to support MPLS. It adds more confusion than solving the = issue as >> base MIB supports write-access, but augmented/ MIB extension doesn't. >>>>=20 >>>> As the BFD MIB authors were not supportive of write-access objects = in >> the MIBs, why to have them in the first place? >>>=20 >>> As noted in earlier mailing list chatter, there is some support for >>> write access in existing implementations. Given the lack of >>> significant detail when pressed for the name of such an >>> implementation, I'm suspecting smaller vendor or internal >>> implementation. That's still sufficient to leave write available. >>>=20 >>> Given that one of the original contexts of asking if we could remove >>> write was whether IETF was being asked to provide such a thing for >>> MPLS-TP with related impact on your extension MIB and the answer was >>> "no", that shouldn't be the main criteria. >> No. The context of my question is not related to MPLS-TP as such, but = write- >> access support in general. >> I should have added 'clarification' in my earlier email. >>>=20 >>> My suspicion is that if we were to ship the base MIB with writeable >>> objects, we may be forced to consider similar things for the = extension >> MIB(s). >> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE = and >> BFD-MIB respectively, with write-access. Had to do write-access = because of >> the reason you've mentioned above, which is base MIB. It would be = painful >> to publish/support write-access MIB's when there is no clear = interest. Hence >> my clarification question. >=20 > This mentions three vendors wanting to implement MIB as writable. >=20 > http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html >=20 > And one more vendor voicing for writable. >=20 > http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html >=20 > I agree that defining & wording writable MIB is much more painful than = all read-only MIB. But above thread indicates the desire by multiple = vendors to implement writable BFD MIB. Therefore it does seem that there = are interests, and going forward with write-access will benefit the = community. And with *ReadOnlyCompliance defined, BFD MIB can also = accommodate those implementing them as just read-only. >=20 > -Nobo >=20 >>=20 >> -sam >>=20 >>>=20 >>> -- Jeff >=20 From nobody Thu Apr 17 18:41:56 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E931A0247; Thu, 17 Apr 2014 18:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-EJv6ivQlcP; Thu, 17 Apr 2014 18:41:45 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 50A341A0242; Thu, 17 Apr 2014 18:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2257; q=dns/txt; s=iport; t=1397785302; x=1398994902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b6TQy5UOH1kB4k7F1+x4znplvvUu1wHmVZ+W4zYEsxw=; b=M8na4kgIknpOEp3py/dhLy0NcS3l1vNngH03Atc3rd55Iv16wtgmYHz3 Ud0a/RQCmoBIDwIBRu0d4r1kYtDor0SUJRTUIN7Hq7j4TEu2JoZOlxgi0 HGup9gX6YQLHIAeoX0yalPSHJcdkXRUFsoW9DeEOh9EHWS52M9KfOZRL0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAASCUFOtJA2M/2dsb2JhbABZgmUhgRLDaIEjFnSCJQEBAQMBOj8MBAIBCA4DBAEBAQoUCQcyFAkIAQEEDgUIh2wIAcwjF44xMQcGgx6BFAEDqzuDMYIr X-IronPort-AV: E=Sophos;i="4.97,882,1389744000"; d="scan'208";a="36817188" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 18 Apr 2014 01:41:41 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3I1ffI5020901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 01:41:41 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 20:41:40 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Index: Ac9Zy+Zk0qHspTLsTUq2+7kL82/PpAAiJosQABf5+IAAA1d10A== Date: Fri, 18 Apr 2014 01:41:40 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <20140417221511.GC29430@pfrc> In-Reply-To: <20140417221511.GC29430@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kgpLvB7ZmizYEUobCenvWV9nzw4 Cc: "ietf@ietf.org" , "Black, David" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , "General Area Review Team \(gen-art@ietf.org\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 01:41:49 -0000 Hi Jeff, > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, April 17, 2014 6:15 PM > To: Nobo Akiya (nobo) > Cc: Black, David; tnadeau@lucidvision.com; Zafar Ali (zali); General Area > Review Team (gen-art@ietf.org); rtg-bfd@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 >=20 > On Thu, Apr 17, 2014 at 09:18:28PM +0000, Nobo Akiya (nobo) wrote: > > > I did not see a compliance requirement for a system that only > > > implements BFD protocol version 0. That absence should at least be > > > mentioned somewhere. For example, if this reflects a considered and > > > deliberate decision by the WG, that should be mentioned in the > introduction. > > > > Good point. If I remember correctly, BFD version 0 had a problem in the > state machine that can cause the two ends to fall into a deadlock. It wou= ld > be, therefore, very bad for anybody to have BFD version 0 deployed out > there, and asking for any MIB compliance requirement for such. Consensus > on absence of compliance requirement for BFD version 0 was never polled > in the WG, but I can say that there shouldn't be any desire for that. >=20 > With respect to v0 vs. v1 from a MIB perspective, the only user-visible d= etail > was the additional state in the state machine. That means that the MIB i= n its > current form should be able to accommodate bfd v0. >=20 > This does suggest, however, that the TC mib could use a comment in the > DESCRIPTION toward the point that failing(5) is only valid for BFD v0. Agree, and it's already there :) [snip] IANAbfdSessStateTC ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "BFD session state. State failing(5) is only applicable if corresponding session is running in BFD version 0." [snip] -Nobo >=20 > A conformance clause indicating that those so foolish as to deploy BFD v0 > would better be served by the determinism of a five-year-old child flippi= ng > a coin is probably out of scope for the draft. But if someone has suffic= iently > proscriptive text to add to say "don't do bfd v0" that is acceptable to t= he > reviewers, I'm fine with that. >=20 > -- Jeff From nobody Thu Apr 17 19:17:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FB91A00B4; Thu, 17 Apr 2014 19:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-aiWU41Ab9d; Thu, 17 Apr 2014 19:17:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B08EA1A001B; Thu, 17 Apr 2014 19:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4382; q=dns/txt; s=iport; t=1397787450; x=1398997050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b6+yzgHZCagbonRihcCu34WjcP/VyaXKFjyYVKTH4qk=; b=PlJgFkx2jkRNiSNuYtVvORSxqOLgie8yzRJ/A2jcMGEMml/OGPbedR8R lazdMe1RuH0TwhfTX9aJrXdEhOg+JeuLvWaSGdb0ijbpMC54A4D2rKJby YfaOTKrqStDqhyjD7MjPQ4WA6/EfSM3aS6XuTatJr/CbjsjBjrwBCFkkC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAK6JUFOtJV2b/2dsb2JhbABZgmUhO1fDaIEjFnSCJQEBAQQ6NAsMBAIBCBEEAQEBChQJByERFAkIAgQOBQgBC4dUAxEBDMUiDYZrF4xJgTcQAgEeMQIFBoMegRQElwCDJYtGhVCDMYIr X-IronPort-AV: E=Sophos;i="4.97,882,1389744000"; d="scan'208";a="318435662" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 18 Apr 2014 02:17:29 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3I2HT3j007371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 02:17:29 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 21:17:29 -0500 From: "Nobo Akiya (nobo)" To: "Sam K. Aldrin" Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17 Thread-Index: Ac9Zy+Zk0qHspTLsTUq2+7kL82/PpAA5br4AAACOm4AAAEPMAAAAv3uAAAaLVxD///l/AIAATS4g Date: Fri, 18 Apr 2014 02:17:28 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> In-Reply-To: <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/utjECopPSp4vrzxlPPxvb39jzf4 Cc: "ietf@ietf.org" , "'Black, David'" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 02:17:38 -0000 Hi Sam, > -----Original Message----- > From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Thursday, April 17, 2014 9:24 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; ietf@ietf.org; 'Black, David'; adrian@olddog.co.uk; rtg= - > bfd@ietf.org; Zafar Ali (zali); 'General Area Review Team' > Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 >=20 > Hi Nobo, > [sorry for the top post] >=20 > Yes, this is an old MIB and was in existence for a long time. > My only concern is with the new extension MIB's. If the base MIB (this MI= B) > has write access, future extension MIB's may be forced to support write- > access. And that is the painful part, where community at large has not > shown interest in developing write-access MIB's at IETF, lest > implementation. >=20 > I want to re-iterate again, I am not objecting or proposing an alternativ= e > option. Just wanted to get clarification, so that, we don't have to burn = cycles > and do the exercise again, when we have to review these new extension > MIB's. That's a good point, it would be good to have this clarified for future wor= k. IMO: For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if gets i= ncluded in the charter) should look into NETCONF/YANG (i.e. not extension t= o the BFD base MIB). For currently chartered BFD tasks, the BFD WG should continue with writable= MIB. Large part of that is the BFD base & MPLS MIBs which [painful] writab= le effort is mostly done already. -Nobo >=20 > -sam >=20 > On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote: >=20 > > Hi Sam, > > > >>> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: > >>>> %sam - If this MIB allows write access, do you/WG anticipate, any > >> extension to the MIB should also provide write-access as well? For > example: > >> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments > >> this base MIB to support MPLS. It adds more confusion than solving > >> the issue as base MIB supports write-access, but augmented/ MIB > extension doesn't. > >>>> > >>>> As the BFD MIB authors were not supportive of write-access objects > >>>> in > >> the MIBs, why to have them in the first place? > >>> > >>> As noted in earlier mailing list chatter, there is some support for > >>> write access in existing implementations. Given the lack of > >>> significant detail when pressed for the name of such an > >>> implementation, I'm suspecting smaller vendor or internal > >>> implementation. That's still sufficient to leave write available. > >>> > >>> Given that one of the original contexts of asking if we could remove > >>> write was whether IETF was being asked to provide such a thing for > >>> MPLS-TP with related impact on your extension MIB and the answer was > >>> "no", that shouldn't be the main criteria. > >> No. The context of my question is not related to MPLS-TP as such, but > >> write- access support in general. > >> I should have added 'clarification' in my earlier email. > >>> > >>> My suspicion is that if we were to ship the base MIB with writeable > >>> objects, we may be forced to consider similar things for the > >>> extension > >> MIB(s). > >> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE > >> and BFD-MIB respectively, with write-access. Had to do write-access > >> because of the reason you've mentioned above, which is base MIB. It > >> would be painful to publish/support write-access MIB's when there is > >> no clear interest. Hence my clarification question. > > > > This mentions three vendors wanting to implement MIB as writable. > > > > http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html > > > > And one more vendor voicing for writable. > > > > http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html > > > > I agree that defining & wording writable MIB is much more painful than = all > read-only MIB. But above thread indicates the desire by multiple vendors = to > implement writable BFD MIB. Therefore it does seem that there are > interests, and going forward with write-access will benefit the community= . > And with *ReadOnlyCompliance defined, BFD MIB can also accommodate > those implementing them as just read-only. > > > > -Nobo > > > >> > >> -sam > >> > >>> > >>> -- Jeff > > From nobody Thu Apr 17 19:19:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC17B1A00B4; Thu, 17 Apr 2014 19:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ4x4Yn91-kt; Thu, 17 Apr 2014 19:19:06 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A93BC1A001B; Thu, 17 Apr 2014 19:19:06 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md12so994256pbc.21 for ; Thu, 17 Apr 2014 19:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kIw2nM3r6y6FniSxk3XSE9wIBRMAQ+U6ypzHYqbDpU0=; b=rg8tuoOHlgTXMMoFIjrTCDqvEPOIcJEqCgsf8FqmnqKlkR66kiZyxGuZ7/8zc8qUMt 6w3rp2bUZJG2FyGUSIGGK3/xjHwoxiWuOeYsr2u6B+0BY9pgfQFAQG0R3jC6ms5Mknxp u5S1tYAqAV4A9203h/Ui44kZJItnf4yb6DOFyq2hSXU+YOq/zTxg574nh4B/f9macORV Jd9ypy1GSj9Bnn+k3+bILaJB/7Va7hRXhCwfpjGd7gam8aYfx2N+kSwrB74d7Ea13m8o NG51RED13+PFoiiNGTZOHGAnYVtnOkL8xPEjku97v9g938IQsOJjZcLC/RRTd5H+XcMA aYmQ== X-Received: by 10.66.197.135 with SMTP id iu7mr18967003pac.149.1397787543040; Thu, 17 Apr 2014 19:19:03 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id xo9sm133063879pab.18.2014.04.17.19.19.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 19:19:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 From: Sam Aldrin In-Reply-To: Date: Thu, 17 Apr 2014 19:19:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OfZa6SIFb0Zovv1XdcbIOKe5_uE Cc: "ietf@ietf.org" , "Black, David" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , General Area Review Team X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 02:19:08 -0000 Thanks, Nobo. Much appreciated. -sam On Apr 17, 2014, at 7:17 PM, Nobo Akiya (nobo) wrote: > Hi Sam, >=20 >> -----Original Message----- >> From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Thursday, April 17, 2014 9:24 PM >> To: Nobo Akiya (nobo) >> Cc: Jeffrey Haas; ietf@ietf.org; 'Black, David'; adrian@olddog.co.uk; = rtg- >> bfd@ietf.org; Zafar Ali (zali); 'General Area Review Team' >> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 >>=20 >> Hi Nobo, >> [sorry for the top post] >>=20 >> Yes, this is an old MIB and was in existence for a long time. >> My only concern is with the new extension MIB's. If the base MIB = (this MIB) >> has write access, future extension MIB's may be forced to support = write- >> access. And that is the painful part, where community at large has = not >> shown interest in developing write-access MIB's at IETF, lest >> implementation. >>=20 >> I want to re-iterate again, I am not objecting or proposing an = alternative >> option. Just wanted to get clarification, so that, we don't have to = burn cycles >> and do the exercise again, when we have to review these new extension >> MIB's. >=20 > That's a good point, it would be good to have this clarified for = future work. >=20 > IMO: >=20 > For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if = gets included in the charter) should look into NETCONF/YANG (i.e. not = extension to the BFD base MIB). >=20 > For currently chartered BFD tasks, the BFD WG should continue with = writable MIB. Large part of that is the BFD base & MPLS MIBs which = [painful] writable effort is mostly done already. >=20 > -Nobo >=20 >>=20 >> -sam >>=20 >> On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote: >>=20 >>> Hi Sam, >>>=20 >>>>> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: >>>>>> %sam - If this MIB allows write access, do you/WG anticipate, any >>>> extension to the MIB should also provide write-access as well? For >> example: >>>> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments >>>> this base MIB to support MPLS. It adds more confusion than solving >>>> the issue as base MIB supports write-access, but augmented/ MIB >> extension doesn't. >>>>>>=20 >>>>>> As the BFD MIB authors were not supportive of write-access = objects >>>>>> in >>>> the MIBs, why to have them in the first place? >>>>>=20 >>>>> As noted in earlier mailing list chatter, there is some support = for >>>>> write access in existing implementations. Given the lack of >>>>> significant detail when pressed for the name of such an >>>>> implementation, I'm suspecting smaller vendor or internal >>>>> implementation. That's still sufficient to leave write available. >>>>>=20 >>>>> Given that one of the original contexts of asking if we could = remove >>>>> write was whether IETF was being asked to provide such a thing for >>>>> MPLS-TP with related impact on your extension MIB and the answer = was >>>>> "no", that shouldn't be the main criteria. >>>> No. The context of my question is not related to MPLS-TP as such, = but >>>> write- access support in general. >>>> I should have added 'clarification' in my earlier email. >>>>>=20 >>>>> My suspicion is that if we were to ship the base MIB with = writeable >>>>> objects, we may be forced to consider similar things for the >>>>> extension >>>> MIB(s). >>>> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, = MPLS-TE >>>> and BFD-MIB respectively, with write-access. Had to do = write-access >>>> because of the reason you've mentioned above, which is base MIB. It >>>> would be painful to publish/support write-access MIB's when there = is >>>> no clear interest. Hence my clarification question. >>>=20 >>> This mentions three vendors wanting to implement MIB as writable. >>>=20 >>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html >>>=20 >>> And one more vendor voicing for writable. >>>=20 >>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html >>>=20 >>> I agree that defining & wording writable MIB is much more painful = than all >> read-only MIB. But above thread indicates the desire by multiple = vendors to >> implement writable BFD MIB. Therefore it does seem that there are >> interests, and going forward with write-access will benefit the = community. >> And with *ReadOnlyCompliance defined, BFD MIB can also accommodate >> those implementing them as just read-only. >>>=20 >>> -Nobo >>>=20 >>>>=20 >>>> -sam >>>>=20 >>>>>=20 >>>>> -- Jeff >>>=20 >=20 From nobody Thu Apr 17 20:53:37 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60861A0147; Thu, 17 Apr 2014 20:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp9kF1SqukfW; Thu, 17 Apr 2014 20:53:30 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 339291A00C0; Thu, 17 Apr 2014 20:53:30 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id rd3so1066974pab.39 for ; Thu, 17 Apr 2014 20:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IPL7jibdZfBm/MKJUWytg45glowdrHwo43dKe8MCkCw=; b=KdIt143+7azLk0RP+nlVOLdWO0Pm2VVRrmwI2EFJuF551H5RcHLnGJybuhjv5wpiHJ tR7/xzCNU11kCd+KPrCZtyxevuYRuRJ4OGVp2qHSijjeinouqXuzqvFcPCz48h8Yecwm MHBHe6BsbDCaMb3oWBm7KAV6OtHIYz2YBbKc+ucEChFBZ1KWEsFv0EbqwO+zu9f2nb6R MSeP33Xfidoj+6Ij9aLUztdYlnx6I+LVr/5KOVj0t1AHmqsChFn+4iZ94xEBPtkYs6j1 eNCa3qkzQkpeWnmkA7JUkU3Jd0rJKRe5Ux9Pr+mBZ4W2opLGvRpwfidx4bDppnBEIkNA GJ0g== X-Received: by 10.68.178.66 with SMTP id cw2mr19692869pbc.89.1397793206554; Thu, 17 Apr 2014 20:53:26 -0700 (PDT) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id ha2sm56880842pbb.8.2014.04.17.20.53.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 20:53:25 -0700 (PDT) Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Sam K. Aldrin" In-Reply-To: <25276146.1397789275400.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Thu, 17 Apr 2014 20:53:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B03C974-91FE-48CC-AF82-A82517E106C0@gmail.com> References: <25276146.1397789275400.JavaMail.root@elwamui-little.atl.sa.earthlink.net> To: Randy Presuhn X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_q2EEo3N3kidElWUe5Oam7oVzy4 Cc: "ietf@ietf.org" , "'Black, David'" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 03:53:31 -0000 Hi Randy, Inline for my comments. On Apr 17, 2014, at 7:47 PM, Randy Presuhn wrote: > Hi - >=20 >> From: "Sam K. Aldrin" >> Sent: Apr 17, 2014 6:24 PM > ... >> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 > ... >> My only concern is with the new extension MIB's. >> If the base MIB (this MIB) has write access, >> future extension MIB's may be forced to support >> write-access. >=20 > And how, exactly, does the fact that a base MIB module > permits write access force extension MIB modules to > require (or even permit) write access? >=20 > It's perfectly reasonable SMI to define an AUGMENTS > table consisting entirely of read-only objects. True, you could add only read-only objects.=20 But the point is, not with syntax or what could be added or augmented. In order to support new functionality, we are extending/augmenting = existing base MIB and in addition some write-access objects as well. If = we make those new ones read-only objects, then only some objects or = tables could be used with write-access and these new objects (read-only) = have to be configured differently. In other words, full functionality = cannot be provided. This got nothing to do with SMI. The point we are extending or re-using the base MIB is not to re-define = new objects altogether and also to re-use the applications. Atleast that = is what we have done in this case. Hope this clarifies. cheers -sam >=20 > Randy From nobody Thu Apr 17 21:50:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B93B1A0140; Thu, 17 Apr 2014 21:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cn9wfGe_k4M; Thu, 17 Apr 2014 21:50:40 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7C1A0130; Thu, 17 Apr 2014 21:50:39 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kl14so1103677pab.32 for ; Thu, 17 Apr 2014 21:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l2MfswrE2Co/PzLnz2IWz81pjYeDLiPL72wg2NcwRfo=; b=szJHJG1zo6gUy7R/UnnmbDbuYZUvlCxfrws3Rzdk3dPWqjAevjtUQ7lB1RXheJp6As C8iJgGPxX1IJuK4nXB+n1G6iAjJOFG8p1XjIVBHdaOFdfvnETF7jCkpEIFF/VoVFyS73 NJ12GYVZpDrNFMdDLgc3tQKwh3G/J7ua3XlL0s2M0eUAQY5lMfDfr3AiwINj/YBE2uw/ NQB6kFS6Zz/eAksoe4Q3DzfBjAqlfd6Gp1ECFNsGbik+sZMe6onOgalpXLqJ2ZuxftD3 GA+vSJE/CvIBaGjn7sJXc8gjsFpnoHKJdfa1L1TzK4DF8nGsnbqI/dJpjJhBgAxO82wj uXXw== X-Received: by 10.66.150.169 with SMTP id uj9mr19900037pab.148.1397796635882; Thu, 17 Apr 2014 21:50:35 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id vd8sm135850111pac.12.2014.04.17.21.50.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 21:50:35 -0700 (PDT) Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <007101cf5ab8$77cf7280$6b01a8c0@oemcomputer> Date: Thu, 17 Apr 2014 21:50:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A35F863-6CBB-447B-9232-B353141E4D9A@gmail.com> References: <25276146.1397789275400.JavaMail.root@elwamui-little.atl.sa.earthlink.net> <4B03C974-91FE-48CC-AF82-A82517E106C0@gmail.com> <007101cf5ab8$77cf7280$6b01a8c0@oemcomputer> To: Randy Presuhn X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VRNUWPVnDtRD1MHJLugRP2RCb2Y Cc: ietf@ietf.org, "Black, David" , rtg-bfd@ietf.org, "Zafar Ali \(zali\)" , General Area Review Team X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 04:50:42 -0000 Hi Randy, On Apr 17, 2014, at 8:43 PM, Randy Presuhn = wrote: > Hi - >=20 >> From: "Sam K. Aldrin" > ... >> Sent: Thursday, April 17, 2014 9:53 PM >> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 > ... >> In order to support new functionality, we are extending/augmenting = existing base >> MIB and in addition some write-access objects as well. If we make = those new >> ones read-only objects, then only some objects or tables could be = used with >> write-access and these new objects (read-only) have to be configured = differently. >> In other words, full functionality cannot be provided. This got = nothing to do with SMI. >=20 > Then what's the problem? If the WG has consensus to add = functionality, and > that functionality logically requires a read-write MIB module of = extension, > the IESG policy already allows for such cases. Yes, that is what I wanted to clarify, when I sent my email, to find if = there is WG consensus to go with write-access objects, as this base MIB = will have implication on the other MIB in the pipeline? We had quite a big thread on MPLS list on this very subject and wanted = to avoid the repeat. http://www.ietf.org/mail-archive/web/mpls/current/msg11598.html cheers -sam >=20 > Randy >=20 From nobody Thu Apr 17 22:18:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1091A0147; Thu, 17 Apr 2014 22:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8OPHTmlB1pU; Thu, 17 Apr 2014 22:18:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9311A015B; Thu, 17 Apr 2014 22:18:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-generic-crypto-auth-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418051841.21102.41276.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 22:18:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jb3DHeHU3uAOGFUaP4FSO099EEU Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 05:18:45 -0000 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 Generic Cryptographic Authentication Authors : Manav Bhatia Vishwas Manral Dacheng Zhang Mahesh Jethanandani Filename : draft-ietf-bfd-generic-crypto-auth-06.txt Pages : 13 Date : 2014-04-17 Abstract: This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of arbitrary cryptographic authentication algorithms in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure that is required for supporting algorithm and key agility for BFD. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-generic-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-generic-crypto-auth-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 18 02:38:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08971A02D5; Fri, 18 Apr 2014 02:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qmc2Iv3_E6j; Fri, 18 Apr 2014 02:38:16 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0D61A0095; Fri, 18 Apr 2014 02:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1625; q=dns/txt; s=iport; t=1397813892; x=1399023492; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ykFJxg01yjpmcg96OyitluycaXNWhMs2sfg+HnqdycU=; b=ZgtY1TgtgcIVl+CuO9JdKix2RVaE/5ubTiD+pBfF9vu0ydyX0Pgf2o5G dWMRCp6z4awe6W+NSer+LiWPGYzQUfRrtaD0I09CfBbQCworLNcwqOlL/ W3fSzUnqR5OHb0dzgjStu3dSQhGFIrS7o7ssx7Lnr0vS2iq9b6R8gmuT2 E=; X-IronPort-AV: E=Sophos;i="4.97,883,1389744000"; d="scan'208";a="18997933" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 18 Apr 2014 09:38:11 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3I9cB6J004547; Fri, 18 Apr 2014 09:38:11 GMT Message-ID: <5350F283.1070907@cisco.com> Date: Fri, 18 Apr 2014 11:38:11 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Black, David'" , tnadeau@lucidvision.com, zali@cisco.com, nobo@cisco.com, "'General Area Review Team'" Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> In-Reply-To: <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uKsNxlFwLIixJAkeU0NYTpdhoZE Cc: rtg-bfd@ietf.org, ietf@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 09:38:20 -0000 Hi Adrian, > Hi David, > > Thanks for the review. > > To pick out one of your points: > >> This MIB contains many writable objects, so the authors should >> take note of the IESG statement on writable MIB modules: >> >> http://www.ietf.org/iesg/statement/writable-mib-module.html >> >> I did not see this mentioned in the shepherd writeup. If the OPS Area >> has not been consulted, I strongly suggest doing so during IETF Last >> Call, e.g., starting with Benoit Claise (AD). > The OPS Directorate and the MIB Doctors will have been alerted to this document > by the last call and we can expect their comments. > > But this question was discussed between the AD and the authors, and the AD was > unlikely to agree to sponsor the document if he felt it went against the IESG > statement. Our discussion resulted in some reduction of writeable objects. > > I think there are several points to consider: > 1. This document had already been completed and publication requested (i.e. > shepherd write-up written) at the time of the IESG statement. It would be > unreasonable to make the statement retrospective. > 2. There are already various implementations in equipment (not just management > stations) of proprietary modules approximating to this document and these > support write-access. > 3. This is a low-level component protocol of the sort that is used on dumber > devices and that is an area where write-access is more common. Thanks for the explanation. That makes sense to me. This would be a useful addition to the writeup. Regards, Benoit > > Cheers, > Adrian > > > . > From nobody Fri Apr 18 02:41:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152DE1A02ED; Fri, 18 Apr 2014 02:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0KikSbirRsL; Fri, 18 Apr 2014 02:41:15 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB151A02E6; Fri, 18 Apr 2014 02:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4493; q=dns/txt; s=iport; t=1397814071; x=1399023671; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bjzfSWuLPBsKnl2k8kCmV3tXHQglzz7edw/goZL3YpI=; b=i3LqvAO0Jye998umRel+XO8l4895jWEp6XTwgfqR3ut9MibP8viqED2I 4SlRWtpPuJ6tIujeNW6Yq/DThuKTNwQ1SAiVevdq6nU65aSR2blC4e80Q xHpG/MrzwkX/1wR10KS/KBUxoBD+2zxQ9T/qgk4V5m3PRjYao2aiBdmke c=; X-IronPort-AV: E=Sophos;i="4.97,883,1389744000"; d="scan'208";a="18999086" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 18 Apr 2014 09:41:10 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3I9f9m5007414; Fri, 18 Apr 2014 09:41:09 GMT Message-ID: <5350F335.8020309@cisco.com> Date: Fri, 18 Apr 2014 11:41:09 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , "Sam K. Aldrin" Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Yn2NNtcDydtUiwydSMSk50t6j04 Cc: "ietf@ietf.org" , "'Black, David'" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 09:41:17 -0000 On 18/04/2014 04:17, Nobo Akiya (nobo) wrote: > Hi Sam, > >> -----Original Message----- >> From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Thursday, April 17, 2014 9:24 PM >> To: Nobo Akiya (nobo) >> Cc: Jeffrey Haas; ietf@ietf.org; 'Black, David'; adrian@olddog.co.uk; rtg- >> bfd@ietf.org; Zafar Ali (zali); 'General Area Review Team' >> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 >> >> Hi Nobo, >> [sorry for the top post] >> >> Yes, this is an old MIB and was in existence for a long time. >> My only concern is with the new extension MIB's. If the base MIB (this MIB) >> has write access, future extension MIB's may be forced to support write- >> access. And that is the painful part, where community at large has not >> shown interest in developing write-access MIB's at IETF, lest >> implementation. >> >> I want to re-iterate again, I am not objecting or proposing an alternative >> option. Just wanted to get clarification, so that, we don't have to burn cycles >> and do the exercise again, when we have to review these new extension >> MIB's. > That's a good point, it would be good to have this clarified for future work. > > IMO: > > For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if gets included in the charter) should look into NETCONF/YANG (i.e. not extension to the BFD base MIB). > > For currently chartered BFD tasks, the BFD WG should continue with writable MIB. Large part of that is the BFD base & MPLS MIBs which [painful] writable effort is mostly done already. This is in essence what https://www.ietf.org/iesg/statement/writable-mib-module.html says. Regards, Benoit. > > -Nobo > >> -sam >> >> On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote: >> >>> Hi Sam, >>> >>>>> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: >>>>>> %sam - If this MIB allows write access, do you/WG anticipate, any >>>> extension to the MIB should also provide write-access as well? For >> example: >>>> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments >>>> this base MIB to support MPLS. It adds more confusion than solving >>>> the issue as base MIB supports write-access, but augmented/ MIB >> extension doesn't. >>>>>> As the BFD MIB authors were not supportive of write-access objects >>>>>> in >>>> the MIBs, why to have them in the first place? >>>>> As noted in earlier mailing list chatter, there is some support for >>>>> write access in existing implementations. Given the lack of >>>>> significant detail when pressed for the name of such an >>>>> implementation, I'm suspecting smaller vendor or internal >>>>> implementation. That's still sufficient to leave write available. >>>>> >>>>> Given that one of the original contexts of asking if we could remove >>>>> write was whether IETF was being asked to provide such a thing for >>>>> MPLS-TP with related impact on your extension MIB and the answer was >>>>> "no", that shouldn't be the main criteria. >>>> No. The context of my question is not related to MPLS-TP as such, but >>>> write- access support in general. >>>> I should have added 'clarification' in my earlier email. >>>>> My suspicion is that if we were to ship the base MIB with writeable >>>>> objects, we may be forced to consider similar things for the >>>>> extension >>>> MIB(s). >>>> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE >>>> and BFD-MIB respectively, with write-access. Had to do write-access >>>> because of the reason you've mentioned above, which is base MIB. It >>>> would be painful to publish/support write-access MIB's when there is >>>> no clear interest. Hence my clarification question. >>> This mentions three vendors wanting to implement MIB as writable. >>> >>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html >>> >>> And one more vendor voicing for writable. >>> >>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html >>> >>> I agree that defining & wording writable MIB is much more painful than all >> read-only MIB. But above thread indicates the desire by multiple vendors to >> implement writable BFD MIB. Therefore it does seem that there are >> interests, and going forward with write-access will benefit the community. >> And with *ReadOnlyCompliance defined, BFD MIB can also accommodate >> those implementing them as just read-only. >>> -Nobo >>> >>>> -sam >>>> >>>>> -- Jeff > . > From nobody Fri Apr 18 04:51:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180EC1A01D9; Fri, 18 Apr 2014 04:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ticfNNMf88AU; Fri, 18 Apr 2014 04:51:17 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 747EA1A01BB; Fri, 18 Apr 2014 04:51:17 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id ED2B9276E09A; Fri, 18 Apr 2014 07:51:12 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CA1BA98C-0029-484D-835E-D8BB0151E3E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 From: Thomas Nadeau In-Reply-To: <5350F335.8020309@cisco.com> Date: Fri, 18 Apr 2014 07:51:11 -0400 Message-Id: <33B44E73-320B-4FC9-8438-E471F605F318@lucidvision.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> <5350F335.8020309@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/cBtbdcuA1JJkS8S6VpEURF9E2KA Cc: "ietf@ietf.org" , "Black, David" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , General Area Review Team X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 11:51:22 -0000 --Apple-Mail=_CA1BA98C-0029-484D-835E-D8BB0151E3E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise = wrote: > On 18/04/2014 04:17, Nobo Akiya (nobo) wrote: >> Hi Sam, >>=20 >>> -----Original Message----- >>> From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com] >>> Sent: Thursday, April 17, 2014 9:24 PM >>> To: Nobo Akiya (nobo) >>> Cc: Jeffrey Haas; ietf@ietf.org; 'Black, David'; = adrian@olddog.co.uk; rtg- >>> bfd@ietf.org; Zafar Ali (zali); 'General Area Review Team' >>> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 >>>=20 >>> Hi Nobo, >>> [sorry for the top post] >>>=20 >>> Yes, this is an old MIB and was in existence for a long time. >>> My only concern is with the new extension MIB's. If the base MIB = (this MIB) >>> has write access, future extension MIB's may be forced to support = write- >>> access. And that is the painful part, where community at large has = not >>> shown interest in developing write-access MIB's at IETF, lest >>> implementation. >>>=20 >>> I want to re-iterate again, I am not objecting or proposing an = alternative >>> option. Just wanted to get clarification, so that, we don't have to = burn cycles >>> and do the exercise again, when we have to review these new = extension >>> MIB's. >> That's a good point, it would be good to have this clarified for = future work. >>=20 >> IMO: >>=20 >> For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if = gets included in the charter) should look into NETCONF/YANG (i.e. not = extension to the BFD base MIB). >>=20 >> For currently chartered BFD tasks, the BFD WG should continue with = writable MIB. Large part of that is the BFD base & MPLS MIBs which = [painful] writable effort is mostly done already. > This is in essence what = https://www.ietf.org/iesg/statement/writable-mib-module.html says. >=20 > Regards, Benoit. Yes, this is why we left the writable stuff in - and why I = recently spent about 4 hours doing Adrian's edits around support of such = things. Lets please put the discussion around read-write to bed for = these two modules as they clearly were well under way and complete by = the time the statement came out. --Tom >>=20 >> -Nobo >>=20 >>> -sam >>>=20 >>> On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote: >>>=20 >>>> Hi Sam, >>>>=20 >>>>>> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: >>>>>>> %sam - If this MIB allows write access, do you/WG anticipate, = any >>>>> extension to the MIB should also provide write-access as well? For >>> example: >>>>> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments >>>>> this base MIB to support MPLS. It adds more confusion than solving >>>>> the issue as base MIB supports write-access, but augmented/ MIB >>> extension doesn't. >>>>>>> As the BFD MIB authors were not supportive of write-access = objects >>>>>>> in >>>>> the MIBs, why to have them in the first place? >>>>>> As noted in earlier mailing list chatter, there is some support = for >>>>>> write access in existing implementations. Given the lack of >>>>>> significant detail when pressed for the name of such an >>>>>> implementation, I'm suspecting smaller vendor or internal >>>>>> implementation. That's still sufficient to leave write = available. >>>>>>=20 >>>>>> Given that one of the original contexts of asking if we could = remove >>>>>> write was whether IETF was being asked to provide such a thing = for >>>>>> MPLS-TP with related impact on your extension MIB and the answer = was >>>>>> "no", that shouldn't be the main criteria. >>>>> No. The context of my question is not related to MPLS-TP as such, = but >>>>> write- access support in general. >>>>> I should have added 'clarification' in my earlier email. >>>>>> My suspicion is that if we were to ship the base MIB with = writeable >>>>>> objects, we may be forced to consider similar things for the >>>>>> extension >>>>> MIB(s). >>>>> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, = MPLS-TE >>>>> and BFD-MIB respectively, with write-access. Had to do = write-access >>>>> because of the reason you've mentioned above, which is base MIB. = It >>>>> would be painful to publish/support write-access MIB's when there = is >>>>> no clear interest. Hence my clarification question. >>>> This mentions three vendors wanting to implement MIB as writable. >>>>=20 >>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html >>>>=20 >>>> And one more vendor voicing for writable. >>>>=20 >>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html >>>>=20 >>>> I agree that defining & wording writable MIB is much more painful = than all >>> read-only MIB. But above thread indicates the desire by multiple = vendors to >>> implement writable BFD MIB. Therefore it does seem that there are >>> interests, and going forward with write-access will benefit the = community. >>> And with *ReadOnlyCompliance defined, BFD MIB can also accommodate >>> those implementing them as just read-only. >>>> -Nobo >>>>=20 >>>>> -sam >>>>>=20 >>>>>> -- Jeff >> . >>=20 >=20 >=20 --Apple-Mail=_CA1BA98C-0029-484D-835E-D8BB0151E3E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTURGvAAoJEPcO+I7eiUJZZdUP/2hj6JdK+vrnJ453vcz5vMtQ hUDqYKBE+thw5IfQ8M8dzqEm0cCEn885BVskoq/VPSfbmeWFTDUhcuQKjY5Oaf2E tAQZkr1erB3MxhI4iUr6on2pzHaNXfvJ3Q7pb16wK/mq+e7MILbNPYX3CdfpdKR5 LiJIAi40qA+1l2noIArF1kFc58HRqlZqj2tx51CVk0f4G/8TL+fT3kBcEa67QWdv HTirCYJU+zyEBEZkA5YXWYQJZW98eXa+2ta8rdR4hJ8C2o9sRAwgxmPjrfldUPVg DZkj99welxc4tAV1j7D3LrIuVYBrlM5SXXaeP90qVhWbLWlRI+B7oUB8L+QsT31e KaLb10AY8W7y/OkwOEjkqMt41Udx7GhkCr8VAdOHVV+Nq0Zwl3tA7373odf48Xxl DWkTyLdaZUJ1sj0oIEaWtYbmTowcpNW3ZRSob9GdLCgv9QYm4JQSPii1/2gCutMm wiqN3Uwfn/Hi4BAy/IT3IUajQ9YCPzB18GrnEWTAiFlrAfqlzjKo+/8JX6d5BVxc bVX0bWPVC/g61+ScskzqluSVXGgE+4dOr52/dHQ3/AJdrTdUT6kRHMGowW8KPP85 HvF+/+I4bjKrDrkAA2U9LIFmQedcf7KZ4EhMTSGY1wUWPXNkjDVwmRI8k8F1Ba2a Vm3F1kdHtkHwB2M3H6sm =AeIB -----END PGP SIGNATURE----- --Apple-Mail=_CA1BA98C-0029-484D-835E-D8BB0151E3E9-- From nobody Fri Apr 18 05:06:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05931A01F6; Fri, 18 Apr 2014 05:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZXkzubpP6WY; Fri, 18 Apr 2014 05:06:50 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6B91A0208; Fri, 18 Apr 2014 05:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5179; q=dns/txt; s=iport; t=1397822806; x=1399032406; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WMcgKt5iEVVOziy2T0Qu/vnY+NvLYvE0yk6xHct/scg=; b=DvcK+m+JKy2TbUZducgPC4glzQRmHCKUUID1pFs0yI7Vth6DUiRgvQaV D1YhdSRFveJARXZP7R5nd/sRxIOE3R9Dlxydz2qsozi7sGMPdBwyvVFZC grN2V16vzmQHTTDgjCDLRxWj9/YKIQCZ9qd31wU+eF1S7/GLtnjM3fTCv 0=; X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="14946174" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 18 Apr 2014 12:06:45 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3IC6i88025687; Fri, 18 Apr 2014 12:06:44 GMT Message-ID: <53511554.2000402@cisco.com> Date: Fri, 18 Apr 2014 14:06:44 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Thomas Nadeau Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <051b01cf5a87$b92a84d0$2b7f8e70$@olddog.co.uk> <33536B2D-46AF-4828-9C2E-0F2349A80E44@gmail.com> <20140417221850.GD29430@pfrc> <8BA1120C-3C89-4F73-A937-D7C118704553@gmail.com> <7B5FD180-D744-415B-AA0E-12EB11AF7245@gmail.com> <5350F335.8020309@cisco.com> <33B44E73-320B-4FC9-8438-E471F605F318@lucidvision.com> In-Reply-To: <33B44E73-320B-4FC9-8438-E471F605F318@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PS8cMwtHbzU3tvMpOY4wBH6UPXU Cc: "ietf@ietf.org" , "Black, David" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , General Area Review Team X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 12:06:55 -0000 On 18/04/2014 13:51, Thomas Nadeau wrote: > On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise wrote: > >> On 18/04/2014 04:17, Nobo Akiya (nobo) wrote: >>> Hi Sam, >>> >>>> -----Original Message----- >>>> From: Sam K. Aldrin [mailto:aldrin.ietf@gmail.com] >>>> Sent: Thursday, April 17, 2014 9:24 PM >>>> To: Nobo Akiya (nobo) >>>> Cc: Jeffrey Haas; ietf@ietf.org; 'Black, David'; adrian@olddog.co.uk; rtg- >>>> bfd@ietf.org; Zafar Ali (zali); 'General Area Review Team' >>>> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 >>>> >>>> Hi Nobo, >>>> [sorry for the top post] >>>> >>>> Yes, this is an old MIB and was in existence for a long time. >>>> My only concern is with the new extension MIB's. If the base MIB (this MIB) >>>> has write access, future extension MIB's may be forced to support write- >>>> access. And that is the painful part, where community at large has not >>>> shown interest in developing write-access MIB's at IETF, lest >>>> implementation. >>>> >>>> I want to re-iterate again, I am not objecting or proposing an alternative >>>> option. Just wanted to get clarification, so that, we don't have to burn cycles >>>> and do the exercise again, when we have to review these new extension >>>> MIB's. >>> That's a good point, it would be good to have this clarified for future work. >>> >>> IMO: >>> >>> For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if gets included in the charter) should look into NETCONF/YANG (i.e. not extension to the BFD base MIB). >>> >>> For currently chartered BFD tasks, the BFD WG should continue with writable MIB. Large part of that is the BFD base & MPLS MIBs which [painful] writable effort is mostly done already. >> This is in essence what https://www.ietf.org/iesg/statement/writable-mib-module.html says. >> >> Regards, Benoit. > Yes, this is why we left the writable stuff in - and why I recently spent about 4 hours doing Adrian's edits around support of such things. Lets please put the discussion around read-write to bed for these two modules as they clearly were well under way and complete by the time the statement came out. No disagreement. Regards, B. > > --Tom > > > >>> -Nobo >>> >>>> -sam >>>> >>>> On Apr 17, 2014, at 6:04 PM, Nobo Akiya (nobo) wrote: >>>> >>>>> Hi Sam, >>>>> >>>>>>> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote: >>>>>>>> %sam - If this MIB allows write access, do you/WG anticipate, any >>>>>> extension to the MIB should also provide write-access as well? For >>>> example: >>>>>> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments >>>>>> this base MIB to support MPLS. It adds more confusion than solving >>>>>> the issue as base MIB supports write-access, but augmented/ MIB >>>> extension doesn't. >>>>>>>> As the BFD MIB authors were not supportive of write-access objects >>>>>>>> in >>>>>> the MIBs, why to have them in the first place? >>>>>>> As noted in earlier mailing list chatter, there is some support for >>>>>>> write access in existing implementations. Given the lack of >>>>>>> significant detail when pressed for the name of such an >>>>>>> implementation, I'm suspecting smaller vendor or internal >>>>>>> implementation. That's still sufficient to leave write available. >>>>>>> >>>>>>> Given that one of the original contexts of asking if we could remove >>>>>>> write was whether IETF was being asked to provide such a thing for >>>>>>> MPLS-TP with related impact on your extension MIB and the answer was >>>>>>> "no", that shouldn't be the main criteria. >>>>>> No. The context of my question is not related to MPLS-TP as such, but >>>>>> write- access support in general. >>>>>> I should have added 'clarification' in my earlier email. >>>>>>> My suspicion is that if we were to ship the base MIB with writeable >>>>>>> objects, we may be forced to consider similar things for the >>>>>>> extension >>>>>> MIB(s). >>>>>> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE >>>>>> and BFD-MIB respectively, with write-access. Had to do write-access >>>>>> because of the reason you've mentioned above, which is base MIB. It >>>>>> would be painful to publish/support write-access MIB's when there is >>>>>> no clear interest. Hence my clarification question. >>>>> This mentions three vendors wanting to implement MIB as writable. >>>>> >>>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html >>>>> >>>>> And one more vendor voicing for writable. >>>>> >>>>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html >>>>> >>>>> I agree that defining & wording writable MIB is much more painful than all >>>> read-only MIB. But above thread indicates the desire by multiple vendors to >>>> implement writable BFD MIB. Therefore it does seem that there are >>>> interests, and going forward with write-access will benefit the community. >>>> And with *ReadOnlyCompliance defined, BFD MIB can also accommodate >>>> those implementing them as just read-only. >>>>> -Nobo >>>>> >>>>>> -sam >>>>>> >>>>>>> -- Jeff >>> . >>> >> From nobody Fri Apr 18 06:13:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A31A0194; Thu, 17 Apr 2014 19:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXJNWw-pUZP6; Thu, 17 Apr 2014 19:48:09 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id ABBAE1A001E; Thu, 17 Apr 2014 19:48:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jk6KUMFGWhs0UB7t4U3v6bBAIYZ23zc1Fsy516gl3MSoVGCn9U/AHLlwE5XG0hMM; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.39] (helo=elwamui-little.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WayqJ-0007yr-En; Thu, 17 Apr 2014 22:47:55 -0400 Received: from 99.23.160.116 by webmail.earthlink.net with HTTP; Thu, 17 Apr 2014 22:47:55 -0400 Message-ID: <25276146.1397789275400.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Thu, 17 Apr 2014 19:47:55 -0700 (GMT-07:00) From: Randy Presuhn To: "Sam K. Aldrin" , "Nobo Akiya (nobo)" Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc8c1f0f3881847dfdf761c2c2f8dbc85f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.39 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/yTGWeWuK72pUv_C1xVq8-nAv6vY X-Mailman-Approved-At: Fri, 18 Apr 2014 06:13:24 -0700 Cc: "ietf@ietf.org" , "'Black, David'" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 02:48:10 -0000 Hi - >From: "Sam K. Aldrin" >Sent: Apr 17, 2014 6:24 PM ... >Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 ... >My only concern is with the new extension MIB's. >If the base MIB (this MIB) has write access, >future extension MIB's may be forced to support >write-access. And how, exactly, does the fact that a base MIB module permits write access force extension MIB modules to require (or even permit) write access? It's perfectly reasonable SMI to define an AUGMENTS table consisting entirely of read-only objects. Randy From nobody Fri Apr 18 06:13:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D4D1A0101; Thu, 17 Apr 2014 21:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEgl1aKCfVJI; Thu, 17 Apr 2014 21:37:57 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 29C2F1A0088; Thu, 17 Apr 2014 21:37:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TgJQePhp8ZEIoouz1h65UWPyEZqrEqCSR+hDr1FY+UMXONUTjvyPVsyCjSjNwJHk; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.160.116] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Wb0Yh-0004Eg-GT; Fri, 18 Apr 2014 00:37:51 -0400 Message-ID: <007101cf5ab8$77cf7280$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Sam K. Aldrin" References: <25276146.1397789275400.JavaMail.root@elwamui-little.atl.sa.earthlink.net> <4B03C974-91FE-48CC-AF82-A82517E106C0@gmail.com> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 Date: Thu, 17 Apr 2014 21:43:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbcc293d221268b88ce71ccdfb8fd2a570a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.116 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FxwhIOSHjJVjzq3E_RDGlxpModI X-Mailman-Approved-At: Fri, 18 Apr 2014 06:13:25 -0700 Cc: ietf@ietf.org, "'Black, David'" , rtg-bfd@ietf.org, "Zafar Ali \(zali\)" , 'General Area Review Team' X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 04:37:58 -0000 Hi - > From: "Sam K. Aldrin" ... > Sent: Thursday, April 17, 2014 9:53 PM > Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 ... > In order to support new functionality, we are extending/augmenting existing base > MIB and in addition some write-access objects as well. If we make those new > ones read-only objects, then only some objects or tables could be used with > write-access and these new objects (read-only) have to be configured differently. > In other words, full functionality cannot be provided. This got nothing to do with SMI. Then what's the problem? If the WG has consensus to add functionality, and that functionality logically requires a read-write MIB module of extension, the IESG policy already allows for such cases. Randy From nobody Fri Apr 18 07:40:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AD01A01BB for ; Fri, 18 Apr 2014 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J9QwSpjI5Jy for ; Fri, 18 Apr 2014 07:39:59 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id D2AC81A00B1 for ; Fri, 18 Apr 2014 07:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14484; q=dns/txt; s=iport; t=1397831995; x=1399041595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7F6jYBUTYjiVfNIm4wnAuSUWQ57GDPM8K/+jB0treSY=; b=WpW/m2ga8AyyOew9QIKTd7vC0wbt3OJAXIIYbHOjperHwaJSm4m91eXO Scfujjye1PtXFtEuHj/1uucXwkciE5ryMjW2p3lG0Dyi1dhFG4xtCafng vi2ALuZj/yvO3OMMJLBsaZOzYIPKueTfiAvkGSfJ1/MAB01IWdh2unrDp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFs4UVOtJA2K/2dsb2JhbABagmUhT1fDb4EdFnSCJQEBAQMBJxM/BQcEAgEIEQQBAQEKFAkHIREUCQgCBA4FCBOIEgMJCAEMxgMNhmsXiT2DDIFoMQcGgx6BFASXAIMli0eFUYMxgis X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="36927466" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 18 Apr 2014 14:39:54 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3IEdsfL013260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 14:39:54 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 09:39:54 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Topic: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) Thread-Index: AQHPOf6XS+Fwf+Ha1E+zfIqKPBSxkJrWVpMAgAEwYpCAAC46sIABCKhQgAArRoCAAII9YIAAeWMAgAFakACAALI6QIAA+YKAgALHwACAAAMxgIAAA9AA//+0uhCAAGGVgP//rSyAgABX74D//674YAAPAGYAALvcmgAAFVk34P//aNMAgAGnmYCAAFK4oIAA+ViAgAAMRICAAE90UIAAFnEggAAgw9CAAMIGAIAASljQgAIwxID//d6/0IAd/weA//Dd07A= Date: Fri, 18 Apr 2014 14:39:53 +0000 Message-ID: References: <20140319082501342601.778988ca@sniff.de> <20211F91F544D247976D84C5D778A4C32E5B50DD@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140321175433104493.12bf1506@sniff.de> <093ED17D-3805-46B4-8A58-8411B395C9E9@gmail.com> In-Reply-To: <093ED17D-3805-46B4-8A58-8411B395C9E9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/W9zVxMuiihNkj7flWTl-bPlt2rk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:40:04 -0000 Hi Sam, > Would it be better to see some references to use cases from the base > document? That way, it provides right context. Just a thought. draft-akiya-bfd-seamless-base-03 now references draft-aldrin-bfd-seamless-u= se-case document in the introduction section. If WG thinks it's beneficial = for the base draft to do more, ex: have a table describing how each use cas= e is addressed, we could also do that. Let's see. -Nobo > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Tuesday, April 08, 2014 2:27 PM > To: Nobo Akiya (nobo) > Cc: Marc Binderberger; Santosh P K; Bhatia, Manav (Manav); MALLIK > MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: Re: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) >=20 > Would it be better to see some references to use cases from the base > document? That way, it provides right context. Just a thought. >=20 > Cheers > Sam > Sent from my iPhone >=20 > > On Mar 23, 2014, at 7:56 AM, "Nobo Akiya (nobo)" > wrote: > > > > Hi Marc, et al, > > > >> * the authors of the draft write down what they have in mind for the > >> D bit and publish it as -03 draft. Seems this will require a closer > >> look at text details, so having it properly written down would be > >> great > > > > There has been many responses around this particular point (and thanks = to > all who has responded!), it would be a good idea to have a revised > document which provides a new starting baseline for further discussions. > Although at this point, *rough consensus* does seem to be D-bit approach. > We would place the D-bit as the solution, but place all other alternative= s in > the Appendix. > > > > The other thing which I would like to point out is that, we are activel= y > discussing the solution but not the use-cases ... many of us are > engineers!? :) What would be helpful to take S-BFD to the next step (i.e.= re- > chartering and WG adoption) is for us to discuss more of use-cases on the > list. > > > > Thus I'd like to direct some of the attention to the S-BFD use-case dra= ft. > > > > http://tools.ietf.org/html/draft-aldrin-bfd-seamless-use-case-00 > > > > Do you [not] agree with use-cases listed? > > Do you see any other use-cases which should be added? > > Even a comment such as "I agree with this use-case from the draft" is v= ery > helpful. > > > > -Nobo > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Friday, March 21, 2014 8:55 PM > >> To: Nobo Akiya (nobo); Santosh P K; Bhatia, Manav (Manav); > >> aldrin.ietf@gmail.com; MALLIK MUDIGONDA (mmudigon) > >> Cc: rtg-bfd@ietf.org > >> Subject: RE: Loop Prevention in S-BFD (draft-akiya-bfd-seamless-base) > >> > >> Hello, > >> > >> may I propose two things: > >> > >> * the authors of the draft write down what they have in mind for the > >> D bit and publish it as -03 draft. Seems this will require a closer > >> look at text details, so having it properly written down would be > >> great > >> > >> > >> * the discussion about the loop prevention should be completed, there > >> are several proposals open. I would like to see what options are > >> available. Sure, when the authors found a clean path for the "D" bit > >> then this is somewhat academic but so far the discussion isn't > >> finished, I think > >> > >> * the discriminator proposal. I will re-re-read it but have still > >> problems to see why the my_discr of a packet received by the initiator= is > used for ... > >> multiplexing? Something else? Sorry, I may be slow thinking here. > >> > >> * Girija proposal to use the state. As S-BFD introduces a new state > >> machine this seems a valid proposal. Haven't seen any reply on the > >> list (beside > >> myself) > >> > >> * my "Required Min Echo RX Interval" proposal. If it's wrong or > >> "weird" I would like to learn about it. > >> > >> * Greg's source UDP port idea (if I understand it right: reflector > >> uses S-BFD port as source port + rule: never reflect when source port > >> is the well-known S-BFD port). > >> > >> > >> Basically a summary with why it won't work or at least pros/cons? > >> > >> > >> > >> Thanks & Regards, > >> Marc > >> > >> > >> > >> > >> > >>> On Thu, 20 Mar 2014 11:40:54 +0000, Nobo Akiya (nobo) wrote: > >>> Hi Santosh, > >>> > >>>>> If implementation shares the local discriminator pool between BFD > >>>>> and S-BFD, then session object located with your_discrim in > >>>>> incoming packet will provide the bfd.SessionType. > >>>> > >>>> If pool is shared then how can your_disc help to get the sessionType= ? > >>>> Did you mean not share pool between BFD and S-BFD? > >>> > >>> If we mimic the logic from multipoint draft, it would be something > >>> like this. > >>> > >>> If the Your Discriminator field is nonzero > >>> > >>> Select a session based on the value of Your Discriminator. > >>> If no session is found, the packet MUST be discarded. > >>> > >>> If bfd.SessionType is SBFDInitiator > >>> > >>> If Demand (D) bit is set, the packet MUST be discarded. > >>> > >>> Else if bfd.sessionType is SBFDReflector > >>> > >>> If Demand (D) bit is clear, the packet MUST be discarded. > >>> > >>> Else (non S-BFD) > >>> > >>> ... > >>> > >>> -Nobo > >>> > >>>> -----Original Message----- > >>>> From: Santosh P K [mailto:santoshpk@juniper.net] > >>>> Sent: Thursday, March 20, 2014 7:01 AM > >>>> To: Nobo Akiya (nobo); Bhatia, Manav (Manav); Marc Binderberger > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: RE: Loop Prevention in S-BFD > >>>> (draft-akiya-bfd-seamless-base) > >>>> > >>>> Nobo, > >>>> I am confused with your statement below. Can you please clarify? > >>>> > >>>> > >>>>> If implementation shares the local discriminator pool between BFD > >>>>> and S-BFD, then session object located with your_discrim in > >>>>> incoming packet will provide the bfd.SessionType. > >>>> > >>>> If pool is shared then how can your_disc help to get the sessionType= ? > >>>> Did you mean not share pool between BFD and S-BFD? > >>>> > >>>> > >>>> Thanks > >>>> Santosh P K > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>>>> Akiya > >>>>> (nobo) > >>>>> Sent: Thursday, March 20, 2014 6:20 AM > >>>>> To: Bhatia, Manav (Manav); Marc Binderberger > >>>>> Cc: rtg-bfd@ietf.org > >>>>> Subject: RE: Loop Prevention in S-BFD > >>>>> (draft-akiya-bfd-seamless-base) > >>>>> > >>>>> Agree with Manav. > >>>>> > >>>>> One nit and one clarification. > >>>>> > >>>>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD > >>>>>> reflector to reflect the S-BFD packets that it receives. The > >>>>>> S-BFD reflectors should discard all packets that come with the D b= it > clear. > >>>>> > >>>>> s/The S-BFD reflectors should discard/The S-BFD reflectors MUST > >>>>> discard/ > >>>>> > >>>>>> Please note that we will always know the S-BFD clients/reflectors > >>>>>> since they would use a new UDP port. > >>>>> > >>>>> If implementation shares the local discriminator pool between BFD > >>>>> and S-BFD, then session object located with your_discrim in > >>>>> incoming packet will provide the bfd.SessionType. In this > >>>>> implementation, non-IP based S-BFD can be supported without new > >>>>> G-Ach code point for S-BFD. If implementation does not share the > >>>>> local discriminator pool between BFD and S-BFD, then UDP port is > >>>>> required to first figure out which table to lookup the session > >>>>> object, in which case will provide BFD or S-BFD answer. In this > >>>>> implementation, non-IP based S- BFD will require separate G-Ach > >>>>> code point than BFD (but one new G-Ach code point for S-BFD should > >>>>> be sufficient). We should probably assume that the > >>>> latter is needed. > >>>>> > >>>>> -Nobo > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Bhatia, Manav (Manav) > >>>>>> [mailto:manav.bhatia@alcatel-lucent.com] > >>>>>> Sent: Wednesday, March 19, 2014 8:01 PM > >>>>>> To: Nobo Akiya (nobo); Marc Binderberger > >>>>>> Cc: rtg-bfd@ietf.org > >>>>>> Subject: RE: Loop Prevention in S-BFD > >>>>>> (draft-akiya-bfd-seamless-base) > >>>>>> > >>>>>> Adding on top of what Nobo has already said. > >>>>>> > >>>>>> New bfd.SessionType variables can be defined for S-BFD clients > >>>>>> and reflectors. The S-BFD draft will update the "D" bit based on > >>>>>> the bfd.SessionType variable. This requires no other changes to > 5880/5881. > >>>>>> The S-BFD draft should unequivocally define what the "D" bit > >>>>>> means in the context of the S-BFD packets. > >>>>>> > >>>>>> It can still be called the "D" (demand) bit and will be redefined > >>>>>> to something like below: > >>>>>> > >>>>>> Demand (D) > >>>>>> > >>>>>> S-BFD clients MUST always set the "D" bit which directs the S-BFD > >>>>>> reflector to reflect the S-BFD packets that it receives. The > >>>>>> S-BFD reflectors should discard all packets that come with the D b= it > clear. > >>>>>> > >>>>>> S-BFD clients MUST always ignore packets coming with the "D" bit s= et. > >>>>>> > >>>>>> Please note that we will always know the S-BFD clients/reflectors > >>>>>> since they would use a new UDP port. > >>>>>> > >>>>>> I like this approach over the one that uses descriminator values > >>>>>> simply because examining a bit to detect a loop is much easier to > >>>>>> implement in hardware. Looking at the descriminator values and > >>>>>> then detecting a loop cannot be easily done in HW. > >>>>>> > >>>>>> Since the approach using the "D" bit seems to be acceptable to > >>>>>> quite a few folks here, I would like to understand the reason, if > >>>>>> any, for > >>>> opposing this. > >>>>>> > >>>>>> Cheers, Manav > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>>>>>> Nobo Akiya > >>>>>>> (nobo) > >>>>>>> Sent: Wednesday, March 19, 2014 9:22 PM > >>>>>>> To: Marc Binderberger; MALLIK MUDIGONDA (mmudigon) > >>>>>>> Cc: rtg-bfd@ietf.org > >>>>>>> Subject: RE: Loop Prevention in S-BFD > >>>>>>> (draft-akiya-bfd-seamless-base) > >>>>>>> > >>>>>>>> we will see how the discussion goes although I personally do > >>>>>>>> not > >>>>>>> think the > >>>>>>>> M and D bit can be compared. Seems other people didn't see D a > >>>>>>>> good > >>>>>>> fit > >>>>>>>> (formally) either. Anyway, I'll have a look again at the "M" > >>>>>>>> bit and > >>>>>>> the > >>>>>>>> multipoint draft. > >>>>>>> > >>>>>>> You are right Marc, M and D bit alone is not a good comparison. > >>>>>>> However, it's not just M bit that's updated in the multipoint dra= ft. > >>>>>>> Multipoint draft updates M bit, introduces new state variables > >>>>>>> (bfd.SessionType) and updates RX procedures. > >>>>>>> > >>>>>>> Take a look at following sections in the multipoint draft. > >>>>>>> 4.4.1. New State Variable > >>>>>>> 4.16.1. Reception of BFD Control Packets 4.16.2. Demultiplexing > >>>>>>> BFD Control Packets > >>>>>>> > >>>>>>> Since your_discrim in S-BFD (both directions) is never zero(0), > >>>>>>> bfd.SessionType is derivable for all cases. And D bit check can > >>>>>>> be added for new bfd.SessionType values defined for S-BFD (both > >>>>>>> directions), as part of RX procedures. Not only this approach > >>>>>>> doesn't require BFDv2, it also addresses the point raised by Greg > (i.e. > >>>>>>> support for non-IP based S-BFD). > >>>>>>> > >>>>>>> -Nobo > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Marc Binderberger [mailto:marc@sniff.de] > >>>>>>>> Sent: Wednesday, March 19, 2014 11:25 AM > >>>>>>>> To: MALLIK MUDIGONDA (mmudigon) > >>>>>>>> Cc: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); rtg- > >>>>>>>> bfd@ietf.org > >>>>>>>> Subject: Re: Loop Prevention in S-BFD > >>>>>>>> (draft-akiya-bfd-seamless-base) > >>>>>>>> > >>>>>>>> Hello Mallik, > >>>>>>>> > >>>>>>>> we will see how the discussion goes although I personally do > >>>>>>>> not > >>>>>>> think the > >>>>>>>> M and D bit can be compared. Seems other people didn't see D a > >>>>>>>> good > >>>>>>> fit > >>>>>>>> (formally) either. Anyway, I'll have a look again at the "M" > >>>>>>>> bit and > >>>>>>> the > >>>>>>>> multipoint draft. > >>>>>>>> > >>>>>>>> > >>>>>>>>> Regarding the discriminator usage for solving this, we do not > >>>>>>>>> want > >>>>>>> to > >>>>>>>>> put any specific restrictions on the way discriminators are use= d. > >>>>>>>> > >>>>>>>> what restriction? > >>>>>>>> > >>>>>>>>> That's the reason the thread stopped there. Can't think of any > >>>>>>>>> particular use case where MyDisc is used to demux, but that's > >>>>>>>>> the reason not to impose this restriction. > >>>>>>>> > >>>>>>>> Huh?! There is some misunderstanding here, so let me repeat > >>>>>>>> the discriminator idea: > >>>>>>>> > >>>>>>>> (1) S-BFD initiator R1 sends a BFD packet to reflector R2 > >>>>>>>> > >>>>>>>> (2) Reflector R2 copies the my_discr from incoming packet into > >>>>>>> your_discr > >>>>>>>> for outgoing packet. > >>>>>>>> > >>>>>>>> (3) Reflector R2 copies one of his local discriminator values > >>>>>>>> into > >>>>>>> my_discr of > >>>>>>>> the outgoing packet. This local discriminator is not a > >>>>>>>> "reflector discriminator" of R2. > >>>>>>>> > >>>>>>>> (4) The S-BFD initiator R1 is doing normal BFD operations by > >>>>>>>> looking > >>>>>>> into the > >>>>>>>> your_discr of the reflected packet to demux. > >>>>>>>> > >>>>>>>> Especially R1 is not using "my_discr" of the reflected packet > >>>>>>>> to > >>>>>>> demux. > >>>>>>>> > >>>>>>>> The point is: when someone is injecting an "endless loop" > >>>>>>>> packet by > >>>>>>> using > >>>>>>>> the "reflector discriminator" of R1 as my_discr, the reflector > >>>>>>> discriminator of > >>>>>>>> R2 as your_discr and sends the packet to R2 then the steps > >>>>>>>> above > >>>>>>> result in a > >>>>>>>> packet > >>>>>>>> > >>>>>>>> attacker -> R2 -> R1 -> R2 -> drop/punt > >>>>>>>> > >>>>>>>> So after maximum 2 reflections the loop is broken. > >>>>>>>> > >>>>>>>> > >>>>>>>> Regards, Marc > >>> From nobody Mon Apr 21 13:19:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA6D1A02A0 for ; Mon, 21 Apr 2014 13:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oVNsn7xTU2I for ; Mon, 21 Apr 2014 13:19:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 109401A0281 for ; Mon, 21 Apr 2014 13:19:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 157A6C220; Mon, 21 Apr 2014 16:19:38 -0400 (EDT) Date: Mon, 21 Apr 2014 16:19:38 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: draft-ietf-bfd-intervals IANA considerations? Message-ID: <20140421201938.GD8955@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/yqE4LCkMuFli8LVeXpmZlNPMU_8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 20:19:44 -0000 WG, > Authors of draft-ietf-bfd-intervals have discussed and concluded that > defined "common intervals set" does _not_ need to be maintained by IANA. > > Reasons: > 1. Document is an informational draft. > 2. Additions of interval(s) in the "common intervals set" should anyways be > done through a new draft, whether or not draft-ietf-bfd-intervals creates an > IANA registry and defines allocation policies for it. > > Do you agree with this? > Do you see any concern with this? > > Seeking opinions/comments from folks on this matter. After seeking WG commentary, my conclusion is that there's no strong consensus to create an IANA registry at this time. If, at a later time, additional documents give rise to a need for such a registry, we can do the work at that time. Consulting with our Area Director, Adrian, about this, he concurs that it's okay. He does suggest the authors add a short sentence or two to the document about the reasoning. (Effectively, "here's why we have no IANA considerations...") I would also note that there's been relatively little other commentary about the suggested timings in the draft. While the submitted milestone to our AD was January 2015, there may cause to declare sufficient consensus to do a WGLC for the upcoming IETF session. Thus, please review your implementations against the recommended timing intervals and provide commentary to this I-D. -- Jeff From nobody Mon Apr 21 13:33:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3E31A029B for ; Mon, 21 Apr 2014 13:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgZFCB-bZMau for ; Mon, 21 Apr 2014 13:33:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF6E1A0281 for ; Mon, 21 Apr 2014 13:33:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2FADDC220; Mon, 21 Apr 2014 16:33:14 -0400 (EDT) Date: Mon, 21 Apr 2014 16:33:14 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Working Group adoption for Seamless BFD (requires re-charter) Message-ID: <20140421203314.GF8955@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/JPFxkyAz64Ocf1FPTqMYiPnNSic X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 20:33:20 -0000 Working Group, >From our last in-person IETF meeting in Vancouver, the S-BFD authors were going to put additional work into their use cases and base protocol document prior to requesting Working Group adoption. That work has since been done and, IMO, the quality of the documents has nicely improved. But, being IETF work, we'd like to carry out further work on the proposal in the openness of the WG. Thus, I'd like to request the Working Group to consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. Note that this work is currently outside the scope of our charter and would require a re-charter. Once we have a sense of the group for the interest in this task we'll propose the charter update in support of the drafts. The following two documents are current and describe the work: http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ Given the scope of this feature, I would like to particularly remind the Working Group to focus on its security aspects. The following three documents are slightly stale as a result of the revisions in the base and use cases draft and will require an update. However, they provide a sense of how the S-BFD mechanisms might be used. Note in particular that the SR work will require coordination with the SPRING Working Group. http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ Finally, there is known future work targeting the distribution of the necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have been authored on the topic at this time, but work on them is expected. This begins a two week poll on whether the WG would like to adopt S-BFD as a chartered task. This poll ends on May 6. As part of your response, please indicate if you have specific concerns about individual drafts being part of this work. Since Nobo is a contributor to this work, I will be taking the part of the shepherding chair. -- Jeff From nobody Mon Apr 21 13:46:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63481A02A3 for ; Mon, 21 Apr 2014 13:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQQB6mdbnq07 for ; Mon, 21 Apr 2014 13:46:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EE21A02A9 for ; Mon, 21 Apr 2014 13:46:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421204602.14715.37711.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 13:46:02 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2Ej96lXBaOkYZ58ARG60GRdWnNA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:46:03 -0000 URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Mon Apr 21 13:46:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FAF1A02A3 for ; Mon, 21 Apr 2014 13:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-m7stwDsCIi for ; Mon, 21 Apr 2014 13:46:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B4B1A02B2 for ; Mon, 21 Apr 2014 13:46:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421204649.25127.53543.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 13:46:49 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8-x37CWHh7g7acSKi1NSuYZbRQ8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:46:53 -0000 Changed milestone "Submit the BFD MIB to the IESG to be considered as a Proposed Standard", resolved as "Done". URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Mon Apr 21 13:51:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE18A1A02BD for ; Mon, 21 Apr 2014 13:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWyqVQ9gPuWh for ; Mon, 21 Apr 2014 13:51:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5E1A02B8 for ; Mon, 21 Apr 2014 13:51:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421205139.19690.33614.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 13:51:39 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/GGoBqqw-iPTFRfrHnEmmVyLfThs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:51:42 -0000 Changed milestone "Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Mon Apr 21 16:28:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFF71A030B for ; Mon, 21 Apr 2014 16:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7pLKs6_-th6 for ; Mon, 21 Apr 2014 16:28:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE91A02B6 for ; Mon, 21 Apr 2014 16:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3672; q=dns/txt; s=iport; t=1398122904; x=1399332504; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=f5ikpRoyWiK5yNKFpH3if2MVu6K/dWPJdHLMpLZI/LM=; b=N2l2obejmiDbuDEzqdZ2PmIfj13+sRbZiVeHB2f7e6CLezzyGNGgVhrb 7EpgaKlT/sd2M702HXC8A7UkpwD2WCGMdIjMY1IMA/SYkSKiqe1SwVTei rSsk2b8ilrF+IR3Vg79+GJ4g22QsaXyNtT1KVOmieYYbJ93DQjtPbkTpn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAOCoVVOtJV2b/2dsb2JhbABZgmUhT1fEEoEfFnSCJQEBAQMBOkQHBAIBCA4DBAEBCxQJBzIUCQgCBAESCIgxCAEMzTUXjhQdOAaDHoEUBJolkRiDMYIr X-IronPort-AV: E=Sophos;i="4.97,898,1389744000"; d="scan'208";a="319317050" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 21 Apr 2014 23:28:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3LNSMXR028994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 23:28:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 18:28:22 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDzsd8RqfWJjUqW3c8k2YnCwZsctAGw Date: Mon, 21 Apr 2014 23:28:21 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aTxQJq0XwLlPywR0LsR0SM81ynA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 23:28:37 -0000 Hi Jeff, Yes/support. Being able to verify BFD up state "when needed" addresses the demand of upc= oming applications, and flexibilities given to ingress truly harnesses the = power of BFD. > As part of your response, please indicate if you have specific concerns a= bout > individual drafts being part of this work. I believe both use-case and base drafts are in good shape for WG adoption. = If we re-charter, then I vote we focus on the use-case and base documents f= irst. Afterwards, if/when required, then *-ip/*-sr/*-alert-discrim drafts c= an be revisited to describe technology specific procedures or extensions. > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts ha= ve > been authored on the topic at this time, but work on them is expected. Agree. Several folks have already expressed interest to take these up. If S= -BFD gets included in the BFD WG charter, I think that'll be a good timing = to kick off these tasks. -Nobo, as individual contributor > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, April 21, 2014 4:33 PM > To: rtg-bfd@ietf.org > Subject: Working Group adoption for Seamless BFD (requires re-charter) >=20 > Working Group, >=20 > >From our last in-person IETF meeting in Vancouver, the S-BFD authors > >were > going to put additional work into their use cases and base protocol > document prior to requesting Working Group adoption. That work has since > been done and, IMO, the quality of the documents has nicely improved. >=20 > But, being IETF work, we'd like to carry out further work on the proposal= in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and wou= ld > require a re-charter. Once we have a sense of the group for the interest= in > this task we'll propose the charter update in support of the drafts. >=20 > The following two documents are current and describe the work: >=20 > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >=20 > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. >=20 > The following three documents are slightly stale as a result of the revis= ions > in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be > used. >=20 > Note in particular that the SR work will require coordination with the > SPRING Working Group. >=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >=20 > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts ha= ve > been authored on the topic at this time, but work on them is expected. >=20 > This begins a two week poll on whether the WG would like to adopt S-BFD > as a chartered task. This poll ends on May 6. >=20 > As part of your response, please indicate if you have specific concerns a= bout > individual drafts being part of this work. >=20 > Since Nobo is a contributor to this work, I will be taking the part of th= e > shepherding chair. >=20 > -- Jeff From nobody Mon Apr 21 16:41:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06F11A0324 for ; Mon, 21 Apr 2014 16:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_abDbD0eOE4 for ; Mon, 21 Apr 2014 16:41:47 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A90FD1A031F for ; Mon, 21 Apr 2014 16:41:47 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lf10so4273152pab.27 for ; Mon, 21 Apr 2014 16:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ueBzrg2hR8NazY6X8pMsGbR6QhzGBuF/+zDQiv+j47c=; b=lzK1i8UhKLXn9Ni7JYDE8GBer4rh87MpPnVALu6j2ZmtDd+6Nu37jUdXrAAdoRa+Fk om82xgpw2exGBj9C6wozNM92ANw97QtUCmVQ3QNSsUvN84vx7UgqzAbEr1V9g/ds/RNB K2q6p5anUtSMitmzTFpE/kKyRsl0dz1U0e1Nnh20RLOXzKebfCjROAJHIPfrAK/tbHv7 FgRtPyB02Qaorp74GqNIFGMjhRFN4BlC/ZCbkxaX0vPAq7G+guvfgDHABQLkpqEaDiIO mFhWf3cAIHf+EJHcyW/cnKslJ++72uIHzV53EmZMCzQL8cHTX5gr4b2q784X5ut85JJ5 xfLA== X-Received: by 10.67.23.135 with SMTP id ia7mr40936980pad.5.1398123702556; Mon, 21 Apr 2014 16:41:42 -0700 (PDT) Received: from [192.168.1.5] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id om6sm80566845pbc.43.2014.04.21.16.41.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 16:41:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) From: Sam Aldrin In-Reply-To: <20140421203314.GF8955@pfrc> Date: Mon, 21 Apr 2014 16:41:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CF50B7B-8DE5-471C-B967-5C7FA9E6D326@gmail.com> References: <20140421203314.GF8955@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NVgzwh0kMXt1oHbNk5d-1jtx7g8 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:41:52 -0000 WG chairs, I support re-chartering the BFD WG to take up S-BFD work as it is = important piece of OAM work useful in many areas like SPRING, SFC etc. Would also like to support the adoption of the use-case and base = documents for S-BFD. cheers -sam On Apr 21, 2014, at 1:33 PM, Jeffrey Haas wrote: > Working Group, >=20 >> =46rom our last in-person IETF meeting in Vancouver, the S-BFD = authors were > going to put additional work into their use cases and base protocol = document > prior to requesting Working Group adoption. That work has since been = done > and, IMO, the quality of the documents has nicely improved. >=20 > But, being IETF work, we'd like to carry out further work on the = proposal in > the openness of the WG. Thus, I'd like to request the Working Group = to > consider whether we'll want to adopt the Seamless BFD (S-BFD) = documents. > Note that this work is currently outside the scope of our charter and = would > require a re-charter. Once we have a sense of the group for the = interest in > this task we'll propose the charter update in support of the drafts. >=20 > The following two documents are current and describe the work: >=20 > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >=20 > Given the scope of this feature, I would like to particularly remind = the > Working Group to focus on its security aspects. >=20 > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be = used. >=20 > Note in particular that the SR work will require coordination with the > SPRING Working Group. >=20 > = http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >=20 > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts = have > been authored on the topic at this time, but work on them is expected. >=20 > This begins a two week poll on whether the WG would like to adopt = S-BFD as a > chartered task. This poll ends on May 6. >=20 > As part of your response, please indicate if you have specific = concerns > about individual drafts being part of this work. >=20 > Since Nobo is a contributor to this work, I will be taking the part of = the > shepherding chair. >=20 > -- Jeff >=20 From nobody Mon Apr 21 16:53:39 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587C31A0322 for ; Mon, 21 Apr 2014 16:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECwq07k9meDz for ; Mon, 21 Apr 2014 16:53:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5631A031A for ; Mon, 21 Apr 2014 16:53:36 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-a9-53556107b4c4 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 05.6C.05011.80165535; Mon, 21 Apr 2014 20:18:48 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Mon, 21 Apr 2014 19:53:29 -0400 From: Gregory Mirsky To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDvMXJp+MLZhkqjPIr07S88qZscvaLw Date: Mon, 21 Apr 2014 23:53:29 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7A40FE@eusaamb103.ericsson.se> References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPrC5HYmiwwflzIhb7D75ltfj8Zxuj A5PHkiU/mTwu925lDWCK4rJJSc3JLEst0rdL4Mq43L6DpeC/SMXhbUdYGxj7BbsYOTkkBEwk vp+ewQhhi0lcuLeerYuRi0NI4CijxKEjMM5yRon/r/pZQarYBIwkXmzsYQexRQQ8JLqPPQfr Fhbwkli04BcrRNxbYuW194wQtpHErFcNYHEWAVWJbad3AvVycPAK+Eo8XqwCEhYS0JDYtaQT rIRTQFPi05rzbCA2I9BB30+tYQKxmQXEJW49mc8EcaiAxJI955khbFGJl4//sULYihL7+qez Q9TrSCzY/YkNwtaWWLbwNVg9r4CgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw3 3chgEyMwGo5JsOnuYNzz0vIQowAHoxIP75TrvsFCrIllxZW5hxilOViUxHm/vHUOEhJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cBosXjrq77NDU/kJWZ+MQu0WpYcfqv2/KGzW5rS9mcHKh4Q UToT2GH8dpnn50Lb3ZO3cwdW7b4SvMytsdJN8nhmlXr3mTX9b+WYTPwPOterpH4IvdMw59+d 1xbtglo71qfcPTD7pHGms//89j1ewfJBbVIn7jRIsd2dsjSrZ3pRg/A1bdFZK/cosRRnJBpq MRcVJwIAaubGx2cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4M3u8U5s55qacjFj0uPwciQaJgU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 23:53:38 -0000 Dear WG chairs, et. al, I support re-chartering of the BFD WG to include work on Seamless BFD to be= in WG charter scope. Also, I support adoption of the listed drafts by the WG (co-author on use-c= ase). Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, April 21, 2014 1:33 PM To: rtg-bfd@ietf.org Subject: Working Group adoption for Seamless BFD (requires re-charter) Working Group, >From our last in-person IETF meeting in Vancouver, the S-BFD authors=20 >were going to put additional work into their use cases and base protocol documen= t prior to requesting Working Group adoption. That work has since been don= e and, IMO, the quality of the documents has nicely improved. But, being IETF work, we'd like to carry out further work on the proposal i= n the openness of the WG. Thus, I'd like to request the Working Group to c= onsider whether we'll want to adopt the Seamless BFD (S-BFD) documents. Note that this work is currently outside the scope of our charter and would= require a re-charter. Once we have a sense of the group for the interest = in this task we'll propose the charter update in support of the drafts. The following two documents are current and describe the work: http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ Given the scope of this feature, I would like to particularly remind the Wo= rking Group to focus on its security aspects. The following three documents are slightly stale as a result of the revisio= ns in the base and use cases draft and will require an update. However, they provide a sense of how the S-BFD mechanisms might be used. Note in particular that the SR work will require coordination with the SPRI= NG Working Group. http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ Finally, there is known future work targeting the distribution of the neces= sary S-BFD bootstrapping information in OSPF and ISIS. No drafts have been= authored on the topic at this time, but work on them is expected. This begins a two week poll on whether the WG would like to adopt S-BFD as = a chartered task. This poll ends on May 6. As part of your response, please indicate if you have specific concerns abo= ut individual drafts being part of this work. Since Nobo is a contributor to this work, I will be taking the part of the = shepherding chair. -- Jeff From nobody Mon Apr 21 16:59:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCA81A032C for ; Mon, 21 Apr 2014 16:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRF7UqLNCGlw for ; Mon, 21 Apr 2014 16:59:12 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CBE431A032B for ; Mon, 21 Apr 2014 16:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2333; q=dns/txt; s=iport; t=1398124748; x=1399334348; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=e/OOTVolOow6zpEeX9hJr9v7F/K3KUukeTeE2G/+Vkc=; b=CqDgJtW7zxdwZMel5aJwikLMBggL3S6Tz0CuevW1HzCP8KcIDKEqTSMO iUj1HOuGMe0lMeEk9XMjR5WgN/r6vhipq26pI4vJqTs0ZMLlJOwKmYu7j Ujk4QI9pJeCFVc7RfzFJDLf+rcw08CBoyISOkHPjEwVO++OVt0wBgrUpw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAGKwVVOtJA2H/2dsb2JhbABZgwZPV8UyFnSCLDpRAQgOKEInBAESiEENzRsXkyEEmG6BN5EYgzGCKw X-IronPort-AV: E=Sophos;i="4.97,899,1389744000"; d="scan'208";a="319347617" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 21 Apr 2014 23:58:56 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3LNwtbF020308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 23:58:56 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.199]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 18:58:00 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDyh9qeNvXt9EuOKG7MlJ26rZsczrEA Date: Mon, 21 Apr 2014 23:58:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.70.45] Content-Type: text/plain; charset="us-ascii" Content-ID: <050F10FB5FA35041B0A00748636FFA0E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nmzayXAXtmD5OU3p4PJtL5F72HQ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 23:59:15 -0000 Support. Regards, Nagendra On 4/21/14 4:33 PM, "Jeffrey Haas" wrote: >Working Group, > >>From our last in-person IETF meeting in Vancouver, the S-BFD authors were >going to put additional work into their use cases and base protocol >document >prior to requesting Working Group adoption. That work has since been done >and, IMO, the quality of the documents has nicely improved. > >But, being IETF work, we'd like to carry out further work on the proposal >in >the openness of the WG. Thus, I'd like to request the Working Group to >consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. >Note that this work is currently outside the scope of our charter and >would >require a re-charter. Once we have a sense of the group for the interest >in >this task we'll propose the charter update in support of the drafts. > >The following two documents are current and describe the work: > >http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > >Given the scope of this feature, I would like to particularly remind the >Working Group to focus on its security aspects. > >The following three documents are slightly stale as a result of the >revisions in the base and use cases draft and will require an update. >However, they provide a sense of how the S-BFD mechanisms might be used. > >Note in particular that the SR work will require coordination with the >SPRING Working Group. > >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > >Finally, there is known future work targeting the distribution of the >necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts >have >been authored on the topic at this time, but work on them is expected. > >This begins a two week poll on whether the WG would like to adopt S-BFD >as a >chartered task. This poll ends on May 6. > >As part of your response, please indicate if you have specific concerns >about individual drafts being part of this work. > >Since Nobo is a contributor to this work, I will be taking the part of the >shepherding chair. > >-- Jeff From nobody Mon Apr 21 17:12:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B131A031F for ; Mon, 21 Apr 2014 17:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UztelXuKijGv for ; Mon, 21 Apr 2014 17:12:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8331A0321 for ; Mon, 21 Apr 2014 17:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2089; q=dns/txt; s=iport; t=1398125568; x=1399335168; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LlU+qYwmlROJbx2sv2hBtOKyUSVHfy0+NoWxP8kDgKU=; b=IsrWguNg9NXVz4Bbhk7+Y37W6dJGu0UBTde+YYmMGmuRtL/86CRAEyDN 5u0qJm4eYnmm69zMKhLcj7eZTdCHXGLednOdUM4/pNBSRX+qty+muKhkw LU6bDooe4lg3iy2vza9yyoVURpxp2KiF4WIIJxsHduEhTbzlp+B1UegBv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAOuyVVOtJA2E/2dsb2JhbABZgmUhgSbEEoEhFnSCJQEBAQMBOksEAgEIDgMEAQELFAkHMhQJCAIEARIIiDEIAc0pF44xOAaDHoEUAQOrPYMxgis X-IronPort-AV: E=Sophos;i="4.97,899,1389744000"; d="scan'208";a="319416047" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 22 Apr 2014 00:12:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s3M0ClQR031820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 00:12:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 19:12:47 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: draft-ietf-bfd-intervals IANA considerations? Thread-Topic: draft-ietf-bfd-intervals IANA considerations? Thread-Index: AQHPXZ8LwLhhKOV6lkuG9GvmQmyNVJscwY2Q Date: Tue, 22 Apr 2014 00:12:46 +0000 Message-ID: References: <20140421201938.GD8955@pfrc> In-Reply-To: <20140421201938.GD8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/sTTZWHhlDjy13QdWohHY9hSDlNU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 00:12:57 -0000 Hi Jeff, > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, April 21, 2014 4:20 PM > To: rtg-bfd@ietf.org > Subject: Re: draft-ietf-bfd-intervals IANA considerations? >=20 > WG, >=20 > > Authors of draft-ietf-bfd-intervals have discussed and concluded that > > defined "common intervals set" does _not_ need to be maintained by > IANA. > > > > Reasons: > > 1. Document is an informational draft. > > 2. Additions of interval(s) in the "common intervals set" should > > anyways be done through a new draft, whether or not > > draft-ietf-bfd-intervals creates an IANA registry and defines allocatio= n > policies for it. > > > > Do you agree with this? > > Do you see any concern with this? > > > > Seeking opinions/comments from folks on this matter. >=20 > After seeking WG commentary, my conclusion is that there's no strong > consensus to create an IANA registry at this time. If, at a later time, > additional documents give rise to a need for such a registry, we can do t= he > work at that time. Sounds like a reasonable approach. >=20 > Consulting with our Area Director, Adrian, about this, he concurs that it= 's > okay. He does suggest the authors add a short sentence or two to the > document about the reasoning. (Effectively, "here's why we have no IANA > considerations...") We (authors) will keep the "here's why" very short, but I'd like to take th= is opportunity to say thanks for all who have chimed in: thanks Sasha, Carl= os, Greg, Jeff, Donald! We will include this text in the next revision. >=20 > I would also note that there's been relatively little other commentary ab= out > the suggested timings in the draft. While the submitted milestone to our > AD was January 2015, there may cause to declare sufficient consensus to d= o > a WGLC for the upcoming IETF session. Thus, please review your > implementations against the recommended timing intervals and provide > commentary to this I-D. Agree. -Nobo >=20 > -- Jeff From nobody Mon Apr 21 18:55:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F851A0346 for ; Mon, 21 Apr 2014 18:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNSYIuA0cf7V for ; Mon, 21 Apr 2014 18:55:29 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 949D31A0341 for ; Mon, 21 Apr 2014 18:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2559; q=dns/txt; s=iport; t=1398131724; x=1399341324; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WSYPoXN6Jf/JzgnSOwDrNdQCx/KU7QtVCDq8pr0upBE=; b=Y7YGqiT0GO8/CbCoehiVMHdljxCSjSNNXBTGKt84mucdpnDPf4k1z3M1 wqCm//B4jJvPpOo0HA3AT4NlGoFo1LqtpnAQSJ0zzVbLvAkTJnhdEwFQe LqUPUMz7awJ1u0mXj71lCmTViMHRNJYSsgTwK5m9xujkl1v4Sdh+k+1RL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIrLVVOtJV2Y/2dsb2JhbABZgwZPV8QRgSAWdIIlAQEBBDpLBAIBCA4DBAEBCxQJBzIUCQgCBAESCIg5DcxeF44lOAaDHoEUBJolkRmDMYIr X-IronPort-AV: E=Sophos;i="4.97,900,1389744000"; d="scan'208";a="319370326" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 22 Apr 2014 01:55:23 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3M1tNs5022291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 01:55:23 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.122]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 20:55:23 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDzygfuPyL4GUWhQDNCisUNfpsc4DFA Date: Tue, 22 Apr 2014 01:55:23 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D33A52B75@xmb-rcd-x15.cisco.com> References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.37.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aabxhf9OiJlhqZOgr5rsHc8UwPE X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 01:55:34 -0000 Support the WG re-chartering and the WG adoption of the S-BFD use-case and = base drafts. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, April 22, 2014 2:03 AM To: rtg-bfd@ietf.org Subject: Working Group adoption for Seamless BFD (requires re-charter) Working Group, >From our last in-person IETF meeting in Vancouver, the S-BFD authors=20 >were going to put additional work into their use cases and base protocol documen= t prior to requesting Working Group adoption. That work has since been don= e and, IMO, the quality of the documents has nicely improved. But, being IETF work, we'd like to carry out further work on the proposal i= n the openness of the WG. Thus, I'd like to request the Working Group to c= onsider whether we'll want to adopt the Seamless BFD (S-BFD) documents. Note that this work is currently outside the scope of our charter and would= require a re-charter. Once we have a sense of the group for the interest = in this task we'll propose the charter update in support of the drafts. The following two documents are current and describe the work: http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ Given the scope of this feature, I would like to particularly remind the Wo= rking Group to focus on its security aspects. The following three documents are slightly stale as a result of the revisio= ns in the base and use cases draft and will require an update. However, they provide a sense of how the S-BFD mechanisms might be used. Note in particular that the SR work will require coordination with the SPRI= NG Working Group. http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ Finally, there is known future work targeting the distribution of the neces= sary S-BFD bootstrapping information in OSPF and ISIS. No drafts have been= authored on the topic at this time, but work on them is expected. This begins a two week poll on whether the WG would like to adopt S-BFD as = a chartered task. This poll ends on May 6. As part of your response, please indicate if you have specific concerns abo= ut individual drafts being part of this work. Since Nobo is a contributor to this work, I will be taking the part of the = shepherding chair. -- Jeff From nobody Mon Apr 21 19:07:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876231A0116 for ; Mon, 21 Apr 2014 19:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKpT67bYEe8p for ; Mon, 21 Apr 2014 19:07:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 989671A012D for ; Mon, 21 Apr 2014 19:07:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFX45430; Tue, 22 Apr 2014 02:07:32 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 03:06:38 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 03:07:29 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 10:07:26 +0800 From: Mach Chen To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDweuDMlS4BR0qrEqXQg783CZsc4rQg Date: Tue, 22 Apr 2014 02:07:25 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QPzmsw7XGJa52ySY2gOief9TK9g X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 02:07:41 -0000 Hi, I support the WG re-chartering to include S-BFD related works. And I also s= upport to adopt the base and use case documents as WG documents. Best regards, Mach > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, April 22, 2014 4:33 AM > To: rtg-bfd@ietf.org > Subject: Working Group adoption for Seamless BFD (requires re-charter) >=20 > Working Group, >=20 > >From our last in-person IETF meeting in Vancouver, the S-BFD authors > >were > going to put additional work into their use cases and base protocol docum= ent > prior to requesting Working Group adoption. That work has since been don= e > and, IMO, the quality of the documents has nicely improved. >=20 > But, being IETF work, we'd like to carry out further work on the proposal= in the > openness of the WG. Thus, I'd like to request the Working Group to consi= der > whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and wou= ld > require a re-charter. Once we have a sense of the group for the interest= in this > task we'll propose the charter update in support of the drafts. >=20 > The following two documents are current and describe the work: >=20 > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >=20 > Given the scope of this feature, I would like to particularly remind the = Working > Group to focus on its security aspects. >=20 > The following three documents are slightly stale as a result of the revis= ions in the > base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be used. >=20 > Note in particular that the SR work will require coordination with the SP= RING > Working Group. >=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >=20 > Finally, there is known future work targeting the distribution of the nec= essary > S-BFD bootstrapping information in OSPF and ISIS. No drafts have been > authored on the topic at this time, but work on them is expected. >=20 > This begins a two week poll on whether the WG would like to adopt S-BFD a= s a > chartered task. This poll ends on May 6. >=20 > As part of your response, please indicate if you have specific concerns a= bout > individual drafts being part of this work. >=20 > Since Nobo is a contributor to this work, I will be taking the part of th= e > shepherding chair. >=20 > -- Jeff From nobody Mon Apr 21 21:21:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821D11A0063 for ; Mon, 21 Apr 2014 21:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGxN0KTS-H29 for ; Mon, 21 Apr 2014 21:21:11 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5737A1A0059 for ; Mon, 21 Apr 2014 21:21:11 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-43-53559fb7f3d5 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.DF.05011.7BF95535; Tue, 22 Apr 2014 00:46:15 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 22 Apr 2014 00:20:57 -0400 From: Jeff Tantsura To: Jeffrey Haas Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDvvk5ap5Uux0uCxiAk/bFxhpsdCULB Date: Tue, 22 Apr 2014 04:20:57 +0000 Message-ID: <7AE46E72-CDD9-4FB0-98A7-C594B91EDCE5@ericsson.com> References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPgu72+aHBBqfmm1nsP/iW1eLzn22M DkweS5b8ZPK43LuVNYApissmJTUnsyy1SN8ugSvj0MGbbAU9whXXj+9gbmDcw9/FyMkhIWAi sfzudhYIW0ziwr31bF2MXBxCAkcZJU79fscM4SxnlFjZsJUVpIpNwEDi/7fjYB0iAooS8/93 soHYzAKaEk0nPrOD2MICXhJH/jexQtR4S6y89p4RwjaSaOk8B2azCKhKtP+aBjaHV8Be4tKq hWBzhAQ0JHYt6QTr5QSa+WnNebA4I9B130+tYYLYJS5x68l8JoirBSSW7DnPDGGLSrx8/I8V okZHYsHuT1C3aUssW/iaGWKXoMTJmU9YJjCKzkIyahaSlllIWmYhaVnAyLKKkaO0OLUsN93I YBMjMB6OSbDp7mDc89LyEKMAB6MSD++U677BQqyJZcWVuYcYpTlYlMR5v7x1DhISSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAOCFNV3R5ygHTA1qb+1+978xWqF32s/ryHIuVzpnrUo+5haRe z7N68dr72uq3vr/PTXRs3b/lYWfdon/XAhgK7nqLTz6m495SsFvxrsD8u2cq9r+SP3j7RoNc ybcF65hfsYp519cEG0+2v+X8zpZXLflVHd90LtfF6WLKPlO5a9z5vwR3rsgoV2Ipzkg01GIu Kk4EAD2o6fVoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hWcPacQ8GNS4e5gDdMexQgAzGuc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 04:21:15 -0000 Yes/support Regards, Jeff > On Apr 21, 2014, at 1:33 PM, "Jeffrey Haas" wrote: >=20 > Working Group, >=20 >> From our last in-person IETF meeting in Vancouver, the S-BFD authors wer= e > going to put additional work into their use cases and base protocol docum= ent > prior to requesting Working Group adoption. That work has since been don= e > and, IMO, the quality of the documents has nicely improved. >=20 > But, being IETF work, we'd like to carry out further work on the proposal= in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and wou= ld > require a re-charter. Once we have a sense of the group for the interest= in > this task we'll propose the charter update in support of the drafts. >=20 > The following two documents are current and describe the work: >=20 > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >=20 > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. >=20 > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be used. >=20 > Note in particular that the SR work will require coordination with the > SPRING Working Group. >=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >=20 > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts ha= ve > been authored on the topic at this time, but work on them is expected. >=20 > This begins a two week poll on whether the WG would like to adopt S-BFD a= s a > chartered task. This poll ends on May 6. >=20 > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. >=20 > Since Nobo is a contributor to this work, I will be taking the part of th= e > shepherding chair. >=20 > -- Jeff >=20 From nobody Mon Apr 21 23:32:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFACF1A0092 for ; Mon, 21 Apr 2014 23:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSIOw1ph0Zse for ; Mon, 21 Apr 2014 23:31:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9576D1A0055 for ; Mon, 21 Apr 2014 23:31:57 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s3M6Vhjt016875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Apr 2014 01:31:43 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s3M6Vgqi009373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 02:31:43 -0400 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 22 Apr 2014 02:31:42 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Tue, 22 Apr 2014 14:31:38 +0800 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaEM5uWqYbi+gUG+BsqNlP9i1JsdLX4w Date: Tue, 22 Apr 2014 06:31:37 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5F1E80@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BVim3z6Nc9qZ0jAc00X4a94UQ-Y X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 06:31:59 -0000 Hi, I support rechartering BFD WG to include S-BFD. Work on IS-IS and OSPF extensions has already started as we speak. Thanks, Manav > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey > Haas > Sent: Tuesday, April 22, 2014 2:03 AM > To: rtg-bfd@ietf.org > Subject: Working Group adoption for Seamless BFD (requires re-charter) >=20 > Working Group, >=20 > >From our last in-person IETF meeting in Vancouver, the S-BFD authors > were > going to put additional work into their use cases and base protocol > document > prior to requesting Working Group adoption. That work has since been > done > and, IMO, the quality of the documents has nicely improved. >=20 > But, being IETF work, we'd like to carry out further work on the > proposal in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) > documents. > Note that this work is currently outside the scope of our charter and > would > require a re-charter. Once we have a sense of the group for the > interest in > this task we'll propose the charter update in support of the drafts. >=20 > The following two documents are current and describe the work: >=20 > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >=20 > Given the scope of this feature, I would like to particularly remind > the > Working Group to focus on its security aspects. >=20 > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be > used. >=20 > Note in particular that the SR work will require coordination with the > SPRING Working Group. >=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >=20 > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts > have > been authored on the topic at this time, but work on them is expected. >=20 > This begins a two week poll on whether the WG would like to adopt S-BFD > as a > chartered task. This poll ends on May 6. >=20 > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. >=20 > Since Nobo is a contributor to this work, I will be taking the part of > the > shepherding chair. >=20 > -- Jeff From nobody Mon Apr 21 23:35:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B3D1A00AA for ; Mon, 21 Apr 2014 23:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hvPA6E-21Ar for ; Mon, 21 Apr 2014 23:35:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAC71A0092 for ; Mon, 21 Apr 2014 23:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2497; q=dns/txt; s=iport; t=1398148530; x=1399358130; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lpuqfEF1VsdTA+M6kts0T3shDXPc0WLVrXg2GzkwMXU=; b=NQMzPhds1NnZjFUl/Tozo/Ot0TWf3b/rBXN20FOI+PdoTMS5FxWVlH0f IKieUmhyt3s/mz8GMKXja86KaieKUFnlmwZVqYHjtSebiptLrO5yHZNXv e9+siMKR4f5v87P6gTZx7f95PhhZgXy3VjSPlUGgn3S31Tj1TBwiEWpQn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFYNVlOtJA2M/2dsb2JhbABZgwZPV8QRgR0WdIImAQEEOk8CAQgOKBAyJQIEARKIQQ3MVheOXYQ4BJhugTeRGYMxgis X-IronPort-AV: E=Sophos;i="4.97,901,1389744000"; d="scan'208";a="319469251" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 22 Apr 2014 06:35:29 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3M6ZTxi030478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 06:35:29 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.97]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 01:35:29 -0500 From: "Srihari Raghavan (srihari)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDzGENsWoBPtkaBGqY1k49VI5sd31mA Date: Tue, 22 Apr 2014 06:35:28 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D62DCA88BA5544384CF470AF8797456@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/avlTD_FknqveiuPlWb8IsS7dKQU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 06:35:39 -0000 As a member of a team implementing BFD and personally involved in the S-BFD discussions, I support the WG re-chartering and adoption of S-BFD use-case and base drafts. Thanks Srihari On 22/04/14 2:03 am, "Jeffrey Haas" wrote: >Working Group, > >>From our last in-person IETF meeting in Vancouver, the S-BFD authors were >going to put additional work into their use cases and base protocol >document >prior to requesting Working Group adoption. That work has since been done >and, IMO, the quality of the documents has nicely improved. > >But, being IETF work, we'd like to carry out further work on the proposal >in >the openness of the WG. Thus, I'd like to request the Working Group to >consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. >Note that this work is currently outside the scope of our charter and >would >require a re-charter. Once we have a sense of the group for the interest >in >this task we'll propose the charter update in support of the drafts. > >The following two documents are current and describe the work: > >http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > >Given the scope of this feature, I would like to particularly remind the >Working Group to focus on its security aspects. > >The following three documents are slightly stale as a result of the >revisions in the base and use cases draft and will require an update. >However, they provide a sense of how the S-BFD mechanisms might be used. > >Note in particular that the SR work will require coordination with the >SPRING Working Group. > >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ >http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > >Finally, there is known future work targeting the distribution of the >necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts >have >been authored on the topic at this time, but work on them is expected. > >This begins a two week poll on whether the WG would like to adopt S-BFD >as a >chartered task. This poll ends on May 6. > >As part of your response, please indicate if you have specific concerns >about individual drafts being part of this work. > >Since Nobo is a contributor to this work, I will be taking the part of the >shepherding chair. > >-- Jeff > From nobody Tue Apr 22 00:19:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5132B1A00D3 for ; Tue, 22 Apr 2014 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCFuT8xjq3Xj for ; Tue, 22 Apr 2014 00:19:53 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id C65761A0028 for ; Tue, 22 Apr 2014 00:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2787; q=dns/txt; s=iport; t=1398151188; x=1399360788; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=FwWXR8/o76Iqir89F1uezN9/AJ1lU/Mm31m/mSDAiJU=; b=G3SWeWoC1u/1TFo2JcGrxn6xHFYmgh9v8jgijIyWJqvjwkaTjTTUYEA5 6kYoogcBVIORxYGPekG3l3d63oJN6Gk9KBU0d2w9GZEnpJ2T1suVGJ1gN HBJQHMphKAHh0R10zv9IyYTUxTkHpDsjxLgsOa2904MXdqeB9XRE+gCk2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHkXVlOtJV2Z/2dsb2JhbABZgwZPV8QRgR4WdIIlAQEBBDpRAQgYHkIlAgQBEohBDcw+F45dhDgEmG6BN5EZgzGCKw X-IronPort-AV: E=Sophos;i="4.97,902,1389744000"; d="scan'208";a="37673751" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 22 Apr 2014 07:19:48 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3M7Jloi013140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 07:19:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 02:19:47 -0500 From: "Girija Raghavendra Rao (giraghav)" To: "Srihari Raghavan (srihari)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDy6aNZC173n06Qiqw0iaYZT5sdgqkAgABrRoA= Date: Tue, 22 Apr 2014 07:19:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F1AD925CB4CC44FB879091516F8A318@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/R_1vdV3rbr_O5h4c8NFH6t4KJbs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 07:19:58 -0000 Hi, Support the WG re-chartering and the WG adoption of the S-BFD use-case and base drafts. Thanks & Regards R.Girija On 22/04/14 12:05 PM, "Srihari Raghavan (srihari)" wrote: >As a member of a team implementing BFD and personally involved in the >S-BFD discussions, I support the WG re-chartering and adoption of S-BFD >use-case and base drafts. > >Thanks >Srihari > > >On 22/04/14 2:03 am, "Jeffrey Haas" wrote: > >>Working Group, >> >>>From our last in-person IETF meeting in Vancouver, the S-BFD authors >>>were >>going to put additional work into their use cases and base protocol >>document >>prior to requesting Working Group adoption. That work has since been >>done >>and, IMO, the quality of the documents has nicely improved. >> >>But, being IETF work, we'd like to carry out further work on the proposal >>in >>the openness of the WG. Thus, I'd like to request the Working Group to >>consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. >>Note that this work is currently outside the scope of our charter and >>would >>require a re-charter. Once we have a sense of the group for the interest >>in >>this task we'll propose the charter update in support of the drafts. >> >>The following two documents are current and describe the work: >> >>http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ >>http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >> >>Given the scope of this feature, I would like to particularly remind the >>Working Group to focus on its security aspects. >> >>The following three documents are slightly stale as a result of the >>revisions in the base and use cases draft and will require an update. >>However, they provide a sense of how the S-BFD mechanisms might be used. >> >>Note in particular that the SR work will require coordination with the >>SPRING Working Group. >> >>http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ >>http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ >>http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >> >>Finally, there is known future work targeting the distribution of the >>necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts >>have >>been authored on the topic at this time, but work on them is expected. >> >>This begins a two week poll on whether the WG would like to adopt S-BFD >>as a >>chartered task. This poll ends on May 6. >> >>As part of your response, please indicate if you have specific concerns >>about individual drafts being part of this work. >> >>Since Nobo is a contributor to this work, I will be taking the part of >>the >>shepherding chair. >> >>-- Jeff >> > From nobody Tue Apr 22 00:22:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533C61A0028 for ; Tue, 22 Apr 2014 00:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4Z5KRGSq_C0 for ; Tue, 22 Apr 2014 00:22:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8A1A00E7 for ; Tue, 22 Apr 2014 00:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10122; q=dns/txt; s=iport; t=1398151349; x=1399360949; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=86SN8xLKXV1EpnumGoHqj0vkQugs/3bQEwCiwVkE164=; b=TkdcuGQOSvweq24amI82nHyv7XrK4wYdJ0MIrbHXNgbMKk1vKQY1+fKA aLhy1bu4FclTxe1IXeciImHXg4dsIzwb3G6vVWfJiOS2e3Hw+s0y7kzrp 84qgd7lxeuTu6v8/1XRCGwDGzOPHmrCJr6TzSFYJcWcU1ijG74RQ3r0bi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUOACwYVlOtJA2N/2dsb2JhbABZgkJET1eELahjjgeIeoEeFnSCJQECBIELAQgRAwECKCYTFAkIAgQBEohBDcw/F45FGIQ4BI8OiWCBN5EZgzGCKw X-IronPort-AV: E=Sophos;i="4.97,902,1389744000"; d="scan'208,217";a="319413581" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 22 Apr 2014 07:22:29 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s3M7MStL012306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 07:22:28 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.208]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 02:22:28 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: "Girija Raghavendra Rao (giraghav)" , "Srihari Raghavan (srihari)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDy2JEdafTvhEmE0cCn0a6V5JsdgqkAgAAMYACAAFzxgA== Date: Tue, 22 Apr 2014 07:22:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.92] Content-Type: multipart/alternative; boundary="_000_CF7C16681E791mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XNFWi1M_X_wAO3ycCZngq0CD2fc X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 07:22:39 -0000 --_000_CF7C16681E791mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I support the rechartering and adoption of the SBFD use-case and base draft= s Regards Mallik From: "Girija Raghavendra Rao (giraghav)" > Date: Tuesday 22 April 2014 12:49 PM To: "Srihari Raghavan (srihari)" >, Jeffrey Haas >, "rtg-bfd@ietf.or= g" > Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Hi, Support the WG re-chartering and the WG adoption of the S-BFD use-case and base drafts. Thanks & Regards R.Girija On 22/04/14 12:05 PM, "Srihari Raghavan (srihari)" > wrote: As a member of a team implementing BFD and personally involved in the S-BFD discussions, I support the WG re-chartering and adoption of S-BFD use-case and base drafts. Thanks Srihari On 22/04/14 2:03 am, "Jeffrey Haas" >= wrote: Working Group, >From our last in-person IETF meeting in Vancouver, the S-BFD authors were going to put additional work into their use cases and base protocol document prior to requesting Working Group adoption. That work has since been done and, IMO, the quality of the documents has nicely improved. But, being IETF work, we'd like to carry out further work on the proposal in the openness of the WG. Thus, I'd like to request the Working Group to consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. Note that this work is currently outside the scope of our charter and would require a re-charter. Once we have a sense of the group for the interest in this task we'll propose the charter update in support of the drafts. The following two documents are current and describe the work: http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ Given the scope of this feature, I would like to particularly remind the Working Group to focus on its security aspects. The following three documents are slightly stale as a result of the revisions in the base and use cases draft and will require an update. However, they provide a sense of how the S-BFD mechanisms might be used. Note in particular that the SR work will require coordination with the SPRING Working Group. http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ Finally, there is known future work targeting the distribution of the necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have been authored on the topic at this time, but work on them is expected. This begins a two week poll on whether the WG would like to adopt S-BFD as a chartered task. This poll ends on May 6. As part of your response, please indicate if you have specific concerns about individual drafts being part of this work. Since Nobo is a contributor to this work, I will be taking the part of the shepherding chair. -- Jeff --_000_CF7C16681E791mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <20C6AF8C0C410242913CA3C91BE7C603@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

I support the rechartering and adoption of the SBFD use-case and base = drafts

Regards
Mallik

From: "Girija Raghavendra Rao = (giraghav)" <giraghav@cisco.c= om>
Date: Tuesday 22 April 2014 12:49 P= M
To: "Srihari Raghavan (srihari= )" <srihari@cisco.com>,= Jeffrey Haas <jhaas@pfrc.org>,= "rtg-bfd@ietf.org" <<= a href=3D"mailto:rtg-bfd@ietf.org">rtg-bfd@ietf.org>
Subject: Re: Working Group adoption= for Seamless BFD (requires re-charter)

Hi,

Support the WG re-chartering and the WG adoption of the S-BFD use-case= and
base drafts.


Thanks & Regards
R.Girija

On 22/04/14 12:05 PM, "Srihari Raghavan (srihari)" <srihari@cisco.com>
wrote:

As a member of a team implementing BFD and personally involved in the<= /div>
S-BFD discussions, I support the WG re-chartering and adoption of S-BF= D
use-case and base drafts.

Thanks
Srihari


On 22/04/14 2:03 am, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

Working Group,

From our last in-person IETF meeting in Vancouver, the S-BFD authors
were
going to put additional work into their use cases and base protocol
document
prior to requesting Working Group adoption.  That work has s= ince been
done
and, IMO, the quality of the documents has nicely improved.

But, being IETF work, we'd like to carry out further work on the propo= sal
in
the openness of the WG.  Thus, I'd like to request the Worki= ng Group to
consider whether we'll want to adopt the Seamless BFD (S-BFD) document= s.
Note that this work is currently outside the scope of our charter and<= /div>
would
require a re-charter.  Once we have a sense of the group for= the interest
in
this task we'll propose the charter update in support of the drafts.

The following two documents are current and describe the work:

http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/

Given the scope of this feature, I would like to particularly remind t= he
Working Group to focus on its security aspects.

The following three documents are slightly stale as a result of the
revisions in the base and use cases draft and will require an update.<= /div>
However, they provide a sense of how the S-BFD mechanisms might be use= d.

Note in particular that the SR work will require coordination with the=
SPRING Working Group.


Finally, there is known future work targeting the distribution of the<= /div>
necessary S-BFD bootstrapping information in OSPF and ISIS.  = ;No drafts
have
been authored on the topic at this time, but work on them is expected.=

This begins a two week poll on whether the WG would like to adopt S-BF= D
as a
chartered task.  This poll ends on May 6.

As part of your response, please indicate if you have specific concern= s
about individual drafts being part of this work.

Since Nobo is a contributor to this work, I will be taking the part of=
the
shepherding chair.

-- Jeff




 --_000_CF7C16681E791mmudigonciscocom_-- From nobody Tue Apr 22 01:15:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCB91A013D for ; Tue, 22 Apr 2014 01:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N4FeCRgXvzJ for ; Tue, 22 Apr 2014 01:15:25 -0700 (PDT) Received: from mail-la0-x241.google.com (mail-la0-x241.google.com [IPv6:2a00:1450:4010:c03::241]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6361A013E for ; Tue, 22 Apr 2014 01:15:25 -0700 (PDT) Received: by mail-la0-f65.google.com with SMTP id hr17so1431765lab.4 for ; Tue, 22 Apr 2014 01:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yvWWXem2EEduj2ZsJzl/DGlngaJk4Jr44wr7RTX7Aho=; b=d8BLIYCjGPb5512wI7rF25djGCIUqNH1BnIaK1PS3fIT1LlQg7lo8AJqMeufgEZaw9 +xTwpvFO+u1/T8/guCPAhqlarGmhH3nNsZwdJmP5Kb+qZWatWio3DjlpbRWqpO9L42qg S2Ta36aoMNwoGFMnkloY3iDzNGIRgWhbBPrTAjTspClZo6tDKEATufRFbDLNu/rLXASx cMTDdOO3NL5kXNp5SA+BWEVMIG3TYcFhusF63TqCptaZSZkl1TvqIAQTlp4bKGegJIbF hPUcCn5ggjIxiWO6g15n1/+cvSBOSi1XCVuCb6g6/Qg0YG9gftZmV3xPkD63/43XfUqO Luyg== MIME-Version: 1.0 X-Received: by 10.112.186.98 with SMTP id fj2mr573265lbc.54.1398154519419; Tue, 22 Apr 2014 01:15:19 -0700 (PDT) Received: by 10.112.50.239 with HTTP; Tue, 22 Apr 2014 01:15:19 -0700 (PDT) In-Reply-To: <20140421203314.GF8955@pfrc> References: <20140421203314.GF8955@pfrc> Date: Tue, 22 Apr 2014 09:15:19 +0100 Message-ID: Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) From: Ignas Bagdonas To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a11361942789f8104f79d3719 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UGApUVHpJPQ8WNBGHv7JYiSKkps X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 08:15:30 -0000 --001a11361942789f8104f79d3719 Content-Type: text/plain; charset=UTF-8 Hi, I have read the documents and believe that they address a needed and valuable functionality, and I do support adopting the base and use cases documents as WG items. A couple of areas that seem concerning to me - the congestion aspects will need to be discussed, and likely more broadly than in RFC5880, especially given the lack of state on the responder node, and ability to allocate discriminators for nodes that do not necessary have a control plane. Those concerns are not blocking and definitely could be addressed later. Ignas On Mon, Apr 21, 2014 at 9:33 PM, Jeffrey Haas wrote: > Working Group, > > >From our last in-person IETF meeting in Vancouver, the S-BFD authors were > going to put additional work into their use cases and base protocol > document > prior to requesting Working Group adoption. That work has since been done > and, IMO, the quality of the documents has nicely improved. > > But, being IETF work, we'd like to carry out further work on the proposal > in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and would > require a re-charter. Once we have a sense of the group for the interest > in > this task we'll propose the charter update in support of the drafts. > > The following two documents are current and describe the work: > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. > > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be used. > > Note in particular that the SR work will require coordination with the > SPRING Working Group. > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have > been authored on the topic at this time, but work on them is expected. > > This begins a two week poll on whether the WG would like to adopt S-BFD as > a > chartered task. This poll ends on May 6. > > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. > > Since Nobo is a contributor to this work, I will be taking the part of the > shepherding chair. > > -- Jeff > > --001a11361942789f8104f79d3719 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have read the documents and b= elieve that they address a needed and valuable functionality, and I do supp= ort adopting the base and use cases documents as WG items. A couple of area= s that seem concerning to me - the congestion aspects will need to be discu= ssed, and likely more broadly than in RFC5880, especially given the lack of= state on the responder node, and ability to allocate discriminators for no= des that do not necessary have a control plane. Those concerns are not bloc= king and definitely could be addressed later.=C2=A0

Ignas



On Mon, Apr 21, 2014 at 9:33 PM, Jeffrey Haas <jhaas= @pfrc.org> wrote:
Working Group,

>From our last in-person IETF meeting in Vancouver, the S-BFD authors we= re
going to put additional work into their use cases and base protocol documen= t
prior to requesting Working Group adoption. =C2=A0That work has since been = done
and, IMO, the quality of the documents has nicely improved.

But, being IETF work, we'd like to carry out further work on the propos= al in
the openness of the WG. =C2=A0Thus, I'd like to request the Working Gro= up to
consider whether we'll want to adopt the Seamless BFD (S-BFD) documents= .
Note that this work is currently outside the scope of our charter and would=
require a re-charter. =C2=A0Once we have a sense of the group for the inter= est in
this task we'll propose the charter update in support of the drafts.
The following two documents are current and describe the work:

http://datatracker.ietf.org/doc/draft-aldrin-bfd-sea= mless-use-case/
http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-= base/

Given the scope of this feature, I would like to particularly remind the Working Group to focus on its security aspects.

The following three documents are slightly stale as a result of the
revisions in the base and use cases draft and will require an update.
However, they provide a sense of how the S-BFD mechanisms might be used.
Note in particular that the SR work will require coordination with the
SPRING Working Group.

http://datatracker.ietf.org/doc/draft-akiya-bfd-= seamless-alert-discrim/
http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip= /
http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr= /

Finally, there is known future work targeting the distribution of the
necessary S-BFD bootstrapping information in OSPF and ISIS. =C2=A0No drafts= have
been authored on the topic at this time, but work on them is expected.

This begins a two week poll on whether the WG would like to adopt S-BFD as = a
chartered task. =C2=A0This poll ends on May 6.

As part of your response, please indicate if you have specific concerns
about individual drafts being part of this work.

Since Nobo is a contributor to this work, I will be taking the part of the<= br> shepherding chair.

-- Jeff


--001a11361942789f8104f79d3719-- From nobody Tue Apr 22 01:17:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25971A013E for ; Tue, 22 Apr 2014 01:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvmvFNgiqbcO for ; Tue, 22 Apr 2014 01:17:08 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 660B81A013D for ; Tue, 22 Apr 2014 01:17:08 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 981421800868 for ; Tue, 22 Apr 2014 10:17:02 +0200 (CEST) Message-ID: <53562582.2020601@pi.nu> Date: Tue, 22 Apr 2014 10:17:06 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtg-bfd@ietf.org Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WF_-IrcZU-iSD-c-h9Iq_ZGNaeU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 08:17:16 -0000 Folks, I support adopting S-BFD as a chartered work item for the working group. I do not have any particular concerns about the document listed below, and think they should be adapted as working group document. /Loa On 2014-04-21 22:33, Jeffrey Haas wrote: > Working Group, > >>From our last in-person IETF meeting in Vancouver, the S-BFD authors were > going to put additional work into their use cases and base protocol document > prior to requesting Working Group adoption. That work has since been done > and, IMO, the quality of the documents has nicely improved. > > But, being IETF work, we'd like to carry out further work on the proposal in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and would > require a re-charter. Once we have a sense of the group for the interest in > this task we'll propose the charter update in support of the drafts. > > The following two documents are current and describe the work: > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. > > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be used. > > Note in particular that the SR work will require coordination with the > SPRING Working Group. > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have > been authored on the topic at this time, but work on them is expected. > > This begins a two week poll on whether the WG would like to adopt S-BFD as a > chartered task. This poll ends on May 6. > > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. > > Since Nobo is a contributor to this work, I will be taking the part of the > shepherding chair. > > -- Jeff > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 22 09:59:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CCD1A0684 for ; Tue, 22 Apr 2014 09:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwROV4wH-oVS for ; Tue, 22 Apr 2014 09:59:52 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2061A0215 for ; Tue, 22 Apr 2014 09:59:51 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D72862AA0F; Tue, 22 Apr 2014 16:59:44 +0000 (GMT) Date: Tue, 22 Apr 2014 09:59:47 -0700 From: Marc Binderberger To: Jeffrey Haas , "rtg-bfd@ietf.org" Message-ID: <20140422095947085332.17a123c2@sniff.de> In-Reply-To: <20140421203314.GF8955@pfrc> References: <20140421203314.GF8955@pfrc> Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ieWfXRtPBpRFfWl9uXPJpo3-6n8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 16:59:56 -0000 Hello Jeff, I support to add S-BFD to the BFD charter and to adopt the "base" and "use case" document as workgroup documents. I assume this won't stop us still having lots of discussions about various details ;-) Regards, Marc On Mon, 21 Apr 2014 16:33:14 -0400, Jeffrey Haas wrote: > Working Group, > >> From our last in-person IETF meeting in Vancouver, the S-BFD authors were > going to put additional work into their use cases and base protocol document > prior to requesting Working Group adoption. That work has since been done > and, IMO, the quality of the documents has nicely improved. > > But, being IETF work, we'd like to carry out further work on the proposal in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and would > require a re-charter. Once we have a sense of the group for the interest in > this task we'll propose the charter update in support of the drafts. > > The following two documents are current and describe the work: > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. > > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be used. > > Note in particular that the SR work will require coordination with the > SPRING Working Group. > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have > been authored on the topic at this time, but work on them is expected. > > This begins a two week poll on whether the WG would like to adopt S-BFD as a > chartered task. This poll ends on May 6. > > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. > > Since Nobo is a contributor to this work, I will be taking the part of the > shepherding chair. > > -- Jeff > From nobody Tue Apr 22 10:01:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659531A0697 for ; Tue, 22 Apr 2014 10:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78Nu0I_Gcv4v for ; Tue, 22 Apr 2014 10:01:40 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1A1A0223 for ; Tue, 22 Apr 2014 10:01:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 15EBFC1ED; Tue, 22 Apr 2014 13:01:32 -0400 (EDT) Date: Tue, 22 Apr 2014 13:01:31 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Message-ID: <20140422170131.GA18985@pfrc> References: <20140421203314.GF8955@pfrc> <20140422095947085332.17a123c2@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140422095947085332.17a123c2@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kfV172h94eepQCg_F5Oordlj50k Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 17:01:41 -0000 On Tue, Apr 22, 2014 at 09:59:47AM -0700, Marc Binderberger wrote: > I support to add S-BFD to the BFD charter and to adopt the "base" and "use > case" document as workgroup documents. > > I assume this won't stop us still having lots of discussions about various > details ;-) Hopefully more of them. -- Jeff From nobody Tue Apr 22 10:24:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46C51A06B2 for ; Tue, 22 Apr 2014 10:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyfMnyGEBqv4 for ; Tue, 22 Apr 2014 10:24:15 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEECF1A0698 for ; Tue, 22 Apr 2014 10:24:14 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 03F6A2AA0F; Tue, 22 Apr 2014 17:24:07 +0000 (GMT) Date: Tue, 22 Apr 2014 10:24:10 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , Jeffrey Haas Message-ID: <20140422102410368618.b0a0531a@sniff.de> In-Reply-To: References: <20140421201938.GD8955@pfrc> Subject: RE: draft-ietf-bfd-intervals IANA considerations? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/caoAhqBBj-Pi1pNg7f3L6YZ085g Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 17:24:19 -0000 Hello Jeff, Nobo et al., thanks for this summarization and thanks for the discussion I have seen. My apology for being silent although being one of the authors; was caught in last minute (more last weeks) activities for code shipment. There is one aspect I would like to comment. > And one must admit the whole point of such a draft in the first place is to > give users a way to say "this is a common value, do you support it?" True. But this should not be seen in a negative way. I see it in first place as a synchronization of the BFD implementors, both vendor and network designers. There should be an understanding on both sides that the common interval list is informal. I do expect some implementations to be not "100% compliant" (*) and still it serves a purpose to minimize the drift from desired interval to the negotiated interval. Minimizing this drift is a main motivation. This is also the reason why the list is larger than some may expect, it offers anchor intervals for de-facto, legacy common values, values borrowed from Y.1731, some must-have values like 3.3msec and 1sec. This isn't exact science, it's heuristic :-) and I hope we found a reasonable balance. Regards, Marc (*: even some implementation of my company won't be 100%. We'll fix it in the future) On Tue, 22 Apr 2014 00:12:46 +0000, Nobo Akiya (nobo) wrote: > Hi Jeff, > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas >> Sent: Monday, April 21, 2014 4:20 PM >> To: rtg-bfd@ietf.org >> Subject: Re: draft-ietf-bfd-intervals IANA considerations? >> >> WG, >> >>> Authors of draft-ietf-bfd-intervals have discussed and concluded that >>> defined "common intervals set" does _not_ need to be maintained by >> IANA. >>> >>> Reasons: >>> 1. Document is an informational draft. >>> 2. Additions of interval(s) in the "common intervals set" should >>> anyways be done through a new draft, whether or not >>> draft-ietf-bfd-intervals creates an IANA registry and defines allocation >> policies for it. >>> >>> Do you agree with this? >>> Do you see any concern with this? >>> >>> Seeking opinions/comments from folks on this matter. >> >> After seeking WG commentary, my conclusion is that there's no strong >> consensus to create an IANA registry at this time. If, at a later time, >> additional documents give rise to a need for such a registry, we can do the >> work at that time. > > Sounds like a reasonable approach. > >> >> Consulting with our Area Director, Adrian, about this, he concurs that it's >> okay. He does suggest the authors add a short sentence or two to the >> document about the reasoning. (Effectively, "here's why we have no IANA >> considerations...") > > We (authors) will keep the "here's why" very short, but I'd like to take > this opportunity to say thanks for all who have chimed in: thanks Sasha, > Carlos, Greg, Jeff, Donald! We will include this text in the next revision. > >> >> I would also note that there's been relatively little other commentary >> about >> the suggested timings in the draft. While the submitted milestone to our >> AD was January 2015, there may cause to declare sufficient consensus to do >> a WGLC for the upcoming IETF session. Thus, please review your >> implementations against the recommended timing intervals and provide >> commentary to this I-D. > > Agree. > > -Nobo > >> >> -- Jeff > From nobody Wed Apr 23 12:04:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAD11A048A for ; Wed, 23 Apr 2014 12:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpmB0bllQEgB for ; Wed, 23 Apr 2014 12:04:11 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3381A0422 for ; Wed, 23 Apr 2014 12:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6922; q=dns/txt; s=iport; t=1398279845; x=1399489445; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JrKjO6gefaqr6PDJQtRX5VqiApogqpgGPhc+EREqnuk=; b=hXk/ptGeSaL4MEtzqlDE6IhAL6kkLzHPF+eLiSJkPyuT8Me5DJvByB44 TrS59VvdlGYmUgamuH98EMbe8vEKSjchfLiwyfkYM1mCR1gC5Qsp/dLKc GLDK9K2Tc4r+sH7fUNPr4+gYGgqFqjyoOXf3SCz9VNtwSblaVdlC01nEx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FACcOWFOtJV2d/2dsb2JhbABagmUhT1eDD8EpGYEDFnSCJQEBAQMBIxFKBwQCAQgOAwQBAQECAgYdAwICAjAUAQgIAgQBEgiIMQgBDKseoxgXgSmMfjgGgmk1gRUEmiyRHoMxgis X-IronPort-AV: E=Sophos;i="4.97,913,1389744000"; d="scan'208";a="38157291" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 23 Apr 2014 19:04:04 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3NJ45jd005370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 19:04:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 14:04:04 -0500 From: "Nobo Akiya (nobo)" To: Ignas Bagdonas , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDzsd8RqfWJjUqW3c8k2YnCwZsdno+AgAHr4oA= Date: Wed, 23 Apr 2014 19:04:03 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dzMYaVbLSxtyJeLdeprzIVivru4 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 19:04:13 -0000 VGhhbmtzIElnbmFzLg0KDQo+IEkgaGF2ZSByZWFkIHRoZSBkb2N1bWVudHMgYW5kIGJlbGlldmUg dGhhdCB0aGV5IGFkZHJlc3MgYSBuZWVkZWQgYW5kDQo+IHZhbHVhYmxlIGZ1bmN0aW9uYWxpdHks IGFuZCBJIGRvIHN1cHBvcnQgYWRvcHRpbmcgdGhlIGJhc2UgYW5kIHVzZSBjYXNlcw0KPiBkb2N1 bWVudHMgYXMgV0cgaXRlbXMuIEEgY291cGxlIG9mIGFyZWFzIHRoYXQgc2VlbSBjb25jZXJuaW5n IHRvIG1lIC0gdGhlDQo+IGNvbmdlc3Rpb24gYXNwZWN0cyB3aWxsIG5lZWQgdG8gYmUgZGlzY3Vz c2VkLCBhbmQgbGlrZWx5IG1vcmUgYnJvYWRseSB0aGFuDQo+IGluIFJGQzU4ODAsIGVzcGVjaWFs bHkgZ2l2ZW4gdGhlIGxhY2sgb2Ygc3RhdGUgb24gdGhlIHJlc3BvbmRlciBub2RlLCBhbmQNCj4g YWJpbGl0eSB0byBhbGxvY2F0ZSBkaXNjcmltaW5hdG9ycyBmb3Igbm9kZXMgdGhhdCBkbyBub3Qg bmVjZXNzYXJ5IGhhdmUgYQ0KPiBjb250cm9sIHBsYW5lLiBUaG9zZSBjb25jZXJucyBhcmUgbm90 IGJsb2NraW5nIGFuZCBkZWZpbml0ZWx5IGNvdWxkIGJlDQo+IGFkZHJlc3NlZCBsYXRlci4NCg0K SSBhZ3JlZSB3aXRoIGJvdGguIEJlbG93IGFyZSBteSB0aG91Z2h0cyBvbiB0aGUgdHdvIGFyZWFz Lg0KDQpDb25nZXN0aW9uOg0KDQpBZ3JlZSwgUy1CRkQgd2lsbCByZXF1aXJlIGFuIGFkZGl0aW9u YWwgaG9vay4gRmlyc3QgYnVsbGV0IG9mIHNlY3Rpb24gOS44IG9mIHRoZSBiYXNlIGRvY3VtZW50 IGRlc2NyaWJlcyBhIHdheSBmb3IgYSByZWZsZWN0b3IgdG8gdGVsbCB0aG9zZSBzcGVha2luZyB0 byBpdCB0byBzbG93IGRvd24sIHZpYSBjaGFuZ2luZyB0aGUgdmFsdWUgb2YgIlJlcXVpcmVkIE1p biBSWCBJbnRlcnZhbCIgaW4gcGFja2V0cyByZWZsZWN0ZWQuIFRvIGhhbmRsZSB0aGUgY29uZ2Vz dGlvbiBmcm9tICJ0cnVzdGVkIHNwZWFrZXJzIiwgdGhpcyBtYXkgYmUgc3VmZmljaWVudC4gU29t ZSBoYXZlIGV4cHJlc3NlZCBhIGNvbmNlcm4gb2YgInRoaXMgd2lsbCBjaGFuZ2UgdGhlIGZhaWx1 cmUgZGV0ZWN0aW9uIHRpbWUgYXQgaW5pdGlhdG9ycy4iLCBhbmQgdGhhdCdzIGNlcnRhaW5seSBh IHZhbGlkIGNvbmNlcm4uIEhvd2V2ZXIsIGF0IHNvbWUgbGV2ZWwsIHdlIGhhdmUgdG8gcmVseSBv biB0aGUgdXNlcnMgKG9wZXJhdG9ycyBvciBhcHBzKSB0byBjb250cm9sIGhvdyBtYW55IFMtQkZE IHNlc3Npb25zIGFyZSBwcm92aXNpb25lZCBpbiB0aGUgbmV0d29yayAoYW5kIGhvdyBmYXN0KS4g VGhlIG90aGVyIGFzcGVjdCBpcyBjb25nZXN0aW9uIGNvbnRyb2wgdG8gIm5vbi10cnVzdGVkIHNw ZWFrZXJzIi4gVGhlcmUncyBubyBndWFyYW50ZWUgdGhhdCBhYm92ZSB0ZWNobmlxdWUgd2lsbCBi ZSBob25vcmVkIGJ5IGluaXRpYXRvcnMuIFRoaXMgb25lIHByb2JhYmx5IHNob3VsZCBiZSB0YWNr bGVkIHdpdGggc2VjdXJpdHkgYXNwZWN0Lg0KDQpXaXRoIHRoYXQgc2FpZCwgSSB0aGluayBib3Ro IGNvbmdlc3Rpb24gYW5kIHNlY3VyaXR5IGFzcGVjdHMgY2FuIGJlbmVmaXQgZnJvbSBtb3JlIHBl b3BsZSBwbGFjaW5nIGZvY3VzIG9uIHRoZW0sIHdoZXRoZXIgd2hhdCB3ZSBoYXZlIGluIGJhc2Ut MDMgaXMgc3VmZmljaWVudCBvciB3ZSBuZWVkIG1vcmUgKGlmIHNvIHdoYXQpLg0KDQpMYWNrIG9m IGNvbnRyb2wgcGxhbmU6DQoNCkN1cnJlbnQgZGlyZWN0aW9uIGFwcGVhcnMgdG8gYmUgImxldCdz IGdldCBTLUJGRCB3b3JraW5nIHdpdGggSUdQcywgYW5kIHRoZW4gZXhwYW5kIHRoZSB1c2UiLCBz byBsb29raW5nIGF0IGNvbnRyb2wtcGxhbmUtbGVzcyBzY2VuYXJpbyBhdCBhIGxhdGVyIHRpbWUg bWFrZSBzZW5zZSBhdCB0aGlzIHBvaW50Lg0KDQotTm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBJZ25hcw0KPiBCYWdkb25hcw0KPiBTZW50OiBUdWVzZGF5LCBBcHJp bCAyMiwgMjAxNCA0OjE1IEFNDQo+IFRvOiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIGZvciBTZWFtbGVzcyBCRkQgKHJlcXVpcmVzIHJlLWNo YXJ0ZXIpDQo+IA0KPiBIaSwNCj4gSSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50cyBhbmQgYmVsaWV2 ZSB0aGF0IHRoZXkgYWRkcmVzcyBhIG5lZWRlZCBhbmQNCj4gdmFsdWFibGUgZnVuY3Rpb25hbGl0 eSwgYW5kIEkgZG8gc3VwcG9ydCBhZG9wdGluZyB0aGUgYmFzZSBhbmQgdXNlIGNhc2VzDQo+IGRv Y3VtZW50cyBhcyBXRyBpdGVtcy4gQSBjb3VwbGUgb2YgYXJlYXMgdGhhdCBzZWVtIGNvbmNlcm5p bmcgdG8gbWUgLSB0aGUNCj4gY29uZ2VzdGlvbiBhc3BlY3RzIHdpbGwgbmVlZCB0byBiZSBkaXNj dXNzZWQsIGFuZCBsaWtlbHkgbW9yZSBicm9hZGx5IHRoYW4NCj4gaW4gUkZDNTg4MCwgZXNwZWNp YWxseSBnaXZlbiB0aGUgbGFjayBvZiBzdGF0ZSBvbiB0aGUgcmVzcG9uZGVyIG5vZGUsIGFuZA0K PiBhYmlsaXR5IHRvIGFsbG9jYXRlIGRpc2NyaW1pbmF0b3JzIGZvciBub2RlcyB0aGF0IGRvIG5v dCBuZWNlc3NhcnkgaGF2ZSBhDQo+IGNvbnRyb2wgcGxhbmUuIFRob3NlIGNvbmNlcm5zIGFyZSBu b3QgYmxvY2tpbmcgYW5kIGRlZmluaXRlbHkgY291bGQgYmUNCj4gYWRkcmVzc2VkIGxhdGVyLg0K PiBJZ25hcw0KPiANCj4gT24gTW9uLCBBcHIgMjEsIDIwMTQgYXQgOTozMyBQTSwgSmVmZnJleSBI YWFzIDxqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQo+IFdvcmtpbmcgR3JvdXAsDQo+IA0KPiA+RnJv bSBvdXIgbGFzdCBpbi1wZXJzb24gSUVURiBtZWV0aW5nIGluIFZhbmNvdXZlciwgdGhlIFMtQkZE IGF1dGhvcnMgd2VyZQ0KPiBnb2luZyB0byBwdXQgYWRkaXRpb25hbCB3b3JrIGludG8gdGhlaXIg dXNlIGNhc2VzIGFuZCBiYXNlIHByb3RvY29sDQo+IGRvY3VtZW50DQo+IHByaW9yIHRvIHJlcXVl c3RpbmcgV29ya2luZyBHcm91cCBhZG9wdGlvbi4gwqBUaGF0IHdvcmsgaGFzIHNpbmNlIGJlZW4N Cj4gZG9uZQ0KPiBhbmQsIElNTywgdGhlIHF1YWxpdHkgb2YgdGhlIGRvY3VtZW50cyBoYXMgbmlj ZWx5IGltcHJvdmVkLg0KPiANCj4gQnV0LCBiZWluZyBJRVRGIHdvcmssIHdlJ2QgbGlrZSB0byBj YXJyeSBvdXQgZnVydGhlciB3b3JrIG9uIHRoZSBwcm9wb3NhbCBpbg0KPiB0aGUgb3Blbm5lc3Mg b2YgdGhlIFdHLiDCoFRodXMsIEknZCBsaWtlIHRvIHJlcXVlc3QgdGhlIFdvcmtpbmcgR3JvdXAg dG8NCj4gY29uc2lkZXIgd2hldGhlciB3ZSdsbCB3YW50IHRvIGFkb3B0IHRoZSBTZWFtbGVzcyBC RkQgKFMtQkZEKSBkb2N1bWVudHMuDQo+IE5vdGUgdGhhdCB0aGlzIHdvcmsgaXMgY3VycmVudGx5 IG91dHNpZGUgdGhlIHNjb3BlIG9mIG91ciBjaGFydGVyIGFuZCB3b3VsZA0KPiByZXF1aXJlIGEg cmUtY2hhcnRlci4gwqBPbmNlIHdlIGhhdmUgYSBzZW5zZSBvZiB0aGUgZ3JvdXAgZm9yIHRoZSBp bnRlcmVzdCBpbg0KPiB0aGlzIHRhc2sgd2UnbGwgcHJvcG9zZSB0aGUgY2hhcnRlciB1cGRhdGUg aW4gc3VwcG9ydCBvZiB0aGUgZHJhZnRzLg0KPiANCj4gVGhlIGZvbGxvd2luZyB0d28gZG9jdW1l bnRzIGFyZSBjdXJyZW50IGFuZCBkZXNjcmliZSB0aGUgd29yazoNCj4gDQo+IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxkcmluLWJmZC1zZWFtbGVzcy11c2UtY2FzZS8N Cj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxl c3MtYmFzZS8NCj4gDQo+IEdpdmVuIHRoZSBzY29wZSBvZiB0aGlzIGZlYXR1cmUsIEkgd291bGQg bGlrZSB0byBwYXJ0aWN1bGFybHkgcmVtaW5kIHRoZQ0KPiBXb3JraW5nIEdyb3VwIHRvIGZvY3Vz IG9uIGl0cyBzZWN1cml0eSBhc3BlY3RzLg0KPiANCj4gVGhlIGZvbGxvd2luZyB0aHJlZSBkb2N1 bWVudHMgYXJlIHNsaWdodGx5IHN0YWxlIGFzIGEgcmVzdWx0IG9mIHRoZQ0KPiByZXZpc2lvbnMg aW4gdGhlIGJhc2UgYW5kIHVzZSBjYXNlcyBkcmFmdCBhbmQgd2lsbCByZXF1aXJlIGFuIHVwZGF0 ZS4NCj4gSG93ZXZlciwgdGhleSBwcm92aWRlIGEgc2Vuc2Ugb2YgaG93IHRoZSBTLUJGRCBtZWNo YW5pc21zIG1pZ2h0IGJlDQo+IHVzZWQuDQo+IA0KPiBOb3RlIGluIHBhcnRpY3VsYXIgdGhhdCB0 aGUgU1Igd29yayB3aWxsIHJlcXVpcmUgY29vcmRpbmF0aW9uIHdpdGggdGhlDQo+IFNQUklORyBX b3JraW5nIEdyb3VwLg0KPiANCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1ha2l5YS1iZmQtc2VhbWxlc3MtYWxlcnQtZGlzY3JpbS8NCj4gaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtaXAvDQo+IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLXNyLw0KPiANCj4g RmluYWxseSwgdGhlcmUgaXMga25vd24gZnV0dXJlIHdvcmsgdGFyZ2V0aW5nIHRoZSBkaXN0cmli dXRpb24gb2YgdGhlDQo+IG5lY2Vzc2FyeSBTLUJGRCBib290c3RyYXBwaW5nIGluZm9ybWF0aW9u IGluIE9TUEYgYW5kIElTSVMuIMKgTm8gZHJhZnRzIGhhdmUNCj4gYmVlbiBhdXRob3JlZCBvbiB0 aGUgdG9waWMgYXQgdGhpcyB0aW1lLCBidXQgd29yayBvbiB0aGVtIGlzIGV4cGVjdGVkLg0KPiAN Cj4gVGhpcyBiZWdpbnMgYSB0d28gd2VlayBwb2xsIG9uIHdoZXRoZXIgdGhlIFdHIHdvdWxkIGxp a2UgdG8gYWRvcHQgUy1CRkQNCj4gYXMgYQ0KPiBjaGFydGVyZWQgdGFzay4gwqBUaGlzIHBvbGwg ZW5kcyBvbiBNYXkgNi4NCj4gDQo+IEFzIHBhcnQgb2YgeW91ciByZXNwb25zZSwgcGxlYXNlIGlu ZGljYXRlIGlmIHlvdSBoYXZlIHNwZWNpZmljIGNvbmNlcm5zDQo+IGFib3V0IGluZGl2aWR1YWwg ZHJhZnRzIGJlaW5nIHBhcnQgb2YgdGhpcyB3b3JrLg0KPiANCj4gU2luY2UgTm9ibyBpcyBhIGNv bnRyaWJ1dG9yIHRvIHRoaXMgd29yaywgSSB3aWxsIGJlIHRha2luZyB0aGUgcGFydCBvZiB0aGUN Cj4gc2hlcGhlcmRpbmcgY2hhaXIuDQo+IA0KPiAtLSBKZWZmDQoNCg== From nobody Fri Apr 25 13:04:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F781A0664 for ; Fri, 25 Apr 2014 13:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWIrbWd45oMU for ; Fri, 25 Apr 2014 13:04:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 067691A02F2 for ; Fri, 25 Apr 2014 13:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2675; q=dns/txt; s=iport; t=1398456280; x=1399665880; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DkNBfXuHJPAh15T8sHVTy2Sa7oyrvOJitL/NdxIguRg=; b=Zz9kO5b6W0GkJXxrQ9+XRRkNCXB92gi0Akzyfx0x2DoickwvDp2EnnSo p8lIH4TYr2n8THieUN4b0JJ5TbnfzbSdGIBiwPFA652zVbKL3118TrBxP F3PMQBXcY81j6VNm1lK7w54DxCyQPFiVZgRaoRb543Gb9v1LVc20dgQnf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAMO+WlOtJV2Z/2dsb2JhbABZgwZPV8QggRQWdIIlAQEBBDpLBAIBCA4DBAEBCxQJBzIUCQgCBAESCIg5DcofF44oOAaDHoEVBJo9kSSDMYIr X-IronPort-AV: E=Sophos;i="4.97,928,1389744000"; d="scan'208";a="320406146" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 25 Apr 2014 20:04:38 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3PK4cm5004989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 20:04:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 15:04:38 -0500 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDyv8WLWl3gwUqrZ8k82k2AtZsix5Vw Date: Fri, 25 Apr 2014 20:04:37 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-VRyd4VJv4o1W1IsH93ATW4mb-U X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:04:48 -0000 I support the WG re-chartering to include all mentioned aspects of S-BFD w= ork. Les > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, April 21, 2014 1:33 PM > To: rtg-bfd@ietf.org > Subject: Working Group adoption for Seamless BFD (requires re-charter) >=20 > Working Group, >=20 > >From our last in-person IETF meeting in Vancouver, the S-BFD authors wer= e > going to put additional work into their use cases and base protocol > document > prior to requesting Working Group adoption. That work has since been > done > and, IMO, the quality of the documents has nicely improved. >=20 > But, being IETF work, we'd like to carry out further work on the proposal= in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and wou= ld > require a re-charter. Once we have a sense of the group for the interest= in > this task we'll propose the charter update in support of the drafts. >=20 > The following two documents are current and describe the work: >=20 > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >=20 > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. >=20 > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be > used. >=20 > Note in particular that the SR work will require coordination with the > SPRING Working Group. >=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >=20 > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts ha= ve > been authored on the topic at this time, but work on them is expected. >=20 > This begins a two week poll on whether the WG would like to adopt S-BFD > as a > chartered task. This poll ends on May 6. >=20 > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. >=20 > Since Nobo is a contributor to this work, I will be taking the part of th= e > shepherding chair. >=20 > -- Jeff From nobody Fri Apr 25 14:12:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675A91A0680 for ; Fri, 25 Apr 2014 14:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9obFKro9xbvz for ; Fri, 25 Apr 2014 14:11:58 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87C1A0663 for ; Fri, 25 Apr 2014 14:11:57 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3PLBox3023979 for ; Fri, 25 Apr 2014 22:11:50 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3PLBnnh023970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 25 Apr 2014 22:11:50 +0100 From: "Adrian Farrel" To: References: <20140421203314.GF8955@pfrc> In-Reply-To: Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Date: Fri, 25 Apr 2014 22:11:46 +0100 Message-ID: <001b01cf60ca$f80aa060$e81fe120$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEzJD+lSLL9H1IJbD8t16sIUBmGdQKCRpfZnEc60dA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20656.002 X-TM-AS-Result: No--18.312-10.0-31-10 X-imss-scan-details: No--18.312-10.0-31-10 X-TMASE-MatchedRID: WMT2WRIkHPN4gIWnbcyVjcrT39PoDNtWr+tNHluPfDLadW4iYSMjUeO7 Q9MS0NLnbrgUJ4CnqHiqEjHR8FX3BetVOyIWwVdSW7gz/Gbgpl5+Mk6ACsw4JrrtDe4+j0oj4Q8 HlPP5GowUKG6CRo+2yrpaun5+C0Zjzsxad8fKlobsjRHO89icwofGLZ++QpQzRfZmyUNDM6PbCS VZ5pxPNivZlqS5etBMskerROSCzdIvte+2gUSlHGOho7buv7d9FJFr2qlKix9mqt/GoHDbxztsj Ox63XuxEypKgSytcyt7QcXSi5EFWMK8bCqGv6nthCecAVGCOf04v0EQeJuGyKw/jGAHkc3fGbNu SeNqcN/RXQUfGHF2THNjxEfTH8yUriNjw9LoWjvqK9Dyg7qdQtZKsq3DGpal6ZoXEGXhCtWU62z vc1Dlo7pCr3t9itOYe/6aYxCz7bJYe6RsTDPSfTl/1fD/Gopd2K+lN2ZUJHbEQdG7H66TyOk/y0 w7JiZo Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lCiT5FeF7wvRgrK-ay-HXwHVm9A X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:12:13 -0000 Replying to Les, but only because it is the top email in the pile. Tome for someone to start proposing some (minor) charter text? Adrian > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Les Ginsberg > (ginsberg) > Sent: 25 April 2014 21:05 > To: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) > > I support the WG re-chartering to include all mentioned aspects of S-BFD work. > > Les > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > > Sent: Monday, April 21, 2014 1:33 PM > > To: rtg-bfd@ietf.org > > Subject: Working Group adoption for Seamless BFD (requires re-charter) > > > > Working Group, > > > > >From our last in-person IETF meeting in Vancouver, the S-BFD authors were > > going to put additional work into their use cases and base protocol > > document > > prior to requesting Working Group adoption. That work has since been > > done > > and, IMO, the quality of the documents has nicely improved. > > > > But, being IETF work, we'd like to carry out further work on the proposal in > > the openness of the WG. Thus, I'd like to request the Working Group to > > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > > Note that this work is currently outside the scope of our charter and would > > require a re-charter. Once we have a sense of the group for the interest in > > this task we'll propose the charter update in support of the drafts. > > > > The following two documents are current and describe the work: > > > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > > > Given the scope of this feature, I would like to particularly remind the > > Working Group to focus on its security aspects. > > > > The following three documents are slightly stale as a result of the > > revisions in the base and use cases draft and will require an update. > > However, they provide a sense of how the S-BFD mechanisms might be > > used. > > > > Note in particular that the SR work will require coordination with the > > SPRING Working Group. > > > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > > > Finally, there is known future work targeting the distribution of the > > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have > > been authored on the topic at this time, but work on them is expected. > > > > This begins a two week poll on whether the WG would like to adopt S-BFD > > as a > > chartered task. This poll ends on May 6. > > > > As part of your response, please indicate if you have specific concerns > > about individual drafts being part of this work. > > > > Since Nobo is a contributor to this work, I will be taking the part of the > > shepherding chair. > > > > -- Jeff From nobody Fri Apr 25 16:05:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F300F1A0415 for ; Fri, 25 Apr 2014 16:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.773 X-Spam-Level: X-Spam-Status: No, score=-109.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifPIgJXnLgeq for ; Fri, 25 Apr 2014 16:04:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8B01A068E for ; Fri, 25 Apr 2014 16:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4231; q=dns/txt; s=iport; t=1398467091; x=1399676691; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ubxb9VbKg89SJp963Pt085aiiQTf5VjdQHK2dP1BqVA=; b=hMSbTMFomvrt4VD816ngN1tQnDS4MSVa/MFL57OKMt9a3vux1nXMPH38 7vERL1JXk5KLU90jR2paLRGcYCcwTsPVoZPVypV256wn9Z0FYgnt3M+NS wb5zxQ2nUoJV5zDGpc1+2hpV0EIUEVZ0Bfrn+awsj2oQRBgYNCXddz1gM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFADvpWlOtJV2Y/2dsb2JhbABYgmUhT1fEIoETFnSCJQEBAQQ6SwQCAQgRBAEBCxQJBzIUCQgCBAESCIg5AQzKQBeNdxEBHzgGgx6BFQSaPZEkgzGBcjk X-IronPort-AV: E=Sophos;i="4.97,929,1389744000"; d="scan'208";a="38828349" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 25 Apr 2014 23:04:50 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3PN4o73024212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Apr 2014 23:04:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 18:04:50 -0500 From: "Nobo Akiya (nobo)" To: "adrian@olddog.co.uk" , "rtg-bfd@ietf.org" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDzsd8RqfWJjUqW3c8k2YnCwZsjG7qAgAASwwD//8a7AA== Date: Fri, 25 Apr 2014 23:04:49 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> <001b01cf60ca$f80aa060$e81fe120$@olddog.co.uk> In-Reply-To: <001b01cf60ca$f80aa060$e81fe120$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZLKTW_xdhtqS5svPq4Hue77gvmg X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 23:05:00 -0000 Hi Adrian, all, Attempt #1 Define a mechanism to run the BFD protocol to seamlessly verify a path func= tionality when needed, to provide flexibilities to the initiator to quickly= alter the BFD session operational state and parameters, and to allow the i= nitiator to run multiple BFD sessions per verified path. Tried to capture these characteristics: - Quick session up. - Flexibility to start, stop, resume, speed up/down the session [quickly] a= s needed. - Not restricting to one session per interface, LSP, etc. Open to tweaks, modifications and/or complete rewrites to what's proposed. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian Farre= l > Sent: Friday, April 25, 2014 5:12 PM > To: rtg-bfd@ietf.org > Subject: RE: Working Group adoption for Seamless BFD (requires re-charter= ) >=20 > Replying to Les, but only because it is the top email in the pile. >=20 > Tome for someone to start proposing some (minor) charter text? >=20 > Adrian >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Les > > Ginsberg > > (ginsberg) > > Sent: 25 April 2014 21:05 > > To: Jeffrey Haas; rtg-bfd@ietf.org > > Subject: RE: Working Group adoption for Seamless BFD (requires > > re-charter) > > > > I support the WG re-chartering to include all mentioned aspects of > > S-BFD > work. > > > > Les > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey > > > Haas > > > Sent: Monday, April 21, 2014 1:33 PM > > > To: rtg-bfd@ietf.org > > > Subject: Working Group adoption for Seamless BFD (requires > > > re-charter) > > > > > > Working Group, > > > > > > >From our last in-person IETF meeting in Vancouver, the S-BFD > > > >authors were > > > going to put additional work into their use cases and base protocol > > > document prior to requesting Working Group adoption. That work has > > > since been done and, IMO, the quality of the documents has nicely > > > improved. > > > > > > But, being IETF work, we'd like to carry out further work on the > > > proposal in the openness of the WG. Thus, I'd like to request the > > > Working Group to consider whether we'll want to adopt the Seamless > BFD (S-BFD) documents. > > > Note that this work is currently outside the scope of our charter > > > and would require a re-charter. Once we have a sense of the group > > > for the interest in this task we'll propose the charter update in sup= port of > the drafts. > > > > > > The following two documents are current and describe the work: > > > > > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > > > > > Given the scope of this feature, I would like to particularly remind > > > the Working Group to focus on its security aspects. > > > > > > The following three documents are slightly stale as a result of the > > > revisions in the base and use cases draft and will require an update. > > > However, they provide a sense of how the S-BFD mechanisms might be > > > used. > > > > > > Note in particular that the SR work will require coordination with > > > the SPRING Working Group. > > > > > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discr > > > im/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > > > > > Finally, there is known future work targeting the distribution of > > > the necessary S-BFD bootstrapping information in OSPF and ISIS. No > > > drafts have been authored on the topic at this time, but work on them= is > expected. > > > > > > This begins a two week poll on whether the WG would like to adopt > > > S-BFD as a chartered task. This poll ends on May 6. > > > > > > As part of your response, please indicate if you have specific > > > concerns about individual drafts being part of this work. > > > > > > Since Nobo is a contributor to this work, I will be taking the part > > > of the shepherding chair. > > > > > > -- Jeff From nobody Fri Apr 25 20:59:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D571A044B for ; Fri, 25 Apr 2014 20:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.773 X-Spam-Level: X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InN66wciJqCf for ; Fri, 25 Apr 2014 20:59:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BC4821A02E0 for ; Fri, 25 Apr 2014 20:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1469; q=dns/txt; s=iport; t=1398484778; x=1399694378; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=g45RDcS6AKUqTVoiH02iXbWUbICzH8/T6T1E79zWmxU=; b=UVLQWlptNnLrda6pnqKLWZRrObBnR8Z1lx29H0m57pMARXuSuBhtEklD VBQOVkZgQXfLZccwk+WB1dyt9njhTHEYmXlv8UmrNXTJkNz33ZuDex2OZ RdIP0cW2GLpm6bustU23i81/yrIR+Qdyppx4Jy4R8XStBnr9dSjrbNjOW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJsuW1OtJV2a/2dsb2JhbABZgmUhgSbETYETFnSCJQEBAQQ6SwYBGQQBAQsUBQQ5FAkJAQQBEgiIOQHKVxeNdxEBHz6DHoEVBKtngXKBP4FyOQ X-IronPort-AV: E=Sophos;i="4.97,931,1389744000"; d="scan'208";a="320499766" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2014 03:59:37 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3Q3xbQX010009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Apr 2014 03:59:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 22:59:37 -0500 From: "Nobo Akiya (nobo)" To: "adrian@olddog.co.uk" , "rtg-bfd@ietf.org" Subject: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKw== Date: Sat, 26 Apr 2014 03:59:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/E1Y5IEWHGlpXFo1_lIoAanUsQ8c X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 26 Apr 2014 03:59:47 -0000 [renaming the subject to separate the thread from the poll] > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Friday, April 25, 2014 7:05 PM > To: adrian@olddog.co.uk; rtg-bfd@ietf.org > Subject: RE: Working Group adoption for Seamless BFD (requires re-charter= ) >=20 > Hi Adrian, all, >=20 > Attempt #1 >=20 > Define a mechanism to run the BFD protocol to seamlessly verify a path > functionality when needed, to provide flexibilities to the initiator to q= uickly > alter the BFD session operational state and parameters, and to allow the > initiator to run multiple BFD sessions per verified path. >=20 > Tried to capture these characteristics: > - Quick session up. > - Flexibility to start, stop, resume, speed up/down the session [quickly]= as > needed. > - Not restricting to one session per interface, LSP, etc. >=20 > Open to tweaks, modifications and/or complete rewrites to what's > proposed. >=20 > -Nobo >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian > > Farrel > > Sent: Friday, April 25, 2014 5:12 PM > > To: rtg-bfd@ietf.org > > Subject: RE: Working Group adoption for Seamless BFD (requires > > re-charter) > > > > Replying to Les, but only because it is the top email in the pile. > > > > Tome for someone to start proposing some (minor) charter text? > > > > Adrian > > From nobody Sat Apr 26 08:56:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC771A033D for ; Sat, 26 Apr 2014 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HgQtFunt5dI for ; Sat, 26 Apr 2014 08:56:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2A1A02E4 for ; Sat, 26 Apr 2014 08:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2849; q=dns/txt; s=iport; t=1398527753; x=1399737353; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BodJq/WG9PfdoY9hBeus0TUgXNEh+nvgg0nKtPnT9/c=; b=f/K+e5jVwVu5QQE6NZt0heQxJXBGOZ72w0ZBTjDkGyJ0/75vn/+Q1IQL LWq7ZXT+fkxDHthTKzqgfSm1JdmZwzfeplHF+SKGLpNbYnnLrrxdWnulx 5lf4qG9aw8ZIo2BSzEgidiVoUM3SYBUC67D3tmagZXikH3gTasI8RPGAf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAL/VW1OtJV2Z/2dsb2JhbABZgwZPV8RbgQsWdIIlAQEBAwE6PwULAgEIDigQMiUCBA4FiDkIDcl4F44mMweDJIEVBJkMgTqRJIMxgis X-IronPort-AV: E=Sophos;i="4.97,933,1389744000"; d="scan'208";a="320590669" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 26 Apr 2014 15:55:52 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3QFtqUf026937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Apr 2014 15:55:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 10:55:52 -0500 From: "Carlos Pignataro (cpignata)" To: Jeff Haas Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDydxr57NvjD0u+gNvsWDo+T5skaI8A Date: Sat, 26 Apr 2014 15:55:51 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> In-Reply-To: <20140421203314.GF8955@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.204] Content-Type: text/plain; charset="us-ascii" Content-ID: <519887EDE2F45B498262382321855B8B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/erfViCWVK85HussARvcZHgX4xV4 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 15:56:02 -0000 Hi, Jeff, I support the BFD WG taking on the work on S-BFD, as it solves a clear prob= lem and strengthens the uses of BFD. I also support your proposed approach = of i. rechartering (I believe this can be done as a surgical addition and n= ot a major re-write), ii. adopting the -base and -usecase documents, and ii= i. continue to work and subsequently (later, not on this call) adopt the ot= her adjunct docs. Thanks, Carlos. On Apr 21, 2014, at 4:33 PM, Jeffrey Haas wrote: > Working Group, >=20 >> From our last in-person IETF meeting in Vancouver, the S-BFD authors wer= e > going to put additional work into their use cases and base protocol docum= ent > prior to requesting Working Group adoption. That work has since been don= e > and, IMO, the quality of the documents has nicely improved. >=20 > But, being IETF work, we'd like to carry out further work on the proposal= in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and wou= ld > require a re-charter. Once we have a sense of the group for the interest= in > this task we'll propose the charter update in support of the drafts. >=20 > The following two documents are current and describe the work: >=20 > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >=20 > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. >=20 > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be used. >=20 > Note in particular that the SR work will require coordination with the > SPRING Working Group. >=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/=20 > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >=20 > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts ha= ve > been authored on the topic at this time, but work on them is expected. >=20 > This begins a two week poll on whether the WG would like to adopt S-BFD a= s a > chartered task. This poll ends on May 6. >=20 > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. >=20 > Since Nobo is a contributor to this work, I will be taking the part of th= e > shepherding chair. >=20 > -- Jeff >=20 From nobody Sat Apr 26 08:57:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A71E1A02E4 for ; Sat, 26 Apr 2014 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRaEXXptQkCA for ; Sat, 26 Apr 2014 08:57:08 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id C5C351A033D for ; Sat, 26 Apr 2014 08:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1793; q=dns/txt; s=iport; t=1398527822; x=1399737422; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GIV46zOj3rq0fCc55PdjYuveeuRBa/1aCwCKBSA3v2w=; b=ZW/VE2YfQHlAONiKuecU/YEHxIUsCCgQUFhPF0nqNHFhyzvUoALwfH+u F9k7RHHkd1athP1CEUIrhq1Q4+UerUPTomt/lGIJdbcdXmgoAroAnLpUR NdP/zw4GNl5DXHaoCP7u0HuzgEvxgGdYJiduCYg+cDwFaJpTN0ad6Hfms w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAEXWW1OtJV2d/2dsb2JhbABZgwaBGgzEW4ELFnSCJQEBAQQ6PwwEAgEIEQQBAR8FBAcyFAkIAQEEDgWIQcoDF413EQEdMwcGgx6BFQEDmQySXoFygT+Bcjk X-IronPort-AV: E=Sophos;i="4.97,933,1389744000"; d="scan'208";a="39008038" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 26 Apr 2014 15:57:01 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3QFv1rp025081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Apr 2014 15:57:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 10:57:01 -0500 From: "Carlos Pignataro (cpignata)" To: "Nobo Akiya (nobo)" Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAjjzAA Date: Sat, 26 Apr 2014 15:57:01 +0000 Message-ID: <2E340A5B-3986-433C-BF6F-20F9A9DB0DAF@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.204] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D211D79D6FEB94AB6B640AAF7C70B12@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6furoYYOrhJzrSWUJq_x7QmLklE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 15:57:10 -0000 This looks really good -- I would add that BFD is expected to liaise and in= terface with other WGs in progressing the set of S-BFD work docs (e.g., SPR= ING, OSPF, ISIS) Thanks, Carlos. On Apr 25, 2014, at 11:59 PM, Nobo Akiya (nobo) wrote: > [renaming the subject to separate the thread from the poll] >=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya >> (nobo) >> Sent: Friday, April 25, 2014 7:05 PM >> To: adrian@olddog.co.uk; rtg-bfd@ietf.org >> Subject: RE: Working Group adoption for Seamless BFD (requires re-charte= r) >>=20 >> Hi Adrian, all, >>=20 >> Attempt #1 >>=20 >> Define a mechanism to run the BFD protocol to seamlessly verify a path >> functionality when needed, to provide flexibilities to the initiator to = quickly >> alter the BFD session operational state and parameters, and to allow the >> initiator to run multiple BFD sessions per verified path. >>=20 >> Tried to capture these characteristics: >> - Quick session up. >> - Flexibility to start, stop, resume, speed up/down the session [quickly= ] as >> needed. >> - Not restricting to one session per interface, LSP, etc. >>=20 >> Open to tweaks, modifications and/or complete rewrites to what's >> proposed. >>=20 >> -Nobo >>=20 >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian >>> Farrel >>> Sent: Friday, April 25, 2014 5:12 PM >>> To: rtg-bfd@ietf.org >>> Subject: RE: Working Group adoption for Seamless BFD (requires >>> re-charter) >>>=20 >>> Replying to Les, but only because it is the top email in the pile. >>>=20 >>> Tome for someone to start proposing some (minor) charter text? >>>=20 >>> Adrian >>>=20 >=20 From nobody Sat Apr 26 21:08:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFC71A070F for ; Sat, 26 Apr 2014 21:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozlfRbNA5yvs for ; Sat, 26 Apr 2014 21:08:38 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C8EAA1A070C for ; Sat, 26 Apr 2014 21:08:35 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-9a-535c34496df9 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E0.5D.05011.9443C535; Sun, 27 Apr 2014 00:33:46 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Sun, 27 Apr 2014 00:08:27 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "adrian@olddog.co.uk" , "rtg-bfd@ietf.org" Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvw Date: Sun, 27 Apr 2014 04:08:26 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPgq6XSUywwbT/ghY/em4wW8zuiLf4 /GcbowOzx5TfG1k9liz5yeSxYvNKxgDmKC6blNSczLLUIn27BK6MK98kCiYIViw/95m9gfEL bxcjJ4eEgInEu223mCBsMYkL99azdTFycQgJHGWU2DXtOTuEs5xR4sbUxcwgVWwCRhIvNvaw g9giAnUSTZtmAtkcHMICxRI/V0GFSyQObt7BCGEbSXw/288GYrMIqEr8+/MDbBmvgK/EiZfP wWqEBHwkVq9aCFbDCRSfvfgQC4jNCHTQ91NrwOqZBcQlbj2ZD3WogMSSPeeZIWxRiZeP/7FC 2EoSH3/PZ4eo15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG jtLi1LLcdCODTYzA6Dgmwaa7g3HPS8tDjAIcjEo8vIzLIoOFWBPLiitzDzFKc7AoifN+eesc JCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExJNTRN4cpb0Xb9wmzY2+vS0nb+/3PJhde3ukP HmxoWB4SdtD4zhOx3bcjpJrq5/lNUn+uzt7x5pO+zM2bYfnC9l6Gq7zyqpS+tkeULxWensSg kP/5ef2PPS/u5fi8ExWqnP66rVua5/3dRXX8NgumOj1cu0/0ltxrvrqOneycE99lzj65e8V+ JZbijERDLeai4kQAOoEh/28CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-5WDa6-WCqnuJfZdsdkpfNXVZ5k X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 27 Apr 2014 04:08:40 -0000 Hi Nobo, I've tried some rewording following characteristics you've set forth. Here'= s what came out: - define mechanism to perform single-ended continuity verification based on= BFD specification; - allow such mechanism to seamlessly work both proactively and on-demand; - allow the mechanism maintain multiple sessions between two given network = entities. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Friday, April 25, 2014 9:00 PM To: adrian@olddog.co.uk; rtg-bfd@ietf.org Subject: BFD charter update proposal [was: RE: Working Group adoption for S= eamless BFD (requires re-charter)] [renaming the subject to separate the thread from the poll] > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo=20 > Akiya > (nobo) > Sent: Friday, April 25, 2014 7:05 PM > To: adrian@olddog.co.uk; rtg-bfd@ietf.org > Subject: RE: Working Group adoption for Seamless BFD (requires=20 > re-charter) >=20 > Hi Adrian, all, >=20 > Attempt #1 >=20 > Define a mechanism to run the BFD protocol to seamlessly verify a path=20 > functionality when needed, to provide flexibilities to the initiator=20 > to quickly alter the BFD session operational state and parameters, and=20 > to allow the initiator to run multiple BFD sessions per verified path. >=20 > Tried to capture these characteristics: > - Quick session up. > - Flexibility to start, stop, resume, speed up/down the session=20 > [quickly] as needed. > - Not restricting to one session per interface, LSP, etc. >=20 > Open to tweaks, modifications and/or complete rewrites to what's=20 > proposed. >=20 > -Nobo >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian=20 > > Farrel > > Sent: Friday, April 25, 2014 5:12 PM > > To: rtg-bfd@ietf.org > > Subject: RE: Working Group adoption for Seamless BFD (requires > > re-charter) > > > > Replying to Les, but only because it is the top email in the pile. > > > > Tome for someone to start proposing some (minor) charter text? > > > > Adrian > > From nobody Sat Apr 26 23:43:25 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4311A0760 for ; Sat, 26 Apr 2014 23:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am9gvmaw-UdP for ; Sat, 26 Apr 2014 23:43:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF6F1A075A for ; Sat, 26 Apr 2014 23:43:19 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB753.namprd05.prod.outlook.com (10.141.208.140) with Microsoft SMTP Server (TLS) id 15.0.929.12; Sun, 27 Apr 2014 06:43:10 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.0929.001; Sun, 27 Apr 2014 06:43:10 +0000 From: Santosh P K To: Jeff Haas Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaEJ591aB652KkixX5G2/+MQ2ZskFLyAgADyiwA= Date: Sun, 27 Apr 2014 06:43:10 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-forefront-prvs: 01949FE337 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(199002)(189002)(377454003)(4396001)(20776003)(80022001)(76482001)(92566001)(85852003)(83072002)(33646001)(77982001)(46102001)(66066001)(19580405001)(74316001)(15975445006)(19580395003)(76576001)(80976001)(99286001)(74502001)(31966008)(99396002)(15202345003)(54356999)(76176999)(77096999)(50986999)(79102001)(81542001)(81342001)(83322001)(2656002)(561944002)(87936001)(86362001)(101416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB753; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:FEB8F2E7.8EFA55C1.71E74F73.4EE5D97D.20324; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SQsXLCeRfp6L0pq-uHdmW6KrDnY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 06:43:22 -0000 Hi, Jeff, I support the WG re-chartering to include all mentioned aspects of S-BFD w= ork.=20 Thanks Santosh P K=20 >=20 > On Apr 21, 2014, at 4:33 PM, Jeffrey Haas wrote: >=20 > > Working Group, > > > >> From our last in-person IETF meeting in Vancouver, the S-BFD authors > >> were > > going to put additional work into their use cases and base protocol > > document prior to requesting Working Group adoption. That work has > > since been done and, IMO, the quality of the documents has nicely impro= ved. > > > > But, being IETF work, we'd like to carry out further work on the > > proposal in the openness of the WG. Thus, I'd like to request the > > Working Group to consider whether we'll want to adopt the Seamless BFD = (S- > BFD) documents. > > Note that this work is currently outside the scope of our charter and > > would require a re-charter. Once we have a sense of the group for the > > interest in this task we'll propose the charter update in support of th= e drafts. > > > > The following two documents are current and describe the work: > > > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > > > Given the scope of this feature, I would like to particularly remind > > the Working Group to focus on its security aspects. > > > > The following three documents are slightly stale as a result of the > > revisions in the base and use cases draft and will require an update. > > However, they provide a sense of how the S-BFD mechanisms might be used= . > > > > Note in particular that the SR work will require coordination with the > > SPRING Working Group. > > > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim > > / http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > > > Finally, there is known future work targeting the distribution of the > > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts > > have been authored on the topic at this time, but work on them is expec= ted. > > > > This begins a two week poll on whether the WG would like to adopt > > S-BFD as a chartered task. This poll ends on May 6. > > > > As part of your response, please indicate if you have specific > > concerns about individual drafts being part of this work. > > > > Since Nobo is a contributor to this work, I will be taking the part of > > the shepherding chair. > > > > -- Jeff > > From nobody Sun Apr 27 07:47:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9EB1A04B9 for ; Sun, 27 Apr 2014 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.253 X-Spam-Level: X-Spam-Status: No, score=-108.253 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRvggjX9b2pE for ; Sun, 27 Apr 2014 07:47:39 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 813641A01D4 for ; Sun, 27 Apr 2014 07:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4090; q=dns/txt; s=iport; t=1398610059; x=1399819659; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pt+26ZFfJMqds+A/rOWlv26qIBe+mskO2w2YSA3iDzQ=; b=F0z1je1w0UlgjEjeFNVhAMNNN/K65mjJw1kdRKDNetkYz4DpH2Iz+Mw1 ieyJ7fa14bz9Q+CaoB5ECr/UpwnKu1pqXclQFbOaqOAk0D83lM/uW9mgH XzIZfpi/onnvsiTkTpm8kxp59I5B0+bx7UadkkEIio/2yQ/jfkrATs2qo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAIAXXVOtJV2a/2dsb2JhbABZgmUhgSbEXIEIFnSCJQEBAQQ6SwQCAQgRBAEBCxQFBAcyFAkIAQEEARIIiDkByQIXjXcRAR84BoMegRUEq2qBcoE/gXI5 X-IronPort-AV: E=Sophos;i="4.97,937,1389744000"; d="scan'208";a="39157601" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 27 Apr 2014 14:47:38 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3RElcUx020600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Apr 2014 14:47:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sun, 27 Apr 2014 09:47:38 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "adrian@olddog.co.uk" , "rtg-bfd@ietf.org" , "Carlos Pignataro (cpignata)" Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TA= Date: Sun, 27 Apr 2014 14:47:37 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/U1qbBQfad7I3q4tBLMJiZnKKuvs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 27 Apr 2014 14:47:42 -0000 Hi All, Thanks for the suggestion Carlos. I absolutely agree that a text regarding = liaison should be included. Thanks for thoughtful texts Greg. I agree with almost all, but tweaked some= texts (in first and third sentences). Reasons below. Here's consolidated charter text proposal. Attempt #2 Define a mechanism to perform single-ended path (ex: continuity) verificati= on based on the BFD specification; allow such mechanism to seamlessly work = both proactively and on-demand; allow the mechanism to maintain multiple se= ssions to a target entity. In doing this work, the WG will work closely wit= h at least the following other WGs: ISIS, OSPF, SPRING. =09 > - define mechanism to perform single-ended continuity verification based > on BFD specification; s/continuity verification based on BFD specification/path (ex: continuity) = verification on the BFD specification/ I agree that the continuity check is the primary goal of this new mechanism= . Although S-BFD alert discriminator requires further considerations and wo= rk, I prefer texts which implicitly excludes this mechanism. > - allow the mechanism maintain multiple sessions between two given > network entities.=09 s/ maintain multiple sessions between two given network entities/to maintai= n multiple sessions to a target entity/ I think it'll be a good idea for the word "maintain" to not imply anything = on the target side (i.e. reflector session). -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Sunday, April 27, 2014 12:08 AM > To: Nobo Akiya (nobo); adrian@olddog.co.uk; rtg-bfd@ietf.org > Subject: RE: BFD charter update proposal [was: RE: Working Group adoption > for Seamless BFD (requires re-charter)] >=20 > Hi Nobo, > I've tried some rewording following characteristics you've set forth. Her= e's > what came out: > - define mechanism to perform single-ended continuity verification based > on BFD specification; > - allow such mechanism to seamlessly work both proactively and on- > demand; > - allow the mechanism maintain multiple sessions between two given > network entities. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Friday, April 25, 2014 9:00 PM > To: adrian@olddog.co.uk; rtg-bfd@ietf.org > Subject: BFD charter update proposal [was: RE: Working Group adoption for > Seamless BFD (requires re-charter)] >=20 > [renaming the subject to separate the thread from the poll] >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Friday, April 25, 2014 7:05 PM > > To: adrian@olddog.co.uk; rtg-bfd@ietf.org > > Subject: RE: Working Group adoption for Seamless BFD (requires > > re-charter) > > > > Hi Adrian, all, > > > > Attempt #1 > > > > Define a mechanism to run the BFD protocol to seamlessly verify a path > > functionality when needed, to provide flexibilities to the initiator > > to quickly alter the BFD session operational state and parameters, and > > to allow the initiator to run multiple BFD sessions per verified path. > > > > Tried to capture these characteristics: > > - Quick session up. > > - Flexibility to start, stop, resume, speed up/down the session > > [quickly] as needed. > > - Not restricting to one session per interface, LSP, etc. > > > > Open to tweaks, modifications and/or complete rewrites to what's > > proposed. > > > > -Nobo > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian > > > Farrel > > > Sent: Friday, April 25, 2014 5:12 PM > > > To: rtg-bfd@ietf.org > > > Subject: RE: Working Group adoption for Seamless BFD (requires > > > re-charter) > > > > > > Replying to Les, but only because it is the top email in the pile. > > > > > > Tome for someone to start proposing some (minor) charter text? > > > > > > Adrian > > > From nobody Sun Apr 27 07:57:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F321A067C for ; Sun, 27 Apr 2014 07:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWQYDpK8ZJOq for ; Sun, 27 Apr 2014 07:57:23 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 951541A067E for ; Sun, 27 Apr 2014 07:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5145; q=dns/txt; s=iport; t=1398610643; x=1399820243; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QbevnS+l0Xu962PX0KaFiItpdVDDsEjhx9o2ClJnCHc=; b=Jk5FY5jkKyrPlaE66RJLUbln9P5B88gDtt+5Rb8zdUUpuZ8jl4CVMz22 pU9SbHfujuoq4n9pQRXFS3mwttOMa+GKzvB6T89r7W1vxd0zIM8MIkFtt czN4PXDIhrGnWQeR7jJ3zE6VgCNW+BEPp+x9cHpDlv+IDW75ucd5vCwWB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFANQZXVOtJA2H/2dsb2JhbABZgmUhgSbEXIEIFnSCJQEBAQQ6SwQCAQgRBAEBCxQFBAcyFAkIAQEEARIIiDkByQYXjXcRAR84BoMegRUEq2qBcoE/gXI5 X-IronPort-AV: E=Sophos;i="4.97,937,1389744000"; d="scan'208";a="39145620" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 27 Apr 2014 14:57:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3REvMJk010126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Apr 2014 14:57:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Sun, 27 Apr 2014 09:57:21 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "adrian@olddog.co.uk" , "rtg-bfd@ietf.org" , "Carlos Pignataro (cpignata)" Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAALfpgA== Date: Sun, 27 Apr 2014 14:57:21 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FGHQ9IHuTWIG6jA2XdSoOKUXdnY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 27 Apr 2014 14:57:26 -0000 Hi, Correcting one typo below. > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Sunday, April 27, 2014 10:48 AM > To: Gregory Mirsky; adrian@olddog.co.uk; rtg-bfd@ietf.org; Carlos Pignata= ro > (cpignata) > Subject: RE: BFD charter update proposal [was: RE: Working Group adoption > for Seamless BFD (requires re-charter)] >=20 > Hi All, >=20 > Thanks for the suggestion Carlos. I absolutely agree that a text regardin= g > liaison should be included. >=20 > Thanks for thoughtful texts Greg. I agree with almost all, but tweaked so= me > texts (in first and third sentences). Reasons below. >=20 > Here's consolidated charter text proposal. >=20 >=20 > Attempt #2 >=20 > Define a mechanism to perform single-ended path (ex: continuity) > verification based on the BFD specification; allow such mechanism to > seamlessly work both proactively and on-demand; allow the mechanism to > maintain multiple sessions to a target entity. In doing this work, the WG= will > work closely with at least the following other WGs: ISIS, OSPF, SPRING. >=20 >=20 > > - define mechanism to perform single-ended continuity verification > > based on BFD specification; >=20 > s/continuity verification based on BFD specification/path (ex: continuity= ) > verification on the BFD specification/ >=20 > I agree that the continuity check is the primary goal of this new mechani= sm. > Although S-BFD alert discriminator requires further considerations and wo= rk, > I prefer texts which implicitly excludes this mechanism. s/implicitly excludes/implicitly does not exclude/ Text should have been: I agree that the continuity check is the primary goal of this new mechanism= . Although S-BFD alert discriminator requires further considerations and wo= rk, I prefer texts which implicitly does not excludes this mechanism. Sorry about that, should've had more coffee before writing this email :) -Nobo >=20 > > - allow the mechanism maintain multiple sessions between two given > > network entities. >=20 > s/ maintain multiple sessions between two given network entities/to > maintain multiple sessions to a target entity/ >=20 > I think it'll be a good idea for the word "maintain" to not imply anythin= g on > the target side (i.e. reflector session). >=20 > -Nobo >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Sunday, April 27, 2014 12:08 AM > > To: Nobo Akiya (nobo); adrian@olddog.co.uk; rtg-bfd@ietf.org > > Subject: RE: BFD charter update proposal [was: RE: Working Group > > adoption for Seamless BFD (requires re-charter)] > > > > Hi Nobo, > > I've tried some rewording following characteristics you've set forth. > > Here's what came out: > > - define mechanism to perform single-ended continuity verification > > based on BFD specification; > > - allow such mechanism to seamlessly work both proactively and on- > > demand; > > - allow the mechanism maintain multiple sessions between two given > > network entities. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Friday, April 25, 2014 9:00 PM > > To: adrian@olddog.co.uk; rtg-bfd@ietf.org > > Subject: BFD charter update proposal [was: RE: Working Group adoption > > for Seamless BFD (requires re-charter)] > > > > [renaming the subject to separate the thread from the poll] > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > > Akiya > > > (nobo) > > > Sent: Friday, April 25, 2014 7:05 PM > > > To: adrian@olddog.co.uk; rtg-bfd@ietf.org > > > Subject: RE: Working Group adoption for Seamless BFD (requires > > > re-charter) > > > > > > Hi Adrian, all, > > > > > > Attempt #1 > > > > > > Define a mechanism to run the BFD protocol to seamlessly verify a > > > path functionality when needed, to provide flexibilities to the > > > initiator to quickly alter the BFD session operational state and > > > parameters, and to allow the initiator to run multiple BFD sessions p= er > verified path. > > > > > > Tried to capture these characteristics: > > > - Quick session up. > > > - Flexibility to start, stop, resume, speed up/down the session > > > [quickly] as needed. > > > - Not restricting to one session per interface, LSP, etc. > > > > > > Open to tweaks, modifications and/or complete rewrites to what's > > > proposed. > > > > > > -Nobo > > > > > > > -----Original Message----- > > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > > Adrian Farrel > > > > Sent: Friday, April 25, 2014 5:12 PM > > > > To: rtg-bfd@ietf.org > > > > Subject: RE: Working Group adoption for Seamless BFD (requires > > > > re-charter) > > > > > > > > Replying to Les, but only because it is the top email in the pile. > > > > > > > > Tome for someone to start proposing some (minor) charter text? > > > > > > > > Adrian > > > > From nobody Mon Apr 28 05:50:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93941A0710; Mon, 28 Apr 2014 05:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MERyLJ9g33KS; Mon, 28 Apr 2014 05:50:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF86F1A09F1; Mon, 28 Apr 2014 05:50:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-18.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428125016.32415.40720.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 05:50:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/phWRWWr5nvkMgeToMQdSLpWKZCk Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:50:21 -0000 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 Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-18.txt Pages : 38 Date : 2014-04-28 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 06:48:37 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4845E1A0A18 for ; Mon, 28 Apr 2014 06:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12S-kHqmaRTM for ; Mon, 28 Apr 2014 06:48:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5361A09F9 for ; Mon, 28 Apr 2014 06:48:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AAC35C12C; Mon, 28 Apr 2014 09:48:30 -0400 (EDT) Date: Mon, 28 Apr 2014 09:48:30 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Message-ID: <20140428134830.GB1256@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/1dqtpNCQv5DsV9nvjLMKG-14UgA Cc: "rtg-bfd@ietf.org" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 13:48:36 -0000 [Not specifically speaking as a chair here...] On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: > Here's consolidated charter text proposal. > > > Attempt #2 > > Define a mechanism to perform single-ended path (ex: continuity) verification based on the BFD specification; allow such mechanism to seamlessly work both proactively and on-demand; allow the mechanism to maintain multiple sessions to a target entity. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. So... what exactly does seamless mean here? What seams were you seeing that you were trying to remove? FWIW, I think the charter discussion is moving along well, but I've never quite groked the context for "seamless" for the proposal. "Stateless" BFD, I can see quite well. -- Jeff From nobody Mon Apr 28 07:28:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE88D1A0A18; Mon, 28 Apr 2014 07:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPjx954n08Zr; Mon, 28 Apr 2014 07:20:40 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id DD51B1A047E; Mon, 28 Apr 2014 07:20:39 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3SEKZxV016338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Apr 2014 10:20:37 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s3SEKZxV016338 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1398694837; bh=ifxQuMJFdVKke3no56uo8mXGgoI=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=db0MLgTiIUMLR66yqA5EFBQEm9S+RSrDcLf5EzY9oX3hQ/+xcLBCBTv+9tAs+Vot3 p2Y9MP/Sevioz1sT04Vz8G8ZN59T/waqhDC2pD4mpuI8pmM8Me2eXogG5vyFr3mntF 2YcTMaE69Q3mfkAyJWCKb2OG5PVyWyRs9c/f1Suo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s3SEKZxV016338 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 28 Apr 2014 10:20:26 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3SEKPDB001656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 10:20:26 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub35.corp.emc.com ([::1]) with mapi; Mon, 28 Apr 2014 10:20:25 -0400 From: "Black, David" To: "tnadeau@lucidvision.com" , "zali@cisco.com" , "nobo@cisco.com" , "General Area Review Team (gen-art@ietf.org)" Date: Mon, 28 Apr 2014 10:20:23 -0400 Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Index: Ac9i7PyERuk5jZsyQOKSHRHy2Ij/Lw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C437CE3@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gpHTNFUGDczbFzP8lcS9sLE3W8s X-Mailman-Approved-At: Mon, 28 Apr 2014 07:28:54 -0700 Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" , "Black, David" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 14:20:46 -0000 The -18 version of this draft responds to all of the comments in the Gen-ART review of -17, including the request for coordination w/the OPS area, although I wasn't exactly expecting that to occur on the main IETF list. The -18 version is ready with one small nit - The following text has been added to the introduction: This memo does not define a compliance requirement for a system that=09 only implements BFD version 0. This is a reflection of a considered=09 and deliberate decision by the BFD WG. An explanation of the rationale for that decision would help - I suggest adding the following text and a suitable reference to the end of the text above: =20 because the BFD version 0 protocol may deadlock and hence SHOULD NOT be used, as explained further in [RFCxxxx]. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, April 16, 2014 7:31 PM > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General Area > Review Team (gen-art@ietf.org) > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > Subject: Gen-ART review of draft-ietf-bfd-mib-17 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-bfd-mib-17 > Reviewer: David L. Black > Review Date: April 16, 2014 > IETF LC End Date: April 28, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft is a MIB module for the BFD protocol, which is an important lo= w- > level routing protocol. The draft is reasonable for a MIB draft; one nee= ds > to go read the protocol documents to understand how the protocol works, a= nd > significant portions of the text are derived from the usual MIB "boilerpl= ate" > as one would expect. The "Brief Description of MIB Objects" is indeed > brief, but reasonable. The shepherd writeup indicates that there are > multiple implementations. >=20 > Major issues: >=20 > This MIB contains many writable objects, so the authors should > take note of the IESG statement on writable MIB modules: >=20 > http://www.ietf.org/iesg/statement/writable-mib-module.html >=20 > I did not see this mentioned in the shepherd writeup. If the OPS Area > has not been consulted, I strongly suggest doing so during IETF Last > Call, e.g., starting with Benoit Claise (AD). >=20 > Minor issues: >=20 > The security considerations section includes considerations for > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus, > but omits the corresponding considerations for bfdAdminStatus and > bfdSessNotificationsEnable. Both of the latter objects are global, > so significant damage can be inflicted via these objects with a > small number of unauthorized modifications, so they need to be > included in the first list of sensitive objects. >=20 > I suggest that the authors recheck the entire MIB to ensure that > every object or table that should be included in the security > considerations section is appropriately included. >=20 > Also, as a General Variable, would bfdSessNotificationsEnable be better > named bfdNotificationsEnable, as it's not in the BFD Session Table? >=20 > I did not see a compliance requirement for a system that only > implements BFD protocol version 0. That absence should at least be > mentioned somewhere. For example, if this reflects a considered and > deliberate decision by the WG, that should be mentioned in the > introduction. >=20 > Nits/editorial comments: >=20 > In the security considerations for authentication-related objects: >=20 > OLD > In order for these sensitive information > from being improperly accessed, implementers MAY wish to disallow > access to these objects. > NEW > In order to prevent this sensitive information > from being improperly accessed, implementers MAY disallow > access to these objects. >=20 > idnits 2.13.01 found a truly minor nit that should be corrected when > the draft is next revised: >=20 > =3D=3D Outdated reference: A later version (-05) exists of > draft-ietf-bfd-tc-mib-04 >=20 > it also generated a warning that probably does not reflect an actual prob= lem: >=20 > -- The document seems to lack a disclaimer for pre-RFC5378 work, but ma= y > have content which was first submitted before 10 November 2008. If = you > have contacted all the original authors and they are all willing to = grant > the BCP78 rights to the IETF Trust, then this is fine, and you can i= gnore > this comment. If not, you may need to add the pre-RFC5378 disclaime= r. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Mon Apr 28 10:46:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042971A6F46; Mon, 28 Apr 2014 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7-YSXwmlJCl; Mon, 28 Apr 2014 10:46:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id E62E71A6F54; Mon, 28 Apr 2014 10:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6446; q=dns/txt; s=iport; t=1398707190; x=1399916790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JyCIPF2EoPy9QGYyxwF75PYSuSCAvEUjofgznu3yey0=; b=aXuU9KPUVVM1bf4PfNkZTps9C5+lI7gec250ERi64ySPEhWfgza9BuyP 33/j5tLRGh+am9hokuD4MmSM6bZ0FuWLIEx2f6xaM2hpKlbpwF6vK8dX2 EFQ9A5sqaPCRHuIq9ooWx6IrXHcdXUqBnVapSXGfRQ9LJl/7tbTDvmu6i o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAHqTXlOtJV2b/2dsb2JhbABWA4JlIU9XxGmBGRZ0giUBAQEDAXkMBAIBCBEDAQEBCx0HMhQJCAEBBAENBQgBiDAIAQzIMheMZ4FBIRACBQYLgxOBFQSIfziLY4UskSSDMYIr X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="39406939" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 28 Apr 2014 17:46:28 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3SHkS6e015443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 17:46:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 12:46:28 -0500 From: "Nobo Akiya (nobo)" To: "Black, David" , "tnadeau@lucidvision.com" , "Zafar Ali (zali)" , "General Area Review Team (gen-art@ietf.org)" Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Index: Ac9i7PyERuk5jZsyQOKSHRHy2Ij/LwAG2CxA Date: Mon, 28 Apr 2014 17:46:28 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C437CE3@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C437CE3@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.215] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PdtwPeHKqb4IzvAhk5JPm9WLWDc Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 17:46:33 -0000 Hi David, > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Monday, April 28, 2014 10:20 AM > To: tnadeau@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); General > Area Review Team (gen-art@ietf.org) > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 >=20 > The -18 version of this draft responds to all of the comments in the Gen-= ART > review of -17, including the request for coordination w/the OPS area, > although I wasn't exactly expecting that to occur on the main IETF list. Thanks, they were very good comments. >=20 > The -18 version is ready with one small nit - The following text has been > added to the introduction: >=20 > This memo does not define a compliance requirement for a system that >=20 > only implements BFD version 0. This is a reflection of a considered > and deliberate decision by the BFD WG. >=20 > An explanation of the rationale for that decision would help - I suggest > adding the following text and a suitable reference to the end of the text > above: >=20 > because the BFD version 0 protocol may deadlock and hence SHOULD NOT > be used, as explained further in [RFCxxxx]. Unfortunately the problem with BFD version 0 is not documented in any RFCs,= and MIB is probably not the right place to start this documentation either= . If this should be documented in a RFC, possibly a new info document or ra= ise errata on RFC5880 ... I'm not sure what would be a reasonable/recommend= ed path here. In any case, my vote for the MIB document(s) is to keep the c= urrent text to proceed. Would that be ok with you? -Nobo >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Wednesday, April 16, 2014 7:31 PM > > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General > > Area Review Team (gen-art@ietf.org) > > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > > Subject: Gen-ART review of draft-ietf-bfd-mib-17 > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-bfd-mib-17 > > Reviewer: David L. Black > > Review Date: April 16, 2014 > > IETF LC End Date: April 28, 2014 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft is a MIB module for the BFD protocol, which is an important > > low- level routing protocol. The draft is reasonable for a MIB draft; > > one needs to go read the protocol documents to understand how the > > protocol works, and significant portions of the text are derived from t= he > usual MIB "boilerplate" > > as one would expect. The "Brief Description of MIB Objects" is indeed > > brief, but reasonable. The shepherd writeup indicates that there are > > multiple implementations. > > > > Major issues: > > > > This MIB contains many writable objects, so the authors should take > > note of the IESG statement on writable MIB modules: > > > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > > > I did not see this mentioned in the shepherd writeup. If the OPS Area > > has not been consulted, I strongly suggest doing so during IETF Last > > Call, e.g., starting with Benoit Claise (AD). > > > > Minor issues: > > > > The security considerations section includes considerations for > > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus, > > but omits the corresponding considerations for bfdAdminStatus and > > bfdSessNotificationsEnable. Both of the latter objects are global, so > > significant damage can be inflicted via these objects with a small > > number of unauthorized modifications, so they need to be included in > > the first list of sensitive objects. > > > > I suggest that the authors recheck the entire MIB to ensure that every > > object or table that should be included in the security considerations > > section is appropriately included. > > > > Also, as a General Variable, would bfdSessNotificationsEnable be > > better named bfdNotificationsEnable, as it's not in the BFD Session Tab= le? > > > > I did not see a compliance requirement for a system that only > > implements BFD protocol version 0. That absence should at least be > > mentioned somewhere. For example, if this reflects a considered and > > deliberate decision by the WG, that should be mentioned in the > > introduction. > > > > Nits/editorial comments: > > > > In the security considerations for authentication-related objects: > > > > OLD > > In order for these sensitive information > > from being improperly accessed, implementers MAY wish to disallow > > access to these objects. > > NEW > > In order to prevent this sensitive information > > from being improperly accessed, implementers MAY disallow > > access to these objects. > > > > idnits 2.13.01 found a truly minor nit that should be corrected when > > the draft is next revised: > > > > =3D=3D Outdated reference: A later version (-05) exists of > > draft-ietf-bfd-tc-mib-04 > > > > it also generated a warning that probably does not reflect an actual > problem: > > > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but > may > > have content which was first submitted before 10 November 2008. I= f > you > > have contacted all the original authors and they are all willing t= o grant > > the BCP78 rights to the IETF Trust, then this is fine, and you can= ignore > > this comment. If not, you may need to add the pre-RFC5378 disclai= mer. > > (See the Legal Provisions document at > > http://trustee.ietf.org/license-info for more information.) > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer EMC Corporation, 176 South St., > > Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- From nobody Mon Apr 28 10:47:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4702F1A6FB8 for ; Mon, 28 Apr 2014 10:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjzG0_9QDADm for ; Mon, 28 Apr 2014 10:47:14 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AFD1A6FBE for ; Mon, 28 Apr 2014 10:46:59 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 615482AA0F; Mon, 28 Apr 2014 17:46:55 +0000 (GMT) Date: Mon, 28 Apr 2014 10:46:54 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140428104654386978.13c1089a@sniff.de> In-Reply-To: <20140428134830.GB1256@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/YvnL7MPzb8LsKygEc2tSC-mxjcs Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 17:47:17 -0000 Hello, > So... what exactly does seamless mean here? What seams were you seeing that > you were trying to remove? :-) I took the "seamless" always as a nice label. Bit marketing, no harm. If someone would ask me to describe it: it's a single-sided BFD, driven by the active side, supported by a (passive, stateless) reflector. Somehow I also stumble over "single-ended" but I assume it means start and end point are the same. Technically maybe not 100% accurate as the reflector processes the packet, i.e. it's not the pure forwarding U-turn we have with echo. But when turns being exact into being non-helpful? ;-) Nevertheless, I like the direction the combined Nobo+Greg+Carlos text takes. Regards, Marc On Mon, 28 Apr 2014 09:48:30 -0400, Jeffrey Haas wrote: > [Not specifically speaking as a chair here...] > > On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: >> Here's consolidated charter text proposal. >> >> >> Attempt #2 >> >> Define a mechanism to perform single-ended path (ex: continuity) >> verification based on the BFD specification; allow such mechanism to >> seamlessly work both proactively and on-demand; allow the mechanism to >> maintain multiple sessions to a target entity. In doing this work, the WG >> will work closely with at least the following other WGs: ISIS, OSPF, >> SPRING. > > So... what exactly does seamless mean here? What seams were you seeing that > you were trying to remove? > > FWIW, I think the charter discussion is moving along well, but I've never > quite groked the context for "seamless" for the proposal. "Stateless" BFD, > I can see quite well. > > -- Jeff > From nobody Mon Apr 28 11:01:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B97C1A6F54 for ; Mon, 28 Apr 2014 11:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGXf0NcKx6as for ; Mon, 28 Apr 2014 11:01:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A09C41A6F46 for ; Mon, 28 Apr 2014 11:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3616; q=dns/txt; s=iport; t=1398708106; x=1399917706; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SrhlDi5mfUYNbwAOFFtW/4lwfempyjsqKRxvZjBRv8o=; b=BKDrnFqpN5iYM7jIU2tLxWealejNKU6kFyvj8ZeVNOc7oeHhmOyUteb4 B8FKrtdkuQQChT/7c4prBGcd0OZlK6EyHJ/qWFujTeuBblzfh2bADYgCY Abd4p/Sk7ql0k2tkPDhJ88RlcGTZD4dFtwARfvS3m4y0Tx4R6t0FdsVnA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAHeWXlOtJV2b/2dsb2JhbABZgmUhgSbEaYEZFnSCJQEBAQMBOjUKBQcEAgEIEQQBAQEKFAUEBzIUCQgBAQQBDQUIiDEIAchBF44oMQcGgx6BFQSraoFygT+CKw X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="321039385" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 28 Apr 2014 18:01:45 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3SI1jLP000581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 18:01:45 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 13:01:45 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Jeffrey Haas Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOymQAAAIU3YAAApkkDA= Date: Mon, 28 Apr 2014 18:01:44 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> In-Reply-To: <20140428104654386978.13c1089a@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7hXmr7A0AA_p93UrGxZqhIczZug Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:01:48 -0000 Hi Jeff, Marc, all, > > So... what exactly does seamless mean here? What seams were you > > seeing that you were trying to remove? >=20 > :-) >=20 > I took the "seamless" always as a nice label. Bit marketing, no harm. Indeed lol. There has been several occasion of "name discussion", but we co= uldn't converge on something better than "seamless". In any case, "seamless" is primary intended to describe: - No bootstrapping - No session up negotiation Meaning "seam" is the time when a node wants to verify a path to the time w= hen a node has verified the path. "stateless" does also capture large part of this (i.e. reflector side). If = we focus on the naming based on the reflector side, then "stateless" is pro= bably a better choice. If we focus the naming based on the initiator side, = then "seamless" does the job better. As far as the charter text is concerned, I have no objection to replacing t= he word "seamless" with something else, if anyone wants to propose a text. > Somehow I also stumble over "single-ended" but I assume it means start > and end point are the same. Technically maybe not 100% accurate as the > reflector processes the packet, i.e. it's not the pure forwarding U-turn = we > have with echo. But when turns being exact into being non-helpful? ;-) That's what I assumed as well. > Nevertheless, I like the direction the combined Nobo+Greg+Carlos text > takes. :) -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, April 28, 2014 1:47 PM > To: Jeffrey Haas > Cc: Nobo Akiya (nobo); rtg-bfd@ietf.org; Carlos Pignataro (cpignata) > Subject: Re: BFD charter update proposal [was: RE: Working Group adoption > for Seamless BFD (requires re-charter)] >=20 > Hello, >=20 > > So... what exactly does seamless mean here? What seams were you > > seeing that you were trying to remove? >=20 > :-) >=20 > I took the "seamless" always as a nice label. Bit marketing, no harm. >=20 > If someone would ask me to describe it: it's a single-sided BFD, driven b= y > the active side, supported by a (passive, stateless) reflector. >=20 > Somehow I also stumble over "single-ended" but I assume it means start > and end point are the same. Technically maybe not 100% accurate as the > reflector processes the packet, i.e. it's not the pure forwarding U-turn = we > have with echo. But when turns being exact into being non-helpful? ;-) >=20 > Nevertheless, I like the direction the combined Nobo+Greg+Carlos text > takes. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Mon, 28 Apr 2014 09:48:30 -0400, Jeffrey Haas wrote: > > [Not specifically speaking as a chair here...] > > > > On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: > >> Here's consolidated charter text proposal. > >> > >> > >> Attempt #2 > >> > >> Define a mechanism to perform single-ended path (ex: continuity) > >> verification based on the BFD specification; allow such mechanism to > >> seamlessly work both proactively and on-demand; allow the mechanism > >> to maintain multiple sessions to a target entity. In doing this work, > >> the WG will work closely with at least the following other WGs: ISIS, > >> OSPF, SPRING. > > > > So... what exactly does seamless mean here? What seams were you > > seeing that you were trying to remove? > > > > FWIW, I think the charter discussion is moving along well, but I've > > never quite groked the context for "seamless" for the proposal. > > "Stateless" BFD, I can see quite well. > > > > -- Jeff > > From nobody Mon Apr 28 11:18:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B351A6F54 for ; Mon, 28 Apr 2014 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qSsdio_Bab5 for ; Mon, 28 Apr 2014 11:17:57 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF021A6FA3 for ; Mon, 28 Apr 2014 11:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1667; q=dns/txt; s=iport; t=1398709076; x=1399918676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jKTY0sb4riIdqtdlNePPJZ3ca6fMVgCT/AHrpU5QpwA=; b=b1AtXzppkpuKknALAmN3jTEE0SgKvU6geSeRah+6LSezHP+3qIWUJkCE h71KVQcVzCkIQgOae6p89bnK5Ebnt2XRNB4H6NqoakbZeCY/6Pqo+/Pmj wcZoQmGfwhL8CJO8UDXEvBYlHt1xBE0NVYiHMnrAUZt1e5S8PDeBQuYqu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPCaXlOtJA2G/2dsb2JhbABZgwaBJsRqgRkWdIIlAQEBBDo/EAIBCA4KHgULMiUBAQQOBYhByEUXjiYzB4MkgRUBA5kMkl6BcoE/gis X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="39418402" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP; 28 Apr 2014 18:17:56 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3SIHurU009006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 18:17:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 13:17:56 -0500 From: "Carlos Pignataro (cpignata)" To: Jeff Haas Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOymQAAAJaKAA Date: Mon, 28 Apr 2014 18:17:55 +0000 Message-ID: <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> In-Reply-To: <20140428134830.GB1256@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ghthqk-o6DrQVmlD_HtOPOJYaAU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:17:59 -0000 Hi Jeff, On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: > [Not specifically speaking as a chair here...] >=20 > On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: >> Here's consolidated charter text proposal. >>=20 >>=20 >> Attempt #2 >>=20 >> Define a mechanism to perform single-ended path (ex: continuity) verific= ation based on the BFD specification; allow such mechanism to seamlessly wo= rk both proactively and on-demand; allow the mechanism to maintain multiple= sessions to a target entity. In doing this work, the WG will work closely = with at least the following other WGs: ISIS, OSPF, SPRING. >=20 > So... what exactly does seamless mean here? What seams were you seeing t= hat > you were trying to remove? >=20 > FWIW, I think the charter discussion is moving along well, but I've never > quite groked the context for "seamless" for the proposal. "Stateless" BF= D, > I can see quite well. >=20 Like others have said, we had some renaming discussions. Now it would be a = good time to converge. Some of the (not perfect, but perfect is the enemy o= f good and progress here) more technical qualifiers are "Stateless", "Refle= ctor", "Responder", "Mesh Group", "Asymmetric". These focus on the behavior= of the responder mostly. Descriptive ones are also possible like "Easy", "= Simple", "Seamless", etc. Frankly I am not concerned about which name -- other than we should be cons= istent. Net-net: I support your proposal of "Stateless" and a %s/Seamless/Stateless= /g. It also keeps the same abbrev of S-BFD. What do others think? Thanks, Carlos. > -- Jeff From nobody Mon Apr 28 11:48:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDCA1A6FB5 for ; Mon, 28 Apr 2014 11:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOivIfq871DW for ; Mon, 28 Apr 2014 11:48:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 866B01A04F1 for ; Mon, 28 Apr 2014 11:48:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C7106C3F4; Mon, 28 Apr 2014 14:48:42 -0400 (EDT) Date: Mon, 28 Apr 2014 14:48:42 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Message-ID: <20140428184842.GG1256@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8ZszgOlFdCE6YmKk4_1OPh3Z4Kk Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:48:44 -0000 Nobo, On Mon, Apr 28, 2014 at 06:01:44PM +0000, Nobo Akiya (nobo) wrote: > In any case, "seamless" is primary intended to describe: > - No bootstrapping > - No session up negotiation > > Meaning "seam" is the time when a node wants to verify a path to the time when a node has verified the path. > > "stateless" does also capture large part of this (i.e. reflector side). If we focus on the naming based on the reflector side, then "stateless" is probably a better choice. If we focus the naming based on the initiator side, then "seamless" does the job better. > > As far as the charter text is concerned, I have no objection to replacing the word "seamless" with something else, if anyone wants to propose a text. And this is most of my point for charter discussion purposes. If the word is intended to mostly be an empty marketing word, let's not do that. It only confuses technical specifications. :-) To my mind, the "fast" property you're looking for isn't a seam since it's part of how the protocol works today. Seams are where you have several things butting together that require interfacing. In this case, it's all of the same components, just optimizing some of the cases. -- Jeff From nobody Mon Apr 28 12:05:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04DC1A6FD2 for ; Mon, 28 Apr 2014 12:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NeFCM4tPzVx for ; Mon, 28 Apr 2014 12:05:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5E1A6FB7 for ; Mon, 28 Apr 2014 12:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2117; q=dns/txt; s=iport; t=1398711915; x=1399921515; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HzeHcj/1zT/muvQbkV30Izo9PqnCQUeQxtIv9eTAggY=; b=euYlUJDMU/2HG2dHwhBQyHcH/5gSPmeeiroV9ENu/qsU1ldOHFIv3/FJ OV3O/4cA3GVu5EV3c3mT6AzANhiLlRl6w3DDBHbrJ7LlN6VHVtDJKUcaC bpH0W0OGd2E0M3G/V8JbkCfzZxmjEfdi/+ptLM85J0Kn8m0iECQmVRliy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAPqkXlOtJV2Y/2dsb2JhbABZgmUhgSbEaoEZFnSCJQEBAQQ6NQoMBAIBCA4DBAEBAQoUBQQHMhQJCAIEDgUIiDkByGEXjigxBwaDHoEVBKtqgXKBP4Ir X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="320967041" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 28 Apr 2014 19:05:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3SJ5EVx021971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 19:05:14 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 14:05:14 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOymQAAAIU3YAAApkkDD//74fAIAAUjDw Date: Mon, 28 Apr 2014 19:05:13 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> In-Reply-To: <20140428184842.GG1256@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/MsM2UejIZsrX7iik9CXYW5yaGl8 Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:05:17 -0000 Hi Jeff, Ok :) Here's Attempt #3: Define a mechanism to perform single-ended path (ex: continuity) verificati= on based on the BFD specification; allow such mechanism to work both proact= ively and on-demand, without prominent initial delay; allow the mechanism t= o maintain multiple sessions to a target entity. In doing this work, the WG= will work closely with at least the following other WGs: ISIS, OSPF, SPRIN= G. -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Monday, April 28, 2014 2:49 PM > To: Nobo Akiya (nobo) > Cc: Marc Binderberger; Jeffrey Haas; rtg-bfd@ietf.org; Carlos Pignataro > (cpignata) > Subject: Re: BFD charter update proposal [was: RE: Working Group adoption > for Seamless BFD (requires re-charter)] >=20 > Nobo, >=20 > On Mon, Apr 28, 2014 at 06:01:44PM +0000, Nobo Akiya (nobo) wrote: > > In any case, "seamless" is primary intended to describe: > > - No bootstrapping > > - No session up negotiation > > > > Meaning "seam" is the time when a node wants to verify a path to the > time when a node has verified the path. > > > > "stateless" does also capture large part of this (i.e. reflector side).= If we > focus on the naming based on the reflector side, then "stateless" is > probably a better choice. If we focus the naming based on the initiator s= ide, > then "seamless" does the job better. > > > > As far as the charter text is concerned, I have no objection to replaci= ng the > word "seamless" with something else, if anyone wants to propose a text. >=20 > And this is most of my point for charter discussion purposes. If the wor= d is > intended to mostly be an empty marketing word, let's not do that. It onl= y > confuses technical specifications. :-) >=20 > To my mind, the "fast" property you're looking for isn't a seam since it'= s part > of how the protocol works today. Seams are where you have several things > butting together that require interfacing. In this case, it's all of the= same > components, just optimizing some of the cases. >=20 > -- Jeff From nobody Mon Apr 28 13:18:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392D81A6F54 for ; Mon, 28 Apr 2014 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WA45QZ_xRPC for ; Mon, 28 Apr 2014 13:18:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 51D2B1A064C for ; Mon, 28 Apr 2014 13:18:04 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-c6-535e667ae88a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 34.EC.02831.A766E535; Mon, 28 Apr 2014 16:32:26 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 16:18:00 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Jeffrey Haas Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOREfAAAIU3YAAACEnwAAAaPqAAAAk6yAAAZUjcA= Date: Mon, 28 Apr 2014 20:17:59 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7A6D8D@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7A6D8Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZXLrHW7cqLS7Y4NpsI4tP73awWOw/+JbV YnZHvMXnP9sYHVg8pvzeyOqxZMlPJo/LvVtZA5ijuGxSUnMyy1KL9O0SuDK+nt/HWtDqVDFj o2QD4z+zLkZODgkBE4nzM68xQ9hiEhfurWfrYuTiEBI4yiix/eBTRghnOaPE+lXtTCBVbAJG Ei829rCD2CIC7hJbTvxhBLGZBeIlzh5/D9TNwSEsUCzxcxVUSYnEwc07GCHsJInp7w6CLWMR UJVYuvMFI0g5r4CvxNXNIRCrDjBL7G7ZzQZSwwkUX7v6MQuIzQh03PdTa5ggVolL3Hoynwni aAGJJXvOQz0gKvHy8T9WCFtRYl//dHaI+nyJk1uXg9XzCghKnJz5hGUCo+gsJKNmISmbhaQM Iq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLcxAiMt2MSbI47GBd8sjzE KMDBqMTDO31xZLAQa2JZcWXuIUZpDhYlcd70T7HBQgLpiSWp2ampBalF8UWlOanFhxiZODil Ghg3TFKKeXPRsfHu61W9W9/skvh6UPe2sNXqjTaBdxhalReZNjW5tq7dmbmjSGxdoILRNFsN q++supNedfHUz5yk2np62UHW9FUphR1ffRvi38bapi6btjd0+hKXKKlzB6aLu2RdOL583geh iTNc14jO70yct1h7xxWvmfpfhRTn8kt+rVw9+32BEktxRqKhFnNRcSIAZL7HhpgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IcYaR3HbkbuQNndxb_r-ctuy2lM Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:18:07 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7A6D8Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, Jeff, et. al, I agree that Reflector in S-BFD is stateless but I'm not sure if "stateless= " can be equally applied to characterization of an S-BFD Sender. Perhaps "S= " in S-BFD can stand for "single-ended"? I think that it is important to stress in the charter update that: * S-BFD enables continuity check/verification/monitoring, i.e. availa= bility of the path, and is not intended to support connectivity verificatio= n; * multiple session can be maintained not only to the same target enti= ty, i.e. Your Discriminator, but between the same pair of network entities,= i.e. IP addresses. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Monday, April 28, 2014 12:05 PM To: Jeffrey Haas Cc: Carlos Pignataro (cpignata); rtg-bfd@ietf.org Subject: RE: BFD charter update proposal [was: RE: Working Group adoption f= or Seamless BFD (requires re-charter)] Hi Jeff, Ok :) Here's Attempt #3: Define a mechanism to perform single-ended path (ex: continuity) verificati= on based on the BFD specification; allow such mechanism to work both proact= ively and on-demand, without prominent initial delay; allow the mechanism t= o maintain multiple sessions to a target entity. In doing this work, the WG= will work closely with at least the following other WGs: ISIS, OSPF, SPRIN= G. -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Monday, April 28, 2014 2:49 PM > To: Nobo Akiya (nobo) > Cc: Marc Binderberger; Jeffrey Haas; rtg-bfd@ietf.org; Carlos > Pignataro > (cpignata) > Subject: Re: BFD charter update proposal [was: RE: Working Group > adoption for Seamless BFD (requires re-charter)] > > Nobo, > > On Mon, Apr 28, 2014 at 06:01:44PM +0000, Nobo Akiya (nobo) wrote: > > In any case, "seamless" is primary intended to describe: > > - No bootstrapping > > - No session up negotiation > > > > Meaning "seam" is the time when a node wants to verify a path to the > time when a node has verified the path. > > > > "stateless" does also capture large part of this (i.e. reflector > > side). If we > focus on the naming based on the reflector side, then "stateless" is > probably a better choice. If we focus the naming based on the > initiator side, then "seamless" does the job better. > > > > As far as the charter text is concerned, I have no objection to > > replacing the > word "seamless" with something else, if anyone wants to propose a text. > > And this is most of my point for charter discussion purposes. If the > word is intended to mostly be an empty marketing word, let's not do > that. It only confuses technical specifications. :-) > > To my mind, the "fast" property you're looking for isn't a seam since > it's part of how the protocol works today. Seams are where you have > several things butting together that require interfacing. In this > case, it's all of the same components, just optimizing some of the cases. > > -- Jeff --_000_7347100B5761DC41A166AC17F22DF1121B7A6D8Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Nobo, Jeff, et. al,
I agree that Reflector in S-BFD is stateless but I'm not sure if "= ;stateless" can be equally applied to characterization of an S-BFD Sen= der. Perhaps "S" in S-BFD can stand for "single-ended"?=
I think that it is important to stress in the charter update that:
  • S-BFD enables continuity check/verification/monitoring, i.e. availabili= ty of the path, and is not intended to support connectivity verification;
  • multiple session can be maintained not only to the same target entit= y, i.e. Your Discriminator, but between the same pair of network entities, = i.e. IP addresses.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
Sent: Monday, April 28, 2014 12:05 PM
To: Jeffrey Haas
Cc: Carlos Pignataro (cpignata); rtg-bfd@ietf.org
Subject: RE: BFD charter update proposal [was: RE: Working Group adoption f= or Seamless BFD (requires re-charter)]
 
Hi Jeff,
 
Ok :)
 
Here's Attempt #3:
 
Define a mechanism to perform single-ended path (ex: continuity) verif= ication based on the BFD specification; allow such mechanism to work both p= roactively and on-demand, without prominent initial delay; allow the mechan= ism to maintain multiple sessions to a target entity. In doing this work, the WG will work closely with at le= ast the following other WGs: ISIS, OSPF, SPRING.
 
-Nobo
 
> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaa= s@pfrc.org]
> Sent: Monday, April 28, 2014 2:49 PM
> To: Nobo Akiya (nobo)
> Cc: Marc Binderberger; Jeffrey Haas; rtg-bfd@ietf.org; Carlos
> Pignataro
> (cpignata)
> Subject: Re: BFD charter update proposal [was: RE: Working Group =
> adoption for Seamless BFD (requires re-charter)]
>
> Nobo,
>
> On Mon, Apr 28, 2014 at 06:01:44PM +0000, Nobo Akiya (nobo) w= rote:
> > In any case, "seamless" is primary intended to des= cribe:
> > - No bootstrapping
> > - No session up negotiation
> >
> > Meaning "seam" is the time when a node wants to ve= rify a path to the
> time when a node has verified the path.
> >
> > "stateless" does also capture large part of this (= i.e. reflector
> > side). If we
> focus on the naming based on the reflector side, then "state= less" is
> probably a better choice. If we focus the naming based on the
> initiator side, then "seamless" does the job better.
> >
> > As far as the charter text is concerned, I have no objection= to
> > replacing the
> word "seamless" with something else, if anyone wants to= propose a text.
>
> And this is most of my point for charter discussion purposes.&nbs= p; If the
> word is intended to mostly be an empty marketing word, let's not = do
> that.  It only confuses technical specifications. :-)
>
> To my mind, the "fast" property you're looking for isn'= t a seam since
> it's part of how the protocol works today.  Seams are where = you have
> several things butting together that require interfacing.  I= n this
> case, it's all of the same components, just optimizing some of th= e cases.
>
> -- Jeff
 
 
 --_000_7347100B5761DC41A166AC17F22DF1121B7A6D8Deusaamb103erics_-- From nobody Mon Apr 28 13:22:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A171A7D84 for ; Mon, 28 Apr 2014 13:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51ZSeoGa_xDw for ; Mon, 28 Apr 2014 13:22:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 92FEA1A7D83 for ; Mon, 28 Apr 2014 13:22:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C8144C12C; Mon, 28 Apr 2014 16:22:20 -0400 (EDT) Date: Mon, 28 Apr 2014 16:22:20 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Message-ID: <20140428202220.GL1256@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> <7347100B5761DC41A166AC17F22DF1121B7A6D8D@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7A6D8D@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/u4kyorMa2VbaQ2Iu0lY1ncGi1kk Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:22:23 -0000 [I'm not helping. :-)] On Mon, Apr 28, 2014 at 08:17:59PM +0000, Gregory Mirsky wrote: > I agree that Reflector in S-BFD is stateless but I'm not sure if "stateless" can be equally applied to characterization of an S-BFD Sender. Perhaps "S" in S-BFD can stand for "single-ended"? For any of the proposals that intend to use "single" to describe this, please think through trying to explain "single... bi-directional forwarding detection" to our English as a (possibly distant) second language participants. -- Jeff (I already have the fun of explaining that the Daves had a sense of humor with regard to the "B.F.D." acronym in the first place...) From nobody Mon Apr 28 13:30:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE191A6FEB for ; Mon, 28 Apr 2014 13:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TUqowzmnDnl for ; Mon, 28 Apr 2014 13:30:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A5AB71A6FA8 for ; Mon, 28 Apr 2014 13:30:51 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-3d-535e697a2333 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 26.BD.02831.A796E535; Mon, 28 Apr 2014 16:45:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 16:30:50 -0400 From: Gregory Mirsky To: Jeffrey Haas Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOREfAAAIU3YAAACEnwAAAaPqAAAAk6yAAAZUjcD//+LnAIAAQiTw Date: Mon, 28 Apr 2014 20:30:49 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7A6DF0@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> <7347100B5761DC41A166AC17F22DF1121B7A6D8D@eusaamb103.ericsson.se> <20140428202220.GL1256@pfrc> In-Reply-To: <20140428202220.GL1256@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPrG51ZlywQfdqZotP73awWOw/+JbV YnZHvMXnP9sYHVg8pvzeyOqxZMlPJo/LvVtZA5ijuGxSUnMyy1KL9O0SuDKmz7/JXDCPs+Lu +z+MDYwH2LsYOTkkBEwkpi2YxARhi0lcuLeeDcQWEjjKKNHbL9rFyAVkL2eU+N90hwUkwSZg JPFiYw9Ys4iAosT8/51sIEXMAq2MEjf2LAMq4uAQFiiW+LkKqqZE4uDmHYwQdp7EpU3LGEFK WARUJV7ulgIJ8wr4Spw52sgKsWsxi0Tb5J1gR3AKaEo8XHQIrJcR6Ljvp9aAHcosIC5x68l8 qKMFJJbsOc8MYYtKvHz8jxXCVpTY1z+dHaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo9gs JGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw3MQIj6JgEm+MOxgWfLA8xCnAwKvHwTl8cGSzE mlhWXJl7iFGag0VJnDf9U2ywkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZ8uVdPjNbZXmTk PHVXnzHlJB/fzbe7Cr60z47i8yv0ErOs6rE/pXw9d0b3lRuhwl/EvpXOz568com6sKjXA2lb STnjD9cvujaoXokzVfy6n2dZeO6vK0ekgzNzFP24cvrapr/i2Mq25mvSrctPj3CYLDjG0GI0 fYvZ9w+T1669/telTXV/DLsSS3FGoqEWc1FxIgC3rQW8gQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UdWdt1PQGoNqbBLXZgDTvqr8JbU Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:30:53 -0000 Hi Jeff, et. al, frankly I was trying to save us from the nightmarish discussion of "single-= ended two-way" vs. "dual-ended one-way" OAM. Regards, Greg -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Monday, April 28, 2014 1:22 PM To: Gregory Mirsky Cc: Nobo Akiya (nobo); Jeffrey Haas; Carlos Pignataro (cpignata); rtg-bfd@i= etf.org Subject: Re: BFD charter update proposal [was: RE: Working Group adoption f= or Seamless BFD (requires re-charter)] [I'm not helping. :-)] On Mon, Apr 28, 2014 at 08:17:59PM +0000, Gregory Mirsky wrote: > I agree that Reflector in S-BFD is stateless but I'm not sure if "statele= ss" can be equally applied to characterization of an S-BFD Sender. Perhaps = "S" in S-BFD can stand for "single-ended"? For any of the proposals that intend to use "single" to describe this, plea= se think through trying to explain "single... bi-directional forwarding det= ection" to our English as a (possibly distant) second language participants= . -- Jeff (I already have the fun of explaining that the Daves had a sense of= humor with regard to the "B.F.D." acronym in the first place...) From nobody Mon Apr 28 14:58:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B51A8842 for ; Mon, 28 Apr 2014 14:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFA6leAuG4oA for ; Mon, 28 Apr 2014 14:58:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDBB1A6FB7 for ; Mon, 28 Apr 2014 14:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1155; q=dns/txt; s=iport; t=1398722284; x=1399931884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8jRVprCowdO+GhPMy2NlakqjO+s6lPDz9jh7yl6G0H8=; b=JcE386UJkrGERgHU9TY+ezH2pBNRoHaDOKq9wZ7j6wLe0MF6uOntxBvw iAkxuUOGF3rjMs2whJ8ptSMWe+Jt5LHngRouNsq6s/WZ8SuL7xmXwjiMx 7RCPWDElKGG7jv6UxrRycodw44NfAQqDmIVh8OS+pAsCwcqYyIw/HSJX6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKvOXlOtJA2L/2dsb2JhbABZgwaBJsRqgRsWdIIlAQEBBDo/EAIBCA4KHgULMiUCBA4FiEHIcBeOJjMHgySBFQEDmQySXoFygT+CKw X-IronPort-AV: E=Sophos;i="4.97,946,1389744000"; d="scan'208";a="39472559" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 28 Apr 2014 21:58:01 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3SLw1Ke014457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 21:58:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 16:58:01 -0500 From: "Carlos Pignataro (cpignata)" To: Jeff Haas Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOymQAAAIU3YAAApkkDD//74fAIAAUjDw///GwoCAAAE3AIAAGrqA Date: Mon, 28 Apr 2014 21:58:00 +0000 Message-ID: <3F0CCD0B-5E6F-4ECA-9465-54095505B2CE@cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> <7347100B5761DC41A166AC17F22DF1121B7A6D8D@eusaamb103.ericsson.se> <20140428202220.GL1256@pfrc> In-Reply-To: <20140428202220.GL1256@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.253.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <248891A335731F4AA5E7868EA1B03D9B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VGS1dnLty1_3l3W_R2WbAe9Uj7o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:58:10 -0000 On Apr 28, 2014, at 4:22 PM, Jeffrey Haas wrote: > [I'm not helping. :-)] >=20 > On Mon, Apr 28, 2014 at 08:17:59PM +0000, Gregory Mirsky wrote: >> I agree that Reflector in S-BFD is stateless but I'm not sure if "statel= ess" can be equally applied to characterization of an S-BFD Sender. Perhaps= "S" in S-BFD can stand for "single-ended"? >=20 > For any of the proposals that intend to use "single" to describe this, > please think through trying to explain "single... bi-directional forwardi= ng > detection" to our English as a (possibly distant) second language > participants. For oxymorons, we already have Bidirectional FD for Unidirectional links [R= FC5883] and (unidirectional) LSPs [RFC5884] :-) That said, I agree that 'si= ngle' or 'one-side' do not maximize clarity.=20 "Stateless BFD Reflection"? Simply "S-BFD" with expansion of the acronym le= ft as an exercise for the brave reader? Carlos, English as a 3rd language participant. >=20 > -- Jeff (I already have the fun of explaining that the Daves had a sense = of > humor with regard to the "B.F.D." acronym in the first place...) From nobody Mon Apr 28 19:22:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2971A887E for ; Mon, 28 Apr 2014 19:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBV6L8eFOuec for ; Mon, 28 Apr 2014 19:22:36 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 176F41A885E for ; Mon, 28 Apr 2014 19:22:36 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 1ACC82AA0F; Tue, 29 Apr 2014 02:22:32 +0000 (GMT) Date: Mon, 28 Apr 2014 19:22:32 -0700 From: Marc Binderberger To: Carlos Pignataro (cpignata) , Nobo Akiya (nobo) Message-ID: <20140428192232664848.b0193c70@sniff.de> In-Reply-To: <3F0CCD0B-5E6F-4ECA-9465-54095505B2CE@cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> <7347100B5761DC41A166AC17F22DF1121B7A6D8D@eusaamb103.ericsson.se> <20140428202220.GL1256@pfrc> <3F0CCD0B-5E6F-4ECA-9465-54095505B2CE@cisco.com> Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lAeBCz2CmyfGd9DD0FWHE8j3qvw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 02:22:39 -0000 the "Asymmetric" BFD is actually not bad. Or shall I say "aSymmetric". Anyway, Nobo's last proposal was: Define a mechanism to perform single-ended path (ex: continuity) verification based on the BFD specification; allow such mechanism to work both proactively and on-demand, without prominent initial delay; allow the mechanism to maintain multiple sessions to a target entity. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. Would it be a problem to be more specific? E.g.: Define a mechanism to perform path (ex: continuity) verification based on the BFD specification, with only one side holding all state and a stateless reflector as the peer. Allow such mechanism ... Regards, Marc On Mon, 28 Apr 2014 21:58:00 +0000, Carlos Pignataro (cpignata) wrote: > > On Apr 28, 2014, at 4:22 PM, Jeffrey Haas wrote: > >> [I'm not helping. :-)] >> >> On Mon, Apr 28, 2014 at 08:17:59PM +0000, Gregory Mirsky wrote: >>> I agree that Reflector in S-BFD is stateless but I'm not sure if >>> "stateless" can be equally applied to characterization of an S-BFD >>> Sender. Perhaps "S" in S-BFD can stand for "single-ended"? >> >> For any of the proposals that intend to use "single" to describe this, >> please think through trying to explain "single... bi-directional forwarding >> detection" to our English as a (possibly distant) second language >> participants. > > For oxymorons, we already have Bidirectional FD for Unidirectional links > [RFC5883] and (unidirectional) LSPs [RFC5884] :-) That said, I agree that > 'single' or 'one-side' do not maximize clarity. > > "Stateless BFD Reflection"? Simply "S-BFD" with expansion of the acronym > left as an exercise for the brave reader? > > Carlos, English as a 3rd language participant. > >> >> -- Jeff (I already have the fun of explaining that the Daves had a sense of >> humor with regard to the "B.F.D." acronym in the first place...) > From nobody Mon Apr 28 21:39:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4711A08AD for ; Mon, 28 Apr 2014 21:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTJL_LHKWucQ for ; Mon, 28 Apr 2014 21:38:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 08BF91A084A for ; Mon, 28 Apr 2014 21:38:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGE90427; Tue, 29 Apr 2014 04:38:53 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Apr 2014 05:37:57 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Apr 2014 05:38:52 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.77]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0158.001; Tue, 29 Apr 2014 12:38:49 +0800 From: Tina TSOU To: Marc Binderberger Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAH+vSAAAIU3YAAACEnwAAAaPqAAAAk6uAAAKKloAAACblAAADV1MAAAk9HQAAFYXn6A== Date: Tue, 29 Apr 2014 04:38:48 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> <7347100B5761DC41A166AC17F22DF1121B7A6D8D@eusaamb103.ericsson.se> <20140428202220.GL1256@pfrc> <3F0CCD0B-5E6F-4ECA-9465-54095505B2CE@cisco.com>, <20140428192232664848.b0193c70@sniff.de> In-Reply-To: <20140428192232664848.b0193c70@sniff.de> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Mi6QZoSXgi_7xLzRwQAl3N6KY-c Cc: Carlos Pignataro , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 04:39:00 -0000 Dear all, Softwire WG may be among the list of other WGs we should work with. See Nobo's discussion on draft-tsou-softwire-bfd-ds-lite in Softwire mailin= g list. Thank you, Tina > On Apr 29, 2014, at 10:22 AM, "Marc Binderberger" wrote: >=20 >=20 > the "Asymmetric" BFD is actually not bad. Or shall I say "aSymmetric".=20 > Anyway, Nobo's last proposal was: >=20 > Define a mechanism to perform single-ended path (ex: continuity) verifica= tion=20 > based on the BFD specification; allow such mechanism to work both proacti= vely=20 > and on-demand, without prominent initial delay; allow the mechanism to=20 > maintain multiple sessions to a target entity. In doing this work, the WG= =20 > will work closely with at least the following other WGs: ISIS, OSPF, SPRI= NG. >=20 >=20 > Would it be a problem to be more specific? E.g.: >=20 > Define a mechanism to perform path (ex: continuity) verification based on= the=20 > BFD specification, with only one side holding all state and a stateless=20 > reflector as the peer. Allow such mechanism ... >=20 >=20 > Regards, Marc >=20 >=20 >=20 >>> On Mon, 28 Apr 2014 21:58:00 +0000, Carlos Pignataro (cpignata) wrote: >>>=20 >>> On Apr 28, 2014, at 4:22 PM, Jeffrey Haas wrote: >>>=20 >>> [I'm not helping. :-)] >>>=20 >>>> On Mon, Apr 28, 2014 at 08:17:59PM +0000, Gregory Mirsky wrote: >>>> I agree that Reflector in S-BFD is stateless but I'm not sure if=20 >>>> "stateless" can be equally applied to characterization of an S-BFD=20 >>>> Sender. Perhaps "S" in S-BFD can stand for "single-ended"? >>>=20 >>> For any of the proposals that intend to use "single" to describe this, >>> please think through trying to explain "single... bi-directional forwar= ding >>> detection" to our English as a (possibly distant) second language >>> participants. >>=20 >> For oxymorons, we already have Bidirectional FD for Unidirectional links= =20 >> [RFC5883] and (unidirectional) LSPs [RFC5884] :-) That said, I agree tha= t=20 >> 'single' or 'one-side' do not maximize clarity.=20 >>=20 >> "Stateless BFD Reflection"? Simply "S-BFD" with expansion of the acronym= =20 >> left as an exercise for the brave reader? >>=20 >> Carlos, English as a 3rd language participant. >>=20 >>>=20 >>> -- Jeff (I already have the fun of explaining that the Daves had a sens= e of >>> humor with regard to the "B.F.D." acronym in the first place...) >=20 From nobody Mon Apr 28 21:48:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57731A08AD for ; Mon, 28 Apr 2014 21:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij_ty-iBcOu9 for ; Mon, 28 Apr 2014 21:48:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6161A08AF for ; Mon, 28 Apr 2014 21:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2156; q=dns/txt; s=iport; t=1398746920; x=1399956520; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=v0xqGktbfmthHG7OnI4r4AvVTFZn2+jonUUJavnT8wY=; b=AEtYiuJrv8S7V1fcYX7LK4jNgN0gRKNFnRxZo54aTGckxkyx2XusJ5Id xcMr8Csr6QSYMbODHWy5nb6iiljrdVn7dktUX4WFKnUq2bckS0jrRg/c8 Vfsq6QKVnWFZ29BY3fFMQ0NZDc8fOJkMvtWAy9FUFfNdHVObWbOoJNEF0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFANAuX1OtJV2b/2dsb2JhbABZgwaBJsR1gRoWdIIlAQEBBDo/DAQCAQgRBAEBAQoUBQQHMhQJCAEBBAENBQiIOckpF44eMQcGgx6BFQEDq26BcoE/gis X-IronPort-AV: E=Sophos;i="4.97,949,1389744000"; d="scan'208";a="321162624" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 29 Apr 2014 04:48:18 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3T4mHVZ020377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 04:48:17 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 23:48:17 -0500 From: "Les Ginsberg (ginsberg)" To: "Carlos Pignataro (cpignata)" , Jeff Haas Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOymQAAAJaKAAAAst9mA= Date: Tue, 29 Apr 2014 04:48:17 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> In-Reply-To: <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uUnfmteTm98nJNKJNF92E-qqPPk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 04:48:42 -0000 "Connectionless" (CL-BFD) works for me. (Now ducking my head...) Les > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos > Pignataro (cpignata) > Sent: Monday, April 28, 2014 11:18 AM > To: Jeff Haas > Cc: rtg-bfd@ietf.org > Subject: Re: BFD charter update proposal [was: RE: Working Group adoption > for Seamless BFD (requires re-charter)] >=20 > Hi Jeff, >=20 > On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: >=20 > > [Not specifically speaking as a chair here...] > > > > On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: > >> Here's consolidated charter text proposal. > >> > >> > >> Attempt #2 > >> > >> Define a mechanism to perform single-ended path (ex: continuity) > verification based on the BFD specification; allow such mechanism to > seamlessly work both proactively and on-demand; allow the mechanism to > maintain multiple sessions to a target entity. In doing this work, the WG= will > work closely with at least the following other WGs: ISIS, OSPF, SPRING. > > > > So... what exactly does seamless mean here? What seams were you > seeing that > > you were trying to remove? > > > > FWIW, I think the charter discussion is moving along well, but I've nev= er > > quite groked the context for "seamless" for the proposal. "Stateless" = BFD, > > I can see quite well. > > >=20 > Like others have said, we had some renaming discussions. Now it would be > a good time to converge. Some of the (not perfect, but perfect is the ene= my > of good and progress here) more technical qualifiers are "Stateless", > "Reflector", "Responder", "Mesh Group", "Asymmetric". These focus on the > behavior of the responder mostly. Descriptive ones are also possible like > "Easy", "Simple", "Seamless", etc. >=20 > Frankly I am not concerned about which name -- other than we should be > consistent. >=20 > Net-net: I support your proposal of "Stateless" and a > %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What do > others think? >=20 > Thanks, >=20 > Carlos. >=20 > > -- Jeff From nobody Mon Apr 28 21:49:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C2C1A8840 for ; Mon, 28 Apr 2014 21:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9l_72mRjEHC for ; Mon, 28 Apr 2014 21:48:56 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8430C1A08AD for ; Mon, 28 Apr 2014 21:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9255; q=dns/txt; s=iport; t=1398746935; x=1399956535; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TumAR3YBVAj6v9oIhzEMnSa2zibUun1ZVWH3b49It3E=; b=fB//fLqvx6ERE5hqN5YhJdub6xksDJ/LCdUH5zVLhYTNoKtm/CNNawyi 7gBCq5KNGz7HdZBE1TIUKhg7Iuk1XYVA2glhoR9OaIBSXnkNJ/Ba2V+/H YzZshlD0UNwg3zFM3vdl9jJfuAeYuX7NmKY0cUMQsdZW+aFEGxuQi0XW3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAJcuX1OtJV2Z/2dsb2JhbABZgkJET1fEdYEaFnSCJQEBAQQtShICAQgRBAEBCx0HMhQJCAIEARIIiDnJKReOHjcBgySBFQSNG5NOiwWDMYIr X-IronPort-AV: E=Sophos; i="4.97,949,1389744000"; d="scan'208,217"; a="39564952" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 29 Apr 2014 04:48:55 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3T4mtJs026041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Apr 2014 04:48:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 23:48:53 -0500 From: "Les Ginsberg (ginsberg)" To: "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Topic: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Index: AQHPWjuSIo9hc5e0sES09J7I8hmrpZsoFESw Date: Tue, 29 Apr 2014 04:48:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.87] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F23D79710xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Z8SpbxbGrfPDICQXTIJQce6xJDU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 04:48:59 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F23D79710xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 2 says "Each protocol instance (e.g. OSPF/IS-IS) allocates one or more BFD discriminators on its network node..." I don't see the BFD clients as the "allocators". BFD owns its discriminator= space and will therefore have to do the allocation. Further, there are cer= tainly use cases where there is no need for a "per client discriminator" - = so the suggestion that "each protocol instance" has to have a unique discri= minator isn't accurate. I understand that in some cases a protocol identifier (e.g. router-id) migh= t be used either as the public discriminator or as a seed for the public di= scriminator - but that is not at all the same thing as acting as the alloca= tor. I also understand IGPs may be used to advertise the public discriminat= ors - but again this is not "allocating". I think all mention of BFD clients should be removed from this section and = you should simply say "BFD on a network node allocates ..." Les From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Thursday, April 17, 2014 5:50 AM To: rtg-bfd@ietf.org Subject: New version notification for draft-akiya-bfd-seamless-base-03.txt Hello BFD WG Members, We have published a new version of Seamless BFD draft, draft-akiya-bfd-seam= less-base-03. Several sections have been updated for improving readability.= It also has a few technical changes as well. Please review the draft and g= et back to us with your comments. Thanks Regards Mallik --_000_F3ADE4747C9E124B89F0ED2180CC814F23D79710xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 2 says=

 <= /p>

“Each protocol inst= ance (e.g. OSPF/IS-IS) allocates one or more BFD

   discriminato= rs on its network node…”

 <= /p>

I don’t see the BFD= clients as the “allocators”. BFD owns its discriminator space = and will therefore have to do the allocation. Further, there are certainly use cases where there is no need for a “per client discriminatorR= 21; – so the suggestion that “each protocol instance” has= to have a unique discriminator isn’t accurate.

 <= /p>

I understand that in some= cases a protocol identifier (e.g. router-id) might be used either as the p= ublic discriminator or as a seed for the public discriminator – but that is not at all the same thing as acting as the allocator. = I also understand IGPs may be used to advertise the public discriminators &= #8211; but again this is not “allocating”.

 <= /p>

I think all mention of BF= D clients should be removed from this section and you should simply say = 220;BFD on a network node allocates …”

 <= /p>

   Les

 <= /p>

 <= /p>

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Thursday, April 17, 2014 5:50 AM
To: rtg-bfd@ietf.org
Subject: New version notification for draft-akiya-bfd-seamless-base-= 03.txt

 

Hello BFD WG Members,

 

We have published a new versi= on of Seamless BFD draft, draft-akiya-bfd-seamless-base-03. Several section= s have been updated for improving readability. It also has a few technical changes as well. Please review the draft and get back to u= s with your comments.

 

Thanks

 

Regards

Mallik

--_000_F3ADE4747C9E124B89F0ED2180CC814F23D79710xmbalnx02ciscoc_-- From nobody Mon Apr 28 23:00:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEEA1A8876; Mon, 28 Apr 2014 23:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGSTr96EXk8U; Mon, 28 Apr 2014 23:00:31 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 269D91A883C; Mon, 28 Apr 2014 23:00:30 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3T60QPg008071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 02:00:28 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s3T60QPg008071 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1398751228; bh=cAqupTYVpHhHWClD9b5xnOOQOIg=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=W7VZGD6Y738hFaqZHi2lCPSt5KAMLiXZbmpNiC3fCpDcHq3Z/ZNbOwzPQSLeYq7Hb i8XXPQKDVZdiaaP7MAa/vZIifhaYbOoyPoDq9Ge6XzNZMnx9UWEXWjql1YImBSMn0H V7wncUiOuUCSKdGO6fxYDcEuegqm7BI7WQ9av73E= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s3T60QPg008071 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Tue, 29 Apr 2014 02:00:14 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3T60C17030349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 02:00:13 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Tue, 29 Apr 2014 02:00:12 -0400 From: "Black, David" To: "Nobo Akiya (nobo)" , "tnadeau@lucidvision.com" , "Zafar Ali (zali)" , "General Area Review Team (gen-art@ietf.org)" Date: Tue, 29 Apr 2014 02:00:05 -0400 Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Index: Ac9i7PyERuk5jZsyQOKSHRHy2Ij/LwAG2CxAABnaMYA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C437EA9@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C437CE3@MX15A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/rtOC-szmWD5kciMTsYV9bIqvtZw Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" , "Black, David" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 06:00:38 -0000 Hi Nobo, With respect to the MIB, this concern is a nit, so I'm ok with going ahead = without making this change ... ... However ... Your WG chairs and AD should be concerned that this significant flaw in BFD version 0 (justifying a "SHOULD NOT use" recommendation) is undocumente= d. Thanks, --David > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Monday, April 28, 2014 1:46 PM > To: Black, David; tnadeau@lucidvision.com; Zafar Ali (zali); General Area > Review Team (gen-art@ietf.org) > Cc: rtg-bfd@ietf.org; ietf@ietf.org > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 >=20 > Hi David, >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Monday, April 28, 2014 10:20 AM > > To: tnadeau@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); Gener= al > > Area Review Team (gen-art@ietf.org) > > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 > > > > The -18 version of this draft responds to all of the comments in the Ge= n-ART > > review of -17, including the request for coordination w/the OPS area, > > although I wasn't exactly expecting that to occur on the main IETF list= . >=20 > Thanks, they were very good comments. >=20 > > > > The -18 version is ready with one small nit - The following text has be= en > > added to the introduction: > > > > This memo does not define a compliance requirement for a system that > > > > only implements BFD version 0. This is a reflection of a considered > > and deliberate decision by the BFD WG. > > > > An explanation of the rationale for that decision would help - I sugges= t > > adding the following text and a suitable reference to the end of the te= xt > > above: > > > > because the BFD version 0 protocol may deadlock and hence SHOULD NOT > > be used, as explained further in [RFCxxxx]. >=20 > Unfortunately the problem with BFD version 0 is not documented in any RFC= s, > and MIB is probably not the right place to start this documentation eithe= r. If > this should be documented in a RFC, possibly a new info document or raise > errata on RFC5880 ... I'm not sure what would be a reasonable/recommended= path > here. In any case, my vote for the MIB document(s) is to keep the current= text > to proceed. Would that be ok with you? >=20 > -Nobo >=20 > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Black, David > > > Sent: Wednesday, April 16, 2014 7:31 PM > > > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General > > > Area Review Team (gen-art@ietf.org) > > > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > > > Subject: Gen-ART review of draft-ietf-bfd-mib-17 > > > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > > Gen-ART, please see the FAQ at > > > > > > . > > > > > > Please resolve these comments along with any other Last Call comments > > > you may receive. > > > > > > Document: draft-ietf-bfd-mib-17 > > > Reviewer: David L. Black > > > Review Date: April 16, 2014 > > > IETF LC End Date: April 28, 2014 > > > > > > Summary: This draft is on the right track, but has open issues > > > described in the review. > > > > > > This draft is a MIB module for the BFD protocol, which is an importan= t > > > low- level routing protocol. The draft is reasonable for a MIB draft= ; > > > one needs to go read the protocol documents to understand how the > > > protocol works, and significant portions of the text are derived from= the > > usual MIB "boilerplate" > > > as one would expect. The "Brief Description of MIB Objects" is indee= d > > > brief, but reasonable. The shepherd writeup indicates that there are > > > multiple implementations. > > > > > > Major issues: > > > > > > This MIB contains many writable objects, so the authors should take > > > note of the IESG statement on writable MIB modules: > > > > > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > > > > > I did not see this mentioned in the shepherd writeup. If the OPS Are= a > > > has not been consulted, I strongly suggest doing so during IETF Last > > > Call, e.g., starting with Benoit Claise (AD). > > > > > > Minor issues: > > > > > > The security considerations section includes considerations for > > > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus= , > > > but omits the corresponding considerations for bfdAdminStatus and > > > bfdSessNotificationsEnable. Both of the latter objects are global, s= o > > > significant damage can be inflicted via these objects with a small > > > number of unauthorized modifications, so they need to be included in > > > the first list of sensitive objects. > > > > > > I suggest that the authors recheck the entire MIB to ensure that ever= y > > > object or table that should be included in the security consideration= s > > > section is appropriately included. > > > > > > Also, as a General Variable, would bfdSessNotificationsEnable be > > > better named bfdNotificationsEnable, as it's not in the BFD Session T= able? > > > > > > I did not see a compliance requirement for a system that only > > > implements BFD protocol version 0. That absence should at least be > > > mentioned somewhere. For example, if this reflects a considered and > > > deliberate decision by the WG, that should be mentioned in the > > > introduction. > > > > > > Nits/editorial comments: > > > > > > In the security considerations for authentication-related objects: > > > > > > OLD > > > In order for these sensitive information > > > from being improperly accessed, implementers MAY wish to disallow > > > access to these objects. > > > NEW > > > In order to prevent this sensitive information > > > from being improperly accessed, implementers MAY disallow > > > access to these objects. > > > > > > idnits 2.13.01 found a truly minor nit that should be corrected when > > > the draft is next revised: > > > > > > =3D=3D Outdated reference: A later version (-05) exists of > > > draft-ietf-bfd-tc-mib-04 > > > > > > it also generated a warning that probably does not reflect an actual > > problem: > > > > > > -- The document seems to lack a disclaimer for pre-RFC5378 work, bu= t > > may > > > have content which was first submitted before 10 November 2008. = If > > you > > > have contacted all the original authors and they are all willing= to > grant > > > the BCP78 rights to the IETF Trust, then this is fine, and you c= an > ignore > > > this comment. If not, you may need to add the pre-RFC5378 > disclaimer. > > > (See the Legal Provisions document at > > > http://trustee.ietf.org/license-info for more information.) > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.= , > > > Hopkinton, MA=A0 01748 > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 2= 93-7786 > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- >=20 From nobody Mon Apr 28 23:16:37 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC891A86DE for ; Mon, 28 Apr 2014 23:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FJT-ugdGdDF for ; Mon, 28 Apr 2014 23:16:34 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 838721A884F for ; Mon, 28 Apr 2014 23:16:34 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so6783235pbc.1 for ; Mon, 28 Apr 2014 23:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yqT3U5KbxnV+yAExeCoaiP8OMfmh0Bp+u+ZnZXD7dE4=; b=RIVbrYGKR4X9zYce3HZEEZ94spcbAXh98dL9fsEAgUkgISCyCNcJ/IlBBa/Pr9B7oG 0ckeBmhFk7dqpCp0BC06ty5tt50o6z4mHwWuPLFXsiZdE32VQAchNDP/SeSrioVK9soK eZqfZCOvOcAEmFp4saTKZU6Cy2QOF+v7TOJUTE+BH1Vd7XaazL2fJA1IBpdHZp+gYy0G zRGmSdHkc1hhDlOcVBRFVIElgJVNVNVS9g/5HK1vnWTQ3hqVS20GeWwzFu0bcEfpZfIe 13FX8HeOzONXoTbMVvfwCkDvexQJN+wxVM0jjTYICdEaWuyXX7E0P17f145ZW74PbAiU hxQg== X-Received: by 10.68.99.194 with SMTP id es2mr34071181pbb.100.1398752193652; Mon, 28 Apr 2014 23:16:33 -0700 (PDT) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id tu3sm103917872pab.1.2014.04.28.23.16.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 23:16:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] From: Sam Aldrin In-Reply-To: Date: Mon, 28 Apr 2014 23:16:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> To: "Les Ginsberg (ginsberg)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6mctoUmJpfXCY121gjsZ4zOhEwE Cc: Carlos Pignataro , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 06:16:35 -0000 connections less BFD checking connection failures :D Sorry couldn=92t resist. :D -sam On Apr 28, 2014, at 9:48 PM, Les Ginsberg (ginsberg) = wrote: > "Connectionless" (CL-BFD) works for me. >=20 > (Now ducking my head...) >=20 > Les >=20 >=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos >> Pignataro (cpignata) >> Sent: Monday, April 28, 2014 11:18 AM >> To: Jeff Haas >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD charter update proposal [was: RE: Working Group = adoption >> for Seamless BFD (requires re-charter)] >>=20 >> Hi Jeff, >>=20 >> On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: >>=20 >>> [Not specifically speaking as a chair here...] >>>=20 >>> On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: >>>> Here's consolidated charter text proposal. >>>>=20 >>>>=20 >>>> Attempt #2 >>>>=20 >>>> Define a mechanism to perform single-ended path (ex: continuity) >> verification based on the BFD specification; allow such mechanism to >> seamlessly work both proactively and on-demand; allow the mechanism = to >> maintain multiple sessions to a target entity. In doing this work, = the WG will >> work closely with at least the following other WGs: ISIS, OSPF, = SPRING. >>>=20 >>> So... what exactly does seamless mean here? What seams were you >> seeing that >>> you were trying to remove? >>>=20 >>> FWIW, I think the charter discussion is moving along well, but I've = never >>> quite groked the context for "seamless" for the proposal. = "Stateless" BFD, >>> I can see quite well. >>>=20 >>=20 >> Like others have said, we had some renaming discussions. Now it would = be >> a good time to converge. Some of the (not perfect, but perfect is the = enemy >> of good and progress here) more technical qualifiers are "Stateless", >> "Reflector", "Responder", "Mesh Group", "Asymmetric". These focus on = the >> behavior of the responder mostly. Descriptive ones are also possible = like >> "Easy", "Simple", "Seamless", etc. >>=20 >> Frankly I am not concerned about which name -- other than we should = be >> consistent. >>=20 >> Net-net: I support your proposal of "Stateless" and a >> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What = do >> others think? >>=20 >> Thanks, >>=20 >> Carlos. >>=20 >>> -- Jeff >=20 From nobody Tue Apr 29 00:05:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D661A8892 for ; Tue, 29 Apr 2014 00:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJD9hgAO0bw3 for ; Tue, 29 Apr 2014 00:05:36 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 888DB1A8887 for ; Tue, 29 Apr 2014 00:05:15 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-e9-535efe240cd2 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4E.BB.02831.42EFE535; Tue, 29 Apr 2014 03:19:32 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 29 Apr 2014 03:05:13 -0400 From: Gregory Mirsky To: Sam Aldrin , "Les Ginsberg (ginsberg)" Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOREfAAAJaMaAABYD6oAAAxTegAAGyerQ Date: Tue, 29 Apr 2014 07:05:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7A7164@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPlK7Kv7hgg6mXxC0mtH5htPj0bgeL xYY/G9ktPv/ZxujA4jHl90ZWj52z7rJ7LFnykymAOYrLJiU1J7MstUjfLoEro+HETbaCmeIV E1a0MjUwfhLqYuTkkBAwkVi16wQ7hC0mceHeerYuRi4OIYGjjBILZl1ghnCWM0pcnbSPEaSK TcBI4sXGHrAOEYEIiVOzbzGD2MwCQRILzrYydTFycAgLFEv8XAVVUiJxcPMORpCwiECUxMX7 oSBhFgFViXMz5zOB2LwCvhLtT2axQqyazSzx/PU3sF5OAVuJvz3vwcYzAh33/dQaJohV4hK3 nkA0SwgISCzZc54ZwhaVePn4HyuErSTx8fd8doh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJ jGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLcxAiMoWMSbI47GBd8sjzEKMDBqMTDO31x ZLAQa2JZcWXuIUZpDhYlcd70T7HBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhZAxfP3Lnl m438v/n5z90qJi+65zrXKV+TRzUj4h3j3zPioiWn91+ZY3x871arn/MnNhRP1qk2eRnEcOFj WJnS1Yjush3+EctVCjep+JjzykTtmCHsnbKOTyRZfdulaffnOwny1fDLzCqZs/W60oTuBadc NukKZJebifXUVVZOvW3/b1VilaYSS3FGoqEWc1FxIgC6aUZWggIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oMaq2s5wgZqAfh5_IncsLnzXcUc Cc: Carlos Pignataro , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 07:05:40 -0000 Verification/monitoring (on-demand/proactive) of path continuity in packet = switched connectionless network domain. Cheers, Greg PS. Resisted but not for too long :) -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Monday, April 28, 2014 11:17 PM To: Les Ginsberg (ginsberg) Cc: Carlos Pignataro; rtg-bfd@ietf.org Subject: Re: BFD charter update proposal [was: RE: Working Group adoption f= or Seamless BFD (requires re-charter)] connections less BFD checking connection failures :D Sorry couldn't resist.= :D -sam On Apr 28, 2014, at 9:48 PM, Les Ginsberg (ginsberg) w= rote: > "Connectionless" (CL-BFD) works for me. >=20 > (Now ducking my head...) >=20 > Les >=20 >=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos=20 >> Pignataro (cpignata) >> Sent: Monday, April 28, 2014 11:18 AM >> To: Jeff Haas >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD charter update proposal [was: RE: Working Group=20 >> adoption for Seamless BFD (requires re-charter)] >>=20 >> Hi Jeff, >>=20 >> On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: >>=20 >>> [Not specifically speaking as a chair here...] >>>=20 >>> On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: >>>> Here's consolidated charter text proposal. >>>>=20 >>>>=20 >>>> Attempt #2 >>>>=20 >>>> Define a mechanism to perform single-ended path (ex: continuity) >> verification based on the BFD specification; allow such mechanism to=20 >> seamlessly work both proactively and on-demand; allow the mechanism=20 >> to maintain multiple sessions to a target entity. In doing this work,=20 >> the WG will work closely with at least the following other WGs: ISIS, OS= PF, SPRING. >>>=20 >>> So... what exactly does seamless mean here? What seams were you >> seeing that >>> you were trying to remove? >>>=20 >>> FWIW, I think the charter discussion is moving along well, but I've=20 >>> never quite groked the context for "seamless" for the proposal. =20 >>> "Stateless" BFD, I can see quite well. >>>=20 >>=20 >> Like others have said, we had some renaming discussions. Now it would=20 >> be a good time to converge. Some of the (not perfect, but perfect is=20 >> the enemy of good and progress here) more technical qualifiers are=20 >> "Stateless", "Reflector", "Responder", "Mesh Group", "Asymmetric".=20 >> These focus on the behavior of the responder mostly. Descriptive ones=20 >> are also possible like "Easy", "Simple", "Seamless", etc. >>=20 >> Frankly I am not concerned about which name -- other than we should=20 >> be consistent. >>=20 >> Net-net: I support your proposal of "Stateless" and a=20 >> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What=20 >> do others think? >>=20 >> Thanks, >>=20 >> Carlos. >>=20 >>> -- Jeff >=20 From nobody Tue Apr 29 00:10:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949791A0155 for ; Tue, 29 Apr 2014 00:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHne-tNV4h6V for ; Tue, 29 Apr 2014 00:10:51 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1606A1A0123 for ; Tue, 29 Apr 2014 00:10:51 -0700 (PDT) Received: from [192.168.1.5] (unknown [112.208.110.53]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 038451800905 for ; Tue, 29 Apr 2014 09:10:48 +0200 (CEST) Message-ID: <535F5074.1060005@pi.nu> Date: Tue, 29 Apr 2014 09:10:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtg-bfd@ietf.org Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7A7164@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7A7164@eusaamb103.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2Hv_OolNqrN6UPHdvKnATi7dQ00 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 07:10:53 -0000 hmmm - "seamless" might not describe what we want or define very accurately, but at least it is short and catchy (the just add a few paragraphs to explain what we'll do). /Loa On 2014-04-29 09:05, Gregory Mirsky wrote: > Verification/monitoring (on-demand/proactive) of path continuity in packet switched connectionless network domain. > > Cheers, > Greg > > PS. Resisted but not for too long :) > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Monday, April 28, 2014 11:17 PM > To: Les Ginsberg (ginsberg) > Cc: Carlos Pignataro; rtg-bfd@ietf.org > Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] > > connections less BFD checking connection failures :D Sorry couldn't resist. :D > > -sam > > On Apr 28, 2014, at 9:48 PM, Les Ginsberg (ginsberg) wrote: > >> "Connectionless" (CL-BFD) works for me. >> >> (Now ducking my head...) >> >> Les >> >> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos >>> Pignataro (cpignata) >>> Sent: Monday, April 28, 2014 11:18 AM >>> To: Jeff Haas >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: BFD charter update proposal [was: RE: Working Group >>> adoption for Seamless BFD (requires re-charter)] >>> >>> Hi Jeff, >>> >>> On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: >>> >>>> [Not specifically speaking as a chair here...] >>>> >>>> On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: >>>>> Here's consolidated charter text proposal. >>>>> >>>>> >>>>> Attempt #2 >>>>> >>>>> Define a mechanism to perform single-ended path (ex: continuity) >>> verification based on the BFD specification; allow such mechanism to >>> seamlessly work both proactively and on-demand; allow the mechanism >>> to maintain multiple sessions to a target entity. In doing this work, >>> the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. >>>> >>>> So... what exactly does seamless mean here? What seams were you >>> seeing that >>>> you were trying to remove? >>>> >>>> FWIW, I think the charter discussion is moving along well, but I've >>>> never quite groked the context for "seamless" for the proposal. >>>> "Stateless" BFD, I can see quite well. >>>> >>> >>> Like others have said, we had some renaming discussions. Now it would >>> be a good time to converge. Some of the (not perfect, but perfect is >>> the enemy of good and progress here) more technical qualifiers are >>> "Stateless", "Reflector", "Responder", "Mesh Group", "Asymmetric". >>> These focus on the behavior of the responder mostly. Descriptive ones >>> are also possible like "Easy", "Simple", "Seamless", etc. >>> >>> Frankly I am not concerned about which name -- other than we should >>> be consistent. >>> >>> Net-net: I support your proposal of "Stateless" and a >>> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What >>> do others think? >>> >>> Thanks, >>> >>> Carlos. >>> >>>> -- Jeff >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 29 03:34:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901E01A081E for ; Tue, 29 Apr 2014 03:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32dpvqGEsdsl for ; Tue, 29 Apr 2014 03:34:39 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6741A0817 for ; Tue, 29 Apr 2014 03:34:39 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id gq1so1468obb.33 for ; Tue, 29 Apr 2014 03:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cFUHbQmqMgiiUbK0KoKSJpDc6NH9S2Im40P0+zdqV2g=; b=LXoi7lv33XWsXdABSUsnM7WKtyuQH+lhwWTA471/kgQu28d/BpKGGJVEk3mZD/TudZ NYen/wUZsTvjqItC4/JOWv+OBw9VjLFY4vhpBIwPXZ3tRSxqx5PP+kGbE+pCdiEnCvZO LtkZbOtSzICwJE7E3klVtE3PAntHq6EZMFwmpIf5tcwparzLUmeBnARtrxot0jqGbv2N sSyVawQar07lpGy5XhmYxN91M2pNnUYOsvEqbf5NqiH2Qrz4pwUVFyviftKzLAGuMbDk +xApvVzOXi+HgC7b8WY6voCkc+mRC6SJGwnOMUP7rnkZYgPVFvYNOrIip3KisrsMFnDf pG2w== MIME-Version: 1.0 X-Received: by 10.182.120.5 with SMTP id ky5mr26909787obb.11.1398767678438; Tue, 29 Apr 2014 03:34:38 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 29 Apr 2014 03:34:38 -0700 (PDT) In-Reply-To: <20140428184842.GG1256@pfrc> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <20140428104654386978.13c1089a@sniff.de> <20140428184842.GG1256@pfrc> Date: Tue, 29 Apr 2014 16:04:38 +0530 Message-ID: Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] From: Manav Bhatia To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VIPQ-cox7u00-JGqOUM-nHOv_ws Cc: "Carlos Pignataro \(cpignata\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 10:34:41 -0000 Jeff, > To my mind, the "fast" property you're looking for isn't a seam since it's > part of how the protocol works today. Seams are where you have several > things butting together that require interfacing. In this case, it's all of >From a different vantage point having to wait for the BFD protocol to finish its handshaking before it can do something thats useful (ensure/verify data plane connectivity) is a seam. You cant send traffic bursting down the tubes till BFD comes up and tells you that everything is ok. Now, when you eliminate this waiting period -- or drastically reduce it to the point where it becomes negligible you have removed that "seam" and thereby made it "Seamless". So my vote is for S-BFD where S could be Seamless, Super, Slick, Smart, or ... ! :-) I am not a big fan of Stateless since the clients (the nodes initiating the session) may not necessarily be stateless. However, i will not be lying down the train tracks in protest if this is what the WG tends towards. Cheers, Manav From nobody Tue Apr 29 07:58:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27DC1A0928; Tue, 29 Apr 2014 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2WRFYNd8foT; Tue, 29 Apr 2014 07:58:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A5A6F1A0925; Tue, 29 Apr 2014 07:58:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 870EBC220; Tue, 29 Apr 2014 10:58:24 -0400 (EDT) Date: Tue, 29 Apr 2014 10:58:24 -0400 From: Jeffrey Haas To: "Black, David" Subject: Re: Gen-ART review of draft-ietf-bfd-mib-18 Message-ID: <20140429145824.GR1256@pfrc> References: <8D3D17ACE214DC429325B2B98F3AE712076C437CE3@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C437EA9@MX15A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C437EA9@MX15A.corp.emc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IHSURTpKBzEWJUqJygHzY3oCDmc Cc: "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 14:58:30 -0000 On Tue, Apr 29, 2014 at 02:00:05AM -0400, Black, David wrote: > With respect to the MIB, this concern is a nit, so I'm ok with going ahead without > making this change ... > > ... However ... > > Your WG chairs and AD should be concerned that this significant flaw in > BFD version 0 (justifying a "SHOULD NOT use" recommendation) is undocumented. And also un-RFCed. It was a "work in progress" that never fully saw the light of full deployment. Vendors very quickly moved to version 1 which fixed a critical issue in the state machine. If any version 0 survives, it's historical and likely to be a source of operational agony rather than a useful feature. -- Jeff From nobody Tue Apr 29 08:38:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D721A091D; Tue, 29 Apr 2014 08:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o92jOI376Ijw; Tue, 29 Apr 2014 08:37:53 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78C1A01DF; Tue, 29 Apr 2014 08:37:52 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3TFbmDT024855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2014 11:37:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s3TFbmDT024855 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1398785870; bh=XDdtEZPUnWQK32BO3jrDItmfWrQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=JDw7ZcIrygsEoH1M/ed5ImfNsp+5Pu9Ul7yGhRsCMIiVRrvOjJyJRjJziGBJmnXJw YdNG3UG+ECbWnE5SU2hHGUU9A6+FNbv9MN6e8UEVQKc3Vi+h2bN0Q9CcwGkAXQhB40 PgvX4stbA2K7mhh6L8ZRTq5IWUhqzAAUAmsHwzPc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s3TFbmDT024855 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd53.lss.emc.com (RSA Interceptor); Tue, 29 Apr 2014 11:37:42 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3TFbfU1015605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 11:37:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 29 Apr 2014 11:37:40 -0400 From: "Black, David" To: Jeffrey Haas Date: Tue, 29 Apr 2014 11:37:39 -0400 Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Index: Ac9ju3y+7+r2M3cwRuClVDsxPJjgywAAKutg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C437F73@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C437CE3@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C437EA9@MX15A.corp.emc.com> <20140429145824.GR1256@pfrc> In-Reply-To: <20140429145824.GR1256@pfrc> 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 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/nvlPdYcFPEMiEi8wTVrGruyEhek Cc: "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" , "Black, David" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 15:37:55 -0000 Jeff - could you work w/Nobo to get the word "historical" included in the MIB draft as a characterization of BFD version 0 ? For example, the following text could be added to the introduction: because the BFD version 0 protocol is primarily of historical interest by comparison to the widespread deployment of the BFD version 1 protocol= . Thanks, --David > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Tuesday, April 29, 2014 10:58 AM > To: Black, David > Cc: Nobo Akiya (nobo); tnadeau@lucidvision.com; Zafar Ali (zali); General= Area > Review Team (gen-art@ietf.org); rtg-bfd@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-ietf-bfd-mib-18 >=20 > On Tue, Apr 29, 2014 at 02:00:05AM -0400, Black, David wrote: > > With respect to the MIB, this concern is a nit, so I'm ok with going ah= ead > without > > making this change ... > > > > ... However ... > > > > Your WG chairs and AD should be concerned that this significant flaw in > > BFD version 0 (justifying a "SHOULD NOT use" recommendation) is > undocumented. >=20 > And also un-RFCed. >=20 > It was a "work in progress" that never fully saw the light of full > deployment. Vendors very quickly moved to version 1 which fixed a critic= al > issue in the state machine. If any version 0 survives, it's historical a= nd > likely to be a source of operational agony rather than a useful feature. >=20 > -- Jeff From nobody Tue Apr 29 10:04:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA211A07D9 for ; Tue, 29 Apr 2014 10:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmE8v9DfJ9Mg for ; Tue, 29 Apr 2014 10:04:29 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id A92051A04B6 for ; Tue, 29 Apr 2014 10:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2351; q=dns/txt; s=iport; t=1398791068; x=1400000668; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pdypfWrzDVy7fdHktthOEGl2jM1527M9vjklt+falCs=; b=M/Vh8ZL4v26p+jSeOBM0MtiTZIBO7D+CfMqKKENViETvq07lvH6dZAh2 jGXJFmaeDtJiGVOWY3EyK861FEnHlqkhmiK6va8TwRJkhjO5NL+cpg1+g K/wu4wCEW8FMZlM2isEH4l9CpG8hzuhQoha3IranaRRezRW3DbaAQ2ziB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABHbX1OtJA2B/2dsb2JhbABZgwaBJsR5gSUWdIIlAQEBBDo/DAYBCBEEAQEBHgUEORQJCAIEAQ0FiEHJJReOTwcGhDMBA5kQkmKBcoE/gis X-IronPort-AV: E=Sophos;i="4.97,952,1389744000"; d="scan'208";a="39730067" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 29 Apr 2014 17:04:28 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3TH4SgW030634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 17:04:28 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.199]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 12:04:27 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Les Ginsberg (ginsberg)" , "Carlos Pignataro (cpignata)" , Jeff Haas , "Nobo Akiya (nobo)" Subject: Re: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOymQAAAJaKAAAAst9mAAHCnigA== Date: Tue, 29 Apr 2014 17:04:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.92.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <86E72A3DB7D89A4FA87E683498B1CC46@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oSS49vV7fvkVSdlqFOSR5NZ4U4U Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:04:31 -0000 Hi, Stateless or Soft BFD?. -Nagendra On 4/29/14 12:48 AM, "Les Ginsberg (ginsberg)" wrote: >"Connectionless" (CL-BFD) works for me. > >(Now ducking my head...) > > Les > > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos >> Pignataro (cpignata) >> Sent: Monday, April 28, 2014 11:18 AM >> To: Jeff Haas >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD charter update proposal [was: RE: Working Group >>adoption >> for Seamless BFD (requires re-charter)] >>=20 >> Hi Jeff, >>=20 >> On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: >>=20 >> > [Not specifically speaking as a chair here...] >> > >> > On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: >> >> Here's consolidated charter text proposal. >> >> >> >> >> >> Attempt #2 >> >> >> >> Define a mechanism to perform single-ended path (ex: continuity) >> verification based on the BFD specification; allow such mechanism to >> seamlessly work both proactively and on-demand; allow the mechanism to >> maintain multiple sessions to a target entity. In doing this work, the >>WG will >> work closely with at least the following other WGs: ISIS, OSPF, SPRING. >> > >> > So... what exactly does seamless mean here? What seams were you >> seeing that >> > you were trying to remove? >> > >> > FWIW, I think the charter discussion is moving along well, but I've >>never >> > quite groked the context for "seamless" for the proposal. >>"Stateless" BFD, >> > I can see quite well. >> > >>=20 >> Like others have said, we had some renaming discussions. Now it would be >> a good time to converge. Some of the (not perfect, but perfect is the >>enemy >> of good and progress here) more technical qualifiers are "Stateless", >> "Reflector", "Responder", "Mesh Group", "Asymmetric". These focus on the >> behavior of the responder mostly. Descriptive ones are also possible >>like >> "Easy", "Simple", "Seamless", etc. >>=20 >> Frankly I am not concerned about which name -- other than we should be >> consistent. >>=20 >> Net-net: I support your proposal of "Stateless" and a >> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. What do >> others think? >>=20 >> Thanks, >>=20 >> Carlos. >>=20 >> > -- Jeff > From nobody Tue Apr 29 11:57:30 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367C91A0958; Tue, 29 Apr 2014 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQUMZpd78Skq; Tue, 29 Apr 2014 11:57:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8301A097C; Tue, 29 Apr 2014 11:57:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-tc-mib-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429185725.2229.56468.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 11:57:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/TBOhtNrDu1FbKPBPu3ppGJRDAJs Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 18:57:29 -0000 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 : Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-06.txt Pages : 12 Date : 2014-04-29 Abstract: This draft defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-tc-mib-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 29 12:03:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216E41A097F; Tue, 29 Apr 2014 12:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3aXbHCCWNqS; Tue, 29 Apr 2014 12:03:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CC31A0981; Tue, 29 Apr 2014 12:03:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-19.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429190343.3546.44430.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 12:03:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/buQ_cV7-wcPd0iwwM1hPrm37D5s Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 19:03:49 -0000 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 Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-19.txt Pages : 38 Date : 2014-04-29 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 29 12:06:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCAC1A097F; Tue, 29 Apr 2014 12:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0md08NaBolkX; Tue, 29 Apr 2014 12:06:49 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE41A0792; Tue, 29 Apr 2014 12:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2317; q=dns/txt; s=iport; t=1398798408; x=1400008008; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JAJOJ90lUsDTAnSqJwPDqTxu8hZxx9IW/Tk7n3KX5EQ=; b=iAyNGn3Splg/6W1CjJUmWX+XA4CuHDDyf1kUBFL+OE+eUpqmqGhuVTa9 liuwxMygUc3LzG0IeXWksZ5r1bVy+VLjkiIR5E9g9n5e9nWVIQlyCR5Yy EB5PA45xKigZSyjjSR65yzrbeZk+CFOm023YfvnGefnsDbg7lh8/3GWqS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHAC/3X1OtJV2b/2dsb2JhbABZgmUhT1EGxQ+BJhZ0giUBAQEEOj8MBAIBCBEEAQEBChQJBzIUCQgBAQQBDQUIAYg4AQcFyTMXjh4xBwaDHoEVBJpMkSaDMYIr X-IronPort-AV: E=Sophos;i="4.97,952,1389744000"; d="scan'208";a="39747614" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 29 Apr 2014 19:06:47 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3TJ6ljS015380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 19:06:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 14:06:47 -0500 From: "Nobo Akiya (nobo)" To: "Black, David" , Jeffrey Haas Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-18 Thread-Index: Ac9i7PyERuk5jZsyQOKSHRHy2Ij/LwAG2CxAABnaMYAAHWa2AAABXuyAAAM2hqA= Date: Tue, 29 Apr 2014 19:06:46 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C437CE3@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712076C437EA9@MX15A.corp.emc.com> <20140429145824.GR1256@pfrc> <8D3D17ACE214DC429325B2B98F3AE712076C437F73@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C437F73@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/txmAuGybuI5ygCzJpt7q_7jYiUA Cc: "General Area Review Team \(gen-art@ietf.org\)" , "Zafar Ali \(zali\)" , "rtg-bfd@ietf.org" , "ietf@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 19:06:51 -0000 Hi David, BFD-MIB-19 with suggested text has just been published. URL: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-19.t= xt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ Htmlized: http://tools.ietf.org/html/draft-ietf-bfd-mib-19 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-19 Thanks again! -Nobo > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Tuesday, April 29, 2014 11:38 AM > To: Jeffrey Haas > Cc: Nobo Akiya (nobo); tnadeau@lucidvision.com; Zafar Ali (zali); General > Area Review Team (gen-art@ietf.org); rtg-bfd@ietf.org; ietf@ietf.org; Bla= ck, > David > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 >=20 > Jeff - could you work w/Nobo to get the word "historical" included in the > MIB draft as a characterization of BFD version 0 ? For example, the foll= owing > text could be added to the introduction: >=20 > because the BFD version 0 protocol is primarily of historical interest > by comparison to the widespread deployment of the BFD version 1 > protocol. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > > Sent: Tuesday, April 29, 2014 10:58 AM > > To: Black, David > > Cc: Nobo Akiya (nobo); tnadeau@lucidvision.com; Zafar Ali (zali); > > General Area Review Team (gen-art@ietf.org); rtg-bfd@ietf.org; > > ietf@ietf.org > > Subject: Re: Gen-ART review of draft-ietf-bfd-mib-18 > > > > On Tue, Apr 29, 2014 at 02:00:05AM -0400, Black, David wrote: > > > With respect to the MIB, this concern is a nit, so I'm ok with going > > > ahead > > without > > > making this change ... > > > > > > ... However ... > > > > > > Your WG chairs and AD should be concerned that this significant flaw > > > in BFD version 0 (justifying a "SHOULD NOT use" recommendation) is > > undocumented. > > > > And also un-RFCed. > > > > It was a "work in progress" that never fully saw the light of full > > deployment. Vendors very quickly moved to version 1 which fixed a > > critical issue in the state machine. If any version 0 survives, it's > > historical and likely to be a source of operational agony rather than a > useful feature. > > > > -- Jeff From nobody Tue Apr 29 12:46:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989DD1A09B6 for ; Tue, 29 Apr 2014 12:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjfgED-yQorE for ; Tue, 29 Apr 2014 12:46:36 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 89A701A09CE for ; Tue, 29 Apr 2014 12:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6644; q=dns/txt; s=iport; t=1398800795; x=1400010395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4mZcRDyFSf/BnW2Kk6PaSrjpDWBqLy+tAjGOzllV7UI=; b=iHtj+TtbMW6kK2CBb9F5VY7AnP72PerbebydZypRhwkTpAsD1K2ZAv1J i+rH2HaopjhTAjO7W8tFK+3ltiI5KNqsAk2cOVPIyHCordQTIOUaaf/0z rSdl6xaZ5OWES/YmOXK41l0SmtBwtzuyhEHu/ZiMUeUNFJD2G1wjzobr5 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAA4BYFOtJA2N/2dsb2JhbABZgmUhgSbFFYEmFnSCJQEBAQQ6MQ4MAgICAQgRBAEBAQoUBQQHGxcUCQgCBAENBQiIOQHJUxcEjWkRAR8xBwaDHoEVBJRblxeBcoE/gXI5 X-IronPort-AV: E=Sophos;i="4.97,952,1389744000"; d="scan'208";a="39752190" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 29 Apr 2014 19:46:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s3TJkYPI029795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 19:46:34 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 14:46:34 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "rtg-bfd@ietf.org" , "Les Ginsberg (ginsberg)" , "Carlos Pignataro (cpignata)" , "Jeffrey Haas (jhaas@pfrc.org)" Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOymQAAAJaKAAAAst9mAADer5gAABs0MAAAAxeQAADwflYA== Date: Tue, 29 Apr 2014 19:46:33 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7A7164@eusaamb103.ericsson.se> <535F5074.1060005@pi.nu> In-Reply-To: <535F5074.1060005@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/EJuaBaMUgC8gFjyx90Hu9K1wyCQ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 19:46:38 -0000 I get the sense that some of you guys are having a lot of fun with the nami= ng :) Continuing to consolidate comments for the charter text proposal (attempt 4= below). [Greg wrote] > I think that it is important to stress in the charter update that: > * S-BFD enables continuity check/verification/monitoring, i.e. availabili= ty of > the path, and is not intended to support connectivity verification; > * multiple session can be maintained not only to the same target entity, = i.e. > Your Discriminator, but between the same pair of network entities, i.e. I= P > addresses. Agree with second bullet. As for first bullet, we can tighten the text to r= estrict to CC. Although result does leave out alert discriminator which is = aimed to provide operators with more clues on why multihop BFD had failed, = doing CV attempt with S-BFD is still a topic that requires further investig= ations/discussions. Let us revisit this at a later time then.=20 [Marc wrote] > Would it be a problem to be more specific? E.g.: >=20 > Define a mechanism to perform path (ex: continuity) verification based on > the BFD specification, with only one side holding all state and a statele= ss > reflector as the peer. Allow such mechanism ... Perhaps too specific, i.e. implies too much of requirements, IMHO. I figure= d it's beneficial for one person to consolidate comments into this charter = text, which provides me with the privilege to apply my own filter first. Bu= t it doesn't mean that's the end, and feel free to discuss/argue :) [Tina wrote] > Softwire WG may be among the list of other WGs we should work with. Yes I do I see S-BFD to fit nicely with DS-lite tunnel check from B4 to AFT= R, and it does require DHCPv6 extension or something else to advertise BFD = discriminators. I haven't seen anyone starting this activity yet, so I don'= t think we should explicitly include Softwire WG at this point. However, cu= rrent proposal text says "... at least following other WGs: ISIS, OSPF, SPR= ING.". Thus I think we are ok. On the other hand, if you can rally sufficie= nt interest before BFD WG charter update is done (May 8th), then I think it= 'll be good to explicitly include Softwire into the "at least" list. Attempt #4 Define a mechanism to perform single-ended path (i.e. continuity) verificat= ion based on the BFD specification; allow such mechanism to work both proac= tively and on-demand, without prominent initial delay; allow the mechanism = to maintain multiple sessions to a target entity and between the same pair = of network entities. In doing this work, the WG will work closely with at l= east the following other WGs: ISIS, OSPF, SPRING. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Tuesday, April 29, 2014 3:11 AM > To: rtg-bfd@ietf.org > Subject: Re: BFD charter update proposal [was: RE: Working Group adoption > for Seamless BFD (requires re-charter)] >=20 > hmmm - "seamless" might not describe what we want or define very > accurately, but at least it is short and catchy (the just add a few parag= raphs > to explain what we'll do). >=20 > /Loa >=20 > On 2014-04-29 09:05, Gregory Mirsky wrote: > > Verification/monitoring (on-demand/proactive) of path continuity in > packet switched connectionless network domain. > > > > Cheers, > > Greg > > > > PS. Resisted but not for too long :) > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sam > > Aldrin > > Sent: Monday, April 28, 2014 11:17 PM > > To: Les Ginsberg (ginsberg) > > Cc: Carlos Pignataro; rtg-bfd@ietf.org > > Subject: Re: BFD charter update proposal [was: RE: Working Group > > adoption for Seamless BFD (requires re-charter)] > > > > connections less BFD checking connection failures :D Sorry couldn't > > resist. :D > > > > -sam > > > > On Apr 28, 2014, at 9:48 PM, Les Ginsberg (ginsberg) > wrote: > > > >> "Connectionless" (CL-BFD) works for me. > >> > >> (Now ducking my head...) > >> > >> Les > >> > >> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos > >>> Pignataro (cpignata) > >>> Sent: Monday, April 28, 2014 11:18 AM > >>> To: Jeff Haas > >>> Cc: rtg-bfd@ietf.org > >>> Subject: Re: BFD charter update proposal [was: RE: Working Group > >>> adoption for Seamless BFD (requires re-charter)] > >>> > >>> Hi Jeff, > >>> > >>> On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: > >>> > >>>> [Not specifically speaking as a chair here...] > >>>> > >>>> On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: > >>>>> Here's consolidated charter text proposal. > >>>>> > >>>>> > >>>>> Attempt #2 > >>>>> > >>>>> Define a mechanism to perform single-ended path (ex: continuity) > >>> verification based on the BFD specification; allow such mechanism to > >>> seamlessly work both proactively and on-demand; allow the mechanism > >>> to maintain multiple sessions to a target entity. In doing this > >>> work, the WG will work closely with at least the following other WGs: > ISIS, OSPF, SPRING. > >>>> > >>>> So... what exactly does seamless mean here? What seams were you > >>> seeing that > >>>> you were trying to remove? > >>>> > >>>> FWIW, I think the charter discussion is moving along well, but I've > >>>> never quite groked the context for "seamless" for the proposal. > >>>> "Stateless" BFD, I can see quite well. > >>>> > >>> > >>> Like others have said, we had some renaming discussions. Now it > >>> would be a good time to converge. Some of the (not perfect, but > >>> perfect is the enemy of good and progress here) more technical > >>> qualifiers are "Stateless", "Reflector", "Responder", "Mesh Group", > "Asymmetric". > >>> These focus on the behavior of the responder mostly. Descriptive > >>> ones are also possible like "Easy", "Simple", "Seamless", etc. > >>> > >>> Frankly I am not concerned about which name -- other than we should > >>> be consistent. > >>> > >>> Net-net: I support your proposal of "Stateless" and a > >>> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. > >>> What do others think? > >>> > >>> Thanks, > >>> > >>> Carlos. > >>> > >>>> -- Jeff > >> > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 29 22:14:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215711A6ED9 for ; Tue, 29 Apr 2014 22:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q7ZQzrQUZkw for ; Tue, 29 Apr 2014 22:14:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E23CA1A6EE2 for ; Tue, 29 Apr 2014 22:14:40 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-a2-536035a673d8 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 55.2C.02831.6A530635; Wed, 30 Apr 2014 01:28:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 01:14:32 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Loa Andersson , "rtg-bfd@ietf.org" , "Les Ginsberg (ginsberg)" , "Carlos Pignataro (cpignata)" , "Jeffrey Haas (jhaas@pfrc.org)" Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAOREfAAAJaMaAABYD6oAAAxTegAAGyerQ///Y1gCAANMsgP//pPvg Date: Wed, 30 Apr 2014 05:14:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7A79AA@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7A7164@eusaamb103.ericsson.se> <535F5074.1060005@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLrHW3e5aUKwQc9xLotP73awWGz4s5Hd Yv/Bt6wW/+bOYbaYfeU/kOiIt/j8ZxujxdHfa1kdODym/N7I6tFy5C2rx5IlP5k8LvduZfWY Nb2NzaN1dTdLAFsUl01Kak5mWWqRvl0CV8bECwvZC55YVEw7WNjAOFu3i5GTQ0LAROLG2m4W CFtM4sK99WxdjFwcQgJHGSVmbv0P5SxnlDjR/ZsZpIpNwEjixcYedpCEiEAbk8S3BTMYQRLM AhUSW08tAUpwcAgLFEv8XMUOEhYRKJE4uHkHI0hYRCBPYvIeThCTRUBVYuUKTpAKXgFfidtL p4FNFxLYyyIx/5s0iM0JFJ997RTYbYxAt30/tYYJYpG4xK0n85kgbhaQWLLnPDOELSrx8vE/ VghbSeLj7/nsEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZ xchRWpxalptuZLiJERiDxyTYHHcwLvhkeYhRgINRiYd3+uLIYCHWxLLiytxDjNIcLErivOmf YoOFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNrubHn158SiWUb9zB3l63m2NThOezKzm1fJ bNmJv4s2mDQ9Dd8wUeKfoZfJocoW4/SplkWm3Z7xiffWX7u5/lSPdtQWzXnLv2Xat+mm+i3m koi5MX1iJVOhnbTHUu673X3z7M6pugtuMDgxTTegI/PaHi/VCwrAdHVMYvbbOCvVzdtst/UK K7EUZyQaajEXFScCAEa1qn6iAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zfgLljNYmXEtLvvTWmA6LzJWVWY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 05:14:46 -0000 Hi Nobo, I think you've nailed it. I'm happy with the Take #4. Regards, Greg -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Tuesday, April 29, 2014 12:47 PM To: Loa Andersson; rtg-bfd@ietf.org; Les Ginsberg (ginsberg); Carlos Pignat= aro (cpignata); Jeffrey Haas (jhaas@pfrc.org) Cc: Marc Binderberger (marc@sniff.de); Gregory Mirsky; Tina.Tsou.Zouting@hu= awei.com Subject: RE: BFD charter update proposal [was: RE: Working Group adoption f= or Seamless BFD (requires re-charter)] I get the sense that some of you guys are having a lot of fun with the nami= ng :) Continuing to consolidate comments for the charter text proposal (attempt 4= below). [Greg wrote] > I think that it is important to stress in the charter update that: > * S-BFD enables continuity check/verification/monitoring, i.e.=20 > availability of the path, and is not intended to support connectivity=20 > verification; > * multiple session can be maintained not only to the same target entity, = i.e. > Your Discriminator, but between the same pair of network entities,=20 > i.e. IP addresses. Agree with second bullet. As for first bullet, we can tighten the text to r= estrict to CC. Although result does leave out alert discriminator which is = aimed to provide operators with more clues on why multihop BFD had failed, = doing CV attempt with S-BFD is still a topic that requires further investig= ations/discussions. Let us revisit this at a later time then.=20 [Marc wrote] > Would it be a problem to be more specific? E.g.: >=20 > Define a mechanism to perform path (ex: continuity) verification based=20 > on the BFD specification, with only one side holding all state and a=20 > stateless reflector as the peer. Allow such mechanism ... Perhaps too specific, i.e. implies too much of requirements, IMHO. I figure= d it's beneficial for one person to consolidate comments into this charter = text, which provides me with the privilege to apply my own filter first. Bu= t it doesn't mean that's the end, and feel free to discuss/argue :) [Tina wrote] > Softwire WG may be among the list of other WGs we should work with. Yes I do I see S-BFD to fit nicely with DS-lite tunnel check from B4 to AFT= R, and it does require DHCPv6 extension or something else to advertise BFD = discriminators. I haven't seen anyone starting this activity yet, so I don'= t think we should explicitly include Softwire WG at this point. However, cu= rrent proposal text says "... at least following other WGs: ISIS, OSPF, SPR= ING.". Thus I think we are ok. On the other hand, if you can rally sufficie= nt interest before BFD WG charter update is done (May 8th), then I think it= 'll be good to explicitly include Softwire into the "at least" list. Attempt #4 Define a mechanism to perform single-ended path (i.e. continuity) verificat= ion based on the BFD specification; allow such mechanism to work both proac= tively and on-demand, without prominent initial delay; allow the mechanism = to maintain multiple sessions to a target entity and between the same pair = of network entities. In doing this work, the WG will work closely with at l= east the following other WGs: ISIS, OSPF, SPRING. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa=20 > Andersson > Sent: Tuesday, April 29, 2014 3:11 AM > To: rtg-bfd@ietf.org > Subject: Re: BFD charter update proposal [was: RE: Working Group=20 > adoption for Seamless BFD (requires re-charter)] >=20 > hmmm - "seamless" might not describe what we want or define very=20 > accurately, but at least it is short and catchy (the just add a few=20 > paragraphs to explain what we'll do). >=20 > /Loa >=20 > On 2014-04-29 09:05, Gregory Mirsky wrote: > > Verification/monitoring (on-demand/proactive) of path continuity in > packet switched connectionless network domain. > > > > Cheers, > > Greg > > > > PS. Resisted but not for too long :) > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Sam=20 > > Aldrin > > Sent: Monday, April 28, 2014 11:17 PM > > To: Les Ginsberg (ginsberg) > > Cc: Carlos Pignataro; rtg-bfd@ietf.org > > Subject: Re: BFD charter update proposal [was: RE: Working Group=20 > > adoption for Seamless BFD (requires re-charter)] > > > > connections less BFD checking connection failures :D Sorry couldn't=20 > > resist. :D > > > > -sam > > > > On Apr 28, 2014, at 9:48 PM, Les Ginsberg (ginsberg)=20 > > > wrote: > > > >> "Connectionless" (CL-BFD) works for me. > >> > >> (Now ducking my head...) > >> > >> Les > >> > >> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > >>> Carlos Pignataro (cpignata) > >>> Sent: Monday, April 28, 2014 11:18 AM > >>> To: Jeff Haas > >>> Cc: rtg-bfd@ietf.org > >>> Subject: Re: BFD charter update proposal [was: RE: Working Group=20 > >>> adoption for Seamless BFD (requires re-charter)] > >>> > >>> Hi Jeff, > >>> > >>> On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: > >>> > >>>> [Not specifically speaking as a chair here...] > >>>> > >>>> On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: > >>>>> Here's consolidated charter text proposal. > >>>>> > >>>>> > >>>>> Attempt #2 > >>>>> > >>>>> Define a mechanism to perform single-ended path (ex: continuity) > >>> verification based on the BFD specification; allow such mechanism=20 > >>> to seamlessly work both proactively and on-demand; allow the=20 > >>> mechanism to maintain multiple sessions to a target entity. In=20 > >>> doing this work, the WG will work closely with at least the following= other WGs: > ISIS, OSPF, SPRING. > >>>> > >>>> So... what exactly does seamless mean here? What seams were you > >>> seeing that > >>>> you were trying to remove? > >>>> > >>>> FWIW, I think the charter discussion is moving along well, but=20 > >>>> I've never quite groked the context for "seamless" for the proposal. > >>>> "Stateless" BFD, I can see quite well. > >>>> > >>> > >>> Like others have said, we had some renaming discussions. Now it=20 > >>> would be a good time to converge. Some of the (not perfect, but=20 > >>> perfect is the enemy of good and progress here) more technical=20 > >>> qualifiers are "Stateless", "Reflector", "Responder", "Mesh=20 > >>> Group", > "Asymmetric". > >>> These focus on the behavior of the responder mostly. Descriptive=20 > >>> ones are also possible like "Easy", "Simple", "Seamless", etc. > >>> > >>> Frankly I am not concerned about which name -- other than we=20 > >>> should be consistent. > >>> > >>> Net-net: I support your proposal of "Stateless" and a=20 > >>> %s/Seamless/Stateless/g. It also keeps the same abbrev of S-BFD. > >>> What do others think? > >>> > >>> Thanks, > >>> > >>> Carlos. > >>> > >>>> -- Jeff > >> > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Apr 30 12:37:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429581A8839; Wed, 30 Apr 2014 12:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr4CLHPdLics; Wed, 30 Apr 2014 12:37:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 855801A888A; Wed, 30 Apr 2014 12:37:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-tc-mib-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430193700.8720.65130.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 12:37:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/U6vIC6QsG9aaXb2MFHQUL8mjmfg Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:37:07 -0000 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 : Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-07.txt Pages : 12 Date : 2014-04-30 Abstract: This draft defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-tc-mib-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 30 17:27:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F281A6F22 for ; Wed, 30 Apr 2014 17:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.151 X-Spam-Level: X-Spam-Status: No, score=-115.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMGAAhYDOQ2b for ; Wed, 30 Apr 2014 17:27:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DA1DE1A0981 for ; Wed, 30 Apr 2014 17:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14206; q=dns/txt; s=iport; t=1398904043; x=1400113643; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Fnjmpazp0lQnPt4V3GziEj/JKCDCU7x/hTyR3LVjIZ0=; b=d6l2mSfQwilsNisgiGxTzy0Z1nE8GMVxaHo6WZD5EcH/puXzvd34pd/r bt6ouO61Lu/m2lTkPDUKmIrOsUp4p31kKGlcq6cj6t0Qd/L6XqepqB9Eu 4F2mgLAo0yWyTDZmRLNRIM8qHnt+THTtyfbEf7dUkrak6Wfm9HYVCzRlk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGqUYVOtJV2Z/2dsb2JhbABZgkIjIU9XxE2BIRZ0giUBAQEELUoSAgEIEQQBAQsdBzIUCQgCBAESCIg5AcoJF44gNwGDJIEVBI0vk1eLDIMxgis X-IronPort-AV: E=Sophos;i="4.97,961,1389744000"; d="scan'208,217";a="321619737" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 01 May 2014 00:27:22 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s410RMKG029257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 May 2014 00:27:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 19:27:22 -0500 From: "Nobo Akiya (nobo)" To: "Les Ginsberg (ginsberg)" , "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Topic: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Index: AQHPWjuSIo9hc5e0sES09J7I8hmrpZsoFESwgALdZKA= Date: Thu, 1 May 2014 00:27:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.178] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E118EE5xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/1-VfH95L9ofiyqya5ZDMXJiWjTo X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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 May 2014 00:27:27 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E118EE5xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Les, That's a good point. Like you said, with certain cases, application might r= equest S-BFD discriminator allocation, to BFD, with specific value, but thi= s is still BFD allocating the discriminator. And apps can certain share the= same S-BFD discriminator if for same purpose. So I agree, section 2 should= get reworded to clarify these. -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Les Ginsberg (= ginsberg) Sent: Tuesday, April 29, 2014 12:49 AM To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org Subject: RE: New version notification for draft-akiya-bfd-seamless-base-03.= txt Section 2 says "Each protocol instance (e.g. OSPF/IS-IS) allocates one or more BFD discriminators on its network node..." I don't see the BFD clients as the "allocators". BFD owns its discriminator= space and will therefore have to do the allocation. Further, there are cer= tainly use cases where there is no need for a "per client discriminator" - = so the suggestion that "each protocol instance" has to have a unique discri= minator isn't accurate. I understand that in some cases a protocol identifier (e.g. router-id) migh= t be used either as the public discriminator or as a seed for the public di= scriminator - but that is not at all the same thing as acting as the alloca= tor. I also understand IGPs may be used to advertise the public discriminat= ors - but again this is not "allocating". I think all mention of BFD clients should be removed from this section and = you should simply say "BFD on a network node allocates ..." Les From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGON= DA (mmudigon) Sent: Thursday, April 17, 2014 5:50 AM To: rtg-bfd@ietf.org Subject: New version notification for draft-akiya-bfd-seamless-base-03.txt Hello BFD WG Members, We have published a new version of Seamless BFD draft, draft-akiya-bfd-seam= less-base-03. Several sections have been updated for improving readability.= It also has a few technical changes as well. Please review the draft and g= et back to us with your comments. Thanks Regards Mallik --_000_CECE764681BE964CBE1DFF78F3CDD3941E118EE5xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Les,=

 <= /p>

That’s a good point= . Like you said, with certain cases, application might request S-BFD discri= minator allocation, to BFD, with specific value, but this is still BFD allocating the discriminator. And apps can certain share the same S-BF= D discriminator if for same purpose. So I agree, section 2 should get rewor= ded to clarify these.

 <= /p>

-Nobo

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; 

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, April 29, 2014 12:49 AM
To: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org
Subject: RE: New version notification for draft-akiya-bfd-seamless-b= ase-03.txt

 

Section 2 = says

 = ;

“Eac= h protocol instance (e.g. OSPF/IS-IS) allocates one or more BFD<= /span>

 &nbs= p; discriminators on its network node…”

 = ;

I don̵= 7;t see the BFD clients as the “allocators”. BFD owns its discr= iminator space and will therefore have to do the allocation. Further, there are certainly use cases where there is no need for a “per client dis= criminator” – so the suggestion that “each protocol insta= nce” has to have a unique discriminator isn’t accurate.

 = ;

I understa= nd that in some cases a protocol identifier (e.g. router-id) might be used = either as the public discriminator or as a seed for the public discriminator – but that is not at all the same thing as acting as t= he allocator. I also understand IGPs may be used to advertise the public di= scriminators – but again this is not “allocating”.

 = ;

I think al= l mention of BFD clients should be removed from this section and you should= simply say “BFD on a network node allocates …”

 = ;

 &nbs= p; Les

 = ;

 = ;

From: Rtg-bfd [= mailto:rtg-bfd-bounces@ietf.org] On Behalf Of MALLIK MUDIGONDA (mmudigon)
Sent: Thursday, April 17, 2014 5:50 AM
To: rtg-bfd@ietf.org
Subject: New version notification for draft-akiya-bfd-seamless-base-= 03.txt

 

Hello BFD WG M= embers,

 

We have publis= hed a new version of Seamless BFD draft, draft-akiya-bfd-seamless-base-03. = Several sections have been updated for improving readability. It also has a few technical changes as well. Please review the draft and g= et back to us with your comments.

 

Thanks

 

Regards

Mallik

--_000_CECE764681BE964CBE1DFF78F3CDD3941E118EE5xmbalnx01ciscoc_--