From nobo@cisco.com Sat Feb 1 08:56: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 0F33B1A05A3 for ; Sat, 1 Feb 2014 08:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 MoerNk75bvxv for ; Sat, 1 Feb 2014 08:56:45 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C1A631A03D2 for ; Sat, 1 Feb 2014 08:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6527; q=dns/txt; s=iport; t=1391273803; x=1392483403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=q+VIWDK5VTmS/r8ntW8qrHcGpa/FOw84K5Dq87Sm64k=; b=VMSJ5BD03KgqXR4dUQ9YrVJjTsUSVA2OdEuUDBLFLHQ9ilbeVUnSEvEa Z1b8FniOb6nO3YeAXn+glnfnPi+LxL18401ruchfZcp0CMEUWRgrtO/Qc 79GhDik2voVgc8RA1qP0YrxzcxbXMKxP3QAoB6N4V06uW1VAXn5Wx1r5n g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOMm7VKtJXG//2dsb2JhbABPCoJtIYENvGqBCRYBdIN9AQEBAwE6LRIFBwQCAQgRBAEBAQoUCQcyFAkIAQEEDgUIE4dhCAHGPxeONisxBwaDHYETBKoqgyuCKg X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208";a="298190880" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 01 Feb 2014 16:56:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s11GufvO008007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Feb 2014 16:56:41 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; Sat, 1 Feb 2014 10:56:41 -0600 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: S-BFD discriminator for ISIS? Thread-Topic: S-BFD discriminator for ISIS? Thread-Index: Ac8e2U/W07BIR+TVQ0y8Kru37a/QEgAR2+2AAAuHwpAAACAzAAAGs8TQ Date: Sat, 1 Feb 2014 16:56:40 +0000 Message-ID: References: <20140131173933034563.54c393e9@sniff.de> <20140131231318767731.e3c8f834@sniff.de> In-Reply-To: <20140131231318767731.e3c8f834@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" , Sam Aldrin 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, 01 Feb 2014 16:56:48 -0000 Hi Marc, Simplicity of using <=3D4 byte IDs as target discriminator is still strong,= as it allows S-BFD to be quickly plugged into various scenarios where apps= are already signaling the IDs or there is no signaling at all. At the same= time, how do we want to handle >4 byte IDs ... it looks like consensus [so= far] is static config for near future, and possibly some sort of auto mech= anism later. Related but slightly tangent topic is the point you brought up: impact to d= iscriminator implementations. I agree that this is a good topic to discuss = further. Considering that S-BFD will use new UDP port, I'm under the impres= sion that new set of rules can be implemented by vendors, i.e. old rules do= not have to be carried over, although more code recycling the better. > But I wasn't in Vancouver and may have missed something :-) There wasn't any discussion around this (impact to discriminator implementa= tions) at Vancouver, discussion was more centered around need for use-case = draft (which is in progress) and shaking out the quirks from the base draft= . Let us continue to think and discuss. -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Saturday, February 01, 2014 2:13 AM > To: Nobo Akiya (nobo) > Cc: Sam Aldrin; rtg-bfd@ietf.org > Subject: RE: S-BFD discriminator for ISIS? >=20 > Hi Nobo, >=20 > > IPv4 address can remain the same, i.e. IPv4 address used as > > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to > > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. >=20 > hmm. You know from our private discussions that I personally think using > IPv4 addresses as discriminator values is, well, not optimal ;-) >=20 > But before explaining this I would say having one mechanism that "covers = it > all" would be a good thing (tm). Like ISIS covers both IPv4 and IPv6, you > don't have to learn a new mechanism. >=20 > So for a network node you would have it's labels and it's discriminator > value (or values?). For simplicity of this discussion lets say assigned b= y an > administrator with a full overview. Then ISIS distributes this. > Some node X wants to BFD-test the path to node Y? Okay, X has learned via > ISIS the necessary information. >=20 > Generic, I haven't talked anywhere about IPv4 or IPv6 :-) >=20 > Back to my "not optimal": so far a node was free to choose what > discriminator values it wants to use. The BFD peer (in RFC5880 sense) jus= t > copied the value back. This freedom of choice has been used to simplify > implementations, e.g. only using the lower bits to index into arrays or > match in TCAMs. And so far all the standards have abide and not imposed a > condition or structure on the discriminator values (except zero). >=20 > Sure, you can get the Address-as-discriminator scheme working. But why > taking this freedom for the implementor away? >=20 > But I wasn't in Vancouver and may have missed something :-) >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Sat, 1 Feb 2014 02:31:31 +0000, Nobo Akiya (nobo) wrote: > > Thanks for comments Sam and Marc. > > > > [combining reply in one] > > > > [Sam wrote] > >> Option #1 is a reasonable approach and is the understanding for the > >> solutions discussed thus far. Eventually support for #2 should be > >> there as well, but that does take time and discussions to come to a > >> common solution. > > > > That's good to hear that you also think option #1 is reasonable. More > > comments about option #2 below. > > > > [Marc wrote] > >>> So I had a chat with ISIS person. > >>> > >>> Obviously we need ISIS to advertise S-BFD discriminator. > >> > >> ... but you mean the discriminator of the reflecting node is not > >> identical with the IPv4 address anymore but potentially independent > >> and learned by the other systems, with ISIS as the distribution > mechanism? > >> > > > > IPv4 address can remain the same, i.e. IPv4 address used as > > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to > > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. > > > >>> But the question is, how does ISIS choose what discriminator to > allocate? > >> > >> Maybe a nitpick but ISIS should transport the discriminator value of > >> a particular site but should not have knowledge how to choose a > >> discriminator. Just another 32bit number for ISIS to send as TLV. > > > > True. It could be outside of ISIS as well, but some entity will have > > to do it. > > > >> > >> Saying this if ISIS finds a conflict in it's database, i.e. two > >> identical discriminators from different nodes, then raising an alarm > >> would be useful (not necessary though). > > > > Exactly. BFD won't be able to detect the conflict but BFD client (ISIS > > in this case) is in better position to identify the conflict. > > Upon conflict, which node need to change then, and how to change w/o > > affecting reflector session already bouncing packets back. These sort > > of questions will need to be answered, when we (WG) think it's > > wanted/needed. > > > >> > >>> 1. One approach would be to simply have operators configure network > >>> wide unique 4-byte for each ISIS. > >> > >> sounds like a working solution to start with. Also it provides a > >> simple answer to an area I think is an implementation detail, outside > >> BFD or even ISIS protocol specification. > > > > Good :) > > > > If there are other agreements to option #1 (config approach) or > > arguments against it, I certainly would like to hear. It will help > > improve usability of S-BFD out in the wild. > > > > -Nobo > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >>> > >>> Discriminator should be as much unique as possible in the domain, if > >>> not guaranteed unique. > >>> This is to ensure reflector session does not respond to falsely > >>> self-terminating S-BFD packet. > >>> > >>> 1. One approach would be to simply have operators configure network > >>> wide unique 4-byte for each ISIS. > >>> > >>> 2. Another approach would be to compute 4-byte from *local stuff*, > >>> and come up with a conflict resolution mechanism. > >>> > >>> My initial thought is that (1) is reasonable for immediate needs. > >>> But wanted to check with others on the list. > >>> > >>> Any comments and/or preferences? > >>> > >>> -Nobo > >>> (as individual contributor) > >>> > > From gregory.mirsky@ericsson.com Sat Feb 1 16:10: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 8DF041A000F for ; Sat, 1 Feb 2014 16:10:17 -0800 (PST) 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 B7q_LrUmIA-r for ; Sat, 1 Feb 2014 16:10:15 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 419141A000C for ; Sat, 1 Feb 2014 16:10:15 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-fb-52ed8cde5c6b Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B8.FC.12743.EDC8DE25; Sun, 2 Feb 2014 01:10:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Sat, 1 Feb 2014 19:10:09 -0500 From: Gregory Mirsky To: Marc Binderberger , Nobo Akiya Subject: RE: S-BFD discriminator for ISIS? Thread-Topic: S-BFD discriminator for ISIS? Thread-Index: Ac8e2U/W07BIR+TVQ0y8Kru37a/QEgAPw3yAAAHQnoAACddXAAAH4xcQ Date: Sun, 2 Feb 2014 00:10:08 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B75D82C@eusaamb103.ericsson.se> References: <20140131173933034563.54c393e9@sniff.de> <20140131231318767731.e3c8f834@sniff.de> In-Reply-To: <20140131231318767731.e3c8f834@sniff.de> 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+NgFnrILMWRmVeSWpSXmKPExsUyuXRPuO79nrdBBh97mS1mX/kPJDriLT7/ 2cZo8bvzO6MDi8eU3xtZPXbOusvusWTJTyaP1tXdLAEsUVw2Kak5mWWpRfp2CVwZl/+2shZ8 06v4eKCLrYHxqmoXIyeHhICJxL/WE+wQtpjEhXvr2boYuTiEBI4wSqy/fIMZwlnGKDG37R8j SBWbgJHEi409YB0iAk4Sj6Y0MIPYzALpEqsuPWUBsYUFtCTuPzvNBFGjLdGw4RZQDQeQ7SZx faoUSJhFQEVi1e0WsBJeAV+JSU+7oBY/ZZTY3PEGbD6ngKnEqanbwOYzAl33/dQaJohd4hK3 nsxngrhaQGLJnvPMELaoxMvH/1ghbEWJff3T2SHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gm MIrNQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chgEyMwmo5JsOnuYNzz0vIQozQHi5I475e3 zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGOcWPb7wla2pvvDu51P8Yj8OmUvIth65Ixtr vWhx0S/1D+XWlfM1fhqYTXp2/8DcQ60lJ7199+/4q3gje8MahWMBBj7eNza5St6aF9DoxxVb sTS+zcLiVMGq3nwXdkudFXaXXoTVVzXpJvvGfvh5Yt8krR7On7ofTmwMenn1TfzF/Yl7fl+P F1ViKc5INNRiLipOBAAc+0zcdAIAAA== Cc: "rtg-bfd@ietf.org" , "Sam Aldrin \(sam.aldrin@gmail.com\)" 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, 02 Feb 2014 00:10:17 -0000 Hi Marc, Nobo, et. al, glad to have our discussion back. I'm all for explicit mapping of NE and discriminators. Using IGP lets us no= t only advertise the discriminator but to withdraw the advertisement at wil= l. With this approach we may manage to keep BFD and S-BFD discriminator spa= ces as one, if we find this goal worth pursuing. And if we find that Seamless BFD is useful in Segment Routing network, then= label advertised by IGP can be viewed as implicit discriminator. If that i= s the case, why not to use extensions proposed for SR in SPRING WG, perhaps= with extra twists, to advertise discriminators for S-BFD. What do you thin= k? Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderber= ger Sent: Friday, January 31, 2014 11:13 PM To: Nobo Akiya Cc: rtg-bfd@ietf.org; Sam Aldrin (sam.aldrin@gmail.com) Subject: RE: S-BFD discriminator for ISIS? Hi Nobo, > IPv4 address can remain the same, i.e. IPv4 address used as=20 > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to=20 > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. hmm. You know from our private discussions that I personally think using IP= v4 addresses as discriminator values is, well, not optimal ;-) But before explaining this I would say having one mechanism that "covers it= all" would be a good thing (tm). Like ISIS covers both IPv4 and IPv6, you = don't have to learn a new mechanism. So for a network node you would have it's labels and it's discriminator val= ue (or values?). For simplicity of this discussion lets say assigned by an = administrator with a full overview. Then ISIS distributes this.=20 Some node X wants to BFD-test the path to node Y? Okay, X has learned via I= SIS the necessary information. Generic, I haven't talked anywhere about IPv4 or IPv6 :-) Back to my "not optimal": so far a node was free to choose what discriminat= or values it wants to use. The BFD peer (in RFC5880 sense) just copied the = value back. This freedom of choice has been used to simplify implementation= s, e.g. only using the lower bits to index into arrays or match in TCAMs. A= nd so far all the standards have abide and not imposed a condition or struc= ture on the discriminator values (except zero). Sure, you can get the Address-as-discriminator scheme working. But why taki= ng this freedom for the implementor away? But I wasn't in Vancouver and may have missed something :-) Regards, Marc On Sat, 1 Feb 2014 02:31:31 +0000, Nobo Akiya (nobo) wrote: > Thanks for comments Sam and Marc. >=20 > [combining reply in one] >=20 > [Sam wrote] >> Option #1 is a reasonable approach and is the understanding for the=20 >> solutions discussed thus far. Eventually support for #2 should be=20 >> there as well, but that does take time and discussions to come to a=20 >> common solution. >=20 > That's good to hear that you also think option #1 is reasonable. More=20 > comments about option #2 below. >=20 > [Marc wrote] >>> So I had a chat with ISIS person. >>>=20 >>> Obviously we need ISIS to advertise S-BFD discriminator. >>=20 >> ... but you mean the discriminator of the reflecting node is not=20 >> identical with the IPv4 address anymore but potentially independent=20 >> and learned by the other systems, with ISIS as the distribution mechanis= m? >>=20 >=20 > IPv4 address can remain the same, i.e. IPv4 address used as=20 > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to=20 > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. >=20 >>> But the question is, how does ISIS choose what discriminator to allocat= e? >>=20 >> Maybe a nitpick but ISIS should transport the discriminator value of=20 >> a particular site but should not have knowledge how to choose a=20 >> discriminator. Just another 32bit number for ISIS to send as TLV. >=20 > True. It could be outside of ISIS as well, but some entity will have=20 > to do it. >=20 >>=20 >> Saying this if ISIS finds a conflict in it's database, i.e. two=20 >> identical discriminators from different nodes, then raising an alarm=20 >> would be useful (not necessary though). >=20 > Exactly. BFD won't be able to detect the conflict but BFD client (ISIS=20 > in this case) is in better position to identify the conflict. > Upon conflict, which node need to change then, and how to change w/o=20 > affecting reflector session already bouncing packets back. These sort=20 > of questions will need to be answered, when we (WG) think it's=20 > wanted/needed. >=20 >>=20 >>> 1. One approach would be to simply have operators configure network=20 >>> wide unique 4-byte for each ISIS. >>=20 >> sounds like a working solution to start with. Also it provides a=20 >> simple answer to an area I think is an implementation detail, outside=20 >> BFD or even ISIS protocol specification. >=20 > Good :) >=20 > If there are other agreements to option #1 (config approach) or=20 > arguments against it, I certainly would like to hear. It will help=20 > improve usability of S-BFD out in the wild. >=20 > -Nobo >=20 >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Discriminator should be as much unique as possible in the domain, if=20 >>> not guaranteed unique. >>> This is to ensure reflector session does not respond to falsely=20 >>> self-terminating S-BFD packet. >>>=20 >>> 1. One approach would be to simply have operators configure network=20 >>> wide unique 4-byte for each ISIS. >>>=20 >>> 2. Another approach would be to compute 4-byte from *local stuff*,=20 >>> and come up with a conflict resolution mechanism. >>>=20 >>> My initial thought is that (1) is reasonable for immediate needs. >>> But wanted to check with others on the list. >>>=20 >>> Any comments and/or preferences? >>>=20 >>> -Nobo >>> (as individual contributor) >>>=20 >=20 From nobo@cisco.com Mon Feb 3 05:49: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 955CF1A0215 for ; Mon, 3 Feb 2014 05:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 ZX3DiSEG0DrH for ; Mon, 3 Feb 2014 05:49:31 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id C198B1A0227 for ; Mon, 3 Feb 2014 05:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7691; q=dns/txt; s=iport; t=1391435349; x=1392644949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8mpiie85L4SkM+sCUsUF3zIr+ShVWbkEiQHkCYlEdWU=; b=My/Zak7I9GI+4Na8V5SwPw6fz0nzXHqDw226toO//te1saiQeU01pFWY dcKZKcJTveS92FT4De80HvHABf+DD9dTu9Ztv2vmhATcJTBoBr14pe1ra Xp+6ZFOXtRyuZFR7aIWNKoxvq28BGbE+Wp15p96bwS5SPX/t/TaShRwBB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAM2d71KtJXG8/2dsb2JhbABPCoJrIYEPvgmBCBZ0giUBAQEDATo/BQcEAgEIEQQBAQEKFAkHIREUCQgBAQQBDQUIE4dWAwkIAcMJDYkzF4xzgTorMQcGgx6BFAEDlj6OSoVDgy2CKg X-IronPort-AV: E=Sophos;i="4.95,772,1384300800"; d="scan'208";a="17525324" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 03 Feb 2014 13:49:08 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s13Dn8pp019469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 13:49:08 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, 3 Feb 2014 07:49:08 -0600 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Marc Binderberger Subject: RE: S-BFD discriminator for ISIS? Thread-Topic: S-BFD discriminator for ISIS? Thread-Index: Ac8e2U/W07BIR+TVQ0y8Kru37a/QEgAR2+2AAAuHwpAAACAzAAAjgzMAAEFIapA= Date: Mon, 3 Feb 2014 13:49:07 +0000 Message-ID: References: <20140131173933034563.54c393e9@sniff.de> <20140131231318767731.e3c8f834@sniff.de> <7347100B5761DC41A166AC17F22DF1121B75D82C@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B75D82C@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.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" , "Sam Aldrin \(sam.aldrin@gmail.com\)" 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, 03 Feb 2014 13:49:33 -0000 Hi Greg, Marc, Sam, et al, I'm starting to agree that explicit mapping and advertisement of NE and dis= criminators is the right way to go. > And if we find that Seamless BFD is useful in Segment Routing network, > then label advertised by IGP can be viewed as implicit discriminator. If = that > is the case, why not to use extensions proposed for SR in SPRING WG, > perhaps with extra twists, to advertise discriminators for S-BFD. What do > you think? If we go with explicit mapping and advertisement of NE and discriminators, = then IGPs are already advertising discriminators, even in SR network. We ca= n use what's already advertised (i.e. NE to discriminator mapping), as oppo= sed to using label/index as discriminators. Perhaps there'll be some additi= ons specific to SR that'll require us to keep bfd-seamless-sr draft alive, = but bigger fish really becomes publishing IGP extensions to carry BFD discr= iminators. Going with this approach, however, does leave a hole in the scenario where = there are no signaling that can carry discriminators. But number of such sc= enarios is probably much smaller than what we can address with NE/discrimin= ator mapping/advertisement. Let's cross the bridge when we get there. -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Saturday, February 01, 2014 7:10 PM > To: Marc Binderberger; Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org; Sam Aldrin (sam.aldrin@gmail.com) > Subject: RE: S-BFD discriminator for ISIS? >=20 > Hi Marc, Nobo, et. al, > glad to have our discussion back. > I'm all for explicit mapping of NE and discriminators. Using IGP lets us = not > only advertise the discriminator but to withdraw the advertisement at wil= l. > With this approach we may manage to keep BFD and S-BFD discriminator > spaces as one, if we find this goal worth pursuing. > And if we find that Seamless BFD is useful in Segment Routing network, > then label advertised by IGP can be viewed as implicit discriminator. If = that > is the case, why not to use extensions proposed for SR in SPRING WG, > perhaps with extra twists, to advertise discriminators for S-BFD. What do > you think? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Friday, January 31, 2014 11:13 PM > To: Nobo Akiya > Cc: rtg-bfd@ietf.org; Sam Aldrin (sam.aldrin@gmail.com) > Subject: RE: S-BFD discriminator for ISIS? >=20 > Hi Nobo, >=20 > > IPv4 address can remain the same, i.e. IPv4 address used as > > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to > > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. >=20 > hmm. You know from our private discussions that I personally think using > IPv4 addresses as discriminator values is, well, not optimal ;-) >=20 > But before explaining this I would say having one mechanism that "covers = it > all" would be a good thing (tm). Like ISIS covers both IPv4 and IPv6, you > don't have to learn a new mechanism. >=20 > So for a network node you would have it's labels and it's discriminator > value (or values?). For simplicity of this discussion lets say assigned b= y an > administrator with a full overview. Then ISIS distributes this. > Some node X wants to BFD-test the path to node Y? Okay, X has learned via > ISIS the necessary information. >=20 > Generic, I haven't talked anywhere about IPv4 or IPv6 :-) >=20 > Back to my "not optimal": so far a node was free to choose what > discriminator values it wants to use. The BFD peer (in RFC5880 sense) jus= t > copied the value back. This freedom of choice has been used to simplify > implementations, e.g. only using the lower bits to index into arrays or > match in TCAMs. And so far all the standards have abide and not imposed a > condition or structure on the discriminator values (except zero). >=20 > Sure, you can get the Address-as-discriminator scheme working. But why > taking this freedom for the implementor away? >=20 > But I wasn't in Vancouver and may have missed something :-) >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Sat, 1 Feb 2014 02:31:31 +0000, Nobo Akiya (nobo) wrote: > > Thanks for comments Sam and Marc. > > > > [combining reply in one] > > > > [Sam wrote] > >> Option #1 is a reasonable approach and is the understanding for the > >> solutions discussed thus far. Eventually support for #2 should be > >> there as well, but that does take time and discussions to come to a > >> common solution. > > > > That's good to hear that you also think option #1 is reasonable. More > > comments about option #2 below. > > > > [Marc wrote] > >>> So I had a chat with ISIS person. > >>> > >>> Obviously we need ISIS to advertise S-BFD discriminator. > >> > >> ... but you mean the discriminator of the reflecting node is not > >> identical with the IPv4 address anymore but potentially independent > >> and learned by the other systems, with ISIS as the distribution > mechanism? > >> > > > > IPv4 address can remain the same, i.e. IPv4 address used as > > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to > > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. > > > >>> But the question is, how does ISIS choose what discriminator to > allocate? > >> > >> Maybe a nitpick but ISIS should transport the discriminator value of > >> a particular site but should not have knowledge how to choose a > >> discriminator. Just another 32bit number for ISIS to send as TLV. > > > > True. It could be outside of ISIS as well, but some entity will have > > to do it. > > > >> > >> Saying this if ISIS finds a conflict in it's database, i.e. two > >> identical discriminators from different nodes, then raising an alarm > >> would be useful (not necessary though). > > > > Exactly. BFD won't be able to detect the conflict but BFD client (ISIS > > in this case) is in better position to identify the conflict. > > Upon conflict, which node need to change then, and how to change w/o > > affecting reflector session already bouncing packets back. These sort > > of questions will need to be answered, when we (WG) think it's > > wanted/needed. > > > >> > >>> 1. One approach would be to simply have operators configure network > >>> wide unique 4-byte for each ISIS. > >> > >> sounds like a working solution to start with. Also it provides a > >> simple answer to an area I think is an implementation detail, outside > >> BFD or even ISIS protocol specification. > > > > Good :) > > > > If there are other agreements to option #1 (config approach) or > > arguments against it, I certainly would like to hear. It will help > > improve usability of S-BFD out in the wild. > > > > -Nobo > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >>> > >>> Discriminator should be as much unique as possible in the domain, if > >>> not guaranteed unique. > >>> This is to ensure reflector session does not respond to falsely > >>> self-terminating S-BFD packet. > >>> > >>> 1. One approach would be to simply have operators configure network > >>> wide unique 4-byte for each ISIS. > >>> > >>> 2. Another approach would be to compute 4-byte from *local stuff*, > >>> and come up with a conflict resolution mechanism. > >>> > >>> My initial thought is that (1) is reasonable for immediate needs. > >>> But wanted to check with others on the list. > >>> > >>> Any comments and/or preferences? > >>> > >>> -Nobo > >>> (as individual contributor) > >>> > > From jhaas@slice.pfrc.org Wed Feb 5 11:34: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 0F9EC1A0138 for ; Wed, 5 Feb 2014 11:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, 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 Ftw5CkbMf9Qu for ; Wed, 5 Feb 2014 11:34:04 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 93A3E1A0122 for ; Wed, 5 Feb 2014 11:34:04 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E0717C147; Wed, 5 Feb 2014 14:34:03 -0500 (EST) Date: Wed, 5 Feb 2014 14:34:03 -0500 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: S-BFD discriminator for ISIS? Message-ID: <20140205193403.GP8022@pfrc> References: <20140131173933034563.54c393e9@sniff.de> <20140131231318767731.e3c8f834@sniff.de> <7347100B5761DC41A166AC17F22DF1121B75D82C@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B75D82C@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" , "Sam Aldrin \(sam.aldrin@gmail.com\)" 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, 05 Feb 2014 19:34:06 -0000 On Sun, Feb 02, 2014 at 12:10:08AM +0000, Gregory Mirsky wrote: > Hi Marc, Nobo, et. al, > glad to have our discussion back. > I'm all for explicit mapping of NE and discriminators. Using IGP lets us > not only advertise the discriminator but to withdraw the advertisement at > will. With this approach we may manage to keep BFD and S-BFD discriminator > spaces as one, if we find this goal worth pursuing. I'm definitely not a fan of just grabbing IP addresses and using them. Thus I'm happy to see discussion moving toward other options. > And if we find that Seamless BFD is useful in Segment Routing network, > then label advertised by IGP can be viewed as implicit discriminator. If > that is the case, why not to use extensions proposed for SR in SPRING WG, > perhaps with extra twists, to advertise discriminators for S-BFD. What do > you think? I'd be very cautious about this as well for several reasons: - Labels have a much smaller space than a BFD Discriminator. - Labels can change for whatever reason and putting additional couplings on them outside of the MPLS forwarding plane is probably not the best idea. - IGPs will take time to converge. Frequent changes tend to get throttled. Relying on any mechanism that causes numbers to be negotiated on remote nodes via iterations of IGP convergence is not pretty. -- Jeff From jhaas@slice.pfrc.org Wed Feb 5 11:44: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 7AD621A0117 for ; Wed, 5 Feb 2014 11:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, 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 yx7YOq4vQlAX for ; Wed, 5 Feb 2014 11:44:50 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 31B9A1A00E2 for ; Wed, 5 Feb 2014 11:44:50 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 71C7CC147; Wed, 5 Feb 2014 14:44:49 -0500 (EST) Date: Wed, 5 Feb 2014 14:44:49 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: State of BFD, pre-IETF 89 Message-ID: <20140205194449.GQ8022@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 05 Feb 2014 19:44:51 -0000 BFD is not meeting at IETF 89, however many people working on BFD things will be there. This mail summarizes the rough status of the working group. Hopefully this will serve to get people motivated to look at open work items. * BFD base MIB and TC-MIB. Waiting on some last minute edits by Tom Nadeau before being handed back to the MIB doctors, then the RFC Editor queue (hopefully). * BFD on LAG: In RFC Editors queue. * BFD MPLS MIB: Quiet, could use more eyes. Could we get volunteers? * BFD Multipoint: Quiet, stable, one partial implementation. Need a meeting with the authors to see about simplifying the doc. * BFD Crypto and Generic Auth documents: Implementation limbo. * BFD Intervals: Adopted as a WG item, still no draft submitted as draft-ietf-bfd. Hey, Marc! * S-BFD: Lots of documents, a tiny bit of list discussion. In desperate need of a use-case document to proceed. -- Jeff From aldrin.ietf@gmail.com Wed Feb 5 11:49:04 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 A1DBC1A0117 for ; Wed, 5 Feb 2014 11:49:04 -0800 (PST) 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 5AGis-7qdYPY for ; Wed, 5 Feb 2014 11:49:03 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D61A00E2 for ; Wed, 5 Feb 2014 11:49:02 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id n7so1478439qcx.30 for ; Wed, 05 Feb 2014 11:49:01 -0800 (PST) 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=WTrPaHDbzsbljSlft+Jm889lpe9ETf/M4e/aoJ8uTZA=; b=UcS37S7V3Tgr3OJIwJXQCqx96spsoacbDYIzgJsUKFpyVohCFRXp21NY7ikzoBzgT2 FaXGlddxDI4GSUwRxQXoPq8F6Ou7OM2A9cCxaF7uKKaLM3xE446XnPq7Xbtc5KDidCWG V+zv2KZKClUIcTo4kU4WO0ZK3IwoKX7FxmNEdB+uzM0Y5RqshYfWxGqR2ngOw8HPKnD+ K5YX1MAFgMsLbA8f04Fk9ierWgOgRSCQnWXiYXkpUUjVrEMKb8iPOp2U9aSVbXF9bT9p G+tFTJejZpy4NSgINnlLXx4A+hTJ86iMpMtqR8P2H/9qcF7Of++9B1K80whLA++PXSeS E88w== MIME-Version: 1.0 X-Received: by 10.224.120.199 with SMTP id e7mr5738576qar.47.1391629731853; Wed, 05 Feb 2014 11:48:51 -0800 (PST) Received: by 10.96.89.194 with HTTP; Wed, 5 Feb 2014 11:48:51 -0800 (PST) In-Reply-To: <20140205194449.GQ8022@pfrc> References: <20140205194449.GQ8022@pfrc> Date: Wed, 5 Feb 2014 11:48:51 -0800 Message-ID: Subject: Re: State of BFD, pre-IETF 89 From: Sam Aldrin To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c3329cd3793104f1ae0ba9 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: Wed, 05 Feb 2014 19:49:04 -0000 --001a11c3329cd3793104f1ae0ba9 Content-Type: text/plain; charset=ISO-8859-1 Hi Jeff, Comments inline. On Wed, Feb 5, 2014 at 11:44 AM, Jeffrey Haas wrote: > BFD is not meeting at IETF 89, however many people working on BFD things > will be there. This mail summarizes the rough status of the working group. > Hopefully this will serve to get people motivated to look at open work > items. > > * BFD base MIB and TC-MIB. Waiting on some last minute edits by Tom Nadeau > before being handed back to the MIB doctors, then the RFC Editor queue > (hopefully). > * BFD on LAG: In RFC Editors queue. > * BFD MPLS MIB: Quiet, could use more eyes. Could we get volunteers? > %sam - We will have to revive it. Hopefully we could address any comments remaining. Will let you know of latest status, soon. * BFD Multipoint: Quiet, stable, one partial implementation. Need a meeting > with the authors to see about simplifying the doc. > * BFD Crypto and Generic Auth documents: Implementation limbo. > * BFD Intervals: Adopted as a WG item, still no draft submitted as > draft-ietf-bfd. Hey, Marc! > * S-BFD: Lots of documents, a tiny bit of list discussion. In desperate > need > of a use-case document to proceed. > %sam - I have published the new use case document, yesterday. WG could take a look at it and provide comments/feedback about it. -sam > > -- Jeff > --001a11c3329cd3793104f1ae0ba9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Comments inline.


On Wed, Feb 5, 2014 at = 11:44 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
BFD is not meeting at IETF 89, however many = people working on BFD things
will be there. =A0This mail summarizes the rough status of the working grou= p.
Hopefully this will serve to get people motivated to look at open work
items.

* BFD base MIB and TC-MIB. =A0Waiting on some last minute edits by Tom Nade= au
=A0 before being handed back to the MIB doctors, then the RFC Editor queue<= br> =A0 (hopefully).
* BFD on LAG: In RFC Editors queue.
* BFD MPLS MIB: Quiet, could use more eyes. =A0Could we get volunteers?
=
%sam - We will have to revive it. Hopefully we could addr= ess any comments remaining. Will let you know of latest status, soon.

* BFD Multipoint: Quiet, stable, one partial implementation. =A0Need a meet= ing
=A0 with the authors to see about simplifying the doc.
* BFD Crypto and Generic Auth documents: Implementation limbo.
* BFD Intervals: Adopted as a WG item, still no draft submitted as
=A0 draft-ietf-bfd. =A0Hey, Marc!
* S-BFD: Lots of documents, a tiny bit of list discussion. In desperate nee= d
=A0 of a use-case document to proceed.
%sam - I have p= ublished the new use case document, yesterday. WG could take a look at it a= nd provide comments/feedback about it.

-sam

-- Jeff

--001a11c3329cd3793104f1ae0ba9-- From jhaas@slice.pfrc.org Wed Feb 5 13:16: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 7802F1A021E for ; Wed, 5 Feb 2014 13:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, 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 tcUglZRHwE3K for ; Wed, 5 Feb 2014 13:16:41 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8785D1A014C for ; Wed, 5 Feb 2014 13:16:41 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id DB92FC147; Wed, 5 Feb 2014 16:16:40 -0500 (EST) Date: Wed, 5 Feb 2014 16:16:40 -0500 From: Jeffrey Haas To: Sam Aldrin Subject: Re: State of BFD, pre-IETF 89 Message-ID: <20140205211640.GB19379@pfrc> References: <20140205194449.GQ8022@pfrc> 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) 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: Wed, 05 Feb 2014 21:16:42 -0000 On Wed, Feb 05, 2014 at 11:48:51AM -0800, Sam Aldrin wrote: > > * S-BFD: Lots of documents, a tiny bit of list discussion. In desperate > > need > > of a use-case document to proceed. > > > %sam - I have published the new use case document, yesterday. WG could take > a look at it and provide comments/feedback about it. I'm presuming it's draft-aldrin-bfd-seamless-use-case? If so, I'd suggest spinning a separate thread to push discussion. (I usually start by forwarding the I-D announcement to the WG.) -- Jeff From marc@sniff.de Wed Feb 5 13:59:04 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 C03FB1A0209 for ; Wed, 5 Feb 2014 13:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535] 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 pGWtsbcvlKt8 for ; Wed, 5 Feb 2014 13:59:02 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB711A012F for ; Wed, 5 Feb 2014 13:59:02 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 90E932AA0F; Wed, 5 Feb 2014 21:59:00 +0000 (GMT) Date: Wed, 5 Feb 2014 13:58:59 -0800 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140205135859323109.8656e7f0@sniff.de> In-Reply-To: <20140205194449.GQ8022@pfrc> References: <20140205194449.GQ8022@pfrc> Subject: Re: State of BFD, pre-IETF 89 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 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: Wed, 05 Feb 2014 21:59:05 -0000 Hello Jeff, * BFD Intervals: Adopted as a WG item, still no draft submitted as draft-ietf-bfd. Hey, Marc! I do feel guilty and should have done more work last year already, I know :-) But I moved across the pond, joined a new team, had been blocked. Good news is I've sent out emails to other people (unicast) as well as company-internal. Collecting feedback, then will produce an update. Regards, Marc On Wed, 5 Feb 2014 14:44:49 -0500, Jeffrey Haas wrote: > BFD is not meeting at IETF 89, however many people working on BFD things > will be there. This mail summarizes the rough status of the working group. > Hopefully this will serve to get people motivated to look at open work > items. > > * BFD base MIB and TC-MIB. Waiting on some last minute edits by Tom Nadeau > before being handed back to the MIB doctors, then the RFC Editor queue > (hopefully). > * BFD on LAG: In RFC Editors queue. > * BFD MPLS MIB: Quiet, could use more eyes. Could we get volunteers? > * BFD Multipoint: Quiet, stable, one partial implementation. Need a meeting > with the authors to see about simplifying the doc. > * BFD Crypto and Generic Auth documents: Implementation limbo. > * BFD Intervals: Adopted as a WG item, still no draft submitted as > draft-ietf-bfd. Hey, Marc! > * S-BFD: Lots of documents, a tiny bit of list discussion. In desperate need > of a use-case document to proceed. > > -- Jeff > From venggovi@cisco.com Wed Feb 5 20:32: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 469261A029D for ; Wed, 5 Feb 2014 20:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 iZzdIvV11dTW for ; Wed, 5 Feb 2014 20:32:30 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B90BA1A022B for ; Wed, 5 Feb 2014 20:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1420; q=dns/txt; s=iport; t=1391661150; x=1392870750; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fKY9Hrb4o3yVgaJ35lx5R4M2mxWblbiwdwNUaOY0WJo=; b=mD/motqGCIpRYekcud37/UITtgpTY/pWXv4LoJUpspdNE7MbkMtvhxRh V0ETqTSoAkSfBSU+6y2U/uljr19TWKhkjY23IBe5yB2AqDZ7snYuwQp3G qyiD7+rapoH+xpKeOTWDITfrAcDiT3DekbUsk3zdBJVL73nLP7fBmtTzx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJ0P81KtJV2a/2dsb2JhbABZgwyBD75ngQcWdIIlAQEBBDo/DAQCAQgOAwQBAQsUCQcyFAkIAgQBDQUIh33ObBeOJAEBHjEHBoMegRQBA6pMgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,791,1384300800"; d="scan'208";a="302227068" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 06 Feb 2014 04:32:30 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s164WTHg009361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 04:32:29 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.77]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 22:32:29 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: State of BFD, pre-IETF 89 Thread-Topic: State of BFD, pre-IETF 89 Thread-Index: AQHPIqrLsghSWyhbWkq4yaQ55WmD3ZqnoltQ Date: Thu, 6 Feb 2014 04:32:28 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D33947E08@xmb-rcd-x15.cisco.com> References: <20140205194449.GQ8022@pfrc> In-Reply-To: <20140205194449.GQ8022@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 06 Feb 2014 04:32:32 -0000 Jeff, Permit me to add one more to the list: draft-vgovindan-l2vpn-evpn-bfd: This was presented at IETF-88 (L2VPN WG). S= ome feedback has been received and the next revision will be submitted befo= re the IETF-89 deadline. Comments are welcome. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Thursday, February 06, 2014 1:15 AM To: rtg-bfd@ietf.org Subject: State of BFD, pre-IETF 89 BFD is not meeting at IETF 89, however many people working on BFD things wi= ll be there. This mail summarizes the rough status of the working group. Hopefully this will serve to get people motivated to look at open work item= s. * BFD base MIB and TC-MIB. Waiting on some last minute edits by Tom Nadeau before being handed back to the MIB doctors, then the RFC Editor queue (hopefully). * BFD on LAG: In RFC Editors queue. * BFD MPLS MIB: Quiet, could use more eyes. Could we get volunteers? * BFD Multipoint: Quiet, stable, one partial implementation. Need a meetin= g with the authors to see about simplifying the doc. * BFD Crypto and Generic Auth documents: Implementation limbo. * BFD Intervals: Adopted as a WG item, still no draft submitted as draft-ietf-bfd. Hey, Marc!=20 * S-BFD: Lots of documents, a tiny bit of list discussion. In desperate nee= d of a use-case document to proceed. -- Jeff From manav.bhatia@alcatel-lucent.com Tue Feb 11 07:29: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 9B6101A0547; Tue, 11 Feb 2014 07:29:26 -0800 (PST) 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 VOpcgmDM0KpK; Tue, 11 Feb 2014 07:29:25 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE51A050E; Tue, 11 Feb 2014 07:29:24 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1BFTNNJ010126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 09:29:24 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s1BFTNLx026029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 10:29:23 -0500 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 11 Feb 2014 10:29:23 -0500 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Tue, 11 Feb 2014 23:29:02 +0800 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Subject: draft-ietf-karp-bfd-analysis-01 Thread-Topic: draft-ietf-karp-bfd-analysis-01 Thread-Index: Ac8nPfvHS7qvGuoGRoqR9yH1fZZ/Vg== Date: Tue, 11 Feb 2014 15:29:01 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E587804@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "karp@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, 11 Feb 2014 15:29:26 -0000 Hi, Can the BFD WG members review draft-ietf-karp-bfd-analysis-01?=20 We (the authors) think we're done with the gap analysis.=20 Would be great to hear from the WG on whether they think we've accurately c= aptured the gaps and if they're gaps in our understanding of the gaps. Cheers, Manav From jhaas@slice.pfrc.org Tue Feb 11 07:43: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 02C731A05C8; Tue, 11 Feb 2014 07:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, 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 7248dvwQSELT; Tue, 11 Feb 2014 07:43:42 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 863841A05D5; Tue, 11 Feb 2014 07:43:42 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id ED563C2C7; Tue, 11 Feb 2014 10:43:41 -0500 (EST) Date: Tue, 11 Feb 2014 10:43:41 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: draft-ietf-karp-bfd-analysis-01 Message-ID: <20140211154341.GH21565@pfrc> References: <20211F91F544D247976D84C5D778A4C32E587804@SG70YWXCHMBA05.zap.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211F91F544D247976D84C5D778A4C32E587804@SG70YWXCHMBA05.zap.alcatel-lucent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "rtg-bfd@ietf.org" , "karp@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, 11 Feb 2014 15:43:44 -0000 Manav, On Tue, Feb 11, 2014 at 03:29:01PM +0000, Bhatia, Manav (Manav) wrote: > Can the BFD WG members review draft-ietf-karp-bfd-analysis-01? More reviewers would be great. > We (the authors) think we're done with the gap analysis. > > Would be great to hear from the WG on whether they think we've accurately captured the gaps and if they're gaps in our understanding of the gaps. My impression on my last review (comments should be in the archive) was that the existing WG documents covering the generic crypto extensions and the SHA-2 extensions addressed the gaps. Is that correct? -- Jeff From manav.bhatia@alcatel-lucent.com Tue Feb 11 08:18: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 ADA061A05E5; Tue, 11 Feb 2014 08:18:43 -0800 (PST) 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 Hmi_gtJX0ncF; Tue, 11 Feb 2014 08:18:41 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3641A01A8; Tue, 11 Feb 2014 08:18:41 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1BGIctX000581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 10:18:39 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s1BGIc00008730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 11:18:38 -0500 Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 11 Feb 2014 11:18:38 -0500 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.02.0328.009; Wed, 12 Feb 2014 00:18:35 +0800 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Subject: RE: draft-ietf-karp-bfd-analysis-01 Thread-Topic: draft-ietf-karp-bfd-analysis-01 Thread-Index: Ac8nPfvHS7qvGuoGRoqR9yH1fZZ/Vv//ff+A//9yG+A= Date: Tue, 11 Feb 2014 16:18:35 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5879B6@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20211F91F544D247976D84C5D778A4C32E587804@SG70YWXCHMBA05.zap.alcatel-lucent.com> <20140211154341.GH21565@pfrc> In-Reply-To: <20140211154341.GH21565@pfrc> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtg-bfd@ietf.org" , "karp@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, 11 Feb 2014 16:18:43 -0000 Hi Jeff, > My impression on my last review (comments should be in the archive) was > that the existing WG documents covering the generic crypto extensions > and the > SHA-2 extensions addressed the gaps. Is that correct? Yes that's correct. The current BFD WG security drafts fix all the issues i= dentified in this gap analysis document. We do provide a recommendation though in Sec 6 about using GMAC instead of = HMAC-SHA-x, that's not covered in SHA-2 extensions WG doc. I guess we're then pretty much good to go from the BFD side of the world fo= r this gap analysis. Cheers, Manav >=20 > -- Jeff From wwwrun@rfc-editor.org Wed Feb 12 20:50:10 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 36A101A0100; Wed, 12 Feb 2014 20:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 8SEaK1nDqAAf; Wed, 12 Feb 2014 20:50:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEE61A0101; Wed, 12 Feb 2014 20:49:51 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 85C117FC394; Wed, 12 Feb 2014 20:49:50 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces From: rfc-editor@rfc-editor.org Message-Id: <20140213044950.85C117FC394@rfc-editor.org> Date: Wed, 12 Feb 2014 20:49:50 -0800 (PST) X-Mailman-Approved-At: Thu, 13 Feb 2014 07:35:26 -0800 Cc: drafts-update-ref@iana.org, rtg-bfd@ietf.org, rfc-editor@rfc-editor.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, 13 Feb 2014 04:50:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7130 Title: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Author: M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed. Status: Standards Track Stream: IETF Date: February 2014 Mailbox: manav.bhatia@alcatel-lucent.com, mach@huawei.com, sboutros@cisco.com, mbinderb@cisco.com, jhaas@juniper.net Pages: 11 Characters: 21291 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-bfd-on-lags-04.txt URL: http://www.rfc-editor.org/rfc/rfc7130.txt This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding. This document is a product of the Bidirectional Forwarding Detection Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jhaas@slice.pfrc.org Thu Feb 13 07:39: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 B2ED31A02E9 for ; Thu, 13 Feb 2014 07:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, 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 MPuIXhwTpt61 for ; Thu, 13 Feb 2014 07:39:20 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 758BA1A02E1 for ; Thu, 13 Feb 2014 07:39:20 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 57A65C313; Thu, 13 Feb 2014 10:39:19 -0500 (EST) Date: Thu, 13 Feb 2014 10:39:19 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Message-ID: <20140213153919.GP12880@pfrc> References: <20140213044950.85C117FC394@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140213044950.85C117FC394@rfc-editor.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 13 Feb 2014 15:39:22 -0000 Congratulations to the working group and the editors of BFD on LAGs for RFC 7130! In roughly two years, we've gone from initial draft, working group discussion, implementation, interop and RFC publication. -- Jeff On Wed, Feb 12, 2014 at 08:49:50PM -0800, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7130 > > Title: Bidirectional Forwarding Detection (BFD) on > Link Aggregation Group (LAG) Interfaces > Author: M. Bhatia, Ed., > M. Chen, Ed., > S. Boutros, Ed., > M. Binderberger, Ed., > J. Haas, Ed. > Status: Standards Track > Stream: IETF > Date: February 2014 > Mailbox: manav.bhatia@alcatel-lucent.com, > mach@huawei.com, > sboutros@cisco.com, > mbinderb@cisco.com, > jhaas@juniper.net > Pages: 11 > Characters: 21291 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-bfd-on-lags-04.txt > > URL: http://www.rfc-editor.org/rfc/rfc7130.txt -- Jeff From jeff.tantsura@ericsson.com Thu Feb 13 07:40: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 9B66B1A01F7 for ; Thu, 13 Feb 2014 07:40:58 -0800 (PST) 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 Z5sp-rb6m8ye for ; Thu, 13 Feb 2014 07:40:56 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 381C81A0273 for ; Thu, 13 Feb 2014 07:40:54 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-98-52fce781cb71 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EC.32.12743.187ECF25; Thu, 13 Feb 2014 16:40:49 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 10:40:52 -0500 From: Jeff Tantsura To: Jeffrey Haas Subject: Re: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Thread-Topic: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Thread-Index: AQHPKNE9jlQWSoF38U+yF9gz0+d/u5qzpbOA//+snuc= Date: Thu, 13 Feb 2014 15:40:52 +0000 Message-ID: <0A72F8F0-3BD0-49FB-BCE0-2F82FFDBD6E9@ericsson.com> References: <20140213044950.85C117FC394@rfc-editor.org>, <20140213153919.GP12880@pfrc> In-Reply-To: <20140213153919.GP12880@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+NgFjrILMWRmVeSWpSXmKPExsUyuXRPiG7j8z9BBu+PmFrsP/iW1eLzn22M DkweS5b8ZPK43LuVNYApissmJTUnsyy1SN8ugStjwc0+xoK73BXbn61iamC8wt7FyMEhIWAi ceMVWxcjJ5ApJnHh3nogm4tDSOAIo8TdqT3MEM5yRoll868zg1SxCRhI/P92nAXEFhFQlJj/ vxOsm1lAU6LpxGd2EFtYIE9ie18zG0RNvsSr+1eg6q0kVndMA6thEVCVeLyylRHE5hWwl7jb +RCsXkggVOJV6wGwek4BLYnTKxeB1TMCXff91BomiF3iEreezGeCuFpAYsme88wQtqjEy8f/ WCFqdCQW7P4EdZu2xLKFr5khdglKnJz5hGUCo+gsJKNmIWmZhaRlFpKWBYwsqxg5SotTy3LT jQw2MQKj4ZgEm+4Oxj0vLQ8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB seypUczmhPXBjJZ5OWlXRVQrk9WvfHiYI6fuxqYg9ECm20Z4T2qtb8CtjYeVD/ksm3GO8bVP o4iIVlVQkvjx3h1ffx7NPLTtKfPbetdlAR1NGWcFspYveucrNfWiqn3tnCL+8KyaG5qbzpcx vf00L1dF0sqQpdjHVeO9vnH5Tgf+WIZ6fQMlluKMREMt5qLiRAA4G2FwVAIAAA== 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, 13 Feb 2014 15:40:58 -0000 Congrats, well done! Regards, Jeff > On Feb 13, 2014, at 4:39 PM, "Jeffrey Haas" wrote: >=20 > Congratulations to the working group and the editors of BFD on LAGs for=20 > RFC 7130! >=20 > In roughly two years, we've gone from initial draft, working group > discussion, implementation, interop and RFC publication. >=20 > -- Jeff >=20 >=20 >> On Wed, Feb 12, 2014 at 08:49:50PM -0800, rfc-editor@rfc-editor.org wrot= e: >> A new Request for Comments is now available in online RFC libraries. >>=20 >>=20 >> RFC 7130 >>=20 >> Title: Bidirectional Forwarding Detection (BFD) on=20 >> Link Aggregation Group (LAG) Interfaces=20 >> Author: M. Bhatia, Ed., >> M. Chen, Ed., >> S. Boutros, Ed., >> M. Binderberger, Ed., >> J. Haas, Ed. >> Status: Standards Track >> Stream: IETF >> Date: February 2014 >> Mailbox: manav.bhatia@alcatel-lucent.com,=20 >> mach@huawei.com,=20 >> sboutros@cisco.com, >> mbinderb@cisco.com,=20 >> jhaas@juniper.net >> Pages: 11 >> Characters: 21291 >> Updates/Obsoletes/SeeAlso: None >>=20 >> I-D Tag: draft-ietf-bfd-on-lags-04.txt >>=20 >> URL: http://www.rfc-editor.org/rfc/rfc7130.txt >=20 >=20 > -- Jeff >=20 From nobody Thu Feb 13 11:28: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 D5DC11A0425 for ; Thu, 13 Feb 2014 11:28:34 -0800 (PST) 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, 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 dAKHIs7dHW2o for ; Thu, 13 Feb 2014 11:28:29 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 022941A0428 for ; Thu, 13 Feb 2014 11:28:28 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DJSQr3015448 for ; Thu, 13 Feb 2014 19:28:27 GMT Received: from 950129200 (16.17.90.92.rev.sfr.net [92.90.17.16]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DJSOSA015432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Feb 2014 19:28:26 GMT From: "Adrian Farrel" To: References: <20140213044950.85C117FC394@rfc-editor.org> <20140213153919.GP12880@pfrc> In-Reply-To: <20140213153919.GP12880@pfrc> Subject: RE: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Date: Thu, 13 Feb 2014 19:28:23 -0000 Message-ID: <0ad401cf28f1$c3a7d7e0$4af787a0$@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: AQIDJehehBITs6qVK1BSoFy/xIlmlAIYeRRsmjrSmcA= Content-Language: en-gb X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/azOOwIkgI5AU-T60TwMqaNxoZ_4 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, 13 Feb 2014 19:28:35 -0000 Yes, exactly! Consider yourselves poster children in the campaign to persuade people that IETF standardisation takes a long time. That you achieved multiple interoperable implementations and resolved some wrinkles in the spec is really proof that the IETF model works. Thanks to all concerned. (and you thought the BFD working group was a sleepy backwater :-) Adrian > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: 13 February 2014 15:39 > To: rtg-bfd@ietf.org > Subject: Re: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link > Aggregation Group (LAG) Interfaces > > Congratulations to the working group and the editors of BFD on LAGs for > RFC 7130! > > In roughly two years, we've gone from initial draft, working group > discussion, implementation, interop and RFC publication. > > -- Jeff > > > On Wed, Feb 12, 2014 at 08:49:50PM -0800, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 7130 > > > > Title: Bidirectional Forwarding Detection (BFD) on > > Link Aggregation Group (LAG) Interfaces > > Author: M. Bhatia, Ed., > > M. Chen, Ed., > > S. Boutros, Ed., > > M. Binderberger, Ed., > > J. Haas, Ed. > > Status: Standards Track > > Stream: IETF > > Date: February 2014 > > Mailbox: manav.bhatia@alcatel-lucent.com, > > mach@huawei.com, > > sboutros@cisco.com, > > mbinderb@cisco.com, > > jhaas@juniper.net > > Pages: 11 > > Characters: 21291 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-bfd-on-lags-04.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc7130.txt > > > -- Jeff From nobody Thu Feb 13 11:35: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 D33A61A0417 for ; Thu, 13 Feb 2014 11:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] 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 9wYTXlvjA6MR for ; Thu, 13 Feb 2014 11:35:55 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BE1A03FA for ; Thu, 13 Feb 2014 11:35:53 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DJZpou013366 for ; Thu, 13 Feb 2014 19:35:51 GMT Received: from 950129200 (16.17.90.92.rev.sfr.net [92.90.17.16]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s1DJZnTQ013358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Feb 2014 19:35:50 GMT From: "Adrian Farrel" To: Subject: RE: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Date: Thu, 13 Feb 2014 19:35:47 -0000 Message-ID: <0add01cf28f2$cc490d50$64db27f0$@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: Ac8o8sjZsSfDLmQNSky2ngnvskD5Lg== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XASeDm5Hal5p9pzXYhT9sHPAW3I 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, 13 Feb 2014 19:35:57 -0000 Oh bother! Insert the words "does not" at some appropriate place. Adrian > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 13 February 2014 19:28 > To: rtg-bfd@ietf.org > Subject: RE: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link > Aggregation Group (LAG) Interfaces > > Yes, exactly! > Consider yourselves poster children in the campaign to persuade people that IETF > standardisation takes a long time. > That you achieved multiple interoperable implementations and resolved some > wrinkles in the spec is really proof that the IETF model works. > Thanks to all concerned. > > (and you thought the BFD working group was a sleepy backwater :-) > > Adrian > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > > Sent: 13 February 2014 15:39 > > To: rtg-bfd@ietf.org > > Subject: Re: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link > > Aggregation Group (LAG) Interfaces > > > > Congratulations to the working group and the editors of BFD on LAGs for > > RFC 7130! > > > > In roughly two years, we've gone from initial draft, working group > > discussion, implementation, interop and RFC publication. > > > > -- Jeff > > > > > > On Wed, Feb 12, 2014 at 08:49:50PM -0800, rfc-editor@rfc-editor.org wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > > > > > > RFC 7130 > > > > > > Title: Bidirectional Forwarding Detection (BFD) on > > > Link Aggregation Group (LAG) Interfaces > > > Author: M. Bhatia, Ed., > > > M. Chen, Ed., > > > S. Boutros, Ed., > > > M. Binderberger, Ed., > > > J. Haas, Ed. > > > Status: Standards Track > > > Stream: IETF > > > Date: February 2014 > > > Mailbox: manav.bhatia@alcatel-lucent.com, > > > mach@huawei.com, > > > sboutros@cisco.com, > > > mbinderb@cisco.com, > > > jhaas@juniper.net > > > Pages: 11 > > > Characters: 21291 > > > Updates/Obsoletes/SeeAlso: None > > > > > > I-D Tag: draft-ietf-bfd-on-lags-04.txt > > > > > > URL: http://www.rfc-editor.org/rfc/rfc7130.txt > > > > > > -- Jeff From nobody Thu Feb 13 11:37: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 8FDFA1A03D0 for ; Thu, 13 Feb 2014 11:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, 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 6mKM_NMlUwlr for ; Thu, 13 Feb 2014 11:37:08 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6331A03FA for ; Thu, 13 Feb 2014 11:37:08 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id DBE0BC2F1; Thu, 13 Feb 2014 14:37:06 -0500 (EST) Date: Thu, 13 Feb 2014 14:37:06 -0500 From: Jeffrey Haas To: Adrian Farrel Subject: Re: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Message-ID: <20140213193706.GC31462@pfrc> References: <0add01cf28f2$cc490d50$64db27f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0add01cf28f2$cc490d50$64db27f0$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jOa1LHCib6x3YzA3ozsqk1FJEJs 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, 13 Feb 2014 19:37:10 -0000 It's fair both ways. We did good for IETF. 2 years for people wanting stuff from IETF still seems slow to them. :-) -- Jeff On Thu, Feb 13, 2014 at 07:35:47PM -0000, Adrian Farrel wrote: > Oh bother! > > Insert the words "does not" at some appropriate place. > > Adrian > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: 13 February 2014 19:28 > > To: rtg-bfd@ietf.org > > Subject: RE: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link > > Aggregation Group (LAG) Interfaces > > > > Yes, exactly! > > Consider yourselves poster children in the campaign to persuade people that > IETF > > standardisation takes a long time. > > That you achieved multiple interoperable implementations and resolved some > > wrinkles in the spec is really proof that the IETF model works. > > Thanks to all concerned. > > > > (and you thought the BFD working group was a sleepy backwater :-) > > > > Adrian > > > > > -----Original Message----- > > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > > > Sent: 13 February 2014 15:39 > > > To: rtg-bfd@ietf.org > > > Subject: Re: RFC 7130 on Bidirectional Forwarding Detection (BFD) on Link > > > Aggregation Group (LAG) Interfaces > > > > > > Congratulations to the working group and the editors of BFD on LAGs for > > > RFC 7130! > > > > > > In roughly two years, we've gone from initial draft, working group > > > discussion, implementation, interop and RFC publication. > > > > > > -- Jeff > > > > > > > > > On Wed, Feb 12, 2014 at 08:49:50PM -0800, rfc-editor@rfc-editor.org wrote: > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > > > > > > > RFC 7130 > > > > > > > > Title: Bidirectional Forwarding Detection (BFD) on > > > > Link Aggregation Group (LAG) Interfaces > > > > Author: M. Bhatia, Ed., > > > > M. Chen, Ed., > > > > S. Boutros, Ed., > > > > M. Binderberger, Ed., > > > > J. Haas, Ed. > > > > Status: Standards Track > > > > Stream: IETF > > > > Date: February 2014 > > > > Mailbox: manav.bhatia@alcatel-lucent.com, > > > > mach@huawei.com, > > > > sboutros@cisco.com, > > > > mbinderb@cisco.com, > > > > jhaas@juniper.net > > > > Pages: 11 > > > > Characters: 21291 > > > > Updates/Obsoletes/SeeAlso: None > > > > > > > > I-D Tag: draft-ietf-bfd-on-lags-04.txt > > > > > > > > URL: http://www.rfc-editor.org/rfc/rfc7130.txt > > > > > > > > > -- Jeff From nobody Fri Feb 14 03:24: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 698351A0221 for ; Fri, 14 Feb 2014 03:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 pbXKvZmTbKSC for ; Fri, 14 Feb 2014 03:24:51 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 74C091A0220 for ; Fri, 14 Feb 2014 03:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2558; q=dns/txt; s=iport; t=1392377090; x=1393586690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RUptQWil2dCT1uq+FXhtJJG8P3Vyy009wUQaqBBZuSY=; b=A5sRdyMLvLJYzLfW7Z1cxDk163FDW/g/uaGRTZ1F77PEn9CxniVDlXcb TQUWWwOTqO0kZesnUSjzYsjW2VloT9HPITawct9+bznCp7CsZ4hfiN/8L hPPBFQ1qmcyHTaeGbedzitYxKqU59QzraFAzZCu6uU4HvmudxDQK9aX2z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFACr8/VKtJXG//2dsb2JhbABZgwY4UQaDArwwGH4WdIIlAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQOBQgBh3wIBaZ0oX4XgSmNHxYbBwaCaTWBFASZXpBxgy2CKg X-IronPort-AV: E=Sophos;i="4.95,844,1384300800"; d="scan'208";a="20442567" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 14 Feb 2014 11:24:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1EBOnbg010768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 11:24:49 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.177]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 05:24:49 -0600 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Topic: New Version Notification for draft-vgovindan-l2vpn-evpn-bfd-01.txt Thread-Index: AQHPKU6nR9GbDMvL1kyrqazOoH9UkZq0m7pA Date: Fri, 14 Feb 2014 11:24:49 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3397E8C3@xmb-rcd-x15.cisco.com> References: <20140214063317.13350.93940.idtracker@ietfa.amsl.com> In-Reply-To: <20140214063317.13350.93940.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.55] 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/pZIPRF6N_6pPT-WqZ8NigxqWqmQ Cc: "Samer Salam \(ssalam\)" , "Ali Sajassi \(sajassi\)" 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, 14 Feb 2014 11:24:53 -0000 SGVsbG8gYWxsLA0KICBGWUksIHRoZSBsYXRlc3QgcmV2aXNpb24gb2YgdGhlIGZvbGxvd2luZyBk cmFmdCBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gdGhlIG1lbWJlcnMgb2YgdGhlIEJGRCBXRyBhcyB3 ZWxsLiANClRoYW5rcw0KUHJhc2FkDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTQsIDIwMTQgMTI6MDMgUE0NClRvOiBTYW1lciBT YWxhbSAoc3NhbGFtKTsgU2FtZXIgU2FsYW0gKHNzYWxhbSk7IFZlbmdhZGEgUHJhc2FkIEdvdmlu ZGFuICh2ZW5nZ292aSk7IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk7IEFsaSBT YWphc3NpIChzYWphc3NpKTsgQWxpIFNhamFzc2kgKHNhamFzc2kpDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0wMS50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4t YmZkLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWZW5nYWRhIFBy YXNhZCBHb3ZpbmRhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 CQlkcmFmdC12Z292aW5kYW4tbDJ2cG4tZXZwbi1iZmQNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlQ cm9hY3RpdmUgZmF1bHQgZGV0ZWN0aW9uIGluIEVWUE4NCkRvY3VtZW50IGRhdGU6CTIwMTQtMDIt MTQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12Z292aW5kYW4t bDJ2cG4tZXZwbi1iZmQtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtdmdvdmluZGFuLWwydnBuLWV2cG4tYmZkLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1l dnBuLWJmZC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LXZnb3ZpbmRhbi1sMnZwbi1ldnBuLWJmZC0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBwcm9hY3RpdmUsIGluLWJhbmQgbmV0d29yayBPQU0gbWVj aGFuaXNtIHRvDQogICBkZXRlY3QgY29ubmVjdGl2aXR5IGZhdWx0cyB0aGF0IGFmZmVjdCB1bmlj YXN0IGFuZCBtdWx0aS1kZXN0aW5hdGlvbg0KICAgcGF0aHMgaW4gYW4gRVZQTiBuZXR3b3JrLiBU aGUgbXVsdGktZGVzdGluYXRpb24gcGF0aHMgYXJlIHVzZWQgYnkNCiAgIEJyb2FkY2FzdCwgdW5r bm93biBVbmljYXN0IGFuZCBNdWx0aWNhc3QgKEJVTSkgdHJhZmZpYy4gVGhlDQogICBtZWNoYW5p c21zIHByb3Bvc2VkIGluIHRoZSBkcmFmdCB1c2UgdGhlIHByaW5jaXBsZXMgb2YgdGhlIHdpZGVs eQ0KICAgYWRvcHRlZCBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHBy b3RvY29sLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Feb 18 12:02: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 378A81A04FB; Tue, 18 Feb 2014 12:02:22 -0800 (PST) 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 Ycril98bhlWv; Tue, 18 Feb 2014 12:02:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 931BB1A0470; Tue, 18 Feb 2014 12:02:20 -0800 (PST) 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-multipoint-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140218200220.2030.62874.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 12:02:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7icrQ_0jfP1thLNeYY2ryCAJmuQ 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, 18 Feb 2014 20:02: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 for Multipoint Networks Authors : Dave Katz Dave Ward Filename : draft-ietf-bfd-multipoint-03.txt Pages : 29 Date : 2014-02-05 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg-bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-multipoint-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-03 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/